the view from a /32: the worms come marching in

jose o. nazario, crimelabs research. may, 2002.


two years of web server logs on a single system were analyzed, running from mid 1999 until mid may, 2002, to look for the patterns of infections from code red 1 and code red 2 along with the nimda worm. by analyzing the data in terms of requests and infected hosts seen per day, it is possible to study the spread of a worm together with mitigation techniques from the perspective of a globally advertised web server on a LAN. analysis of the data shows the effectiveness of aggressive remediation steps as well as the persistence of both nimda and code red 1 on a production network.


this analysis is of a globally advertised web server running on a single homed /32 (a globally unique host). the web server runs apache and resides on a .edu network in the united states. the surrounding network is a /16. using the apache server software, worm requests were logged and analyzed within a two year period of web server traffic. the apache suite is unaffected by the attacks which are used by the code red and nimda worms to attack IIS servers. however, the attacks are captured and logged, which allow for monitoring.

the network on which this host sits has been agressively identifying and blocking nimda hosts at the edge or at the nearest subnet device. no filtering of worm affected hosts was performed on this server. as such, the persistence seen in other studies (such as data recently published by arbor networks, see reference 1) is not observed here. this data gives us a measure of the effectiveness of these measures on a production network taking active measures to stem the tide.

this positioning of the host is important because of the 'island hopping' that code red 2 and nimda do, with the following characteristics: code red 2 will hit the hosts /8 with a 50% probability, a 37.5% chance it will scan in its /16, and a 12.5% chance it will scan a totally random network. for nimda this distribution is 50% in the same /16, 25% in the same /8, and 25% in a random network. see references 2, 3 and 4 for more information on these worms. hence, nimda and code red 2 hosts on the same network will be visible to this host (or any similarly positioned host) as it scans and attacks web servers. in contrast, the code red worm does not do any such island hopping, instead it moves from one randomly chosen network to another as it seeks victim hosts.

in the analysis of the data, it is important to recall that code red 1 and 2 each have one attack request, while nimda has seven unique attack requests. thus any one host infected by nimda would have seven times as many attacks logged per attack instance than a code red 1 or 2 attack.

data was culled from apache logs from approximately july, 1999, until may 18, 2002. this represents approximately 10 months of code red 1 traffic, over 9 months of code red 2 traffic, and approximately 8 months of nimda attacks. processing was done using shell scripts to extract requests matching the signature of the worm attack patterns. data was then sliced to show the number of unique hosts per day and the number of requests by worm type per day over this period. visualization was done using the gnuplot tool (see reference 5).

nimda, code red 1 and 2

in this first series of figures, we can see the overall impact of these worms over this monitored period. in figure 1, we can see a sharp spike on september 18, 2001, the release date of the nimda worm. while some tailing of nimda is visible, this dramatic peak obscures any meaningful analysis in the plot shown in figure 1. this visualization does not accurately represent the impact of the three worms analyzed here, which all significantly diminished performance of the Internet as a whole.

graph on hits for nimda, code red 1 and code red
2, by day, july 99 - jul 02

figure 1: total number of hits per day due to the worms nimda, code red 1 and code red 2. logfile signatures matching the worm requests made by code red 1 and 2 and nimda were extracted from an apache server's logs over a two year period. daily sums were taken and plotted. the sharp spike represents september 18, 2001, the global release date of the nimda worm. as is visible here, the scale of this dwarfs the visualization of the other data points on the graph.

in figure 2, the data is expanded on the y-axis, allowing for more a detailed understanding. immediately obvious is the aggressiveness of the nimda worm (represented in red bars), along with the swamping out of code red 2 (shown in blue bars). it is also interesting to note that code red 1 (represented in green) only shows mild amounts of penetration, however it does show a similar persistence to nimda, continuing at a noticable rate for more than 8 months. code red 2, in contrast, is almost entirely eliminated in the view of this single server within a 2 month period.

zoom in of previous graph

figure 2: an expanded view of the requests made by nimda, code red 2 and code red 1 in a two year period.. the data in this figure is the same as it is in figure 1, however the y-axis has been shrunk to make the data from code red 1 and 2 more visible. the result is that any detail for nimda is lost over this period.

the data in figure 2 preceeds the onset of these widespread worms by about one year. as such, we can gauge the amount of `noise' in the detection process. code red 1 and 2 each have a single attack which was uncommon for attackers to attempt manually. the exploit released by the eeye team, who discovered the vulnerability, used a different method and left a different signature in the server's logs. in contrast, nimda used seven different attack methods, some of which mirrored methods an attacker would try manually. as such, the `noise' in the nimda detection is noticably higher than the detection `noise' for code red 1 and 2. based on this, it is reasonable to say that the code red 1 persistence seen in figure 2 is not an artifact and represents a real phenomenon.

shown in figure 3 are the number of hosts detected for each type of attack per day. the immediate observation is that code red 1 took a bit to `ramp up' the number of hosts it was using for its attacks. the number of code red 1 hosts reaches a maximum a few days after the initial observation before it drops off dramatically. code red 2, in contrast, is an immediate onset with a pronounced persistence in the number of hosts seen. nimda shows this, as well, but noticably more dramatically. the first day the worm was seen shows a marked upsurge in infected hosts, almost 60, before dropping off quickly due to filtering.

number of hosts per day

figure 3: the number of infected hosts seen per day. the server's logfiles were analyzed to determine the number of hosts seen per day and this value plotted as a function of time for each of the three worms analyzed in this report. these are not cumulatively unique, only the number of unique hosts seen per day.

analyzing the data in figure 3 further, we can assay the `noise' any one infection typically makes on the network. in the cases of code red 1 and code red 2, the number of hosts mirrors the number of attacks logged by the server. nimda hosts, however, do not show this mirroring. while there is a noticable spike in the number of nimda hosts seen on september 18, 2001, this number quickly drops off. the number of nimda requests seen, however, do not drop off as quickly. this suggests that the nimda worm is noticably more `noisy' than either code red 1 or code red 2, above its seven fold number of requests made during an attack compared to either of the variants of code red.

the onset of nimda

the nimda worm represents an interesting opportunity to study the onset and effectiveness of mitigation techniques against an aggressive worm. nimda's day 1 is well known, september 18, 2001, and is clearly visible in figures 1 through 3. in figure 4, the month of september is more clearly graphed. at this level of detail, the effectiveness of mitigation techniques on a day by day basis can be observed. as is visible in figure 4, on day 2 of nimda's life, the network's visibility of nimda is down to approximately 1/12th of the original impact, due to the network administrators identifying and removing or filtering affected systems. on the 20th of september, nimda stops its scanning and begins a DDoS against one of the published IPs of it then lies dormant until the first day of the next month, when it begins scanning for and attacking new hosts as described above.

the onset of nimda, sep 2001

figure 4: the number of nimda requests seen in the month of september, 2001. the sudden onset of nimda on the monitored network on september 18, 2001, is clearly visible here. additionally, the active identification and blockage or removal of affected systems reduces this number to 1/12th of the first day's requests within 24 hours. on the 20th of september the worm shut down its active scanning and attacking of new nodes and instead began a DDoS against one of the IPs of

the data in figure 5 can be used to assay the long term effectiveness of nimda mitigation techniques. the data from september, 2001, until january 1, 2002, has been plotted by the number of nimda hosts seen per day. after a very aggressive first round in september, nimda hosts only `flare up' a few times, typically at the beginning of the month. the most major flare up observed here is in december, 2001.

the onset of nimda, second half, 2001

figure 5: the number of nimda infected hosts per day in the second half of the calendar year 2001. the number of nimda infected hosts were plotted per day for the second half of 2001 to ascertain the long term effectiveness of aggressive mitigation techniques. the bell shaped profile during the 1 december, 2001, flare up of nimda is most likely due to clock skew on various computers or the effect of differing timezones around the world.

from these two figures, 4 and 5, it is possible to say that the aggressive identification and filtering or removal of hosts affected by the nimda worm are effective. after an initial burst by the new worm, the number of attacks by nimda hosts decreases, a result of this strategy.


by analyzing two year's worth of the logs of a globally advertised apache web server, we can ascertain the impact of the code red 1 and 2 worms together with nimda on a large network. furthermore, we can assay the effectiveness of aggressive mitigation techniques and find that they make a dramatic impact on the survivability of the worm. however, despite this, both nimda and code red 1 persist on the network.


1. "a global snapshot of internet worm activity", dug song, robert malan, and robert stone, november, 2001. available at see also a set of presentation slides available at
2. "CERTŪ Advisory CA-2001-26 Nimda Worm", september 18, 2001, available at
3. "CERTŪ Advisory CA-2001-19 "Code Red" Worm Exploiting Buffer Overflow In IIS Indexing Service DLL", july 19, 2001, available at
4. ""Code Red II:" Another Worm Exploiting Buffer Overflow In IIS Indexing Service DLL", august 6, 2001, available at
5. the GNUPlot homepage, available at


the author wishes to thank the Internet community at large, especially the members of the mailing lists 'incidents' and 'log-analysis', each hosted at, for assistance in the analysis of this data.