This document describes the best practice definitions based on the experience of the Red Button company. The experience includes implementation with many customers, testing and participating in real DDoS attacks that Akamai WAF was the main defense.

[1] Every time a setting is changed in WAF, the user is required to approve a new version. Before going into the technical details of the DoS protection within the version, make sure that the version settings are correct:

Inspection

Evasive URL Request Matching - off - Attackers may try to evade protections by requesting URLs that are similar to but don't match your real URLs. To keep these fuzzing attacks from reaching your origin, turn on Evasive URL request matching. It applies protections to any URL that come close to matching URLs you specify as protected resources in API definitions or in match targets.

Request Size Inspection Limit - Evaluation inspects request bodies up to a certain size. The default size is 8KB and can be changed. The user should consider the max acceptable size, and set the threshold accordingly.

Logging - On

In each version, the user can set several security policies. In each security policy, the user can configure up to 1,000 hostnames to be covered by the WAF policy. In each policy, the security measures are:

Red Button's best practice for security policy DDoS protection is:

[1] IP/Geo Firewall - To reduce the attack surface, we recommend blacklistiing countries, IP addresses, subnets, and ASNs where traffic is not allowed. Using this tool is DDoS safe, as Akamai's FW equipment in the cloud can withstand massive traffic.

[2] DoS Protection - 

2.1 Layer 3 / Layer 4 Protections - Enabled 

2.2 Rate limit policies - Used - The user can set up to 10 rate limit policies in each security policy. We recommend covering all HTTP methods and all error codes. The initial thresholds aren’t that critical and can be set as Akamai defaults in ‘Count’ mode. After weeks-months of baseline traffic learning by Akamai, the tuned threshold will be set, and the rate limit policy action will be changed to ‘Deny’. 

Rate limit policy technical recommendation:

Count - Requests from client to the edge

Client Identifier - Client IP

Don’t make use of Request header "X-Requested-With" does not match (it makes the policy useless)

Burst threshold (5 seconds period) - Tends to act unreliable - Set to high threshold

Average threshold (120 seconds period) - Tends to act reliably - Set to the lowest threshold that doesn’t cause false positives.

2.2 Slow POST protection - On - default (by Slow rate threshold)

[3] Web Application Firewall 

The only set of rules that relevant to DDoS is ‘Web Attack Tool (20 / 20)’. We recommend to set them on ‘Deny’ on Risk scoring mechanism, in the default settings by Akamai.

[4] Client Reputation - On

DoS Attackers (High Threat) - Deny

DoS Attackers (Low Threat) - Deny

Conclusion

Following these best practices enhances the security and resilience of Akamai WAF, improving protection against DDoS attacks while ensuring legitimate traffic flows smoothly. Adjust policies based on traffic analysis and security needs to maintain optimal protection.