From owner-freebsd-security Tue Jan 18 22:49:30 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 1B4CE14E36 for ; Tue, 18 Jan 2000 22:49:24 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id XAA17373; Tue, 18 Jan 2000 23:49:01 -0700 (MST) Message-Id: <4.2.2.20000118234610.01dd9b60@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 18 Jan 2000 23:49:02 -0700 To: Matthew Dillon , Wes Peters From: Brett Glass Subject: Re: TCP/IP Cc: patl@phoenix.volant.org, David Wolfskill , matt@ARPA.MAIL.NET, freebsd-security@FreeBSD.ORG In-Reply-To: <200001190630.WAA33466@apollo.backplane.com> References: <388557FB.443E66B0@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 11:30 PM 1/18/2000 , Matthew Dillon wrote: > Blocking SYN floods with spoofed source IP addresses is virtually > impossible. Not only can one not tell the difference between a spoofed > packet and a real SYN, it is also virtually impossible to determine > whether the actual source of the packets is if the source is not coming > from another customer in the same ISP. True. But one can minimize the damage. The best way to do this seems to be via a pseudorandom sequence number on the SYN-ACK, which eliminates the need for the server to retain any state after the SYN. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message