F5 SSL Orchestrator and McAfee Web Gateway Solution for SSL Visibility and Management
Data transiting between clients (e.g. PCs, tablets, phones, etc.) and servers are predominantly encrypted with Secure Socket Layer (SSL) or the newer Transport Layer Security (TLS). 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 (For reference, see the TLS Telemetry Report Summary from F5 Labs). An integrated F5 SSL Orchestrator and McAfee Web Gateway (MWG) solution provide visibility and management of SSL/TLS traffic to expose the hidden malware, data exfiltration, and command and control threats. F5 SSL Orchestrator with its ability to address HTTP proxy devices inside its decrypted inspection zone allows the MWG to provide optimal security functionality while offloading SSL and complex orchestration to the F5 system. Bill of Materials F5 SSL Orchestrator Optional functional add-ons include URL filtering subscription, IP Intelligence subscription, network hardware security module (HSM), and F5 Access Manager (APM). McAfee Web Gateway 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 the root certificate is imported into the client browser. SSL orchestration generally presents a new paradigm in the typical network architecture. Integrated with SSL Orchestrator, the traffic to the MWG is decrypted – including usernames, passwords, social security, and credit card numbers, etc. It is therefore highly recommended that security services be isolated within a private, protected enclave defined by the SSL Orchestrator. Solution Deployment In this example deployment setup, the SSL Orchestrator is configured to send decrypted traffic to an inline MWG. SSL Orchestrator handles both decryption and re-encryption of HTTPS traffic, with an inspection zone installed between the ingress and egress. Decrypted traffic is steered to a service pool of MWG devices. You can also deploy the F5 system as a device sync/failover device group (including an HA pair) with a floating IP address for high availability. Configure the Web Proxy Service Before the MWG can receive traffic from the SSL Orchestrator, there are a few basic configurations that must be completed.Any and all licenses should be applied, and the basic system setup should be completed. Along with many other settings, the system setup will include the configuration of the hostname and Domain Name Servers (DNS).The system hostname should be configured as well as the IP address, subnet mask, and hostname for the management interface. The following settings will detail how to configure MWG as an explicit proxy. Please refer to the appropriate MWG documentation for more detailed information on configuring MWG. In the MWG UI under Appliances -> (this appliance) -> Proxies (HTTP(S), FTP, SOCKS, ICAP…): 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. Select L3 Outbound (transparent proxy) or L3 Explicit Proxy to support decrypted forward proxy traffic flows through the MWG. 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 Web Gateway 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 Secure Web Gateway HTTP Proxy' service and configure the service settings: McAfee Web Gateway IP address, port, and connected VLANs. In the MWG Web UI, create these routes to route from the MWG appliance back to SSL Orchestrator. A gateway route to SSL Orchestrator 'from-service' self-IP ( 198.19.96.245 in the above example). A static return route to define the path back to the SSL Orchestrator 'to-service' self-IP (198.19.96.7 in the above example) on the inbound side of the MWG. Using the SSL Orchestrator 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 ordered list 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. Testing the Solution Use one of the following ways to observe the decrypted traffic Server certificate test To test an explicit forward proxy topology, configure a client’s browser proxy settings to point this listening IP and port. Ensure that the client trusts the local issuing CA certificate. Open a browser from the client and attempt to access an external HTTPS resource. Once the page is loaded, observe the server certificate of that site and take note of the certificate issuer, which should be the local issuing CA. If you have access to the client’s command-line shell and the cURL or wget utilities, you can simulate browser access using one of the following commands: curl -vk --proxy [proxy IP:port] https://www.example.com wget --no-check-certificate -e use_proxy=yes -e https_proxy=[proxy IP:port] -dO – https://www.example.com Both of these commands will display both the HTML server response and the issuer of the server’s certificate. Decrypted traffic analysis on the SSL Orchestrator Perform a tcpdump on the SSL Orchestrator to observe the decrypted clear text traffic. This confirms the SSL interception by the F5 system. tcpdump –lnni [interface or VLAN name] -Xs0 The security service VLANs and their corresponding application services are all visible from the SSL Orchestrator GUI: Network -> VLANs. Decrypted traffic analysis on the McAfee Web Gateway From the MWG UI, use the Packet Tracing feature to capture traffic on all interfaces. Analyze the tcpdump to observe the decrypted clear text traffic. Additional Resources Learn more about SSL Orchestrator on f5.com Recommended best practices guide: F5 SSL Orchestrator and McAfee Web Gateway SolutionF5 SSL Orchestrator - Symantec DLP Integrated Solution
The Secure Sockets Layer (SSL) protocol and its successor, Transport Layer Security (TLS), have been widely adopted by organizations to secure IP communications. But while SSL provides data privacy and secure communications, it also creates challenges to inspection devices such as data loss prevention (DLP) software in the security stack. In short, the encrypted communications cannot be seen as clear text and are passed through without inspection, becoming security blind spots. This creates serious risks, leaving organizations vulnerable to costly data breaches and loss of intellectual property. But today’s security devices, such as intrusion prevention systems (IPSs) and next-generation firewalls (NGFWs), lack the processing power to easily decrypt SSL/TLS traffic. This performance concern becomes even more challenging with the demands of 2048-bit certificates. An integrated F5 SSL Orchestrator and Symantec Data Loss Prevention (DLP) solution solves these SSL/TLS challenges across cloud, mobile, and on-premises environments. F5 SSL Orchestrator centralizes SSL inspection across complex security architectures, providing flexible deployment options for decrypting and re-encrypting user traffic. It also provides intelligent traffic orchestration using dynamic service chaining and policy-based management. Once decrypted, the traffic is inspected by Symantec DLP, which can detect, and block data breaches and exfiltration of sensitive data previously hidden by encryption. This joint solution thus eliminates the blind spots introduced by SSL and closes any opportunity for attackers. Solution Overview Functional implementation of the solution involves both SSL visibility and content adaptation. 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 client and server with SSL visibility for inspection. Within the decryption zone, the content adaptation feature of SSL Orchestrator conditionally forwards both unencrypted HTTP and decrypted HTTPS requests by encapsulating them within Internet Content Adaptation Protocol (ICAP, RFC3507). These encapsulated requests go to a pool of Symantec DLP servers for inspection and possible request modification (REQMOD). In this context, SSL Orchestrator is the ICAP client and Symantec DLP is the ICAP server. After inspection, HTTPS requests are re-encrypted on their way to the web server. The same process of decryption, inspection, possible response modification (RESPMOD), and re-encryption takes place for the return response from the web server to the client. The F5 SSL Orchestrator and Symantec DLP solution Bill of Materials F5 SSL Orchestrator 5.1 Optional functional add-ons include URL filtering subscription, IP intelligence subscription, network hardware security module (HSM) and F5 BIG-IP Access Policy Manager (APM) Symantec Data Loss Prevention (DLP) 15.0 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. Symantec DLP is installed and set up with IP connectivity to SSL Orchestrator. Symantec DLP software is composed of three components: Oracle Database, Enforce Server, and a detection server. Refer the Symantec technical documentation to further understand the various deployment types. Solution Configuration Steps The solution deployment involves policy creation on Symantec DLP and configuration of SSL Orchestrator on the F5 system. I. Configure DLP Policy On the web UI of the Symantec DLP Enforce Server, navigate to the Policies page and configure a policy. For example, here we show configuration of a policy named symconfidential with a rule type of Content Matches Keyword and the keyword confidential. II. Deploy SSL Orchestrator using Guided Configuration SSL Orchestrator version 5.1 introduced Guided Configuration, a workflow-based architecture that provides intuitive, re-entrant configuration steps and presents a completely new and streamlined user experience. To deploy the SSL Orchestrator application, log into the F5 system. On the F5 Web UI Main menu, navigate to SSL Orchestrator > Configuration and follow the guided configuration steps. 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 ultimately create an explicit proxy listener. Step 2: SSL Properties Select the previously imported subordinate CA certificate (see Prerequisites, above) to sign and issue certificates to the end-host for client-requested HTTPS websites that are intercepted. Step 3: Create the 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 ICAP service and configure the service settings: Symantec 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 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 BIG-IP LTM virtual servers 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 The configuration summary page presents an expandable list of all the workflow-configured objects. Review the setting and click Deploy to deploy SSL Orchestrator. SSL Orchestrator will be successfully deployed on the F5 system. III. Verification From the client, open Gmail or any other email service and compose an email with the body containing “confidential” and press Send. You will see the mail blocked with the following alert in Symantec DLP server. Conclusion The joint solution from F5 and Symantec brings together the best of application delivery and data security to help you identify and stop data loss. By taking advantage of ICAP and other standards, this joint solution gives you easy-to-use tools and granular control to decrease the risk of data breaches and data ex-filtration. Learn more: Product page: F5 SSL Orchestrator
SSL Intercept
Hi All, fairly new to using an iApp - so here is my question. We need to be using the SSL_intercept_SVC_chain iApp to mitigate the scenario where TLS 1.0 is no longer supported in the big wide world. Basically we have a number of old apps that will only use TLS 1.0 and since this is now being deprecated we plan to use the F5 to handle the client to F5 as TLS 1.0, but then forwards onto external sites as TLS1.2 or 1.3. I have downloaded the iApp, and have worked out all the settings I need to use to make the Application Service - however what I don't get is how to join together the AS and a virtual server. We plan to use an internal DNS entry for selected external sites so that the traffic is forced to the F5 and passed to the internet, and away from our proxies thereby using the F5 to do the TLS re-negotiation/upgrade. We have a two LTMs running in HA so its not a case of passing it from one F5 to another F5 via a decrypt zone. Once I have run the iApp - what do I need to do to use it.
Service chains packet processing for L3 devices
Hello, I'm trying to understand SSL intercept and Service Chains, and have a few questions about it: According to a devCentral video, https://www.youtube.com/watch?v=mvse6zCt_jo , devices in a service chain are accessed in parallell, minimizing the delay in a long chain with many inspection devices. However, reading the SSL intercept deployment guide, it says " Each service chain is an ordered list of services of various types", that sounds like the devices are processed one at a time? Question 2: When you hook up a L3 device in your service chain, does the complete packet get sent to the device and back again to the BIGIP (if allowed though the L3 device)? Question 3: What about the return traffic, is it automatically send back to the sending interface of the L3 device? In my case the L3 device is a NGFW, I'm asking because I want to know if the traffic flow will be weird in any way from the NGFW point of view (statistics, logging and so on).Lightboard Lessons: Air Gap Architectures
In this episode of Lightboard Lessons, Jason covers a couple deployment options for routing traffic through an IPS tier while maintaining source IPs. The first option compresses the external and internal legs of the air gap solution onto a single BIG-IP (or pair) by using route domains. The second option splits the external/internal requirements onto separate BIG-IPs to allow for isolated vertical security zones. Resources SSL Intercept iApp SSL Intercept Deployment Guide IPS Bridged Air Gap Solution (Lightboard Lesson | Article)F5 Networks Response to US-CERT Alert (TA17-075A) HTTPS Interception Weakens TLS Security
F5 Networks Response to US-CERT Alert (TA17-075A) HTTPS Interception Weakens TLS Security Summary When properly configured, the F5 BIG-IP addresses nearly all the concerns, and avoids nearly all the risks, specified in US-CERT Alert (TA17-075A). This is the key point; on BIG-IP most of the functionality, and the level of security, is determined by the customer created configuration. Whether certificates are validated, and the level of validation, is determined by the configuration, as are the specific cipher suites and protocols that are supported, etc. There are a couple of corner cases, as explained below, where the BIG-IP does not fully meet the recommendations; F5 Networks is continuously improving our products and working to address these areas in future releases. In short, when properly configured, the F5 BIG-IP or SSL Orchestrator can perform SSL Interception without compromising overall security. Detailed Examination A great deal of interest has been generated by the recent publication of US-CERT Alert (TA17-075A) HTTPS Interception Weakens TLS Security. This is of interest to F5 customers as we do support SSL Intercept on BIG-IP, as well as commonly being used for SSL/TLS termination. While the US-CERT Alert does not name F5 Networks, a primary reference for the alert is a two year old blog post, The Risks of SSL Inspection, which does. It is important to acknowledge upfront that the concern, in general, is not unwarranted. Any point where encrypted communications are decrypted, such as for SSL Intercept, is a potential weak link in the chain, a point of increased vulnerability. But it is equally important to acknowledge that such interception may be necessary as part of a comprehensive security solution. Interception allows for traffic inspection, such as to protect networks from malware or phishing attempts. It is also used for scanning inbound & outbound traffic for evidence of data extraction or an existing intrusion. Without the use of SSL/TLS Interception at an ingress or egress chokepoint, the same level of protection could only be achieved by monitoring every end-point device on the network. End-point protection is much more resource intensive, and it may not be practical to do so on appliances such as routers, switches, or even networked printers. With the growth of the Internet of Things (IoT) endpoint-based protection is increasingly unfeasible. It is not possible to run detection software on every connected thermostat or lightbulb. Malware is increasingly using encrypted communication to hide from conventional detection systems, and interception is required to level the playing field. In response to the question of ‘why use or support SSL/TLS interception at all?’ consider an even larger question: If not SSL/TLS interception, how do you provide equivalent protection? Using interception may add some risk, but there are greater risks in not detecting and blocking malware, phishing attempts, intrusions, etc. Security is about minimizing the overall risk, and tradeoffs are required. SSL/TLS interception is a useful tool and when used well it adds minimal risk while providing a great security benefit. While the US-CERT Alert generalizes, the cited blog post raised specific technical concerns which have subsequently been raised by customers. These points are addressed in Appendix A. A second reference cited in the alert, a research paper, The Security Impact of HTTPS Interception, touches on several other potential issues. This include the protocols supported by the interception device (allowing a protocol downgrade), the ciphers allowed by the device, etc. On F5 products these are configurable in the associated profiles. The level of security, or vulnerability, is determined by the configuration used by the customer – and not F5 or the BIG-IP inherently. Customers who had additional concerns, or who desire assistance in configuring their BIG-IP to meet their specific needs, are encouraged to reach out to their F5 Account Team and/or F5 Professional Services. The key point to take away is that the F5 products can perform SSL Interception without compromising security, but it comes down to the configuration that is used. It is a tool, and like any tool it can be used skillfully or haphazardly. Customer are advised to properly configure the system for their specific needs, and best practices should always be followed. When it comes to security, being conservative in what you accept and enforcing higher levels of validation is always recommended and any exceptions to these practices should be well considered. Used judiciously, SSL Interception can make a net positive contribution to security. Appendix A: F5 Networks response to The Risks of SSL Inspection technical points. 1) Incomplete validation of upstream certificate validity Some SSL-inspecting software fails to validate the certificates of systems that it connects to. In some cases, the software may attempt to perform some validation of the certificate, but the validation may be insufficient. Risks: Clients cannot know if they are connected to a legitimate site or not. F5 Response: Configuration Dependent Certificate validation is configuration dependent. Customers can configure the CA bundle that is used to authenticate downstream certificates. They can also configure whether to allow connection to servers with expired certificates, or to servers with untrusted certificates. Note that the default is to ignore both expired and untrusted certificates, so customers should change this during configuration if they desire increased validation. To satisfy the US-CERT recommendations, the configuration should not allow connections with expired or untrusted certificates; Ultimately, the customer is in control of the configuration, and therefore the requirements for certificate validation. Note that once the upstream certification is validated, the BIG-IP does cache the certificate it generates for the client. This is to improve performance, as certificate generation and signing is a computationally expensive operation. While this certificate remains in the cache, the upstream certificate is not re-validated. The cache lifetime may be configured, trading off re-validation time for performance. F5 Networks is also working to add OCSP Stapling support in a future release. 2) Not conveying validation of upstream certificate to the client In some cases, the SSL inspection software does perform validation of upstream certificates, but it does not relay the results of the validation to the client. Risks: Clients cannot know if they are connected to a legitimate site or not. F5 Response: Configuration Dependent If the BIG-IP is configured to perform certificate validation and the upstream certificate does not pass, the upstream connection will not be completed. In turn the client connection will be disconnected. If the configuration allows upstream connections with untrusted certificates the client is not informed if the certificate has failed validation. There are two different validations performed: expiration and trust: If set to ignore an expired cert, the BIG-IP will re-issue and cache an expired cert to the client. This satisfies the notification recommendation in the US-CERT Alert; the client can make the same evaluation as it would without the BIG-IP in the path. If set to ignore an untrusted cert, the BIG-IP will re-issue and cache a valid cert to the client. This does not satisfy the notification recommendation in the US-CERT Alert. F5 Networks is planning a change to this behavior in a future release to better align with the US-CERT recommendations. To satisfy the US-CERT recommendations, F5 Networks recommends not ignoring expired or untrusted certifications, and allowing connections only with sites issuing current, trusted certificates. 3) Overloading of certificate Canonical Name (CN) field Some SSL inspecting software attempts to relay the validity of the upstream certificate to the client by way of the CN field of the certificate. For example, Komodia SSL Digestor changes the CN to begin with "verify_fail" if the server-provided certificate is invalid for any reason. There are a number of issues with this technique. The most obvious mistake being that the actual error conveyed to the user usually has nothing to do with why it failed. Risks: Users of client systems may not know why certificate validation failed, or even if it failed. An attacker may be able to specify a Subject Alternative Name field to specify any domain that the certificate specifies it is valid for, which results in a browser that does not display a certificate warning. F5 Response: Not Applicable F5 does not overload the certificate CN field. 4) Use of the application layer to convey certificate validity To relay the validity of the certificate to the client, some SSL inspectors provide web content (e.g. HTML) to the client, describing what is wrong with the certificate. The normal mechanisms through which client software ascertains and displays certificate validity may still indicate that the certificate is fine. Risks: Not everything that accesses data using HTTPS is a human using a web browser. For example, the client may be an application that communicates with a server using JSON data. This flaw also causes inconsistent use of SSL validity indicators (e.g., "Where do I look for the padlock again?"). F5 Response: Not Applicable F5 does not use the application layer to convey meta information. 5) Use of a User-Agent HTTP header to determine when to validate a certificate Some software will selectively decide when to validate upstream certificates based on the User-Agent HTTP header provided by the client. This technique is likely used in conjunction with the technique described above where certificate validity is conveyed in the application layer. Risks: Not every web client may receive certificate validation. Various web browser versions and non-browser software may be exempt from validation. F5 Response: Not Applicable F5 does not use the User-Agent HTTP header to determine when to validate a certificate. This is controlled strictly by the configuration; if validation is required it is performed for all connections. 6) Communication before warning Upon detecting a certificate error, some SSL inspection applications will send the client's request to the server prior to presenting a warning to the user. Risks: An attacker still may be able to view or modify sensitive data. F5 Response: Not Applicable F5 does not do this. If the upstream connection fails validation we do not complete the connection, let alone forward the client’s request. 7) Same root CA certificate Some SSL inspection applications use and install the same trusted root CA certificate for each installation of the application. Risks: An attacker may be able to extract the private key from the software and sign all visited sites with the universally-trusted root CA certificate. F5 Response: Configuration Dependent On F5 BIG-IP the customer provides the CA certificates and configures the CA bundle to use for validation. This is entirely under the control of the customer.
SSL Intercept with F5 in L2 mode
I am looking for a deployment where I configure same VLAN to the ports my client and server are connected. I would like to intercept this traffic. Is this possible on F5. The current scenario explained in the F5 doc is to have self-ips for server and client vlans and route the traffic to the F5 using these IPs. Anyone is aware of deployment without these self-ips and having client and server in the same vlan?
