- NANOG - lists.nanog.org

Photos from Verizon's West St. (NYC) CO
by Jeff Wasilko 19 Sep '01

19 Sep '01

A friend of mine passed this URL on to me: http://www.internetsvc.com/vznwestco.ppt It's got 5 photos from inside of Verizon's CO, showing their DACS and 5ESS and the surrounding damage... -jeff

2 2

Re: Online DB of Nimda infected hosts.
by Ulf Zimmermann 19 Sep '01

19 Sep '01

I just fixed a problem in my php code, which will make the search for "prefix" work right. Searching for "10.10%" will not return an IP like "172.16.10.10" anymore. Going to try and work on a search based on real CIDR, so that you can enter "172.16.0.0/16". -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204

1 0

Summary: Blocking nimda probes with a content-layer switch
by Joe Abley 19 Sep '01

19 Sep '01

Summary of suggested comments on defeating nimda probes follows. Lincoln Dale's comments were cc'd to the list, but I've included fragments here anyway just to keep them together with the other bits. Thanks! Three people suggested using NBAR on cisco routers, along these lines: http://www.cisco.com/warp/public/63/nbar_acl_codered.shtml One person suggested the following config fragment for F5's Big/IP switches: rule block_nimda { if (http_uri starts_with "/scripts" or http_uri contains "root.exe") { discard } else { use ( server_pool) } } with the proviso that adjustments might be required of those url patterns are too general for your purposes. Users of Big/IP versions prior to 4.0 (which don't support "discards" can route the connections to a dummy pool. One person was using a Nortel/Alteon switch to redirect all traffic to a cacheflow client accelerator, then using pattern matching on the cacheflow box to prevent the traffic reaching the origin servers. Lincoln suggested the following for the cisco Content Engine and Content Services Switch: Cisco Content Engine: rule enable rule block url-regex http://.*/cmd\.exe rule block url-regex http://.*/root\.exe Cisco CSS11K (Content Services switch): service dummy ip address 10.1.1.1 keepalive type none active ! header-field-group cmd.exe header-field cmd.exe request-line contain "cmd.exe" header-field-group root.exe header-field root.exe request-line contain "root.exe" ! content block_cmd.exe protocol tcp port 80 url "/*" header-field-rule cmd.exe add service dummy active content block_root.exe protocol tcp port 80 url "/*" header-field-rule root.exe add service dummy active Lincoln also pointed out that the CSS and CE configs above will prevent the client's TCP SYN from reaching the server (the devices will accept the TCP sessions and receive the HTTP headers before deciding whether to pass them on to the servers). NBAR will only match the HTTP headers on TCP sessions that successfully establish a TCP session with the server ("delayed binding").

1 0

Nimda & Yahoo
by Bill Larson 19 Sep '01

19 Sep '01

Well It looks as if the Yahoo Corporate network is infected. hilla.corp.yahoo.com - [19/Sep/2001:11:22:10 -0500] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 280 "-" "-" If anyone from Yahoo is reading this list you might want to start scanning systems. --- Bill Larson Network Administrator Compu-Net Enterprises

2 1

Online DB of IPs for Nimda worm infected machines
by Ulf Zimmermann 19 Sep '01

19 Sep '01

Hello, at: http://seven.alameda.net/~ulf/nimda/ I put a page to search for infected IPs. This is the first version. Currently I put IPs into it which probed me before about 2pm PDT. I got email from 2 people who sent me their IPs, which I am going to add when they ok it. You can right now search by SQL for IPs like: 64.81.% This will display all IPs which probed me starting with 64.81. Things I am adding in the next minutes is so that people can submit them self single IPs or bulk list. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204

5 7

Afghanistan
by Smith, Rick 19 Sep '01

19 Sep '01

Has anyone started to deny all traffic to/from Afghanistan ? Wouldn't that be worth it ? Or did I miss that post? R

13 15

RE: looping traceroutes
by Hire, Ejay 19 Sep '01

19 Sep '01

This behavior would occur if the traffic was routed to a loopback interface. -----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org] Sent: Wednesday, September 19, 2001 8:09 AM To: nanog(a)merit.edu Subject: Re: looping traceroutes On Wed, Sep 19, 2001 at 12:40:51AM -0700, Ratul Mahajan wrote: > Do you think that it can be a real persistent routing loop (data packets > would actually shuttle between the two interfaces) as against some > wierdness because of traceroute? I'd tell you a story, but it would make all of nanog cringe. Put simply, I know of at least one medium size regional network who when they couldn't make "bgp work" decided to implement a series of scripts that logged into all routers and installed statics to make things work. Let me just tell you, after a few short weeks of adding and removing (and missing) such routes there were loops all over the place, many of which are probably still there. :-( There are a number of ways long lived loops can occur. I believe others have pointed out some other methods. -- Leo Bicknell - bicknell(a)ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org

1 0

Worm probes
by sigma＠pair.com 19 Sep '01

19 Sep '01

Has anyone else been seeing a dramatic increase in /scripts/.. NT worm probes this morning? We're seeing about 8000/second, starting around 9:15 Eastern time, to and from a wide variety of addresses. Is CodeRed or one of its relatives scheduled to start sweeping again today? We've never seen this level of traffic related to the NT worms. Even though we don't run any NT at all, we still have to suffer :( Kevin

30 35

RE: Afghanistan
by Smith, Rick 19 Sep '01

19 Sep '01

I called. Arin does not. They explained that they DO store the country code with the data, but then they don't allow you to query whois by country code... At least not in their version. -----Original Message----- From: Tim Devries [mailto:tim.devries@inquent.com] Sent: Tuesday, September 18, 2001 5:54 PM To: nanog(a)merit.edu Subject: Re: Afghanistan What about all other nations and states? I think that type of information would be useful regardless of this particular situation. Anyone know if arin et al catagorizes and publishes this information? ----- Original Message ----- From: "Nathan J . Mehl" <memory-nanog(a)blank.org> To: <nanog(a)merit.edu> Sent: Tuesday, September 18, 2001 10:45 AM Subject: Re: Afghanistan > > In the immortal words of Tim Devries (tim.devries(a)inquent.com) > > > > Does anyone even have a list of IP blocks allocated on a national or > > regional level? > > "None" and "none." > > Afghanistan barely has working voice phone service, and the Taliban > issued an edict banning all computers and most especially internet > access several months ago. > > Note reply-to. > > -n > > ------------------------------------------------------------<memory@blank. org> > "Thus do `Snuff Movies' take their place with `Political-Correctness,' `Sex > Addiction,' and `Postmodernism' as Godzillas of bogus moral panic, always > threatening to crush the nation in their jaws, but never quite willing to take > the final step of biting down. (--www.suck.com) > <http://blank.org/memory/>-------------------------------------------------- -- >

2 1

RE: looping traceroutes
by Jeb R. Linton 19 Sep '01

19 Sep '01

Even more interesting, I think, is the fact that the first example (with the same repeating host address) increases RTT while the second (with the alternating address) does not. It seems counter-intuitive based on the alternating versus non-alternating host addresses, but it may be that the first is a route loop, while the second is actually the filter, as described by Patrick, but between two load-balancing interfaces. As for the route-loop (?) with the same repeating address... maybe the addresses are NATed? - Jeb -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Stephen J. Wilcox Sent: Wednesday, September 19, 2001 5:16 AM To: Ratul Mahajan Cc: nanog(a)merit.edu Subject: Re: looping traceroutes the most interesting thing is that the rtt increases.. and it does so by regular amounts, about 30ms in each hop i'd guess there is a routing loop going on there for sure, i'd also guess its between two routers that are 30ms apart! perhaps it could be being caused by some sort of nat on the router so there are actually two routers looping but one or both of the addresses get nat'd as the replies come to you Steve On Tue, 18 Sep 2001, Ratul Mahajan wrote: > > > > while playing around with traceroutes for a measurement study of bgp, i > often come across the traceroute outputs similar to those appended below. > i don't have a reasonable explanation of such behaviour (i don't think > these are routing loops; they are not transient in any case). i am hoping > someone on the list has a hang of traceroute implementations, and provide > insights into under what circumstances this might happen. > > thanks, > -- ratul > > -------------- > > $ traceroute 200.13.39.1 > traceroute to 200.13.39.1 (200.13.39.1), 30 hops max, 38 byte packets > 1 regina-GE1-2.cac.washington.edu (128.95.219.100) 1.098 ms 1.233 ms > 2 uwbr2-GE3-0.cac.washington.edu (140.142.153.24) 0.349 ms 0.377 ms > 3 cnsp1-wes-GE1-0.pnw-gigapop.net (198.107.150.1) 1.561 ms 1.005 ms > 4 so-1-2-2.a07.sttlwa01.us.ra.verio.net (204.203.3.1) 21.690 ms 6.076 > 5 ge-6-2-0.r03.sttlwa01.us.bb.verio.net (129.250.28.1) 8.481 ms 8.756 > 6 p4-7-2-0.r06.plalca01.us.bb.verio.net (129.250.3.138) 29.934 ms > 7 p16-3-0-0.r00.plalca01.us.bb.verio.net (129.250.2.162) 26.740 ms > 8 p4-0.francetelecom.plalca01.us.bb.verio.net (129.250.9.134) 23.058 ms > 9 P4-3.DALBB1.Dallas.opentransit.net (193.251.132.221) 84.523 ms > 10 P5-1.FWHBB2.Fort-worth.opentransit.net (193.251.132.213) 86.653 ms > 11 Sr9-0-0.FWHAR1.Fort-worth.opentransit.net (193.251.132.227) 88.507 ms > 12 193.251.133.117 (193.251.133.117) 115.472 ms * 116.554 ms > 13 193.251.133.117 (193.251.133.117) 145.386 ms 147.224 ms 148.333 ms > 14 193.251.133.117 (193.251.133.117) 178.751 ms 172.224 ms * > 15 193.251.133.117 (193.251.133.117) 208.640 ms 203.841 ms 199.946 ms > 16 193.251.133.117 (193.251.133.117) 231.618 ms 233.234 ms 229.844 ms > 17 193.251.133.117 (193.251.133.117) 259.227 ms 258.488 ms 262.034 ms > 18 193.251.133.117 (193.251.133.117) 288.661 ms 292.598 ms 288.129 ms > 19 193.251.133.117 (193.251.133.117) 321.982 ms 320.806 ms 318.364 ms > 20 193.251.133.117 (193.251.133.117) 350.245 ms 349.834 ms 540.883 ms > 21 193.251.133.117 (193.251.133.117) 539.971 ms 410.838 ms 419.743 ms > 22 193.251.133.117 (193.251.133.117) 468.291 ms 409.761 ms 406.256 ms > 23 193.251.133.117 (193.251.133.117) 432.990 ms 439.589 ms 434.184 ms > 24 * 193.251.133.117 (193.251.133.117) 466.399 ms 465.287 ms > 25 193.251.133.117 (193.251.133.117) 500.719 ms 498.601 ms 499.957 ms > 26 193.251.133.117 (193.251.133.117) 530.089 ms 527.642 ms 528.999 ms > 27 193.251.133.117 (193.251.133.117) 556.208 ms 555.552 ms 557.387 ms > 28 193.251.133.117 (193.251.133.117) 586.776 ms 584.171 ms 586.944 ms > 29 193.251.133.117 (193.251.133.117) 608.677 ms 610.789 ms 618.232 ms > 30 193.251.133.117 (193.251.133.117) 641.141 ms 643.149 ms 639.050 ms > > ---------- > > $ traceroute 198.146.21.26 > traceroute to 198.146.21.26 (198.146.21.26), 30 hops max, 38 byte packets > 1 regina-GE1-2.cac.washington.edu (128.95.219.100) 4.395 ms 0.986 ms > 2 uwbr2-GE2-0.cac.washington.edu (140.142.155.24) 0.326 ms 0.310 ms > 3 cnsp1-wes-GE1-0.pnw-gigapop.net (198.107.150.1) 1.305 ms 1.113 ms > 4 so-1-2-2.a07.sttlwa01.us.ra.verio.net (204.203.3.1) 4.219 ms 4.308 > 5 ge-6-2-0.r03.sttlwa01.us.bb.verio.net (129.250.28.1) 4.096 ms 6.462 > 6 p4-5-0-0.r06.plalca01.us.bb.verio.net (129.250.3.89) 25.469 ms > 7 p4-0-0.r05.plalca01.us.bb.verio.net (129.250.2.129) 23.593 ms 22.371 > 8 svl-brdr-01.inet.qwest.net (205.171.4.45) 24.093 ms 25.967 ms > 9 svl-core-03.inet.qwest.net (205.171.14.109) 27.487 ms 22.669 ms > 10 svl-core-01.inet.qwest.net (205.171.14.121) 22.500 ms 24.719 ms > 11 chi-core-03.inet.qwest.net (205.171.8.50) 62.208 ms 55.153 ms > 12 chi-core-01.inet.qwest.net (205.171.20.173) 57.742 ms 54.672 ms > 13 chi-edge-01.inet.qwest.net (205.171.20.34) 54.261 ms 58.971 ms > 14 208.46.63.202 (208.46.63.202) 88.583 ms 69.619 ms 67.605 ms > 15 208.63.128.3 (208.63.128.3) 70.551 ms 67.581 ms 69.375 ms > 16 208.63.128.1 (208.63.128.1) 65.115 ms 70.951 ms 66.083 ms > 17 208.63.128.3 (208.63.128.3) 67.628 ms 65.488 ms 68.418 ms > 18 208.63.128.1 (208.63.128.1) 72.197 ms 71.422 ms 69.517 ms > 19 208.63.128.3 (208.63.128.3) 68.539 ms 68.976 ms 67.911 ms > 20 208.63.128.1 (208.63.128.1) 72.373 ms 67.838 ms 66.468 ms > 21 208.63.128.3 (208.63.128.3) 67.040 ms 69.136 ms 67.631 ms > 22 208.63.128.1 (208.63.128.1) 66.317 ms 83.947 ms 70.693 ms > 23 208.63.128.3 (208.63.128.3) 66.865 ms 69.521 ms 69.760 ms > 24 208.63.128.1 (208.63.128.1) 69.604 ms 67.534 ms 70.447 ms > 25 208.63.128.3 (208.63.128.3) 68.285 ms 69.772 ms 67.721 ms > 26 208.63.128.1 (208.63.128.1) 71.915 ms 69.530 ms 72.403 ms > 27 208.63.128.3 (208.63.128.3) 111.475 ms 69.670 ms 69.267 ms > 28 208.63.128.1 (208.63.128.1) 68.883 ms 67.147 ms 72.106 ms > 29 208.63.128.3 (208.63.128.3) 69.842 ms 67.889 ms 66.944 ms > 30 208.63.128.1 (208.63.128.1) 70.986 ms 73.124 ms 68.452 ms > > > > -- Stephen J. Wilcox IP Services Manager, Opal Telecom http://www.opaltelecom.co.uk/ Tel: 0161 222 2000 Fax: 0161 222 2008

1 0