How To: Customize blocking response pages on BIG-IP Next Central Manager¶
When the enforcement mode of the security policy is blocking, and a request (or response) triggers a violation for which the block action is enabled, the system returns the response page to the client. If you configure login pages, you can create a custom response page for your organization’s application.
You perform the following actions for your policy response pages:
For a general overview of blocking response pages configured to your policy see Overview: Blocking response pages. For general policy response page settings, see Response Pages.
Types of blocking response pages¶
Option | Response to Blocked Request |
---|---|
Default Response | The response returns the system-supplied response page in HTML. |
Custom Response | The response returns a response page with HTML code that you define. |
Redirect URL | The response redirects the user to a specified web page. |
Prerequisites¶
A WAF policy is configured.
WAF policy enforcement mode is set to Blocking. Although this is not required, the responses will not be returned to a violation unless the setting is set to Blocking.
Configure custom responses to blocked requests¶
Configure the blocking web response that is sent to the user when the security policy blocks a client request.
Click the workspace icon next to the F5 icon, and click Security.
Select the name of the policy.
From the panel menu, click Response Pages.
By default, the panel displays the Blocking Page response message body.
For Response Type select Web Response.
Note: Web Response is the default option.
To create a custom response modify the default text:
For the Response Body type or paste the text you want to send to a client in response to an illegal blocked request. Use standard HTTP syntax.
Click Preview to the far right of the editor to view the user response.
Click Response Header to customize the default header.
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.
The updated web response is added to the policy’s blocking response page.
Add custom redirect URLs from blocked requests¶
Direct the user to a specified URL. The URL should be for a page that is not within the web application itself. In addition, it is recommended to add a URL with a support ID, to ensure that a valid, blocked user can request support.
Click the workspace icon next to the F5 icon, and click Security.
Select the name of the policy.
From the panel menu, click Response Pages.
By default, the panel displays the Blocking Page response message body.
For Response Type select Redirect URL.
In the Redirect URL field, type the URL to which the system redirects the user, for example,
http://www.myredirectpage.com
.To redirect the blocking page to a URL with a support ID in the query string, type the URL and the support ID in the following format:
http://www.myredirectpage.com/block_pg.php?support_id= <%TS.request.ID()%>
The WAF policy replaces<%TS.request.ID%>
with the relevant support ID so that the blocked request is redirected to the URL with the relevant support 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.
The updated web response is added to the policy’s blocking response page. Blocked users are redirected to the provided URL.
Restore default response pages¶
For the response web page, you can restore the default settings.
Click the workspace icon next to the F5 icon, and click Security.
Select the name of the policy.
From the panel menu, click Response Pages.
By default, the panel displays the Blocking Page response message body.
Select either the Blocking Page or AJAX Blocking Page tab.
If you selected the Blocking Page: From the top left of the editor, for either Response Body or Response Header, click Restore Default.
If you select AJAX Blocking Page: From the top left of the editor, for either Popup Message or Custom Response types, click Restore Default.
Confirm the restore settings.
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.
The response is restored to WAF policy default settings.
Configure AJAX blocking page¶
Normal policy blocking and login response behavior could interfere with applications that use AJAX. If you want to display a message or redirect traffic without interfering with the user experience while browsing to an AJAX-featured web application, you need to enable AJAX blocking behavior (JavaScript injection). You can implement blocking and login response behavior for applications that use AJAX with JSON or XML for data transfer.
When the enforcement mode of the security policy is set to blocking and a request triggers a violation (that is set to block), the system displays the AJAX blocking response according to the action set that you define. If a login violation occurs when requesting the login URL, the policy sends a login response page, or redirects the user.
Click the workspace icon next to the F5 icon, and click Security.
Select the name of the policy.
From the panel menu, click Response Pages.
By default, the panel displays the Blocking Page response message body.
Select the AJAX Blocking Page tab.
Note: By default the response type is disabled.
Ensure the Blocking Page is Enabled.
Select a Response Type:
Popup message displays text in a popup window (default text is included). Click Preview to view the response.
Custom Response lets you specify HTML text to use as a replacement for the frame or browser page that generated the AJAX request. Include the text, then click Preview to view the response.
Redirect URL redirects the user to the URL you specify.
Add the Redirect URL. You can also include the support ID. For example:
http://www.example.com/blocking_page.php?support_id=<%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.