The most common attack vector against publicly exposed servers is exploiting vulnerabilities in the services those servers provide. Webservers are a welcome target for crackers and script-kiddies: misconfigured servers or buggy software make an easy prey for hacking into.
The following is a very wide-spread, very simple and often successful attack that can be prevented by using mod-security:
The attacker finds a vulnerable script that has write access to the server's file system. This can be done by
- using security-scanner software,
- blind or educated guess or
- by using a known vulnerability in a publicly available service
Then the attacker uses this script to alter a file or upload malware to the server:
this may be a sneaky change to an already existing script which opens a backdoor or some kind of webshell or ircbot.
If that already happened to you: Congratulations, you're now the proud owner of a freshly infected zombie!
If you are a sysadmin and running one ore more webservers with apache you may have been wondering how you could protect those machines from being compromised. There are a few steps you should take before you follow this quick introduction to mod-security:
1. Make sure apache is configured properly. Try to restrict the server from sending unnecessary information about its version, installed services etc. Search and read articles about hardening webservices and apache. Understand how attackers gather information about your servers and what kind of vulnerablity they could be after.
2. Do not run exploitable software. Common targets are unpatched versions of Wordpress etc., webmail-services, and CMSs. If possible, try to restrict access to or avoid tools like phpmyadmin.
3. Make sure potentially exploitable scripts, like php, have no way to write on the filesystem. This is not always practical, but should be manageable: use a development system for file uploads and merge changes into your (read-only) public production system. You may want to use wget to take an html-only-snapshot of your development system for deployment on your production system.
4. If your web-folder (like /var/www) contains any files or directories with permissions like 0777, you're likely to experience problems in the near future. Be sure to understand what you are doing and try to explain your concerns to your users/web-developers. Database access should be configured read-only where no writing to the database is needed.
But now let's start with the HowTo:
mod-security is a very good tool for professionally securing webservers. Once you spent some time with it you wouldn't want to run a webserver without it. By design, mod-security is a web application firewall (WAF) that blocks potentially dangerous requests to your server. But even without taking any action, just by logging, mod-sec can show you how bots or attackers try to exploit your services.
I wrote this HowTo because I could not find any recent documentation on how to quickly set up mod-security on Debian wheezy. This really is only a quick and superficial way to get mod-sec working. Be sure to read further documentation on how to set up and maintain this magnificent tool. (And please point out to me any mistakes I made or possible improvements to this HowTo).
This documentation has only been tested on Debian wheezy (7.3 as of now). It is likely to be broken on any other distro or version.
I'm assuming apache is configured and running. Start by installing mod-security. Note that apache will be restarted in the process:
# apt-get install libapache2-modsecurity
The module is now up and running. It is in no way configured yet, so it still does nothing. Let's configure mod-sec: if your installation went right you now have a set of rules under /usr/share/modsecurity-crs
If you're using wheezy, the config-files are under /etc/modsecurity
Copy the default rules:
# cp -rp /usr/share/modsecurity-crs/* /etc/modsecurity
Make an initial configuration:
# cd /etc/modsecurity
# cp -p modsecurity.conf-recommended modsecurity.conf
# vi modsecurity.conf
Important: the first directive controls mod-sec's behaviour. Until everything is configured and your rules are O.K. it should look like this:
SecRuleEngine DetectionOnly # Do not block anything, just write logs
If you're satisfied, here is nothing more to do right now. Enable the configuration in apache:
# vi /etc/apache2/conf.d/mod-security
with the following content:
<IfModule security2_module>
Include /etc/modsecurity/*.conf
Include /etc/modsecurity/activated_rules/*.conf
</IfModule>
Activate all rules in /etc/modsecurity/activated_rules by setting symlinks:
# cd /etc/modsecurity
# for f in `ls base_rules/` ; do ln -s /etc/modsecurity/base_rules/$f activated_rules/$f ; done
### As the name says the following is optional.
### Some of those rules may lead to PCRE-recursion-limit
### exceptions or missing data errors,
### depending on your configuration.
# for f in `ls optional_rules/` ; do ln -s /etc/modsecurity/optional_rules/$f activated_rules/$f ; done
The preparations are done now. Test the configuration:
# apachectl configtest
You should be getting "Syntax OK" - If not, you're up to some trouble-shooting; please consult your search-engine of choice for solutions - there are plenty!
If you got a "Syntax OK" you're fine. Time to restart apache:
# service apache2 restart
if the server is very busy there should be plenty of false-positives now in /var/log/apache2/modsec_audit.log
That's O.K. for now: mod-sec is up and running.
If there is not enough traffic to trigger alarms you may want to use a security-scanner such as nessus etc. or some simple SQL-injection-attempt to trigger positive alarms.
Now you need to understand the logged errors and find false positives. The better way to cope with those errors is to modify the rule that triggered the alarm to your needs. The fast and insecure way is to deactivate the rule by whitelisting. You can create a whitelist-file with the following example content to whitelist rules:
# vi /etc/modsecurity/activated_rules/modsecurity_crs_99_whitelist.conf
content:
# This client is allowed to bypass mod-sec:
#SecRule REMOTE_ADDR "^192.168.0.3" phase:1,nolog,allow,ctl:ruleEngine=off
#SecRuleRemoveById 90001 # deactivated rule
To activate the changes you need to reload your apache-configuration (I prefer a restart).
When you're confident that the rules are set up correctly you can activate mod-sec's blocking engine in /etc/modsec/modsecurity.conf:
SecRuleEngine On
That's it!
To even further secure your server you could use a tool like fail2ban to block IPs after a certain amount of alarms or logcheck to send you email-notifications on security events.
Keine Kommentare:
Kommentar veröffentlichen