Configuring ModSecurity on FreeBSD ---------------------------------- To enable ModSecurity in Apache, follow the instructions in %%PREFIX%%/%%APACHEETCDIR%%/modules.d/%%APMOD_FILE%% ModSecurity has various configuration options. To change them, edit the following file: %%ETCDIR%%/modsecurity.conf Getting the Core Rule Set ------------------------- ModSecurity requires firewall rule definitions. Most people use the OWASP ModSecurity Core Rule Set (CRS). The easiest way to track the OWASP CRS repository right now is to use Git. Let's make a directory for all our ModSecurity related stuff, and clone the CRS repository under it. pkg install git cd %%ETCDIR%% git clone https://github.com/SpiderLabs/owasp-modsecurity-crs cp owasp-modsecurity-crs/modsecurity_crs_10_setup.conf.example \ crs.conf The CRS has various config options. To change them, edit crs.conf. To activate the CRS base rules, add the following to your httpd.conf: Include etc/modsecurity/owasp-modsecurity-crs/base_rules/*.conf You can also add custom configuration and CRS exceptions here. For instance, you might want to disable rules that generate false positives. Example: SecRuleRemoveById 960015 Starting ModSecurity -------------------- When the configuration is all set, simply restart Apache and confirm that ModSecurity is loaded by checking Apache's log file: apachectl restart tail /var/log/httpd-error.log Configuring blocking mode ------------------------- Now that ModSecurity is active, try making a suspicious request to your web server, for instance browse to a URL: http://www.example.com/?foo=/etc/passwd. The CRS has a rule against this type of request. After browsing to the URL, you should now see the request logged in /var/log/modsec_audit.log. You'll notice that the request succeeds, and the response is sent to the browser normally. The reason is that ModSecurity runs in "DetectionOnly" mode by default, in order to prevent downtime from misconfiguration or heavy-handed blocking. You can enable blocking mode simply by editing modsecurity.conf and changing the following line: SecRuleEngine On Again, restart Apache. Now, make the same suspicious request to your web server. You should now see a "403 Forbidden" error! In practice, it's probably best to keep SecRuleEngine DetectionOnly for some time, while your users exercise the web applications. Meanwhile, you should keep an eye on /var/log/modsec_audit.log to see what is being blocked. If there are any false positives, you need to mitigate this by writing custom exceptions. Maintenance ----------- An essential resource for working with ModSecurity is the ModSecurity Handbook by Ivan Ristic. ModSecurity exposes quite some internals, and it's good to scan this book before you start writing custom rules and exceptions. You probably want to keep the CRS updated from time to time. You can do this with Git: cd %%ETCDIR%%/owasp-modsecurity-crs git pull apachectl restart