F5 SSL Orchestrator and McAfee DLP Solution for SSL Visibility and Content Adaptation
Data transiting between clients (e.g. PCs, tablets, phones, etc.) and servers is predominantly encrypted with Secure Socket Layer (SSL) or the newer Transport Layer Security (TLS) (For reference, see the 2019 TLS Telemetry Report Summary from F5 Labs). Pervasive encryption results in threats being hidden and invisible to security inspection unless traffic is decrypted. This creates serious risks, leaving organizations vulnerable to costly data breaches and loss of intellectual property. An integrated F5® SSL Orchestrator™ and McAfee Data Loss Prevention (DLP) solution solves this SSL/TLS challenge across cloud, mobile, and on-premises environments. SSL Orchestrator centralizes SSL inspection throughout the complex security architectures, providing high-performance decryption of web traffic for security services like McAfee DLP to detect and block data breaches hidden by encryption. This joint solution thus eliminates the blind spots introduced by SSL and closes any opportunity for attackers. Solution Overview F5 SSL Orchestrator, deployed inline to the wire traffic, intercepts any outbound secure web request and establishes two separate SSL connections, one each with the client (the user device) and the requested web server. This creates a decryption zone between the client and the server for inspection. Within the inspection zone, both unencrypted HTTP and decrypted HTTPS requests are encapsulated within Internet Content Adaptation Protocol (ICAP, RFC3507) and steered to the McAfee DLP systems for inspection and possible request modification (REQMOD). In this context, SSL Orchestrator is the ICAP client and McAfee DLP is the ICAP server. After inspection, user HTTPS requests are re-encrypted by SSL Orchestrator, on their way to the web server. The same process of decryption, inspection, and re-encryption takes place for the return response from the web server to the client. Bill of Materials F5 SSL Orchestrator 16.0 Optional functional add-ons include URL filtering subscription, IP intelligence subscription and network hardwaresecurity module (HSM) McAfee Data Loss Prevention 11.4 Pre-requisites F5 SSL Orchestrator is licensed and set up with internal and external VLANs, and self-IP addresses. An SSL certificate—preferably a subordinate certificate authority (CA)—and private key are imported into SSL Orchestrator. The CA certificate chain with root certificate is imported into the client browser. Solution Configuration Steps The solution deployment involves policy creation on McAfee DLP and configuration of SSL Orchestrator on the F5 system. I. Configure DLP Policy Log in to the McAfee ePolicy Orchestrator [ePO] system and create a rule set to block PII related violations and assign it to a DLP policy. II. Deploy SSL Orchestrator using Guided Configuration The SSL Orchestrator guided configuration presents a completely new and streamlined user experience. This workflow-based architecture provides guided configuration steps tailored to a selected topology. Step 1: Topology Properties SSL Orchestrator creates discreet configurations based on the selected topology. Selecting explicit forward proxy topology (as shown in the example) will create an explicit proxy listener. Step 2: SSL Configuration Select the previously imported subordinate CA certificate (see Prerequisites, above) for signing and issuing certificates to the end-host for client-requested HTTPS websites that are intercepted by SSL Orchestrator. Step 3: Create the McAfee DLP ICAP Service The services list section defines the security services that interact with SSL Orchestrator. The guided configuration includes a services catalog that contains common product integrations. In the service catalog, double click the McAfee DLP ICAP service and configure the service settings: McAfee DLP IP address, port, URI paths and preview maximum length. Using the service catalog, create additional security services as required before proceeding to the next step. Step 4: Service Chains Create a service chain, which is an arbitrarily ordered lists of security devices. The service chain determines which services receive decrypted traffic. Step 5: Security Policy SSL Orchestrator’s guided configuration presents an intuitive rule-based, drag-and-drop user interface for the definition of security policies. In the background, SSL Orchestrator maintains these security policies as visual per-request policies. If traffic processing is required that exceeds the capabilities of the rule-based user interface, the underlying per-request policy can be managed directly. Use this section to create custom rules as required. Step 6: Intercept Rule Interception rules are based on the selected topology and define the listeners (analogous to BIG-IP Local Traffic Manager virtual servers) that accept and process different types of traffic, such as TCP, UDP, or other. The resulting listeners will bind the SSL settings, VLANs, IPs, and security policies created in the topology workflow. Step 7: Egress Settings The egress settings section defines topology-specific egress characteristics like NAT and outbound route. Step 8: Summary Review the setting and click deploy SSL Orchestrator. III. Verification Open browser and navigate to https:///dlptest.com (DLPTest.com is a DLP testing resource that focuses on testing to make sure your DLP software is working correctly).In the HTTPS Post section, input some PII data In the text box (an example of PII data is ‘ABC Smith, 123-45-6789, 123 Main St, Seattle WA 98008’) and click on the Submit button.You will see the ‘Access Denied’ message in the response. The DLP Incident Manager web page reports the PII violation. Additional Resources Learn more about SSL Orchestrator on f5.com Recommended best practices guide: F5 SSL Orchestrator and McAfee DLP solutionICAP 204 Response Frequently Asked Questions
The question keeps coming up: Why doesn’t BIG-IP support internet content adaptation protocol (ICAP) 204 response? (meaning beyond the preview, as would be indicated to the server by the optional "Allow: 204" header). Detailed explanations are below, with sequence diagrams to support the explanations following. Does BIG-IP support the "204 no-content" response from an ICAP server. Yes, as long as it is within or immediately following the preview. BIG-IP is an ICAP client. After the preview has been sent, BIG-IP awaits a response from the server. If it is 204, BIG-IP will replay its preview to the HTTP client or server instead of awaiting a response from the ICAP server. If it is "200 ok" or "100 continue", BIG-IP will drop its preview and stream the response from the ICAP server as it arrives. Why doesn't BIG-IP support ICAP "Allow: 204" so that a "204 no-content" response can be issued by the ICAP server at any time? The ability to accept 204 after the server has responded to the preview, is an optional client capability that must be announced by the client with an “Allow: 204” header in the request to the server. Whether to support it is explicitly left to the client “because it imposes a burden on the client of buffering the entire message” (RFC 3507 section 4.6). Since BIG-IP is not a storage device and handles many connections concurrently (not all ICAP) with finite memory, it cannot support unbounded buffering. Even a single ICAP message can be gigabytes long (e.g. video) so an attempt to buffer beyond a well-defined (smallish) preview could exhaust memory and crash the entire BIG-IP, depending on what the ICAP server does (which we have no control over). Therefore we do not support "Allow: 204" and do not announce it. What if I use an iRule to add the "Allow: 204" header to the ICAP request? Using the iRule command "ICAP::header add Allow 204" in the ICAP_REQUEST event will insert the header "Allow: 204" into the ICAP request, but will not affect the behavior of the Big-IP as an ICAP client. It will not enable the desired functionality. It will, however, misinform the ICAP server into thinking the client can accept 204 outside of the preview. When the server responds with 204 outside the preview, the Big-IP ICAP client will (correctly) treat it as an error and reset the ICAP connection. It will also report an error to ADAPT which will perform its service-down-action, having already dropped its copy of the preview. The ICAP server will have stopped streaming the response payload, and that data will be lost. Can Internal Virtual Servers be assigned to a route-domain? The clientside of an IVS is referred to by name and does not have a destination address at all, therefore there is no restriction on the route domain. Internally, the IVS is a virtual server in which the destination is ignored, but it still has the destination fields (which have value 0 and are ignored). Is there any reason to doubt that Internal VSs will work with route-domains? The server side is the same as any other VS. The client side has no destination, therefore no route domain. Sequence Diagrams Normal request modification with preview Request modification with 204 response to preview Request modification with 204 response beyond preview (Unsupported) Normal response modification with preview Response modification with 204 response to preview Response modification with 204 response beyond preview (Unsupported)
