- Test - lists.nanog.org

SYN attack makes NandO Times as well...
by Michael A. Patton 13 Sep '96

13 Sep '96

The NandO Times also has an article, from The Associated Press, on this. <URL:http://www.nando.net/newsroom/ntn/nation/091396/nation8_825.html>

4 3

Apologies for that spam of my message...
by Dalvenjah FoxFire 13 Sep '96

13 Sep '96

I'd like to express my apologies for that mail getting sent to the list 4+ times (what I've been told). For some reason, sendmail on my end never registered it as having gotten to the list, despite having run the queue a whole bunch of times since it was written. I wonder if it had to do with the sprint problems or no, but oh well. Again, I apologize for this mistake. -dalvenjah Dalvenjah FoxFire, the Teddy Dragon (also known as Sven Nielsen to some :) dalvenjah(a)dal.net --- dalvenjah on IRC Remember: if you're not on DALnet, you're on the wrong IRC server!! (/serv irc.dal.net 7000 or telnet telnet.dal.net to try it out) -- ____ _ _ _ "I had the dagger in my hand, and he has | _ \ __ _| |_ _____ _ _ (_)__ _| |_the indecency to start dying on his own!" | |_) / _` | \ V / -_) ' \ | / _` | ' \ --Ambassador G'kar, Babylon 5 |____/\__,_|_|\_/\___|_||_|/ \__,_|_||_| FoxFire -- dalvenjah(a)dal.net -- (SN90) |__/

1 0

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

13 Sep '96

Curtis, As I stated in my previous e-mail, we could do this by adding this to our release notes in our product, describing the problem and advising against not taking measures. However, this would only apply to our customers, which I would venture to say that most already do understand the problem :). However, if there is anything that I can do to help, please let me know since I take the threat of the "imminent death of the internet" very seriously. 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: Curtis Villamizar <curtis(a)ans.net> at Internet Date: 9/12/96 1:44 PM In message <233128C0.3000(a)usr.com>, Pat Calhoun writes: > This is a Mime message, which your current mail reader > may not understand. Parts of the message will appear as > text. To process the remainder, you will need to use a Mime > compatible mail reader. Contact your vendor for details. > > --IMA.Boundary.388702248 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Content-Description: cc:Mail note part > > 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. 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. :-) Curtis > ______________________________ 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 > --IMA.Boundary.388702248 > Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" > Content-Transfer-Encoding: 7bit > Content-Description: cc:Mail note part > Content-Disposition: attachment; filename="RFC822 message headers" > > Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP > (IMA Internet Exchange 2.02 Enterprise) id 233028F0; Sun, 8 Sep 96 12:29:51 > -0500 > Received: from merit.edu by usr.com (8.7.5/3.1.090690-US Robotics) > id MAA17658; Mon, 9 Sep 1996 12:33:14 -0500 (CDT) > Received: from localhost (daemon@localhost) by merit.edu (8.7.5/merit-2.0) wi > th > SMTP id NAA17064; Mon, 9 Sep 1996 13:20:33 -0400 (EDT) > Received: by merit.edu (bulk_mailer v1.5); Mon, 9 Sep 1996 13:19:08 -0400 > Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id NAA16987 > for > nanog-outgoing; Mon, 9 Sep 1996 13:19:08 -0400 (EDT) > Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by > merit.edu (8.7.5/merit-2.0) with ESMTP id NAA16982 for <nanog(a)merit.edu>; Mon > , 9 > Sep 1996 13:19:05 -0400 (EDT) > Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6. > 12) > with SMTP id NAA24855 for <nanog(a)merit.edu>; Mon, 9 Sep 1996 13:19:02 -0400 > (EDT) > Message-Id: <199609091719.NAA24855(a)jekyll.piermont.com> > X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't us > e > HELO protocol > To: nanog(a)merit.edu > Subject: Re: SYN floods (was: does history repeat itself?) > In-reply-to: Your message of "Mon, 09 Sep 1996 12:47:13 EDT." > <199609091647.MAA01458(a)tomservo.mindspring.com> > Reply-To: perry(a)piermont.com > X-Reposting-Policy: redistribute only with permission > Date: Mon, 09 Sep 1996 13:19:02 -0400 > From: "Perry E. Metzger" <perry(a)piermont.com> > Sender: owner-nanog(a)merit.edu > --IMA.Boundary.388702248--

1 0

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

13 Sep '96

John, This sort of feature could be easily added into a NAS, but I question your implementation details. If this filter was turned on by default, then this could "break" other types of services which may require source ip addresses other than the one which was negotiated to the user. This would mean that a customer could perform a flash upgrade and find that their service no longer operates (a technical support nightmare). Would you be willing to consider such a feature where it would have to be enabled (and is disabled by default) and a very well explained document with the release notes to service providers advising them of the risk of not enabling this switch?? 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: "John G. Scudder" <jgs(a)ieng.com> at Internet Date: 9/12/96 2:33 PM At 1:44 PM -0400 9/12/96, 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. :-) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Curtis, this is a great point. USR and other NAS vendors are actually in a great position to do exactly this, by changing their boxes to block random addresses *by default* on dial-up ports. This is of course exactly the point Vadim and others keep making, and of course as they point out there ought to be a knob to disable it if desired. Insofar as guys who "barely know what a TCP SYN is" are unlikely to twist the knobs, defaulting filtering to "block spoofed addresses" seems like the best and maybe only way to get them to do it. How about it, USR &al? --John -- John Scudder email: jgs(a)ieng.com Internet Engineering Group, LLC phone: (313) 669-8800 122 S. Main, Suite 280 fax: (313) 669-8661 Ann Arbor, MI 41804 www: http://www.ieng.com

1 0

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

13 Sep '96

Joel, If I understand what you are stating is that the filtering which I have described could work for dial-up users, but not for customers which have a dedicated "leased" line into the network. You state that this is not possible due to the CPU overhead that the filtering of each packet creates. Out of curiosity, what would the CPU usage be on a typical router in your installation??? Also, do we know what the overhead is for a single filter at the ingress on a router such as a Cisco??? 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: Joel Gallun <joel(a)linux.wauug.org> at Internet Date: 9/12/96 2:52 PM What you propose is a Good Thing (tm), but I don't think it's sufficient. It still doesn't protect the 'net from antisocial behavior perpetrated by someone who has penetrated a system with dedicated access to the 'net. It seems like it would still be necessary for anyone selling dedicated access to install Good Neighboor (tm) anti-spoofing filters on their inbound interfaces (which probably requires MIPS that the routers in the field don't have). Regards, Joel On Thu, 12 Sep 1996, John G. Scudder wrote: > At 1:44 PM -0400 9/12/96, 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. :-) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Curtis, this is a great point. USR and other NAS vendors are actually in a > great position to do exactly this, by changing their boxes to block random > addresses *by default* on dial-up ports. This is of course exactly the > point Vadim and others keep making, and of course as they point out there > ought to be a knob to disable it if desired. > > Insofar as guys who "barely know what a TCP SYN is" are unlikely to twist > the knobs, defaulting filtering to "block spoofed addresses" seems like the > best and maybe only way to get them to do it. > > How about it, USR &al? > > --John > > -- > John Scudder email: jgs(a)ieng.com > Internet Engineering Group, LLC phone: (313) 669-8800 > 122 S. Main, Suite 280 fax: (313) 669-8661 > Ann Arbor, MI 41804 www: http://www.ieng.com > >

1 0

[fwd] Cracker Attack Paralyzes Panix
by Paul Ferguson 13 Sep '96

13 Sep '96

FYI: Edupage excerpt of a WSJ article. - paul >Date: Thu, 12 Sep 1996 17:18:14 -0400 (EDT) >From: Edupage Editors <educom(a)elanor.oit.unc.edu> >To: "EDUCOM Edupage Mailing List" <edupage(a)elanor.oit.unc.edu> >Subject: Edupage, 12 September 1996 > >CRACKER ATTACK PARALYZES PANIX >Repeated attacks by a computer cracker have virtually shut down New York's >Public Access Networks Corp., better known as Panix. The attacks have >overwhelmed the computers' capacity to respond to requests for an >"electronic handshake" by sending as many as 150 bogus requests a second. >"This is the first major attack of a kind that I believe to be the final >Internet security problem," says a Lucent Technologies Internet security >expert, who says he "has been waiting" for just such an event. Internet >computers have no quick way of distinguishing these bogus requests from real >ones, and even when security software is upgraded to ease the problem, the >crackers could respond with even more intense assaults. "There's going to >be the usual arms race," predicts the Lucent security expert, between >improved security measures and crackers' ability to disable them. (Wall >Street Journal 12 Sep B1) >

2 1

Re: SYN floods continue
by Vadim Antonov 13 Sep '96

13 Sep '96

Vern Paxson <vern(a)ee.lbl.gov> wrote: >In my Internet end-to-end routing study I found that fully 50% of the pairs >of paths through the Internet had a major asymmetry at the end of 1995. Sure, but where the asymmetry is? Certainly not on tail circuits of single-homed customers :) Moreover, multi-homed non-transit networks still announce all routes to all places; i.e. the filtering i was talking about will still work. It breaks on transit networks, i.e. the backbones; but people who run backbones are presumeably clueful enough to disable the filtering on backbone links, and leave it on on customer tail links. >"Major" meaning: visited at least one different city in the two directions. >(30% visited at least one different AS.) This was a significant increase >over the same figure for the end of 1994, 30%. So it may be quite hard to >make and keep Internet routing symmetric. Routing *must* be symmetrical within IGP only networks if metrics in different directions are symmetrical. When the packets leave the routing domain, that's another story. Again, the rule is "dont accept packets from an interface if there's no route for their source addresses pointing back to the same interface". Note that that route does not have to be the best one -- just that the router gets it from somewhere. --vadim

3 2

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