Layered WAF Security Architecture: Combining Cloudflare, AWS WAF, and ModSecurity

prod Scenario: Context and Requirements

This case study follows a SaaS provider hosting a multi-region application stack. The system processes sensitive customer data across US, EU, and APAC regions while meeting strict compliance standards such as GDPR (General Data Protection Regulation) and CCPA (California Consumer Privacy Act). The provider faces high-volume, multi-cloud traffic and contends with sophisticated threats, including credential stuffing (using stolen credentials to gain unauthorized access), SQL injection (injecting malicious SQL queries), and business-logic abuse (exploiting flaws in application workflows). Their Service Level Agreement (SLA) demands minimal downtime and rapid incident response.

The accompanying photo shows a close-up of a laptop screen displaying website analytics data, such as real-time visitors, pageviews, and active pages, in a dimly lit environment. This visual context is typical for articles about digital marketing, analytics, or online business performance. (Photo via Pexels)

Initially, the team relied solely on Cloudflare Web Application Firewall (WAF). However, after attackers managed to bypass some WAF rules, they shifted to a layered approach. The new architecture integrates ModSecurity, Cloudflare, and AWS WAF. Their objectives include reducing both false negatives (missed attacks) and false positives (legitimate traffic blocked), centralizing logging, enabling custom protections, and optimizing operational costs.

Layered WAF Architecture: Combining ModSecurity, Cloudflare, and AWS WAF

The revised architecture uses multiple layers of protection, each with a specific role:

• Cloudflare WAF at the network edge filters global traffic, providing Distributed Denial of Service (DDoS) mitigation, bot management, and default protections against the OWASP Top Ten (a list of the most common web application vulnerabilities).
• AWS WAF handles AWS-hosted services. It provides geo-blocking (blocking traffic from specified regions), IP reputation filtering (blocking known bad IPs), and integrates with AWS Shield (a managed DDoS protection service).
• ModSecurity runs on NGINX within Kubernetes clusters for deep request inspection. It allows for custom rules and business-logic protections specific to the application.

Below is an example of a custom ModSecurity rule. This rule blocks requests to a sensitive API endpoint:

# Example: ModSecurity custom rule to block suspicious payloads
SecRule REQUEST_URI "@rx /api/v1/sensitive" \
 "id:2001,phase:2,deny,status:403,log,msg:'Blocked request to sensitive API endpoint'"

This layered setup blocks threats at multiple points: at the edge, in the cloud, and within the application infrastructure. It enables granular control over tuning and exceptions.

Operational Flow

• Traffic first hits Cloudflare, which blocks known malicious IPs and DDoS attempts.
• Requests routed to AWS load balancers pass through AWS WAF, which applies geo-blocking and IP reputation rules.
• Within the Kubernetes cluster, NGINX with ModSecurity inspects requests for application-specific threats and enforces business policies.

For example, a request from a suspicious IP in a blocked region would be dropped by AWS WAF before reaching the application. If a crafted request passed Cloudflare and AWS WAF, ModSecurity could still block it based on custom business logic.

This architecture provides fast threat mitigation at the edge, centralized cloud-level controls, and detailed application inspection for complex logic.

ModSecurity in prod: Operational Lessons and Tuning

Deploying ModSecurity at scale uncovered several practical lessons:

• Rule tuning is ongoing. The default Core Rule Set (CRS) often generates false positives, especially with APIs or custom payloads. For instance, a legitimate API call containing JSON data might trigger a CRS rule meant to block SQL injection. Teams regularly analyze logs to identify these patterns and adjust rules accordingly.
• Performance management. Untuned rules can slow down request processing. For example, complex regular expressions (regexes) in rules may add noticeable latency. Use tools like modsec_auditlog to profile which rules consume the most resources. Disable or rewrite those that cause significant delays.
• Logging forensics. Enable detailed, structured JSON logs to capture request and response data. Reviewing these logs helps identify both false positives and attack trends. For instance, seeing repeated blocked requests to a specific endpoint may indicate an attacker probing for vulnerabilities.
• Frequent patching. Subscribe to security advisories (such as GSA-6105-1) to keep the CRS and custom rules current. New vulnerabilities often require prompt rule updates.
• Custom rules crafting. Use the SecRule syntax to tailor rules for your application’s logic. For example, rate-limiting rules can block automated abuse of sensitive endpoints.

# Example: Block rapid requests at specific endpoint
SecRule REQUEST_URI "@beginsWith /api/v1/transfer" \
 "phase:2,deny,id:3002,log,msg:'Rate limit exceeded',chain"
SecRule IP:REQS_PER_MIN "@gt 30"

For more detailed configurations and best practices, see the full ModSecurity deployment guide.

Limitations and Alternatives: ModSecurity and Beyond

While ModSecurity is the most flexible open-source WAF, it presents several challenges:

• Complexity. ModSecurity requires expertise in its rule syntax and regular expression crafting. Writing and maintaining rules for new threats or business logic can be time-consuming.
• Scaling. Without careful tuning, ModSecurity can increase CPU usage and introduce request latency. For example, enabling all default rules on high-traffic endpoints may degrade application response times.
• Support gaps. Community support remains active, but enterprise support is becoming less available as of 2024. Organizations may need to rely more on internal expertise.

Alternatives include:

• F5 Silverline WAF: Commercial, fully supported, and provides easier management through a graphical interface.
• Cloudflare WAF: Fully managed, requiring minimal operational overhead. Updates and patches are handled automatically.
• AWS WAF: Integrates directly with AWS services. Uses YAML or JSON for rule management and scales with AWS resources.

The best choice depends on your team’s operational expertise, the level of control you require, and compliance needs.

Detection and Monitoring: Beyond Signature Blocking

Modern WAFs require more than just matching signatures against known attack patterns. They must provide:

• SIEM (Security Information and Event Management) integration. This allows real-time alerting and centralized dashboards for security incidents. For example, integrating WAF logs with Splunk or Elasticsearch enables tracking suspicious activity across the environment.
• Enhanced audit logs. Capturing full request and response data (with personally identifiable information masked) supports incident investigations and compliance checks.
• Behavioral analytics. Detecting evasion techniques, such as encoded payloads or request chaining, helps identify attacks that bypass traditional signatures.
• Periodic rule validation. Replay attacks, fuzzing (automated testing with random data), and security testing frameworks validate that rules block actual threats and do not generate excessive false positives.

Operational teams often visualize key metrics such as top rule triggers, frequent source IPs, targeted URIs, and recurring attack patterns. For instance, a dashboard might highlight that a particular rule is triggering hundreds of times per hour, signaling either an ongoing attack or a misconfiguration. Regular reviews of these metrics help teams refine rules and improve detection accuracy.

Checklists and Pitfalls: What to Audit in Your WAF Stack

To maintain a secure and efficient WAF deployment, audit the following:

• Are all rules and signature updates current?
• Is logging complete and centralized across all WAF layers?
• Are false positives regularly reviewed and scoped?
• Are custom rules validated for performance impact?
• Is there automation for rule updates and incident response?
• Are rule exclusions scoped and documented?
• Are performance metrics monitored, and is latency acceptable?

For example, teams should automate rule updates where possible, such as integrating WAF signature feeds with their deployment pipeline. Documenting exclusions ensures that temporary exceptions do not become permanent vulnerabilities.

Comparison Table: Cloudflare WAF, AWS WAF, and ModSecurity

Next Steps

Layered WAF deployments using Cloudflare, AWS WAF, and ModSecurity can provide strong security while reducing false positives. Success relies on continuous tuning, guided by logs and observed attack patterns. Regularly review your WAF configuration, automate rule updates where possible, and document all exceptions.

Begin your next tuning cycle by collecting logs in detection mode, identifying false positives, and crafting precise exclusions. For more detailed configurations, see the full WAF comparison and deployment guide.