Installing McAfee Agent for SSL Decryption at F5
McAfee agent can be installed in the Linux Based OS. Even though F5 is a CentOS-based Linux installation, I understand that the McAfee agent cannot be installed on it. I am looking for any supporting documentation published by F5 which says that external agents cant be installed on it.
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 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 solution
F5 ASM with Mcafee Virusscan for storage ICAP server
Dear all, Working on a integration with F5 ASM with Mcafee Virusscan for storage (ICAP server) and the server keeps sending me HTTP response code 400 Bad Request. Below the configuration and Wireshark output and logs. Following is the response code 400 In ASM request log the following is being logged This is the ouput of that log F5 is configured with /REQMOD as stated in the documentation I believe we are using the right solution for ICAP scanning Mcafee Virusscan for storage with ICAP AV scanner enabled version 8.8 hotfix 4 and Enterprise for storage 1.1
Problem with session persistence using CARP when load balancing a McAfee Web Gateway cluster using progress page for downloads
We have a cluster of 14 McAfee Web Gateways and about 15000 users connecting to them from a few dozen Citrix farms. Previously we have been using source address persistence, which works fine until one of the pool members are taken offline then online again. All clients will then be load balanced to another available pool member and the one that was offline gets no traffic after that. Enter hash persistence using CARP. The idea is simple, use something like the host header and make a hash of it then load balance using the CARP algorithm. This also works great, except when downloading files. McAfee Web Gateway works like this; it downloads the file for malware scanning before delivering it to the client. Meanwhile it displays a progress page to the client. The problem is that with hash persistence quite often the progress page will show an error. This is because I get loadbalanced to a different pool member than the one showing me the progress page. I really would like to use hash persistence, but I'm not sure there is a proper workaround for this. Any suggestions? What are you guys doing for persistence to web caches?
