- Test - lists.nanog.org

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

Re: customers and web servers and level one naps
by Justin W. Newton 12 Sep '96

12 Sep '96

At 11:30 AM 9/10/96 -0700, Michael Dillon wrote: >On Tue, 10 Sep 1996, Srinivasarao Mulugu wrote: > >> I know we do, Michael. And I have "their" answer. But they may not have >> the same experiences you did. > >> > > Have you had much experience, having the servers connect directly on to a >> > > level-2 device like a FDDI-to Ethernet (e.g. catalyst) connector ? and it >> > > security implications ? > >It's not a matter of experience. It's a matter of what a level-2 device is >and how it normally works. There is no security at level 2. > >Therefore, you should only connect trusted pieces of equipment to a >level-2 media unless it is being used as a point-to-point media. Lets use >Ethernet as an example. If you connect a customer web server to an >Ethernet then they can sniff any traffic that goes by and possibly do >nasty things like spoofing. Even if they would never do such a thing they >may be hacked by somebody who would do such a thing. So it is not a good >idea to share a level 2 media in this way. The MAE's are switches. Unless you are sending super secret BROADCAST traffic the security implications you are mentioning are non-existant. Justin Newton Internet Architect Erol's Internet Services

3 2

Re: SYN floods continue
by Vern Paxson 12 Sep '96

12 Sep '96

> That prohibits IP src spoofing (and asymmetrical paths). > ... > In most networks asymmetrical routing is an indication of a bug in > an IGP configuration, so early detection of the configuration problems > would be an additional benefit. 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. "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. The paper's available from: ftp://ftp.ee.lbl.gov/papers/routing.SIGCOMM.ps.Z - Vern

2 1

InterNIC mail problems?
by Eric Kozowski 12 Sep '96

12 Sep '96

Is anyone else having problems sending mail to the InterNIC? I have stuff in the queue for them for 19 hours now. The queue shows the following error: (Deferred: Connection reset by peer with rs.internic.net.) Also a telnet to port 25 on rs.internic.net produces the following: % telnet rs.internic.net 25 Trying 198.41.0.5 ... Connected to rs.internic.net. Escape character is '^]'. Connection closed by foreign host. This makes it hard to get them to correct screwed up whois entries :-O -- Eric Kozowski Senior Network Engineer eric(a)structured.net Structured Network Systems, Inc. (503)656-3235 FAX Better, Cheaper, Faster -- pick any two. (800)881-0962 Voice http://www.structured.net/ "Providing High Quality, Reliable Internet Service" -- 56k to DS1

2 1

SYN Resisting
by Avi Freedman 12 Sep '96

12 Sep '96

I know this may not be strictly on-topic here because it deals with "host-stuff" rather than "router-stuff", but here goes... I will have some comments on how to track where SYN storms are coming from a bit later. In order to build a SYN-resistant BSD kernel, you need to modify one file in src/sys/os, uipc_socket2.c, and you also need to modify src/sys/netinet/tcp_timer.h and you have to rebuild tcp_usrreq.c and tcp_input.c in the netinet directory. For those without SunOS source, I will get Sun4c (Sparc 1/1+/2/IPC/IPX/ ELC/SLC) binaries online; for those running BSD on other platforms, you probably have source. >From the bottom level up, change TCPTV_KEEP_INIT from 75*PR_SLOWHZ to 7*PR_SLOWHZ (or whatever # you want). This timeout (the 75) is the number of seconds that the kernel will keep un-established TCP PCB/sockets around for... When the SYN is received, it is acknowledged and the PCB && socket are set up for the embryonic session; the goal is to rip those things out of any queues they're in more aggressively. At the top (socket) level, instead of modifying SOMAXCONN, I decided to just see what happened if I removed the limit. What you do is up to your own personal taste. I commented out: if (head->so_qlen + head->so_q0len > 3 * head->so_qlimit / 2) goto bad; in src/sys/os/uipc_socket2.c. Head in this case points to a 'server' socket (the socket for your web, mail, news, ... server). so_qlimit is set to the min of either what the listen() system call inside of it requested or SOMAXCONN. I had some funkiness increasing SOMAXCONN to 8096 or so when I was playing with it - and didn't want to recompile inetd, sendmail, etc... to ask for more slots in the listen() queue (just a linked list or two), so I figured I'd *try* to make the queue size infinite and see what happened. so_qlen and so_q0len are the linked lists of sockets waiting to be accept()ed and the sockets of the embryonic (not established) TCP connections that were aimed at this server socket, respectively. The code uses a 3/2 fudge factor to make the comparison, and is saying "if the number of queued requests is > 3/2 times the limit for this socket, don't stick this requesting socket in the queue - just destroy it and exit". I just commented those two lines out. On a Sparc 1+ w/ 4.1.4, I could sustain a 200-400 SYN-packet/sec attack and still remain functional (and quick for a 1+), but the machine didn't normally run web servers... Even when I nailed it with 1000 SYNs/sec, the machine continued functioning but I couldn't connect to the socket being nailed. A second after stopping the heavier attack, I could. I've had trouble compiling and getting these modified modules to work on a Sun4m architecture (Sparc 5 and 10) but may play more with that today. The best solution is to implement a better data structure than a linked list for storing the embryonic connections per socket. A large-ish array with appropriate hashing, perhaps. Either per socket or for the whole kernel. If anyone wants to attack that problem, please do; otherwise, I'll blow BSD on a laptop so I can play with it when I'm next on a plane/ train. Avi

3 3