August 2001 - Test - lists.nanog.org

Re: Code Red 2 cleanup; reporting..
by Steven M. Bellovin 12 Aug '01

12 Aug '01

In message <Pine.LNX.4.10.10108100034440.14898-100000(a)home.highertech.net>, mik e harrison writes: > >> Spent nearly two days convincing someone who was managing a server that he >> was beating up machines all over the company. It finally took someone at > >Tonight, 20 minutes after openning up port 80 >on a firewall to a server supposedly only running >the latest CITRIX on Port 80 (why 80? Don't ask me?) >and the high paid out of town consultants swearing they >had applied the appropriate patches and were safe, >they are now broadcasting out the latest CodeRed style worm. > >I got some nice sniffit captures from my Linux firewall >though.. this morning will be interesting. I wonder >how they like their crow served. > > > > I've seen a report that the patch is not fully effective -- see http://archives.neohapsis.com/archives/incidents/2001-08/0218.html. That was on incidents.org last night, but it's gone this morning, so maybe that claim isn't accurate. --Steve Bellovin, http://www.research.att.com/~smb

3 2

RFC warz?
by Roeland Meyer 12 Aug '01

12 Aug '01

> From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] > Sent: Sunday, August 12, 2001 12:31 AM > On the other hand, we've had RFC1918 filtering wars recently - I don't > recall flame-fests about martian AS numbers lately ;) ... and there are RFC920 and RFC1591 warz. Frankly, it's *all* tiresome! Some of us need to get-a-life(tm).

1 0

RE: Affects of the balkanization of mail blacklisting
by Roeland Meyer 11 Aug '01

11 Aug '01

> From: Margie Arbon [mailto:margie@mail-abuse.org] > Sent: Saturday, August 11, 2001 11:42 AM > Subscribers are obligated contractually to maintain current > zone files. Yes, but does MAPS have the resources to enforce the contract?

3 2

SP's & network security issues
by Christian Kuhtz 11 Aug '01

11 Aug '01

Hey there, so, you want to be a good citizen and stewart of the inet. DDoS and security after security attack happens, it won't ever stop. You try to do the best you can to effectively respond to it. You try to inform you customers. You try to educate them. Yet, you realize that you're not doing enough... What do the rest of you SPs actually do to combat this threat? How do you keep the hype, fear, panic and dispair of your management team (all the way to the CEO) in check? And that of your customers? Some of it is sometimes warranted.. but, got any ideas for crowd control? In our case, we have several hundred thousands of DSL customers today, and the million plus subscriber mark is on the engineering horizon. The problem of security threats & resulting incidents is going to get considerably worse before it gets better. And that's for at least two reasons.. the ramp up of broadband and presumably the declining sophistication of the subscriber population as a result of the greater market penetration. Sure, you can try to teach your subscribers to protect themselves. But this is really not the answer. How many unsophisticated subscribers are going to be able to do this in an effective and timely manner? What do you do in response? How do you effectively scale the massive support effort need for collaborative marketing of personal firewalls and the potential for false positives and negatives? Any ideas on the legal exposure of security services? Like, in the current case, several providers have resorted to blocking port 80 to their non-DIA subscriber base. Is this really scalable? Obviously not for every threat. You can't effectively keep this up with the myriad of threats. Or can you? Is it realistic to be able to maintain your own NIDS patterns with the help of your own staff and public resources? Are options like security service providers the only workable option? Do they work at all? How effective are they? IDS will obviously only work against known threats.. how do you create an effective early warning system? How do you provide effective vaccination against an unknown threat? How do you respond to potentially massive infections of your subscriber base? Potential zombie manifestations in the 100k's are easily possible. They really do make Code Red's impact to date seem more like a case of a mild flu than any serious infection. So, you do have a responsibility to your customers to protect them. To what extent is this realistic, though? Doesn't this also bear the risk of false security or even potential legal liabilities? How do you manage this risk? You do have also a responsibility to "protect" the rest of the world from zombie gatherings among your subscribers. Same questions apply. So, I think it's clear that something needs to be done, but coming up with a definitive plan of attack is everything but trivial. This obviously doesn't just apply to DSL, it applies to Cable and whatever other broadband networks are out there or will evolve... We want to be a good stewart and citizen of the inet, yet, these questions are tough to answer in any satisfactory way it seems. (Yes, I've taken some of these questions to various security forums from time to time, but none of them seem to represent a significant number of SPs; suggestions are very welcome). I'm sure this isn't a comprehensive list.. but, perhaps, it'll get a useful conversation going. Hey, I can hope, right? Cheers, Chris -- Christian Kuhtz <ck(a)arch.bellsouth.net> -wk, <ck(a)gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."

5 7

RE: Code Red 2 cleanup; reporting..
by Roeland Meyer 11 Aug '01

11 Aug '01

[HTML formatting removed] I should have been more clear [comments about nit-picky bit-heads, removed]. Win2K Active Directory clients run some parts of IIS, in order to support Active Directory. Even if, you never installed IIS explicitly. Especially, there is some serious LDAP/IIS integration here. Note the option to share a directory on the web, how do you think that happens? Also note that, users very often don't understand the difference between SMB file sharing and Web Sharing and Win2K goes to great lengths to obfuscate those two anyway. Win2K is a major re-write of the Domain Controller and its clients. Expect large bugs, roaches the size of small dogs. MSFT [lack of] design QA is well known. If you've never built large software systems, you'd not know that you can integration-test the hell out of one [large software system] and still never catch design flaws because it all meets specification. It is the specifications that are wrong. The exploit that CodeRed uses is a classic example. The only thing that works there is remorseless/ruthless high-level architectural peer review. MSFT doesn't do those. They replace that process with a bazillion integration testers. -----Original Message----- From: Tim Devries [mailto:Tim.Devries@Q9.com] Sent: Friday, August 10, 2001 8:23 AM To: 'Roeland Meyer'; 'up(a)3.am'; nanog(a)merit.edu Subject: RE: Code Red 2 cleanup; reporting.. -----Original Message----- From: Roeland Meyer [mailto:rmeyer@mhsc.com] Sent: Friday, August 10, 2001 11:22 AM To: 'up(a)3.am'; nanog(a)merit.edu Subject: RE: Code Red 2 cleanup; reporting.. > From: up(a)3.am [mailto:up@3.am] > Sent: Friday, August 10, 2001 8:09 AM > > On Fri, 10 Aug 2001, Roeland Meyer wrote: > > > Win2K boxen are ALWAYS running IIS. It doesn't matter > whether you have Pro > > or Server. ALL Win2K systems need to run the patch. MSFT > chose to integrate > > much of the IIS stuff into DLLs with other system critical > stuff. As a > > result, IIS can't be completely removed without killing off > other critical > > functions. Yes, what they proved in court is even more true > with Win2K than > > with Win98 (Duh! MSFT didn't lie, but they didn't tell the > whole truth > > either). WinXP is even more in that direction, from all reports. > > I admit to knowing very little about Win2k, but on the only box I've > installed Win2k on, it doesn't *appear* to be running: > > Port State Protocol Service > 135 open tcp loc-srv > 139 filtered tcp netbios-ssn > 445 open tcp microsoft-ds > 1025 open tcp list > > ...unless it runs on one of those 3 other open ports? This was Win2k > Client, not server, BTW...perhaps you mean every Win2k Server? Win2k proffesional can run IIS. Goto add remove programs -->add/remove windows components ---> IIS. You probably did not select the component on the install. So I guess that means that not every w2k box is vulnerable. Tim

3 2

The Cidr Report
by CIDR Report 11 Aug '01

11 Aug '01

This is an auto-generated mail on Fri Aug 10 23:00:00 PDT 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 10Aug01 0) General Status Table History ------------- Date Prefixes 030801 102236 040801 102194 050801 102268 060801 102340 070801 102456 080801 102930 090801 103092 100801 102845 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 82.105.0.0/16 from AS3269 *** Bogus 82.105.128.0/17 from AS3269 AS Summary ---------- Number of ASes in routing system: 11345 Number of ASes announcing only one prefix: 6735 (3850 cidr, 2885 classful) Largest number of cidr routes: 862 announced by AS701 Largest number of classful routes: 1396 announced by AS701 1) Gains by aggregating at the origin AS level --- 10Aug01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1251 962 289 23.1% Telstra Pty Ltd AS701 1396 1186 210 15.0% UUNET Technologies, Inc. AS2551 748 601 147 19.7% ICG NetAhead, Inc AS4151 288 164 124 43.1% USDA AS4293 391 279 112 28.6% Cable & Wireless USA AS4755 257 147 110 42.8% Videsh Sanchar Nigam Ltd. Autonom AS6595 163 57 106 65.0% DoD Education Activity Network As AS577 294 188 106 36.1% Bell Advanced Communications Inc. AS6429 203 102 101 49.8% AT&T Chile Internet S.A. AS13999 108 12 96 88.9% Mega Cable S.A. de C.V. AS705 233 141 92 39.5% UUNET Technologies, Inc. AS7018 735 646 89 12.1% AT&T AS16473 151 65 86 57.0% Bell South AS7046 325 253 72 22.2% UUNET Technologies, Inc. AS724 222 156 66 29.7% DLA Systems Automation Center AS6471 122 60 62 50.8% ENTEL CHILE S.A. AS12302 93 32 61 65.6% MobiFon S.A. AS4200 126 66 60 47.6% Apex Global Information Services, AS1239 455 396 59 13.0% Sprint AS3464 149 91 58 38.9% Alabama SuperComputer Network AS16758 63 6 57 90.5% IKON Office Solutions AS703 301 246 55 18.3% UUNET Technologies, Inc. AS3908 325 270 55 16.9% Supernet, Inc. AS1 547 492 55 10.1% BBN Planet AS226 147 94 53 36.1% Los Nettos AS6413 65 13 52 80.0% Southern Online Systems, Inc. AS4323 242 190 52 21.5% Time Warner Communications, Inc. AS17561 113 62 51 45.1% Internet service provision to Wes AS852 214 164 50 23.4% Telus Advanced Communications AS9842 54 5 49 90.7% Lotte Data Communication Company For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: Code Red 2 cleanup; reporting..
by Steven M. Bellovin 10 Aug '01

10 Aug '01

In message <3B7360B4.71755CA7(a)deaddrop.org>, Etaoin Shrdlu writes: > >mike harrison wrote: >> >> > FWIW, I just tried to telnet to the 20 most recent hosts I got Code Red II >> > probes from, and didn't get a shell prompt on any of them. Are people >> > cleaning up their boxes that quickly? >> >> I have been told, but not personally conformed confirmed of non IIS >> machines being infected with CodeRed (I or II not known, assume II). >> Infection method: running an file from somewhere? They still scan out >> and seek victims, just no webserver running. > >Spent nearly two days convincing someone who was managing a server that he >was beating up machines all over the company. It finally took someone at >close to VP level to get him to fix it. Last I heard, he was saying >something on the phone like "Yes sir, you're right sir. Sorry sir." The >thing that sucks is that he KNEW he couldn't be a problem, since he wasn't >running IIS. I had the packet captures and obvious grabs for default.ida to >prove it. > >Believe it. I have at least three verified, and that was using web server >logs they'd hit, and ethereal running on the openbsd machine in my office, >which sits right next to the local building router. [Yes, it's true. IRL, I >work for Big Company X.] So -- if he wasn't running IIS, what was he running? --Steve Bellovin, http://www.research.att.com/~smb

3 3

Re: [NANOG] Was: Code Red 2 cleanup -- SHOULD NSPs PULL THE PLUG? Solutions?
by z＠s0be.net 10 Aug '01

10 Aug '01

On Sat, 11 Aug 2001, matt carter wrote: > I don't think in any situation, aggravating the problem by 'returning > fire' serves any purpose. Put filters on your routers if it's that much of > a problem, get your upstream to do likewise if it's that serious.. > <--( SNIP )--> Helu, In the case of a lot of networks that are affected by this problem in particular, putting filters on your routers isn't a solution. It localizes the problem, sure, however do you just let the problem continue ad inifinitum? Also, the filtering of ingress/egress scanning attempts can be fairly resource intensive and is a very short-term 'measure' ( I say measure, because it doesn't offer a solution ). You might not 'return fire', but you should probably be thinking further ahead to an ultimate solution. In doing so, what are the possible solutions.. and how does elapsed time come into play when determining which solution fits the situation? This extends past the Code Red debacle, and into the ethereal 'what if?'. .z

1 0

Another one bites the dust...
by Andy Dills 10 Aug '01

10 Aug '01

http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/08-1… Rhythms is disbanding their network. Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access

2 1

RE:
by Roeland Meyer 10 Aug '01

10 Aug '01

> From: Jim Shankland [mailto:nanog@shankland.org] > Sent: Friday, August 10, 2001 11:04 AM > > Roeland Meyer <rmeyer(a)mhsc.com> writes: > > > ... and I just saw a Rythms truck, on the San Mateo bridge, > Wednesday. > > Which side were they pushing it over? The San Mateo side, going to Hayward, I believe. It was rush-hour, no one was going anywhere.

1 0