Defending Against SQL Injection and XSS with ModSecurity (WAF)

While network firewalls like UFW protect your server's ports, and rate limiting mitigates flood attacks, neither of these tools inspects the actual content of the traffic allowed through to your web server. If an attacker sends a perfectly formatted HTTP request on port 443, your firewall will allow it. But if that request contains a malicious SQL injection payload designed to dump your database, or a Cross-Site Scripting (XSS) script targeting your users, standard server defenses are entirely blind to it.

To inspect the payloads of incoming web traffic, you must deploy a Web Application Firewall (WAF). ModSecurity is an open-source, highly respected WAF engine that integrates directly into web servers like Apache and Nginx, actively intercepting and analyzing every GET and POST request before it ever reaches your application code.

Installing the ModSecurity Engine

ModSecurity acts as the processing engine, and it is readily available in the default repositories for Debian and Ubuntu servers. The installation process is most straightforward on the Apache web server, as the module integrates natively without requiring manual compilation.

• Connect to your server via SSH as a user with sudo privileges.

• Update your package manager and install the Apache module: sudo apt update && sudo apt install libapache2-mod-security2

• Once installed, enable the Apache headers module (if not already active) and restart the server to load the WAF engine: sudo a2enmod headers sudo systemctl restart apache2

• Verify the module is loaded by checking the Apache configuration: sudo apache2ctl -M | grep security2

Activating the OWASP Core Rule Set (CRS)

By itself, ModSecurity does nothing; it is an engine without a database. To detect attacks, it requires a rule set. The industry standard is the Open Worldwide Application Security Project (OWASP) Core Rule Set. This is a continuously updated list of thousands of regular expressions that identify SQL injection, local file inclusion, remote command execution, and known malicious bot user-agents.

• Move the default, blank ModSecurity configuration file into place: sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

• Instead of using the outdated OWASP rules packaged with older Linux distributions, download the latest stable release directly from the official GitHub repository into a new folder: sudo git clone [https://github.com/coreruleset/coreruleset](https://github.com/coreruleset/coreruleset) /etc/apache2/modsecurity-crs

• Rename the included setup template to activate it: sudo cp /etc/apache2/modsecurity-crs/crs-setup.conf.example /etc/apache2/modsecurity-crs/crs-setup.conf

To tie the rules to the engine, you must edit Apache's security configuration file (sudo nano /etc/apache2/mods-enabled/security2.conf) to include the OWASP directories:

<IfModule security2_module>
    SecDataDir /var/cache/modsecurity
    IncludeOptional /etc/modsecurity/*.conf
    Include /etc/apache2/modsecurity-crs/crs-setup.conf
    Include /etc/apache2/modsecurity-crs/rules/*.conf
</IfModule>

Configuring "DetectionOnly" vs "On"

A common mistake administrators make is activating ModSecurity in strict enforcement mode immediately. Because the OWASP rules are highly aggressive, doing this will almost certainly block legitimate users (false positives) from uploading large files or submitting complex forms on your website.

You must run the WAF in observation mode first to train it and whitelist your application's unique behaviors.

• Open the main engine configuration file: sudo nano /etc/modsecurity/modsecurity.conf.

• Locate the SecRuleEngine directive. By default, it is set to DetectionOnly. Leave it exactly as it is for the first week of deployment.

• In this mode, ModSecurity evaluates all traffic against the OWASP rules. If it detects an attack, it will not block the connection, but it will write a detailed warning to the audit log (/var/log/apache2/modsec_audit.log).

Auditing Logs and Enforcing Rules

After letting your application run in DetectionOnly mode for a few days under normal traffic, you must review the logs to identify any false positives.

• Monitor the log using the tail command: sudo tail -f /var/log/apache2/modsec_audit.log.

• If you see legitimate user actions triggering a specific rule (identified by a [id "949110"] tag in the log), you can create a custom exception in your Apache virtual host file using SecRuleRemoveById 949110 to ignore that specific check for that specific website.

• Once you have resolved the false positives and are confident the WAF is only flagging genuine attacks, reopen /etc/modsecurity/modsecurity.conf, change SecRuleEngine DetectionOnly to SecRuleEngine On, and restart your web server. Your VPS is now actively dropping malicious application traffic before it can do harm.