d828cd4d4f
- install etc/apache2x/modules.d/280_mod_security.conf.sample - adjust README and pkg-message to reflect new module activation - adjust and sort pkg-plist Changes: - ModSecurity: update to 2.9.1 - Add support for Lua 5.1 or higher (was 5.1 only) - pkg-plist: bring back mod_unique_id activation, fix deprecated @exec - README: point user to configuration files PR: 208144 Submitted by: Walter Hop (maintainer) MFH: 2016Q2
89 lines
2.9 KiB
Text
89 lines
2.9 KiB
Text
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
|