Forum Moderators: phranque
viewtopic.php?t=7010&highlight=%2527%252Esystem(chr(112)%252Echr(101)%252Ec
/viewtopic.php?t=9813&highlight=%2527%252Esystem(chr(112)%252Echr(101)%252Echr(114)%252Echr
Since they all have that "Esystem(chr(112)" I thought I should be able to block them by url request using two wildcards. I know enough of .htaccess to know where to put things but I really don't know the syntax for putting in two wildacrds, one before the expression and one after the expression. I'd like to deny them entirely or send them somewhere else with a rewrite condition.
This attack has been going on four 6 hours now.
Are you sure you want to do this?
About all you'll have left are members with galoshes and MacIntoshes if I have that right. - Larry
You are correct: most user agents have Mozilla/4.0 in them but they look something like this:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
The person who was attacking/siphoning my site was using JUST mozilla/4.0 as a user agent with nothing else (no compatable stuff at the end). That is what I blocked.
I just verified with my logs. The good Mozilla user agents are getting all 200's but the bad guy is getting 302's so I think I got it right.
(The ban script grabs the IP address, and adds it to the .htaccess file living in my /blogs/ directory, with a related email notifying me which I get on my Treo immediately. The basic script was found on this site, but I don't recall where. Try a search on ban script. )
Thanks. That was another option. I've pretty much found that most of the baddies use a blank referrer as this guy was using as well. But i was hesitant to block all blank referrers because I wondered if there was some legitimate use for them. Are there any legitimate requests with blank referrers?
BTW, that is a nice tidy solution.
First, don't 302 bad guys. If you 302 them to some other site, you're contributing to the problem. If you 302 them to your own site, then your server will have to handle *another* HTTP request if they follow that 302.
Instead, use a simple 403-Forbidden response, as in:
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0$ [OR]
RewriteCOnd %{QUERY_STRING} Esystem [OR]
RewriteCond %{HTTP_USER_AGENT} ^-$ [OR]
RewriteCond %{HTTP_REFERER} ^-$
RewriteRule .* - [F]
If you have defined a custom 403 error page, then it will be served with the 403 response code. So keep that page very short to save bandwidth. You'll also need to modify the code above to *allow* the server to serve your custom 403 page, by adding
RewriteCond %{REQUEST_URI} !/path_to_your_custom_403_page\.html$ Second, do not block blank referrers unless you have absolute control over your user-base -- as in a corporate intranet environment. Many ISPs and corporations use caching proxies to control internet bandwidth costs, notably AOL. And some visitors will be using Norton Internet Security or similar, which can block referrers. In many or even most cases, these visitors will have no idea what an HTTP referrer is, much less know that they are not providing one -- or how to change that (if it's even possible). If you block blank referrers on a commercial site, you are going to need a 24/7 help desk.
If controlling access to your content is so important that you feel a compelling need to block blank referrers, this is a very good indication that it's time to add serious access-control mechanisms to your site. HTTP_Referer-based access control is simple, but limited. Sometimes it can be enough, even allowing for blank referrers. But it is unreliable at best. Using a cookies-based access-control script is a much better solution.
Ban malicious visitors with this Perl script - continued [webmasterworld.com] (See also links to previous threads)
Jim
Thanks. As always you've posted a very thoughtful and professional reply. I've now switched it so that my bad guys are now getting 403ed instead of 302ed.
It has worked very well.
(1) It stops them right at the door.
(2) I'm not adding some php code to my pages that I'm going to forget about later.
I know what everything in my .htacess is for. With the exception of a few 302 redirects, it's mostly to block the bad guys. And the defense is all centralized.
Anybody care to comment on the advantages of modifying the php code as opposed to the .htacess code. Smaller .htacess = faster processing for the rest of the site maybe?
When using the .htaccess solution 296 bytes were still consumed by the hit. With the .php solution 0 bytes are consumed. I prefer the lower drain on bandwidth, etc. I used the other solution too and it worked well.
Bandwidth and time are a consideration but I think for this one I like keeping the defense centralized under .htaccess.
For anybody who runs into similar multiple requests for view-topic like I was getting, it is the 'Santy worm' that has been defacing phpBB boards that haven't been upgraded to 2.0.11. The thread the Swordman mentioned is a good start. I was wrong about it being an e-mail siphoner.
Excuse me for I'm a bit late on this thread.
The following code :
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0$ [OR]
RewriteCOnd %{QUERY_STRING} Esystem [OR]
RewriteCond %{HTTP_USER_AGENT} ^-$ [OR]
RewriteCond %{HTTP_REFERER} ^-$
RewriteRule .* - [F]
...will match :
(any user agent beginning with "Mozilla/4.0")
OR
(any query string containing Esystem)
OR
(Any user agent string equal to "-")
Should not it be logical ANDs instead of ORs? Banning any Mozilla/4.0 UA seems a bit harsh. Following my own log files, many of my visitors would be banned.
The pattern ^Mozilla/4\.0$ is fully-anchored and therefore matches only a User-agent exactly equal to "Mozilla/4.0". This is not a valid Mozilla User-agent. Valid Moz User-agents contain "Mozilla/4.0 (compatible; ... ", not just the Mozilla/4.0 part.
I suspect that none of your legitimate visitors would be banned.
Similarly, blocking User-agents and Referrers exactly equal to "-" is not equivalent to blocking blank entries. The "-" we're blocking is a literal hyphen, and is used maliciously in a deliberate attempt to bypass webmaster blocks on blank referrers and UAs, but to appear to be blank in your logs because of Apache's logging format, where blanks are shown as hyphens.
Regular-expressions pattern anchoring is covered in the tutorial cited in our forum charter.
Jim
However some browsers give their user their opportunity to change the user-agent string. Lynx -I'm a Lynx user- and Opera (AFAIK) provide this feature. It's useful not to bounce on a IE-only website.
Some time ago, I've found these string within my log file:
/mypage.php&highlight=%2527%252esystem(chr(99)%252echr(100)2[... big bunch of chars...]%2527 HTTP/1.0" 403 1411 "-" "lwp-trivial/1.35" 0
Same "&highlight=" and "esystem", but with another UA string.
