Re: SYN floods - possible solution? (fwd)
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
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
On Fri, 13 Sep 1996, Alexis Rosen wrote:
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. :-(
Tell me about it. But if this kind of solution could be packaged up in a single box with two ethernet interfaces then a lot of less clueful ISP's could easily install such a thing and protect their whole network. If the box also provided default filters on source addresses that could help solve another problem as well. The fear of attack may well be the force which overcomes inertia here and gets more ISP's up to speed on these issues just like AIDS brought the issues of safe sex to the forefront.
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.
Well, the advantage to using something like FreeBSD is that it is freely available, well-documented, and eleigible for creating commercial products as long as you check copyrights carefully. Most parts of FreeBSD have no commercial use restrictions like GNU does. And FreeBSD already has the basic functionality in it including support for readily available hardware including 10baseT and 100baseTx and FDDI interfaces. Building this kind of box would be mostly an excercise in subtraction and it may well be possible to strip enough stuff out that it can all be booted off a 1.44 megabyte diskette into a diskless 486 or Pentium box with a RAMdisk. At that point all an ISP needs to do is download a file, a disk writing utility (RAWRITE.EXE) and assemble a box with certain standard components like their choice of 3 types of network card as mentioned above. If the box included ssh for the admin interface maybe it could create a precedent for router manufacturers? NOTE: I copied this one to freebsd-hackers Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
-->Well, the advantage to using something like FreeBSD is that it is freely -->available, well-documented, and eleigible for creating commercial products -->as long as you check copyrights carefully. Most parts of FreeBSD have no -->commercial use restrictions like GNU does. --> -->And FreeBSD already has the basic functionality in it including support -->for readily available hardware including 10baseT and 100baseTx and FDDI -->interfaces. Building this kind of box would be mostly an excercise in -->subtraction and it may well be possible to strip enough stuff out that it -->can all be booted off a 1.44 megabyte diskette into a diskless 486 or -->Pentium box with a RAMdisk. --> -->At that point all an ISP needs to do is download a file, a disk writing -->utility (RAWRITE.EXE) and assemble a box with certain standard components -->like their choice of 3 types of network card as mentioned above. If the -->box included ssh for the admin interface maybe it could create a precedent -->for router manufacturers? --> -->NOTE: I copied this one to freebsd-hackers --> -->Michael Dillon - ISP & Internet Consulting -->Memra Software Inc. - Fax: +1-604-546-3049 -->http://www.memra.com - E-mail: michael@memra.com --> well it's sad to say, but if you want to get the attention of anybody around here in this clueful organisation, you have to put it on NT and make sure microsoft supports it. I hate NT, I'd NEVER run it on my box, but there are enough people around here that that's all they care about. I approached our people concerning this yesterday and was stunned to see blank stares and the question, "you mean you can . . . Why would you want to do that? . . . They'd never strike here." so I attempted to create a filter for our max. All that was successful in doing was destroying our rip updates. The filtering code on a max isn't the best since they don't concider arp an ip protocol, you have to deny all other IP then allow the rest. I'll probably look at it some more today. Jeremy -- ------------------------------------------- | Jeremy Hall Network Engineer | | ISDN-Net, Inc Office +1-615-371-1625 | | Nashville, TN and the southeast USA | | jhall@isdn.net Pager +1-615-702-0750 | -------------------------------------------
... and other discussion about <<they are updating phasers and we are building new shields>>... Please, note one important issue. You can protect you server from SYN attack, you can protect it against spoofing, etc... But IF customer (cracker) will be allowed to send packets with the ANY SRC address into the whole network, he (cracker) will have always 1,000 different ways of cracking the Internet. He can send DNS request with YOUR src address, he can send SYN's, he can send ICMP UNREACHABLE and any other packets. The only shield you can use this case is _your pipe is larger then him one_. But if there is any way to cause some server to send 10 packets on 1 requesting UDP packet - that's all... The ONLY way of preventing this attacks is SRC CONTROL you must have on the boundaries with the customers. IP provider have to control customers STRICTLY. One way to do it is _to check routing of SRC address_. Then (in this check) different criterias of filtering can be used. The easiest is _back routing have to be the same as direct routing_; another is _SRC from interface0 can't be routed to interface2_, etc... But anyway, this (by SRC) filtering is the only way of creating good shield. --- Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
alex@relcom.EU.net writes:
[...] He can send DNS request with YOUR src address, [...]
Apart from the obvious sexism :-) of the message let me point out that there are some other tricks one can play with DNS, e.g. throwing in any addresses for some other's servers in additional records in your DNS reponces. We are hit by this DNS/named deficiency _every freaking day_.
Aleksei Roudnev, Network Operations Center, Relcom, Moscow
Dima
On Thu, 12 Sep 1996, Michael Dillon wrote: ==>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 ==> ==>From: "Roderick Murchison, Jr." <murchiso@vivid.newbridge.com> ==> ==>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 This is bad. You should never depend upon remote hosts to give you ICMP responses to establish connections. This is because of several reasons: 1. What if a real remote site uses "established" connection firewalls and chooses to block ICMP? In that case, you've limited yourself vastly as to what can connect to you (there are a lot of sites which use cisco's "established" keyword to firewall and keep functionality). 2. When links become congested, ICMP packets are given a lower priority to make way for real data. /cah ---- Craig A. Huegen CCIE #2100 || || Network Analyst, IS-Network/Telecom || || cisco Systems, Inc., 250 West Tasman Drive |||| |||| San Jose, CA 95134, (408) 526-8104 ..:||||||:..:||||||:.. email: chuegen@cisco.com c i s c o S y s t e m s
Yes, using ICMP to try and do TCP SYN validation is bad. In addition to case where a firewalled site blocks ICMP, consider the case where a group of hosts will respond to pings but have (some/much) TCP traffic to them filtered by a conventional firewall. These hosts can be used as candidate source addresses for TCP SYN attack as they will respond to the ICMP echo request but will not send a TCP RST to tear down the bogus TCP connection. Much better IMO to consider waiting for a TCP ACK response to TCP SYN ACK for the requested TCP connection than to wait for ICMP echo response at the firewall. As noted before this is a very simple transparent proxy service that can be implemented at the packet level very similar to that of a NAT box. -Steve
On Thu, 12 Sep 1996, Michael Dillon wrote:
==>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 ==> ==>From: "Roderick Murchison, Jr." <murchiso@vivid.newbridge.com> ==> ==>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
This is bad. You should never depend upon remote hosts to give you ICMP responses to establish connections. This is because of several reasons:
1. What if a real remote site uses "established" connection firewalls and chooses to block ICMP? In that case, you've limited yourself vastly as to what can connect to you (there are a lot of sites which use cisco's "established" keyword to firewall and keep functionality).
2. When links become congested, ICMP packets are given a lower priority to make way for real data.
/cah
---- Craig A. Huegen CCIE #2100 || || Network Analyst, IS-Network/Telecom || || cisco Systems, Inc., 250 West Tasman Drive |||| |||| San Jose, CA 95134, (408) 526-8104 ..:||||||:..:||||||:.. email: chuegen@cisco.com c i s c o S y s t e m s
participants (7)
-
alex＠relcom.EU.net -
Alexis Rosen -
Craig A. Huegen -
dvv＠sprint.net -
Michael Dillon -
Mr. Jeremy Hall -
Steven L. Johnson