With source, and reasonable knowledge of the kernel, this would be easy enough to do on any unix. Avi's already explained what needs to be done, and you don't need a special box. But to protect other machines, you'd have to put a filter machine in front of them. This sounds like a workable solution to me, for those who can cope with the technical or financial demands (which *might* not be so high). There's no protocol issue to prevent this. You can tag held SYNs any way you like; you're not limited to using parts of the packet. But even if you did, it would still be fine. If your attacker were on a T1, and *if* his router and your can handle the packet-forwarding load, you could see perhaps 4000 pps theoretical max. In real life I'd be surprised to see half that many, and that would be a *real* flood. 30sec. timeout means 60k slots in a hash table of SYNs, each taking up 12 bytes for the data. Your total memory used is maybe 1MB if you figure the hash just right. You might also do better if you used a tree keyed on the source IP. For free, you can protect any number of hosts, not just one. But... I still don't believe that this is a good global solution. Most ISPs can't cope with this. The clue level I've been seeing among many of the ISP "engineers" and "systems administrators" who have called in the last few days to ask for help ("is your problem happening to me too???") is astonishingly low. :-( I also have no clue what I'd choose to implement this on. It *could* be done in a unix kernel but that's probably a really *bad* choice. I'm sure plenty of people out there know some good possibilities, though. /a Michael Dillon writes:
Now here is something that could be used by sites to protect against SYN flood attacke assuming that they can build a special custom box with enough RAM to buffer the sockets for 30 seconds or more. How high a rate can SYN floods come in at? I've heard of 1,000 per sec which implies that this box needs to hold open 30,000 to 75,000 potential sockets. Is there any problem within IPv4 (seq #'s?) that would make this inherently impossible?
Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
---------- Forwarded message ---------- Date: Fri, 13 Sep 1996 01:36:54 -0400 (EDT) From: "Roderick Murchison, Jr." <murchiso@vivid.newbridge.com> To: firewall-1@applicom.co.il Cc: firewalls@GreatCircle.COM Subject: Re: SYN floods - possible solution?
On Thu, 12 Sep 1996, Blast wrote:
This problem has kept me awake more than coffee. :-)
Ditto... I just woke up *again* with a kludgy but potential defense... sorry if this is totally out of whack, but I'm really beat!
Ok. say you have a firewall between your network and you Internet connection. If that firewall could detect and *detain* a segment with the SYN option set, then see if the set source IP answers an ICMP echo request, we could effectively determine whether or not the SYN could be dropped at the firewall and not sent through to spam our hosts. If the source responds, release the SYN and let it pass through to the intended host. If it does not, trash the SYN and log the failure.
Some moderate tracking and aging methods could be employed to intelligently quick drop sources we know are recently offline, and lessen the amount of echo requests we send out.
Could this be a potential defense? If so, what products would be best suited to implement this?
hope this helps, -r
Roderick Murchison, Jr. murchiso@vivid.newbridge.com Newbridge Networks, Inc. office: (703) 708-5930 Product Manager - VIVID ACS fax: (703) 708-5937 Herndon, VA 22070-5241 http://www.vivid.newbridge.com