- NANOG - lists.nanog.org

Re: SYN floods - possible solution? (fwd)
by Michael Dillon 13 Sep '96

13 Sep '96

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(a)memra.com ---------- Forwarded message ---------- Date: Fri, 13 Sep 1996 01:36:54 -0400 (EDT) From: "Roderick Murchison, Jr." <murchiso(a)vivid.newbridge.com> To: firewall-1(a)applicom.co.il Cc: firewalls(a)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(a)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

7 7

Re: SYN floods (was: does history repeat itself?)
by Justin W. Newton 13 Sep '96

13 Sep '96

At 09:08 PM 9/9/96 -0400, Avi Freedman wrote: >This is *exactly* the right thing to do; every provider which does >not provide complicated transit (which excludes even certain regionals, >alas) should do this at their borders if they don't do it at each customer >connect. > >And everyone should at least filter on each customer 56k/t1/etc... >I know router cycles are tight but it might *really* become >imperative... Am I missing something.... If I am announcing a network via BGP I am more or less agreeing to carry traffic for it. If I am not I am not. Therefore, if I filter based on my outbound BGP announcements and do not allow any packets which have a source address not originating from a network in my BGP announcements then I should not be causing any harm to the networks which I am providing connectivity to. This has the added benefit of stopping people from defaulting into me at exchange points as I will not carry that traffic across my backbone. I'd love to hear the holes in this theory. Justin Newton Internet Architect Erol's Internet Services

3 2

customers and web servers and level one naps
by Gordon Cook 13 Sep '96

13 Sep '96

What are the positions of Ameritech, sprint, pac bell and MFS on two issues? First having someone at a NAP who is there as a customer of one of the National service providers... and who may or may not engage in cost free peering with any of the other NSPs or even with other isps? Second: allowing such a customer, or an NSP, to attach web services directly to the FDDI ring at the NAP. PAIX is doing this. As far as I know the other major interchange provider are not. I am wondering why. ************************************************************************ The COOK Report on Internet For subsc. pricing & more than 431 Greenway Ave, Ewing, NJ 08618 USA ten megabytes of free material (609) 882-2572 (phone & fax) visit http://pobox.com/cook/ Internet: cook(a)cookreport.com For case study of MercerNet & TIIAP induced harm to local community http://pobox.com/cook/mercernet.html ************************************************************************

12 19

Re[2]: SYN floods (was: does history repeat itself?)
by pcalhoun＠usr.com 13 Sep '96

13 Sep '96

Perry, This is actually quite simple to implement on Dial Access Routers, and obviously this is the best place to add the filtering. Pat R. Calhoun e-mail: pcalhoun(a)usr.com Project Engineer - Lan Access R&D phone: (847) 933-5181 US Robotics Access Corp. ______________________________ Reply Separator _________________________________ Subject: Re: SYN floods (was: does history repeat itself?) Author: "Perry E. Metzger" <perry(a)piermont.com> at Internet Date: 9/9/96 1:19 PM Re: SYN floods PANIX, a large public access provider in New York, was badly hit with SYN flood attacks from random source addresses over the last few days. It nearly wrecked them. I think its time for the larger providers to start filtering packets coming from customers so that they only accept packets with the customer's network number on it. Yes, its a load on routers. Yes, its nasty for the mobile IP weenies. Unfortunately, the only known way to stop this. Many TCPs go belly up as soon as they get SYN flooded -- its a defect in the protocol design, and other than Karn style anti-clogging tokens ("cookies") being put into a TCP++ and mass implemented worldwide soon, the only reasonable way to stop this sort of terrorism is provider filtering. Perry

9 10

Re[4]: SYN floods (was: does history repeat itself?)
by pcalhoun＠usr.com 13 Sep '96

13 Sep '96

Alexis, However if you are filtering on your outbound router to the net, there is still the possbility that a malicious user could spoof addresses as long as they belong to your address space. By moving the filter out to the edge (when you have the equipment) this eliminates that problem as well. Pat R. Calhoun e-mail: pcalhoun(a)usr.com Project Engineer - Lan Access R&D phone: (847) 933-5181 US Robotics Access Corp. ______________________________ Reply Separator _________________________________ Subject: Re: Re[2]: SYN floods (was: does history repeat itself?) Author: Alexis Rosen <alexis(a)panix.com> at Internet Date: 9/10/96 2:07 PM Alec H. Peterson writes: > > Pat Calhoun writes: > > This is actually quite simple to implement on Dial Access Routers, > > and obviously this is the best place to add the filtering. > > Sure, that's a place to start. Except for a few problems: > > 1) The people doing this are not necessarily using a dialup IP > connection. True. That's why you need to filter upstream of public-access unix boxes (like our own). > 2) Many of us don't have dial access routers that can handle this. Also true. As I said before, I don't know about the Ascends, but I do know that the Xylogics boxes we use have the capability but probably not the capacity. When all ports are connected at 28.8, CPU usage can hover in the high 80% range. Adding filters would probably be a bad idea. That's why I was talking about filtering at a router just upstream from the dial-access box. FWIW, even with a thousand very busy modems, I'm pretty sure that even a small cisco is up to the job. They just don't generate all that much traffic. /a

5 5

Re: SYN floods (was: does history repeat itself?)
by salo＠msc.edu 12 Sep '96

12 Sep '96

> Cc: nanog(a)merit.edu > Subject: Re: SYN floods (was: does history repeat itself?) > Date: Thu, 12 Sep 1996 14:41:09 -0400 > From: "Perry E. Metzger" <perry(a)piermont.com> > [...] > BTW, I would suggest that for a variety of applications, hardware > assisted filtering boxes that simply take in IP one end and put out > processed IP on the other end would be of use -- not just for this, > but also for helping in doing packet traces through high traffic > areas, for implementing firewalls, and for all sorts of other > things. Vendors, are you listening? > [...] Network Systems has a box which does this for IP over ATM packets. I believe that it runs at full OC-3c (155 Mbps) speed. It also potentially does a bunch of other stuff to the IP packets. It might make an interesting NANOG presentation, if it hasn't been done already. -tjs

1 0

Re: Re[2]: SYN floods (was: does history repeat itself?)
by Justin W. Newton 12 Sep '96

12 Sep '96

At 01:44 PM 9/12/96 -0400, Curtis Villamizar wrote: >I agree with you completely -- sort of. Only problem is there are >thought to be some 3,000 dial access providers. Many of them barely >know what a TCP SYN is, let alone why they need to block ones with >random source addresses and how. Unless of course you are >volunteering to explain it and help them. Thanks in advance. :-) We are currently blocking any outgoing packets which have a source address which is not advertised by us. I have also crossposted Avi's and Craig's access filter list for Border routers to the inet-access mailing list which has approx 2,000 subscribers, mostly small ISP's. Maybe it'll help. Maybe not. Justin Newton Internet Architect Erol's Internet Services

2 1

Re: InterNIC mail problems?
by William S. Duncanson 12 Sep '96

12 Sep '96

At 02:22 9/12/96 -0400, Deepak Jain wrote: > >Speaking of screwed whois, have you noticed an increasing number of >connection refused errors when trying to look at whois information? No >more of those "Too busy" messages, just a refusal. Even their CGI/WWW >based whois tool comes back blank half the time. > >-Deepak. I have noticed the same problem over the past week or so. A second query usually goes through... -- William S. Duncanson NeoSoft Operations william(a)neosoft.com (888) NEOSOFT or (713) 968-5800

1 0

SYN floods continue
by Alexis Rosen 12 Sep '96

12 Sep '96

We got hit again tonight. This time on seven different machines- three mail hosts, two news machines, our web site, and VTW's web site (we provide all service for VTW). I am simply amazed that anyone would attack VTW. Even the shmuck who's attacking us benefits from VTW's work. Why would anyone attack them? Anyway. Point is this: We can't take too much more of this, nor can our customers. I have yet to hear *anyone* come up with any ideas even remotely reasonable for how to deal with this situation, long term, except for the filtering that Avi, Perry, and I have been promoting these last few days. Whether or not existing equipment can handle the job is *IRRELEVANT*. If it won't, new equipment must be bought. The net won't survive without it. (And yes, I've been hearing "death of the net" predictions for longer than most readers of this list have been on the net. This could really be it.) /a

9 10

Returned mail: Too many hops 19 (17 max): from <edd@aic.net> via localhost, to <postmaster@internic.net> (fwd)
by Edgar Der-Danieliantz 12 Sep '96

12 Sep '96

[I don't know is this appropriate place to post but anyway... Pardon if not] Seems there are problems... All mail to *(a)internic.net bounces... Someone in the US, call Internic please :) -edd Forwarded message: > From postmaster Thu Sep 12 12:34 AMT 1996 > Date: Thu, 12 Sep 1996 03:55:34 -0400 (EDT) > From: Mail Delivery Subsystem <MAILER-DAEMON(a)rs1.internic.net> > Subject: Returned mail: Too many hops 19 (17 max): from <edd(a)aic.net> via localhost, to <postmaster(a)internic.net> > Message-Id: <199609120755.DAB28714(a)rs4.internic.net> > To: <edd(a)aic.net> > To: postmaster(a)rs4.internic.net > MIME-Version: 1.0 > Auto-Submitted: auto-generated (failure) > Content-Type: multipart/report; report-type=delivery-status; > boundary="DAB28714.842514934/rs4.internic.net" > Content-Length: 7804 > > This is a MIME-encapsulated message > > --DAB28714.842514934/rs4.internic.net > > The original message was received at Thu, 12 Sep 1996 03:55:33 -0400 (EDT) > from uucp@localhost > > ----- The following addresses have delivery notifications ----- > <postmaster(a)internic.net> (unrecoverable error) > > ----- Transcript of session follows ----- > 554 Too many hops 19 (17 max): from <edd(a)aic.net> via localhost, to <postmaster(a)internic.net> > > --DAB28714.842514934/rs4.internic.net > Content-Type: message/delivery-status > > Reporting-MTA: dns; rs4.internic.net > Arrival-Date: Thu, 12 Sep 1996 03:55:33 -0400 (EDT) > > Final-Recipient: rfc822; postmaster(a)internic.net > Action: failed > Status: 5.4.6 > Last-Attempt-Date: Thu, 12 Sep 1996 03:55:34 -0400 (EDT) > > --DAB28714.842514934/rs4.internic.net > Content-Type: message/rfc822 > > Return-Path: edd(a)aic.net > Received: (uucp@localhost) by rs4.internic.net (8.7.5/SLAM-1) id DAA28714 for <postmaster(a)internic.net>; Thu, 12 Sep 1996 03:55:33 -0400 (EDT) > Received: from rs4.internic.net(198.41.0.9) by rs4.internic.net via smap (V1.3) > id sma027947; Thu Sep 12 03:54:04 1996 > Received: (uucp@localhost) by rs4.internic.net (8.7.5/SLAM-1) id DAA27925 for <postmaster(a)internic.net>; Thu, 12 Sep 1996 03:54:02 -0400 (EDT) > Received: from rs0.internic.net(198.41.0.5) by rs4.internic.net via smap (V1.3) > id sma027324; Thu Sep 12 03:53:07 1996 > Received: (uucp@localhost) by rs0.internic.net (8.7.5/SLAM-1) id DAA28712 for <postmaster(a)internic.net>; Thu, 12 Sep 1996 03:53:06 -0400 (EDT) > Received: from rs3.internic.net(198.41.0.8) by rs0.internic.net via smap (V1.3) > id sma028191; Thu Sep 12 03:52:16 1996 > Received: (uucp@localhost) by rs3.internic.net (8.7.5/SLAM-1) id DAA12522 for <postmaster(a)internic.net>; Thu, 12 Sep 1996 03:52:14 -0400 (EDT) > Received: from rs1.internic.net(198.41.0.6) by rs3.internic.net via smap (V1.3) > id sma011957; Thu Sep 12 03:51:25 1996 > Received: (uucp@localhost) by rs1.internic.net (8.7.5/SLAM-1) id DAA21154 for <postmaster(a)internic.net>; Thu, 12 Sep 1996 03:51:24 -0400 (EDT) > Received: from rs4.internic.net(198.41.0.9) by rs1.internic.net via smap (V1.3) > id sma020838; Thu Sep 12 03:50:56 1996 > Received: (uucp@localhost) by rs4.internic.net (8.7.5/SLAM-1) id DAA26399 for <postmaster(a)internic.net>; Thu, 12 Sep 1996 03:50:55 -0400 (EDT) > Received: from rs0.internic.net(198.41.0.5) by rs4.internic.net via smap (V1.3) > id sma025676; Thu Sep 12 03:49:03 1996 > Received: (uucp@localhost) by rs0.internic.net (8.7.5/SLAM-1) id DAA26287 for <postmaster(a)internic.net>; Thu, 12 Sep 1996 03:49:03 -0400 (EDT) > Received: from rs4.internic.net(198.41.0.9) by rs0.internic.net via smap (V1.3) > id sma025697; Thu Sep 12 03:47:54 1996 > Received: (uucp@localhost) by rs4.internic.net (8.7.5/SLAM-1) id DAA25027 for <postmaster(a)internic.net>; Thu, 12 Sep 1996 03:47:52 -0400 (EDT) > Received: from rs1.internic.net(198.41.0.6) by rs4.internic.net via smap (V1.3) > id sma023948; Thu Sep 12 03:45:13 1996 > Received: (uucp@localhost) by rs1.internic.net (8.7.5/SLAM-1) id DAA18325 for <postmaster(a)internic.net>; Thu, 12 Sep 1996 03:45:12 -0400 (EDT) > Received: from ns.aic.net(194.67.30.65) by rs1.internic.net via smap (V1.3) > id sma017227; Thu Sep 12 03:43:11 1996 > Received: by aic.net (8.7.3/8.7.3) id LAA04871; Thu, 12 Sep 1996 11:42:21 +0400 (AMT) > From: Edgar Der-Danieliantz <edd(a)aic.net> > Message-Id: <199609120742.LAA04871(a)aic.net> > Subject: Returned mail: Too many hops 19 (17 max): from <edd(a)aic.net> via localhost, to <markk(a)internic.net> (fwd) > To: postmaster(a)internic.net, postmaster(a)netsol.com > Date: Thu, 12 Sep 1996 11:42:21 +0400 (AMT) > Content-Type: text > > Forwarded message: > > From postmaster Thu Sep 12 11:39 AMT 1996 > > Date: Thu, 12 Sep 1996 03:38:37 -0400 (EDT) > > From: Mail Delivery Subsystem <MAILER-DAEMON(a)rs1.internic.net> > > Subject: Returned mail: Too many hops 19 (17 max): from <edd(a)aic.net> via localhost, to <markk(a)internic.net> > > Message-Id: <199609120738.DAB27687(a)rs2.internic.net> > > To: <edd(a)aic.net> > > To: postmaster(a)rs2.internic.net > > MIME-Version: 1.0 > > Auto-Submitted: auto-generated (failure) > > Content-Type: multipart/report; report-type=delivery-status; > > boundary="DAB27687.842513917/rs2.internic.net" > > Content-Length: 9709 > > > > This is a MIME-encapsulated message > > > > --DAB27687.842513917/rs2.internic.net > > > > The original message was received at Thu, 12 Sep 1996 03:38:37 -0400 (EDT) > > from uucp@localhost > > > > ----- The following addresses have delivery notifications ----- > > <markk(a)internic.net> (unrecoverable error) > > > > ----- Transcript of session follows ----- > > 554 Too many hops 19 (17 max): from <edd(a)aic.net> via localhost, to <markk(a)internic.net> > > > > --DAB27687.842513917/rs2.internic.net > > Content-Type: message/delivery-status > > > > Reporting-MTA: dns; rs2.internic.net > > Arrival-Date: Thu, 12 Sep 1996 03:38:37 -0400 (EDT) > > > > Final-Recipient: rfc822; markk(a)internic.net > > Action: failed > > Status: 5.4.6 > > Last-Attempt-Date: Thu, 12 Sep 1996 03:38:38 -0400 (EDT) > > > > --DAB27687.842513917/rs2.internic.net > > Content-Type: message/rfc822 > > > > Return-Path: edd(a)aic.net > > Received: (uucp@localhost) by rs2.internic.net (8.7.5/SLAM-1) id DAA27687 for <markk(a)internic.net>; Thu, 12 Sep 1996 03:38:37 -0400 (EDT) > > Received: from rs0.internic.net(198.41.0.5) by rs2.internic.net via smap (V1.3) > > id sma027231; Thu Sep 12 03:37:34 1996 > > Received: (uucp@localhost) by rs0.internic.net (8.7.5/SLAM-1) id DAA19874 for <markk(a)internic.net>; Thu, 12 Sep 1996 03:37:33 -0400 (EDT) > > Received: from rs1.internic.net(198.41.0.6) by rs0.internic.net via smap (V1.3) > > id sma019456; Thu Sep 12 03:36:44 1996 > > Received: (uucp@localhost) by rs1.internic.net (8.7.5/SLAM-1) id DAA14304 for <markk(a)internic.net>; Thu, 12 Sep 1996 03:36:42 -0400 (EDT) > > Received: from rs0.internic.net(198.41.0.5) by rs1.internic.net via smap (V1.3) > > id sma013584; Thu Sep 12 03:35:02 1996 > > Received: (uucp@localhost) by rs0.internic.net (8.7.5/SLAM-1) id DAA18370 for <markk(a)internic.net>; Thu, 12 Sep 1996 03:35:01 -0400 (EDT) > > Received: from rs1.internic.net(198.41.0.6) by rs0.internic.net via smap (V1.3) > > id sma017846; Thu Sep 12 03:34:03 1996 > > Received: (uucp@localhost) by rs1.internic.net (8.7.5/SLAM-1) id DAA13178 for <markk(a)internic.net>; Thu, 12 Sep 1996 03:34:01 -0400 (EDT) > > Received: from rs3.internic.net(198.41.0.8) by rs1.internic.net via smap (V1.3) > > id sma012858; Thu Sep 12 03:33:25 1996 > > Received: (uucp@localhost) by rs3.internic.net (8.7.5/SLAM-1) id DAA03985 for <markk(a)internic.net>; Thu, 12 Sep 1996 03:33:22 -0400 (EDT) > > Received: from rs0.internic.net(198.41.0.5) by rs3.internic.net via smap (V1.3) > > id sma003555; Thu Sep 12 03:32:35 1996 > > Received: (uucp@localhost) by rs0.internic.net (8.7.5/SLAM-1) id DAA17001 for <markk(a)internic.net>; Thu, 12 Sep 1996 03:32:35 -0400 (EDT) > > Received: from rs4.internic.net(198.41.0.9) by rs0.internic.net via smap (V1.3) > > id sma016602; Thu Sep 12 03:32:04 1996 > > Received: (uucp@localhost) by rs4.internic.net (8.7.5/SLAM-1) id DAA18124 for <markk(a)internic.net>; Thu, 12 Sep 1996 03:32:02 -0400 (EDT) > > Received: from rs3.internic.net(198.41.0.8) by rs4.internic.net via smap (V1.3) > > id sma017804; Thu Sep 12 03:31:34 1996 > > Received: (uucp@localhost) by rs3.internic.net (8.7.5/SLAM-1) id DAA03059 for <markk(a)internic.net>; Thu, 12 Sep 1996 03:31:32 -0400 (EDT) > > Received: from ns.aic.net(194.67.30.65) by rs3.internic.net via smap (V1.3) > > id sma001467; Thu Sep 12 03:28:34 1996 > > Received: by aic.net (8.7.3/8.7.3) id LAA04740 for markk(a)internic.net; Thu, 12 Sep 1996 11:28:08 +0400 (AMT) > > From: Edgar Der-Danieliantz <edd(a)aic.net> > > Message-Id: <199609120728.LAA04740(a)aic.net> > > Subject: Re: [NIC-960814.1251] AM (fwd) > > To: markk(a)internic.net > > Date: Thu, 12 Sep 1996 11:28:08 +0400 (AMT) > > Content-Type: text > > > > --DAB28714.842514934/rs4.internic.net-- > >

1 0