Protecting Legacy Applications with Nginx and ModSecurity
Excerpt: Learn how to configure Nginx with ModSecurity as a proxy layer to protect legacy applications, including installation, configuration, and automated email notifications for security incidents.
Introduction
In this article, we’ll walk you through how to protect your legacy applications using Nginx as a reverse proxy with ModSecurity as a Web Application Firewall (WAF). ModSecurity provides a powerful layer of defense against common web attacks, such as SQL injection, XSS, and more. Since legacy applications often lack modern security features, this setup acts as a necessary protective measure without requiring code changes to the legacy system.
Why Use Nginx with ModSecurity for Legacy Apps?
- Security: ModSecurity filters out malicious traffic before it reaches the legacy application.
- Flexibility: Nginx can be used to load balance traffic and handle large-scale operations while ModSecurity provides the protection.
- Non-invasive: The legacy application remains untouched, as ModSecurity and Nginx act as a proxy layer.
Installation and Configuration
1. Installing Nginx with ModSecurity on Ubuntu
- Update the package list:
sudo apt update
- Install Nginx:
sudo apt install nginx
- Install ModSecurity (ModSecurity 3.x):
sudo apt install libmodsecurity3
- Install Nginx ModSecurity Module:
sudo apt install nginx-module-security
- Enable ModSecurity in the Nginx configuration. Edit the Nginx configuration file:
- Add the following lines to enable ModSecurity:
- Restart Nginx:
sudo systemctl restart nginx
sudo nano /etc/nginx/nginx.conf
modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/modsec_rules.conf;
2. Installing Nginx with ModSecurity on CentOS
- Install Nginx:
sudo yum install nginx
- Install ModSecurity:
sudo yum install mod_security
- Enable ModSecurity by modifying the Nginx configuration as done in the Ubuntu guide:
- Restart Nginx:
sudo systemctl restart nginx
sudo nano /etc/nginx/nginx.conf
Configuring ModSecurity with Nginx
Once ModSecurity is installed, you need to configure it to protect the legacy application. One of the first steps is to use a rule set, such as the OWASP ModSecurity Core Rule Set (CRS), but there are alternatives available.
Alternatives to CRS
- Comodo WAF Rules: A popular alternative to the CRS that provides a range of rules for SQL injection, XSS, and other threats.
- Atomicorp WAF: A commercial WAF solution with additional rules designed for high-traffic applications.
- Custom Rules: You can develop your own rules based on the specific vulnerabilities in your legacy app.
Configuring ModSecurity Rules
- Download the CRS rule set (or use an alternative):
git clone https://github.com/coreruleset/coreruleset.git
- Copy the rules to your ModSecurity directory:
sudo cp -r coreruleset /etc/nginx/modsec/
- Configure the rule set file:
sudo nano /etc/nginx/modsec/modsec_rules.conf
- Include the following in your Nginx configuration to enable ModSecurity:
modsecurity on; modsecurity_rules_file /etc/nginx/modsec/modsec_rules.conf;
Automating Email Notifications for Security Incidents
To monitor and respond to incidents effectively, configure ModSecurity to send email notifications when security rules are triggered:
- Edit ModSecurity to send an email:
SecRuleEngine On SecAuditLog /var/log/modsec_audit.log SecAuditLogParts ABIJDEFHZ SecRule REQUEST_URI "@rx /wp-admin" \ "phase:2,deny,status:403,msg:'Possible WordPress Admin Access Attempt',\ log,auditlog,exec:/path/to/your/email/script" - Write a script to send an email when an audit log event is triggered. The script could look like this:
#!/bin/bash tail -n 50 /var/log/modsec_audit.log | mail -s "ModSecurity Alert" your-email@example.com - Make the script executable:
chmod +x /path/to/your/email/script
ModSecurity SecRule Cheat Sheet
Here’s a list of common SecRule directives and their functions:
| SecRule Directive | Function |
|---|---|
| SecRule REQUEST_METHOD | Matches a specific HTTP method (e.g., GET, POST, DELETE). |
| SecRule REQUEST_URI | Matches the URI of the incoming request. |
| SecRule ARGS | Matches input parameters in HTTP requests (such as GET/POST data). |
| SecRule RESPONSE_BODY | Inspects the response body to detect potential threats. |
| SecRule REQUEST_HEADERS | Matches specific headers in HTTP requests (e.g., User-Agent, X-Forwarded-For). |