How To: Manage and edit a WAF policy on BIG-IP Next Central Manager¶
The following describes how to modify your WAF policy on BIG-IP Next Central Manager using the UI.
Most of the WAF policy settings can be changed by modifying the JSON declaration in the UI editor or by using the BIG-IP Next Central Manager WAF OpenAPI
If you prefer to use the API, or would like to view use cases for the API endpoints, see API workflows and use cases.
The following procedure describe how to edit the WAF policy using the BIG-IP Next Central Manager UI:
L7 DoS protection See special instructions about policy best practices for creating L7 DoS protection for your applications.
Edit Policy JSON Declaration - Edit the JSON declaration directly
General settings¶
Customize your policy’s general settings. Once you create a new policy, you can edit all settings excluding the policy name and template.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens. Here you can edit most fields, excluding the Name, Template, and Application Language.
To view all available fields, toggle Advanced View button to the top right of the Basic Settings panel.
Add or remove Tags for policy sorting and filtering within BIG-IP Next Central Manager.
Enable or disable, Bot Defense, Threat Campaigns, or IP Intelligence by toggling the button.
Note: By default, all these protection settings are enabled.
Change the Enforcement Mode by selecting:
Transparent - Traffic is blocked if it causes a violation (configured for blocking).
Blocking - Traffic is not blocked even if a violation is triggered.
Modify default Allowed Response Codes to your applications by entering or deleting response codes the policy permits.
By default, the system accepts all response codes from 100 to 399 as valid responses. Response codes from 400 to 599 are considered invalid unless added to the Allowed Response Status Codes list. By default, 400, 401, 404, 407, 417, and 503 are on the list as allowed HTTP response status codes.
Modify the allowed and disallowed geolocations for the policy. By default, all countries are allowed. Traffic that originates from the countries assigned to the Disallowed Geolocations are restricted.
Select one or more countries from a list and use the arrow key to move the selection to the other list.
Select Select All and use the arrow key to move the entire country list from one status to another.
For Log Events select the following option for security policy event logging:
None - None of the events detected are logged.
Illegal - Only illegal events are added to the events log.
All - All events regardless of their outcome are added to the events log.
Note: For more information about web application and L7 DoS event logs, see How To: Create and Manage WAF Event Logs on BIG-IP Next Central Manager
For advanced settings you can provide general specifications for headers on incoming requests:
Maximum HTTP Header Length allows you to specify whether there is a limit to the allowed header Length (in Bytes) from a request. If you do not need a limit select Any to allow requests regardless of HTTP header length. The default setting is a maximum of 8192 Bytes.
If a length is specified, Maximum HTTP Header Length must be greater than 0 and less than 65536 bytes (64K).
Maximum Cookie Header Length allows you to specify whether there is a limit to the allowed header Length (in Bytes) from a request. If you do not need a limit select Any to allow requests regardless of cookie header length. The default setting is a maximum of 8192 Bytes.
If a length is specified, Maximum Cookie Header Length must be greater than 0 and less than 65536 bytes (64K).
Enable Trust XFF if you want the policy to trust the X-Forwarded-For header and use the IP address information in the HTTP header for the proxy server.
Leave this option disabled if you think the HTTP header may be spoofed or crafted by a malicious client. With this setting disabled, if the system is deployed behind an internal proxy, the system uses the internal proxy’s IP address instead of the client’s IP address.
Add Custom XFF Headers if you require the policy to trust a server further than one hop toward the client (the last proxy traversed). You can use this setting to define a specific header that is inserted closer to, or at the client. Additionally, if you require the policy to trust a proxy server that uses a different header name than the XFF header name, you can add the desired header name to the Custom XFF Headers setting. When adding a custom header, the XFF header is not trusted anymore.
Click Save to save your changes. If you would like to automatically deploy your changes to the BIG-IP Next instance, click Save & Deploy.
Manage Threat Campaigns¶
Threat Campaigns frequently update feeds containing contextual information about active attack campaigns currently being observed by F5 Threat Labs that WAF can provide protection against. You can enable or disable Threat Campaigns in the WAF policy using the BIG-IP Next Central Manager UI or send a PUT request with updated policy changes in the WAF OpenAPI.
Note: Threat Campaigns is enabled by default on all policy templates.
Use the following procedure to change the Threat Campaigns status in the BIG-IP Next Central Manager UI.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
Use the toggle to change the Threat Campaigns setting.
Click Save to save your changes. If you would like to automatically deploy your changes to the BIG-IP Next instance, click Save & Deploy.
Manage IP Intelligence¶
IP Intelligence incorporates external, intelligent services to enhance automated application delivery with better IP intelligence and stronger, context-based security. By identifying IP addresses and security categories associated with malicious activity, the IP Intelligence service can incorporate dynamic lists of threatening IP addresses into the BIG-IP Next, adding context to policy decisions. You can enable or disable IP Intelligence and categories in the WAF policy using the BIG-IP Next Central Manager UI or send a PUT request with updated policy changes in the WAF OpenAPI.
Note: IP Intelligence is enabled by default on all policy templates. To ensure IP Intelligence can regularly reach a third party vendor to identify IP addresses and security categories, you must ensure that your BIG-IP Next Central Manager or instances have Licensing activated. To activate your license, go to the Workspace icon > Instances > Select instance name > Licensing. For more information about this BIG-IP Next license, log in to https://account.f5.com/myf5 with your F5 customer credentials.
Use the following procedure to change the IP Intelligence status in the BIG-IP Next Central Manager UI.
Enable or disable IP Intelligence¶
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
Use the toggle to change the IP Intelligence setting.
Click Save to save your changes. If you would like to automatically deploy your changes to the BIG-IP Next instance, click Save & Deploy.
Manage IP Intelligence categories¶
The following describes how to manage IP Intelligence categories in the BIG-IP Next Central Manager UI. If you are using the API, ensure you edit the declaration using the requests provided in WAF OpenAPI.
For more information about IP Intelligence categories, see IP Intelligence categories.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu click {:} Policy Editor.
The panel displays an editor with the policy’s JSON declaration.
Click within the editor and type Ctrl+F. This displays the search bar at the top of the editor. Search
ip-intelligence.See the sample disabled
ip-intelligencedeclaration in the snippet below.Change the
alarmorblocksettings. By default, both aretrue. You can change tofalseif you do not want the policy to mitigate and/or log a category of IP address.Click Save to save your changes. If you would like to automatically deploy your changes to the BIG-IP Next instance, click Save & Deploy.
{
"ip-intelligence": {
"enabled": true,
"ipIntelligenceCategories": [
{
"alarm": true,
"block": true,
"category": "Spam Sources",
"description": "The Spam Sources category includes Tunneling Spam messages through proxy, anomalous SMTP activities, and Forum Spam activities."
},
{
"alarm": true,
"block": true,
"category": "Cloud-based Services",
"description": "The Cloud-based Services category includes IP addresses and networks that are used by cloud providers."
},
{
"alarm": true,
"block": true,
"category": "Mobile Threats",
"description": "The Mobile Threats category includes IP addresses of malicious and unwanted mobile applications."
},
{
"alarm": true,
"block": true,
"category": "Tor Proxies",
"description": "The Tor Proxies category includes IP addresses acting as exit nodes for the Tor Network. Exit nodes are the last point along the proxy chain and make a direct connection to the originatorâs intended destination."
},
{
"alarm": true,
"block": true,
"category": "Windows Exploits",
"description": "The Windows Exploits category includes active IP address offering or distributing malware, shell code, rootkits, worms, and viruses."
},
{
"alarm": true,
"block": true,
"category": "Web Attacks",
"description": "The Web Attacks category includes cross site scripting, iFrame injection, SQL injection, cross domain injection, and domain password brute force."
},
{
"alarm": true,
"block": true,
"category": "BotNets",
"description": "The Botnets category includes Botnet C&C channels and an infected zombie machine controlled by a Bot master."
},
{
"alarm": true,
"block": true,
"category": "Scanners",
"description": "The Scanners category includes all reconnaissance, such as probes, host scan, domain scan, and password brute force."
},
{
"alarm": true,
"block": true,
"category": "Denial of Service",
"description": "The Denial of Services category includes DOS, DDOS, anomalous syn flood, and anomalous traffic detection."
},
{
"alarm": true,
"block": true,
"category": "Infected Sources",
"description": "The Infected Sources category includes IP addresses currently known to be infected with malware, and IP addresses with an average low Reputation Index score. Enabling this category prevents access from sources identified to contact malware distribution points."
},
{
"alarm": true,
"block": true,
"category": "Phishing Proxies",
"description": "The Phishing Proxies category includes IP addresses hosting phishing sites, and other kind of fraud activities such as Ad Click Fraud and Gaming fraud."
},
{
"alarm": true,
"block": true,
"category": "Anonymous Proxy",
"description": "The Anonymous Proxy category includes IP addresses that provide proxy and anonymizing services."
}
]
}
}
Evasion technique violations¶
Evasion techniques refers to a technique that is typically used by hackers in an attempt to access resources or evade what would otherwise be identified as an attack. When this technique is detected, it triggers an evasion technique violation.
For a full list of violations and their protection status, see Reference: Violation Protection.
Manage evasion technique violations¶
Evasion technique violations are automatically enabled or disabled on a policy based on your selected template. You can use this process to manually enable or disable violations configured to your policy.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Evasion Techniques.
The panel displays evasion technique violations.
Click the radial button next to each violation to enable or disable policy enforcement.
Click Save.
If you have completed your changes to the policy, click Deploy to update associated BIG-IP Next instance(s).
To confirm the deployment, click Deploy.
HTTP Protocol Compliance violations¶
HTTP RFC non-compliance is one of the basic application security violations. It detects non-compliant violations and prevents the use of the HTTP protocol as an entry point to the application.
For a full list of violations and their protection status, see Reference: Violation Protection.
Manage HTTP RFC violations¶
HTTP protocol compliance violations are automatically enabled or disabled on a policy based on your selected template. You can use this process to manually enable or disable violations configured to your policy.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click HTTP Protocol Compliance.
The panel displays HTTP protocol compliance violations.
Click the radial button next to each violation to enable or disable policy enforcement.
Click Save.
If you have completed your changes to the policy, click Deploy to update associated BIG-IP Next instance(s).
To confirm the deployment, click Deploy.
Manage attack signatures¶
Attack signatures in a security policy are compared with requests or responses to identify classes of attacks, for example, SQL injection, command injection, cross-site scripting, and directory traversal. WAF receives a client request (or a server response), the system compares the request or response against the attack signatures associated with the security policy. If a matching pattern is detected, the policy triggers an attack violation, and either alarms or blocks the request, based on the enforcement mode of the security policy.
When tuning your policy, specific attack signatures may require customization according to known traffic patterns to your application. You can override a signature’s settings for a specific property (e.g. cookies or URLs). To override specific attack signatures see Override a specific attack signature
Note: F5 recommends using signature sets to manage your policy’s signatures. This will allow you to manage signatures based on a defined filter or attack-type, rather than each signature individually. See Manage attack signature sets for applying and managing signature sets.
Manage policy signature enforcement status¶
Define how the policy manages each attack signature when it is detected in application traffic.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Attack Signatures.
The panel displays a list of attack signatures defined in the policy. You can select the signature name to view general signature properties and additional information about the potential attack risk of the signature. See Reference: Attack Signatures.
Select the checkbox next to the signature(s) name(s). You can filter the signature list by key words.
Click one of the enforcement statuses at the top right of the panel:
Enforce - Traffic containing attack signatures is blocked and logged. Select one of the following:
Enforce Selected - Only signatures manually selected in the list are enforced.
Enforce all Staged Signatures - Enforce all signatures with a staging status.
Stage - Traffic containing the attack signatures is logged, but not blocked. This is the default enforcement status for most signatures.
Disable - Remove any logging or enforcement against the detected attack signatures.
Confirm the enforcement of the selected signatures. You can view your signature’s enforcement in the Status column.
If you have completed your changes to the policy, click Deploy to update associated BIG-IP Next instance(s).
To confirm the deployment, click Deploy.
Override a specific attack signature¶
You can enable or disable specific attack signatures in a security policy, one at a time for specific application elements: cookies and URLs. This allows you to create exceptions to attack signatures detected in allowed cookies and URLs. Creating a signature override reduces known false positives in valid traffic.
For more information about how to detect and override signatures for allowed application elements, see How To: Override an attack signature.
Manage attack signature sets¶
An attack signature set is a logical grouping of attack signatures based on defined filters, or type. See Reference: Attack Signature Sets for more information. F5 recommends using signature sets rather than applying individual attack signatures to a security policy. Each security policy has its own attack signature set assignments. By default, a generic signature set is assigned to new security policies. You can assign additional signature sets to the security policy.
F5 recommends using signature sets when adding or removing signatures.
Manage policy signature sets enforcement status¶
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Attack Signatures.
The panel displays a list of Signatures defined in the policy.
Select the Signature Sets tab.
Select the checkbox next to the signature set(s) name(s). You can filter the signature set list by key words.
Click one of the enforcement statuses at the top right of the panel:
Alarm - Traffic with an attack signature that belongs to the signature set triggers alarm.
Alarm & Block - Traffic with an attack signature that belongs to the signature set triggers alarm, and the traffic is blocked.
Disable - Remove any alarms or enforcement against the detected attack signatures from the signature set.
Confirm the enforcement of the selected signatures. The new status is listed in the Action column.
If you have completed your changes to the policy, click Deploy to update associated BIG-IP Next instance(s).
To confirm the deployment, click Deploy.
Manage filter-based signature sets¶
You can add or remove filter-based signature sets from a policy.
Filter-based signature sets are based solely on criteria defined in the signature filter provided by WAF. Rather than applying several individual attack signatures to a security policy, you can apply the most relevant attack signature sets for the systems running your applications. Each policy template includes signature sets by default. See Reference: Attack Signature Sets for more information about the system-provided sets.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Attack Signatures.
The panel displays a list of Signatures defined in the policy.
Select the Signature Sets tab.
Click Settings from the top right of the panel.
A panel provides a list of the policy’s associated signature sets.
Select the arrow to the right of the Associated Signature Sets.
Select (or de-select) the check box next to the signature set you would like to add to the policy. You can filter the list by key words in the Search bar.
Click Save.
If you have completed your changes to the policy, click Deploy to update associated BIG-IP Next instance(s).
To confirm the deployment, click Deploy.
IP address exceptions¶
Add IP addresses to the policy and specify whether they are always or never allowed to send requests to your protected applications.
Add, edit, or delete IP addresses exceptions that are specified within the policy.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click IP Address Exceptions.
The panel displays a list of IP addresses currently specified within the policy.
To create an IP address exception:
At the top of the panel, click Create.
Enter the IP Address. You can add a Netmask if it applies.
From Block Mode select how you want the policy to manage requests from the IP address:
Policy Default - Requests from this IP address are blocked according to policy rules.
Always Block - Requests from the IP address are always blocked.
Never Block - Requests from this IP address are always allowed and never blocked.
Enable additional IP address exceptions, according to your application security needs:
EXCLUDE IP ADDRESS FROM POLICY BUILDER TRAFFIC - Policy builder always trusts traffic from the IP address as safe. In addition, the IP address is added to the Trust IP Address list for Policy Learning.
EXCLUDE LOG TRAFFIC FROM IP ADDRESS - Requests and responses sent from the IP address are not logged, even if the request was illegal, and the security policy is configured to log all traffic.
EXCLUDE IP ADDRESS FROM LEARNING SUGGESTIONS - Requests from the IP address do not generate learning suggestions.
APPLY TO ADDITIONAL POLICIES - Enable this setting to apply the IP address exception rules to additional policies. Once you have enabled this setting you can select one or more policies.
Click Save. The IP address is added to the IP Address Exceptions list.
To edit an IP address exception:
From the IP Address Exception list, select the IP address.
Edit the Blocking Mode settings. For more information, see step 5 for more information.
Click Save to save your changes.
To remove an IP address from the exception list:
Select the check box next to the IP address.
At the top of the panel click Delete.
Policy Builder Settings¶
Policy Builder enables traffic learning to customize the WAF policy to your application protection requirements. You can enable or disable Policy Builder and its traffic learning settings.
Policy Builder is only available on the following WAF policy templates:
Rapid
Fundamental
Comprehensive
For information about Policy Builder see Overview: WAF Policy Builder.
Note: For adaptive WAF protection with less overhead than Policy Builder, see WAF rating-based protection
Manage Policy Builder settings¶
You can change the settings for Policy Builder for each WAF policy
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Policy Builder.
The panel displays Learning Suggestions.
Click Settings
For Learning Mode select one of the following:
The defaults for this setting vary depending on the WAF policy template.
Automatic - Accepts learning suggestions once they reach 100%, or when you manually accept the suggestion.
Manual - Requires that you manually accept any suggestion.
Disabled - Disables learning.
For Learning Speed select one of the following to customize the number of traffic samples for a suggestion:
Fast - Samples a low volume of traffic to generate a suggestion and reach a full learning score at a faster rate.
Medium - Samples a moderate volume of traffic to generate a suggestion. Recommended for most applications.
Slow - Samples a high volume of traffic to generate a suggestion to sample more traffic and reach higher suggestion accuracy.
For Readiness Period (Days) enter the number of days entities and attack signatures remain in staging before they can become enforced.
Click Save.
If you have completed your changes to the policy, click Deploy to update associated BIG-IP Next instance(s).
To confirm the deployment, click Deploy.
To manage Policy Builder learning suggestions and entity enforcement, see How To: Policy Builder learning suggestion and entity management.
Response Pages¶
You can configure the blocking response that the system sends to the user when the security policy blocks a client request. The following is a general overview of managing blocking response pages. You can create custom response pages and restore default pages for more information, see How To: Customize blocking response pages on BIG-IP Next Central Manager
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Response Pages.
The panel displays the Blocking Page response message body. If you have not yet changed the defaults, the blocking page is a Web Response type with the following body:
<html><head><title>Request Rejected</title></head><body> The requested URL was rejected. Please consult with your administrator. <br><br>Your support ID is: <%TS.request.ID()%><br><br> <a href='javascript:history.back();'>[Go Back]</a></body></html>
To change the blocking page to a set URL, from Response Type select Redirect URL.
Enter or paste the URL in Redirect URL.
To provide a response type for AJAX-based applications, click AJAX Blocking Page tab. For more information about customizing AJAX response pages see Configure AJAX blocking page.
The tab displays the default *Popup message response message body. The following is the default response body:
The requested URL was rejected. Please consult with your administrator. Your support ID is: <%TS.request.ID()%>Click Save.
If you have completed your changes to the policy, click Deploy to update associated BIG-IP Next instance(s).
To confirm the deployment, click Deploy.
Any changes to response pages are added once you deploy your changes to the BIG-IP Next instance. For more information about the types of response pages and how to customize the response, see How To: Customize blocking response pages on BIG-IP Next Central Manager.
Data Guard¶
In some web applications, a response may contain sensitive user information, such as credit card numbers or social security numbers (U.S. only). The Data Guard feature can prevent responses from exposing sensitive information by masking the data (this is also known as response scrubbing). Data Guard scans text in responses looking for the types of sensitive information that you specify.
For more information see Overview: Data Guard.
Note: If using an API, you can enable and modify Data Guard settings directly through the JSON declaration for the WAF policy. You can use either the JSON editor provided in the UI or push changes from an external editor. See Edit policy JSON declaration.
Data Guard procedures¶
Enable and manage Data Guard settings¶
Enable and manage which information requires data masking in your protected application’s response.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Data Guard.
By default, Data Guard is disabled.
To enable Data Guard, toggle the Enabled button.
The settings are displayed.
For Credit Card Numbers select Detect is you want to consider this information as sensitive data.
Enter the number of digits that will be exposed in the request in Expose last characters.
For U.S. Social Security Numbers select Detect is you want to consider this information as sensitive data.
Enter the number of digits that will be exposed in the request in Expose last characters.
To specify additional sensitive data patterns that occur in the application:
For Custom Patterns select Detect.
In the Custom Pattern Syntax field, type a PCRE regular expression to specify the sensitive data pattern.
For example: 999-[/d][/d]-[/d][/d][/d][/d].
Click + Add to add more custom patterns.
Click Save.
If you have completed your changes to the policy, click Save & Deploy to update associated BIG-IP Next instance(s).
To confirm the deployment, click Deploy.
Manage Data Guard violations¶
For details about default template settings for violations, see Data Guard violations
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Data Guard.
Click Violations.
The Data Guard Violations panel opens.
Select the policy action when the WAF policy detects information leakage included in the responses:
Select one of the following protection settings:
Alarm - Sends an alert to the event log that certain traffic is associated with data leakage.
Alarm & Block - Sends an alert to the event log and blocks traffic associated with data leakage.
Disabled - The policy does not detect or enforce information leakage.
Click Save.
The Data Guard’s detected information leakage protection is updated, but policy changes are not yet deployed. You can click Deploy to deploy changes to the BIG-IP Next instances.
CSRF protection¶
CSRF (Cross-site request forgery) is a security vulnerability found in web applications. An application vulnerable to CSRF allows an attacker to force a victim user to execute unwanted actions in a web application to which they are currently authenticated.
For more information about CSRF, see Overview: CSRF Protection Using Origin Validation.
CSRF Protection procedures¶
Add CSRF protection to URLs - Add URLs to the CSRF list.
Manage CSRF violations - Manage whether the system allows or enforces detected CSRF attacks.
Add CSRF protection to URLs¶
Add CSRF protection for specific URLs on applications, or exclude certain URLs from CSRF protection. Excluding CSRF protection may be required for applications with different request origins.
By default, CSRF is disabled. When it is enabled, the default wildcard (*) URL enable protection on all URLs. You can use this procedure to specify URLs to protect. In this case, you need to remove the wildcard URL (see Delete a URL). In addition, you can exclude URLs from CSRF protection based on the enforecment action.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the menu, select CSRF.
If CSRF is not yet enabled, toggle the Enable button.
A list of URLs with CSRF protection is displayed. By default, a wildcard (*) URL is added to protect against all URLs.
Click Add URL.
Add the URL to the CSRF list.
For Choose Method select the URL method.
For Enforcement Action select one an action you want to the policy to take. The policy goes through the list to find the first match for the method and URL combination. If a matching entry in the list is found, the configured action will be performed. Actions are:
None: The policy does not enforce the URL when a CSRF attack is detected. This option should be used to allow the URL.
Verify Origin: The policy verifies and detects a CSRF attack on applications.
Note: This enforcement action requires host names.
Click Add.
Click Add Host Names or Manage Host Names to add authorized host names to verify the origin of the URL.
In the Name field, type the host name that is used to access the application .
Select the following in the sub-domains field:
Select Include if you also want to use all sub-domains of the specified host name to access the application. The policy matches all FQDNs, and inserts WAF cookies into responses from the sub-domains of the host name.
Select Exclude if only the specified host name can access the application.
Click Save. The host name is added to the policy.
Click Save. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.
Click Deploy to deploy changes.
Manage CSRF violations¶
Manage how the policy handles detected CSRF attacks.
For details about default template settings for violations, see CSRF violations
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click CSRF.
Click Violations.
The CSRF Violations panel opens.
Select the policy action when the policy detects a CSRF attack:
Select one of the following protection settings:
Alarm - Sends an alert to the event log that an attack was detected.
Alarm & Block - Sends an alert to the event log and blocks traffic.
Disabled - The policy does not detect or enforce CSRF attacks.
Click Save.
The CSRF is updated, but policy changes are not yet deployed. You can click Deploy to deploy changes to the BIG-IP Next instances.
SSRF protection¶
Manages protection for an SSRF (Server-Side Request Forgery) attack. In an SSRF (Server-Side Request Forgery) attack, the attacker takes advantage of parameters that contain dynamic IP addresses or domain names which the server application invokes. Identify the parameters that are subject to SSRF attack and configure the IP address or domain name to deny, allow or resolve access from these parameters.
For more information about SSRF, see Overview: Server-Side Request Forgery (SSRF)
SSRF protection procedures¶
Manage SSRF protection¶
Add, delete or manage actions for SSRF hosts (domain names or IP addresses). SSRF host actions can either allow or deny specified hosts detected with the specified payload parameters. To enable the SSRF functionality, the parameter which carries the IP addresses or domain names must be configured as a parameter of data type Auto Detect.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the menu, select SSRF.
To add an SSRF host:
Click Add.
Under Host enter the domain name or IP address.
For Action select one of the following:
Deny - If the SSRF host is detected in the payload parameters, the request is always denied.
Allow - If the SSRF host is detected in the payload parameters the request is always allowed.
Resolve - This option is only relevant to domain names. When the host name is detected, the WAF policy will use the host name to look up IP address(es) using the configured DNS resolver. If one or more IP address corresponds with the domain name, they are looked up in the SSRF host list, if any IP addresses are set to Deny the configured mitigation action is taken. For the wildcard entry (*), the resolve action is interpreted as Allow for IP addresses.
Click Save. The SSRF host is added to the list.
Add a parameter. This is optional if you already have parameters configured with the value type of Auto Detect. SSRF protection will not be enabled until at least one parameter is configured:
Under the Parameters area, click Add Parameter. If parameters are already configured, click Manage Parameters and then Create.
Add a parameter Name
Select a Parameter Type:
Explicit - Specifies a unique parameter.
Wildcard - Specifies that the parameter is a wildcard expression. Any parameter that matches the wildcard expression is considered legal.
Note: See Wildcard syntax for more information.
Ensure the Value Type is Auto Detect.
Click Save.
Click Deploy to deploy changes.
Manage an SSRF violation¶
Manage how the WAF policy handles a request for server-side access to a disallowed host. This violation is an attempt to access a disallowed SSRF host from the server side by exploiting an address parameter.
For details about default template settings for violations, see SSRF violations
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click SSRF.
Click Violations.
The SSRF Violations panel opens.
Select the policy action when the policy detects a CSRF attack:
Select one of the following protection settings:
Alarm - Sends an alert to the event log when a request to SSRF host set to deny.
Alarm & Block - Sends an alert to the event log and blocks traffic when a request to SSRF host set to deny.
Disabled - The policy does not detect or enforce SSRF attacks.
Click Save.
The SSRF is updated, but policy changes are not yet deployed. You can click Deploy to deploy changes to the BIG-IP Next instances.
Brute force protection¶
You can configure WAF to protect against brute force attacks. The security policy detects brute force attacks based on failed login rates by suspected malicious users. Therefore, the security policy needs to have login pages for the web applications you want to protect.
For more information see Overview: Brute force protection.
Note: If using an API, you can enable and modify brute force settings directly through the JSON declaration for the WAF policy. You can use either the JSON editor provided in the UI or push changes from an external editor. See Edit policy JSON declaration.
Prerequisites¶
*It is recommended to add allowed URLs are added to your WAF policy, see Add allowed URLs.
Brute force protection procedures¶
Create brute force protection for login pages¶
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Brute Force Protection.
The login pages configured for brute force protection are listed.
Click Create.
Click Create under the Login Page field.
Click the dropdown for the Login URL field:
Select a URL from your WAF policy.
Note: The list provides URLs configured to the policy that do not have brute force protection.
Create a new allowed URL:
Click Create under the Login URL field to open a panel for Allowed URL Properties.
Add the allowed URL properties.
Click Save.
The URL is added to the allowed URLs in the policy and is added as the Login URL. You can now complete the Login Page Properties using the new URL.
From the Authentication Type list, select the method the web server uses to authenticate the login URL’s credentials with a web user.
Enter the expected login conditions for the URL
For Condition select a validation criteria for the login page response.
For Value define the criteria for the selected condition.
To add multiple login conditions, click + Add Condition.
Note: If you define more than one login condition, the response must meet all the criteria before the policy allows the user to access the application login URL.
Click Save.
Configure the source-based brute force protection for the login page:
For IP Address enable to set a threshold and action to take when the threshold is reached.
If disabled, the policy does not monitor IP addresses for brute force attacks.
Enter the Maximum Failed Login Attempts for a single IP address. The default is 20.
For Mitigation select one of the following protection settings:
Alarm - Sends an alert to the event log that a threshold was passed for an IP address.
Alarm & Block - Sends an alert to the event log and blocks traffic from an IP address that passed the threshold.
For Username enable to set a threshold and action to take when the threshold is reached.
If disabled, the policy does not monitor usernames for brute force attacks.
Enter the Maximum Failed Login Attempts for a single username. The default is 5.
For Mitigation, Alarm is enabled. This sends an alert to the event log that a threshold was passed for a username.
Configure the amount of time the policy mitigates brute force attacks to the login page:
For Detection Period enter period of time in minutes a policy tracks a potential brute force attack. The default is 60 minutes.
For Maximum Attack Prevention Time enter the period of time the policy enforced a detected brute force attack. The default is 60 minutes.
Click Save.
The login page is immediately added to brute force protection, but policy changes are not yet deployed. You can click Deploy to deploy changes to the BIG-IP Next instances.
Modify brute force protection for login pages¶
You can change the login page and brute force protection properties for a login page current protected from brute force attacks.
For more information about the login page settings and brute force protection properties, see Create brute force protection for login pages.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Brute Force Protection.
The login pages configured for brute force protection are listed.
Click the login page name.
The Brute Force Protection Properties panel opens.
To change the login page settings:
Click Edit.
The Login Page Properties panel opens.
Edit the Authentication Type and Login Conditions.
Click Save.
Edit the brute force protection properties for the login page.
CLick Save.
The login page brute force protection is updated, but policy changes are not yet deployed. You can click Deploy to deploy changes to the BIG-IP Next instances.
Manage brute force protection violations¶
If a brute force attack is detected due to maximum login attempts, you can manage how the WAF policy handles the violation. Brute force attacks indicate an attempt to access secure parts of the website by guessing usernames and passwords.
For details about default template settings for violations, see Brute force violations
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Brute Force Protection.
Click Violations.
The Brute Force Protection Violations panel opens.
Select the policy action when the number of times a user or IP address tried to log on to a URL is more than what is allowed by the security policy:
Select one of the following protection settings:
Alarm - Sends an alert to the event log that a threshold was passed for a login page.
Alarm & Block - Sends an alert to the event log and blocks traffic when a threshold was passed for a login page.
Disabled - The policy does not detect or enforce brute force attacks.
Click Save.
The brute force protection is updated, but policy changes are not yet deployed. You can click Deploy to deploy changes to the BIG-IP Next instances.
L7 DoS protection¶
Manage the L7 DoS protection settings that mitigate denial-of-service (DoS) attacks.
L7 DoS protection identifies DoS attack behavior in traffic by applying machine learning and data analysis of HTTP signatures, TLS fingerprinting, and bad actors (assessment of IP addresses by traffic behavior and anomaly detection).
You can enable, or disable the detection and mitigation techniques based on your application’s security requirements.
In addition, you can set the mitigation mode, which allows you to balance between the precise mitigation (conservative), service protection (standard) and monitoring only (none).
To review notifications of when an attack started, ended, or a bad actor was detected (if applicable to your settings), see Reference: L7 DoS Event Logs or go to: Security → Event Logs → L7 DoS.
Note: If using an API, you can modify the L7 DoS settings and settings directly through the JSON declaration for the WAF policy. You can use either the JSON editor provided in the UI or push changes from an external editor. See Edit policy JSON declaration.
Special instructions for L7 Dos Protection¶
F5 recommends a specific policy configuration and deployment procedure to ensure your L7 DoS protection has the best, and most accurate visibility in BIG-IP Next Central Manager’s L7 dashboard and event logs.
If you do not configure your L7 DoS protection according to recommended best practices, visibility of L7 DoS protection to your applications might be inaccurate.
When creating a L7 DoS protection apply the following:
Create a separate WAF policy for L7 DoS protection. Aside from General Settings and L7 DoS protection, do not add additional WAF services to this policy.
Create a dedicated L7 DoS application service with ONE virtual server.
Deploy the dedicated L7 DoS application service to ONE BIG-IP Next instance.
IMPORTANT¶
If you require L7 DoS protection on a pool member (endpoint) that is located on a different BIG-IP Next instance, you must create or clone a separate L7 DoS WAF policy and attach it to another dedicated application service that has only one virtual server (you can clone the existing L7 DoS application service but ensure it is attached to the correct policy.)
Manage L7 DoS settings¶
Before you begin: Read Special instructions for L7 Dos Protection.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click L7 DoS Protection.
The panel displays the policy’s settings.
If L7 DoS Protection is disabled, toggle the Enabled button. This will display the policy’s settings.
For Mitigation Mode select one of the following mitigation rates:
Standard (Default) - For Bad Actors, slows down requests from anomalous IP addresses based on its anomaly detection confidence and the server’s health. Rate limits requests from anomalous IP addresses and, if necessary, rate limits all requests based on the servers health. Limits the number of concurrent connections from anomalous IP addresses and, if necessary, limits the number of all concurrent connections based on the server’s health. If Signatures is enabled, this blocks requests that match attack signatures.
Conservative - For Bad Actors, rate slows down and rate limits requests from anomalous IP addresses based on its anomaly detection confidence and the server’s health. If Signatures is enabled, this blocks requests that match the attack signatures.
None - Learns and monitors traffic behavior, but no action is taken.
Enable or disable Signatures. When enabled, the policy examines requests and creates behavioral signatures that describe patterns found in attacks identified.
Enable or disable Bad Actors. When enabled, the policy identifies IP addresses of bad actors by examining traffic behavior and anomaly detection.
Enable or disable TLS fingerprint. When enabled, the policy uses TLS fingerprinting to distinguish between bad and good actors behind the same IP (NAT) and only blocks traffic from bad actors.
Click Save.
The L7 DoS protection settings are saved, but policy changes are not yet deployed. You can click Deploy to deploy changes to the BIG-IP Next instances.
Note: You can deploy L7 DoS protection on up to 70 applications for a single BIG-IP Next instance.
Bot protection¶
Bot protection helps identify and mitigate attacks before they cause damage to the site. Enable or disable Bot Protection in your WAF policy using the policy editor or send a PUT request with updated policy changes in the WAF OpenAPI.
Note: Bot Defense is enabled by default on all WAF policy templates.
Manage bot protection¶
Use the following procedure to change Bot Defense status in the BIG-IP Next Central Manager UI. When enabled, you can fine-tune the bot mitigation settings and exceptions.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Bot Protection.
To enable or disable Bot Protection, toggle the Enable button. When disabled, no further settings are displayed.
Manage bot mitigation settings:
See Overview: Bot Protection for mitigation setting details.
Ignore - All bot signatures and anomalies of this mitigation class are disabled and are not checked.
Detect- Bot detection is preformed and logged, but the request is not flagged with an alarm or blocked.
Alarm - Bot detection is performed, and flagged with an alert, but the request is not blocked.
Alarm & Block - Bot detection is performed, flagged with an alert, and the request is blocked.
To add an exception for a known bot signature:
Click Add Exception.
Select one or more bot signature names.
Select the action from the buttons on the top right of the list.
Confirm the action. The bot signature(s) is listed under the exceptions.
Click Save.
To save and immediately deploy changes, click Save & Deploy.
Manage file types¶
Manage which files types are always or never allowed access to your protected application.
You can use the OpenAPI to manage file types in your managed policies.
For more information about the file type violations, default allowed/disallowed file types, and wildcard syntax, see Reference: File Types.
Manage disallowed file types¶
Create, delete, or edit the policy’s management of disallowed file types.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click File Types.
The panel displays a list of disallowed file types defined in the policy.
To create a Disallowed File Type:
Click Create.
In the File Type (Explicit only) field, type the file type that the security policy does not allow (for example, jpg or exe).
Note: File types are case-sensitive unless you cleared Security Policy is case sensitive when you created the policy.
Click Save.
To edit the protection settings of all disallowed file types:
Click Settings.
Select one of the following protection settings:
Alarm - Sends an alert to the event log that the illegal file type was detected in traffic to protected applications.
Alarm & Block - Sends an alert to the event log and blocks traffic that includes the illegal file type.
Disabled - Traffic that includes the file type is not specified as illegal.
Click Deploy to deploy changes.
To remove a file type from the Disallowed File Types list:
Select the check box next to one or more file types.
Click Delete.
Click Delete to confirm.
Any changes to your policy are saved, but not yet deployed. Ensure you deploy your changes when you are done.
Manage allowed file types¶
Create, delete, or edit the policy’s management of allowed file types.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click File Types.
The panel displays a list of disallowed file types defined in the policy.
Select the Allowed File Types tab.
The panel displays a list of allowed file types defined in the policy. The pure wildcard (*) file type is added by default to all policies.
To create an Allowed File Type:
Click Create.
Enter a file type Name.
Select a Type:
Explicit - Specifies a unique file type, such as JPG or HTML.
Wildcard - Specifies that the file type is a wildcard expression. Any file type that matches the wildcard expression is considered legal. The pure wildcard (*) is automatically added to the security policy so you do not need to add it, but you can add other wildcards such as
htm*.Note: See Wildcard syntax for more information.
No Extension - Specifies that the web application has a URL with no file type. The system automatically assigns this file type the name
no_ext. The slash character (/) is an example of ano_extfile type.
Toggle the Staging to enable staging on the new file type.
For the length settings, you can select Length and adjust the values as needed:
The default setting is Any. Adding length settings is optional. To manage allowed file type length violations, see Manage file type length violations.
URL Length - The maximum acceptable length, in bytes, for a URL in the context of an HTTP request containing this file type. The default is 100 bytes.
Request Length - The maximum acceptable length, in bytes, for the whole HTTP request that applies to this file type. The default is 5000 bytes.
Query String Length - The maximum acceptable length, in bytes, for the query string portion of a URL that contains the file type. The default is 1000 bytes.
POST Data Length - The maximum acceptable length, in bytes, for the POST data of an HTTP request that contains the file type. The default is 1000 bytes.
If you want the system to validate responses for this file type, select Enforce. By default, this option is set to Ignore.
Note: Enforcing this option enables attack signatures (that are designed to inspect server responses) to filter responses.
Click Save.
To edit the settings on one or more allowed file types:
Select the file type name.
Change your file type settings and click Save.
To stage or enforce a file type from the Allowed File Types list:
Select the check box next to one or more file types. Check the Status column in the Allowed File Types list.
Click Stage or Enforce.
Confirm the selection. The status is immediately updated in the policy, but is not yet deployed.
To remove a file type from the Allowed File Types list:
Select the check box next to one or more file types.
Click Delete.
Click Delete to confirm.
Any changes to your policy are saved, but not yet deployed. Ensure you deploy your changes when you are done.
Manage file type length violations¶
Change the settings of file type length violations set in Manage allowed file types.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click File Types.
The panel displays a list of disallowed file types defined in the policy.
For general disallowed file type violations, click Violations.
Select a file type violation setting:
Check violation defaults per template.
Alarm - Sends an alert to the event log that the length violation was detected in traffic to protected applications.
Alarm & Block - Sends an alert to the event log and blocks traffic that includes the length violation.
Disabled - The policy does not enforce the file type restriction.
Select the Allowed File Types tab.
The panel displays a list of allowed file types defined in the policy. The pure wildcard (*) file type is added by default to all policies.
Click Violations to display the Allowed File Type Violations panel.
Select a file type violation setting:
Check violation defaults per template.
Alarm - Sends an alert to the event log that the length violation was detected in traffic to protected applications.
Alarm & Block - Sends an alert to the event log and blocks traffic that includes the length violation.
Disabled - The policy does not enforce the file type restriction.
CLick Save.
Manage URLS¶
Specify the HTTP URLs that are allowed in traffic to the protected web application. By default, wildcard URLs of * (representing all HTTP URLs) are added to the Allowed URLs list.
Manage your policy’s allowed URLs and URL violation settings:
Add allowed URLs - Add an allowed URL to your policy.
Modify allowed URLs - Change settings for an allowed URL.
Modify a URL enforcement status - Manually change the URL status to enforced or staging.
Delete a URL - Remove an allowed URL from the policy list.
Modify URL violation settings - Modify how your policy handles known URL violation.
Note: If using an API, you can modify the allowed URL list and settings directly through the JSON declaration for the WAF policy. You can use either the JSON editor provided in the UI or push changes from an external editor. See Edit policy JSON declaration.
Add allowed URLs¶
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click URLs.
The panel displays the policy’s allowed URLs.
Click Create.
The Allowed URL Properties panel opens.
If you would like the policy restrict allowed URLs with disallowing file upload and required message body enable Advanced View to the top right of the panel.
Enter a URL.
Select the URL Type:
Explicit (Default) - The policy identifies the URL by its specific name.
Wildcard - The policy identifies the URL by regular expression.
Note: The pure wildcard () is automatically added to the policy so you do not need to add it. You can add more specified wildcards such assite.com. See Wildcard syntax for more information.
Choose the URL’s HTTP request method from the Select Method list.
Add an optional Description to the URL.
Enable Staging if you want the security policy to evaluate traffic before allowing traffic.
(Advanced View enabled) Enable Disallow File Upload of Executables if you want the policy to disallow file upload of executable code from an allowed URL.
Because most web applications do not legitimately allow users to upload executable code, you can disallow a URL containing binary executable content.
(Advanced View enabled) Enable Body is Mandatory if you want the policy to allow the URL only if the request contains a body.
Click Save. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.
Click Deploy to deploy changes.
Modify allowed URLs¶
You can change the enforcement properties of an existing allowed URL. The URL name, type, and method cannot be modified.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click URLs.
The panel displays the policy’s allowed URLs.
Click the URL name.
The Allowed URL Properties panel opens.
Make the required changes to the URL properties. See steps in Add allowed URLs for more information about each property.
Click Save. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.
Click Deploy to deploy changes.
Modify a URL enforcement status¶
Manually change an allowed URL’s status to enforced or staging. A staging status can help the policy learn from traffic before allowing listed URLs. Once enforced, the policy will manage traffic with an allowed URL according to your policy’s settings.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click URLs.
The panel displays the policy’s allowed URLs.
Click the check box next to the URL row.
Click Stage to stage the allowed URL, and click Stage again to confirm the action.
Click Enforce to enforce the allowed URL, and click Enforce again to confirm the action.
The URL’s status is immediately updated, but policy changes are not yet deployed. You can click Deploy to deploy changes to the BIG-IP Next instances.
Delete a URL¶
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click URLs.
The panel displays the policy’s allowed URLs.
Click the check box next to the URL row.
Click Delete to remove allowed URL from the policy, and click Delete again to confirm the action.
The URL’s status is immediately updated, but policy changes are not yet deployed. You can click Deploy to deploy changes to the BIG-IP Next instances.
Modify URL violation settings¶
You can specify how the WAF policy handles traffic with known illegal URLs. For more information see Reference: URL Enforcement.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click URLs.
The panel displays the policy’s allowed URLs.
Click Violations.
The Allowed URLs Violations panel opens.
Modify the policy violation settings:
Check violation defaults per template.
Alarm - Sends an alert to the event log that the URL violation was detected in traffic to protected applications.
Alarm & Block - Sends an alert to the event log and blocks traffic that includes the URL violation.
Disabled - The policy does not enforce URL violations.
Click Save. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.
Click Deploy to deploy changes.
Manage Methods¶
All security policies accept standard HTTP methods by default. If your web application uses HTTP methods other than the default allowed methods, you can add them to the security policy. The system treats any incoming HTTP request that uses an HTTP method other than an allowed method as an invalid request. The system ignores, learns, logs, or blocks the request depending on the settings configured.
Default allowed methods vary according to your selected policy template.
Note: GET and POST are always allowed and cannot be removed.
Manage your policy’s allowed methods and violation settings using the UI:
Note: If using an API, you can modify the method list and method settings directly through the JSON declaration for the WAF policy. You can use either the JSON editor provided in the UI or push changes from an external editor. See Edit policy JSON declaration.
Manage allowed methods¶
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Headers.
The panel displays the Methods tab, which lists the policy’s allowed HTTP methods.
To add an allowed method:
Click Create.
For the Method Type, select the type of method to allow:
Predefined - Select an HTTP method from a list provided in the Choose Method list.
Custom - Enter the name of an HTTP method under Method Name.
Click Save. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.
To remove an allowed method:
Select the check box next to the method name.
Click Delete.
To confirm the action, click Delete. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.
Note: GET and POST are mandatory and cannot be removed.
Click Deploy to deploy changes.
Manage method violations¶
If a request includes an HTTP method that is not allowed by the policy, the request is illegal. You can manage how the WAF policy handles illegal methods when they are detected in traffic.
See Reference: Violation Protection for information about template default settings.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Headers.
The panel displays the Methods tab, which lists the policy’s allowed HTTP methods.
Click Violations.
Select one of the following violation settings:
Check violation defaults per template.
Alarm - Sends an alert to the event log that the illegal method was detected in traffic to protected applications.
Alarm & Block - Sends an alert to the event log and blocks traffic that includes the illegal method.
Disabled - The policy does not enforce illegal methods.
Click Save. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.
Click Deploy to deploy changes.
Manage Cookies¶
WAF allows you to add cookies with different characteristics to security policies. You can specify the cookies that you want to allow, and the ones you want to enforce in a security policy:
Allow - The security policy ignores certain known and recognized cookie headers that are included in HTTP requests and allows clients to change the cookies.
Enforce - The security policy prevents changes to specific cookies, such as session-related cookies that are set by the protected application. The cookie in the request must not be modified, or it generates the Modified Domain Cookie violation.
Both allowed and enforced cookies can be put in staging when they are created so that you can make sure that they do not cause false positives during the staging period.
If the cookies in the web application change, you can edit or delete the cookies.
Manage your policy’s allowed and illegal method settings using the UI:
Add policy cookies - Add a cookie to your policy.
Modify policy cookies - Change settings for a policy cookie.
Modify cookie enforcement status - Manually change cookie status to enforced or staging.
Delete a cookie - Remove a cookie from the policy list.
Modify cookie violations - Modify how your policy handles known cookie violations and/or cookie attributes detected in traffic. traffic.
Note: If using an API, you can modify cookies and their settings directly through the JSON declaration for the WAF policy. You can use either the JSON editor provided in the UI or push changes from an external editor. See Edit policy JSON declaration.
Add policy cookies¶
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Headers.
The panel displays the Methods tab.
Select the Cookies tab.
Click Create.
The Cookie Properties panel opens.
If you would like the policy to add attributes to the response header of the cookie domain, enable Advanced View to the top right of the panel.
Enter a Cookie Name. Type either the name of the cookie, or the pattern string for the wildcard to match cookie names.
Select the Cookie Type:
Explicit (Default) - The policy identifies the cookie by its specific name.
Wildcard - The policy identifies the cookie by regular expression.
Note: The pure wildcard () is automatically added to the policy so you do not need to add it. You can add more specified wildcards such assite.com. See Wildcard Syntax for more information.
Select the Enforcement Type:
Enforce - The policy prevents clients from modifying the cookie.
Allow (Default) - The policy allows the cookie. You may want to add allowed cookies for certain known and recognized cookie headers that are often included in HTTP requests.
Enable Staging if you want the security policy to evaluate traffic before allowing or enforcing the cookie.
Enable Mask Value in Logs if you want to treat the parameter you are creating as a sensitive parameter (data not visible in logs or the user interface).
Enable Check Attack Signatures and Threat Campaigns on this Cookie if you want the policy to check for attack signatures and threat campaigns on the cookie.
Note: This setting is only for allowed cookies, because enforced cookies are set by the server, and therefore, are considered to be secure.
(Advanced View enabled) Enable Insert HTTP Only Attribute if you want the policy to add the HttpOnly attribute to the response header of the domain cookie.
This attribute prevents the cookie from being modified or intercepted on the client side, by unwanted third parties that run scripts on the web page. The client’s browser allows only pure HTTP or HTTPS traffic to access the protected cookie.
(Advanced View enabled) Enable Insert Secure Attribute if you want the policy to add the SameSite attribute to the response header of the domain cookie.
This attribute allows servers to instruct the browser not to send cookies along with cross-site requests. This assertion allows mitigation of CSRF attacks.
Click Save. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.
Click Deploy to deploy changes.
The new cookie is now in the Cookies list. If you note a high number of block or alert events for allowed cookies, you may require a signature override. See Override an attack signature on BIG-IP Next Central Manager.
Modify policy cookies¶
You can change the enforcement properties of an existing cookie. The cookie name and type cannot be modified.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Headers.
The panel displays the Methods tab.
Select the Cookies tab.
Click the cookie name.
The Cookie Properties panel opens.
Make the required changes to the cookie properties. See steps 10-16 in Add policy cookies for more information about each property.
Click Save. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.
Click Deploy to deploy changes.
If you note a high number of block or alert events for allowed cookies, you may require a signature override. See Override an attack signature on BIG-IP Next Central Manager.
Modify cookie enforcement status¶
Manually change a cookie’s status to enforced or staging. A staging status can help reduce the occurrence of false positives. Once enforced, the policy will manage traffic with a detected cookie according to your cookie’s configured properties.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Headers.
The panel displays the Methods tab.
Select the Cookies tab.
The Status column lists the cookie’s current enforcement status.
Click the check box next to the cookie row.
Click Stage to stage the cookie, and click Stage again to confirm the action.
Click Enforce to enforce the cookie, and click Enforce again to confirm the action.
The cookie’s status is immediately updated, but policy changes are not yet deployed. You can click Deploy to deploy changes to the BIG-IP Next instances.
Delete a cookie¶
You can delete cookies that are no longer needed in your security policy. If a cookie changes in your application, you may want to delete the old cookie and add a new cookie.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Headers.
The panel displays the Methods tab.
Select the Cookies tab.
The Status column lists the cookie’s current enforcement status.
Click the check box next to the cookie row.
Click Delete, and click Delete again to confirm the action.
The cookie is immediately removed from the list, but policy changes are not yet deployed. You can click Deploy to deploy changes to the BIG-IP Next instances.
Modify cookie violations¶
You can specify globally how WAF policies handle traffic with known cookie violations and/or specific cookie parameters. For more information about cookie violations, cookie properties, see Reference: Cookie Enforcement.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Headers.
The panel displays the Methods tab.
Select the Cookies tab.
Click Violations.
The Cookie Violations panel opens.
Modify the policy violations settings:
Check violation defaults per template.
Alarm - Sends an alert to the event log that the cookie violation/property was detected in traffic to protected applications.
Alarm & Block - Sends an alert to the event log and blocks traffic that includes the cookie violation/property.
Disabled - The policy does not enforce cookie violation.
Click Save. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.
Click Deploy to deploy changes.
Manage host names¶
You can manually add legitimate host names to a security policy, for example, if users can access the application from multiple host names.
Manage your policy’s legitimate host names and host name violations using the UI:
Add allowed host names¶
Add host names that can legitimately access the policy-protected web application.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Headers.
The panel displays the Methods tab, which lists the policy’s allowed HTTP methods.
Select the Host Names tab.
Click Create.
The Host Name Properties panel opens.
In the Name field, type the host name that is used to access the application .
Select the following in the sub-domains field:
Select Include if you also want to use all sub-domains of the specified host name to access the application. The policy matches all FQDNs, and inserts WAF cookies into responses from the sub-domains of the host name.
Select Exclude if only the specified host name can access the application.
Click Save. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.
Click Deploy to deploy changes.
The new host name is now in the Host Names list.
Modify sub-domain settings¶
Change the sub-domain access settings for an existing host name.
When sub-domains are included The policy matches all FQDNs, and inserts WAF cookies into responses from the sub-domains of the host name.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Headers.
The panel displays the Methods tab.
Select the Host Names tab.
Click the host name.
The Host Name Properties panel opens.
From the sub-domains field:
Select Include if you also want to use all sub-domains of the specified host name to access the application. The policy matches all FQDNs, and inserts WAF cookies into responses from the sub-domains of the host name.
Select Exclude if only the specified host name can access the application.
Click Save. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.
Click Deploy to deploy changes.
The sub-domain settings are updated for the host name. You can see the update in the Sub-Domains column of the policy’s Host Names list.
Manage host name violations¶
You can specify globally how WAF policies handle traffic with known host name violations. For more information about these violations, see Reference: Host name enforcement.
See Reference: Violation Protection for information about template default settings.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Headers.
The panel displays the Methods tab.
Select the Host Names tab.
Click Violations.
The Host Name Violations panel opens.
Modify the policy settings:
Alarm - Sends an alert to the event log that the host name violation was detected in traffic to protected applications.
Alarm & Block - Sends an alert to the event log and blocks traffic that includes the host name violation/p.
Disabled - The policy does not enforce host name violations.
Click Save. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.
Click Deploy to deploy changes.
Manage parameters¶
Configure sensitive parameters to protect applications against client/server-side tampering attacks, malicious file uploads, or SSRF attacks.
By default, a wildcard parameter with a user input value type and alpha-numeric data type is added to the list. This means that any alpha-numeric values (e.g. comments, names, or phone numbers) added by the user in a request is permitted by the WAF policy, unless another user input parameter is specified.
Note: If using an API, you can modify parameters directly through the JSON declaration for the WAF policy. You can use either the JSON editor provided in the UI or push changes from an external editor. See Edit policy JSON declaration.
Manage your policy’s parameters and parameter violations using the UI:
Add new parameters¶
Define new parameters that protects against attacks to your applications by doing following steps:
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Parameters.
Click + Create.
Enter a parameter Name.
Select a Parameter Type:
Explicit - The policy identifies the parameter by its specific name.
Wildcard - The policy identifies the parameter by regular expression. Any parameter name that matches the wildcard expression is permitted by the security policy.
Note: The pure wildcard () is automatically added to the policy so you do not need to add it. You can add more specified wildcards such assite.com. See Wildcard syntax for more information.
Select a Location where the parameter is found in the request:
Query String - Parameter is found as a query string in the request.
Form Data - Parameter is found in the form data of the request.
Select a parameter Value Type:
Auto Detect - The policy automatically detects the parameter within the request. This value type is useful in reducing false positives for detecting violations in XML or JSON parameter values in a request.
User Input - The parameter data is provided by user-added input. Once you select user input, select a Data Type.
Alpha-Numeric - Parameter data can be any text consisting of letters, digits and the underscore character. Once you select this value, you can specify whether this data type has minimum and maximum limits:
Minimum Length - To enforce limits on the minimum size parameter, select Value and enter the minimum alpha-numeric character limit.
Note: The default value is 0.
Maximum Length - To enforce limits on the maximum size parameter, select Value and enter the maximum alpha-numeric character limit.
Note: The default value is 10.
File Upload - Prevent uploading of executable files. Once you select this value, you can configure the policy to block file uploads that contain binary executable content by enabling Disallow File Upload of Executables.
Dynamic content value - Enforce parameters where the application sets the value on the server side to extract dynamic parameters from responses to requests from allowed URLs.
Note: You must add allowed URLs to configure dynamic parameters. See Add allowed URLs.
Select an allowed URL from Extract from Allowed URLs.
To log, but allow, requests even with the detected parameter, enable Staging. If you would like to enforce the parameter, do not enable this option.
Note: You can later change the enforcement status in the parameters list.
Enable Mask Value in Logs if the parameter detects sensitive information. By enabling this option request information is not visible in logs or user interface.
To enable additional parameter values, enable Advanced View to the top right of the panel:
Enable Allow Empty Value if the parameter is acceptable without a value. By default, this setting is disabled, and requires the parameter to always include a value.
Enable Allow Repeated Occurrences to allow users to send a request that contains multiple parameters with the same name.
Click Save. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.
Click Deploy to deploy changes.
The new parameter is now in the Parameters list. If you note a high number of block or alert events for allowed parameters, you may require a signature override. See Override an attack signature on BIG-IP Next Central Manager.
Modify parameters¶
Manage parameter violations¶
You can specify how WAF policies handle traffic with detected parameter violations. For more information about these violations, see Reference: parameters.
See Reference: Violation Protection for information about template default settings.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Select the name of the policy.
A panel for the General Settings opens.
From the panel menu, click Parameters.
Click Violations.
The Parameter Violations panel opens.
Modify the policy settings:
Alarm - Sends an alert to the event log that the parameter violation was detected in traffic to protected applications.
Alarm & Block - Sends an alert to the event log and blocks traffic that includes the parameter violation/s.
Disabled - The policy does not enforce parameter violations.
Click Save. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.
Click Deploy to deploy changes.
Edit policy JSON declaration¶
It is possible to edit your policy by modifying your JSON declaration using the UI or API (see BIG-IP Next Central Manager WAF OpenAPI ).
Use BIG-IP Next Central Manager’s UI to make changes directly to a JSON declaration. The editor provides the following editing tools to ensure deployment of your declaration without errors:
Find and Replace - Use CRTL+F to enable the search feature in the JSON editor. You can use the toolbar to find and replace objects (such as one or more instances) or properties inside the JSON.
Schema Validation - The editor provides schema-based validation by underlining and providing suggestions for schema errors.
Syntax Validation - The editor highlights and underlines syntax errors in the JSON structure.
Auto Complete - Use CTRL+SPACE to view suggestions you can use auto complete during your edits. This can be applied to correcting errors, or adding schema properties.
Editor Options and Shortcuts - Use F1 to view a list of additional options and shortcuts in the JSON editor.
Image of JSON editor with F1 selected:
For more information about the WAF declarative policy, see Declarative WAF Policy Schema.
Click the workspace icon next to the F5 icon, and click Security.
From the left menu click Policies under WAF.
Click the Policy Name you would like to edit.
From the policy panel’s menu, click {:} Policy Editor. The panel displays a JSON editor that allows you to make changes directly to the declaration.
To save and immediately deploy changes, click Save & Deploy.
To save changes on BIG-IP Next Central Manager without deploying, click Save.