You can integrate the F5 BIG-IP System with Network Prevent for Web.  You configure the integration as an ICAP client-server solution.

Configuration process

During testing, Symantec identified a few issues that can be mitigated or fixed by configuring the F5 BIG-IP System as detailed in the procedures provided here. Following these procedures ensures that the F5 BIG-IP System can be integrated with Symantec Data Loss Prevention as an ICAP client-server solution.

The Symantec team tested this integration on the F5 virtual appliance running BIG-IP, version 12.0.0 and version 13.1.0.8.  The following procedures are based on results from this internal testing.  You may have specific requirements that need additional configuration.  In that case, contact F5 support or Symantec support for assistance.

iRules

You must configure iRules for the F5 BIG-IP System and assign them to the respective virtual servers for processing the ICAP request, so that the Symantec Data Loss Prevention ICAP server can take appropriate actions.

1. To identify the authenticated users in Data Loss Prevention incidents, an X-Authenticated-User header must be included in ICAP traffic. You can use the following iRule:

when ICAP_REQUEST{
ICAP::header add X-Scan-Progress-Interval 10 
ICAP::header remove X-Client-IP
ICAP::header remove Date 
HTTP::header remove Accept-Encoding
ICAP::header add X-Authenticated-User [HTTP::header X-Authenticated-User]
} 

This iRule must be added to the internal virtual server that is configured with the ICAP profile and the ICAP server pool.  It must be combined with the following second iRule that is added to a Standard Virtual Server.

2. Configure a second iRule to insert the authenticated user's information in HTTP traffic that is eventually transmitted as ICAP traffic: 

when ACCESS_ACL_ALLOWED {
log local0. "user authenticated"
set authuser [ACCESS::session data get session.logon.last.username]
HTTP::header insert "X-Authenticated-User" [b64encode $authuser]
log local0. "x-auth header inserted $authuser"
} 

Note that this iRule is added to the standard virtual server that processes traffic on service port 443 and that has the ICAP policy applied to it.

Profiles

For profiles, the following values are recommended when setting up F5 as a forward proxy or as a reverse proxy.

 For the Adapt Profile: 

• Preview Size = 0
• Timeout (ms) = 0
• Service Down Action = Reset (unless otherwise needed) 

See the attachments for sample setting in the F5 BIG-IP interface.

We encountered an issue where Gmail attachments larger than a certain size get stuck during uploading with the default connection timeout settings on F5.

Workaround: We advise you to increase the Request Adapt service timeout value until the uploading issue is resolved.

For example, if it normally takes x seconds to upload an attachment, the timeout value should be greater than this value.

To increase this value in the F5 BIG-IP user interface:

Go to Local Traffic and hover over Profiles > Services and click Request Adapt.

Then, click the service name corresponding to your application and change the Timeout(ms) value for the ICAP Profile to: 

          Preview Size = 0

Known issues

1.  Content-heavy mails or attachments may intermittently fail to go through because of network latency between the F5 BIG-IP System ICAP client and the Data Loss Prevention ICAP client.

Workaround:  If you plan to deploy the F5 BIG-IP System as a proxy server and as an ICAP client, Symantec recommends deploying the ICAP server in same network segment to mitigate this issue.

2.  Large attachment uploads fail when No policy or Pass policy is violated. Note that this may not be limited to attachment uploads. It may also apply to mails with large content or in any case where large content is transmitted using the F5 BIG-IP System as the ICAP client with the Data Loss Prevention ICAP server.

Recommendation: This may be a performance-related issue with the F5 BIG-IP virtual appliance that was used for testing, so Symantec recommends that you repeat the following tests with a physical appliance during the proof-of-concept phase of deployment.

Here is a sample scenario where you might encounter this issue when testing with the F5 virtual appliance:

1. Configure the F5 BIG-IP System as an ICAP client with Symantec Data Loss Prevention Network Prevent for Web as an ICAP server.

2. Ensure that the ICAP Preview Size is set to 0, and the Timeout(ms) is set to 0 on the F5 BIG-IP System.

3. Configure two keyword policies: One without any response rule and another with a response rule to redact or block HTTP content.

4. Configure the F5 BIG-IP System as an explicit proxy on the Firefox browser at the client's end.

5. Log on to Gmail from this browser and upload an attachment greater than 15 MB that violates the first policy (that has no associated response rule).

6. Then, upload another attachment greater than 15 MB that violates the second policy (associated with the redact response rule).

7. Upload another large attachment greater 15 MB that doesn't violate any policy. 

Expected results

1. The attachment violating the first policy uploads and a corresponding incident is generated on the Enforce Server.

2. The attachment violating the second policy uploads. The content is redacted or blocked (based on the response rule applied) and the corresponding incident is generated on the Enforce Server.

3. The attachment that doesn’t violate any policy uploads without incident on the Enforce Server.

Actual results

1. The attachment upload fails and an incident is generated against the first policy on the Enforce Server.

2. The attachment upload succeeds with content redacted or blocked (according to the response rule).  An incident is generated against the second policy on the Enforce Server.

3. The attachment upload fails and no incident is generated on the Enforce Server.