F5 Secure Web Gateway Recommended Practicesstatic.newsletter.veracomp.pl/files/dcdd50c93adf5913f...A...

F5 Secure Web Gateway

Recommended Practices

F5 Networks, Inc.

2Copyright F5 Networks Inc.

F5 Simplified Application Acceleration Recommended Practices

Contents

Concept 4

SWG Reference Architecture 5

2.1 Web Security for Corporate Enterprise Users 8

2.2 Guest Network Access Deployment Scenario 9

2.2.1 Defer Liability with a Captive Portal 10

2.3 The PCI CDE DMZ 11

2.4 Microsoft Threat Management Gateway Replacement Deployment Scenario 12

Getting Started with SWG 13

3.1 Base Configuration Requirements 13

3.1.1 Network Time Protocol (NTP) 14

3.1.2 DNS 14

3.1.3 Routing and Outbound Security 15

3.1.4 Verify Connectivity and Initial Database Download 15

3.2 Authentication, Accounting, and Authorization 17

3.2.1 Use Corporate Directories to Identify User Traffic 18

3.3 Create an SWG Filtering Policy and Scheme 19

3.3.1 Malware Scanning and the Security Category 20

3.4 Create an Access Profile and Policy 20

3.5 Create a Per-Request Access Policy (Version 11.6) 22

3.6 Plan for SSL Intercept 23

3.6.1 Inspecting Encrypted Traffic 24

3.6.2 Per-Request Policy SSL Bypass and Intercept (Version 11.6) 25

3.7 Plan for Captive Portal 26

3.8 Provisioning for Stand-alone vs. Consolidated Security 26

3.9 Use the SWG iApp 27

3.9.1 Configuring the iApp for Explicit Proxy 28

3.9.2 Configuring the iApp for Transparent Proxy with Captive Portal 33

More SWG Recommended Practices 40

4.1 Validation 40

4.1.1 Filtering Validation 40

4.1.2 SSL Bypass 42

4.1.3 Malware Validation 42

4.2 Getting the Most from Reporting 43



4.3 Manage Video Streaming with Schedules 44

4.3.1 Scheduling in SWG Version 11.6 45

4.4 Deleting Single User Sessions 45

4.5 Customize Error Messages in the Proxy Auto-configuration (PAC) File 46

4.6 Ensure Safe Searches as Enterprise Policy 47

4.6.1 Enforce Safe Searches as Enterprise Policy (Version 11.6) 48

4.7 Limit Viral Videos Without Denying All Multimedia Websites 48

4.8 Protecting DNS Services 49

Conclusion 51



ConceptThe F5 Secure Web Gateway (SWG) solution provides complete control of outbound Internet traffic.

SWG leverages F5’s partner Websense’s technology and research to offer a broad spectrum of traffic

classification categories for monitoring and mitigation purposes, allowing easy enforcement of human

resources or security policies. The rich and flexible capability SWG provides allows for many different

deployment scenarios and controls.

This guide highlights some of the most common SWG customer scenarios. It discusses the pros and

cons of different deployments and elucidates the nuances of control and visibility of Internet usage.

SWG intercepts outbound HTTP or HTTPS traffic through a couple of possible scenarios. It can be

deployed transparently in the outbound path to the Internet. Outbound web traffic can be redirected

by a device such as a router or another BIG-IP to the SWG. Alternatively, clients can be explicitly

configured to direct their outbound web requests to the SWG.

Once the traffic is intercepted, Access Policy Manager is used to authenticate the user and create a

session ID. If authentication fails, the request is denied. If authentication succeeds, the request is

passed to the access policy for evaluation and enforcement. If the request is accepted, it is then

passed on to the website.

SWG leverages the categorization database from F5 partner Websense to offer support for multiple

policies and apply enforcement to groups of users based on authorization parameters such as group

memberships within a corporate directory. SWG is a key component in the technical controls and

visibility into the performance of an organization’s Internet Acceptable Use Policy.

Recommended Practice: Before starting down the road of building out an SWG deployment, you

should work with your security officers, and human resources and legal departments to develop an

acceptable-use policy. This policy will help you determine your filtering requirements in advance of

deployment. Appendix A provides a link to a sample Internet Acceptable Use Policy, which can be

customized to fit your organization’s requirements.

A sample Prohibited Usage section could include the following:

4.4 Prohibited UsageAcquisition, storage, and dissemination of data that is illegal, pornographic, or thatnegatively depicts race, sex, or creed is specifically prohibited.

In the above policy example, technical controls implemented on SWG would align with configuring the

URL filter to block access to a minimum category list of Adult Material, Illegal or Questionable,

Intolerance, and Religion.

Construct an Internet Acceptable Use Policy and have it approved by senior management prior to

specifying filters. This will ensure that the user community understands that the filtering implemented

is only a representation of the organization’s policy.



Recommended Practice: The Acceptable Use Policy should specify whether or not the organization

wants to authenticate and track based on client name activity for both approved and/or denied

requests and what the retention period on that information should be. Some organizations may be

legally bound to retain this information, while others may not want to retain the information beyond that

needed for troubleshooting.

SWG Reference Architecture

Figure 1. The F5 SWG Reference Architecture

The Secure Web Gateway architecture acts as an inspection filter and strategic point of control for

outbound web traffic. There are four primary deployment scenarios for the SWG:

• Corporate. The corporate deployment was validated for both Explicit and Transparent Proxy

deployments in an active/standby, high-availability, clustered scenario. The explicit and

transparent proxy configurations validated in the corporate deployment scenario can be

leveraged in the remaining three deployment scenarios with minimal modification identified in

their respective sections.

• Guest Network Access. Organizations often have visiting contractors or outside visitors who

need access to the Internet temporarily to access resources. Guest networks can be

configured to securely permit Internet access while restricting bandwidth-consuming sites.

• PCI CDE. Section 1.3.7 of the PCI DSS standard requires that if any servers in the CDE make

connections to the Internet, there must be a controlling forward proxy protecting those servers.

• Microsoft Threat Management Gateway. SWG is a great alternative to gateway security

devices like TMG. The solution combines granular access control, robust compliance reporting,



Recommended Practice: Explicit proxy deployed in a one-armed implementation is the most

common deployment scenario. It is useful when other critical outbound Internet services that

are not http/https-based rely on traditional or Next-Generation Firewalls to manage the security

policy for these protocols.

• Inline implementation is used where the SWG cluster is the default gateway for the network. All

outbound traffic will flow through the SWG, and http(s) traffic will be inspected according to the

URL filtering policy. This leverages the Transparent Proxy deployment topology. Internet

resources are only accessed via the SWG as the network default gateway. This architecture

was used to validate the Transparent Proxy deployment for corporate, guest network, PCI, and

TMG scenarios.

When SWG is implemented inline, the administrator must be aware that users and applications

are typically unaware of the proxy. Some applications and websites are not compatible with a

proxy deployment and managing their bypassing of the SWG will be part of the ongoing system

operations.

Figure 3. Transparent Proxy Validation Architecture Deployed Inline

Deploy inline when you are leveraging the BIG-IP for other features such as Datacenter Firewall

(AFM+ASM+LTM), Remote Access, and SSO (APM), and your outbound Internet service requirements

are limited or you want to restrict them such as in a PCI environment. Inline may also be useful in

environments where tools to manage the configuration and updating of clients aren’t readily available.

There will be an increased administrative workload in identifying websites that are incompatible with

proxies or other protocols that require modification of the SWG to ensure a positive user experience.

Recommended Practice: To ensure proper operation, SNAT should be implemented in both

Transparent and Explicit modes to ensure application response traffic is returned to the SWG device.



Common Deployment ScenariosTo achieve the goals of the customer scenarios, the actual deployment of Secure Web Gateway

services will typically fall into three distinct models: corporate, guest access, and PCI CDE DMZ. An

ancillary deployment scenario is provided to demonstrate a suitable replacement for the Microsoft

Threat Management Gateway. The multiple customer scenarios are supported within these four

deployment scenarios depending on the features implemented. Regardless of the deployment

scenario, the solution provides for URL categorization and filtering, malware content scanning, and

detailed reporting.

2.1 Web Security for Corporate Enterprise Users

Figure 4. Corporate Network Deployment Scenario

A corporate deployment of SWG has many possible configuration profiles to fit the different network

and security requirements for the organization. While no two organizations are the same, for most,

Secure Web Gateway secures outbound web traffic generated by the organization’s employees by

categorizing and filtering URLs, scanning for embedded malware, and optionally curbing unproductive

web-browsing behavior.



In general, a typical corporate architecture will include a common set of SWG features protections—as

in the following table—in order to implement the customer scenarios:

Corporate SWG Deployment Details

1 Explicit- or Transparent-Mode Proxy

2 URL Filtering for security

3 URL Filtering for productivity

4 Malware Protection

5 Identification Mapping with Active Directory

6 Transparent SSL Interception

Implementation of these feature sets will accomplish the goal of the customer scenarios with context-

aware security, bandwidth control, and Acceptable Use Policy presentation through a configuration of

an appropriate SWG filtering scheme and schedule. Context-aware filtering can be enforced only by

allowing http and https traffic destined for the Internet to be sourced from the SWG. By building a

filtering scheme and schedule that limits access to bandwidth-consuming sites during business hours,

enterprises can limit productivity losses. What traffic is filtered and what is allowed are representations

of the enterprise Acceptable Use Policy.

2.2 Guest Network Access Deployment Scenario

Figure 5. Guest Network Deployment Scenario



2.3 The PCI CDE DMZ

Figure 6. PCI Deployment Scenario

This deployment scenario complies with the Payment Card Industry (PCI) security guidelines. For

example, the SWG is commonly used to create a PCI DSS–compliant Cardholder Data Environment

(CDE). Section 1.3.7 of the PCI DSS standard requires that if any servers in the CDE make

connections to the Internet, there must be a controlling forward proxy protecting those servers.

Deploying the SWG around a CDE provides this compliance while securing the outbound connections

and the communications.

In these cases, the goal of the security administrator should be to proxy as much as possible, thereby

reducing threat surface. If the server inside the environment is eventually compromised, a malware-

aware proxy can make it harder for the attacker to load attack tools onto that server.

Recommended Practice: For protected DMZ use cases, create whitelists of sites by setting up a

custom category while denying all other requests. Only allow requests to the sites in the whitelist. This

practice will provide maximum security and control for the DMZ environment.

A typical guest-access SWG deployment will have a common number of features enabled, such as:

PCI DMZ SWG Features

1 Explicit or Transparent Mode Proxy

2 Full Reporting





Implementation of these feature sets will accomplish the goal of the customer scenario requiring

forward proxies for compliance. PCI DSS Section 1.3.7 requires any servers in the cardholder data

environment (CDE) accessing the Internet to make those connections via a controlling forward proxy.

The configuration guidelines outlined here provide recommendations to help secure the CDE and help

an organization in its compliance efforts.

2.4 Microsoft Threat Management Gateway Replacement Deployment Scenario

Figure 7. TMG Replacement Scenario

Microsoft Threat Management Gateway (TMG) in the past has been used by organizations as method

of providing the enterprise deployment scenario. As Microsoft has discontinued the product offering

enterprises are moving to SWG to replace the functionality TMG provided as an enterprise outbound

proxy.

The Microsoft TMG Replacement Deployment scenario is another variation of the Enterprise

Deployment scenario. Implementation of these feature sets will accomplish the goal of the customer

scenarios with context-aware security, bandwidth control, and acceptable-use policy presentation

through a configuration of an appropriate SWG filtering scheme and schedule. Context-aware filtering

can be enforced only by allowing http and https traffic destined for the Internet to be sourced from the

SWG. By building a filtering scheme and schedule that limit access to bandwidth-consuming sites

during business hours, enterprises can limit productivity losses. What traffic is filtered and what is

allowed are representations of the enterprise Acceptable Use Policy.

Moving beyond TMG, how will the enterprise provide its users with secure and controlled access to

the Internet? Failure in outbound security—whether it’s a direct financial impact from data loss or the

liability or loss of employee productivity due to inappropriate use of the Internet—can be very costly to

the enterprise.



In addition to using traditional and next-generation firewalls, many organizations have identified a need

to use a web proxy, such as TMG. Moving forward, those organizations will leverage SWG to deliver

user access to Internet resources while protecting corporate assets. Figure 7 shows an example of

this type of architecture. The features required to replace TMG are as follows:

TMG Deployment Details

1 Explicit or Transparent Mode Proxy


3 URL Filtering for productivity


5 Identification Mapping with Active Directory

6 Transparent SSL Interception

Getting Started with SWGThe deployment of SWG can be a straightforward process once a handful of decisions have been

made. This section provides a quick guide to those prerequisites. For the complete implementation

guide for SWG, follow the link below:

https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-secure-web-gateway-

implementations-11-5-0/1.html

3.1 Base Configuration RequirementsThere are a number of essential BIG-IP system configuration items that must be completed prior to the

SWG deployment scenario implementation to avoid any unnecessary issues that may require

troubleshooting. These configuration items establish base functionality for SWG system regardless of

the user or deployment scenario chosen.

https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-secure-web-gateway-implementations-11-5-0/1.html

https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-secure-web-gateway-implementations-11-5-0/1.html



3.1.1 Network Time Protocol (NTP)

Network Time Protocol is critical in trust relationships. SSL Certificates are no exception, and BIG-IP

devices need NTP to trust each other. And your SWG clients need synchronized time to trust the SWG.

Ideally, all SWG clients are using the same time sources as the SWG servers. Make sure you configure

NTP to point to multiple reliable sources.

Figure 8. NTP Configuration

3.1.2 DNS

The base system configuration setting for DNS is required so the BIG-IP can resolve the hostnames of

your AAA servers and the site http://download.websense.com. This is required to ensure that the

filtering database is updated regularly. Configure two sources for high availability, as shown in Figure 9.

Figure 9. DNS Configuration

http://download.websense.com



3.1.3 Routing and Outbound Security

Secure Web Gateway uses the production Self IP interfaces to download updates from http://

download.websense.com. The management interfaces are not used to retrieve database updates.

Recommended Practice: All configuration for connectivity from the Self IP to download.websense.

com should be completed and verified prior to attempting to download the initial update.

The external firewall policy must allow http traffic requests outbound. Additionally, the screened user

traffic is sourced from a Secure NAT (SNAT) IP address, which must be allowed out to the Internet.

Configure the default route to point to the next-hop gateway facing the Internet. In one-armed mode

this will likely be a router, and in routed mode this would likely be your next-generation firewall (NGFW).

A sample routing configuration with a standard default route is show below:

Figure 10. Routing Configuration

Recommended Practice: To enforce your security policy, configure the outbound firewall policy to

only allow traffic originating from the Self IP of each secure web gateway and any SNAT addresses.

3.1.4 Verify Connectivity and Initial Database Download

To verify base configuration and connectivity for SWG to regularly get updates from Websense,

manually update the database. Navigate to Access Policy >> Secure Web Gateway: Database

Download and select “Download Now.”

Figure 11. Updating Database





3.1.4.1 Verify Progress and Success

There are a couple ways to verify that the database is being downloaded and that progress is being

made. Error and success messages can be found in /var/log/apm. Both are noted in the following

example:

tail -f /var/log/apm

May 12 16:41:42 swg notice urldbmgrd[23601]: 01770004:5: 00000000: Downloading latest database...May 12 16:41:42 swg err urldbmgrd[23601]: 01770072:3: 00000000: Download failed with return code 4May 12 16:41:42 swg err urldbmgrd[23601]: 01770026:3: 00000000: Master db download failed with return code 4May 12 16:41:42 swg err urldbmgrd[23601]: 01770002:3: 00000000: Download of Master DB failed, will retry.

May 12 16:42:02 swg notice urldbmgrd[23601]: 01770004:5: 00000000: Downloading latest database...May 12 16:42:03 swg notice urldbmgrd[23601]: 01770004:5: 00000000: Database download completed.May 12 16:42:03 swg debug urldbmgrd[23601]: 01770034:7: 00000000: Transfer Status: 247May 12 16:42:03 swg debug urldbmgrd[23601]: 01770035:7: 00000000: Expiration Date: 1601535600May 12 16:42:03 swg debug urldbmgrd[23601]: 01770037:7: 00000000: DB Type: 3May 12 16:42:03 swg notice urldbmgrd[23601]: 01770038:5: 00000000: DBVersion: 0May 12 16:42:03 swg debug urldbmgrd[23601]: 01770039:7: 00000000: Users: 100May 12 16:42:03 swg debug urldbmgrd[23601]: 01770040:7: 00000000: Server Status: 0

Figure 12. Database Download Log Entries

tcpdump can be used to ensure that the database is continuing to download. Replacing SWG_

Production in the following example with the VLAN name for the production interface that has the

default route to the Internet produced the results in Figure 13.

tcpdump -i SWG_Production | grep download.websense

tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on SWG _ Production, link-type EN10MB (Ethernet), capture size 96 bytes17:06:30.636927 IP kl.download.websense.com.http > 172.31.120.118.31843: . 2607499653:2607501021(1368) ack 3403672784 win 54 <nop,nop,timestamp 3657338353 1249055995>17:06:30.637077 IP 172.31.120.118.31843 > kl.download.websense.com.http: . ack 1368 win 501 <nop,nop,timestamp 1249056070 3657338353>17:06:30.638195 IP kl.download.websense.com.http > 172.31.120.118.31843: . 1368:2736(1368) ack 1 win 54 <nop,nop,timestamp 3657338353 1249055995>17:06:30.638374 IP 172.31.120.118.31843 > kl.download.websense.com.http: . ack 2736 win 501 <nop,nop,timestamp 1249056072 3657338353>

Figure 13. tcpdump



Once the download is complete, you should see the database indexing notification similar to the one

below:

Figure 14. DB Indexing

After the process is complete, the additional ACE entry and the Master and RTU should all be green

as shown in the following example:

Figure 15. Download Results

3.2 Authentication, Accounting, and AuthorizationDetermine your authentication, accounting, and authorization (AAA) source for identifying which users

should have access to which filtering policies. Access Policy Manager (APM ) has the capability to

leverage many different authentication sources. By authenticating users, SWG can enforce the usage

policy based on group memberships to a very granular level. For example, the HR department may

have a usage policy that allows members to browse Facebook for research on prospective employees,

while a call center is restricted due to productivity concerns.

Identifying users can also be of use even though filtering is not implemented. SWG Administrators

have the ability to record a person’s history to determine

Consult the BIG-IP Access Policy Manager: Authentication and Single Sign-On guide for a full

list of methods, their requirements, and configurations.

http://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-authentication-single-

sign-on-11-5-0.html

http://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-authentication-single-sign-on-11-5-0.html

http://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-authentication-single-sign-on-11-5-0.html

http://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-secure-web-gateway-implementations-11-5-0/3.html

http://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-secure-web-gateway-implementations-11-5-0/3.html



If a mapping cannot be determined (perhaps because of a rogue device on the network), the SWG

offers three possible approaches for the unauthenticated connection:

• The connection can be denied (maximum security)

• The connection can be attached to a much more strict security policy.

• The connection can be forwarded to a captive portal, where the user will be required to

authenticate (thereby allowing the SWG to track the user associated with that device).

Recommended Practice: Using the above considerations, define the security policy for

unauthenticated requests and configure the Transparent Identity Import fallback path to provide a

secondary means of authenticating users.

3.3 Create an SWG Filtering Policy and SchemeSecure Web Gateway allows you to customize which categories should be filtered to match your

Acceptable Use Policy. Categories have drill-downs to allow for very granular control.

Figure 17. SWG Filtering Policy



3.3.1 Malware Scanning and the Security Category

The security category is where you enable features such as the malware content scanning.

Recommended Practice: If you have a very liberal policy for filtering, but you want SWG to perform

malware content scanning, enable the functions in the Security Category.

Figure 18. Security Filtering Policy

3.4 Create an Access Profile and Policy

The Secure Web Gateway access profile supports both transparent and explicit forward proxy modes. The access policy includes support for using a captive portal to collect credentials for transparent forward proxy mode and HTTP 407–based credential capture for explicit forward proxy mode. In addition to user identification by credentials, SWG provides the option to identify users transparently, providing access based on best-effort identification.

Figure 19. Access Policy Creation



The access policy determines how those outbound user connections will be authenticated and

authorized. The F5 Access Policy Manager (APM) module and its associated visual policy editor (VPE)

are used to create the Access Policy.

To edit the Access Policy follow the link from the Main Page to Access Policy and select the access

policy you wish to edit, or create a new Access Policy:

Figure 20. Access Policy Edit Navigation

At a minimum, the policy must include the method of identifying users (transparently or otherwise) and

an SWG “Scheme.” The VPE allows an administrator to create very sophisticated access policies, but

if need be, one can be as simple as this explicit proxy policy:

Figure 21. VPE Explicit Proxy Example



Or a slightly more detailed access policy can be created for transparent proxy with logon page and

decision box for displaying and prompting for acceptance of an Acceptable Use Policy:

Figure 22. VPE Transparent Proxy Example

A policy can be created for transparently importing user identities based on their Active Directory

credentials and applying a filtering scheme accordingly:

Figure 23. SWG Policy with Transparent Identity Import via IFMAP

3.5 Create a Per-Request Access Policy (Version 11.6)In SWG version 11.6, F5 introduced Per-Request Policies to allow greater flexibility in policy creation

and enforcement. This new type of policy is where the functionality for protocol mapping, SSL

Intercept, and Bypass actions are determined; Date and Time actions are configured; and the filtering

policy is applied. In version 11.5, the iApp is required to match a URL to a bypass list. This list applied

to all clients of SWG. In 11.6, the Per-Request framework can be used to provide granular policies to

different groups.

Figure 24 Per-Request Policy Creation



Recommended Practice: To avoid errors or problems in logic processing, a Per-Request Access

Policy should follow the following logical flow:

Protocol Lookup

Determines the HTTP request type

Category Lookup

Results are used for URL Filter Assign and Response Analytics

Response Analytics

Looks for malicious content and used for URL Filter Assign

URL Filter Assign

Allow or Deny HTTP Response

A simple Per-Request Policy can be created that matches the protocol to HTTP; completes a

Category Lookup to classify the website and then determines if the response contains malicious files;

and applies the URL Filtering Policy.

Figure 25 Simple Per-Request Policy Example

Per-Request Policies have a behavioral advantage: a change to the active policy takes effect

immediately after the change is made on the next request. As an administrator, you can make

changes to the URL Filters or modify the SSL Bypass configuration within your policy without a

technical impact to the SWG clients.

3.6 Plan for SSL InterceptOne of the decisions that should be made up front is how SSL interception will be handled. Because

more and more outbound is encrypted, F5 recommends that SWG be allowed to intercept and inspect

that outbound SSL traffic to provide complete coverage moving forward.

Each explicit proxy should have an associated SSL certificate that is signed by a certificate authority

trusted by the internal user browsers. This is because some browsers (such as Google Chrome) will

use SSL when connecting to the explicit proxy itself.

Recommended Practice: The common name for the certificate should be the IP address or

hostname of the explicit proxy virtual server itself. The tmsh command can be used to create a

certificate request to be submitted to a certificate authority.

% tmsh create sys crypto key swg_prime gen-csr common-name “swg.example.net”

The deployment of a transparent SSL proxy will require a special certificate (and associated key) that

can sign other certificates. This is known as a CA certificate. Typically these cannot be created on the

BIG-IP but are available via the organization’s security or certificate team.



3.6.1 Inspecting Encrypted Traffic

The increasing use of HTTPS as the default transport protocol means that administrators must be able

to inspect SSL-encrypted traffic to provide security and policy enforcement.

The SSL Intercept feature works by generating certificates on demand that appear to the internal user

as the certificate for the target website. The browser, which is configured to trust the SWG CA

certificate, appears to be communicating directly with the target website.

While SSL Intercept is a powerful feature of SWG, there are times when an administrator will not want

to intercept the connection due to privacy or compliance concerns.

Recommended Practice: F5 recommends that the following categories be considered against your

security policy goals for SSL bypass:

• Websites that provide online banking. Typically an administrator will not want to intercept the

user data for financial institutions.

• Websites that require client-certificate authentication. Due to the way that the SSL protocol is

structured, SWG cannot intercept sites that require client-certificate authentication.

• Websites that fingerprint the server certificate. Sometimes automated update servers will have

the target certificate embedded in their client software, and they will throw an error if SSL

Intercept is used.

• High-trust SaaS sites. Many administrators have a high-trust relationship with their most

frequently used SaaS platforms. They may choose, in the interests of performance, to avoid

intercepting and inspecting each user connection to those services.

Note that client-certificate authentication is not compatible with transparent SSL proxies. The same is

true for certificate pinning services or any services that validate the fingerprint of the server certificate

(such as Windows Update).

Recommended Practice: For sites that require client-certificate authentication or other features that

are not compatible with transparent SSL proxies, create a custom category of whitelisted sites for

which you can bypass the inspection.

Ultimately, the choice of which websites should be bypassed for SSL Intercept is a policy decision to

be made and managed by the administrator, but it should include those where sensitive data is best

not transmitted in the clear.

In SWG 11.5 the iApp can be used to manage the categories of sites that should be bypassed. Error!

Reference source not found. Figure 24 shows a recommended list and hints at a custom category

(in this case, named ssl bypass).



Figure 26. Use the SWG iApp to Manage the SSL-Bypass Categories

When managing the list-bypass category, for diagnostic purposes or otherwise, it may be necessary

to clear the SSL-intercept cache certificates. The command to do this is:

% tmsh delete ltm clientssl-proxy cached-certs clientssl-profile <the name of clientssl profile>

virtual <name of the associated virtual server tunnel>

3.6.2 Per-Request Policy SSL Bypass and Intercept (Version 11.6)

In Version 11.6, SSL Intercept configuration Bypass Default Action is configured in the client SSL

profile. The default action for the iApp is to Intercept SSL traffic.

Therefore when you specify categories to be bypassed in the Category Lookup, you must change the

default action within the Per-Request Policy to override the default. In the example below, the Per-

Request Access Policy does a category lookup for SSL-based traffic and Banking Health–related

traffic follows the Financial and Health branch where the overriding action of SSL_Bypass_Set allows

the traffic to continue without being intercepted by SWG.

Figure 27. Per-Request Policy with SSL Bypass Configured



3.7 Plan for Captive PortalLike a transparent proxy, the captive portal will also require a certificate. A captive portal is necessary

for providing guest access to visitors (and requiring them to accept a usage policy). A captive portal

can also be used to provide a “daily landing page” to provide internal users with Single Sign On ability.

3.8 Provisioning for Stand-alone vs. Consolidated SecurityThe target system must also have these two modules provisioned regardless of whether preparing for

a stand-alone or multi-module system:

• Access Policy (APM)

• Secure Web Gateway

The size of the URL categorization and filtering databases requires that the underlying platform system

have a minimum of 8GB of memory installed.

Recommended Practice: If the system has only 8GB, deploy it as a stand-alone forward proxy.

Provision SWG without additional services (even LTM must be disabled). Figure 28. shows what the

provisioning screen must look like when the system has only 8GB of memory.

If the target system is to be a multi-module security device hosting SWG and say, ASM for inbound

traffic, then it must have 16GB or more RAM.

Figure 28. SWG Resource Provisioning



3.9 Use the SWG iAppA successful setup of the SWG will ultimately yield many related configuration objects. Creating,

associating, and adjusting this many objects by hand would be a challenging task. The F5 SWG iApp

simplifies the process to a mere handful of questions.

Use the SWG iApp to create SWG configurations. You can download the iApp from the F5 DevCentral

website: https://devcentral.f5.com/wiki/iApp.F5-Secure-Web-Gateway.ashx

Once you have downloaded the iApp file, install it by clicking the Import button on the iApps

Templates screen. After the template has been installed, press the create (+) button next to the

Application Services menu and select “f5.secure_web_gateway” as the template as shown in Figure

29.

Figure 29. Create iApp

The iApp will then provide information about what prerequisites will be required before the

configuration can be complete. A typical set of prerequisites is shown below. The Getting Started

section (3) can help guide an administrator to take care of these prior to the use of the iApp.

Please make sure you have the following items completed before beginning your configuration:

• A CA certificate and key have been imported for use with the SSL Intercept feature.

• If you intend to use the captive-portal feature (Transparent) or SSL-wrapped proxy feature

(Explicit), a certificate and key with the proper common name have been imported for use.

• An access profile of the appropriate type (SWG-Explicit for Explicit Proxy mode and SWG-

Transparent for Transparent Proxy mode) has been created with the authentication, SWG

scheme, and access policy of your choice.

• All routing and reachability to download the Websense updates have been tested and verified.

https://devcentral.f5.com/wiki/iApp.F5-Secure-Web-Gateway.ashx



3.9.1 Configuring the iApp for Explicit Proxy

Name your new Application Service and select the f5.secure_web_gateway iApp template.

Figure 30. Deploying the SWG iApp

3.9.1.1 Template Options

The additional features enabled in advanced options allows VLAN configuration on which SWG should

listen.

Recommended Practice: In a standard explicit SWG deployment, select “No, do not enable

advanced options” unless you have other functions being performed by the BIG-IP device that may

require you to specify which VLAN the SWG component should listen on.

Figure 31. Inline Help and Advanced Options

3.9.1.2 Configuration Type

Select “Explicit Proxy.”

Figure 32. Explicit Proxy



3.9.1.3 Explicit Proxy Configuration

In the Explicit Proxy Configuration section provide the IP address and port on which the SWG will

listen for requests. If it’s been decided to support SSL intercept as described in Section 3.4, select

“Yes, support SSL interception.”

The standard ports for HTTP and HTTPS should be populated. If applications are leveraging

nonstandard ports for either HTTP or HTTPS they should be added under the appropriate section.

Finally, the SWG Access Policy created in Section 3.4 should be selected.

Figure 33. Explicit Proxy Configuration

3.9.1.4 Per-Request Access Policy Selection (Version 11.6)

SWG Version 11.6 and Version 1.1 of the SWG iApp require the additional selection field for a Per-

Access Request Policy as discussed in Section 3.5.

Figure 34. Per-Request Policy Selection Field



3.9.1.5 DNS Name Resolution

To reduce network traffic and to provide for consistency, configure the DNS Name Resolution to point

to the same group of DNS caching servers as used by the internal clients.

Figure 35. DNS Name Resolution

3.9.1.6 Proxy Autoconfiguration Support

Many enterprises have the ability to push configuration changes and settings to workstations. If your

enterprise doesn’t have this ability, support for autoconfiguration is available.

Allowing plain names to bypass the proxy will allow clients to go directly to internal hosts by their

internal short name, e.g., http://hr_dept_application. For many internal HR or Financial applications,

this is likely desired behavior. It also reduces the resource consumption on the SWG devices, freeing

them to focus on inspecting Internet-bound traffic.

Additionally, you can preclude IP address ranges from going through the proxy. This is useful where

you may need to access management GUIs of some devices that don’t have fully qualified domain

names (FQDN) to reference.

Recommended Practice: The URL scheme matches for proxy bypass to allow the clients to go

directly to internal hosts and not through the SWG. This most likely is a desired behavior for internal

applications and networks. This also allows your firewall security policies and application logs to act

on the internal native client IP addresses.

Figure 36. PAC File Creation Options

http://hr_dept_application



3.9.1.7 SSL Intercept Configuration

When SSL Intercept configuration is desired, the following options are available. The trusted

subordinate certificate authority’s (CA) certificate and key should be installed. Many organizations may

have their own internal trusted CA already installed on their servers and workstations.

Figure 37. SSL Intercept Configuration

The configuration sections under SSL Intercept Configuration, specifically “What action should be

taken for an expired certificate” and “What action should be taken for an untrusted certificate,” should

be noted. If the option is chosen to “ignore” in either case, the client will be presented with either an

invalid or expired certificate signed by the trusted CA. This can cause confusion for some users if they

examine the certificate. Others may just accept the certificate and continue on to the requested site.

If “drop” is selected for either case, the client browser will be presented with the connection-reset

message similar to the example below:



Figure 38. SSL Intercept Invalid Certificate Behavior “Block”



3.9.2 Configuring the iApp for Transparent Proxy with Captive Portal

The SWG can be installed transparently within the network path to manage all traffic following the

default gateway for the enterprise network. This allows for SWG to be deployed without explicit

configuration of browsers on the network. This also guarantees that all outbound traffic destined for

the Internet is inspected by the Secure Web Gateway.

As with the explicit proxy, name your new Application Service and select the f5.secure_web_gateway

iApp template.

Figure 40. iApp Template Selection

3.9.2.1 Template Options

In this case it is recommended to select “Yes, enable advanced configuration options” to enable the

Secure Web Gateway to be configured to only act on outbound Internet traffic.

Figure 41. Template Options

3.9.2.2 Configuration Type

Select “Transparent Proxy.”

Figure 42. Transparent Proxy



3.9.2.3 Transparent Proxy Configuration

Modify any ports that might be additionally used for HTTP or HTTPS traffic that you want to be

recognized, e.g., 8443, 8080, etc.

If the policy dictates that outbound SSL encrypted traffic should be inspected select “Yes, support

SSL interception.”

The transparent proxy can be configured to listen only on trusted VLANs. In the common deployment

scenario there is a trusted (inside) and untrusted (outside) VLAN, and only the inside trusted network

should be configured to listen for http(s) traffic.

Select the access policy you created in Section 3.3.

Depending on the placement in the network and additional security requirements, the Secure Web

Gateway can be configured to translate client traffic (SNAT) out to the Internet behind either a single IP

address or a pool of IP addresses. SNAT configuration should be selected if you do not want to worry

about the granular filtering of the native client IP address on the external firewall. The SWG will record

the username and IP address whether or not you use “auto-map” or specify a pool of IP addresses to

be leveraged. A pool of SNAT IP addresses will allow your SWG deployment to support significantly

more users than a single IP address will.



Figure 43. Transparent Proxy Configuration

3.9.2.4 Per-Request Access Policy Selection (Version 11.6)

SWG Version 11.6 and Version 1.1 of the SWG iApp require the additional selection field for a Per-

Access Request Policy as discussed in Section 3.5.

Figure 44. Per-Request Policy Selection Field



3.9.2.5 Captive Portal Configuration

For unauthenticated requests a captive portal can be used to capture user credentials and compare

those credentials against a user database and access policy to allow granular control over access.

Any unauthenticated session can be redirected to the SWG Captive Portal for Authentication before

allowing screened Internet access.

The SWG Captive Portal needs to have its own trusted certificate and key installed and a matching

Fully Qualified Domain Name (FQDN) in order to present the authentication page without a certificate

warning being issued by the browser.

Figure 45. Captive Portal Configuration

The F5 SWG solution provides two ways of presenting the Acceptable Use policy in a captive portal.

The first is a question form, where the user must choose to “Accept” or “Decline” the use policy. The

second is a message box that is presented with an “OK” button to continue.

Recommended Practice: F5 recommends that organizations present the “Accept” or “Decline”

option for acceptable use policies instead of a simple Okay.

Figure 46. Sample VPE policy with “Acceptable Use Policy Decision Box”



Recommended Practice: When configuring a captive portal, customize the format of the decision

box to provide a clear format for common browsers to ensure your policy is legible to its audience.

Consult the BIG-IP Access Policy Manager: Customization manual section for details:

http://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-customization-11-5-0.

html

Figure 47. Customized Acceptable Use Policy Decision Box Page

3.9.2.6 SSL Intercept

When SSL Intercept configuration is desired, the options in the following illustration are available. The

trusted subordinate certificate authority’s (CA) certificate and key should be installed. Many

organizations may have their own internal trusted CA already installed on their servers and

workstations.



Figure 48. SSL Intercept Configuration

The configuration sections under SSL Intercept Configuration, specifically “What action should be

taken for an expired certificate” and “What action should be taken for an untrusted certificate,” should

be noted. If the option is chosen to “ignore” in either case, the client will be presented with either an

invalid or expired certificate signed by the trusted CA. This can cause confusion for some users if they

examine the certificate. Others may just accept the certificate and continue on to the requested site.

If “drop” is selected for either case, the client browser will be presented with the connection-reset

message similar to the example below:

Figure 49. SSL Intercept Invalid Certificate Error ‘Block’



With either setting, support calls may be increased due to this behavior so SWG system administrators

should be aware of the differences.

Recommended Practice: Users may be accustomed to inspecting and accepting expired or invalid

certificates. Unless the security policy requirements dictate (as they do in PCI, High Security

environments) that untrusted certificates should be dropped and access to those sites denied,

configuration should be set to ignore.

Figure 50. Invalid Certificate Error Set to ‘Ignore’

3.9.2.7 Additional Transparent Proxy Considerations and Recommendations

If the transparent proxy is configured in the outbound Internet path, there are a couple of additional

considerations. Since it’s in the path, a configuration must be made for other network traffic such as

DNS. An enterprise’s DNS servers must be able to resolve and reach DNS servers across the Internet.

Another common usage of outbound Internet access is for email. In order for these services to pass

through the Secure Web Gateway, a forwarding virtual server must be configured.



The forwarding virtual server or numerous forwarding virtual servers can be configured as granular as

policy dictates and SNAT can be applied individually for protocols. If your outbound firewall is

providing SNAT and it is desired to have the native client IP address recorded on the firewall then do

not configure SNAT on the SWG.

Recommended Practice: Consult the F5 solution for forwarding virtual servers and configure

appropriate forwarding virtual servers and SNAT where desired.

For a more detailed discussion on forwarding virtual servers consult SOL7595: Overview of IP

forwarding virtual servers.

http://support.f5.com/kb/en-us/solutions/public/7000/500/sol7595.html

More SWG Recommended Practices

4.1 ValidationThe filtering-policy configuration should be validated before migrating the system into production.

Validation should include key components of your policy. Typically this would include validating that the

policy blocks requests to sites that violate the policy categories; validating that the policy allows for the

bypassing of SSL decryption for sensitive sites; and validating that malware scanning prevents the

download of malicious software if it is enabled.

4.1.1 Filtering Validation

Websense provides a website (https://testdatabasewebsense.com/) for safely validating the

configuration of your filtering policy. It can be accessed to safely validate categories for both clear text

http connections and secured https connections.

Figure 51. Websense URL Filtering Validation Page



https://testdatabasewebsense.com/



Blocked sites should result in a similar message page.

Figure 52. Blocked URL Response Page

The session reference number can be used to look up the user session and validate the sites they

were going to.

Figure 53. Event Logs



4.1.2 SSL Bypass

Validate SSL bypass configuration by leveraging the Websense test website. Or you can visit a site

matching the category and validate that the certificate is not signed by your local CA.

Figure 54. SSL Bypass Validation with Certificate Not Issued by Local CA

4.1.3 Malware Validation

Eicar.org provides links to download “safe” malware via both http and https. It is a text file that

contains strings that trigger malware protection but will not do any harm to your computer system and

contains both a clear text and encrypted (HTTPS) link.

http://www.eicar.org/85-0-Download.html

http://www.eicar.org/85-0-Download.html



4.2 Getting the Most from ReportingAdministrators today insist on rich reporting capabilities from their web-security solutions. Some

organizations have a policy that requires logging of every request, and others may only log only those

requests that trigger a risk alert.

Recommended Practice: Unless your organization needs specific, detailed logging, enable sampling

mode for SWG reporting. This will provide insight into the larger picture and trends, but won’t besiege

the reporting system with overwhelming amounts of browsing data.

If in-depth detailed logging is required in high-traffic or distributed environments, a third-party logging

tool is recommended.

Here are some examples of reports:

Figure 55. Request Count by Category



Figure 56. Top URLs by Request Count

Figure 57. Top Users by Request Count Where Action Contains Allowed

4.3 Manage Video Streaming with SchedulesMedia-streaming sites like Netflix are another type of entertainment site that the SWG can control

access to. Some organizations will want these sites blocked all the time. Some will want them

available only after hours (for those employees who have to be present but not necessarily engaged).



Figure 58. Schedule Configuration

Recommended Practice: Tune security policy to disallow video streaming from entertainment sites

during normal business hours.

4.3.1 Scheduling in SWG Version 11.6

Scheduling in SWG Version 11.6 is now configured in the Per-Request Policy as discussed in Section

3.5.

Figure 59. Dynamic Date Time Lookup in Per-Request Policy

4.4 Deleting Single User SessionsEvery administrator has experienced the situation where a configuration has been changed and

somehow a user session got trapped in between the changes. Often the best thing to do is delete the

session and let the user re-authenticate and re-route through the gateway. To delete the session or

sessions, select from those that are displayed and click the Kill Selected Sessions button. You can

also select multiple sessions at once by using the checkbox.



Figure 60. Active Sessions

The F5 user interface provides the ability to view and delete individual sessions from the “Manage

Sessions” screen under the “Access Policy” menu.

Recommended Practice: In large production environments, it may be more common to have user

sessions active for hours or even days as web pages often have embedded objects that dynamically

refresh. Some websites continuously poll for status updates or advertisements. If you need to quickly

apply a new access policy and cannot wait for sessions to time out, install the shell script detailed in

Appendix B on your SWG devices in the /shared directory so that it survives reboots and upgrades,

and run it as part of your process of modifying policies.

4.5 Customize Error Messages in the Proxy Auto-configuration (PAC) FileThe SWG has the ability to respond to browsers that request a “Proxy Auto-Configuration” file (PAC) or

(WPAD) file. These files contain all the information that the browsers need to talk to the SWG as an

outbound proxy.

The PAC file also contain the ability to configure settings for bypassing the proxy for sites within the

internal network. This is useful for reducing the bandwidth requirements and resources on the SWG

for internal zones.

Using the “HTTP Proxy” screen, an administrator can provide custom messages that even include

iRule primitives to provide more information to their users. For example, within failure messages, you

can include iRule primitives such as [HTTP::host].

Under Local Traffic -> Profiles -> Services -> HTTP



Figure 61. Failure Message Customization

The following message fields can be customized:

Connection Failed Message

Specifies the message that appears when a connection failure occurs. You can include TCL

expressions.

DNS Lookup Failed Message

Specifies the message that appears when a DNS lookup failure occurs. You can include TCL

expressions.

Bad Request Message

Specifies the message that appears when a bad request occurs. You can include TCL

expressions.

Bad Response Message

Specifies the message that appears when a bad response occurs. You can include TCL

expressions.

4.6 Ensure Safe Searches as Enterprise PolicyModern browsers and search engines include filtering modes to prevent search results from displaying

sites that are known malware hosts. Google refers to its filtering mode as Safe Search and Microsoft

calls its filtering mode SmartScreen Filter.

When users fail to use these safe modes, they can be exposed to malware and malicious URLs in their

unfiltered search results. The F5 Secure Web Gateway can detect and block links embedded inside

these search results, effectively making Safe Search a companywide policy.



4.6.1 Enforce Safe Searches as Enterprise Policy (Version 11.6)

In SWG Version 11.6, Safe Searches can be enforced as a policy within the Category Lookup Agent in

the Per-Request Policy. Search filtering is currently supported on Ask, Bing, DuckDuckGo, Google,

Lycos, and Yahoo.

Figure 62. Category Lookup with SafeSearch Mode Enabled

Recommended Practice: If your Acceptable Usage Policy is to deny explicit content, ensure when

using compatible search engines a safe search string is returned and the search results are filtered.

4.7 Limit Viral Videos Without Denying All Multimedia WebsitesThe Secure Web Gateway recognizes thousands of websites as entertainment sites. Administrators

can use this category to control not just access but how much access. For example, suppose that

periodic access to video website is necessary for an employee to do their job. However, the

organization doesn’t want employees watching all the viral videos that normally propagate around the

office every day.

The Secure Web Gateway can enforce this policy, allowing only a certain number of users to view any

one video within a period of time. Customers identify with this problem and love the solution for the

control that it provides.



Media-streaming sites like Netflix are another type of entertainment site that the SWG can control

access to. Some organizations will want these sites blocked all the time. Some will want them

available only after hours (for those employees who have to be present but not necessarily engaged).

Figure 63. Limiting Bandwidth-Consuming Services

Recommended Practice: For departments and users that require access to entertainment videos,

enable the viral-video category in the SWG to prevent users from spending too much time (and

bandwidth) watching so-called viral videos. Viral video is available as a subcategory of Bandwidth in

the URL Categorization database.

4.8 Protecting DNS ServicesDue to its strategic point of control in the network, the Secure Web Gateway can automatically

function as a transparent proxy for all of the user requests flowing through it to the Internet. When the

SWG is used this way, administrators do not have to make changes to each PC’s settings or to the

group policy.

Unlike transparent proxy mode, the explicit proxy mode requires administrators to explicitly define the

outgoing forward proxy for each of the target devices (and users) on the network.

A security benefit of explicit proxies is that the proxy becomes the default name server for all external

requests. This allows the administrator to detach the internal DNS server from having to serve external

addresses. This detachment means a reduction in the threat surface for name services. For example,

an attacker has mapped the network from the outside and discovered the internal DNS name server

intra.example.com. If this internal name server is detached from serving external addresses, the

attacker cannot poison its cache.



When used in explicit proxy mode, the SWG solution will intercept all name-related URL queries.

Because it is proxying these as well, it has the opportunity to help secure these transactions against

name attacks like cache-poisoning.

Recommended Practice: Use the DNS resolver profile to enable query-case-randomization.

Query-case-randomization adds an additional layer of security to name queries by randomly changing

the case of a name and then ensuring that the reply has the same exact case as the modified request.

It is enabled by default in the iApp.

Figure 64. DNS Query Randomization


Solutions for an application world.

F5 Networks, Inc.Corporate [email protected]

F5 Networks, Inc. 401 Elliott Avenue West, Seattle, WA 98119 888-882-4447 www.f5.com

F5 [email protected]

F5 Networks Ltd.Europe/Middle-East/[email protected]

F5 NetworksJapan [email protected]

©2014 F5 Networks, Inc. All rights reserved. F5, F5 Networks, and the F5 logo are trademarks of F5 Networks, Inc. in the U.S. and in certain other countries. Other F5 trademarks are identified at f5.com.

ConclusionIn conclusion, the F5 Secure Web Gateway (SWG) solution is a powerful and robust platform that

allows organizations superior controls around user-generated Internet traffic.

Leveraging the power of the Websense categorization database and content scanning, Secure Web

Gateway can be used to protect clients in common deployment scenarios. Those typical scenarios

addressed are for Corporate Networks, Guest Networks, and Secure PCI DSS cardholder data

environments. Additionally, the SWG recommended practices address the replacement of the

Microsoft TMG. The threats from malicious sites and programs on the Internet are constantly

expanding and evolving. The SWG is a powerful tool in the customer scenarios of context-aware

security, bandwidth control, and Acceptable Use Policy presentation; while helping customers achieve

compliance for PCI DSS.

mailto:info%40f5.com?subject=

http://www.f5.com

mailto:apacinfo%40f5.com?subject=

mailto:emeainfo%40f5.com?subject=

mailto:f5j-info%40f5.com?subject=

F5 Secure Web Gateway Recommended Practicesstatic.newsletter.veracomp.pl/files/dcdd50c93adf5913f...A...

Documents

Transcript of F5 Secure Web Gateway Recommended Practicesstatic.newsletter.veracomp.pl/files/dcdd50c93adf5913f...A...