F5 Waf Configuration Guide

Getting F5 WAF working the way you actually need it

F5 WAF Configuration Guide. That is what most people search for when they first try to slap a policy on their ASM bigip and realize it is not as simple as clicking "enable." The documentation is fine, but it assumes you already know the terminology and the traps. I spent three days last year untangling a WAF policy that was blocking legitimate inventory API calls because a custom header was triggering a signature match, so here is how to actually configure this without shooting yourself in the foot. The first thing you do after deploying your ASM policy is set it to learning and blocking mode. Most people start with blocking right away and then spend two weeks tuning by hand instead of letting the policy learn the traffic baseline. You create the policy through the BIG-IP GUI under Security -> Application Security -> Policy Building Wizard. The wizard walks you through selecting a signing key, picking the network topology, and defining which virtual servers the policy attaches to. It sounds straightforward until you actually get there. One thing the official guide does not emphasize enough: the difference between URL-only and full request inspection matters. If you leave request inspection off, the WAF only checks the URI and parameters. It will miss body payloads, JSON POST data, and multipart uploads. Turn on full request inspection for anything handling APIs or file uploads. It adds latency, roughly 2 to 4 milliseconds per request depending on your hardware, but it actually catches things.

Signature verification is another area where people go wrong. There are two modes: strict and relaxed. In strict mode, the WAF requires every signature to have a verified match before it blocks. In relaxed mode, it blocks on a lower threshold and logs suspicious activity. Most production environments should start in relaxed mode with logging enabled, then review the audit log for a few days before switching to strict. I learned that the hard way when a client's checkout flow got blocked because a payment gateway parameter happened to match an SQL injection signature in strict mode. The fix was to add an exception for that specific parameter path in the signature set, not just disable the signature entirely. Here is a realistic problem I ran into last year that the documentation barely covers. We had a React application sending form data as URL-encoded payloads with nested JSON objects inside the parameters. The WAF's default heuristic inspection model flagged the nested JSON structure as anomalous and started blocking requests in blocking mode. The workaround was not to lower the sensitivity across the board, which would have weakened security. Instead, I created a custom anomaly scoring override for that specific virtual server, set the heuristic inspection to disabled for that policy, and added a custom signature that matched the legitimate payload pattern and assigned it a negative score. That effectively whitelisted the known-good traffic while keeping the rest of the heuristic engine active. It took about four hours to dial in because you have to test each change in monitoring mode first, but it avoided the nightmare of maintaining a long block of individual exclusions.

Advanced configuration details most guides skip

The protocol dictionary is one of those settings that silently controls whether your WAF works or fails. F5 ships with a built-in protocol dictionary for HTTP, HTTPS, SOAP, and a few others. If you are protecting a custom binary protocol or a non-standard API format, the default dictionary will not understand it, and your policy will either pass everything through or block everything. You can create a custom protocol dictionary, but it is tedious and requires you to define exactly how the protocol frames requests and responses. For most REST and SOAP APIs, the built-in dictionaries are sufficient if you configure them properly. White listing by IP is common but often misused. I see teams create massive allow lists for entire subnet ranges because someone complained about a false positive. The correct approach is to scope exceptions as narrowly as possible. An IP exception should target a single virtual server or even a single URL pattern, not the entire policy. There is a setting called "bypass policy" that some admins use incorrectly thinking it removes all WAF checks for selected IPs. It does, which means those requests are completely unprotected. Use it sparingly and only for internal health check endpoints or monitoring tools that genuinely cannot conform to WAF expectations. Response body inspection is another feature most people ignore. By default, the WAF inspects requests but not responses. This means it will catch an injection attempt in the input, but it will not detect if your application returns sensitive data in error messages, like stack traces or database query strings. Enabling response body inspection is available in newer versions of ASM, but it increases memory usage significantly. On a VE deployment, expect your RAM consumption to rise by roughly 20 to 30 percent when you enable it across multiple policies. If you are running on constrained hardware, this might be a dealbreaker.

Known limitations and when to look elsewhere

F5 ASM is powerful but it has real bottlenecks. The policy editing interface is slow when you have more than fifty signatures configured, and saving a large policy can take thirty seconds or more. The logs are detailed but storing them locally fills up disk quickly, so you need to forward them to a SIEM from day one. Also, F5 WAF is hardware dependent. If you are running on an F5 VE in a cloud environment, the throughput will be noticeably lower than bare metal, and you will hit licensing limits before you hit performance limits in many cases. For modern cloud-native applications, especially microservices with heavy API traffic, F5 ASM might be the wrong tool. It is designed for perimeter defense around traditional web applications, not for service mesh level inspection. If you are running Kubernetes with Istio or Linkerd, a service mesh sidecar proxy or a dedicated API gateway like Kong or AWS API Gateway with its native WAF integration will give you finer granularity and better performance at the cost of different operational complexity. Use F5 ASM where it makes sense, which is at the edge in front of legacy or monolithic applications. Another thing to keep in mind is that F5's JSON inspection has limitations. It handles flat JSON structures well, but deeply nested objects or arrays with mixed types can trigger false positives that are difficult to resolve without creating custom signatures. There is no built-in schema validation, so you cannot define what a valid request body should look like and let the WAF enforce the structure. You have to approximate validation through signatures and exceptions, which is never as clean as true schema enforcement.

Quick reference for the essential settings

Start every new policy in learning and blocking mode. Run it for at least forty-eight hours before switching to blocking. Check the audit log daily for false positives. Keep request inspection enabled. Set signature verification to relaxed until you have reviewed the logs. Create exceptions by URL pattern, not by broad IP ranges. Forward logs to your SIEM immediately. Test policy changes in a staging virtual server before applying them to production traffic. These steps are boring but they prevent the kind of outages that make security engineers cry at 2 AM.