Date: Thu, 13 May 1999 19:37:44 -0700 (PDT) From: Thamer Al-Herbish <shadows@whitefang.com> To: security@FreeBSD.ORG Subject: Re: Forwarded from BUGTRAQ: SYN floods against FreeBSD Message-ID: <Pine.BSF.4.05.9905131924570.267-100000@rage.whitefang.com> In-Reply-To: <19990513222133.A23982@puck.nether.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 13 May 1999, Jared Mauch wrote: > What would be ideal is to have a fair-queue such as this: > > real-queue = 16 > extended-queue = 32 > > once the real-queue fills with syns, fill the extended > queue, (these are folks that need syn-ack, btw), once the > extended queue fills, begin sequentially dropping elements from the > real-queue I don't see you mentioning why its more fair? Are you assuming that the real queue will most likely have bogus packets? If the bogus syn packets are coming in faster than the real ones you'll wind up kicking off all the real ones. I'm assuming the random dropping will be more fair because in time you'll eventually respond to a real SYNs in the face of a storm of bogus SYNs. Btw, if it matters any I liked Bernstein's syn cookies. The only conceivable problem there was storing initial TCP option information which could not be done because of the cookie-response design. Quick summary of syn cookies: You would send back a cookie as one the sequence number based on a secret that changes every so often hashed with the clients initial sequence number. If you get back a SYN-ACK, you check it against the same hash, and a match means you can respond and finish the handshake. You effectively _never_ store information about the first SYNs and thus _never_ have to worry about resources. TCBs are created after the hand shake is completed. > Obviously, doing prefered drops (based on dst port on our side), > ie: we have 200 syns for port 80, but only 3 for port 22, deal with the > 3 that are not causing a problem first, so we can get ssh in, but let the > web folks go a bit slower. Why not deal with them both? In both instances you either accept or drop incoming SYNs. It doesn't cost you more to handle both unless you're talking about CPU cycles with which the added overhead of not handling would be insignificant. Or are you assuming otherwise? -- Thamer Al-Herbish PGP public key: shadows@whitefang.com http://www.whitefang.com/pgpkey.txt [ The Secure UNIX Programming FAQ http://www.whitefang.com/sup/ ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9905131924570.267-100000>