SiteHost

Working with ModSecurity on Apache+PHP containers

ModSecurity is a powerful web application firewall (WAF) engine for Apache that provides protection against a wide range of attacks. Newer SiteHost Apache containers come with ModSecurity and the OWASP Core Rule Set (CRS) pre-installed but disabled by default to ensure maximum compatibility with your applications.

Enabling ModSecurity

ModSecurity is enabled by creating symlinks in your Apache mods-enabled directory. This follows the standard Apache module pattern and means the module is only loaded when you want it active.

To enable ModSecurity, create the following two symlinks in /container/config/apache2/mods-enabled/:

cd /container/application/config/apache2/mods-enabled
ln -s ../mods-available/security2.load security2.load
ln -s ../mods-available/security2.conf security2.conf

Then restart the container for the change to take effect.

To disable ModSecurity, remove those symlinks and restart:

rm /container/config/apache2/mods-enabled/security2.load
rm /container/config/apache2/mods-enabled/security2.conf

Default Configuration

When enabled, ModSecurity runs in DetectionOnly mode by default — it logs rule matches without blocking any traffic. This is the safest starting point, letting you review the audit log and add exceptions before switching to blocking mode.

Other defaults:

  • OWASP Core Rule Set (CRS): Version 3.3.x is pre-loaded and active once the module is enabled.
  • Audit Logs: Stored at /container/logs/apache2/modsec_audit.log.
  • Persistent Data: ModSecurity state and data are stored at /container/system/modsecurity/.

Switching to Blocking Mode

Once you are satisfied that there are no false positives affecting your application, switch to blocking mode by adding the following to a file in /container/config/modsecurity/:

Create /container/config/modsecurity/0-modsecurity-base.conf:

SecRuleEngine On

Restart the container to apply the change.

Customizing Rules

All .conf files placed in the following directory are automatically included in the Apache configuration:

/container/config/modsecurity/

Examples of Customizations

To disable a specific rule (e.g., if it causes a false positive): Create a file at /container/config/modsecurity/exceptions.conf and add the rule ID you wish to exclude:

SecRuleRemoveById 942100

To add a custom security rule: Create a file at /container/config/modsecurity/custom-rules.conf:

# Block requests containing a specific malicious string in a parameter
SecRule ARGS:testparam "@contains badstuff" "id:10001,deny,status:403,msg:'Malicious string detected'"

Testing the Firewall

Once in blocking mode (SecRuleEngine On), you can confirm ModSecurity is active by sending a simple XSS test:

curl -I "http://your-site-url.com/?q=<script>alert(1)</script>"

You should receive a 403 Forbidden response. In DetectionOnly mode the request will succeed but the match will appear in the audit log.

Troubleshooting

If your application is being blocked unexpectedly:

  1. Check the Audit Log: Look at /container/logs/apache2/modsec_audit.log to identify which rule ID is being triggered.
  2. Switch back to DetectionOnly: Create or update /container/config/modsecurity/engine.conf with SecRuleEngine DetectionOnly to allow traffic while still logging, giving you time to add exceptions for false positives.