| 8:17 am on Apr 2, 2002 (gmt 0)|
You can integrate this into your .htaccess file. If SetEnvIfNoCase doesn't work you can use SetEnvIf instead.
|SetEnvIfNoCase Request_URI "^/default.ida" ban |
SetEnvIfNoCase Request_URI "^/scripts" ban
SetEnvIfNoCase Request_URI "^/c/winnt" ban
SetEnvIfNoCase Request_URI "^/_mem_bin" ban
SetEnvIfNoCase Request_URI "^/_vti_bin" ban
SetEnvIfNoCase Request_URI "^/msadc" ban
SetEnvIfNoCase Request_URI "^/d/winnt" ban
<Limit GET POST>
deny from env=ban
allow from all
| 8:24 am on Apr 2, 2002 (gmt 0)|
Thank you. I put it in there and stopped and restarted the server. Now I am going to go clean out my logs hopefully for the has time.
| 8:59 am on Apr 3, 2002 (gmt 0)|
>really tired of this virus still wandering around the internet.
I really think most of the boxes have been fixed. What we are seeing now, are script runners still probing for the weekness.
| 9:32 am on Apr 3, 2002 (gmt 0)|
Whatever it is needs to stop. It is really annoying. It looks like most of my hits are coming from within my cable modem subnet. My assumption is people are at home setting up a personal webserver to learn with and not knowing anything about the administrative side, not looking for updates to there server. They are mainly concerned with the page itself. Would be nice if microsoft or somebody tooks responsibilit for this bug and made an attempt at contacting the infected web servers. That would be a probe I would be happy to see in my logs.
| 11:56 pm on Apr 3, 2002 (gmt 0)|
A common misconception is that .htaccess can block IP's UA's etc. It only controls access to directories where the requests are allowed or denied.
All requests to Apache are logged so they will appear in your access_log.
Key_Master's suggestion is half way to a solution but it won't block the requests or prevent them from being logged. It only assigns an environment variable ban to them and logs 403 errors.
We need to configure Apache to prevent logging of them. To do this add env=!ban to the end of your CustomLog directive in httpd.conf
These are a couple of examples.
CustomLog logs/access_log combined env=!ban
CustomLog /home/mysite/logs/access_log combined env=!ban
Apache needs to be restarted for this to work. Now all these junk requests will not be logged to access_log but they will still appear in your error_log.
If your not sure where httpd.conf is, type locate httpd.conf and the full path should be displayed.
Before editing httpd.conf MAKE A BACKUP Even a small typo error will prevent Apache from restarting
Also, you should put the SetEnvIf directives in httpd.conf or srm.conf instead of .htaccess for the Nimda/Code Red requests.
All the Nimda requests end with either root.exe or cmd.exe
so this is all that is needed in srm.conf or httpd.conf
SetEnvIf Request_URI (.*)cmd\.exe ban
SetEnvIf Request_URI (.*)root\.exe ban
SetEnvIf Request_URI \.ida(.*)$ ban
More info can be found at
| 2:45 am on Apr 4, 2002 (gmt 0)|
thanks. I noticed that the first suggested fix got rid of a lot of the logs but not everything. I have put this in place now and hopefully that will take care of things.
Thanks for everybodies help on this.
| 4:00 am on Apr 7, 2002 (gmt 0)|
> It looks like most of my hits are coming from within
> my cable modem subnet. My assumption is people are at
> home setting up a personal webserver to learn with and
> not knowing anything about the administrative side, not
> looking for updates to there server.
Not necessarily a good assumption. If you do an analysis of incoming IP numbers from "average" (that is, pre-Code Red/Nimda) surfers, you will discover that the breakdown by Class A IP quad is extremely uneven from 0 to 255.
I did such an analysis, prior to the Code Red onslaught last summer. Based on a sample of over 100,000, over one third of the Class A were close to zero hits, over one third were fairly low, and less than one third were very high.
The distribution is very, very uneven. That's why Code Red didn't propagate as fast as Nimda. In Code Red, the IP number targeted by infected machies was generated randomly. Two-thirds of its effort was wasted on Class As that didn't go hardly anywhere.
Starting with Nimda, the IP generation routine gave heavy priority to the Class A of the machine that was infected. That neatly solved the problem of wasted attacks, as the outgoing attacks were now proportional to the actual Class As in use on the Internet.
Therefore, Nimda propagated much more quickly than Code Red. Almost all the probes you see will be from your same Class A, because all the virus writers from here on out will not be repeating the mistake of generating the attack IPs using a random generator.
| 3:43 pm on Apr 28, 2002 (gmt 0)|
I have the same problem, but I
would like to know what I should
type in as a script to make my
linux box relaliate.
I want to shut down the server that
keeps nimda'ing me.
Is this possible? If so how do I do it,
I can't stand these bad hits anymore.
If no one knows the answer, where might
I find it?
I search all over google and
there is no information.
| 4:10 pm on Apr 28, 2002 (gmt 0)|
Welcome to wmw ineedhelp.
Your post says, "I want to shut down the server that keeps nimda'ing me." You won't find help doing that here. Suppose someone decided they didn't like something about your server and decided to shut it down...