Re: New Denial of Service Attack on Panix
At 09:09 AM 9/18/96 -0400, Guy T Almes wrote:
Kent, I liked the rest of your message more than the first sentence.
I wish that it were not so, but after reading the clever and insightful approaches to tracking down the denial-of-service perps, I am pessimistic about our ability to stay ahead in the escalation of this counter-counter- measure warfare. I think that if we were able to trace the Panix attacker that a future attacker would hit simultaneously from a half-dozen free dial-up connections with a real random number generator and synthetic SYNs to fool the router stat collector (or whatever it takes). I think we are on the short end of the technology stick here.
I want to amend my statement a bit. While it sounds like I completely ignored Curtis' summary message from Monday, in fact, I never received any of those nanog messages and if I had, I doubt that I would have posted my original message. I faithfully read all my nanog mail and I don't understand the gaps in my receipts. It seems to me after reading Curtis' summary that servers can be modified to make the SYN flooding attacks much more difficult to accomplish. Perhaps enough so that source address filtering doesn't have the urgency of implementation and coordination that I thought before reading Curtis' note. --Kent
We too have recently gotten hit with these wonderful syn attacks, until router logging (or whatever means we develop to trace these packets is developed) I think there are only 2 resolutions 1) filter incoming ip's, at least on dial-ups and on non-border (or non-core) routers for ip-spoofing. (Do not allow ip's that should not originate over this port(s) to be passed), this will allow ISP's to stop their users from originating these floods. 2) Fix the OS's to not be as susceptible to SYN floods. This will eventually make the hackers board and the problem will slowely disappear. (well, maybe) --Dan Ellis MIS On Wed, 18 Sep 1996, Kent W. England wrote:
It seems to me after reading Curtis' summary that servers can be modified to make the SYN flooding attacks much more difficult to accomplish. Perhaps enough so that source address filtering doesn't have the urgency of implementation and coordination that I thought before reading Curtis' note.
--Kent
~.............................................................................. --Daniel Ellis Director of Engineering / Chief Engineer, MicroServe Information Systems Inc. "The only way to predict the future is to invent it." --Alan Kay
Good Morning, Please excuse me if this simple suggestion was mentioned in the thread (the traffic was so heavy I did not read so many), but I woke up this morning thinking simply: If all ISPs would configure final end user routers (not transit carriers or intermediate systems, but only the router that actually services end users) to drop all packets originating in the direction of the end user where the source IP address does not match the IP address of the customer on a per port basis (or some variation of this plot and theme) then it would become trival to trace these denial-of-service attacks. Again, I apologize if this simple technique was mentioned during the heavy traffic on the subject and I missed it, but this approach seems so simple, that it must of been mentioned, but I missed it. For this simple technique, I agree that a BCP is appropriate, so all IP service providers can 'sing off the same sheet of music' and cooperate together to stop bogus packets originating inside of their 'sphere of influence'. Of course, getting all providers in the world to cooperate sounds like an impossible task, so in that case, all level 0, 1, etc. transit networks must have a policy that all downstream (or is it upstream, I'm still asleep) do this filtering as part of the service agreement. Unless my groggy mind from a deep sleep is missing some marbles, this general technique and administrative policy would go a very long way toward stopping the random() attack and provide for a much easier way to trace attackers. Yawn. Back to sleep...... All The Best, Tim
Hi. I've been testing the SYN attack on with 'the patch' with no success of stopping the attack so far with the patch (right now, without the patch it is DoA and with the patch, the attack panics the kernel :.... but this is more-than likely an implementation issue that will be solved. However, I was thinking (dangerous, admittedly) that since the success of the attack is based on using an UNREACHABLE source address and the host under attack attempts to ACK/SYN with the bogus attacker wouldn't it be easier to: Just have either (1) a listening daemon; (2) or an internal flag in the kernel, (3) or some other better IPC, to notify TCP, or better yet, IP to say: "Hey, there is a lot of HOST UNREACHABLES going on here, and I don't like it" algorithm to either (a) just filter the IP packets at in the kernel IP code, (best IMO) (b) or do it in the TCP code? This seems simple, so I must be missing something in this! Because, it seems to me, since the way to exploit TCP is to use bogus, unreachable IP sources, why not use this fact to let the kernal just filter itself under certain flooding conditions? Please let me know why this will not work. Thanks, Tim
Nevermind..... I've been working on the non-random attack first.... I apologize for wasting everyones time when the approach below does nothing for the random() attack. Staying up too late in the lab, I guess. Best Regards, Tim
Hi.
I've been testing the SYN attack on with 'the patch' with no success of stopping the attack so far with the patch (right now, without the patch it is DoA and with the patch, the attack panics the kernel :.... but this is more-than likely an implementation issue that will be solved.
However, I was thinking (dangerous, admittedly) that since the success of the attack is based on using an UNREACHABLE source address and the host under attack attempts to ACK/SYN with the bogus attacker wouldn't it be easier to:
Just have either (1) a listening daemon; (2) or an internal flag in the kernel, (3) or some other better IPC, to notify TCP, or better yet, IP to say: "Hey, there is a lot of HOST UNREACHABLES going on here, and I don't like it" algorithm to either (a) just filter the IP packets at in the kernel IP code, (best IMO) (b) or do it in the TCP code?
This seems simple, so I must be missing something in this!
Because, it seems to me, since the way to exploit TCP is to use bogus, unreachable IP sources, why not use this fact to let the kernal just filter itself under certain flooding conditions?
Please let me know why this will not work.
Thanks,
Tim
Tim Bass writes:
[...]
Because, it seems to me, since the way to exploit TCP is to use bogus, unreachable IP sources, why not use this fact to let the kernal just filter itself under certain flooding conditions?
Please let me know why this will not work.
Thanks,
It will, except that a slight modification of the attack (using IP addresses that _don't_ produce ICMP_UNREACH) will get us back to square one. Anyway, filtering packets with SRC addresses known to generate ICMP_UNREACH at the earliest possible stage might be a good idea.
Tim
Dima
It will, except that a slight modification of the attack (using IP addresses that _don't_ produce ICMP_UNREACH) will get us back to square one.
Anyway, filtering packets with SRC addresses known to generate ICMP_UNREACH at the earliest possible stage might be a good idea.
I understand paragraph two, but about paragraph 1.... When I ran the TCP SYN attack using routable source addresses, before I patched my attack kernel to allow Spoofers, I literally beat-to-death a server on the same subnet and the attack has no effect. However, when I hacked the kernel to allow spoofed addresses, the attack was severe and immediate. So, from my tests, the attack is only sucessful when the bogus source address is UNREACHABLE (which is a defense in the non-random attack. For clarity, the attack only works when the IP source address is UNREACHABLE, this has been my observation here in the lab using an source address from my net (however I haven't confirmed this with a good source address in another domain but I will...) Tim
Tim
Dima
Well, my understanding of your idea was that you proposed to detect SYN packets with unroutable src addresses before they hit the SYN_RCVD queue. The only way to deem them unroutable is to observe ICMP_UNREACHs hitting the box in large numbers. Now my first paragraph just means that an SRC address might be a perfectly routable one without its being real - an unused address on an ethernet segment is enough for the attack. Or thousands of them for an untraceable attack. Dima Tim Bass writes:
It will, except that a slight modification of the attack (using IP addresses that _don't_ produce ICMP_UNREACH) will get us back to square one.
Anyway, filtering packets with SRC addresses known to generate ICMP_UNREACH at the earliest possible stage might be a good idea.
I understand paragraph two, but about paragraph 1....
When I ran the TCP SYN attack using routable source addresses, before I patched my attack kernel to allow Spoofers, I literally beat-to-death a server on the same subnet and the attack has no effect.
However, when I hacked the kernel to allow spoofed addresses, the attack was severe and immediate. So, from my tests, the attack is only sucessful when the bogus source address is UNREACHABLE (which is a defense in the non-random attack.
For clarity, the attack only works when the IP source address is UNREACHABLE, this has been my observation here in the lab using an source address from my net (however I haven't confirmed this with a good source address in another domain but I will...)
Tim
Tim
Dima
Well, my understanding of your idea was that you proposed to detect SYN packets with unroutable src addresses before they hit the SYN_RCVD queue. The only way to deem them unroutable is to observe ICMP_UNREACHs hitting the box in large numbers. Now my first paragraph
Yes, we are 'in SYN' on the approach.....
just means that an SRC address might be a perfectly routable one without its being real - an unused address on an ethernet segment is enough for the attack. Or thousands of them for an untraceable attack.
Yes, this also works to our advantage, it seems. As long as the destination (the source route) is UNREACHABLE, be the address bogus like 0.0.0.4 or an unused IP address or a machine that is off on the network, thereby being UNREACHABLE; after some magic number of ICMP_UNREACHes IP could block them with a system clock stamp and unblock them after some other 'optimal deterministic' time. Thanks for pointing out that the UNREACHABLE could just be hosts that are turned off. The difficult case, now that you mention it, are the UNREACHABLEs due to a route flap or other intermediate system blip. However, there may be some 'deterministic time' or number of packets, etc. to set a metrics to fine tune this. Thanks for the feedback, BTW. Best Regards, Tim
Tim Bass writes:
Thanks for pointing out that the UNREACHABLE could just be hosts that are turned off. The difficult case, now that you mention it, are the UNREACHABLEs due to a route flap or other intermediate system blip.
A host being down is _not_ necessarily an UNREACHABLE host. In most cases you won't see _anything at all_ if a host on an ethernet is down. A smart router might detect a chronically unresolved ARP and produce an ICMP_UNREACH, but do you know about routers like that?
Tim
Dima
I just *KNOW* I'm going to make enemies out of this...
Begin forwarded message:
X-Fibernet-Tip: Don't quote more than you contribute! From: Tim Bass <bass@cactus.silkroad.com> Subject: Re: New Denial of Service Attack on Panix To: dvv@sprint.net (Dima Volodin) Date: Wed, 2 Oct 1996 18:01:30 -0400 (EDT) Cc: dvv@sprint.net, kwe@6SigmaNets.com, nanog@merit.edu, iepg@iepg.org In-Reply-To: <199610022151.RAA00565@mercury.int.sprintlink.net> from "Dima Volodin" at Oct 2, 96 05:51:34 pm X-Mailer: ELM [version 2.4 PL24]
Dima got sent a note, and then Dima got CCed. Anyone else see a problem with that? Further, two lists got CCed, but aren't Kent and Dima BOTH on BOTH lists? I don't mean to make a mountain out of a molehill, but I can't rightfully gnaw the leg off a newbie for over-CCing when my colleagues do it without contest. I know *I* don't need 2 copies of every post. If I'm wrong...tell me. Carl
...... The draft BCP that people are working on is OK. However, much of what I have seen today in my lab, might be better off discussed in private... I'll say, as most of you know, SR filtering is useful, but it cannot stop the attacks. Kernel Protection and Recovery Tools are Critical and Needed in a Hurry. Right now, I could use a 'simple command line flush the queue, close all sockets, release all descriptors' tool. If anyone has such a critter, it is one more brick in the wall. Please let me know. via e-mail, thanks. Regards, Tim
The draft BCP that people are working on is OK.
However, much of what I have seen today in my lab, might be better off discussed in private... I'll say, as most of you know, SR filtering is useful, but it cannot stop the attacks.
Kernel Protection and Recovery Tools are Critical and Needed in a Hurry.
Right now, I could use a 'simple command line flush the queue, close all sockets, release all descriptors' tool.
Comment out the line in /etc/inetd.conf; kill -1 the inetd proc; stop any processes listing on those ports; comment it back in; kill -1 inetd again. If you want to command-line it, move a file with the commented line in and out of /etc/inetd.conf's place. When there's nothing listening on those ports all the sockets, descriptors, queues, pcbs, etc... go away. Is this not what you were thinking of?
If anyone has such a critter, it is one more brick in the wall.
Please let me know. via e-mail, thanks.
Regards,
Tim
Avi
Two things: (1)
When there's nothing listening on those ports all the sockets, descriptors, queues, pcbs, etc... go away.
How about when a socket is actively listening? (2) Why when I do a traceroute to 0.0.0.4 or some similar bogus route, the router does not send an ICMP destination unreachable error back to me? My plan tonight was to hack the tcp_err() routine for sockets in the SYN_RECV state that is looking for an ACK and got an ICMP UNREACHABLE instead.... however, the ICMP UNREACHABLE CLUES never come. As my 5 year old nephew says.... " I NEED THAT !" Shouldn't these error messages be returned 'as a rule' ?? Thanks, Tim
Nevermind the 'clear the sockets thing' I just attack an inetd port and then kill inetd and they go away, which allows me to work faster in the lab. I guess my real question to someone who is more familiar with 'RFC' history is the same as the last post... Why when an attacked host sends a SYN,ACK to an UNREACHABLE destination does the SYN,ACK just go down a black hole without an ICMP message to the originator, when I use 0.0.0.4 as a spoofed address? Shouldn't this be covered in an RFC somewhere as something that must happen? The reason I ask is obvious.... if I could get the error message I could have tcp_err() do some quick and dirty cleaning of the queue (and at least have a piece of this puzzle in place..) Thanks, Tim
[CC: list rigorously trimmed] On Thu, 3 Oct 1996, Tim Bass wrote:
Why when an attacked host sends a SYN,ACK to an UNREACHABLE destination does the SYN,ACK just go down a black hole without an ICMP message to the originator, when I use 0.0.0.4 as a spoofed address?
Shouldn't this be covered in an RFC somewhere as something that must happen?
RFC792: If, according to the information in the gateway's routing tables, the network specified in the internet destination field of a datagram is unreachable, e.g., the distance to the network is infinity, the gateway may send a destination unreachable message to the internet source host of the datagram. In addition, in some networks, the gateway may be able to determine if the internet destination host is unreachable. Gateways in these networks may send destination unreachable messages to the source host when the destination host is unreachable. ICMP unreachable messages are optional in any case, but there seems to be a singularity about 0/8. Does anyone know why this is? Try using a different bogus source address... -- // Matt Zimmerman Chief of System Management NetRail, Inc. // mdz@netrail.net sales@netrail.net // (703) 524-4800 [voice] (703) 516-0500 [data] (703) 534-5033 [fax]
Thanks for the RFC quote..... I've been hacking code for hours and just the qoute is a big help. BTW: On the SYNDefender firewall..... if we are interested in firewalls, then the 'elegant firewall solution' is, IMO, to insure that our gateways send ICMP UNREACHABLE messages back to the host. Then it is somewhat easy to do the kernel checks to free SYN_REVC 'zombies' For example it is two hops from here to the provider host that blackholes the SYN/ACK second part of the handshake. If that gateway would send me an UNREACHABLE message, it would be easy to just end RST as in the no-problem reachable state. And, TCP remains an end-to-end protocol, which, I think, we all would think would be 'elegant'..... I feel like a cheerleader 'Give me an U N R E A C H A B L E' wha-at-ya-got ......... Best Regards, Tim
Tim Bass writes:
On the SYNDefender firewall..... if we are interested in firewalls, then the 'elegant firewall solution' is, IMO, to insure that our gateways send ICMP UNREACHABLE messages back to the host. Then it is somewhat easy to do the kernel checks to free SYN_REVC 'zombies'
It would also make it easier to nuke vital network communications paths. Thanks, but I'll pass. Perry
It would also make it easier to nuke vital network communications paths. Thanks, but I'll pass.
Well, do have a valid point? Let's see... If we use the condition: sk->state == TCP_SYN_RECV && buf->sk->saddr == icmp->sk->daddr Then any connection in the SYN state receiving an UNREACH that matched one of the active addresses in the queue.... translates to: If you are an attacker and know your target host is about to set up a connection with a particular host address, then if you timed it exactly right you could nuke the connection during one state of the TCP connection, SYN_RCVD. But, if the ICMP UNREACHABLE is set with the same sequence number as the actual bogus SYN/ACK packet then the condition becomes: sk->state == TCP_SYN_RECV && buf->sk->saddr == icmp->sk->daddr && buf->sk=seq_numb == icmp->sk->seq_num Out hero Rich Steven's says in 'The Protocols' the identifier field and the sequence number can be anything the sender wants to match the request and the reply.... pg. 71 aro, So, if you can guess sequence numbers, ip addresses, and the exact state on the connection..... er.. I think we can sleep okay with that security for a little while.... don't you? Thanks for the feedback, BTW. Tim PS; Here are some of my klog stuff that was playing during this email based on a yet to work defense... for those of you who do not have the time to enjoy hacking TCP: Oct 3 19:01:30 linux kernel: TCP CONN: BACKLOG = 7, MAXBACK = 10 Oct 3 19:01:30 linux kernel: TCP DROP: STATE = 3, ADDRESS = 00fbcd34 Q = 6 Oct 3 19:01:30 linux kernel: TCP CONN: BACKLOG = 7, MAXBACK = 10 Oct 3 19:01:30 linux kernel: TCP DROP: STATE = 3, ADDRESS = 00fbcd34 Q = 3 Oct 3 19:02:42 linux kernel: TCP CONN: BACKLOG = 0, MAXBACK = 10 Oct 3 19:03:21 linux kernel: TCP CONN: BACKLOG = 0, MAXBACK = 5 Oct 3 19:04:29 linux kernel: TCP CONN: BACKLOG = 0, MAXBACK = 5 Oct 3 19:10:09 linux kernel: TCP CONN: BACKLOG = 0, MAXBACK = 10 Oct 3 19:18:13 linux kernel: TCP CONN: BACKLOG = 0, MAXBACK = 5 Oct 3 19:20:57 linux kernel: TCP CONN: BACKLOG = 0, MAXBACK = 5
Tim Bass writes:
If you are an attacker and know your target host is about to set up a connection with a particular host address, then if you timed it exactly right you could nuke the connection during one state of the TCP connection, SYN_RCVD.
Yup. If you don't think this is a serious problem, well, I can think right away of how to use such a defect to cause serious harm to the infrastructure of the net. Indeed, I can think of two. We are trying to reduce the number of ways that forged packets can be used to cause harm, not open new ones.
So, if you can guess sequence numbers, ip addresses, and the exact state on the connection..... er..
What makes you think you can't? You CAN guess sequence numbers, and pretty consistantly. The paper by Bob Morris on how to do it is nearly a decade old. We have a simple and practical pair of ways of dealing with this: ingress filtering and host hardening. Lets stick with things that cause no additional harm, shall we? Perry
(Doing my usual reiteration thing) routers _cannot_ generate UNREACH for every host. Routers don't usually generate UNREACH for dead hosts on ethernet/FDDI (should they, anyway?). Routers cannot generate UNREACH for hosts that (for whatever reason) don't respond to spurious SYN/ACKs. Dima Tim Bass writes:
I feel like a cheerleader 'Give me an U N R E A C H A B L E' wha-at-ya-got .........
Best Regards,
Tim
(Doing my usual reiteration thing) routers _cannot_ generate UNREACH for every host. Routers don't usually generate UNREACH for dead hosts on ethernet/FDDI (should they, anyway?). Routers cannot generate
Yes, it's understood what 'routers usually don't do' :-) Routers don't do a lot of thing they might. Confirming this and pointed out by another, Postal, RFC 793, points out this could be done as well (guess vendors just decided not to do it). IMO, we are seeing one example (of many) why this 'might always be done' independent of the SYN attacks discussion. There are lots of application protocols that could benefit from knowing the destination was UNREACHABLE with an ICMP control packet. Why would you NOT want to know about network errors, for example why shouldn't a non-defaulting router inform the originator that 0.0.0.4 is not routable? Or, why would you not want to be informed that a host is UNREACHABLE? Even during periods of route flap, it should be up to the protocol designer to decide how to set timers and respond to such errors, etc. This is an interesting issue, IMO. Application and protocol programmers would have more information to 'use as they choose' if ICMP UNREACHABLES were actually sent when destinations are unreachable and sent 'as a rule'. This, IMO, is a direct protocol issue, and not a security issue per se. Best Regards, Tim
On Fri, 4 Oct 1996, Tim Bass wrote:
This is an interesting issue, IMO. Application and protocol programmers would have more information to 'use as they choose' if ICMP UNREACHABLES were actually sent when destinations are unreachable and sent 'as a rule'.
This, IMO, is a direct protocol issue, and not a security issue per se.
Right on! PHRACK will be publishing my program to transmit bogus ICMP UNREACHABLE packets in the december 2001 issue. It's called the Bass Player. :-) Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
Right on! PHRACK will be publishing my program to transmit bogus ICMP UNREACHABLE packets in the december 2001 issue. It's called the Bass Player. :-)
Wonderful! And Phack with publish a patch to ip_input.c that redirects all bogus ICMP directs root names servers as SYN packets called the Dillion Diversion :-) (think about it..) Therefore: It does not matter what the packet *is* or the information in the packet, it is up to the protocol implementor(s) to 'do the right thing' when a packet is received. TCP is broken. ICMP is broken. It is not Phrack or 2600 that broke it. VR, Tim
Yep. Life sucks and we all die. Dima Tim Bass writes:
Therefore:
It does not matter what the packet *is* or the information in the packet, it is up to the protocol implementor(s) to 'do the right thing' when a packet is received.
TCP is broken. ICMP is broken. It is not Phrack or 2600 that broke it.
VR,
Tim
Dimo laments: > Yep. Life sucks and we all die. Victor Hugo, _The Hunchback of Notre Dame_ and _Les Miserables_ both inspired by the author seeing the word FATALITY graphically painted on a wall in Paris. (I highly recommend _Les Miserables_) Jean Valjean, the man who, for stealing a loaf of bread to feed a starving family, lives out his entire life in misery... ... hence, FATALITY (set in Paris in the early 1800s) Anyway ..... I'll drop off unless someone can provide a technical suggestion on an algorithm that will stop high speed TCP SYN attacks in tcp_input.c (otherwise, I'm not moving toward my aim/target) What is the IPV6 approach to solving this problem? Is there one? Regards, Tim
See Jeff Weisberg's post to nanog yesterday. It can be solved in tcp_input.c, even for tens of thousands of syn packets/second. Just keep no state until the syn/ack comes back (and with a valid hash matching one you would have supplied as an initial seq number). Avi
Dimo laments: > Yep. Life sucks and we all die.
Victor Hugo, _The Hunchback of Notre Dame_ and _Les Miserables_ both inspired by the author seeing the word FATALITY graphically painted on a wall in Paris. (I highly recommend _Les Miserables_) Jean Valjean, the man who, for stealing a loaf of bread to feed a starving family, lives out his entire life in misery... ... hence, FATALITY (set in Paris in the early 1800s)
Anyway .....
I'll drop off unless someone can provide a technical suggestion on an algorithm that will stop high speed TCP SYN attacks in tcp_input.c (otherwise, I'm not moving toward my aim/target)
What is the IPV6 approach to solving this problem? Is there one?
Regards,
Tim
On Fri, 4 Oct 1996, Tim Bass wrote:
Right on! PHRACK will be publishing my program to transmit bogus ICMP UNREACHABLE packets in the december 2001 issue. It's called the Bass Player. :-)
Wonderful! And Phack with publish a patch to ip_input.c that redirects all bogus ICMP directs root names servers as SYN packets called the Dillion Diversion :-) (think about it..)
I have thought about it. If the Internet industry spends a couple of years deploying ICMP UNREACHABLE as you have asked, then they will have created a weakness that can be exploited by the Bass Player. Even though a solution to this problem could be deployed, it would also take years to work its way into most network hosts. The solution is to not deploy something that creates new attack possibilities. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
Well then, Mike, I disagree with your thought process. You can send ICMP unreachables all day long today! It only strengthens the protocol to send the correct error messages and to respond to the protocol conditions correctly. Also, you have not responded by a valid technical question, but are hand-waving... I'll ask again. How do you propose a hack can do these three things at the same time. (1) Know the state of a TCP connection (SYN_RCVD). (2) Know the sequence number of the response, (3) Know a random code in the identifier field, (4) Know the both source and destination address of connection; (5) Know the exact time window of the SYN-ACK/SYN-SYN handshake. If you, Mike, can break this, and explain how do do it, then we can add (6) MD5 authentication to ICMP. BTW, after you explain in detail how to spoof (1)-(5) then I would like to ask you a favor.... I would appreciate it if you would not give credit to for ICMP UNREACHABLE to me. ICMP UNREACHABLE errors are in specified in RFC 793. Please 'redirect' this credit elsewhere. It is not my original idea. All I am asking is for the procotcol to work as designed so I can have one more piece of info to use in an algorithm. I await your technical reply on how to defeat the conditions 1-5 above, and if you can, then add 6 and explain how do defeat that as well. Somewhat Patiently (but anxiously awaiting technical answers), Tim
On Fri, 4 Oct 1996, Tim Bass wrote:
Also, you have not responded by a valid technical question, but are hand-waving... I'll ask again. How do you propose a hack can do these three things at the same time.
This is not the right forum to discuss TCP internals nor is it the right forum to discuss building hardened kernels There are already lots of people working on fixing the SYN problems. Implementations are available for SunOS, FreeBSD, NetBSD, BSDI, Linux, IRIX and perhaps others. Solaris can be protected by adjusting kernel resources with the ndd command. HP, SCO and others have announced that they have teams working on a fix. Most firewall companies are working on a solution for those sites protected by firewalls; two have announced available products. So what is it you are trying to do here? And why are you trying to do it here of all places?
I would appreciate it if you would not give credit to for ICMP UNREACHABLE to me. ICMP UNREACHABLE errors are in specified in RFC 793. Please 'redirect' this credit elsewhere. It is not my original idea.
OK, OK, OK, it was supposed to be a joke, a funny comment, a witticism.
All I am asking is for the procotcol to work as designed so I can have one more piece of info to use in an algorithm.
This is too much to ask for, IMHO.
Somewhat Patiently (but anxiously awaiting technical answers),
That's like sending an email to president@whitehouse.gov to tell him that you are hungry and then waiting anxiously for the Domino's delivery guy to knock at your door. You would get much better response to your questions if you would send a subscribe message to firewalls-request@greatcircle.com and ask there. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
This is not the right forum to discuss TCP internals nor is it the right forum to discuss building hardened kernels
That may or may not be true, I'll pass on that one. What is the name of the 'right list' for this discussion, BTW? linux-net is quiet and the linux code fragement for linux does not work on high speed networks..... If you have a pointer to a better place to work on this, I would appreciate it. I feel like I'm hacking kernel code in a vaccuum! Some good suggestion would save time, and I have not found a good list to work on internals. All suggestions to good kernel hackers lists working on this is appreciated. Thanks, Tim
On Fri, 4 Oct 1996, Tim Bass wrote:
This is not the right forum to discuss TCP internals nor is it the right forum to discuss building hardened kernels
That may or may not be true, I'll pass on that one.
What is the name of the 'right list' for this discussion, BTW? linux-net is quiet and the linux code fragement for linux does not work on high speed networks.....
I think you should ask the people who normal work on Linux internals. If nothing else, Alan Cox frequents server-linux; send subscribe server-linux Tim Bass to listserv@netspace.org (note the spelling netSPaCe) But server-linux is mostly people who run large Linux servers or large networks of Linux machines, so it's still not a great place to talk about TCP/IP internals. I haven't looked into comp.os.linux.development.system recently but similar things get discussed there. And these days the Debian Linux distribution is the hot one to work on so you may find useful contacts at the mailing lists hosted by http://www.debian.org. In fact the Debian lists may be the reason that linux-net has quieted down. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
This is not the right forum to discuss TCP internals nor is it the right forum to discuss building hardened kernels
That may or may not be true, I'll pass on that one.
What is the name of the 'right list' for this discussion, BTW? linux-net is quiet and the linux code fragement for linux does not work on high speed networks.....
If you have a pointer to a better place to work on this, I would appreciate it. I feel like I'm hacking kernel code in a vaccuum! Some good suggestion would save time, and I have not found a good list to work on internals.
All suggestions to good kernel hackers lists working on this is appreciated.
Thanks,
Tim
It's in-scope for nanog to the extent that published results and host-mod procedures are something we may want to pass on to publishers, but probably some of the TCP/IP newsgroups would be a better place than nanog. Perhaps inet-access? Inet-access at least has so much random garbage flowing by that people are used to responding only to what they are interested in. Nanog usually (at least, in my case it does) goes right into my main mailbox; inet-access is a "when I have time" kind of thing. Avi
Thanks for the pointers. I tried inet-access for about 1 day and never subscribed again. It is too noisy, IMO, for a distinct login :-) linux-net is quiet and the last patch or communique from Alan was a patch for 'slower' links, as Alan says himself. I like the 'no-data structures until the' three way handshake is complete idea that Jeff posted yesterday. Guess I can applied this to linux.... has anyone done this? If so, I would rather start testing a patch to save time. Regards, Tim
Thanks for the pointers.
I tried inet-access for about 1 day and never subscribed again. It is too noisy, IMO, for a distinct login :-)
linux-net is quiet and the last patch or communique from Alan was a patch for 'slower' links, as Alan says himself.
I like the 'no-data structures until the' three way handshake is complete idea that Jeff posted yesterday. Guess I can applied this to linux.... has anyone done this? If so, I would rather start testing a patch to save time.
Regards,
Tim
I'm quite sure I could take the code Jeff did and hack it so that it could be applied to my vacuum cleaner if that was being SYN- stormed... Jeff's a SunOS/BSD bigot as well so I doubt he'll do anything directly re: a linux port :) Avi
I'm quite sure I could take the code Jeff did and hack it so that it could be applied to my vacuum cleaner if that was being SYN- stormed...
Avi, If you are serious about doint the port, I'll be happy to test it. Right now, I'm heading out to drink expresso and read the two smaller files. Tim
I'm quite sure I could take the code Jeff did and hack it so that it could be applied to my vacuum cleaner if that was being SYN- stormed...
Avi,
If you are serious about doint the port, I'll be happy to test it. Right now, I'm heading out to drink expresso and read the two smaller files.
Tim
No. I have no interest in any but the SunOS (or, if I can get IOS sources and build utils, the IOS port). :) Avi
Thanks for all the help earlier. Just to followup, I have had an offline discussion on the UNREACHABLE, ICMP idea and the last ARP hop was a show stopper, (security we could deal with). I have some archives to read and catch up on as well as some more linux kernel hacking/testing to do. If anyone hears of a linux port for Jeff's BSD SYN patch, please email please let me know. Otherwise, I may get to it, but next week I'm out-of-town most of the week and will not have the pleasure of a kernel to hack. Thanks for the great posts and remarkably constructive comments. It was impressive, to me, to watch the transition from last week when, if you recall, someone implied that a kernel fix was 'impossible', to seeing numerous excellent approaches within a few days, in particular Vernon's and Jeff's; however there must be others. In times of a crisis, it is impressive to see how humans put their differences aside and work together. I know that my 'innovative' idea for a predictive firewall algorithm was far fetched compared to the much easier and workable kernel adjustments under test. Also, the ICMP UNREACHABLE fix has merit, but to fix all the things required to 'make it work' (almost everything, it seems) seem orders of magnitude less attrative than the other idea factories at work out there. Best Regards, Tim
Vern Schriver at SGI has been running experiements and the conclusions are pretty compelling. Have the listen queue do Random Drop of waiting connections. If the queue size is equal or greater than the attack rate times the expected roud-trip time, the probability of a real session connecting on the first SYN is very close to one. Note this performs much better than "oldest drop" (aka FIFO). In his tests, a machine sustained a 1200 SYN/second attack with no observable impact in system performance. With a queue size of 383, from a machine 250 msec round-trip thousands of connections completed with only a handful of initial SYN retransmissions (again, with a 1200 SYN/sec attack). Best way to make the bogons leave is to make it not fun anymore. This certainly seems to accomplish the goal. -mo
Now can I hold my breath waiting for vendors to incorporate this stuff into their products? Has anybody heard anything from Sun on this matter? Dima Mike O'Dell writes:
Vern Schriver at SGI has been running experiements and the conclusions are pretty compelling.
Have the listen queue do Random Drop of waiting connections. If the queue size is equal or greater than the attack rate times the expected roud-trip time, the probability of a real session connecting on the first SYN is very close to one.
Note this performs much better than "oldest drop" (aka FIFO).
In his tests, a machine sustained a 1200 SYN/second attack with no observable impact in system performance. With a queue size of 383, from a machine 250 msec round-trip thousands of connections completed with only a handful of initial SYN retransmissions (again, with a 1200 SYN/sec attack).
Best way to make the bogons leave is to make it not fun anymore.
This certainly seems to accomplish the goal.
-mo
Dima Volodin wrote:
Now can I hold my breath waiting for vendors to incorporate this stuff into their products? Has anybody heard anything from Sun on this matter? The latest word going out from their SunService center is that
their engineers are working on it. The cust. support reps at least seemed to know what it was right off (which means lots of people have been calling about it) I've been monkeying about with the ndd settings, but I've had a hard time getting the exploit code to work. Both neptune (phrack) and the 2600 code both send the SYN packets (after some work) but a sniffer shows that both of these don't correctly spoof the IP address, so RSTs follow the reply. Does anyone have _simple_ working exploit code for any platform? I'm going to go ahead and implement the ndd fix, but I'd sure as heck like to know how much it fixes it. allan allan@bellsouth.net
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. Ran rja@cisco.com
On Thu, 3 Oct 1996, 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.
the linux ip folk have released at least one patch (available near http://www.uk.linux.org/NetNews.html) that holds off the problem for a bit. it has a larger infant connection queue and drops some off the end if its under attack. There has also been some talk of doing much more 'sneaky' stuff. i.e. encoding cookies in rsts instead of sending synacks.. zach
On Thu, 3 Oct 1996, 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.
the linux ip folk have released at least one patch (available near http://www.uk.linux.org/NetNews.html) that holds off the problem for a bit. it has a larger infant connection queue and drops some off the end if its under attack. There has also been some talk of doing much more 'sneaky' stuff. i.e. encoding cookies in rsts instead of sending synacks..
Yes. This is the approach I like. Store the mss info either in toto or in a table of "mss values I have seen" as some # of bits of the iss and the rest is a one-way hard-to-guess hash of some sort of the rest of the data (a rotating secret #, src/dest ips and ports etc...);
zach
Avi
Vern Schriver at SGI has been running experiements and the conclusions are pretty compelling.
Yes, I have been looking for 'another approach' other than random drop, just as an alternative. But, since ICMP/IP seems to be broken, using ICMP UNREACHABLE error messages does not work. I agree that random drop is 'best current idea' (BCI :-) However, I think it is prudent to look at other possible approaches as well. This is what I have been doing in the lab; looking to see if any other practical alternatives exist at the kernel implementation of TCP/IP. My efforts in the lab do not imply that random drop is not a good idea. On the contrary, the more I look for an alternative solution, the better random drop appears. However, it is interesting to see if another kernel mod would work as well......... I do worry about the limitation of the queue drop algorithm based on queue size and delay. FYI: I implemented 'someones' version of random drop on my servers (using their patch) and the servers all crashed (when the attack was fast and hard on the same subnet). There is a lot of work to be done. Thanks, Tim
Vern tested several other approaches. Random Drop wins. As for your servers, I won't suggest any particular implementation is good or bad, only that there is at least one that seems to work. I suspect that if the network interface is fast enough compared to the processor speed, the machine will wedge when subjected to a fire-hose of even good requests. -mo
Vern tested several other approaches. Random Drop wins.
Understood. But....
I suspect that if the network interface is fast enough compared to the processor speed, the machine will wedge when subjected to a fire-hose of even good requests.
Not really. I can attack the servers with 'a fire hose' and the DoS attack 'works' but the server runs. I think it is just a problem with the way I installed the patchs. I'm working it now. Thanks again, Tim
-mo
-- We're just two lost souls swimming in a fish bowl, year after year, Running over the same old ground. What have we found? The same old fears. Wish you were here. -Roger Waters
participants (15)
-
Allan Chong -
Avi Freedman -
Carl Payne -
Dan Ellis -
dvv＠sprint.net -
Kent W. England -
Matt Zimmerman -
Michael Dillon -
Mike O'Dell -
Perry E. Metzger -
Ran Atkinson -
Tim Bass -
Tim Bass -
Tim Bass -
Zach