At 11:37 AM 10/3/96 -0700, Ran Atkinson wrote:
Dima Volodin writes:
Now can I hold my breath waiting for vendors to incorporate this stuff into their products?
At least BSDI, Sun, SGI, and HP are working on TCP SYN hardening. (yes, cisco is also on top of things :-).
I have no data on what might be up at other vendors.
Check out the elegant solution just announced by Checkpoint: http://www.checkpoint.com/fw21/syndefender/syndefender-white.html This is a firewall solution. I like the psuedo-NAT done to adjust sequence number. ---------------------------------------------------------------------------- Richard Stiennon richards@netrex.com Director, Business Development http://www.netrex.com Netrex, Inc. Voice: 810-352-9643 Southfield, Michigan Fax: 810-352-2375 ----------------------------------------------------------------------------- Providing businesses and organizations with secure Internet solutions.
Any data on how the firewall itself withstands SYN attacks? How much resources are needed to cope with a real attack? From what I've read in their white paper it's just a piece of SYN-processing code that was duplicated (functionally) in the gateway, so all concerns about resource usage and speed seem to be still valid. Dima Richard Stiennon writes:
Check out the elegant solution just announced by Checkpoint:
http://www.checkpoint.com/fw21/syndefender/syndefender-white.html
This is a firewall solution. I like the psuedo-NAT done to adjust sequence number. ---------------------------------------------------------------------------- Richard Stiennon richards@netrex.com Director, Business Development http://www.netrex.com Netrex, Inc. Voice: 810-352-9643 Southfield, Michigan Fax: 810-352-2375 ----------------------------------------------------------------------------- Providing businesses and organizations with secure Internet solutions.
The moving finger of Dima Volodin, having written:
Dima> Any data on how the firewall itself withstands SYN attacks? How much Dima> resources are needed to cope with a real attack? From what I've read in Dima> their white paper it's just a piece of SYN-processing code that was Dima> duplicated (functionally) in the gateway, so all concerns about resource Dima> usage and speed seem to be still valid. Dima> Dima I agree. It seems to me that placing this processing in the firewall is *potentially* dangerous, as now a SYN-flooding attack (*IF* *successful*) will deny service to everything behind the firewall, instead of just the targeted host. If I know I can fire-hose your firewall, and take your *site* off the net, then it might become more attractive to me to "find" sufficient CPU and bandwidth resources to generate enough packets to take you out. This could "raise the stakes" enough to make it worth it to an attacker. -- Tom E. Perrine (tep@SDSC.EDU) | San Diego Supercomputer Center http://www.sdsc.edu/~tep/ | Voice: +1.619.534.5000 "Ille Albus Canne Vinco Homines" - You Know Who
I agree.
It seems to me that placing this processing in the firewall is *potentially* dangerous, as now a SYN-flooding attack (*IF* *successful*) will deny service to everything behind the firewall, instead of just the targeted host.
If I know I can fire-hose your firewall, and take your *site* off the net, then it might become more attractive to me to "find" sufficient CPU and bandwidth resources to generate enough packets to take you out. This could "raise the stakes" enough to make it worth it to an attacker.
If someone can hose a firewall with an adaptive SYN timeout and a 100,000 or more-entry state storage structure for pending SYNs (not that any particular implementation does this that I know of or don't know of) then I *WANT* them to attack me. Something that un-subtle should be eeasy to track back to the source.
Tom E. Perrine (tep@SDSC.EDU) | San Diego Supercomputer Center http://www.sdsc.edu/~tep/ | Voice: +1.619.534.5000 "Ille Albus Canne Vinco Homines" - You Know Who
Avi
Now what is 100,000 entries? With the timeout aggressively set at 10 secs (heck, with 10 secs I sometimes cannot even get all the images on home.netscape.com) it's only 1000 SYNs/sec. How many hosts you want to protect with such a firewall? Dima Avi Freedman writes:
If someone can hose a firewall with an adaptive SYN timeout and a 100,000 or more-entry state storage structure for pending SYNs (not that any particular implementation does this that I know of or don't know of) then I *WANT* them to attack me.
Something that un-subtle should be eeasy to track back to the source.
Tom E. Perrine (tep@SDSC.EDU) | San Diego Supercomputer Center http://www.sdsc.edu/~tep/ | Voice: +1.619.534.5000 "Ille Albus Canne Vinco Homines" - You Know Who
Avi
Now what is 100,000 entries? With the timeout aggressively set at 10 secs (heck, with 10 secs I sometimes cannot even get all the images on home.netscape.com) it's only 1000 SYNs/sec. How many hosts you want to protect with such a firewall?
Dima
A timeout of 10 seconds is on two packets going back and forth. Many have said that the timeout must be much higher. I just don't see it. A SYN arrives. A SYN-ACK is sent out. A 10 second timer starts that is counted down to 0. An ACK of that SYN-ACK arrives back within the 10 seconds and we set up the connection. If the two packets can't each go one way in 10 seconds, the SYN will be retransmitted. The timeout isn't on open connections, just on embryonic ones. So let's say 1,000,000 entries: But even 100k entries at 10 seconds allows for 10k packets/sec, which is 2 * what you can receive in a maxed out t1. My preferred approach is to not even have to store state on any of the embryonic connections. And to implement the fix on all of my hosts. And customers can implement it in a firewall, if they choose (and have boxes which can't be fixed: Win95, NT, Macs, ...). Avi
Avi Freedman writes:
If someone can hose a firewall with an adaptive SYN timeout and a 100,000 or more-entry state storage structure for pending SYNs (not that any particular implementation does this that I know of or don't know of) then I *WANT* them to attack me.
Something that un-subtle should be eeasy to track back to the source.
Tom E. Perrine (tep@SDSC.EDU) | San Diego Supercomputer Center http://www.sdsc.edu/~tep/ | Voice: +1.619.534.5000 "Ille Albus Canne Vinco Homines" - You Know Who
Avi
My preferred approach is to not even have to store state on any of the embryonic connections. And to implement the fix on all of my hosts. And customers can implement it in a firewall, if they choose (and have boxes which can't be fixed: Win95, NT, Macs, ...).
Avi
Agreed. Certainly this should be an option in the host kernel configuration; performing this service in firewalls is a valid option as well; and I might add, this is what will 'more than likely' happen. I think we would all like to see TCP continue to rein as an end2end protocol. To concede that TCP in not an end2end protocol is 'a stake in the heart of TCP' (ouch!). Ihe issue is how best to do this in tcp_input.c, IMO. The algorithm is non-trivial. Random packet drop is not perfect and when I try to hash the connections looking for SYN_RECV states and timeout values; it is difficult to build an algorithm (if not, for memory constraints, practically impossible) that will stop the attack over high speed networks. I have not been constraining my lab tests to WANS and T1 connections, BTW. When/If SYN attack code becomes common place (i.e. available on MS Windows, etc.), the office place can become a battlefield. as everyone can well imagine, further adding 'mud to the face' of TCP and the future of the protocol for high speed networks. This is why I have been testing all ideas on the over Ethernet. In the 'office or internal organizational attack' scenerio, an outside firewall is ineffective, of course, unless ones thinks it is a good idea to put up a firewall in front of every server??? The firewall, stated another way, should be in the TCP/IP implementation to strengthen TCP/IP. Best Regards, Tim
Avi Freedman writes:
Now what is 100,000 entries? With the timeout aggressively set at 10 secs (heck, with 10 secs I sometimes cannot even get all the images on home.netscape.com) it's only 1000 SYNs/sec. How many hosts you want to protect with such a firewall?
Dima
A timeout of 10 seconds is on two packets going back and forth. Many have said that the timeout must be much higher. I just don't see it. A SYN arrives. A SYN-ACK is sent out. A 10 second timer starts that is counted down to 0. An ACK of that SYN-ACK arrives back within the 10 seconds and we set up the connection. If the two packets can't each go one way in 10 seconds, the SYN will be retransmitted.
(quoting myself): (heck, with 10 secs I sometimes cannot even get all the images on home.netscape.com) My kernel values: tcp_ip_abort_cinterval 10000 tcp_ip_notify_cinterval 1000 In Solaris, these values work for both incoming and outgoing connections. I could have lowered the notify_cinterval even more though. And I'm not even on a dial-up line: traceroute to www30.netscape.com (207.12.240.31), 30 hops max, 40 byte packets 1 206.229.244.1 (206.229.244.1) 159 ms 106 ms 10 ms 2 sl-dc-17-S1/0-T1.sprintlink.net (144.228.0.225) 11 ms 7 ms 15 ms 3 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 19 ms 8 ms 8 ms 4 sl-stk-5-H1/0-T3.sprintlink.net (144.228.10.2) 80 ms 81 ms 79 ms 5 sl-stk-16-F0/0.sprintlink.net (144.228.40.16) 77 ms 79 ms 81 ms 6 sl-netscape-1-s-T3.sprintlink.net (144.228.146.26) 223 ms 101 ms 162 ms 7 207.12.240.31 (207.12.240.31) 147 ms 85 ms 92 ms
My preferred approach is to not even have to store state on any of the embryonic connections. And to implement the fix on all of my hosts. And customers can implement it in a firewall, if they choose (and have boxes which can't be fixed: Win95, NT, Macs, ...).
That's for sure. The only thing that bothers me with this approach - why we need all those stinking options in TCP SYN packets then?
Avi
Dima
Tom Perrine writes:
Dima> Any data on how the firewall itself withstands SYN attacks? How much Dima> resources are needed to cope with a real attack? From what I've read in Dima> their white paper it's just a piece of SYN-processing code that was Dima> duplicated (functionally) in the gateway, so all concerns about resource Dima> usage and speed seem to be still valid.
I agree.
It seems to me that placing this processing in the firewall is *potentially* dangerous, as now a SYN-flooding attack (*IF* *successful*) will deny service to everything behind the firewall, instead of just the targeted host.
If I know I can fire-hose your firewall, and take your *site* off the net, then it might become more attractive to me to "find" sufficient CPU and bandwidth resources to generate enough packets to take you out. This could "raise the stakes" enough to make it worth it to an attacker.
I have no opinion about this product specifically, though I don't really favor the approach (at least if you have other options, which most people do). However, I doubt this objection is valid. I think it should be pretty easy to write code that can handle an entire T1 full of SYNs pretty easily on a low-end pentium box (as long as the Ethernet driver is up to it, which should also not be a big problem). Even without the moderately clever ideas already being implemented (like random drop and SYN hashing) the current bsd code can comfortably handle 1000 elements in a linked list. Hashing alone will probably buy you two or three orders of magnitude improvement. So maybe you can kill someone's firewall with a T3 with this approach. So what? You can *already* do that... /a
Check out the elegant solution just announced by Checkpoint:
Yep, if you are in the business of: (1) selling firewalls; Good idea. However, puttin up 'yet another firewall' is 'not elegant', IMO. The point to understand is the following.... All the 'ideas and solutions' of the past few days show just how much developers and hackers can rise to a challenge AND... Do not go out a buy a 'SYNDefender' just yet, because, as mentioned, the SYN problem is solvable in the TCP/IP code. It is just a matter of time..... Best Regards, Tim
Richard Stiennon writes:
Check out the elegant solution just announced by Checkpoint:
http://www.checkpoint.com/fw21/syndefender/syndefender-white.html
This is a firewall solution. I like the psuedo-NAT done to adjust sequence number.
I'm not fond of this class of solution. I'll also point out that it appears that kernel fixes almost completely alleviate the problem. Perry
participants (8)
-
Alexis Rosen -
Avi Freedman -
dvv＠sprint.net -
Perry E. Metzger -
Richard Stiennon -
Tim Bass -
Tim Bass -
Tom Perrine