- Test - lists.nanog.org

Re: TCP SYN attacks - a simple solution
by Jeff Weisberg 07 Oct '96

07 Oct '96

| There have been several (many?) products attempting to solve the TCP | SYN attack through timeouts. They watch the SYN packets, and flush | ones, by doing a RESET on the connection if the third packet isn't | received in time. Or letting conenctions fail by flushing the infant | connection table when full. I believe this is wrong! [...] | I propose a solution where the initial sequence number is calculated | (not random), and is based on a cryptographic calculation of the | senders Initial Sequence Number, the ports, and a "per boot" | secret number. In this way the initial packet can be discarded, | and on receipt of the third SYN packet can be recalculated. cool idea! look at: ftp.op.net:/pub/src/syn-prophylactica/ for an implementation. --jeff

1 0

Re: My First Denial of Service Attack..... (fwd)
by Eric Ziegast 07 Oct '96

07 Oct '96

> > The foreman commented, "We'd be sued for $100,000 for every 10 minutes > > the line was cut." Correction: $100,000 per minute. I was quite sure of the $6,000,000 per hour figure. -- Eric Ziegast

1 0

SYN flooding -- drop policies
by Vadim Antonov 07 Oct '96

07 Oct '96

Mike O'Dell suggested using drop oldest in some situations. Unfortunately it is about as good as RED if source of good SYNs is deterministic and is *much* worse then RED if it is bursty. Assuming that source of bad SYNs is deterministic as well as server, and good SYNs come as Poisson process chances of good SYN survival with RED are about 1-e^-1 times better than with Drop Oldest. With self-similar SYN inter-arrival pattern (there are some indications that it's like that) the advantage of RED is even bigger. I didn't do any serious research on that, so the result is of "back of envelope" kind, but it does make some intuitive sense. It should also be observed that tail-drop at customer access gateway would reduce usefulness of RED (or Drop Oldest), particularly when flood rate comes closer to link capacity. The question of what max. queue length is the best remains pretty much open; as well as how it interacts with back-off SYN retransmissions. --vadim

2 1

Re: Agenda item for Nanog?
by Guy T Almes 07 Oct '96

07 Oct '96

I would love to hear at least 20 minutes worth. -- Guy At 07:41 AM 10/4/96 DST, Peter Lothberg wrote: > >I could say some worlds about this if anyone is interested and there >are 20 minutes avaliable on the Nanog agenda. > > >-Peter > > > >"" > >Worlds first transatlantic 155Mbit native IP service > >On Monday 23 September 1996 00:15 UTC, > >Was the worlds first transatlantic 155Mbit native IP service brought >into operation by Sprint/USA and Tele2/Sweden. > >The circuit which is part of SprintLink and ICMnet runs between the >NY-NAP in Pennsauken, NJ, USA and Tele2 in Sweden and uses Cisco >packet-over-sonet/sdh technology. (Native IP over SDH) > >In 1995 the same team from Sprint and Tele2 brought up the worlds first >transatlantic E3 service between the same endpoints. > >For more information; > >Sprint: Tricia Schibler, +1 703 904 2042, <tricia.schibler(a)qm.sprintcorp.com> >Tele2: Olle Wallner, +46 8 5626 4058, <wallner(a)swip.net> > >"" >

1 0

Re: TCP SYN attacks - a simple solution
by Mike O'Dell 07 Oct '96

07 Oct '96

best solution known so far is Random Drop of waiting connections once queue fills to a limit at least as large as design RTT*Attack-Rate (queues in the 350-400 range appear to be quite sufficient for RTTs in the 250msec range with 1000-packets/second attacks). Some also argue that somewhat more aggressive aging with Oldest Drop (aka FIFO) also helps while the queue fills to the point of instigating Random Drop. One can mutter about where transition between Oldest and Random should occur. I'm willing to believe hybrid strategy could be better at possible cost of more complexity. (although more agressive Oldest Drop is probably just a timer tweek.) Note that with Random Drop and 350-400 max queue size legit connections almost always complete on the first SYN with no retransmission. cheers, -mo

3 2

TCP SYN attacks - a simple solution
by rex＠staff.cs.su.oz.au 07 Oct '96

07 Oct '96

There have been several (many?) products attempting to solve the TCP SYN attack through timeouts. They watch the SYN packets, and flush ones, by doing a RESET on the connection if the third packet isn't received in time. Or letting conenctions fail by flushing the infant connection table when full. I believe this is wrong! There is, I believe, a much simpler solution. The problem is, as I see it, that the current implementations are keeping the first packet (in some form) around, as state. Instead, we want to discard all this state information, to allow us to accept more packets. Only when we have a full connection do we want to keep state information. The only piece of information we require at this early stage is the initial sequence number for our side. I propose a solution where the initial sequence number is calculated (not random), and is based on a cryptographic calculation of the senders Initial Sequence Number, the ports, and a "per boot" secret number. In this way the initial packet can be discarded, and on receipt of the third SYN packet can be recalculated. This means that initial packets, fired from random addreses will never have the third packet, and no overheads are consumed, except for the hash calculation. Since there is only one random number in the connection, the initial sequence number from the originating site, there is a higher probability of "rogue", or lost packets, but if the initial ISN was truely random this shouldn't be to much of a problem (hmmm - am I sure?). Pictorally: Host A to conenct to Host B host A (good) Host B (good) gen ISN send packet to B ---> receives packet, and ISN. uses F(ISN(A) + ports + secret) as calculated ISN for return and sends to A, discards all receives packet <---- state. as normal, and sends third packet ---> receives packet, recalculates ISN from 1st step. If it matches the ACK in the packet then this is a valid connection. The nice thing about this is that no changes have to occur on the sending side. This solution will work with current IP stacks, but will automatically reject bogus connections, and has no silly timeout on valid connections. This scheme does have implications with firewalls that base all decisions on the first packet, such as packet filtering firewalls, but then again, I don't consider them real firewalls. :-) I'm going to implement this, using boring old md5, and give it a try, but I was wondering if there are any thoughts about this as a solution? Any obvious holes I missed. Rex di Bona.

2 1

Re: TCP SYN attacks - a simple solution
by matthew＠scruz.net 07 Oct '96

07 Oct '96

Original message <199610062314.TAA29781(a)merit.edu> From: rex(a)staff.cs.su.oz.au (Rex di Bona) Date: Oct 7, 8:10 Subject: TCP SYN attacks - a simple solution > ... > I propose a solution where the initial sequence number is calculated > (not random), and is based on a cryptographic calculation of the > senders Initial Sequence Number, the ports, and a "per boot" > secret number. In this way the initial packet can be discarded, > and on receipt of the third SYN packet can be recalculated. ... The idea has been floated before, and I believe it to be the right solution to this problem. However, I have some suggested improvements: 1. The use of a "per boot" secret number allows an attacker to poll your machine to deduce the secret, and then attack you with that knowledge. A solution to this problem is to use a rapidly changing secret, the pattern of which cannot be easily deduced, and a sliding window of acceptance. (If the hash doesn't match the current scheme, but matches the scheme we were using in the past N seconds, then accept the packet) The change interval needs to be short enough that, by the time an attacker has been able to compute the next number, the window for accepting that has closed. 2. The TCP specification allows data to ride along with the initial SYN, and requires that after the three-way handshake, that the data be presented to the application layer. One solution is to realize that very few implementations take advantage of this, and simply not accept this form of SYN. A second solution is to NOT ack the data that is riding along, but the TCP state machine definition has some holes here which may not work for all implementations. The solution of buffering those SYN's which contain data is unacceptable, because attackers will simply switch to sending SYNs with data. I believe that switching to this sort of scheme would also thwart most attacks which rely on sequence number prediction, and save memory significantly over schemes which simply increase the number of TCBs allowed. -matthew kaufman matthew(a)scruz.net ps. I've been meaning to write this entire scheme, with the enhancements I propose here, as a draft specification, but I keep getting interrupted by flooded phone rooms and the like this weekend. *sigh*

2 1

RE: My First Denial of Service Attack..... (fwd)
by Michael Dillon 07 Oct '96

07 Oct '96

---------- Forwarded message ---------- Date: Sun, 6 Oct 1996 11:40:25 -0400 From: Dave Van Allen <dave(a)fast.net> Reply-To: inet-access(a)earth.com To: "'inet-access(a)earth.com'" <inet-access(a)earth.com> Subject: RE: My First Denial of Service Attack..... Resent-Date: Sun, 6 Oct 1996 09:38:04 -0600 (MDT) Resent-From: inet-access(a)earth.com FYI, (if it has already been mentioned, please excuse the double post, but:) The latest version of the SYN attack code published in Phrack (last weeks edition, NOT last months) has an imbedded 'ping' ever several hundred SYN packets. If you get attacked, run snoop, tcpdump or anything that captures packets, and look for the pings - they have the real source address of the sender of the SYN flood attack. Please note, obviously the code can be modified to NOT ping, but our attacker last night did not do that, and we had the name of the user, their ISP, and other info in less than 15 minutes. Best regards, - Dave Van Allen - You Tools Corporation/FASTNET(tm) dave(a)fast.net (610)954-5910 http://www.fast.net FASTNET - PA/NJ/DE Business Internet Solutions >---------- >From: Avi Freedman[SMTP:freedman@netaxs.com] >Sent: Saturday, October 05, 1996 7:37 PM >To: inet-access(a)earth.com >Subject: Re: My First Denial of Service Attack..... > >> I have a question about this - >> >> Could place an incoming ping filter denying all on your router, AND turn >> off small servers on the router? Would this work? Is there a downside to >> this? >> >> -Elroy ( elroy(a)mail.kcstar.com ) > >Not to state the obvious, but if you turn off pings into your network >then noone can ping into your network (for diagnostics etc...) > >Turning off small-servers on the router only affects things to the >router (and not ICMP pings, just presumably udp pings). > >Avi > > >============================== ISP Mailing List >============================== >Email ``unsubscribe'' to inet-access-request(a)earth.com to be removed. >Email ``subscribe'' to inet-access-request(a)earth.com to join the list. > ============================== ISP Mailing List ============================== Email ``unsubscribe'' to inet-access-request(a)earth.com to be removed. Excellent day for putting Slinkies on an escalator.

2 1

Re: New Denial of Service Attack on Panix
by Kent W. England 05 Oct '96

05 Oct '96

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

15 47

RE: TCP SYN attacks
by Ted Linnenkamp 04 Oct '96

04 Oct '96

>---------- >From: Tim Bass[SMTP:bass@linux.silkroad.com] >Sent: Friday, October 04, 1996 7:58 AM >To: freedman(a)netaxs.com >Cc: nanog(a)merit.edu; iepg(a)iepg.org >Subject: Re: TCP SYN attacks > >> >> 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, Did you mean to state that these boxes can't be fixed (hardened against SYN attacks) by you? Ted L. My statements are my own and not of the Microsoft Corp. >

2 1