- Test - lists.nanog.org

Re: Code Red growth stats
by Steven M. Bellovin 02 Aug '01

02 Aug '01

In message <20010801190627.A7553(a)caida.org>, k claffy writes: > >hmm, not sure about that, smb. > >albeit crippled caida monitor (we're working on it), >it does seem to have reversed slope again: >http://www.caida.org/analysis/security/code-red/aug1-live-hosts.gif Fascinating; thanks. SANS hasn't updated their plots lately, so I can't compare. Anyone else with any data to post? (On the other hand -- any chance that the dip recorded at CAIDA is due to the measurement problems?) If it has indeed turned up again, I'm at a loss to explain it. While I'm sure there are some IIS servers on home machines, I doubt there are that many. But I don't have another explanation to offer. --Steve Bellovin, http://www.research.att.com/~smb

7 6

Re: Code Red growth stats
by Larry Sheldon 02 Aug '01

02 Aug '01

I did a poor job of formating this message. Somebody else said this (Idon't remember who at the moment): > Indeed. I've seen 1215 probes since the start of August, and a rough glance > shows something like 30% or more are dialups, cable modems and DSL lines. > Better than 50% appear to be addresses without INADDR. I said this: > Here too I think a sociologist might be useful (by the way I am not a > sociologist, I disagree with some sociology, but I have lunch with > one or more nearly every week). > > What is likely to be the population characteristic most common among > xDSL connected folk? > > I think it is small [home|business|shop] relatively unsophisticated, > poorly staffed and more likely to have all the bells and whistles on. > > And maybe the most frequently occuring thing in the population. I am sorry to have stolen somebody else's words--I did not mean to do that.

1 0

Re: Code Red growth stats
by Larry Sheldon 02 Aug '01

02 Aug '01

Indeed. I've seen 1215 probes since the start of August, and a rough glance shows something like 30% or more are dialups, cable modems and DSL lines. Better than 50% appear to be addresses without INADDR. Here too I think a sociologist might be useful (by the way I am not a sociologist, I disagree with some sociology, but I have lunch with one or more nearly every week). What is likely to be the population characteristic most common among xDSL connected folk? I think it is small [home|business|shop] relatively unsophisticated, poorly staffed and more likely to have all the bells and whistles on. And maybe the most frequently occuring thing in the population.

1 0

Re: MicroSoft amplification?
by Tony Rall 02 Aug '01

02 Aug '01

On Thursday, 2001/08/02 at 00:49 AST, Valdis.Kletnieks(a)vt.edu wrote: > On Wed, 01 Aug 2001 16:26:55 PDT, Tony Rall <trall(a)almaden.ibm.com> said: > > echo). This probably makes PMTUD work a lot better, but it sucks for ICMP > > Or totally horques it up entirely if the actual data path used has a > different PMTU. No way this will work if 9 paths are clean and one > requires a frag. ;) > > I won't discuss what to do if you get back 10 FRAG NEEDED packets, with > differing frag sizes ;) That's not the way it works. You've got a load-balancing-system (LBS) front-ending (using a single IP address) a cluster 10 web servers. A client on the other side of the LBS initiates an 80/tcp connection. The LBS directs it to (let's say) server 6. Once data starts flowing on the connection, nothing interesting happens until server 6 sends a large packet to the client with (as on all of its packets) the Don't-frag flag on. That packet reaches a link with a smaller mtu. The router on that link returns (to the server complex) and ICMP unreachable, fragmentation needed packet (type 3, code 4). That ICMP reaches the LBS; it has to decide what to do with it. Some LBSs will just discard any ICMP packets addressed to the cluster. The one used by MS instead forwards it to all the back-end servers. The servers that don't have a session with the client may just discard the ICMP packet (or they may simply update info in their routing table (I know that Aix does that)). The server that does have a session with the client will repackage his data packet (per the newly learned mtu) and send the smaller packet. The path between the chosen server to the client is no more ambiguous than any other PMTUD situation. Which is to say that, yes, the path could change from packet to packet, but that isn't brought on by the presence of the LBS, it's just a shortcoming of the PMTUD mechanism. In fact outbound traffic from the clustered servers often doesn't even go through the LBS. (Note that if the client is also using PMTUD and happens to send a large enough packet to trigger it, the only ICMP unreachable sent would be towards the client. Even if the link mtu causing the unreachable is on the server side of the LBS, there will be only one unreachable sent - no ambiguity at all.) (Also note that it isn't necessary for an LBS to forward all ICMPs to make PMTUD work. It just has to forward the unreachable, fragmentation needed packets. And it doesn't have to forward those to all the back-end servers. There is enough info in the unreachable message to determine which connection this ICMP message relates to - the 80/tcp connection between the client and server 6. So the LBS could know that this ICMP only has to be forwarded to server 6. I don't know of any LBS that is smart enough to handle it this way.) Tony Rall

2 1

All hazard Internet security
by Larry Sheldon 02 Aug '01

02 Aug '01

> One of the issues I've been discussing as part of various > critical infrastructure protection forums is the need > for "all hazard" outage information. Treating Internet > security as just a law-enforcement issue can warp your > perception. Unless you have a good view into all the > other things which can wreck Internet availability, it is > difficult to gauge the impact of a malicious activity > versus "normal" outages. BoyHowdy! Bingo! I'll say. Also difficult to "sell" to managment--the notion of "normal" outages (I like the terms "risk assessment" and "business continuation preparation" here). > I don't completely understand the data. The impact of the > Baltimore train wreck shows up very clearly. Traffic > returns to nearly normal by 6am the next morning. But then > degrades again the following the day (i.e. "Worm day"). I > don't have access to the raw data, so I can't tell if there > are differences between carriers with fiber in the Howard > tunnel and other carriers. Did congestion increase the following > day due to the reduced bandwith the following day, or was it > consumed by the worms propagation. I think you have left out the "rubberneck effect" (I may have just coined a new term). I often notice in our traffic graphs that certain events and certain rumored events, as well as (in the instant case) certain "predictions" Will cause dramatic increases in traffic in our network. I think a sociologist would be helpful in understanding that, but my very informal and anecdote-ridden "study" indicates to me that when we make a major upgrade in facilities, there is a jump in traffic as people ping stuff all over, try the MS web page (and its speedometer doodad), and so on. There was a jump last evening at about 1930 local and there was one the night before at about the same time--people checking to see if the 'net was dead? -- -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- . . - L. F. (Larry) Sheldon, Jr. - . Unix Systems and Network Administration . - Creighton University Computer Center-Old Gym - . 2500 California Plaza . - Omaha, Nebraska, U.S.A. 68178 Two identifying characteristics - . lsheldon(a)creighton.edu of System Administrators: . - 402 280-2254 (work) Infallibility, and the ability to - . 402 681-4726 (cellular) learn from their mistakes. . - 402 332-4622 (residence) - . http://www.creighton.edu/~lsheldon Adapted from Stephen Pinker . -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-

1 0

All hazard Internet security
by Sean Donelan 02 Aug '01

02 Aug '01

One of the issues I've been discussing as part of various critical infrastructure protection forums is the need for "all hazard" outage information. Treating Internet security as just a law-enforcement issue can warp your perception. Unless you have a good view into all the other things which can wreck Internet availability, it is difficult to gauge the impact of a malicious activity versus "normal" outages. I don't completely understand the data. The impact of the Baltimore train wreck shows up very clearly. Traffic returns to nearly normal by 6am the next morning. But then degrades again the following the day (i.e. "Worm day"). I don't have access to the raw data, so I can't tell if there are differences between carriers with fiber in the Howard tunnel and other carriers. Did congestion increase the following day due to the reduced bandwith the following day, or was it consumed by the worms propagation. http://www.keynote.com/press/html/special_worm_update.html One of the unique things IOPS/Kelly Cooper have been trying to include in the ISP-ISAC, which the other ISAC are lacking, is an outage reporting component. Currently the Internet does have a clear point of contact for dealing with these events. Even if your company is already joining other ISACs, if you are an Internet provider, I hope you look into and consider working with the ISP-ISAC. See the last NANOG conference web page for a copy of the proposal. The "all hazard" aspect makes things more complicated, but I think it significantly enhances the usefullness of the ISP-ISAC.

1 0

RE: Code Red growth stats
by Roeland Meyer 02 Aug '01

02 Aug '01

> From: Petr Swedock [mailto:petr@ai.mit.edu] > Sent: Wednesday, August 01, 2001 9:38 PM > : From: "Steven M. Bellovin" <smb(a)research.att.com> > : Date: Wed, 01 Aug 2001 23:15:50 -0400 > : In message > <EA9368A5B1010140ADBF534E4D32C728025AB1(a)condor.mhsc.com>, Roeland Me > : yer writes: > : >> From: Steven M. Bellovin [mailto:smb@research.att.com] > : >> Sent: Wednesday, August 01, 2001 7:36 PM > : > > : >> If it has indeed turned up again, I'm at a loss to > explain it. While > : >> I'm sure there are some IIS servers on home machines, I doubt > : >> there are > : >> that many. But I don't have another explanation to offer. > : > > : >Are you taking into account that every copy of Win2K > comes with IIS? I had > : >to quickly run around and do upgrades yesterday. I clean > forgot about the > : >workstations. I bet that I'm not the only one either. > I think it is NOT on by default for IIS 4.0 but IS on by default > for IIS 5.0... In any event, we had a machine that was freshly > installed with the very latest W2k on July 18, in the evening. That > machine was worm ridden within 12 hours. The grad student who > installed didn't specifically add IIS and didn't have any reason > to do so. I've just been staring at www.caida.org/analysis/security/code-red/aug1-live-hosts.gif (yeah, I know ... not enough to do). We have a nice little camel here. It occurs to me that the time coincide with info workers leaving work, eating dinner, and firing up the workstation at home, in the US. Do we have any location data on these infected hosts? What would be interesting is, if we have another tail-off starting at about 0400 (we do) UTC and picking up again about 10-12 hours later. UTC midnight is about 2100 EDT and 1700 PDT. That's when it starts to pick up again. The second peak corresponds to 0000EDT/0800PDT. This supposes that the super-majority of Win2K machines are in the US. There are also a bunch of WinXP beta machines out there. Is XP vulnerable?

1 0

Re: Code Red growth stats
by Avi Freedman 02 Aug '01

02 Aug '01

In article <10171.223820.2348(a)avi.netaxs.com> smd wrote: : Fascinating; thanks. SANS hasn't updated their plots lately, so I : can't compare. Anyone else with any data to post? (On the other hand : -- any chance that the dip recorded at CAIDA is due to the measurement : problems?) : If it has indeed turned up again, I'm at a loss to explain it. While : I'm sure there are some IIS servers on home machines, I doubt there are : that many. But I don't have another explanation to offer. : --Steve Bellovin, http://www.research.att.com/~smb Data from Akamai (we are not gathering all data, so this shows size as a trend based on sampling, not absolute #): Time Hosts New Hosts/Hour 11:00 4,782 15:00 25,600 5204.5 15:33 30,921 9674.55 16:29 37,240 6770.36 17:25 43,120 6300.00 18:23 48,885 5963.79 This is ONLY for default.ida and some pieces of "classic code red" byte matching, off of hits to Akamai web servers - not just port 80 scans to unused IP space. We saw almost nothing last night/yesterday. Then today we saw it go exponential, then linear, then slow, then linear. I can't get in to get the last-few-hours data... We've noted 4-5 new worm signatures today, though. Luckily no super-duper-evil ones yet. The security and architecture elves at Akamai are owed the credit, but if I mentioned their names the security weenies would have to kill me... Avi

3 2

Re: A watched pot never boils: The Return of Code Red
by Simon Waters 02 Aug '01

02 Aug '01

>After eight hours of Code Red II, I haven't seen any impact. So far >the only website I can't reach is WWW.KEYNOTE.COM Everything else >seems to be humming along just fine. Funny I get KEYNOTE.COM fine, but www.internethealthreport.com has problems. The site is reachable via http://internetpulse.com/ but Keynote seem to use the other name in their link. It is a DNS delegation issue (and possibly web server configuration), I have flagged it to the contact listed in the SOA at Keynote. A quick glance suggests at the Internet Pulse suggests that things may be slightly below average, but not dramatically different from normal, certainly it doesn't look fatal yet. The CAIDA Code Red figures quoted elsewhere suggest it may level off at about half as many infections as last time. But we don't really know what living with this thing for another 19 days will be like. My /24 *8-) didn't see any probes till about 80,000 unique hosts had been detected at www.incidents.org, so I suspect the "pseudo random" approach to IP addresses may lead to a long tail in the infection.

2 1

RE: Code Red growth stats
by Roeland Meyer 02 Aug '01

02 Aug '01

> From: Steven M. Bellovin [mailto:smb@research.att.com] > Sent: Wednesday, August 01, 2001 8:16 PM > >Are you taking into account that every copy of Win2K comes > with IIS? I had > >to quickly run around and do upgrades yesterday. I clean > forgot about the > >workstations. I bet that I'm not the only one either. > > > Are you sure about that? Or rather, are you sure it's on by > default? No, it's not on by default. But, no one that I know (including my duaghter's warez friends) whom is running Win2K at home, isn't running a web server. Even when they're not supposed to (behind cable modems). In the shop, we all run IIS, on the workstations, for local testing and development. But, what do you expect from a shop full of development geeks? > I just checked my toy desktop machine and rebooted to the other > partition of my laptop, and didn't see it running on either.l To be > sure, I'd have turned it off if I knew it was on, but I have no idea > how to do things like that on Windows... It is altogether too easy. Goto: Control Panel >> Administrative Tools >> Internet services manager.

2 1