From owner-freebsd-security Fri Dec 1 13:53:36 2000 Delivered-To: freebsd-security@freebsd.org Received: from nenya.ms.mff.cuni.cz (nenya.ms.mff.cuni.cz [195.113.17.137]) by hub.freebsd.org (Postfix) with ESMTP id 21BC837B401 for ; Fri, 1 Dec 2000 13:53:33 -0800 (PST) Received: from localhost (mencl@localhost) by nenya.ms.mff.cuni.cz (8.9.3+Sun/8.9.1) with ESMTP id WAA07088; Fri, 1 Dec 2000 22:53:06 +0100 (MET) Date: Fri, 1 Dec 2000 22:53:06 +0100 (MET) From: "Vladimir Mencl, MK, susSED" To: Brett Glass Cc: Umesh Krishnaswamy , freebsd-security@FreeBSD.ORG Subject: Re: Defeating SYN flood attacks In-Reply-To: <4.3.2.7.2.20001201131729.04907bf0@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 1 Dec 2000, Brett Glass wrote: > Steve Gibson just published a great article on SYN flood avoidance, > complete with a mechanism that I think FreeBSD should adopt for it. > See I see two problems with it. 1) SYN/ACKs are not resent. This partially breaks the TCP concept, resending is completely transferred to client, doubling the load (statistically according to the probability that a packet is lost). 2) Once you KNOW the SISN, you can make requests to the server even without being able to read its responses. This can be security issue when you rely on your firewall to block some incoming connections (SYN packets only), and you have a stateless firewall. In the current state, one could wait for the servers SISN for an (allowed) http connection, then try to telnet to that machine (not allowed) by spoofing an ACK with the already known SISN. The scheme might be improved be making BOTH portnumbers a part of the encrypted plaintext, however still the scheme may be exploited (though in rather obscure scenarios). Vladimir Mencl > > http://grc.com/r&d/nomoredos.htm > > --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message