3.6. Creating an F5 Secure Web Gateway Service¶
3.6.1. What it is¶
SWG is a full-featured secure web gateway solution for blocking unwanted or malicious user-initiated web traffic and enforcing corporate and regulatory policies. Rich integration with both BIG-IP Access Policy Manager (APM) and BIG-IP iRules provides near limitless web policy enforcement flexibility. SWG as an inline security service is available as a security device option in the security service catalog and allows you to define an SWG per-request policy that runs inside the decrypted service chain.
SWG must be licensed and provisioned to use this feature. The Secure Web Gateway subscription includes:
A URL database with millions of URLs and hundreds of URL categories, that regularly updates as new threats are identified
Identification and blocking of malicious traffic
Web application controls
Safe search enforcement
3.6.2. How to build it¶
Either from a topology workflow or directly under the Services tab in the SSL Orchestrator user interface, click the Add button to create a new F5 Secure Web Gateway service.
SWG Service |
User Input |
|---|---|
Name |
Provide a name for this service. |
Description |
Optionally enter a description here. |
Access Profile |
Select an existing SWG Access profile, or Create New to create a new Access Profile object. Make sure to select SWG-Transparent from the Profile Type field list in the BIG-IP system. Once you select Finished, refresh the Access Profile field in SSL Orchestrator Guided Configuration. The newly created access profile will be available to select from the field list. |
Access Profile Scope |
This setting prevents a malicious user from establishing a session using one virtual server, and then using that same session to access, potentially without further authentication, another virtual server and the resources behind it. This setting is specifically used when authentication is applied at the topology, and allows the authenticated user information to be made available to the SWG per-request policy. In this case, you will use the Named profile scope and set the authentication and SWG policies to the same named scope value. However other settings are available: Profile: Gives a user access only to resources that are behind the same access profile Virtual Server: Gives a user access only to resources that are behind the same virtual server Global: Gives a user access to resources behind any access profile that has global scope Named: Gives an SSLO user access only to resources that are behind any virtual server with access profile using the same named-scope value |
Named Scope |
When Access Profile Scope is set to Named, enter a string value here. If used with a front end authentication profile, ensure both policies use the same named scope value. |
Per-Request Policy |
Displays a list of per-request policies for use with SSL Orchestrator. A per-request policy runs each time the client initiates a transaction. A per-request policy provides the logic for determining how to process URL requests. Depending on the actions you include in the per-request policy, it can control whether or not to bypass SSL traffic and determine whether to allow or reject a URL request. Select Create New to create a new Per-Request Policy object. Note: Make sure to select All from the Policy Type field list in the BIG-IP system. Once you select Finished, refresh the Per-Request Policy field in SSL Orchestrator Guided Configuration. The newly created access profile will be available to select from the field list. |
Service Down Action |
Specify how you want the system to handle service failure. Ignore: Specifies that the traffic to the service is ignored and is sent to the next in chain Drop: Specifies that the system initiates a close on the client connection Reset: Specifies that the system immediately sends a RST on the client connection for TCP traffic. For UDP traffic, this action is the same |
Log Setting |
Lists the log settings with which this access profile is associated. Select an Available log setting and move it to the list of Selected log settings. |
Click Save & Next to proceed.
The workflow will proceed to the Service Chains page to allow adding of this new service to a service chain. Once complete here, if in a topology workflow click Save & Next to continue. If adding the service directly, click the Deploy button.
3.6.3. How it works¶
SSL Orchestrator uses the following configuration information to correctly address a Secure Web Gateway service.
Access Profile - Select an existing SWG Access profile, or Select Create New to create a new Access Profile object. Note: Make sure to select SWG-Transparent from the Profile Type field list in the BIG-IP system. Once you select Finished, refresh the Access Profile field in SSL Orchestrator Guided Configuration. The newly created access profile will be available to select from the field list.
Access Profile Scope - This setting is specifically used when authentication is applied at the topology, and allows the authenticated user information to be made available to the SWG per-request policy. In this case, you will use the Named profile scope and set the authentication and SWG policies to the same named scope value.
Named Scope - When Access Profile Scope is set to Named, enter a string value here. If used with a front end authentication profile, ensure both policies use the same named scope value.
Per-Request Policy - Displays a list of per-request policies for use with SSL Orchestrator. A per-request policy runs each time the client initiates a transaction. A per-request policy provides the logic for determining how to process URL requests. Depending on the actions you include in the per-request policy, it can control whether or not to bypass SSL traffic and determine whether to allow or reject a URL request. Select Create New to create a new Per-Request Policy object. Note: Make sure to select All from the Policy Type field list in the BIG-IP system. Once you select Finished, refresh the Per-Request Policy field in SSL Orchestrator Guided Configuration. The newly created access profile will be available to select from the field list.
Log Setting - Lists the log settings with which this access profile is associated. Select an Available log setting and move it to the list of Selected log settings.
For additional information on configuring the F5 Secure Web Gateway as an SSL Orchestrator security service, please see the following:
https://community.f5.com/t5/technical-articles/ssl-orchestrator-use-case-swgaas/ta-p/285469
3.6.4. Implementing a Secure Web Gateway Service¶
While the possibilities are nearly endless, the F5 Secure Web Gateway can minimally perform the following functions:
URL Filtering - This is a typical F5 SWG Service use-case. Malicious categories are typically blocked by all organizations. However, there may be special categories which an organization chooses to present a confirmation page prior to allowing access to a site.
URL Branching - A URL branching action is useful to perform different actions depending upon the URL. For example, if a URL contains the word “secret”, then authentication can be applied. Otherwise, the request will be passed through without authentication.
Discrete Categorization - The F5 SWG Service supports custom categories. Users can create custom categories based on an exact URL or with wildcard/regex type matching. Custom categories are configured under Access :: Secure Web Gateway :: URL Categories.
Indentity-based Access - Most organizations will use various authentication techniques to identify users and enforce an appropriate policy. Membership in different user groups like “IT”, “HR” and “Sales” are often used to determine which policies are enforced. As an example, members of the HR group may have very little restrictions for Internet access when compared to Customer Service or Technical Support. Ultimately, it is up to the organization to decide who is allowed to access various categories. The F5 SWG Service gives them the flexibility to create the policy that is desired.
Conditional Access - Combined with identity from an APM authentication policy, SWG can use conditional access to specify a multitude of parameters before a request is ultimately allowed or denied. For example,
User A is authenticated
User A is a member of the Sales group
User A is in North America
It is between the hours of 3:00 PM and 4:00 PM
User A is accessing a specific resource (site, category, content, etc.)
These and any combination of additional request parameters can be defined to create robust conditional access policies.
Access Confirmation - It depends on the organization, but Sports, Shopping and Gambling might be categories that are gated with a confirmation page. A confirmation page may say something like the following:
“This category is outside of the organizations typical allowed categories. Please be cautious and aware that all activity is being logged and monitored.”
In order to proceed to the website the user must click a Confirmation button.
3.6.5. Creating an SWG per-request policy¶
SWG as an inline security service is intended to perform typical transactional web gateway functions. While it is possible to create SSL intercept/bypass and traffic flow actions in an SWG policy, these are not appropriate inside the SSL Orchestrator service chain. In the BIG-IP UI, under Access -> Profiles / Policies -> Per Request Policies, click the Create button.
SWG Per-Request Policy |
User Input |
|---|---|
Name |
Enter a unique name |
Policy Type |
Select All |
Incomplete Action |
Select Allow |
Customization Type |
Either type will work here |
Languages |
Select the appropriate language(s) |
Once complete, edit the new SWG per-request policy VPE. You can begin adding functionality directly, or you can start with one of the pre-built macro templates. Click the Add New Macro button and select from one of the three templates and click Save. Now add that macro to the primary policy flow to enable it. Make any additional modifications as required.
Figure 35: SWG Per-Request Policy¶
For detailed instructions on creating SWG policies, please see the following resources:
As stated previously, while most options are possible, some of these are not appropriate for an inline SWG service. The below is a list of SWG agents that are inappropriate for use in an SWG per-request policy inside the SSL Orchestrator service chain:
- Assignment (functions that control traffic flow)
Pool Assignment
- General Purpose (functions that read or control TLS-level attributes)
IP Based SSL Bypass Set
Server Cert Response Control
Server Cert Status
SSL Check
SSL Intercept Set
SSL Configuration Select
- Traffic Management (functions that control traffic flow)
Proxy Select
Service Connect
Session Check