Has anyone tried using Managed Rules for a WordPress site? How'd it go?

Hello everyone,

I've been helping a team migrate their WordPress workloads to Kubernetes (EKS, specifically) and we recently implemented AWS WAF with the AWS Managed Rules for WordPress. Since this is a common use case but I don't see many deep-dives on it in our community, I thought I'd share our experience and configuration approach. Our primary goals were to mitigate common application layer attacks (SQLi, XSS) and reduce the noise from automated scanners and comment spam, without breaking the core WordPress functionality or its admin panel.

We started with the **AWSManagedRulesWordPressRuleSet** and the **AWSManagedRulesAdminProtectionRuleSet**. The WordPress rule set is tuned for the application itself, while the Admin Protection rule set is crucial for shielding the `/wp-admin` and `/wp-login.php` endpoints. The initial deployment was straightforward via Terraform, but we immediately ran into a classic problem: false positives.

Here's a snippet of the core Terraform resource we used, which might be helpful:

```hcl
resource "aws_wafv2_web_acl" "wordpress" {
name = "wordpress-managed-rules"
scope = "REGIONAL"
description = "WAF ACL for WordPress on EKS ingress"

default_action {
allow {}
}

rule {
name = "AWS-AWSManagedRulesWordPressRuleSet"
priority = 10
override_action {
none {}
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesWordPressRuleSet"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "AWSManagedRulesWordPressRuleSet"
sampled_requests_enabled = true
}
}

rule {
name = "AWS-AWSManagedRulesAdminProtectionRuleSet"
priority = 20
override_action {
none {}
}
statement {
managed_rule_group_statement {
name = "AWSManagedRulesAdminProtectionRuleSet"
vendor_name = "AWS"
}
}
visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "AWSManagedRulesAdminProtectionRuleSet"
sampled_requests_enabled = true
}
}

visibility_config {
cloudwatch_metrics_enabled = true
metric_name = "wordpress-waf"
sampled_requests_enabled = true
}
}
```

The main challenges we faced and how we addressed them:

* **Blocked Admin Actions:** Certain plugin operations in the admin dashboard, like uploading themes or updating via the built-in installer, were being blocked. The requests often contained PHP-like strings or used specific query parameters that triggered the rules.
* **Solution:** We didn't disable the rules. Instead, we used **rule action overrides** to switch the action for specific rules from `Block` to `Count`. This allowed us to monitor the traffic without impacting users. We identified the specific rules causing issues (e.g., `WordPress_Generic` and `WordPress_Applications`) and created overrides for them, but only for the source IP range of our internal admin users.

* **Comment and Search Functionality:** Some legitimate user-generated content in comments or complex search queries were flagged.
* **Solution:** We implemented a combination of logging and custom rules. First, we ensured WAF logs were shipped to S3 and analyzed in Athena. We then added a custom rule at a higher priority (lower number) to allow traffic from users who had passed a CloudFront CAPTCHA (using AWS Lambda@Edge) on the comment form, effectively whitelisting them from some of the stricter managed rules.

* **Performance Impact:** We monitored latency introduced by the WAF. For our traffic volume, the impact was negligible (<5ms p99) when attached to the Application Load Balancer (ALB) ingress for our WordPress pods.

Overall, the managed rules provided a strong, maintenance-free baseline of security. The key to success was not deploying them and walking away, but actively using the visibility tools (CloudWatch Metrics, WAF Logs) to tune them. The Admin Protection rule set was particularly valuable in reducing brute-force login attempts visible in our application logs.

I'm curious if others have taken a similar path. Did you integrate the managed rules with a CI/CD pipeline for WordPress updates? Has anyone combined these with AWS Shield Advanced for DDoS protection on the same resource, and did you notice any interaction issues?

kubectl apply -f