September 1996 - NANOG - lists.nanog.org

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 11 Sep '96

11 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 11 Sep '96

11 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 11 Sep '96

11 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

SYN: from the firewalls list
by Michael Dillon 11 Sep '96

11 Sep '96

---------- Forwarded message ---------- Date: Thu, 12 Sep 1996 03:31:11 +0200 (MET DST) From: Bernd Eckenfels <lists(a)lina.inka.de> To: Robert Hanson <roberth(a)cet.com> Cc: firewalls(a)GreatCircle.COM Subject: Re: SYN floods continue (fwd) Hi, > how do we fix zillions of machines from a "red flag" situation. or at > least the ones we care about... is this not "logical"... There are 2 fixes. The first is very simple: Every ISP has ppl to do the work. Within a few hours every SYN attack should be backtraceable, especially if one can expect it and prepare to it. Every ISP only needs the phone number of the person on the upstream isp which is providing the trace service. Additionally Tools like Argus can be used at ISPs to log the Traffic and bad conditions with source. Geenrally this is a political Fix which can be supported by Filtering and all kind of time consuming and expensive work. The other fix is to deveop a new protocol which is beeter suited for communication in an hostile environment. This is IPv6 or IPsec. Currently the is no real fix to SYN attacks. There are a few good attempts like reverse-resolving of addresses, wrap around listen-backlogs instead of fill up queues. At least systems can be enhanced to WARN about SYN Attacks. With some things like Wrap-Around queues one can at least enhance the amount of bandwith needed for a syn attack. But you can nerver gurantee operation forr servicers which are connected to the open internet. Greetings Bernd -- (OO) -- Bernd_Eckenfels(a)Wittumstrasse13.76646Bruchsal.de -- ( .. ) ecki(a){lina.inka.de,linux.de} http://home.pages.de/~eckes/ o--o *plush* 2048/A2C51749 eckes@irc +4972573817 *plush* (O____O) If privacy is outlawed only Outlaws have privacy

1 0

SYN? GIF at 11? Nahhh...
by Michael Dillon 11 Sep '96

11 Sep '96

> This is as big a reason as any for providers to start filtering their > _outgoing_ traffic so that only addresses which could have originated in > your network can pass out of your network. And if you don't do this, very soon your provider will yank your connection and sue *YOU* for damages if not fraud. Think about it... The company who gets allocated 192.0.2/8 pays Sprint for access to the net. You pay MCI for access for the net. One of your customers launches a SYN storm and your provider identifies a certain number of packets leaving your network with 192.0.2/8 addresses which are part of the attack. Sprint gets a court order to see those records after the attack is tracked down to your network. Sprint sues you and has the police lay fraud charges against you because your network was illegally impersonating a Sprint customers network and as a result, your packets transitted a route through Sprint's infrastructure that neither you nor MCI were supposed to use. Could it happen? If that's what it takes to prevent GIF at 11 then, yes it could happen. You see there is a fundamental law of the universe that as you approach GIF at 11 the fabric of the universe stretches and distorts in a chaotic fractal manner such that you can never actually reach the point where GIF at 11 occurs. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael(a)memra.com

1 0

Re: SYN floods continueg
by Avi Freedman 11 Sep '96

11 Sep '96

> Could you provide sample CISCO syntax ACL filters to perform the above? > I'm not clear how you filter out these kind of attacks. > Thanks, > > --curtis This is actually an incoming filter... 'sho access-list 102' shows you counts on hits for each line; pretty interesting, actually. Each line says permit any kind of ip data from anywhere, from any IP address, to the network specified. For an outgoing filter you'd reverse it so it looked like 'acc 102 permit ip <our-net> <inverted-mask> any'. no acc 102 acc 102 permit ip any 198.138.103.0 0.0.0.255 acc 102 permit ip any 205.199.164.0 0.0.0.255 acc 102 permit ip any 204.193.157.0 0.0.0.255 acc 102 permit ip any 199.171.193.0 0.0.0.255 acc 102 permit ip any 199.67.58.0 0.0.0.255 acc 102 permit ip any 205.160.86.0 0.0.0.255 acc 102 permit ip any 192.135.189.0 0.0.0.255 acc 102 permit ip any 198.133.170.0 0.0.0.255 ! not all of these are /16s, I was just lazy yesterday ! eventually the 0.0.0.255.255s should become more specific acc 102 permit ip any 206.42.0.0 0.0.255.255 acc 102 permit ip any 137.239.0.0 0.0.255.255 acc 102 permit ip any 198.69.0.0 0.0.255.255 acc 102 permit ip any 206.161.0.0 0.0.255.255 acc 102 permit ip any 205.164.128.0 0.0.255.255 acc 102 permit ip any 170.115.0.0 0.0.255.255 acc 102 permit ip any 207.106.0.0 0.0.255.255 acc 102 permit ip any 199.234.208.0 0.0.255.255 acc 102 permit ip any 207.8.128.0 0.0.255.255 acc 102 permit ip any 192.157.69.47 0.0.0.0 acc 102 permit ip any 192.41.177.87 0.0.0.0 ! acc 102 permit ip any 198.32.136.82 0.0.0.0 acc 102 deny ip any any Avi

3 3

Re: SYN floods continue (fwd)
by Michael Dillon 11 Sep '96

11 Sep '96

Is this practical on a global scale? ---------- Forwarded message ---------- Date: Wed, 11 Sep 96 14:06:05 CDT From: Andrew Molitor <amolitor(a)anubis.network.com> To: firewalls(a)greatcircle.com, michael(a)memra.com Subject: Re: SYN floods continue (fwd) With fine NSC routers all over the place, one could insert a RR option into all the SYN packets flowing through them. The enclosed filter fragment will insert a RR option capable of recording the first 7 routers after this one that the packet goes through. It won't work on all our stuff, and (realistically) is enclosed for reference only. I can dream, though, eh? A little additional checking could be added to make it hard or impossible to spoof this by inserting your own RR option at the source. Basically, if you're deploying this, you strip out options on packets arriving from 'little leaf nodes that might be bad guys' before you add yours in. It would be relatively trivial to add this to, say, the freely available IP filtering in Linux. The performance hit in the core routers would only be taken for SYN packets, which are some modest percentage (less that 10?) of all packets. They'd feel it, but would probably not topple right over. With this option present, the problem or tracing it back to the source begins to look like backtracing usenet headers -- it's not easy, but it often/usually provides some useful information. It also would require lots of co-operation among ISPs. Andrew filter syn_tracking not ip_protocol in (6) break; # Get outta here if it's not TCP not ip_fo in (0) break; # or if the header's not here not tl_byte (13) mask 0x02 in (0x02) break; # if SYN not set, get out ip_option_present 0x07 break; # Get out if RR option already here # Otherwise insert a 7 hop RR option. stamp_option 0x071f0400000000000000000000000000000000000000000000000000000000; end

2 1

Re: SYN floods continueg
by Avi Freedman 11 Sep '96

11 Sep '96

> On Wed, 11 Sep 1996, Avi Freedman wrote: > > and another provider in Philly was attacked for 4-6 hours on news ports > > (pretty ineffective). > > Hi. Why was this ineffective? > > Thanks, > Chris Caputo > President, Altopia Corporation Because most providers only let their customers connect to their nnrp/nntp servers. And you can easily build a filter which allows just port-119 connects from your news peers and denies all others... Of course, that wouldn't work as well for alt.net (you guys) if you're still selling off-site nnrp access to hundreds of people. Avi

1 0