This looks pretty much like a NIMDA worm probe (more advanced variant of code red) attempting to exploit known IIS vulnerabilities . Code Red probes are similar and are recognisable by XXXXXXXXXXX or NNNNNNNNNN patterns in the access_log .
The Apache http service running on my home linux server has been logging this sort of crap since September last year. My initial trace attempts when I first came across it, revealed that only a minority of source IP addrs resolved to a valid host with open ports for common services. Most addresses looked like reassigned Dynamic IP s and many failed reverse DNS lookup. When I researched this on the net last year, I found the approaches from linux users varied from ignoring it completely to implementing various forms of automated counter measures, including scripts that scan httpd logs, detect an attack and add then add firewall rules to block the offending host. Some people even proposed attempting to reverse the exploit i.e. on the assumption that the attacking host has an infected IIS server, exploit the worm itself to disable the server in some way . Try a google search with key words such as NIMDA, apache, linux etc. for more info. I chose to simply tolerate and ignore these probes for now . My only real concern relates to possible *invalid* over limit traffic charges from my ISP. My linux server is online roughly 24/7 (not quite 5 nines yet :-) ) to a TelstraClear/paradise 256Kb/128Kb cable connection, which has a 5GB per month traffic limit . Needless to say I keep a close watch on the fairly detailed usage logs that paradise provide . The paradise web interface allows you to drill down to individual usage line items, which detail time for each 'usage' and charge in terms of international MB equivalents. My concern arose when I noticed a lot of 0.01 MB charges at unusual times from various oddball IP addresses. Correlation with my apache access logs showed that most of these 0.01MB charges were the result of incoming NIMDA probes. Now, although I haven't proved it, I suspect that a NIMDA probe doesn't generate 10Kb worth of traffic. Does anyone know how paradise or T/C bills for short bursts of traffic, is there a threshold or some form of consolidation ? If this type of billing isn't being done fairly, given a sufficient number of such attacks, there is the danger of falsely exceeding traffic limits and over billing due to rounding errors. To exemplify that this possibly does happen - a Paradise cable user with a 256Kb cable connection (same as mine) recently reported (on nz.comp) that he was billed for 5GB of traffic over a 5 minute period (1GB per minute on a 256KB connection - yeah right). He was told that this was 'probably' caused my a smurf DOS attack . That report served to strengthen my suspicions. +I am currently 'playing' with apache, does anyone here ever +get tired of; + +<snip> +[Wed Jan 30 15:30:59 2002] [error] [client 210.74.146.190] +File does not +exist: /somedir/scripts/root.exe +[Wed Jan 30 15:31:01 2002] [error] [client 210.74.146.190] +File does not +exist: /somedir/MSADC/root.exe +[Wed Jan 30 15:31:03 2002] [error] [client 210.74.146.190] +File does not +exist: /somedir/c/winnt/system32/cmd.exe +[Wed Jan 30 15:31:05 2002] [error] [client 210.74.146.190] +File does not +exist: /somedir/d/winnt/system32/cmd.exe +[Wed Jan 30 15:31:06 2002] [error] [client 210.74.146.190] +File does not +exist: /somedir/scripts/..%5c../winnt/system32/cmd.exe +[Wed Jan 30 15:31:08 2002] [error] [client 210.74.146.190] +File does not +exist: /somedir/_vti_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe +[Wed Jan 30 15:31:10 2002] [error] [client 210.74.146.190] +File does not +exist: /somedir/_mem_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe +[Wed Jan 30 15:31:12 2002] [error] [client 210.74.146.190] +File does not +exist: +/somedir/msadc/..%5c../..%5c../..%5c/..�^\../..�^\../..�^\../wi +nnt/system32/cmd.exe +</snip> + +I mean this attack was directed at an NT/2k/XP machine. I +have whois'ed the +IP and have someone to complain to, what is the general attitude here +towards responding to provocation such as this? + +I do realise that .190 is not a specific address and will +probably not be +traceable back to the purpotrating computer. But someone +needs a good stiff +slaping with a dripping wet trout. + +Mark Carey + + + + +_________________________________________________________________ +Send and receive Hotmail on your mobile device: http://mobile.msn.com + +
