From my old experience with my server From time to time we work with clients who would like to upgrade their web sites. Often their site is composed of various one-off applications — typically PHP-based — that someone built for them. More often than not, these applications were not developed with security in mind.
Our first reaction is to pull the plug, analyze, and rebuild a secure and scalable solution. But pulling the plug is usually not an option. If a company relies on an application for leads or sales, they probably can’t afford to shut it down for any length of time. Under these circumstances, triage is usually the best one can hope for.
Fortunately, there are a few things one can do to stem the bleeding. One of the more common problems with PHP-based applications is that they can allow the injection of malicious content, such as SQL or email spam. In some cases we find that over 95% of a client’s ISP traffic is coming from spam injection. The solution? Grab an industrial size helping of Apache mod_security.
ModSecurityTM is an open source intrusion detection and prevention engine for web applications (or a web application firewall). Operating as an Apache Web server module or standalone, the purpose of ModSecurity is to increase web application security, protecting web applications from known and unknown attacks.
Essentially, it inspects web traffic passing through the web server for suspicious content as well as attempts to trigger buffer overflows, etc. When it finds such content, it can stop the traffic and/or log the incident.
To put mod_security to work for you, first, download and unpack the tarball, build and install the DSO, and update Apache’s httpd.conf file.
cd /usr/local; tar xzf /root/modsecurity-apache-1.9.4.tar.gz
cd /usr/local/modsecurity-apache-1.9.4/apache2
/usr/local/apache2/bin/apxs -cia mod_security.c
cd /usr/local/modsecurity-apache-1.9.4/apache2
/usr/local/apache2/bin/apxs -cia mod_security.c
Paste the ModSecurity minimal recommended filtering rules into your httpd.conf file. Here are the first few lines from from the online manual’s Appendix A: Recommended Configuration:
# Turn ModSecurity On
SecFilterEngine On
# Reject requests with status 403
SecFilterDefaultAction “deny,log,status:403″
# Some sane defaults
SecFilterScanPOST On
SecFilterCheckURLEncoding On
SecFilterCheckUnicodeEncoding Off
If you’d just like to see if someone is trying to exploit your site, you can set up ModSecurity to simply audit your traffic. The lines
# Log rule violations, but allow the requests
SecFilterDefaultAction “log,pass”
will do that for you. However, please note that if you want to merely log rule violations without denying the traffic, you must not include any implicit validations (URL encoding validation, Unicode encoding validation, cookie format validation, and byte range restrictions) in your rules.When you are satisfied with your rules, you can deny the traffic by changing the default action to this:
# Deny requests and log with status 403
SecFilterDefaultAction “deny,log,status:403″
Once you’ve got a bunch of traffic in your audit log, you can grep through it to see if you’ve got visitors with bad intentions:
grep -i ‘to|bcc|cc’ audit_log | less
or
grep -i ‘to|bcc|cc’ audit_log | wc -l
or
grep -i ‘to|bcc|cc’ audit_log | wc -l
You may find lots of suspicious lines. In fact, you may find that some spammers are including portions of books, stories, or other nonsense, presumably to get past the final recipients’ Bayesian spam filters.
To block a common PHP mail injection exploit, add a rule like this to your httpd.conf file in the ModSecurity section:
# necessary to stop spammers doing mail injection into PHP mail forms!!!
SecFilterSelective ARGS_VALUES “\n[[:space:]]*(to|bcc|cc)[[:space:]]*:.*@”
SecFilterSelective ARGS_VALUES “\n[[:space:]]*(to|bcc|cc)[[:space:]]*:.*@”
The ModSecurity site also conveniently includes a package of rules, including PHP-related rules, grouped by function. Note that there are “SQL Injection Attack” rules in the “general” conf file. You can include the rule groups you want by using an “Include” directive in the ModSecurity section of your httpd.conf file; i.e. “Include conf/modsecurity-php.conf”.
These rules are a good place to start, as are the rules from gotroot.com. You may need to tweak these a little bit, and be selective in which rulesets you apply. For example, often aggregating IP addresses such as AOL proxies are blocked due to the blacklist rules, which may not be what you want.
This is only a brief introduction, but I hope you will try ModSecurity for yourself, and discover how powerful it can be.
vending machine c...
injection molding
rugged lcd monitors
One Theme
Recent Comments