- NANOG - lists.nanog.org

Re: looping traceroutes
by Marshall Eubanks 19 Sep '01

19 Sep '01

> >From AS 16517 one seems normal, one does not. In both cases eBGP seems normal. I cannot ping to the non-normal one, so a black hole is possible. Maybe they are running an iBGP with a loop. Regards Marshall Eubanks NORMAL multicasttech-2>trace 200.13.39.1 Type escape sequence to abort. Tracing the route to 200.13.39.1 1 207.ATM1-0.GW2.DCA8.ALTER.NET (157.130.46.53) 4 msec 4 msec 4 msec 2 0.so-3-0-0.XL2.DCA8.ALTER.NET (146.188.162.194) [AS 701] 8 msec 4 msec 24 msec 3 0.so-3-0-0.TR2.DCA8.ALTER.NET (152.63.144.29) [AS 701] 4 msec 4 msec 4 msec 4 115.at-6-0-0.TR2.HOU7.ALTER.NET (146.188.141.142) [AS 701] 64 msec 56 msec 60 msec 5 186.at-1-0-0.XR2.HOU7.ALTER.NET (152.63.97.233) [AS 701] 60 msec 52 msec 56 msec 6 182.ATM5-0.GW4.HOU7.ALTER.NET (152.63.100.133) [AS 701] 60 msec 56 msec 60 msec 7 avental-gw.customer.ALTER.NET (157.130.133.206) [AS 701] 72 msec 72 msec 72 msec 8 200.33.208.206 [AS 6503] 100 msec 84 msec 92 msec 9 ar6.mexmdf.avantel.net.mx (200.33.209.29) [AS 6503] 92 msec 100 msec 88 msec 10 na-62-239.na.avantel.net.mx (200.39.239.62) [AS 6503] 112 msec 96 msec 88 msec 11 200.13.38.129 [AS 3561] 144 msec 136 msec 128 msec multicasttech-2>show ip bgp 200.13.39.1 BGP routing table entry for 200.13.39.0/24, version 155431 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 192.168.1.2 701 6503 157.130.46.53 from 157.130.46.53 (137.39.4.99) Origin IGP, localpref 100, valid, external, best 1239 1239 1239 5511 160.81.38.225 from 160.81.38.225 (144.228.242.54) Origin IGP, metric 48, localpref 100, valid, external NOT NORMAL multicasttech-2>trace 198.146.21.26 Type escape sequence to abort. Tracing the route to 198.146.21.26 1 207.ATM1-0.GW2.DCA8.ALTER.NET (157.130.46.53) 4 msec 12 msec 4 msec 2 0.so-3-0-0.XL1.DCA8.ALTER.NET (146.188.162.198) [AS 701] 4 msec 8 msec 8 msec 3 189.at-1-0-0.XR1.DCA6.ALTER.NET (152.63.33.77) [AS 701] 4 msec 8 msec 24 msec 4 0.so-2-1-0.XL1.DCA6.ALTER.NET (152.63.38.85) [AS 701] 8 msec 8 msec 8 msec 5 POS6-0.BR4.DCA6.ALTER.NET (152.63.41.229) [AS 701] 32 msec 12 msec 4 msec 6 204.255.169.98 [AS 701] 8 msec 8 msec 8 msec 7 wdc-core-01.inet.qwest.net (205.171.24.37) [AS 209] 8 msec 8 msec 4 msec 8 dca-core-02.inet.qwest.net (205.171.8.209) [AS 209] 4 msec 8 msec 8 msec 9 atl-core-02.inet.qwest.net (205.171.8.153) [AS 209] 28 msec 24 msec 24 msec 10 atl-edge-05.inet.qwest.net (205.171.21.54) [AS 209] 44 msec 24 msec 28 msec 11 63.144.0.110 [AS 209] 36 msec 40 msec 32 msec 12 * * * 13 208.63.129.1 [AS 19956] 32 msec 32 msec 32 msec 14 208.63.129.3 [AS 19956] 56 msec * 32 msec 15 208.63.129.1 [AS 19956] 36 msec 36 msec 32 msec 16 * 208.63.129.3 [AS 19956] 32 msec * 17 208.63.129.1 [AS 19956] 32 msec 100 msec 96 msec 18 * 208.63.129.3 [AS 19956] 36 msec * 19 208.63.129.1 [AS 19956] 36 msec 32 msec 32 msec 20 208.63.129.3 [AS 19956] 32 msec * 32 msec 21 208.63.129.1 [AS 19956] 32 msec 36 msec 44 msec 22 * * 208.63.129.3 [AS 19956] 40 msec 23 208.63.129.1 [AS 19956] 32 msec 40 msec 32 msec 24 * 208.63.129.3 [AS 19956] 32 msec * 25 208.63.129.1 [AS 19956] 36 msec 36 msec 40 msec 26 208.63.129.3 [AS 19956] 32 msec * 32 msec 27 208.63.129.1 [AS 19956] 32 msec 36 msec 40 msec 28 * 208.63.129.3 [AS 19956] 36 msec * 29 208.63.129.1 [AS 19956] 36 msec 36 msec 52 msec 30 * * * multicasttech-2>show ip bgp 198.146.21.26 BGP routing table entry for 198.146.21.0/24, version 696388 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 192.168.1.2 701 209 19956 16473 157.130.46.53 from 157.130.46.53 (137.39.4.99) Origin incomplete, localpref 100, valid, external, best 1239 1239 1239 209 19956 16473 160.81.38.225 from 160.81.38.225 (144.228.242.54) Origin incomplete, metric 8, localpref 100, valid, external multicasttech-2> multicasttech-2>ping 198.146.21.26 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 198.146.21.26, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) multicasttech-2> > >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 > > Marshall Eubanks tme(a)21rst-century.com

1 0

looping traceroutes
by Ratul Mahajan 19 Sep '01

19 Sep '01

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

2 1

Fw: NIPC Advisory 01-021, "Potential DDoS Attacks"
by Mike Lewinski 19 Sep '01

19 Sep '01

----- Original Message ----- From: "VanMeter, John" <John.VanMeter(a)ost.dot.gov> To: "Incidents (E-mail)" <INCIDENTS(a)SECURITYFOCUS.COM> Sent: Tuesday, September 18, 2001 4:12 AM Subject: NIPC Advisory 01-021, "Potential DDoS Attacks" > > > National Infrastructure Protection Center > "Potential Distributed Denial of Service (DDoS) Attacks" > Advisory 01-021 > 17 September 2001 > > The National Infrastructure Protection Center (NIPC) expects an increase in > Distributed Denial of Service (DDoS) attacks. NIPC Advisory 01-020, > "Increased Cyber Awareness" dated September 14, 2001 warned of threatened > vigilante hacking activity against organizations associated with the > perceived perpetrators of the September 11, 2001 terror attacks. > On September 12, 2001, a group of hackers named the Dispatchers claimed they > had already begun network operations against information infrastructure > components such as routers. The Dispatchers stated they were targeting the > communications and finance infrastructures. They also predicted that they > would be prepared for increased operations on or about Tuesday, September > 18, 2001. > There is the opportunity for significant collateral damage to any computer > network and telecommunications infrastructure that does not have current > countermeasures in place. The Dispatchers claim to have over 1,000 machines > under their control for the attacks. It is likely that the attackers will > mask their operations by using the IP addresses and pirated systems of > uninvolved third parties. > System administrators are encouraged to check their systems for zombie agent > software and ensure they institute best practices such as ingress and egress > filtering. The NIPC has made available the "Find DDoS" tool to determine if > your computer has been infected by the most common DDoS agents. The tool > may be downloaded from the following website: > http://www.nipc.gov/warnings/advisories/2000/00-055.htm. > Additionally, a list of best practices is available from the CERT/CC > website, located at: > http://www.cert.org/security-improvement. > Recipients of this advisory are encouraged to report computer intrusions to > their local FBI office > (http://www.fbi.gov/contact/fo/fo.htm) or the NIPC, and to the other > appropriate authorities. Incidents may be reported online at > http://www.nipc.gov/incident/cirr.htm. The .NIPC Watch and Warning Unit > can be reached at (202) 323-3204/3205/3206 or nipc.watch(a)fbi.gov. > > > > > ---------------------------------------------------------------------- ------ > This list is provided by the SecurityFocus ARIS analyzer service. > For more information on this free incident handling, management > and tracking system please see: http://aris.securityfocus.com > >

1 0

Somebody Doesn't Like QwestOutage.Com
by Allen Gwinn 19 Sep '01

19 Sep '01

The firewall is reporting SYN floods all across our class C :) They'll eventually give up and go away (or get caught), so keep trying and you'll eventually be able to access it. Allen Gwinn

1 0

Pattern matching odd HTTP request
by Jake Khuon 19 Sep '01

19 Sep '01

Anyone seeing a lot of these in their webserver logs? 208.202.180.4 - - [18/Sep/2001:11:19:31 -0700] "-" 408 - I'm attempting to pattern match this on my cisco so I can drop the packets at the front door. I can't seem to get a good pattern. Firing up snoop yields: ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 262 arrived at 11:35:57.88 ETHER: Packet size = 60 bytes ETHER: Destination = 8:0:20:9d:e1:8a, Sun ETHER: Source = 0:1:96:24:c2:41, ETHER: Ethertype = 0800 (IP) ETHER: IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx. .... = 0 (precedence) IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: Total length = 40 bytes IP: Identification = 19380 IP: Flags = 0x4 IP: .1.. .... = do not fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 122 seconds/hops IP: Protocol = 6 (TCP) IP: Header checksum = 5ca8 IP: Source address = 208.178.66.12, 208.178.66.12 IP: Destination address = 208.178.117.2, Espresso.NEEBU.Net IP: No options IP: TCP: ----- TCP Header ----- TCP: TCP: Source port = 3082 TCP: Destination port = 80 (HTTP) TCP: Sequence number = 1100924065 TCP: Acknowledgement number = 2712346555 TCP: Data offset = 20 bytes TCP: Flags = 0x10 TCP: ..0. .... = No urgent pointer TCP: ...1 .... = Acknowledgement TCP: .... 0... = No push TCP: .... .0.. = No reset TCP: .... ..0. = No Syn TCP: .... ...0 = No Fin TCP: Window = 8760 TCP: Checksum = 0x6128 TCP: Urgent pointer = 0 TCP: No options TCP: HTTP: ----- HTTP: ----- HTTP: HTTP: "" HTTP: 0: 0800 209d e18a 0001 9624 c241 0800 4500 .. ......$.A..E. 16: 0028 4bb4 4000 7a06 5ca8 d0b2 420c d0b2 .(K.@.z.\...B... 32: 7502 0c0a 0050 419e c4a1 a1ab 1fbb 5010 u....PA.......P. 48: 2238 6128 0000 0000 0000 0000 "8a(........ -- /*====================[ Jake Khuon <khuon(a)GBLX.Net> ]======================+ | Chief Global Data Network Management Architect /~_ |_ () |3 /-\ |_ | | VOX: +1 (425) 391-2262 Fax: +1 (425) 391-6772 \_| C R O S S I N G | +=============[ 900 4th. Ave., Floor 12, Seattle, WA 98164 ]=============*/

6 8

worm blocker
by Joseph McDonald 18 Sep '01

18 Sep '01

Here is a little worm blocker I came up with. It runs like: tail -f $server_root/logs/error_log | blockworm.rb #!/usr/local/bin/ruby x = 0 badips = Hash.new(0) while line = gets if line =~ /root.ext|winnt|msadc|unrecognized FrontPage/i line =~ /client ([^\]].*)]/ bad = $1 bad.gsub!(/[^0-9\.]/, "") if not badips.has_key?(bad) system("/sbin/ipfw add 3000 unreach host tcp from #{bad} to any 80") $stderr.puts "killed #{bad}" end badips[$1] += 1 x += 1 end end I'm not positive that it's the best ipfw rule... I didn't know if "unreach" or "deny" was better. My ipfw guru is gone for the day. If anyone has any thoughts on that, please let me know. Also, the above assumes that IP "spoofing" isn't going on... BTW, if you want to run the above and don't have ruby, you can get it at: http://www.ruby-lang.org/en/index.html It is a way cool language, the snippet above does not show off any of its unique features, a summary of which you can find here: http://www.pragmaticprogrammer.com/talks/introruby/img1.htm regards, -joe

1 0

Issues at AADS
by Mitchell Rose 18 Sep '01

18 Sep '01

is anyone else experiencing packet loss and extremely variable ping times when pinging between peers? - Mitchell Rose

1 0

What Worked - What Didn't
by Sean Donelan 18 Sep '01

18 Sep '01

As the New York Stock market re-opens, and some things are returning to normal, I'd like to look at how well the Internet performed last week. At the Oakland NANOG I'd like to give a presentation about what worked, and what didn't work during the last week in regards to the Internet. I would like to gather what details I can from both small and large providers in New York, the rest of the USA, and even overseas about what they saw, what problems they experienced, and what things worked. You can send me private mail if you wish, with or without attribution. This is a personal effort, not assocated with my employer. Oakland NANOG is several weeks away, so I don't expect an immediate response. I expect many ISPs will be conducting their own internal reviews. But if you could, please consider responding. I'm looking for input from small, medium and large providers. Thank you. A few questions, all related to the time between Sept 11 and 17: 1. Briefly tell me who you are, and generally where your operations were located? 2. What worked? 3. What didn't work? 4. Did you activate your emergency response plan? 5. Were you required to do anything different operationally? Did you make preventive operational changes? 6. Were any infrastructure administration functions impaired, such as DNS registration, routing registry, address delegation? 7. Were you able to communicate NOC-to-NOC when needed? 8. Were any means of communications nonfunctional or impaired (direct dial telephone, toll-free telephone, pager, e-mail, fax) when you attempted to communicate with other NOC's? 9. Did you ask for or receive a request for mutual aid from any other providers? Was it provided? 10. Within the limits of safety and rescue efforts, where you able to gain access to your physical facilities? 11. Did hoaxes or rumors impact your operations? 12. Do you have any recommendations how Internet providers could have responded differently?

20 34

RE: What Worked - What Didn't
by Roeland Meyer 18 Sep '01

18 Sep '01

|> From: Randy Bush [mailto:randy@psg.com] |> Sent: Monday, September 17, 2001 1:45 PM |> inter-isp peering and intra-isp ibgp to be covered fairly quickly. i |> would suggest having one's provisioning folk working with |> bgp customers |> to close that avenue as well, starting with the more |> critical customers. |> |> also, think about your igp. Why, IGP shouldn't even be visible from outside the border, neh? Internal issues are, internal issues. If it leaks, plug the leak.

4 3

Nimda Worm
by Mike Jackson 18 Sep '01

18 Sep '01

One of the spread methods has to do with retrieving a file called "readme.eml" from the infected web servers. Adding this to my Cisco HBAR code red config seems to at least keep my customers from becoming infected using that method. class-map match-any http-hacks .. code red stuff.. match protocol http url "*readme.eml" Can anyone confirm exactly what filenames the email spread version uses? -- Mike Jackson <mhjack(a)tscnet.com> Vice-President TSCNet, Inc. Phone: 360-308-0205 Fax: 360-698-7789 http://www.tscnet.com

1 0