March 2003 - Test - lists.nanog.org

Req contact: "Kindhosts", PA
by Avleen Vig 15 Mar '03

15 Mar '03

Any admins from Kindhosts in PA here? -- Avleen Vig "Say no to cheese-eating surrender-monkeys" Systems Admin "Fast, Good, Cheap. Pick any two." www.silverwraith.com "Move BSD. For great justice!"

1 0

RE: 923Mbits/s across the ocean
by Cottrell, Les 15 Mar '03

15 Mar '03

Also as the OS's are shipped they come with small default maximum window sizes (I think Linux is typically 64KB and Solaris is 8K), and so one has to get the sysadmin with root privs to change this. -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Sunday, March 09, 2003 5:25 AM To: Joe St Sauver Cc: nanog(a)nanog.org Subject: Re: 923Mbits/s across the ocean On Sat, 8 Mar 2003, Joe St Sauver wrote: > you will see that for bulk TCP flows, the median throughput is still > only 2.3Mbps. 95th%-ile is only ~9Mbps. That's really not all that > great, throughput wise, IMHO. Strange. Why is that? RFC 1323 is widely implemented, although not widely enabled (and for good reason: the timestamp option kills header compression so it's bad for lower-bandwidth connections). My guess is that the OS can't afford to throw around MB+ size buffers for every TCP session so the default buffers (which limit the windows that can be used) are relatively small and application programmers don't override the default.

5 6

[Q] Stable Service Provider IOS Version?
by Matt Martini 15 Mar '03

15 Mar '03

nanog: I have to upgrade some 7513 routers running Service Provder IOS. I'd like to know what code have people been using that has proved stable as well as versions to stay away from. Thanks Matt __________________________ http://www.invision.net/ _______________________ Matthew E. Martini, PE InVision.com, Inc. (631) 543-1000 x104 Chief Technology Officer matt(a)invision.net (631) 864-8896 Fax _______________________________________________________________________pgp_

2 1

[Fwd: FC: Email a RoadRunner address, get scanned by their securitysystem]
by William Allen Simpson 15 Mar '03

15 Mar '03

-------- Original Message -------- Subject: FC: Email a RoadRunner address, get scanned by their securitysystem Date: Fri, 14 Mar 2003 15:25:46 -0500 From: Declan McCullagh <declan(a)well.com> Reply-To: declan(a)well.com To: politech(a)politechbot.com --- Date: Fri, 14 Mar 2003 15:22:24 -0500 Subject: RoadRunner Automated Portscans From: Gunnar Hellekson <gunnar(a)onepeople.org> To: declan(a)well.com After sending an email to a friend at a RoadRunner address, I see this in my web access log: 24.30.199.228 - - [13/Mar/2003:15:11:25 -0500] "CONNECT security.rr.com:25 HTTP/1.0" 404 535 "" "" Basically, RoadRunner tried to spam themselves using my server. I mailed abuse(a)rr.com about this, and received a canned response, enclosed. It's a humble response, but woefully inadequate. Have anti-spam measures come to this? This seems like an ill-considered compromise between privacy and anti-spam efforts. A blunt instrument that betrays less-than-careful thinking. The opt-out option, which was revealed only after my complaint, is even more obnoxious. Under their logic, I feel entitled to poke and prod their customers, just to make sure they don't spam me. Is that fair? I promise to provide an opt-out if anyone complains. I'm curious whether this preemptive measure is effective at all. -Gunnar >From: "Road Runner Security \[DSR\]" <abuse(a)rr.com> >Date: Fri Mar 14, 2003 2:05:12 PM America/New_York >Subject: Re: Port scans? > >Hello, > >The securityscan.sec.rr.com machine is a Road Runner Security resource that >is used as a tool to assist us in determining if machines being used to >send us mail may be abused from outside sources, allowing them to be used >to spam our customers and role accounts. We fully understand your concerns >surrounding the probing of your machine. This issue has been raised >internally and we hope this email helps you better understand our process. > >The intention of this process is truly not meant to be a "big brother" >system, but we understand that some may view it as such. Our ultimate goal, >however, is to protect our network, our customers, and our role accounts. > >Road Runner has begin the REACTIVE testing of IP addresses which connect >to its inbound SMTP gateways. If your machine connects to ours to send >email, we reserve the absolute right to perform SMTP relay and open proxy >server tests upon the connecting IP address to ensure that the machine at >that IP address cannot be abused for malicious > purposes. > >These scans are done once per week per IP, via an automated process, and >only on those servers that have sent our subscriber base mail. The only >way for these tests to occur is if an IP address connects to our inbound >SMTP gateway. If found to be an open proxy or smtp relay, the IP address >will be blocked at our mail gateway borders with one of the following >error messages: > >ERROR:5.7.1:550 Mail Refused - See >http://security.rr.com/mail_blocks.htm#proxy >ERROR:5.7.1:550 Mail Refused - See >http://security.rr.com/mail_blocks.htm#relay > >We understand that some entities may not wish to be scanned as part of this >automated process. If you do not wish to be tested by Road Runner, there >are two ways to accomplish this: > >1. Send an e-mail to 'donottest(a)security.rr.com' with the IP address that >you do not wish to be tested. Please note that if you are not the >designated contact for your IP address range (for example, if you are on a >cable modem, DSL, or dialup range), we will be unable to fulfill your >request for addition or removal. >2. Do not connect to our inbound SMTP servers. Again, this test is only >conducted on servers that connect to our servers. > >If you have any further questions, you can visit http://security.rr.com or >contact Road Runner Security via e-mail at 'spamblock(a)security.rr.com' > >Regards, >Road Runner Security ------------------------------------------------------------------------- POLITECH -- Declan McCullagh's politics and technology mailing list You may redistribute this message freely if you include this notice. To subscribe to Politech: http://www.politechbot.com/info/subscribe.html This message is archived at http://www.politechbot.com/ Like Politech? Make a donation here: http://www.politechbot.com/donate/ ------------------------------------------------------------------------- Declan McCullagh's photographs are at http://www.mccullagh.org/ -------------------------------------------------------------------------

7 7

* * * SECURITY UPDATE * * * MRLG-4.2.4 Released * * * (fwd)
by John Payne 15 Mar '03

15 Mar '03

Forwarded by request. ---------- Forwarded Message ---------- * * * SECURITY UPDATE FOR MULTI-ROUTER LOOKING GLASS * * * A vulnerability has been discovered by the EnterZone staff in Multi-Router Looking Glass versions 4.2.2 and 4.2.3. Vulnerability: If the MRLG admin has specified "$::output_before_menu = 1;" in mrlg.conf, remote users are able execute MRLG commands on password (MRLG password) protected routers that have been configured. This vulnerability does not effect users who have not specified "$::output_before_menu = 1;" in mrlg.conf or MRLG versions prior to 4.2.2. Fix: Upgrade to MRLG-4.2.4, available for immediate download at: ftp://ftp.enterzone.net/looking-glass/CURRENT/ Alternately, users running MRLG-4.2.3 may patch their MRLG to version 4.2.4 with the following patch: *** index.cgi Wed Nov 27 01:23:57 2002 --- index.cgi.new Fri Mar 14 23:11:16 2003 *************** no warnings "once"; *** 8,10 **** ! $::Version='4.2.3 Beta (IPv6)'; --- 8,10 ---- ! $::Version='4.2.4 Beta (IPv6)'; *************** set_router(); *** 150,154 **** --- 150,162 ---- + if ($::Form{'pass1'} eq $::Routers{$::Form{'router'}}{'pass'}) + { if ($::output_before_menu) { + ## Set up which command is to be executed (and then execute it!) set_command(); + } + } + else + { + print "INVALID PASSWORD! "; } ---------- End Forwarded Message ----------

1 0

RE: 69/8...this sucks -- Centralizing filtering..
by Todd A. Blank 14 Mar '03

14 Mar '03

I continue to agree that moving critical resources (see below) to these new blocks is the best approach I have seen or heard in the months since I made the original post. This approach punishes the clueless instead of the people that already know what the problem is (and have to live with it every day). I can't begin to calculate the amount of support time we have burned contacting the offending networks. I know the cost has been prohibitive at best. I have seen this suggestion once before (maybe even by Jon) and I still think it is the best way things will get resolved quickly. Maybe we should suggest that ARIN also host some of their stuff on this block :-) Todd IPOutlet LLC -----Original Message----- From: jlewis(a)lewis.org [mailto:jlewis@lewis.org] Sent: Monday, March 10, 2003 12:52 PM To: E.B. Dreger Cc: nanog(a)merit.edu Subject: RE: 69/8...this sucks -- Centralizing filtering.. On Mon, 10 Mar 2003, E.B. Dreger wrote: > Now, how can we force that? Sufficient reward for doing so, or > pain for failure. Evidently "some people can't reach you" isn't > enough pain, and having full reachability isn't enough reward. I think the only way that's relatively guaranteed to be effective is to move a critical resource (like the gtld-servers) into new IP blocks when previously reserved blocks are assigned to RIR's. I still have a couple hundred thousand IPs to check (I'm going to step up the pace and see if I can get through the list today), but I already have a list of several hundred IPs in networks that ignore 69/8. The list includes such networks as NASA, the US DoD, and networks in China, Russia, and Poland. Those are just a few that I've done manual whois's for. I haven't decided yet whether I'll send automated messages to all the broken networks and give them time to respond and fix their filters, or just post them all to NANOG when the list is complete. Are people interested in seeing the full list (at least the ones I find) of networks that filter 69/8? Does Atlantic.Net get an ARIN discount for doing all this leg work? :) ---------------------------------------------------------------------- Jon Lewis *jlewis(a)lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

10 15

RE: DSL-IP Probes Curiousity..
by McBurnett, Jim 14 Mar '03

14 Mar '03

> There is so much of it, I liken it to Internet background > radiation. In > fact, if I didnt see a constant stream of this (either by > accident-- SNMP > auto discovery, or design-- lets find all the 'private' routers and > switches out there) I would be more worried as my network > probably has been > blackholed! Good Point!! > > In terms of reporting it, I usually do if its more than just > some automated > probe and is a directed attack against a particular device > and is causing > some grief or potential grief. But it would be a full time > job evaluating > and responding to each and every scan/hack attempt as the > volume is way too > high. I think something like dshield is going in the right > direction. > Ultimately if these things are not reported and the people doing them > sanctioned somehow, it wont stop. Yeah, If a dshield type system is used and the ISP's can use that to add to the Abuse reports.. That would be great! > Also, its March Break in many parts of North America... More > time to do > these sorts of things. > Yeah, and don't forget spring exams in the AP Rim... That is always bad too.... J

1 0

The Cidr Report
by cidr-report＠potaroo.net 14 Mar '03

14 Mar '03

This report has been generated at Fri Mar 14 21:45:21 2003 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 07-03-03 120289 86148 08-03-03 120272 86188 09-03-03 120197 86257 10-03-03 120223 86324 11-03-03 120475 86388 12-03-03 120508 86345 13-03-03 120478 86334 14-03-03 120659 86376 AS Summary 14740 Number of ASes in routing system 5812 Number of ASes announcing only one prefix 1562 Largest number of prefixes announced by an AS AS701 : ALTERNET-AS UUNET Technologies, Inc. 73048064 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 14Mar03 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 120741 86391 34350 28.4% All ASes AS3908 1097 537 560 51.0% SUPERNETASBLK SuperNet, Inc. AS18566 518 25 493 95.2% COVAD Covad Communications AS701 1562 1129 433 27.7% ALTERNET-AS UUNET Technologies, Inc. AS4151 535 109 426 79.6% USDA-1 USDA AS7843 600 217 383 63.8% ADELPHIA-AS Adelphia Corp. AS4323 555 173 382 68.8% TW-COMM Time Warner Communications, Inc. AS7018 1372 1021 351 25.6% ATT-INTERNET4 AT&T WorldNet Services AS6197 499 160 339 67.9% BATI-ATL BellSouth Network Solutions, Inc AS1221 1101 805 296 26.9% ASN-TELSTRA Telstra Pty Ltd AS1239 974 690 284 29.2% SPRINTLINK Sprint AS22927 295 14 281 95.3% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS4355 391 119 272 69.6% ERMS-EARTHLNK EARTHLINK, INC AS705 449 195 254 56.6% ASN-ALTERNET UUNET Technologies, Inc. AS6198 451 200 251 55.7% BATI-MIA BellSouth Network Solutions, Inc AS4814 264 15 249 94.3% CHINANET-BEIJING-AP China Telecom (Group) AS1 656 431 225 34.3% GNTY-1 Genuity AS17676 230 27 203 88.3% GIGAINFRA XTAGE CORPORATION AS2386 480 280 200 41.7% INS-AS AT&T Data Communications Services AS6347 370 171 199 53.8% DIAMOND SAVVIS Communications Corporation AS22291 242 45 197 81.4% CHARTER-LA Charter Communications AS4134 309 115 194 62.8% CHINANET-BACKBONE No.31,Jin-rong Street AS690 503 313 190 37.8% MERIT-AS-27 Merit Network Inc. AS209 530 341 189 35.7% ASN-QWEST Qwest AS27364 258 84 174 67.4% ACS-INTERNET Armstrong Cable Services AS2048 258 87 171 66.3% LANET-1 State of Louisiana AS17557 370 212 158 42.7% PKTELECOM-AS-AP Pakistan Telecom AS6140 292 140 152 52.1% IMPSAT-USA ImpSat AS22773 184 33 151 82.1% CCINET-2 Cox Communications Inc. Atlanta AS6327 187 40 147 78.6% SHAWFIBER Shaw Fiberlink Limited AS7303 242 98 144 59.5% AR-TAST-LACNIC Telecom Argentina Stet-France Telecom S.A. Total 15774 7826 7948 50.4% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

DSL-IP Probes Curiousity..
by McBurnett, Jim 14 Mar '03

14 Mar '03

Hello, I am just curious about this. I see a rather unusual # of SNMP queiries and port scans from DSL IP blocks in the US... How many of you really go after the script kiddies doing this? I know 1, 2 or even 3 a day is not a concern for me, but when I get 3 a day from the same source IP allocation, I start wondering... Will anyone answer this? I know you may not be able to comment due to legal concerns.. But I am curious.. Thanks, Jim

4 3

Re: DSL-IP Probes Curiousity..
by Mike Tancsa 14 Mar '03

14 Mar '03

At 05:19 PM 3/13/2003 -0500, McBurnett, Jim wrote: >Hello, >I am just curious about this. >I see a rather unusual # of SNMP queiries >and port scans from DSL >IP blocks in the US... > >How many of you really go after the script kiddies >doing this? > >I know 1, 2 or even 3 a day is not a concern for me, >but when I get 3 a day from the same source IP allocation, >I start wondering... There is so much of it, I liken it to Internet background radiation. In fact, if I didnt see a constant stream of this (either by accident-- SNMP auto discovery, or design-- lets find all the 'private' routers and switches out there) I would be more worried as my network probably has been blackholed! In terms of reporting it, I usually do if its more than just some automated probe and is a directed attack against a particular device and is causing some grief or potential grief. But it would be a full time job evaluating and responding to each and every scan/hack attempt as the volume is way too high. I think something like dshield is going in the right direction. Ultimately if these things are not reported and the people doing them sanctioned somehow, it wont stop. Also, its March Break in many parts of North America... More time to do these sorts of things. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike

1 0