- NANOG - lists.nanog.org

a list of hosts in a RPC BOTNET, mostly 209.x.x.x,
by Drew Weaver 06 Aug '03

06 Aug '03

I've tried contacting abuse departments of several of these isps and none of them seem to care, so I figured I would post the info here, and maybe someone will let them know, the biggest offender is atlantech. These are all hosts that have been compromised by the same person, they're being used to SYN flood 65.110.34.100 If you want to see this glorious channel for your self its called #!LPOL! on Undernet. Basically the way this works is your box gets attacked, then it sits on this irc channel and waits for commands, in this case the command is !SYN 65.110.34 1000 6667 9999 -s Anyways here is the list, and every 30 seconds or so 2 or 3 more jump into this room.. the botnet is growing! #!LPOL! Jessica74 H Peter90(a)adsl-209-204-181-32.sonic.net :3 Jessica743071 #!LPOL! Claire272 H ~Claire272(a)80-192-182-73.cable.ubr05.wi.blueyonder.co.uk #!LPOL! Sophia554 H ~Sophia554(a)209.195.200.6 :3 Sophia554325 #!LPOL! Chloe9013 H Karolina80(a)209.202.78.152 :3 Chloe901312 #!LPOL! Sydney542 H Mariah0494(a)209.191.9.227 :3 Sydney542199 #!LPOL! Elsa12423 H Angelina42(a)15.shnt4.xdsl.nauticom.net :3 Elsa124230 #!LPOL! Minki7099 H Zoe756815(a)209.194.190.16 :3 Minki709990 #!LPOL! Makayla57 H Natalie572(a)209.195.218.54 :3 Makayla574543 #!LPOL! Leslie525 H Svala28188(a)pppoe-64-91-70-20.rb.lax.centurytel.net :3 Leslie525606 #!LPOL! Autumn319 H Grace99989(a)AC9F6DA8.ipt.aol.com :3 Autumn319583 #!LPOL! Samantha3 H Autumn9932(a)host25.brooksml-2.cust.sover.net :3 Samantha394828 #!LPOL! Yamilla15 H Claire4282(a)host26.brooksml-2.cust.sover.net :3 Yamilla150205 #!LPOL! Grace2018 H Adriana488(a)8.svnf1.xdsl.nauticom.net :3 Grace201892 #!LPOL! Lujan7794 H Josie11923(a)a5.c3bed1.client.atlantech.net :3 Lujan779454 #!LPOL! Minki7888 H Victoria72(a)ep190.ips.PaulBunyan.net :3 Minki788839 #!LPOL! Briana185 H Alyssa5638(a)209.205.172.43 :3 Briana185975 #!LPOL! Angela274 H Laura15269(a)host33.brooksml-2.cust.sover.net :3 Angela274842 #!LPOL! Anna79907 H Madeline32(a)user-101.city.urbana.il.us :3 Anna799072 #!LPOL! Sung42146 H ~Sung42146(a)216.13.67.57 :3 Sung421466 #!LPOL! Estella68 H Daniela968(a)209.198.126.76 :3 Estella680044 #!LPOL! Jenna5293 H Adriana023(a)209.202.78.179 :3 Jenna529394 #!LPOL! Courtney6 H Chloe43907(a)209.190.200.152 :3 Courtney697581 #!LPOL! Caroline5 H Melissa162(a)d-191-144-nospr3.i-55.com :3 Caroline527031 #!LPOL! Shannon50 H ~Shannon50(a)209.201.28.156 :3 Shannon505552 #!LPOL! Beyonce82 H Olivia5920(a)209.189.232.237 :3 Beyonce828929 #!LPOL! Kelsey198 H Alyssa5678(a)209.203.75.134 :3 Kelsey198278 #!LPOL! Nicole203 H Julia74311(a)209.189.250.214 :3 Nicole203361 #!LPOL! Jasmine27 H Andrea3792(a)dsl-132-ndcr2.i-55.com :3 Jasmine270357 #!LPOL! Niki68912 H Grace06891(a)9.e1bed1.client.atlantech.net :3 Niki689129 #!LPOL! Bailey427 H ~Bailey427(a)d3.e8bed1.client.atlantech.net :3 Bailey427581 #!LPOL! Emily9352 H Morena9837(a)a4.e3bed1.client.atlantech.net :3 Emily935216 #!LPOL! Nicole893 H Isabella19(a)pc66.cbk.gov.kw :3 Nicole893482 #!LPOL! Hannah294 H ~Hannah294(a)209.189.244.252 :3 Hannah294622 #!LPOL! Savannah7 H Sierra3410(a)d-174-51-nospr3.i-55.com :3 Savannah707812 #!LPOL! Marissa29 H ~Marissa29(a)host210.terransolutions.com :3 Marissa298910 #!LPOL! Marissa89 H Laura07290(a)www.bdrtransport.com :3 Marissa898535 #!LPOL! Shakira76 H user14(a)209.202.78.118 :3 Shakira762665 #!LPOL! Jenna8438 H ~Jenna8438(a)d-173-32-nospr2.i-55.com :3 Jenna843871 #!LPOL! Ashley377 H Faith87547(a)19.crcr6.xdsl.nauticom.net :3 Ashley377799 #!LPOL! Andrea434 H Elizabeth9(a)209.202.78.59 :3 Andrea434270 #!LPOL! Jessica49 H Yamilla634(a)cp209-202-78-157.cp.telus.net :3 Jessica494079 #!LPOL! Caitlin83 H Mackenzie6(a)5a.e1bed1.client.atlantech.net :3 Caitlin835383 #!LPOL! Denise777 H Molly48369(a)df.ebbed1.client.atlantech.net :3 Denise777131 #!LPOL! Nicole948 H Aaliyah253(a)209.183.203.7 :3 Nicole948345 #!LPOL! Haley0390 H Leslie5962(a)b5.e2bed1.client.atlantech.net :3 Haley039010 #!LPOL! Samantha1 H Lauren9830(a)209.178.193.220 :3 Samantha151353 #!LPOL! Niki13026 H Kimberly97(a)a7.c8bed1.client.atlantech.net :3 Niki130268 I hope this isn't off topic. -Drew

7 7

Earthlink and/or o1.com in the house?
by Christopher Chin 06 Aug '03

06 Aug '03

Hello folks, If Earthlink or o1.com are represented here, could you please contact me offlist? Thanks, - Christopher ======================

1 0

Stats of Internet connection speeds
by Minseok Kwon 06 Aug '03

06 Aug '03

Can anyone tell me where I can get the recent statistics of Internet connection speeds? Specifically, I need statistics for edge link bandwidth (e.g., what's the percentage of 56kbps lines?) Thanks a million. M. S. Kwon

2 1

RE: Server Redundancy
by Ejay Hire 06 Aug '03

06 Aug '03

It really depends on the application. I've seen a couple of boxes (IIRC, the one that the client bought was from cisco) that do "sticky" load balancing that associates the source address with the NAT translation and does round-robin nat to several internal servers... Come to think of it, most services depend on some sort of round-robin NAT. Can you tell us a little more about your application? -e -----Original Message----- From: Jason Greenberg [mailto:jg@execulink.com] Sent: Wednesday, August 06, 2003 12:36 PM To: nanog(a)merit.edu Subject: Server Redundancy Can I have some suggestions on how to load balance servers that are on seperate IP blocks? Is there any way to perform translation at this level? Exclude DNS based balancing please... -- Jason Greenberg, CCIE #11021 Network Administrator Execulink, Inc. <jg(a)execulink.com>

1 0

SBL soon only from sbl.spamhaus.org
by Steve Linford 06 Aug '03

06 Aug '03

If you currently use the SBL by querying the master zone sbl.spamhaus.org then you can ignore this message. If you are using the SBL via 3rd party composite DNSBLs and not directly from sbl.spamhaus.org, then please read this as the following change affects your DNSBL setup. For a long time the SBL has been available either directly from Spamhaus (as sbl.spamhaus.org) or via 3rd party composite zones such as relays.osirusoft.com (as spamhaus.relays.osirusoft.com) and blackholes.easynet.nl which import SBL data from Spamhaus. This distribution is now changing. In order to better manage SBL logistics, DNSBL zone and query traffic, from Monday 11 August 2003 the SBL should only be available from sbl.spamhaus.org. The fact the SBL was available from multiple DNSBLs was causing some confusion, plus other small factors (such as the different zones having different build times - which for example meant that we'd tell someone an IP had been removed, but they'd contact us a few hours later to say it was still blocked), plus the likely emergence of further composite lists which may add confusion, meant that it was time to make a change now rather than in a year or two. So, if you are not using sbl.spamhaus.org but would like to continue using the SBL, please add sbl.spamhaus.org to your mail server's DNSBL list. -- Steve Linford The Spamhaus Project http://www.spamhaus.org

1 0

RE: a list of hosts in a RPC BOTNET, mostly 209.x.x.x,
by Michel Py 06 Aug '03

06 Aug '03

> The controlling node for this problem seems to be: > spaley spale(a)le.seul.ircop.a.cul.nu For the entertainment on non French-speaking nanogers, the literal translation is: Spaley space(a)the.only.ircop.with.a.naked.ass Excuse my French. Michel.

1 0

Re: WANTED: ISPs with DDoS defense solutions
by Michael.Dillon＠radianz.com 06 Aug '03

06 Aug '03

>> How would the spoofing program, or its user, be able to tell if >> it was successful? Unless I'm very confused, the definition of >> spoofing is that the return packets aren't going to come back to you. >the whole thing would have to take place during a tcp control session >which used d-h to scramble itself, sort of the same way ssh does. Diffie-Hellmann is a bit overkill. It's simpler to have the client open a TCP connection to the server, retrieve a token which is just some reasonable number of random bits like 64, then send the token back in a set of UDP packets using spoofed addresses, then pause for a second or two and ask the server (through the TCP connection) whether it saw the spoofed packets. Three UDP packets should be enough to eliminate most packet loss scenarios and the spoofed address could be chosen by munging the first octet to a number from 44 to 54. That's enough for the server to collect stats and to provide a status report to the client. If the client is behind a NAT, and the spoofed source address doesn't get through, then that's OK because it means that no application in that same location behind the NAT can use spoofed addresses. --Michael Dillon

2 1

Is Anyone Seeing Packet Loss To Savvis?
by Peter Rohrman 06 Aug '03

06 Aug '03

I'm getting ICMP timeouts to 2 destinations that on are on Savvis. Is anyone else seeing it? I don't have packet loss to anything else. Below is my ping to www.savvis.net and a customer that I have masked to protect the innocent :). MUSKET:8:36:56am/export/home/pete:ping -s www.savvis.net PING www.savvis.net: 56 data bytes 64 bytes from 216.91.182.42: icmp_seq=0. time=67. ms 64 bytes from 216.91.182.42: icmp_seq=1. time=68. ms 64 bytes from 216.91.182.42: icmp_seq=2. time=68. ms 64 bytes from 216.91.182.42: icmp_seq=3. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=4. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=5. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=6. time=64. ms 64 bytes from 216.91.182.42: icmp_seq=7. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=8. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=9. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=10. time=68. ms 64 bytes from 216.91.182.42: icmp_seq=11. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=12. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=13. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=14. time=73. ms ICMP Time exceeded in transit from dsl092-097-001.nyc2.dsl.speakeasy.net (66.92.97.1) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33434 ICMP Time exceeded in transit from dsl092-097-001.nyc2.dsl.speakeasy.net (66.92.97.1) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33435 ICMP Time exceeded in transit from dsl092-097-001.nyc2.dsl.speakeasy.net (66.92.97.1) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33436 ICMP Time exceeded in transit from border28.g3-2.speakeasy-26.nyc.pnap.net (209.191.132.48) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33437 ICMP Time exceeded in transit from border28.g3-2.speakeasy-26.nyc.pnap.net (209.191.132.48) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33438 ICMP Time exceeded in transit from border28.g3-2.speakeasy-26.nyc.pnap.net (209.191.132.48) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33439 ICMP Time exceeded in transit from core1.ge3-0-bbnet2.nyc.pnap.net (209.191.128.129) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33440 64 bytes from 216.91.182.42: icmp_seq=15. time=2063. ms ICMP Time exceeded in transit from core1.ge3-0-bbnet2.nyc.pnap.net (209.191.128.129) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33441 ICMP Time exceeded in transit from core1.ge3-0-bbnet2.nyc.pnap.net (209.191.128.129) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33442 ICMP Time exceeded in transit from sl-bb12-nyc-8-0.sprintlink.net (160.81.48.17) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33443 ICMP Time exceeded in transit from sl-bb12-nyc-8-0.sprintlink.net (160.81.48.17) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33444 ICMP Time exceeded in transit from sl-bb12-nyc-8-0.sprintlink.net (160.81.48.17) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33445 ICMP Time exceeded in transit from sl-bb26-nyc-15-1.sprintlink.net (144.232.7.125) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33446 64 bytes from 216.91.182.42: icmp_seq=16. time=3461. ms ICMP Time exceeded in transit from sl-bb26-nyc-15-1.sprintlink.net (144.232.7.125) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33447 ICMP Time exceeded in transit from sl-bb26-nyc-15-1.sprintlink.net (144.232.7.125) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33448 ICMP Time exceeded in transit from sl-bb22-nyc-6-0.sprintlink.net (144.232.7.42) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33449 ICMP Time exceeded in transit from sl-bb22-nyc-6-0.sprintlink.net (144.232.7.42) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33450 ICMP Time exceeded in transit from sl-bb22-nyc-6-0.sprintlink.net (144.232.7.42) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33451 ICMP Time exceeded in transit from sl-bb21-chi-9-0.sprintlink.net (144.232.9.149) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33452 64 bytes from 216.91.182.42: icmp_seq=17. time=4865. ms ICMP Time exceeded in transit from sl-bb21-chi-9-0.sprintlink.net (144.232.9.149) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33453 ICMP Time exceeded in transit from sl-bb21-chi-9-0.sprintlink.net (144.232.9.149) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33454 ICMP Time exceeded in transit from sl-gw31-chi-10-0.sprintlink.net (144.232.26.30) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33455 ICMP Time exceeded in transit from sl-gw31-chi-10-0.sprintlink.net (144.232.26.30) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33456 ICMP Time exceeded in transit from sl-gw31-chi-10-0.sprintlink.net (144.232.26.30) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33457 ICMP Time exceeded in transit from sl-savvis-16-0.sprintlink.net (144.228.154.178) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33458 64 bytes from 216.91.182.42: icmp_seq=18. time=6285. ms ICMP Time exceeded in transit from sl-savvis-16-0.sprintlink.net (144.228.154.178) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33459 ICMP Time exceeded in transit from sl-savvis-16-0.sprintlink.net (144.228.154.178) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33460 64 bytes from 216.91.182.42: icmp_seq=19. time=6081. ms 64 bytes from 216.91.182.42: icmp_seq=20. time=5081. ms 64 bytes from 216.91.182.42: icmp_seq=21. time=4081. ms 64 bytes from 216.91.182.42: icmp_seq=22. time=3082. ms 64 bytes from 216.91.182.42: icmp_seq=23. time=2082. ms 64 bytes from 216.91.182.42: icmp_seq=24. time=1082. ms 64 bytes from 216.91.182.42: icmp_seq=25. time=82. ms 64 bytes from 216.91.182.42: icmp_seq=26. time=64. ms 64 bytes from 216.91.182.42: icmp_seq=27. time=68. ms 64 bytes from 216.91.182.42: icmp_seq=28. time=68. ms 64 bytes from 216.91.182.42: icmp_seq=29. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=30. time=68. ms 64 bytes from 216.91.182.42: icmp_seq=31. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=32. time=64. ms 64 bytes from 216.91.182.42: icmp_seq=33. time=64. ms 64 bytes from 216.91.182.42: icmp_seq=34. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=35. time=64. ms 64 bytes from 216.91.182.42: icmp_seq=36. time=68. ms 64 bytes from 216.91.182.42: icmp_seq=37. time=68. ms 64 bytes from 216.91.182.42: icmp_seq=38. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=39. time=70. ms 64 bytes from 216.91.182.42: icmp_seq=40. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=41. time=64. ms 64 bytes from 216.91.182.42: icmp_seq=42. time=64. ms 64 bytes from 216.91.182.42: icmp_seq=43. time=66. ms ^C ----www.savvis.net PING Statistics---- 44 packets transmitted, 44 packets received, 0% packet loss round-trip (ms) min/avg/max = 64/919/6285 MUSKET:8:59:34am/export/home/pete: MUSKET:8:46:35am/export/home/pete:ping -s CustXOn.savvis PING CustXOn.savvis: 56 data bytes 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=0. time=49. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=1. time=100. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=2. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=3. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=4. time=102. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=5. time=122. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=6. time=56. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=7. time=50. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=8. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=9. time=45. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=10. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=11. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=12. time=50. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=13. time=50. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=14. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=15. time=51. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=16. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=17. time=78. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=18. time=52. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=19. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=20. time=76. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=21. time=45. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=22. time=56. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=23. time=44. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=24. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=25. time=50. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=26. time=66. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=27. time=70. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=28. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=29. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=30. time=52. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=31. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=32. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=33. time=52. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=34. time=58. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=35. time=62. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=36. time=72. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=37. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=38. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=39. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=40. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=41. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=42. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=43. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=44. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=45. time=58. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=46. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=47. time=44. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=48. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=49. time=76. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=50. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=51. time=58. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=52. time=54. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=53. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=54. time=58. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=55. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=56. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=57. time=60. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=58. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=59. time=98. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=60. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=61. time=56. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=62. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=63. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=64. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=65. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=66. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=67. time=64. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=68. time=51. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=69. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=70. time=76. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=71. time=50. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=72. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=73. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=74. time=51. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=75. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=76. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=77. time=50. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=78. time=47. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=79. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=80. time=51. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=81. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=82. time=47. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=83. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=84. time=47. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=85. time=44. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=86. time=73. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=87. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=88. time=99. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=89. time=58. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=90. time=57. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=91. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=93. time=50. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=101. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=102. time=47. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=103. time=44. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=104. time=45. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=105. time=57. ms ICMP Time exceeded in transit from dsl092-097-001.nyc2.dsl.speakeasy.net (66.92.97.1) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33434 ICMP Time exceeded in transit from dsl092-097-001.nyc2.dsl.speakeasy.net (66.92.97.1) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33435 ICMP Time exceeded in transit from dsl092-097-001.nyc2.dsl.speakeasy.net (66.92.97.1) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33436 ICMP Time exceeded in transit from border28.g3-2.speakeasy-26.nyc.pnap.net (209.191.132.4 8) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33437 ICMP Time exceeded in transit from border28.g3-2.speakeasy-26.nyc.pnap.net (209.191.132.4 8) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33438 ICMP Time exceeded in transit from border28.g3-2.speakeasy-26.nyc.pnap.net (209.191.132.4 8) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33439 ICMP Time exceeded in transit from core4.fe0-0-fenet1.nyc.pnap.net (209.191.128.72) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33440 ICMP Time exceeded in transit from core4.fe0-0-fenet1.nyc.pnap.net (209.191.128.72) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33441 ICMP Time exceeded in transit from core4.fe0-0-fenet1.nyc.pnap.net (209.191.128.72) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33442 ICMP Time exceeded in transit from p3-2.nycmny1-cr11.bbnplanet.net (4.25.14.17) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33443 ICMP Time exceeded in transit from p3-2.nycmny1-cr11.bbnplanet.net (4.25.14.17) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33444 ICMP Time exceeded in transit from p3-2.nycmny1-cr11.bbnplanet.net (4.25.14.17) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33445 ICMP Time exceeded in transit from p3-0.nycmny1-nbr1.bbnplanet.net (4.24.10.78) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33446 ICMP Time exceeded in transit from p3-0.nycmny1-nbr1.bbnplanet.net (4.24.10.78) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33447 ICMP Time exceeded in transit from p3-0.nycmny1-nbr1.bbnplanet.net (4.24.10.78) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33448 ICMP Time exceeded in transit from so-5-1-0-100.bbr1.nyc1.Level3.net (64.159.4.61) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33449 ICMP Time exceeded in transit from so-5-1-0-100.bbr1.nyc1.Level3.net (64.159.4.61) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33450 ICMP Time exceeded in transit from so-5-1-0-100.bbr1.nyc1.Level3.net (64.159.4.61) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33451 ICMP Time exceeded in transit from gigabitethernet2-1.core1.NewYork1.Level3.net (64.159.1 7.69) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33452 ICMP Time exceeded in transit from gigabitethernet2-1.core1.NewYork1.Level3.net (64.159.1 7.69) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33453 ICMP Time exceeded in transit from gigabitethernet2-1.core1.NewYork1.Level3.net (64.159.1 7.69) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33454 ICMP Time exceeded in transit from savvis-level3-oc3.NewYork1.Level3.net (209.244.160.174 ) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33455 ICMP Time exceeded in transit from savvis-level3-oc3.NewYork1.Level3.net (209.244.160.174 ) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33456 ICMP Time exceeded in transit from savvis-level3-oc3.NewYork1.Level3.net (209.244.160.174 ) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33457 ICMP Time exceeded in transit from savvis-pnet3.cntx13.usnycm4-bsn.savvis.net (66.100.79. 86) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33458 ICMP Time exceeded in transit from savvis-pnet3.cntx13.usnycm4-bsn.savvis.net (66.100.79. 86) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33459 ICMP Time exceeded in transit from savvis-pnet3.cntx13.usnycm4-bsn.savvis.net (66.100.79. 86) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33460 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=121. time=43. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=122. time=49. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=123. time=47. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=124. time=45. ms ^C ----CustXOn.savvis PING Statistics---- 130 packets transmitted, 102 packets received, 21% packet loss round-trip (ms) min/avg/max = 43/53/122 MUSKET:8:48:51am/export/home/pete: MUSKET:9:24:25am/export/home/pete:

1 0

Chicago CFP Redux
by Susan Harris 06 Aug '03

06 Aug '03

Thanks to everyone who's already sent in a proposal for NANOG 29. (PS they're due Sept. 8). * * * * * * * * * * * * * * * * * CALL FOR PRESENTATIONS NANOG 29 GENERAL SESSION TUTORIALS CASE STUDIES RESEARCH FORUM October 19-21, 2003 * * * * * * * * * * * * * * * * * The North American Network Operators' Group (NANOG) will hold its 29th meeting October 19-21, 2003, at the Chicago Marriott Downtown Hotel. This will be NANOG's second joint meeting with ARIN, the American Registry for Internet Numbers (www.arin.net) NANOG will meet from Sunday to Tuesday, and ARIN from Wednesday to Friday, October 22-24. Registration opens September 2. NANOG conferences provide a forum for the coordination and dissemination of technical information related to backbone/enterprise networking technologies and operational practices. Meetings are held three times each year, and include two days of short presentations, plus afternoon/evening tutorial sessions. The meetings are informal, with an emphasis on relevance to current backbone engineering practices. NANOG conferences draw over 350 participants, mainly consisting of engineering staff from national service providers, and members of the research and education community. For more information about NANOG meetings, schedules, and logistics, see: http://www.nanog.org ------------------------------------------------------------------------------ CALL FOR PRESENTATIONS NANOG invites presentations on backbone/enterprise engineering, coordination, and research topics. Presentations should highlight issues relating to technology already deployed or soon to be deployed in core Internet backbones and exchange points. Vendors are encouraged to work with operators to present deployment experiences with the vendor's products. Researchers are invited to present short (10-minute) summaries of their work for operator feedback. Topics include routing, network performance, statistical measurement and analysis, and protocol development and implementation. Studies presented may be works in progress. Researchers from academia, government, and industry are encouraged to present. The community is invited to present talks on: -- Survey of open-source/commercial network management systems -- Operator experience/how-to's on building packet-switched networks (e.g., IP or MPLS) that can carry: - TDM - Layer 2 (e.g., Frame Relay and ATM) - IP services - Emerging services such as the Virtual Private LAN Service (VPLS). -- Operator case studies on: - Integration with optical control planes (GMPLS, ASON, etc.), voice (enterprise, Class 4 and Class 5), and video - Provisioning and automation - Enterprise network security, management, and route control - Network troubleshooting and problems solved -- Experience with active DoS retaliation methods, e.g., reverse port scanning. -- Implementation and use of measurement technologies in vendor devices Other potential topics include: -- Backbone traffic engineering -- Impact of BGP dynamics on backbone traffic patterns -- Route processor architecture -- Large-scale wireless deployment -- Building large-scale measurement infrastructure -- Inter-domain multicast deployment NANOG also welcomes suggestions/recommendations for tutorials, panels, and other presentation topics. ------------------------------------------------------------------------------ HOW TO PRESENT Submit a detailed abstract or outline describing the presentation in email to nanog-support(a)nanog.org. The deadline for proposals is September 8, 2003. While the majority of speaking slots will be filled by September 8, a limited number of slots will be available after that date for topics that are exceptionally timely and important. Submissions will be reviewed by the NANOG Program Committee, and presenters will be notified of acceptance by September 22. Final drafts of presentation slides are due by October 8, and final versions October 15. ---------------------------------------------------------------------------

1 0

Re: WANTED: ISPs with DDoS defense solutions
by Paul Vixie 06 Aug '03

06 Aug '03

> How would the spoofing program, or its user, be able to tell if > it was successful? Unless I'm very confused, the definition of > spoofing is that the return packets aren't going to come back to you. the whole thing would have to take place during a tcp control session which used d-h to scramble itself, sort of the same way ssh does. the random address/addresses would be chosen by the server. the only info the initiator would gain is a count of how many spoofed packets made it in; this could be left out if we feared that bad people would profit from being able to use this tester. (we don't, though, since they have their own ways of knowing whether spoofing is working from a given source, and we don't think they'd want us to know what sources they were testing.) > I can imagine a packet format where the real source address was in the > data, but with no authentication this would itself be subject to abuse. > ... > Doing this from behind a NAT would be difficult. one hopes that a nat box would also complicate the lives of spoofers.

1 0