How to Tune F5 BIG-IP Advanced WAF

2026-07-29T10:15:00+10:00

An F5 policy has three separate controls between a signature match and a blocked request.

The policy has an enforcement mode. Each violation has Learn, Alarm and Block settings. Each signature or policy entity can also be in staging.

Record all three before changing the policy.

Start a new policy in Transparent mode

Set a new policy, a major policy revision or a newly protected application to Transparent under Security > Application Security > Policy Building > Learning and Blocking Settings.

Transparent mode allows requests through while the policy records violations. F5 normally generates a learning suggestion when the violation has Learn enabled. Save the change and select Apply Policy.

Blocking mode behaves differently. A request is blocked only when the policy is in Blocking mode, the violation has Block enabled and the matching entity or signature has left staging. F5 documents the interaction between enforcement mode, violation actions and staging.

F5 calls the staging window the Enforcement Readiness Period. The default is seven days. During that period, the policy does not enforce staged signatures or entities. Configure learning and logging to capture their matches. The policy settings guide explains Transparent mode and enforcement readiness.

Seven quiet days prove only that the traffic seen during those days was quiet. Include month-end jobs, imports, account recovery, administration, checkout, API writes and other flows that ordinary browsing misses.

For an established blocking policy, stage the signatures or entities affected by a change. The rest of the policy can remain in force while those changes collect traffic.

Log staged signature matches

The default logging profile records illegal requests. A staged attack-signature match can be allowed and therefore needs an explicit logging choice.

Create or edit an application-security logging profile under Security > Event Logs > Logging Profiles. Set the request filter to Illegal requests, and requests that include staged attack signatures. Associate the profile with the virtual server that runs the security policy.

F5 supports local and remote logging profiles. Local logging competes for resources on the BIG-IP system; remote logging can send CSV, key-value or CEF records to a reporting system. F5 documents the logging destinations, staged-signature filter and virtual-server association.

Keep these fields for each investigation:

security policy and virtual server;
support ID and event time;
hostname, URL and method;
violation name;
attack-signature ID and attack type;
parameter, cookie, header or request area that matched;
matched data;
violation rating;
enforcement mode and staging state;
application response.

The support ID ties a user-facing block page to the stored request. The violation rating runs from 1 to 5. F5 describes 1 as most likely a false positive and 5 as most likely an attack. Use the rating to order the work, then read the request and ask the application owner what the input means. F5 lists the request details and explains violation ratings.

Group events by policy, violation, signature ID, URL, method and named request field. A signature firing in comment on POST /api/tickets needs a different review from the same signature firing in an authentication parameter.

Request logs may contain credentials, personal information and customer text. Mark account numbers, tokens and other secrets as sensitive parameters so F5 masks their stored values. F5 documents the sensitive-parameter setting and log masking.

Read the request behind each learning suggestion

Traffic Learning turns observed violations and new entities into proposed policy changes. Open Security > Application Security > Policy Building > Traffic Learning, select the policy and inspect the requests attached to each suggestion.

Accept Suggestion changes the policy. Treat it like any other configuration change.

Manual learning waits for an operator to accept a suggestion. Automatic learning can apply most suggestions after F5 has seen enough traffic, sessions, time and source addresses. Manual learning keeps each relaxation visible while a new or sensitive application is being tuned. F5 describes Manual, Automatic and Disabled learning modes.

A busy suggestion can still describe a busy attack. Confirm that the requests reached the expected application path, parsed successfully and produced the expected business result.

Ask the developer who owns the endpoint:

what values the field accepts;
how the application parses them;
whether the value is stored, rendered or executed;
which server-side validation protects it;
whether the field has the same meaning on every URL;
which test request reproduces the legitimate match.

Accept a suggestion only after its scope matches the application behaviour. Ignore removes a suggestion from the normal Traffic Learning view; it does not repair a false positive. F5 lets operators accept, delete or ignore suggestions and inspect the requests behind them. The Traffic Learning guide documents those actions.

Check how F5 parsed the body

A JSON request treated as unparsed content produces different signature targets from a JSON request split into named parameters.

Check the allowed URL and its Request Body Handling setting. F5 can parse form data, JSON or XML, or scan an unparsed payload with content and value signatures. A JSON or XML setting also names the content profile used for validation. F5 lists the request-body handling modes in its allowed-URL documentation.

Match the profile to the content type the application accepts. Associate the profile with the correct URL or parameter. Reproduce malformed bodies with the same bytes because the application and F5 may recover from parser errors differently.

Use explicit parameters for fields that need their own policy. F5 supports global, URL and flow parameters, and applies the most specific definition first: flow, then URL, then global. A free-text comment field on one endpoint usually belongs at URL level.

The Ignore value parameter type removes parameter-based signature checks from that value while leaving other relevant signature checks active. A one-signature override removes less inspection. Reserve Ignore value for data the application genuinely does not interpret.

Put the exception on the field or URL that needs it

F5 exposes several scopes for an attack-signature override:

one signature on one URL parameter;
one signature on one named cookie;
one signature in a content profile;
one signature on an allowed URL;
one signature across the security policy.

Choose the scope that matches the application.

For a false positive in comment on /api/tickets, define comment as a URL parameter and disable the signature for that parameter. The same signature continues to inspect other parameters and other URLs.

F5 also allows a signature override on an allowed cookie. Use that control when a named analytics or session-related cookie carries the legitimate value. Cookie names and values have their own configuration, so record which part produced the match.

A content-profile override applies wherever that JSON, XML or plain-text profile is associated. Check every URL and parameter using the profile before changing it. F5 documents signature overrides and associations for JSON profiles.

An allowed-URL override disables the selected signature for the whole URL. Every request field on that URL receives the exception. F5 describes URL-level signature overrides as a common operation and marks overridden signatures in the policy list. The allowed-URL and cookie procedures describe their attack-signature overrides.

Disabling a signature at policy level removes it from the whole application-security policy. Use that scope only when the signature is irrelevant to every request covered by the policy.

Record the signature ID, signature revision, URL, parameter or cookie, matched examples, application owner and protections that remain.

Apply, synchronise and test the policy

Saving an edit does not put it into the active policy. Select Apply Policy, wait for the operation to finish and confirm that the virtual server still has the intended application-security and logging profiles.

Synchronise the change to the peer device when the BIG-IP pair uses manual ConfigSync. F5 can display a sync reminder after policy changes in a high-availability configuration. The Advanced WAF preferences guide describes Apply Policy confirmation, change logging and the ConfigSync reminder.

Replay:

the original legitimate request;
the same value in another parameter;
the same value on another URL;
a safe signature test in the excluded field;
the safe test in a neighbouring field;
malformed and oversized versions of the request;
normal application traffic.

The legitimate request should complete without the false-positive event. The safe test in the excluded scope shows the inspection removed by the exception. Neighbouring fields and URLs should still produce the expected signature event.

Check the support ID, signature ID, staging state and application response after every replay.

Compare and export the policy

Use Security > Application Security > Security Policies > Policy Diff to compare the tuned policy with the earlier policy or a staging copy. F5 can compare active, inactive and exported policies.

Export the policy before a large tuning session, signature update or BIG-IP upgrade. A readable XML export supports review and version control; a binary policy archive preserves a restorable copy.

Compact XML omits attack-signature staging state and omits some settings that remain at their defaults. Use the full XML format when the review needs to show staging. Export user-defined attack signatures separately because a policy export contains their sets without the signatures themselves. F5 documents Policy Diff and the export-format limits.

Stage signature updates and application releases

F5 Live Update places newly added attack signatures in staging. Updated signatures follow the policy's Updated Signature Enforcement setting. Review that setting before installing an attack-signature update. F5 documents the post-update staging behaviour.

Keep signature staging enabled during the observation period. Review each high-volume match, then enforce the signatures that have clean traffic and tested application flows.

Run the same process after an application release that changes:

public URLs or methods;
parameter names or value types;
JSON, XML, GraphQL or multipart bodies;
cookies and headers;
uploads;
authentication and account flows.

Tell the application team which policy changes are waiting in staging. The application team knows whether a new field belongs in the release.

Keep rate limiting in the DoS profile

F5 application-security policies inspect individual requests. BIG-IP Layer 7 DoS protection measures transaction rates and server latency through a separate DoS profile attached to the virtual server.

Configure rate limiting under the DoS profile when repeated traffic is the problem. F5 can rate limit suspicious source addresses, countries, URLs or a site under attack. Transparent and Blocking modes for the DoS profile control whether those conditions are reported or mitigated. F5 documents TPS-based detection, stress-based detection and request rate limiting.

Track WAF signature blocks and DoS rate limits as separate outcomes. A false-positive signature needs a policy exception. The application owner must set an acceptable rate and response for excessive legitimate traffic.

Move the policy to Blocking

Switch the policy from Transparent to Blocking after:

normal and infrequent application flows have run;
every repeated legitimate match has been classified;
each exception has the smallest supported scope;
staged entities and signatures have been reviewed;
Learn, Alarm and Block settings match the intended response;
the replay tests pass;
the active and standby devices have the same applied policy.

Move a small application or virtual server first when the deployment supports it. Watch blocked requests, application errors and business transactions together.

The blocking response includes a support ID. Keep the event long enough for support staff to find the exact request without storing customer content in the exception record.

Review the policy after each application release and signature update. Remove an override when the field, parser or application behaviour that required it has gone.

Peakhour.IO - BIG-IP Advanced WAF