Adding a WAF to an existing IIS infrastructure doesn’t necessarily require changing the web servers or applications.
In this setup, an Ubuntu server running Nginx, ModSecurity v3, and OWASP Core Rule Set (CRS) was deployed between the firewall and internal IIS servers.
Architecture
- The firewall forwards incoming web traffic to the Nginx gateway.
- Nginx uses SNI-based routing to forward HTTPS traffic to the appropriate backend.
- Selected applications use Nginx as a reverse proxy, allowing ModSecurity to inspect HTTP requests.
- Other services can continue using TLS passthrough without terminating SSL on the gateway.
ModSecurity Configuration
ModSecurity v3 was integrated with OWASP CRS 3.3.9. Initially, the engine was configured in DetectionOnly mode to identify potential attacks without blocking legitimate requests.
A simple SQL injection test was performed:
curl -sk -i -G 'https://portal.example.com/' \
--data-urlencode "test=1' OR '1'='1"The audit log successfully reported:
- 942100 – SQL Injection detected via libinjection.
- 949110 – Inbound anomaly score exceeded.
This confirmed that ModSecurity and OWASP CRS were inspecting incoming requests correctly.
Key Takeaways
- A separate Nginx gateway can add a WAF layer without modifying the IIS applications.
- TLS passthrough and reverse proxy can coexist, depending on the application.
DetectionOnlyis a sensible starting point before enabling blocking.- Real application traffic should be monitored for false positives before switching to enforcement mode.
Important: When using this architecture, client IP forwarding must be handled explicitly. Also, hiding the backend’s Server header is useful for reducing information disclosure, but it is not a substitute for actual security controls.
This approach provides a practical way to introduce application-layer inspection into an existing Windows/IIS infrastructure with minimal changes to backend systems.