Forum Moderators: DixonJones
These annoy me, because I like to look through my error_logs to find genuine problems users are having, but it's hard when the error logs are filled with exploit attempts to access files like "cmd.exe", "formmail.pl", etc
So I came across some .htaccess code that supposedly does this, and I've modified it, but apparently not enough. I'm having problems with RegEx I think. Here's the code:
Options +FollowSymLinks
RewriteEngine on
RewriteBase /
# Recurring exploits causing errors in my logs.
RewriteCond %{REQUEST_URI} cltreq\.asp$[OR]
RewriteCond %{REQUEST_URI} owssvr\.dll$[OR]
RewriteCond %{REQUEST_URI} CAPREQ=0$[OR]
RewriteCond %{REQUEST_URI} u00=a$[OR]
RewriteCond %{REQUEST_URI} c\+dir$[OR]
RewriteCond %{REQUEST_URI} default\.ida$[NC,OR]
RewriteCond %{REQUEST_URI} formmail\.(pl¦cgi)$[NC,OR]
RewriteCond %{REQUEST_URI} ^/cgi-bin/FormMail\. [NC]
RewriteRule .* /worms.txt [L]
I've put a file called "worms.txt", containing a single byte, to send back to these exploiters. My thinking is that it would result in a non-error, and be slightly more efficient than sending back a 404.htm page.
But my code has problems. Its not apparently working for requests for "cltreq.asp" or "owssvr.dll" or "default.ida" and I don't think my formmail rules are working right either.
Can you help, and maybe improve the concept beyond what's here now?
# Recurring exploits causing errors in my logs.
RewriteCond %{REQUEST_URI} .*cltreq\.asp$[OR]
RewriteCond %{REQUEST_URI} .*owssvr\.dll$[OR]
RewriteCond %{REQUEST_URI} .*CAPREQ=0$[OR]
RewriteCond %{REQUEST_URI} .*u00=a$[OR]
RewriteCond %{REQUEST_URI} .*/c\+dir$[OR]
RewriteCond %{REQUEST_URI} .*efault\.ida$[NC,OR]
RewriteCond %{REQUEST_URI} .*ormmail\.(pl¦cgi)$[NC]
RewriteRule .* /worms.txt [L]
Are you seeing any negative impact on users with this code ?
This "new" line
RewriteCond %{REQUEST_URI} .*cltreq\.asp$[OR]RewriteCond %{REQUEST_URI} cltreq\.asp$[OR]There is no need to add .* to the beginning or end of any pattern. If you don't care what a pattern-matching string begins with, then leave off the "^" start anchor. If you don't care what it ends with, leave off the "$" end anchor. Ref: [etext.lib.virginia.edu...]
You need to add a space preceding the [OR] and [NC,OR] flags in all cases.
cltreq, owssrv and few others have to do with a standard IE browser that has web discussions enabled. As such, it is not malicious, but just annoying if you are hosted on Apache. Do a site search here on WebmasterWorld for some previous discussion.
Consider adding a few lines to block or redirect "cmd.exe$" and a few others - these are requested by a very common exploit:
RewriteRule /(cmd¦root¦shell)\.exe$ - [F]
RewriteRule \.ida - [F]
RewriteRule \_vti\_ - [F]
RewriteRule ^NULL - [NC,F]
RewriteRule bin/ - [NC,F]
When I grepped through my July access_logs, all the instances of "cltreq.asp" and "owssrv.dll" seemed to serve no purpose. ( And they were probably the most numerous of my error_log clutter). Unfortunately, the WebmasterWorld site search feature isn't working now. I'm not familiar with the web discussion feature of the browser. If possible, I want to deal with cltreq.asp and owssrv.dll somehow, to get them out of my error_logs. Is it OK to return a ".txt" page to this request.. or does it screw up the users browser?
I found that pattern-matching for CAPREQ, u00=A, and c+dir, was successfully finding most of the "cmd.exe" requests. I think I'll wait for another month of error_log accumulation, to see if the remaining requests are sufficiently numerous to justify an extra line.
I'm not entirely sure, ( and I'm away from my main computer right now), but I think "default.ida" was the only significant request of ".ida" But as you suggest, a line for ".ida", replacing my line for "default.ida" seems better. But can you please comment on whether it should terminate with "$" as in:
RewriteCond %{REQUEST_URI} \.ida$ [NC,OR]
( I don't recall seeing errors where ".ida" was in the middle of the requested URL ).
My access_logs last month, didn't have any requests for "root.exe" or "shell.exe", so I was thinking maybe those have fallen out of common use in exploits. ( Can someone else please confirm or refute? )
Your approach for frontpage stuff looks good, by matching anything containing "_vti_".
I see you've implemented your suggestions as a series of individual RewriteRule's. Can you comment on my approach, which is to serve these exploits a tiny ".txt" file. Does your approach, using the [F] flag, keep these things from making error_log entries?
So, I tested and learned that it doesn't hurt the Discuss bar users, to send them back a tiny .txt file. My site's features work just fine, and I'm very pleased to have cleaned up my error_logs with it.
I found that pattern-matching for CAPREQ, u00=A, and c+dir, was successfully finding most of the "cmd.exe" requests. I think I'll wait for another month of error_log accumulation, to see if the remaining requests are sufficiently numerous to justify an extra line.
Yes, this is just a matter of "style" and up to the individual webmaster. I just found it easier to match any occurrance of "cmd.exe" regardless of the directory path or query string.
I'm not entirely sure, ( and I'm away from my main computer right now), but I think "default.ida" was the only significant request of ".ida" But as you suggest, a line for ".ida", replacing my line for "default.ida" seems better. But can you please comment on whether it should terminate with "$" as in:
RewriteCond %{REQUEST_URI} \.ida$ [NC,OR]
( I don't recall seeing errors where ".ida" was in the middle of the requested URL ).
My access_logs last month, didn't have any requests for "root.exe" or "shell.exe", so I was thinking maybe those have fallen out of common use in exploits. ( Can someone else please confirm or refute? )
Your approach for frontpage stuff looks good, by matching anything containing "_vti_".I see you've implemented your suggestions as a series of individual RewriteRule's. Can you comment on my approach, which is to serve these exploits a tiny ".txt" file. Does your approach, using the [F] flag, keep these things from making error_log entries?
Jim
212.35.100.227 - - [13/Jul/2003:00:01:31 +0000] "GET /scripts/shell.exe?/c+dir+c: HTTP/1.1"
403 - "-" "Mozilla/3.0 (compatible; Indy Library)"
66.30.206.169 - - [31/Jul/2003:03:35:21 +0100] "GET /MSADC/root.exe?/c+dir HTTP/1.0"
403 - "-" "-"
As for the "default.ida" issue, this is what I've been seeing lately:
66.143.146.159 - - [02/Aug/2003:03:29:17 +0100] "GET /default.ida?XXXXXXX[...and on and on...]
stevenha, have you been back to the perfect .htaccess list thread [webmasterworld.com]? I've just recently posted a message there that may help you...
By adding these rules to my .htaccess:
RewriteRule /(cmd¦root¦shell)\.exe$ - [F]
RewriteRule \.ida - [F]
RewriteRule \_vti\_ - [F]
RewriteRule ^NULL - [NC,F]
RewriteRule bin/ - [NC,F]
What is the charachter between the words cmd root and shell as I see a funny squigly line in my browser.
The first line gives a failed response to any cmd.exe, or root or shell command? Is that right.
The second does the same for any .ida as does the thirs with a request for _vti
What does the fourth and fifth lines do?
If I only wanted to stop the _vti appearing as errors in my error logs could I just add this one line only?
RewriteRule \_vti\_ - [F]
What is the benefit of the other lines? (i.e what are they used for?) and finally is there any negative impact of using such code in the users experience?
To deal with the "funny squigly line", which means OR, hunt on your keyboard for a solid vertical line character, or a character that's almost a complete vertical line, but with a small gap in it, like a vertical dashed line. On the US keyword, SHIFT-\ but it could be lots of other places on the keyword, depending on the language.
These rules don't affect users, at all. They are for webmasters who like to examine their access_logs and error_logs in detail. In particular, the error_log records all the unexpected errors and 404 page-not-found events.
One goal of examining error logs, it to find ways that users commonly mis-spell URLs. You'd be surprised how many users, use a search engine to find a page... but then try to manually type the URL instead of clicking on it. I try to spot patterns of these mis-spellings, and route them to the proper pages anyway.
But my error logs were choked with recurring errors caused by worms like nimda, codered, and various exploits to use formmail to send spam.
So the goal of these anti-exploit rules, is to block these exploits and prevent them from causing recorded error_log entries.
Your interpration of the meaning of these rules is right. I didn't implement the ones for NULL and bin/ because they were either very rare, or already fixed by rules higher up.
My current version of these is:
# Recurring exploits causing errors in my logs.
RewriteCond %{REQUEST_URI} cltreq\.asp$ [OR]
RewriteCond %{REQUEST_URI} owssvr\.dll$ [OR]
RewriteCond %{REQUEST_URI} CAPREQ=0$ [OR]
RewriteCond %{REQUEST_URI} u00=a$ [OR]
RewriteCond %{REQUEST_URI} /c\+dir$ [OR]
RewriteCond %{REQUEST_URI} /\_vti\_ [OR]
RewriteCond %{REQUEST_URI} (.?mail.?form¦form¦(GM)?form.?.?mail¦.?mail)(2¦to)?\.?(asp¦cgi¦exe¦php¦pl¦pm)?$ [NC]
RewriteRule .* /worms.txt [L]
( thanks to jdMorgan and balam )
You may notice that I got rid of my default.ida rule, and didn't use the cmd.exe or root or shell variations, since these were all being caught by the rules above them.
RewriteRule /(cmd¦root¦shell)\.exe$ - [F]
RewriteRule \.ida - [F]
RewriteRule \_vti\_ - [F]
RewriteRule ^NULL - [NC,F]
RewriteRule bin/ - [NC,F]The first line gives a failed response to any cmd.exe, or root or shell command? Is that right.
The second does the same for any .ida as does the thirs with a request for _vtiWhat does the fourth and fifth lines do?
If I only wanted to stop the _vti appearing as errors in my error logs could I just add this one line only?RewriteRule \_vti\_ - [F]
What is the benefit of the other lines? (i.e what are they used for?) and finally is there any negative impact of using such code in the users experience?
The only negative impact that I am aware of is the time taken to parse these extra rules.
Jim
So I would like to 403 _vti which can be done as you kindly explained with :
RewriteRule \_vti\_ - [F]
Will this rule block errors? such as domain.com/_vti_bin/owssvr.dll?etc etc
I also want to 403 sun (can I do that?) as I get a lot of requests for domain.com/sun/io/default.class and sun/awt/windows/default.class - So could I simply add :
RewriteRule \sun\ - [F]
The other is MSOffice which gives me errors such as domain.com/MSOffice/cltreq.asp? etc etc - So with this should I do?
RewriteRule \MSOffice\ - [F]
which would give me the three lines plus the fourth for NULL:
RewriteRule \_vti\_ - [F]
RewriteRule \sun\ - [F]
RewriteRule \MSOffice\ - [F]
RewriteRule ^NULL - [NC,F]
I also notice that steveha and jim's code is not the same what is the difference?
Thank you in advance.
RewriteRule \_vti\_ - [F]
RewriteRule ^sun/ - [F]
RewriteRule ^MSOffice/ - [F]
RewriteRule ^NULL - [NC,F]
You should consider reviewing this regular-expressions tutorial [etext.lib.virginia.edu] and this Introduction to mod_rewrite [webmasterworld.com].
Jim
One goal of examining error logs, it to find ways that users commonly mis-spell URLs. You'd be surprised how many users, use a search engine to find a page... but then try to manually type the URL instead of clicking on it. I try to spot patterns of these mis-spellings, and route them to the proper pages anyway.
if you are running on an apache server, mod_speling does wonders in this area ;)
the easiest thing i can say is to give it a try and if it is too slow, then comment it back out of the config and restart the server... AIR, it doesn't take any config options... it just runs... after you set it up, give it a try with some of the misspelings (;)) and see if it gets them right... i use most all of the mod_ addons that come with apache and only occasionally do i get a list of available urls that fit close to the desired one and have to click on one to get where i want to go...
My problem is that the module is not loaded on the server - Is there any way I can by pass that by adding it directly to .htaccess?
I am trying to get the hosts to add it but no luck so far.
i've never tried to add any modules via .htaccess... a quick look at the apache manual for apache v1.3.*, [httpd.apache.org ] shows that addmodule and loadmodule are only available in the server config context... in otherwords, not available via .htaccess... a quick look at the manual for apache v2.* shows the same...
have they stated why they won't load mod_speling? it is a default module that comes with apache even though it is not loaded by default... maybe they are one of those that compile their own apache from the sources and don't have everything necessary to compile mod_speling?
argh! and i was incorrect in my earlier statement about mod_speling not having any other config directives... it does... CheckSpelling on¦off in most all available areas including .htaccess...
Will have to wait and see for that.
I now want to add formmail queries and a query for ticker$COMClassObject.class to this code which was discussed earlier in the thread. How would I do it :
RewriteRule \_vti\_ - [F]
RewriteRule ^sun/ - [F]
RewriteRule ^MSOffice/ - [F]
RewriteRule ^NULL - [NC,F]
Could I just put
RewriteRule \_vti\_ - [F]
RewriteRule ^sun/ - [F]
RewriteRule ^cgi-bin/ - [F]
RewriteRule ^ticker$COMClassObject.class/ - [F]
RewriteRule ^MSOffice/ - [F]
RewriteRule ^NULL - [NC,F]
Obviously I still want my forms and other things in the cgi-bin to work but want to stop getting 404's for formmail, FormMail etc.
Thanks
