- NANOG - lists.nanog.org

Smurfing
by Alex Rubenstein 17 Feb '98

17 Feb '98

One of my customers is being smurfed right now. Filling a 10 Meg to UU Net. It is wonderful to know that everyone has 'no ip directed-broadcast'. It's *SO* easy to do!

10 9

Re: Fiber cut in SJ 1:54 EST
by Matt Sommer 16 Feb '98

16 Feb '98

-----Original Message----- From: Richard Irving <rirving(a)onecall.net> Date: Saturday, February 14, 1998 4:56 PM Subject: Fiber cut in SJ 1:54 EST >There has been a fiber cut in SJ region affecting several >carriers. The fiber carriers (WC) will be keeping everyone >informed. Expect unusual flows. > > :( They will? How many know about the cut in Atlanta Sunday? 8-12 hrs? I don't know exactly. Do they (WorldCom) have a maillist for trouble and scheduled maintenance or a status page? And what happened to their website? Their dns entry is gone. I subscribed to weather-talk(a)internetweather.com but there's not much posting there. Any other sites or lists for outages? Matt Sommer Sysadmin

2 1

whois
by Bill Becker 16 Feb '98

16 Feb '98

Have i Missed Something or is whois broke today? --------------------------------------------------------------------- biteme:~$ whois 38 [rs.internic.net] No match for "38". The InterNIC Registration Services Host contains ONLY non-military Domains and POC's. Other associated whois servers: American Registry for Internet Numbers whois server - whois.arin.net European IP Address Allocations whois server - whois.ripe.net US Military whois server - whois.nic.mil ---------------------------------------------------------------------- Oh well.

6 7

Re: Smurfing
by William Allen Simpson 16 Feb '98

16 Feb '98

Thanks for the excellent reply, although you forgot to mention that every other ICMP message, including error messages, timestamps, and such, MUST discard broadcast/multicast. Echo is the _only_ MAY be discarded. As the discussion notes, there was some controversy. I vaguely remember the discussion at the time. But _all_ the stacks that I've ever worked on follow the MAY and _do_ the discard. Maybe I should join a *nix group. We need to put pressure on vendors (especially router vendors and large commercial host vendors) to _discard_ by default. I am unaware of any troubleshooting value. After all, should you want to scan for hosts, use SNMP. Or increment your ping address. Lots of simple harmless ways to do the same thing. Especially since you need to know the (now variable) local mask to effectively use a directed broadcast anyway. Directed broadcast was a kludge in the first place. Maybe it's time to deprecate it entirely. > From: "Craig A. Huegen" <chuegen(a)quadrunner.com> > Most stack implementors have chosen to respond to it because of its > troubleshooting value; then again, the date of the RFC shows why many > folks would tend to believe the threat of the attack wouldn't be very > large. > WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

2 1

Re: Smurfing
by Havard.Eidnes＠runit.sintef.no 16 Feb '98

16 Feb '98

Hi, getting Smurfing "under control" takes two things: o All router administrators on the immediately reachable Internet needs to turn off directed broadcasts on their router interfaces. It's conceivable that "a significant portion of all" would do as well, but the magnitude of this problem boggles the mind. First of all, we'd need to distribute the appropriate amount of clue to all the corners of the net where this needs to happen. Maybe, just maybe, we'll get there sometime (I'm an optimist!). o Making sure source IP address spoofing isn't as easily done as it is now. Also an easy one, right? ;-) Anyone have any idea where most of the attacks originate: dial-up ports or from folks more directly connected to the net? (I'd bet on a happy mix ;-) Equipment providers can offer some help here in offering an effective and efficient knob which can do the equivalent of "RPF"ing on unicast traffic (if you don't have a route back to the source and the route doesn't point to the incoming interface for the packet, drop it on the floor). Obviously, this assumes symmetric traffic patterns, which are typical at the edges of the network but not quite so typical in our/your modern backbone networks. o While we struggle with the above two, at least some service providers need to become more responsive in tracking these sort of events back to their real source. No names mentioned, none forgotten. o Lastly, I think that better tools are needed to track this sort of attacks back to their source (?). I'm not saying these battles should not be fought; far from it, but it's probably going to take a while before any of these can have any significant effect on the problem. - Håvard

9 9

NSI Bulletin 098-003 | ARIN Announcement
by Chuck Gomes 16 Feb '98

16 Feb '98

Effective immediately, information about networks, autonomous system numbers, and inverse addressing records will only be available from ARIN's Whois servers via telnet at WHOIS.ARIN.NET. The Whois database managed for the InterNIC by Network Solutions will no longer be the authoritative source for IP numbers, autonomous system numbers and inverse addressing records. On December 22, 1997 the American Registry for Internet Numbers (ARIN) assumed responsibility for IP address allocation and network registration functions previously performed by the InterNIC. As part of the process to separate ARIN from the InterNIC, services related to IP address allocations, autonomous system numbers and inverse addressing are no longer available from InterNIC Registration Services. Changes and updates to these records need to be made by contacting ARIN via e-mail at hostmaster(a)arin.net. NOTE: the WHOIS database maintained by InterNIC Registration Services (Network Solutions, Inc.) will remain as the authoritative source for .COM, .NET, .ORG and .EDU domain name information. In some cases, such as updates to host records, it may be necessary to file an update request with the InterNIC and also ARIN. For example the IP address of a host record may need to be updated with InterNIC Registration Services and a request may need to be made to update the inverse addressing records maintained by ARIN. Information about Network Solutions, Inc is available at http://www.netsol.com. Information about ARIN is available at http://www.arin.net. _____________________________________ Chuck Gomes Director of Customer Programs Network Solutions, Inc.

1 0

Re: Smurfing
by Sean M. Doran 16 Feb '98

16 Feb '98

| > o Making sure source IP address spoofing isn't as easily done as | > it is now. Also an easy one, right? ;-) | | I agree, and this is what we have done. The earlier post (from someone else) | was asking about how to filter *outbound* directed broadcasts, and I didn't | understand how this could be done. A number of my NANOG colleagues have | adamantly agreed that it can't! You probably can't, however the point Håvard was making is that if you deny people the opportunity to spoof the origin of their packets, you deny people the ability to engage in long-term denials-of-service of this nature, and you increase the liklihood of catching the individual perpetrator. These two things will tend to reduce the number of Smurf and other attacks. | > o Lastly, I think that better tools are needed to track this | > sort of attacks back to their source (?). | | That would be very difficult, effectively requiring the ability to query | routers and ask if they are seeing packets bound for a specific address. I'd | love to see some tools that would help us do that, however! Håvard mentioned work going on to do RPF checking. A feature that looked for "out of profile" RPF-failed traffic but that did not drop RPF-failed traffic in general would be a useful debugging tool. Out-of-profile traffic ought to include any large amount of traffic over a sustained period. More cleverly, if the traffic is not TCP traffic or if it is TCP traffic but does not appear to react to induced early packet loss (i.e., you drop a packet deliberately and wait for the sender to react with a retransmit and a decrease in sending bandwidth) and it fails the RPF test, ring alarm bells and optionally drop the traffic altogether. RPF, btw, is "reverse path forwarding", which comes from the wonderful world of multicast lingo. Essentially when you do any type of flooding you ant to make sure you don't forward the flooded traffic back in the direction from which you heard it in the first place. In the world of unicast it is a short-hand way of saying that you check to make sure that a particular packet came from the direction in which you route traffic destined for that packet's source address. Sean.

1 0

Re: Smurfing
by shields＠crosslink.net 15 Feb '98

15 Feb '98

In article <Pine.QUAD.3.96.980213225740.16562C-100000(a)quad.quadrunner.com>, "Craig A. Huegen" <chuegen(a)quadrunner.com> wrote: > "ipfw" can be used from Linux to block broadcast echos, a la: Or the kernel can be trivially patched. http://www.geek-girl.com/bugtraq/1997_3/0158.html -- Shields, CrossLink.

1 0

POP3 server3 on NT server 4 .0
by tien＠VNET.IBM.COM 15 Feb '98

15 Feb '98

Hi, Can someone suggest a few good POP3 mail servers on Microsoft NT server Version 4 ? Either freeware or commercial products are fine. Thanks a lot. Regards, Sung S. Tien tien(a)vnet.ibm.com

5 5

Performance probs / asymetric routing in the us
by Winfried Haug 14 Feb '98

14 Feb '98

Hello, we have sometimes heavy performance problems and we are now at the end of our knowledge :-) The facts: we have a 3 Mbit Part of the OC3 going from Frankfurt (ECRC/Ebone) to Sprint. We never had longer peaks, there is enough space in the line. Sometimes more than one MB/sec. Ping times are quite good, so this cant be the reason for our problems. Some ftp Downloads from US-Sites (cisco.com, sun.com etc...) are as fast as a ISDN line. (6-7 kb/sec :-)) othes have 60-80kb/sec... Several Traceroutes now have shown us, that almost all routes in the usa are asymetric: Just one example: Von nitrous.digex.net: Type escape sequence to abort. Tracing the route to anify.farside.net (195.110.11.2) 1 icm-mae-e-f0/0.icp.net (192.41.177.240) 4 msec 4 msec 4 msec 2 icm-bb1-dc-1-0-T3.icp.net (198.67.131.10) [AS 1800] 4 msec 4 msec 4 msec 3 icm-pen-1-1-0-T3.icp.net (198.67.131.18) [AS 1800] 8 msec 4 msec 4 msec 4 icm-pen-14-P0/0-OC3C.icp.net (198.67.142.70) [AS 1800] 8 msec 4 msec 4 msec 5 icm-pen-13-P1/0-OC3C.icp.net (198.67.142.97) [AS 1800] 8 msec 8 msec 4 msec 6 198.67.142.86 [AS 1800] 88 msec 88 msec 165.117.55.2 64 msec 7 NCP.Frankfurt2.ECRC.NET (192.121.158.110) [AS 1755] 92 msec NCP.Frankfurt2.ECRC.NET (192.121.158.110) [AS 1755] 88 msec NCP.Frankfurt2.ECRC.NET (192.121.158.110) [AS 1755] 92 msec 8 165.117.50.26 76 msec seicom-gw-FFM2.ecrc.net (195.27.83.90) [AS 1273] 112 msec seicom-gw-FFM2.ecrc.net (195.27.83.90) [AS 1273] 136 msec 9 US-gw.Frankfurt.seicom.NET (194.97.193.18) [AS 5549] 128 msec US-gw.Frankfurt.seicom.NET (194.97.193.18) [AS 5549] 168 msec US-gw.Frankfurt.seicom.NET (194.97.193.18) [AS 5549] 128 msec 10 Frankfurt1-s0-0.bw-bone.net (195.254.83.33) [AS 5549] 352 msec 140 msec 156 msec 11 Heidelberg1-s3-7.bw-bone.net (195.110.0.85) [AS 8254] 156 msec 156 msec 168 msec 12 portal.farside.net (195.110.7.34) [AS 8254] 196 msec 288 msec 336 msec 13 anify.farside.net (195.110.11.2) [AS 8254] 128 msec 148 msec 160 msec and the way back: traceroute to nitrous.digex.net (205.197.249.3), 30 hops max, 40 byte packets 1 195.110.11.1 (195.110.11.1) 3.218 ms 2.171 ms 2.065 ms 2 core1 (195.110.7.33) 7.054 ms 4.865 ms 5.615 ms 3 Frankfurt1-s0-0.bw-bone.net (195.110.0.86) 8.134 ms 7.691 ms 8.097 ms 4 195.254.83.34 (195.254.83.34) 8.886 ms 7.593 ms 7.070 ms 5 Ebone-gw.I-bone.NET (194.97.193.17) 14.484 ms 16.114 ms 16.668 ms 6 s1-0-r1-FFM2.ecrc.net (195.27.83.89) 38.792 ms 34.726 ms 65.364 ms 7 frankfurt-ebs2-h2-0-1.ebone.net (192.121.158.109) 59.266 ms 47.429 ms 39.759 ms 8 198.67.142.85 (198.67.142.85) 116.419 ms 107.364 ms 140.257 ms 9 sprint-nap.digex.net (192.157.69.42) 127.001 ms 133.519 ms 122.598 ms 10 phl2-core2-f4-0.atlas.digex.net (165.117.51.37) 276.222 ms 144.815 ms 134.420 ms 11 dca1-cpe2-h10-1-0.atlas.digex.net (165.117.51.33) 124.355 ms 127.911 ms 139.501 ms 12 dca1-cpe8-fe4-0.atlas.digex.net (165.117.224.2) 148.073 ms 144.636 ms 131.157 ms 13 nitrous.digex.net (205.197.249.3) 259.808 ms 170.213 ms 196.965 ms Currently we dont have a second path to the us, so it must have other reasons. The route object in the RIPE Datebase contains the correct AS and Maintainer. We dont have a advisory: AS690 1:1800 2:1239(147) 3:1239(218) 4:1239(144) which some ISPs have even it. Is this still necessary ? Does it make sense ? The Source IPs belong either to several /19 Blocks in 195.X.X.X or one /17 in 195.X.X.X or one /18 in 194.X.X.X.According to the filter- policies, theses ip-blocks are good enough :-=) Are there other sources for gernerating filter-lists on the core router in the us than the ripe datebase ? To avoid wrong results due to the server load: can anybody provide my a ftp-sute, which is connected very good (OC3 or more) and has no local load problems caused by too much user on the system... Winfried -- --- Winfried Haug | SEICOM.DE & SCHWABEN.DE | Tel. +49 7121 9770- 0 Laiblinsplatz 12 | Internet+ISDN access & consulting | Fax. +49 7121 9770-19 72793 Pfullingen | Access in STGT + RT + TUE + BB + LB | Rack +49 7127 989-X haug(a)schwaben.net| 150*ISDN (64kb/X.75) / 100 * K56flex | Rack +49 711 9675-X haug(a)seicom.net |SAP-OSS * FTP * TELNET * NETNEWS * IRC | Rack +49 7121 709-X * 10 MBit DE-CIX * 2 MBit INXS * 3 MBit ecrc/ebone * 2 Mbit Belwue * 2 Mbit WIN

1 0