Implementing SSL Orchestrator - High Level Considerations
Introduction This article is the beginning of a multi-part series on implementing BIG-IP SSL Orchestrator. It includes high availability and central management with BIG-IQ. Implementing SSL/TLS Decryption is not a trivial task. There are many factors to keep in mind and account for, from the network topology and insertion point, to SSL/TLS keyrings, certificates, ciphersuites and on and on. This article focuses on pre-deployment tasks and preparations for SSL Orchestrator. This article is divided into the following high level sections: Solution Overview Customer Use Case Architecture & Network Topology Please forgive me for using SSL and TLS interchangeably in this article. Software versions used in this article: BIG-IP Version: 14.1.2 SSL Orchestrator Version: 5.5 BIG-IQ Version: 7.0.1 Solution Overview Data transiting between clients (PCs, tablets, phones etc.) and servers is predominantly encrypted with Secure Socket Layer (SSL) and its evolution Transport Layer Security (TLS)(ref. Google Transparency Report). Pervasive encryption means that threats are now predominantly hidden and invisible to security inspection unless traffic is decrypted.The decryption and encryption of data by different devices performing security functions potentially adds overhead and latency.The picture below shows a traditional chaining of security inspection devices such as a filtering web gateway, a data loss prevention (DLP) tool, and intrusion detection system (IDS) and next generation firewall (NGFW). Also, TLS/SSL operations are computationally intensive and stress the security devices’ resources.This leads to a sub-optimal usage of resource where compute time is used to encrypt/decrypt and not inspect. F5’s BIG-IP SSL Orchestrator offers a solution to optimize resource utilization, remove latency, and add resilience to the security inspection infrastructure. F5 SSL Orchestrator ensures encrypted traffic can be decrypted, inspected by security controls, then re-encrypted—delivering enhanced visibility to mitigate threats traversing the network. As a result, you can maximize your security services investment for malware, data loss prevention (DLP), ransomware, and next-generation firewalls (NGFW), thereby preventing inbound and outbound threats, including exploitation, callback, and data exfiltration. The SSL Orchestrator decrypts the traffic and forwards unencrypted traffic to the different security devices for inspection leveraging its optimized and hardware-accelerated SSL/TLS stack.As shown below the BIG-IP SSL Orchestrator classifies traffic and selectively decrypts traffic.It then forwards it to the appropriate security functions for inspection.Finally, once duly inspected the traffic is encrypted and sent on its way to the resource the client is accessing. Deploying F5 and inline security tools together has the following benefits: Traffic Distribution for load sharing Improve the scalability of inline security by distributing the traffic across multiple Security appliances, allowing them to share the load and inspect more traffic. Agile Deployment Add, remove, and/or upgrade Security appliances without disrupting network traffic; converting Security appliances from out-of-band monitoring to inline inspection on the fly without rewiring. Customer Use Case This document focuses on the implementation of BIG-IP SSL Orchestrator to process SSL/TLS encrypted traffic and forward it to a security inspection/enforcement devices. The decryption and forwarding behavior are determined by the security policy. This ensures that only targeted traffic is decrypted in compliance with corporate and regulator policy, data privacy requirements, and other relevant factors. The configuration supports encrypted traffic that originates from within the data center or the corporate network.It also supports traffic originating from clients outside of the security perimeter accessing resources inside the corporate network or demilitarized zone (DMZ) as depicted below. The decrypted traffic transits through different inspection devices for inbound and outbound traffic. As an example, inbound traffic is decrypted and processed by F5’s Advanced Web Application Firewall (F5 Advanced WAF) as shown below. *Can be encrypted or cleartext as needed As an example, outbound traffic is decrypted and sent to a next generation firewall (NGFW) for inspection as shown in the diagram below. The BIG-IP SSL Orchestrator solution offers 5 different configuration templates. The following topologies are discussed in Network Insertion Use Cases. L2 Outbound L2 Inbound L3 Outbound L3 Inbound L3 Explicit Proxy Existing Application In the use case described herein, the BIG-IP is inserted as layer 3 (L3) network device and is configured with an L3 Outbound Topology. Architecture & Network Topology The assumption is that, prior to the insertion of BIG-IP SSL Orchestrator into the network (in a brownfield environment), the network looks like the one depicted below.It is understood that actual networks will vary, that IP addressing, L2 and L3 connectivity will differ, however, this is deemed to be a representative setup. Note: All IP addressing in this document is provided as examples only.Private IP addressing (RFC 1918) is used as in most corporate environments. Note: the management network is not depicted in the picture above.Further discussion about management and visibility is the subject of Centralized Management below. The following is a description of the different reference points shown in the diagram above. a.This is the connection of the border routers that connect to the internet and other WAN and private links. Typically, private IP addressing space is used from the border routers to the firewalls. b.The border switching connects to the corporate/infrastructure firewall.Resilience is built into this switching layer by implementing 2 link aggregates (LAG or Port Channel ®). c.The “demilitarized zone”(DMZ) switches are connected to the firewall.The DMZ network hosts application that are accessible from untrusted networks such as the Internet. d.Application server connect into the DMZ switch fabric. e.Firewalls connect into the switch fabric.Typically core and distribution infrastructure switching will provide L2 and L3 switching to the enterprise (in some case there may be additional L3 routing for larger enterprises/entities that require dynamic routing and other advanced L3 services. f.The connection between the core and distribution layers are represented by a bus on the figure above because the actual connection schema is too intricate to picture.The writer has taken the liberty of drawing a simplified representation.Switches actually interconnect with a mixture of link aggregation and provide differentiated switching using virtualization (e.g. VLAN tagging, 802.1q), and possibly further frame/packet encapsulation (e.g. QinQ, VxLAN). g.The core and distribution switching are used to create 2 broadcast domains. One is the client network, and the other is the internal application network. h.The internal applications are connected to their own subnet. The BIG-IP SSL Orchestrator solution is implemented as depicted below. In the diagram above, new network connections are depicted in orange (vs. blue for existing connections).Similarly to the diagram showing the original network, the switching for the DMZ is depicted using a bus representation to keep the diagram simple. The following discusses the different reference points in the diagram above: a.The BIG-IP SSL Orchestrator is connected to the core switching infrastructure A new VLAN and network are created on the core switching infrastructure to connect to the firewalls (North) to the BIG-IP SSL Orchestrator devices. b.The client network (South) is connected to the BIG-IP via a second VLAN and network. c.The SSL Orchestrator devices are connected to a newly created inspection network.This network is kept separate from the rest of the infrastructure as client traffic transits through the inspection devices unencrypted.As an example, Web Application Firewalls (BIG-IP ASM) are used to filter inbound traffic. d. The LAN configuration for the connection to the BIG-IP ASM is as depicted below. e. The NGFW is connected to the INSPECTION switching network in such a manner that traffic traverses it when the BIG-IP SSL Orchestrator is configured to push traffic for inspection. Summary This article should be a good starting point for planning your initial SSL Orchestrator deployment. We covered the solution overview and use cases. The network topology and architecture was explained with the help of diagrams. Next Steps Click Next to proceed to the next article in the seriesIntegrating SSL Orchestrator with McAfee Web Gateway-Transparent Proxy
Introduction SSL Orchestrator centralizes & manages decryption of SSL/TLS traffic. This enables security and monitoring tools to view the decrypted content and analyze it for threats and other anomalies. SSL Orchestrator removes the burden of decrypting content from your security tools so they perform better and are more scalable. An integrated F5 and McAfee Web Gateway solution eliminates the blind spots introduced by SSL/TLS encrypted content. Versions Tested This article assumes you have SSL Orchestrator configured with a Topology and Service Chain F5 BIG-IP version 17.1 SSL Orchestrator version 11.0 McAfee Web Gateway version 11.2 McAfee Web Gateway will be configured as a Transparent Proxy Additional Help If setting up SSL Orchestrator for the first time refer to theF5 SSL Orchestrator Deployment Guides For information on SSL Certificate considerations and trust, refer to Implementing SSL Orchestrator - Certificate Consid... - DevCentral McAfee Web Gateway (MWG) Configuration Configure the Transparent Web Proxy as follows and click the plus sign under Port Redirects Set the Destination proxy port to 80 and click OK Click Save Changes Configure the Network Interfaces as follows Specify the IP address and mask to be used for eth2, 10.0.0.55 255.255.255.0 in this example. Specify the IP address and mask to be used for eth3, 10.1.1.5 255.255.255.0 in this example. The Default Gateway will be a Self IP address on SSL Orchestrator, 10.1.1.1 in this example. BIG-IP SSL Orchestrator Configuration The BIG-IP VLAN settings should look like the following 10.0.0.0 is the interface used for Transparent Proxy connections to the MWG 10.1.1.0 is the interface used for Transparent Proxy connections to SSL Orchestrator North_vlan is used for network connectivity from the BIG-IP to the North South_vlan is used for network connectivity from the BIG-IP to the South The BIG-IP Self IPs setting should look like the following 10.0.0.1 will be used for Transparent Proxy connections to the McAfee Web Gateway 10.1.1.1 will be used for Transparent Proxy connections from the McAfee Web Gateway Note: in this example SSL Orchestrator is deployed with an L3 Outbound Topology. That’s what the other two Self IPs are for. Your configuration will look different if using an L2 Topology. This article assumes you have SSL Orchestrator configured with a Topology and Service Chain. Navigate to SSL Orchestrator > Configuration Create the McAfee Web Gateway Service Under Services, click Add. In the Service Catalog select the Inline HTTP tab then double click on McAfee Web Gateway HTTP Proxy. Give it a name, MWG in this example. Under Service Definition unselect the option to Auto Manage Addresses. Set the Proxy Type to Transparent For the To Service VLAN select 10.0.0.1 (VLAN 10.0.0.0). Click Add for HTTP Proxy Devices. Enter the MWG IP address, 10.0.0.55 in this example. Click Done. For the From Service VLAN select 10.1.1.1 (VLAN 10.1.1.0) Enable Port Remap. Set the Remap Port to 80. Set Manage SNAT Settings to Auto Map Click Save & Next at the bottom. Click the name of the Service Chain. Select the MWG Service from the left and click the arrow to move it to the right. Click Save. Click OK Click Save & Next at the bottom. Click Deploy Click OK to the Success message. When done it should look like the following: From the Services screen if you expand the Pool Member Status you should see the McAfee Web Gateway Testing the Configuration In this example there is a Windows client that connects through the SSL Orchestrator to a Windows server running the following web site: https://10.4.11.52 Test this connection now and it should look like the following: In this example the MWG is configured with a Custom Category to block connections to http://10.4.11.99. When attempting to connect to this site with a web browser you should see a block page like the following: Conclusion This completes configuration of BIG-IP SSL Orchestrator with McAfee Web Gateway. At this point traffic that flows through SSL Orchestrator will be decrypted and sent to the MWG Service and inspected for malicious payloads or policy violations. Related Articles Integrating SSL Orchestrator with McAfee Web Gateway-Explicit Proxy Verified Design SSL Orchestrator with McAfee Web Gateway (Part 1) Verified Design SSL Orchestrator with McAfee Web Gateway (Part 2)Verified Design: SSL Orchestrator with Palo Alto NGFW Virtual Edition-Part 1
Summary This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability and the protection of critical assets using Virtual Palo Alto NGFW. It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working. If you need help setting up SSL Orchestrator for the first time, refer to the Dev/Central article series on Implementing SSL Orchestrator here or the CloudDocs Deployment Guide here. This article focuses on using SSL Orchestrator as a tool to assist with simplifying Change Management processes, procedures and shortening the duration of the entire process. Configuration files of Palo Alto NGFW can be downloaded fromherefrom GitLab. Please forgive me for using SSL and TLS interchangeably in this article. This article is divided into the following high level sections: Part 1(available here) Palo Alto NGFW Virtual Machine configuration Create a new Topology to perform testing Monitor Palo Alto statistics – change the weight ratio – check Palo Alto stats again Remove a single Palo Alto VM from the Service Part 2 (available here) Perform maintenance on the Palo Alto VM Add the Palo Alto VM to the new Topology Test functionality with a single client Add the Palo Alto VM back to the original Topology Test functionality again Repeat to perform maintenance on the other Palo Alto VM Palo Alto Virtual Machine configuration If you haven’t already configured the Palo Alto Virtual Machines there are a few things to be aware of. For the ESX Network configuration you will need 4 interfaces at a minimum. The configuration should look something like this: The corresponding Palo Alto network settings should look something like the image below. Click the name (ethernet1/X) of the interface you wish to configure. Set the Interface Type to Virtual Wire and the Security Zone to trust. Click OK. Do the same for the next interface. Click the name of one of the interfaces configured previously. Click Virtual Wire > New Virtual Wire. Give it a name. Select the 2 interfaces configured previously. Click OK and OK. You will need to Commit the changes for them to take effect. Note: setting the Security Zone to trust is needed for the F5 Health Monitors to work. Repeat these steps if configuring SSL Orchestrator deployed with High Availability. Create a new Topology to perform testing A new Topology will be used to safely test the Service after maintenance is performed. The Topology should be similar to the one used for production traffic. This Topology can be re-used in the future. From the BIG-IP Configuration Utility select SSL Orchestrator > Configuration. Click Add under Topologies. Scroll to the bottom of the next screen and click Next. Give it a name, Topology_Staging in this example. Select L2 Inbound as the Topology type then click Save & Next. For the SSL Configurations you can leave the default settings. Click Save & Next at the bottom. Click Save & Next at the bottom of the Services List. Click the Add button under Services Chain List. A new Service Chain is needed so we can remove PaloAlto1 from the Production Service and add it here. Give the Service Chain a name, Staging_Chain in this example. Click Save at the bottom. Note: The Service will be added to this Service Chain later. Click Save & Next. Click the Add button on the right to add a new rule. For Conditions select Client IP Subnet Match. Enter the Client IP and mask, 10.1.11.52/32 in this example. Click New to add the IP/Subnet. Set the SSL Proxy Action to Intercept. Set the Service Chain to the one created previously. Click OK. Note: This rule is written so that a single client computer (10.1.11.52) will match and can be used for testing. In the All Traffic default rule set the SSL Proxy Action to Bypass. Select Save & Next at the bottom. For the Interception Rule set the Source Address to 10.1.11.52/32. Set the Destination Address/Mask to 10.4.11.0/24. Set the port to 443. Select the VLAN for your Ingress Network and move it to Selected. Set the L7 Profile to Common/http. Click Save & Next. For Log Settings, scroll to the bottom and select Save & Next. Click Deploy. Monitor Palo Alto statistics – change the weight ratio – check Palo Alto statistics again Check the statistics on the Palo Alto NGFW we will be performing maintenance on. It’s “Palo_Alto1” in this example. From the Palo Alto GUI select ACC (Application Command Center). Select Network Activity then Sessions. A time filter can be set on the left, in this case it’s set to the Last Hour. Palo_Alto1 appears to be completely healthy. Change the Weight Ratio Back to the SSL Orchestrator Configuration Utility. Click SSL Orchestrator > Configuration > Services > then the Service name, ssloS_PALOALTO in this example. Click the pencil icon to edit the Service. Click the pencil icon to edit the Network Configuration for PaloAlto2 Set the ratio to 65535 and click Done. Note: Alternately you could disable the Pool Member from LTM > Pools. Click Save & Next at the bottom. Click OK if presented with the following warning. Click Deploy. Click OK when presented with the Success message. Check Palo Alto Statistics Again Check the ACC statistics on “Palo_Alto1”. It should look like the image below, with the number of sessions tapering off until there is zero. Remove a single Palo Alto VM from the Service Back to the SSL Orchestrator Configuration Utility. Click SSL Orchestrator > Configuration > Services > then the Service name, ssloS_PALOALTO in this example. Click the pencil icon to edit the Service. Under Network Configuration, delete Palo1. Click Save & Next at the bottom. Click OK if presented with the following warning. Click Deploy. Click OK when presented with the Success message. Proceed to Part 2Implementing SSL Orchestrator - Certificate Considerations
Introduction This article is part of a series on implementing BIG-IP SSL Orchestrator. It includes high availability and central management with BIG-IQ. Implementing SSL/TLS Decryption is not a trivial task. There are many factors to keep in mind and account for, from the network topology and insertion point, to SSL/TLS keyrings, certificates, ciphersuites and on and on. This article focuses on SSL certificates and everything you need to know about them. This article is divided into the following high level sections: Using OpenSSL Using Microsoft CA Importing a private key and certificate into SSL Orchestrator Manually Installing Certificates in browsers Creating a Certificate Signing Request (CSR) for Inbound Topology Using Group Policy Objects (GPO) to distribute certificates Please forgive me for using SSL and TLS interchangeably in this article. Software versions used in this article: BIG-IP Version: 14.1.2 SSL Orchestrator Version: 5.5 BIG-IQ Version: 7.0.1 Using OpenSSL OpenSSL can be used to sign a CSR.It can also be used to generate a self-signed certificate.When creating a CSR for production, you might need to use OpenSSL with a template in order to populate certain fields like the Digital Signature. This information is provided as a courtesy. OpenSSL contains an open-source implementation of the SSL and TLS protocols. The core library, written in the C programming language, implements basic cryptographic functions and provides various utility functions. Wrappers allowing the use of the OpenSSL library in a variety of computer languages are available. OpenSSL can be used to create private keys, certificates and more.Here’s an example of the syntax used to create a self-signed certificate: openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt Full instructions about how to use OpenSSL are beyond the scope of this article.However, the links below contain excellent information on usage: OpenSSL - Command Line Utilities SSLShopper- Common OpenSSL Commands Note: If you want to create your own OpenSSL Certificate Authority the following Dev/Central Article is excellent: Building an OpenSSL Certificate Authority - Creating Your Root Certificate Using Microsoft Certificate Authority This method is generally preferred to using self-signed certificates. Rather than reinvent the wheel, the Virtually There Blog does an excellent job of explaining the process to sign a CSR with a local Certificate Authority.Click the link below to learn more: VirtuallyThere - Signing a CSR with your Microsoft Certificate Authority Note: If you’re looking for information about how to setup your own local Microsoft CA see this previous blog: VirtuallyThere - Building a Microsoft Certificate Authority for your lab Note: the blog author has given f5 permission to include the links above. Installing signed certificate into SSL Orchestrator From the Configuration Utility > SSL Orchestrator > Certificate Management > Traffic Certificate Management.Click on the certificate created earlier (my_certificate). Click Import. Click Choose File and select the signed certificate from the CA.Click OK/Open.Click Import. Note: Using Certificate Chains or Subordinate CAs If using Certificate Chains be sure to include all intermediate certificates in the chain.For more information on Certificate Chains, see this Microsoft article. Import private key and certificate into SSL Orchestrator Follow the steps below if you already have the private key and certificate you want to use for SSL decryption. From the BIG-IP Configuration Utility click SSL Orchestrator > Certificate Management > Certificates and Keys.On the far right, click Import. For Import Type click Select.Different types of import options are available. For this example, select Key.Give it a name, in this example SSL.key.You can upload the key from a local file or paste it in as text.Choose the method you prefer and click Import when done.The example below shows the local file method. Click the name of the Key you created. Click Import.You can upload the certificate from a local file or paste it in as text.Choose the method you prefer and click Import when done.The example below shows the local file method. You have successfully imported the private key and certificate. Note: most Enterprise customers will have their own local Certificate Authority (CA). Creating a Certificate Signing Request (CSR) for Inbound Topology If you are creating an Inbound Topology you can use this method to create a CSR. From the F5 Configuration Utility go to SSL Orchestrator > Certificate Management > Certificates and Keys.Click Create on the top right. Give the certificate a name.For Issuer select Certificate Authority.Fill in the rest of the form. Click Finished when done. The page should look like the following.Click Download my_certificate to download it as a file.You can optionally copy the text output to the Clipboard. Download the CSR so it can be signed by your Local Certificate Authority. Manually Installing Certificates in browsers Certificates generated by SSL Orchestrator need to be trusted by the client computers. If using a Microsoft Certificate Authority (CA) to sign the SSL certificates the clients will trust it automatically, assuming they are members of the same domain as the CA. If using Self-Signed certificates you need to install them in the Certificate store on all client computers. Most Enterprise customers won't do this in production but it's often used for testing or demos. Either way, it's important to know these procedures. Firefox has its own Certificate store.Click the icon on the top right then Preferences. Note: Firefox version 70.0.1 was used in the configuration below. Scroll to the bottom of the next screen.Under Security click View Certificates. Click Import. Find the Certificate on your computer.Select it and click Open. Select the option to Trust this CA to identify websites.Click OK. Internet Explorer/Edge and Chrome use the Windows Certificate store. Locate the Certificate on your computer and double click it.Click Install Certificate. Click Next at the Import Wizard. Select the option to Place all certificates in the following store.Click Browse. Select Trusted Root Certification Authorities then OK. Click Next. Click Finish. You should see a Security Warning like the following.Click Yes. Click OK to the Successful Import message. Using GPO to distribute certificates Microsoft has a variety of support articles and documentation for how to do this with GPO: Distribute Certificates to Client Computers by using Group Policy Summary In this article we covered the most common tasks associated with SSL certificates and how to use them with SSL decryption. Next Steps The next article in this series will cover the Guided Configuration component of SSL Orchestrator.F5 BIG-IP SSL Orchestrator Configuration with Advanced WAFaaS
Introduction This use case allows you to insert F5 Advanced WAF functionality in SSL Orchestrator from the Service Catalog. This is a new feature in SSL Orchestrator version 11.0. Note:This article applies to SSL Orchestrator version 11.0 and newer. If using an older version refer to the article HERE Below is a video demonstration of this article: Click HERE for a Lightboard Lesson on F5 Advanced WAF. Advanced WAFaaS is the ability to insert F5 BIG-IP Advanced WAF profiles into the SSL Orchestrator Service Chain for Inbound Topologies. This service allows you to configure and deploy Advanced Web Application Firewall profiles through the SSL Orchestrator. This configuration is specific to a WAF policy running on the SSL Orchestrator device. It is also possible to deploy WAF on a separate BIG-IP device, in which case you’d simply configure an inline transparent proxy service. The ability to insert F5’s Advanced WAF into the Service Chain presents a significant customer benefit. Some examples of the benefits are: Consolidation of best-in-class advanced WAF capabilities with SSL Orchestrator’s dynamic, policy-based decrypted malware inspection and traffic steering. The Advanced WAF Service can be used for multiple SSL Orchestrator Topologies. Management of SSL Orchestrator and Advanced WAF on the same platform. Simplifies logging and troubleshooting. This guide assumes you already have SSL Orchestrator and F5 Advanced WAF licensed and provisioned on the BIG-IP and wish to add this functionality to an Inbound Topology. In order to run Advanced WAF and SSL Orchestrator on the same device you will need an Advanced Web Application Firewall (AWF) add-on license. Note: SSL Orchestrator 11.0 requires BIG-IP version 17.1.0 Configuration From the SSL Orchestrator Guided Configuration click Services then Add Select the F5 tab then double click on F5 Advanced WAF (On-Box) Give it a name, F5_AWAF in this example Click the down arrow next to Application Security Policy and select your Advanced WAF policy, Advanced-WAF-Policy in this example The Advanced WAF Policy protects your web applications from application attacks like SQL injection, cross-site scripting and a variety of other malicious attacks. You can also specify a DoS Protection and Bot Defense Profile. A DoS Protection profile will also protect your web applications from Denial of Service attacks. A Bot Defense Profile will protect your web applications from malicious bot attacks Select a Log Profile if desired. The logging of connections is important for visibility and forensics. Click Save & Next at the bottom Click Save & Next at the bottom Click Deploy Click OK to the Success message Add the Advanced WAF Service to the Service Chain by clicking the Service Chains tab then click on the name of the Service Chain, Service_Chain in this example Move the F5_WAF Service from Available to Selected Click Deploy when done If presented with the following warning, click OK Click OK to the Success message When done it should look like the following The configuration is now complete. Using the F5 Advanced WAFaaS this way is functionally the same as using it by itself. There are no known limitations to this configuration. Additional Information For more information on configuration of SSL Orchestrator refer to the Deployment Guides HERE Exporting/Importing WAFaaS policy To export an existing Advanced WAF policy navigate to Security > Application Security > click the name of the policy you wish to export Click Export then choose one of the supported formats like XML To import the Advanced WAF policy click Create > Import from the Policies List screen Example of Advanced WAF Policy creation A demo video of Advanced WAF Policy creation is available HERE Example of Advanced WAF Protection in action SQL Injection is a common web application attack that should be blocked by the Advanced WAF policy. Here is what a typical SQL Injection attack might look like as an HTTPS request: https://10.1.20.200/rest/products/search?q=qwert%27%29%29%20UNION%20SELECT%20id%2C%20email%2C%20password%2C%20%274%27%2C%20%275%27%2C%20%276%27%2C%20%277%27%2C%20%278%27%2C%20%279%27%20FROM%20Users-- This request should be blocked and the response will look like this: Here is an example of what the Log File should contain: Note: Both Advanced WAF and SSL Orchestrator are CPU-driven functions. This will need to be factored into capacity planning when deploying the two together.
Verified Design: SSL Orchestrator with McAfee Web Gateway-Part 1
Summary This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability and the protection of critical assets using McAfee Web Gateway. It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working. If you need help setting up SSL Orchestrator for the first time, refer to the Dev/Central article series on Implementing SSL Orchestrator here or the CloudDocs Deployment Guide here. This article focuses on using SSL Orchestrator as a tool to assist with simplifying Change Management processes, procedures and shortening the duration of the entire process. Configuration files of McAfee Web Gateway can be downloaded fromherefrom GitLab. Please forgive me for using SSL and TLS interchangeably in this article. A video demo of this Dev/Central article is available HERE This article is divided into the following high level sections: Part1(Available here) Configure McAfee Web Gateway (MWG) interfaces Create a new Topology to perform testing Monitor McAfee Web Gateway statistics – change the weight ratio – check McAfee Web Gateway stats again Remove a single McAfee Web Gateway device from the Service Part 2(Available here) Perform maintenance on the McAfee Web Gateway device Add the McAfee Web Gateway device to the new Topology Test functionality with a single client Add the McAfee Web Gateway device back to the original Topology Test functionality again Repeat to perform maintenance on the other McAfee Web Gateway device Configure McAfee Web Gateway (MWG) interfaces From the MWG UI navigate to Configuration > Appliances > Proxies. Under Network Setup select Transparent bridge. Click Save Changes on the top right Navigate to Network interfaces. In this example eth2 and eth3 will be used to create the Transparent bridge. Both interfaces need to be enabled and the IP settings must be disabled for IPv4 and IPv6. On the Advanced tab enable the bridge and give it a name, ibr0 in this example. Do this for both interfaces. Save changes Check ibr0 and set it to enabled. Disable IPv4 and IPv6 Click Save Changes Note: complete these steps on the 2 nd McAfee Web Gateway Note: when configuring for High Availability you will need to create a 2 nd Transparent bridge Please contact McAfee for assistance if needed Create a new Topology to perform testing A new Topology will be used to safely test the Service after maintenance is performed. The Topology should be similar to the one used for production traffic. This Topology can be re-used in the future. From the BIG-IP Configuration Utility select SSL Orchestrator > Configuration. Click Add under Topologies. Scroll to the bottom of the next screen and click Next. Give it a name, Topology_Staging in this example. Select L2 Outbound as the Topology type then click Save & Next. For the SSL Configurations you can leave the default settings. Click Save & Next at the bottom. Click Save & Next at the bottom of the Services List. Click the Add button under Services Chain List. A new Service Chain is needed so we can remove McAfee Web Gateway from the Production Service and add it here. Give the Service Chain a name, Staging_Chain in this example. Click Save at the bottom. Note: The Service will be added to this Service Chain later. Click Save & Next Click the Add button on the right to add a new rule. For Conditions select Client IP Subnet Match. Enter the Client IP and mask, 10.5.9.51/32 in this example. Click New to add the IP/Subnet. Set the SSL Proxy Action to Intercept. Set the Service Chain to the one created previously. Click OK. Note: This rule is written so that a single client computer (10.5.9.51) will match and can be used for testing. In the All Traffic default rule set the SSL Proxy Action to Bypass. Select Save & Next at the bottom. For the Interception Rule set the Source Address to 10.5.9.51/32. Set the Destination Address/Mask to 10.4.11.0/24. Set the port to 443. Select the VLAN for your Ingress Network and move it to Selected. Set the L7 Profile to Common/http. Click Save & Next. For Log Settings, scroll to the bottom and select Save & Next. Click Deploy. Monitor McAfee Web Gateway statistics – change the weight ratio – check McAfee Web Gateway statistics again Check the statistics on the McAfee Web Gateway device we will be performing maintenance on. It’s “MWG1” in this example. One way to do this is with a packet trace. From the McAfee Web Gateway UI go to Troubleshooting > Packet tracing. I set the Command line parameters to “-I ibr0” which will capture all packets on the bridge interface. Note: This McAfee Web Gateway device is actively processing connections. Note the connections are in clear text, HTTP on port 80. SSL Orchestrator decrypted the SSL/TLS and sent it to the McAfee device for inspection. Change the Weight Ratio Back to the SSL Orchestrator Configuration Utility. Click SSL Orchestrator > Configuration > Services > then the Service name, ssloS_McAfeeWebGateway in this example. Click the pencil icon to edit the Service. Click the pencil icon to edit the Network Configuration for MWG2 Set the ratio to 65535 and click Done. Click Save & Next at the bottom. Click OK if presented with the following warning. Click Deploy. Click OK when presented with the Success message. Check McAfee Web Gateway Statistics Again Check the statistics on the McAfee Web Gateway device again. It’s “MWG1” in this example. From the McAfee Web Gateway UI go to Troubleshooting > Packet tracing. I set the Command line parameters to “-I ibr0” which will capture all packets on the bridge interface. It should look like the following: Note: The connections above represent the health checks from SSL Orchestrator to the inline Service. Therefore, this McAfee Web Gateway is not actively processing connections. Remove a single McAfee Web Gateway device from the Service Back to the SSL Orchestrator Configuration Utility. Click SSL Orchestrator > Configuration > Services > then the Service name, ssloS_McAfeeWebGateway in this example. Click the pencil icon to edit the Service. Under Network Configuration, delete MWG1. Click Save & Next at the bottom. Click OK if presented with the following warning. Click Deploy. Click OK when presented with the Success message. Click HERE for Part 2 of the article Related Articles Integrating SSL Orchestrator with McAfee Web Gateway-Explicit ProxyOrchestrated Infrastructure Security - Advanced WAF
The F5 Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latesthere. Introduction This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability, Central Management with BIG-IQ, Application Visibility with Beacon and the protection of critical assets using F5 Advanced WAF and Protocol Inspection (IPS) with AFM.It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working. If you need help setting up SSL Orchestrator for the first time, refer to the Dev/Central article series Implementing SSL Orchestrator here. This article focuses on configuring F5 Advanced WAF deployed as a Layer 2 solution. It covers the configuration of Advanced WAF protection on an F5 BIG-IP running version 16.0.0. Configuration files of BIG-IP deployed as Advanced WAF can be downloaded from here from GitLab. Please forgive me for using SSL and TLS interchangeably in this article. This article is divided into the following high level sections: Advanced WAF Network Configuration Attach Virtual Servers to an Advanced WAF Policy Advanced WAF: Network Configuration The BIG-IP will be deployed with VLAN Groups.This combines 2 interfaces to act as an L2 bridge where data flows into one interface and is passed out the other interface. Vwire configuration will be covered later. From the F5 Configuration Utility go to Network > VLANs.Click Create on the right. Give it a name, ingress1 in this example.Set the Interface to 2.1.Set Tagging to Untagged then click Add. Note: In this example interface 2.1 will receive decrypted traffic from sslo1 Interface 2.1 (untagged) should be visible like in the image below.Click Repeat at the bottom to create another VLAN. Give it a name, egress1 in this example.Set the Interface to 2.2.Set Tagging to Untagged then click Add. Note: In this example interface 2.2 will send decrypted traffic back to sslo1 Interface 2.2 (untagged) should be visible like in the image below.Click Finished. Note: This guide assumes you are setting up a redundant pair of SSL Orchestrators.Therefore, you should repeat these steps to configure VLANs for the two interfaces connected to sslo2.These VLANs should be named in a way that you can differentiate them from the others.Example: ingress2 and egress2 It should look something like this when done: Note: In this example Interface 2.3 and 2.4 are physically connected to sslo2. Click VLAN Groups then Create on the right. Give it a name, vlg1 in this example.Move ingress1 and egress1 from Available to Members.Set the Transparency Mode to Transparent.Check the box to Bridge All Traffic then click Finished. Note: This guide assumes you are setting up a redundant pair of SSL Orchestrators.Therefore, you should repeat these steps to configure a VLAN Group for the two interfaces connected to sslo2.This VLAN Group should be named in a way that you can differentiate it from the other, example: vlg1 and vlg2.It should look like the image below: For full Layer 2 transparency the following CLI option needs to be enabled: (tmos)# modify sys db connection.vgl2transparent value enable Attach Virtual Servers to an Advanced WAF Policy You can skip this step if you already have an Advanced WAF policy created and attached to one or more virtual servers.If not, we’ll cover it briefly.In this example we configured Comprehensive Protection which includes Bot Mitigation, Layer 7 DoS and Application Security. Give it a name, App_Protect1 in this example then click Save & Next. Select the Enforcement Mode and Policy Type.Click Save & Next. Configure the desired Bot Defense options.Click Save & Next on the lower right. Configure the desired DoS Profile Properties.Click Save & Next. Assign the policy to your application server(s) by moving them to Selected.Click Save & Next. Click Finish/Deploy when done. Summary In this article you learned how to configure BIG-IP in layer 2 transparency mode using VLAN groups.We also covered how to create an Advanced WAF policy and attach it to your Virtual Servers. Next Steps Click Next to proceed to the next article in the series.Implementing SSL Orchestrator - Guided Configuration
Introduction This article is part of a series on implementing BIG-IP SSL Orchestrator. It includes high availability and central management with BIG-IQ. Implementing SSL/TLS Decryption is not a trivial task. There are many factors to keep in mind and account for, from the network topology and insertion point, to SSL/TLS keyrings, certificates, ciphersuites and on and on. This article focuses on the SSL Orchestrator Guided Configuration and everything you need to know about it. This article is divided into the following high level sections: Configuration prerequisites Deployment Topology SSL certificate and key settings Service properties Security policy Interception rule Please forgive me for using SSL and TLS interchangeably in this article. Software versions used in this article: BIG-IP Version: 14.1.2 SSL Orchestrator Version: 5.5 BIG-IQ Version: 7.0.1 Configuration Prerequisites From the BIG-IP Configuration Utility click SSL Orchestrator > Configuration.This is the default landing page when SSL Orchestrator is not configured.The configuration options are presented on this page.Notice the Required Configuration settings on the top right.For DNS click the link to configure. Enter the IP address of the DNS server you wish to use and click Add.You can add multiple DNS servers.Click Update when done. Click SSL Orchestrator > Configuration.For NTP click the link to configure. Enter the IP address or hostname of the NTP server you wish to use and click Add.You can add multiple NTP servers.Click Update when done. Click SSL Orchestrator > Configuration.For Route click the link to configure. Name it.In this example it’s default_route.Enter the correct Destination and Netmask.In this example we’re using 0.0.0.0 as this is a default route.Enter the Gateway IP Address, in this example 10.0.0.1. Click Finished. Click SSL Orchestrator > Configuration.The Required Configuration section should look like the following. Deployment Topology We are now ready to begin the Guided Configuration.Click Next at the bottom. Choose the Topology you would like to deploy.In this example we will configure an L3 Outbound Topology. Name the Topology.For the Protocol choose Any.Select L3 Outbound then click Save & Next Note: some of the available Topologies might be greyed out if not supported by your platform.As an example, virtual machines don’t support L2. SSL Certificate and Key Settings Leave the Certificate Key Chain settings to their defaults. Edit the existing CA Certificate Key Chain by clicking the pencil icon. In a previous article you installed your own private key and certificate.Click the down arrow on the right to select that Certificate and Key.Click Done. Click Save & Next Notes: The difference between the Cert Key Chain and the CA Cert Key Chain: Certificate Key Chain – the certificate key chain represents the certificate and private key used as the “template” for forged server certificates. While re-issuing server certificates on-the-fly is generally easy, private key creation tends to be a CPU-intensive operation. For that reason, the underlying SSL Forward Proxy engine forges server certificates from a single defined private key. This setting gives customers the opportunity to apply their own template private key, and optionally store that key in a FIPS-certified HSM for additional protection. The built-in “default” certificate and private key uses 2K RSA and is generated from scratch when the BIG-IP system is installed. The pre-defined default.crt and default.key can be left as is. CA Certificate Key Chain – an SSL forward proxy must re-sign, or “forge” remote server certificate to local clients using a local certificate authority (CA) certificate, and local clients must trust this local CA. This setting defines the local CA certificate and private key used to perform the forging operation. Service Properties Click Add Service You can choose from many pre-defined templates from different security vendors.In this example select Palo Alto Networks NGFW Inline Layer 2 then click Add. Give it a name.Under Network Configuration click Add. Here you define the VLANS that the Palo Alto is connected to (or will be connected to).You can use existing ones or create new VLANS.We will create new ones by choosing the Create New radio button. Give each VLAN a unique name to help remember which device it’s connected to and in which direction data flows.Select the Interface from the drop-down menu.Click Done. Enable the Port Remap option and leave the port at 80. Click Save Notes: SSL Orchestrator allows for the insertion of additional iRule logic at different points. An iRule defined at the service only affects traffic flowing across this service. It is important to understand, however, that these iRules must not be used to control traffic flow (ex. pools, nodes, virtuals, etc.), but rather should be used to view/modify application layer protocol traffic. For example, an iRule assigned here could be used to view and modify HTTP traffic flowing to/from the service. Click Save & Next Click the button to Add a Service Chain List Give it a name.Click the arrow in the middle to move the Palo Alto Service to the Selected side.Click Save. Note: When you have multiple Services in a Service Chain you can adjust the order that they are used. Your screen should like the following.Click Save & Next. Security Policy The Security Policy is next.Notice you have the option to create new or use an existing one.By default, the policy should look like this. The Name is populated automatically but can be changed.If you click the pencil icon to the far right of the Pinners_Rule you can see the contents of the rule. The Pinners_Rule checks to make sure the content is SSL/TLS.It also checks the category “Pinners” which contains websites with Pinned Certificates.Sites in the category Pinners are automatically set to Bypass decryption.It is recommended to keep this setting. Notes: If you have a URL categorization database you can also bypass decryption based on website category. Conditions can be toggled between Match Any and Match All.Actions can be to Allow or Reject.Also note the Service Chain is bypassed by default.However, you can choose to send the encrypted content through the Security Chain. Click Cancel. The Pinners Category can be viewed/edited from SSL Orchestrator > Policies > URL Categories.Expand Custom Categories and you will see the Pinners category.Click Pinners (custom) to view and/or edit the sites. Back to the Security Policy.Click the pencil icon to the far right of the All Traffic rule to edit it. Set the Service Chain to the one created previously, in this case it’s ssloSC_SecurityServiceChain.Click OK. Click Save & Next at the bottom. Interception Rule Next is the Interception Rule.For Ingress Network select the VLAN that internal clients connect through.In this example select INTERNAL and click the arrow to move it to Selected.Note that you can also create VLANS from this screen. Click Save & Next at the bottom. Notes:L7 Interception Rules – FTP and email protocol traffic are all “server-speaks-first” protocols, and therefore SSL Orchestrator must process these separately from typical client-speaks-first protocols like HTTP. This selection enables processing of each of these protocols, which create separate port-based listeners for each. As required, selectively enable the additional protocols that need to be decrypted and inspected through SSL Orchestrator. Egress Settings For the Egress Settings Click Save & Next at the bottom. Last is the Summary screen.You can review and edit any of the Configurations we just went through.Click Deploy when done.The next screen should look like the image below. Click OK and you should see something like the following: Notes: The Palo Alto Service is shown as DOWN in red.This is because we haven’t configured it yet.We’ll do that in the next article. Summary In this article you learned how to use the SSL Orchestrator Guided Configuration to do the following: Configuration prerequisites Deployment Topology SSL certificate and key settings Service properties Security policy Interception rule Next Steps Click Next to proceed to the next article in the series.Integrating SSL Orchestrator with CheckPoint Firewall VM-Explicit Proxy
Introduction SSL Orchestrator centralizes & manages decryption of SSL/TLS traffic. This enables security and monitoring tools to view the decrypted content and analyze it for threats and other anomalies. SSL Orchestrator removes the burden of decrypting content from your security tools so they perform better and are more scalable. An integrated F5 and CheckPoint Firewall solution eliminates the blind spots introduced by SSL/TLS encrypted content. Versions Tested This article assumes you have SSL Orchestrator configured with a Topology and Service Chain F5 BIG-IP version 17.1 SSL Orchestrator version 11.0 CheckPoint Gaia R81.20 CheckPoint SmartConsole version 81.20.9700.641 CheckPoint Firewall will be configured as an Explicit Proxy Additional Help If setting up SSL Orchestrator for the first time refer to the Deployment Guide availableHERE For information on SSL Certificate considerations and trust, click HERE Video demo VMware ESX Configuration Create the following 3 Port Groups: Network-North Network-South New-CheckPoint-Egress Attach them to a vSwitch, CheckPoint-Switch in this example: Configure the BIG-IP virtual network settings as follows: NOTE: VM Network is used for Management Network-North is used for connectivity to the North side of the network Network-South is used for connectivity to the South side of the network New-CheckPoint-Egress is used for connections from/to the BIG-IP and the CheckPoint Firewall Configure the CheckPoint Firewall virtual network settings as follows: NOTE: VM Network is used for Management New-CheckPoint-Egress is used for connections from/to the BIG-IP and the CheckPoint Firewall CheckPoint Firewall Configuration Using a web browser connect to the GAIA Portal. Under Network Management select Network Interfaces. In this example eth1 is being used for incoming and outgoing connections from/to the BIG-IP and the CheckPoint Firewall. It has an IP address of 10.0.0.5. NOTE: eth2 is not used in this example 10.0.0.5 will need a route or default gateway that is the BIG-IP Self IP of 10.0.0.1 (to be configured later). This example uses a closed network, a Static Route is added so the CheckPoint knows where to send connections destined for 192.168.0.5 (this is the IP address of the web server we will be using to test this). Launch the Smart Console and log in. Double click on the firewall you want to configure, check-fw1 in this example. Enable the HTTP/HTTPS Proxy with the following settings. Click OK when done. Double click on check-fw1 again. Select Network Management Select Get Interfaces then choose With Topology in this example. The Topology Results should look like the following. Click Accept then OK. NOTE: Typically eth1 (10.0.0.5) should be defined as Internal. Double click on the interface name to configure this. For eth1 click Modify. Set “Leads To” to Internal. Click OK Click Publish at the top. Click Publish again Click Security Policies on the left Change the Action from Drop to Accept NOTE: This is just an example for this article. Normally you would not set a firewall policy to Any/Any/Accept Select NAT and create a new NAT rule like the following: Set the Original Source to 10.0.0.1. Set the Original Destination to 10.0.0.5. Set the Translated Source to 10.0.0.5. Set Install On to the correct CheckPoint Firewall. Click Publish then Publish again When that completes click Install Policy Click Install NOTE: in this example the policy is installed on a single firewall. Your setup may differ. At this point the CheckPoint Firewall should be configured properly with an Access Control Policy and NAT BIG-IP SSL Orchestrator Configuration The BIG-IP VLAN settings should look like the following: Egress is the VLAN used for connections from/to the BIG-IP and the CheckPoint Firewall North_vlan is used for network connectivity from the BIG-IP to the North South_vlan is used for network connectivity from the BIG-IP to the South Create the following Self IP 10.0.0.1 is used for connections from/to the BIG-IP and the CheckPoint Firewall. The VLAN is set to Egress. This article assumes you have SSL Orchestrator configured with a Topology and Service Chain. Navigate to SSL Orchestrator > Configuration. Create the CheckPoint Firewall Service Under Services, click Add. In the Service Catalog select the Inline HTTP tab then double click on Generic HTTP Service Give it a name, CheckPoint in this example. Uncheck the box to Auto Manage Addresses. Set the Proxy Type to Explicit. For the To Service VLAN select 10.0.0.1/24 For HTTP Proxy Devices click Add Enter 10.0.0.5 for the IP Address. Enter 8080 for the Port. Click Done For the From Service select 10.0.0.1/24 Set Manage SNAT Settings to Auto Map. Click Save and Next. Click the name of the Service Chain. Select the CheckPoint Service from the left and click the arrow to move it to the right. Click Save. Click OK Click Save & Next at the bottom. Click Deploy Click OK to the Success message. When done it should look like the following: From the Services screen if you expand the Pool Member Status you should see the CheckPoint Firewall Testing the Configuration In this example there is a Windows client that connects through the SSL Orchestrator to a Windows server running the following web site: https://192.168.0.5 Test this connection now and it should look like the following: We’ll use tcpdump on the BIG-IP to verify connectivity. The capture from the Network_South vlan shows the encrypted HTTPS request The capture from the Egress vlan shows plain text HTTP content being sent to the CheckPoint Firewall for Inspection NOTE: Some of the requests are identified as “webcache” due to using HTTP port 8080. Check the log file on the CheckPoint Firewall. Launch the SmartConsole and click LOGS & MONITOR. Double click on the entry highlighted below for more detail. Here we can see the connection was Accepted. We can also see the Service is http on TCP port 8080. Conclusion This completes configuration of BIG-IP SSL Orchestrator with CheckPoint Firewall. At this point traffic that flows through SSL Orchestrator will be decrypted and sent to the CheckPoint Service and inspected for malicious payloads or policy violations. Related Articles Integrating SSL Orchestrator with CheckPoint Firewall VM-Bridge Mode (L2) Integrating SSL Orchestrator with CheckPoint Firewall VM-Transparent Proxy - DevCentralAutomating SSL Orchestrator in AWS with the help of Ansible and Terraform
Overview Learn how to automate the deployment of SSL Orchestrator in Amazon Web Services. This article is based on the automation templates available here: https://github.com/f5devcentral/sslo-cloud-templates This will deploy SSL Orchestrator with an L3 Inbound Topology and two L3 Services in a Service Chain. Follow the instructions here: lab-instructions-aws.md A demo video of this article is available below Steps Performed: Install the Container Environment Clone the Repository Subscribe to EC2 Instances Export your AWS Credentials Copy the Terraform variables file and update the values Deploy the Terraform configuration Build the SSL Orchestrator Topology using Ansible Deploy the Ansible Configuration Check the results Launch the development container environment Restart the container and attach to the console: Clone the Repository Subscribe to EC2 Instances From a web browser client - subscribe to the following EC2 instances: https://aws.amazon.com/marketplace/pp?sku=5e92658b-3fa7-42c1-9a9b-569f009582df https://aws.amazon.com/marketplace/pp?sku=78b1d030-4c7d-4ade-b8e6-f8dc86941303 https://aws.amazon.com/marketplace/pp?sku=a133064f-76e1-4d8a-aa3d-26ef12e6b95a Export your AWS Credentials From inside your development environment - export the AWS credentials export AWS_ACCESS_KEY_ID="your-aws-access-key-id" export AWS_SECRET_ACCESS_KEY="your-aws-secret-access-key" export AWS_SESSION_TOKEN="your-aws-session-token" Copy the Terraform variables file and update the values From the terraform-aws-sslo folder - Copy the includedterraform.tfvars.examplefile toterraform.tfvarsand update the values It should look like this: Deploy the Terraform Configuration From inside your development environment - deploy the Terraform configuration terraform init terraform validate terraform plan terraform apply -auto-approve Build the SSL Orchestrator Topology using Ansible Edit the ansible.cfg file and add the two lines at the bottom: [defaults] host_key_checking = False retry_files_enabled = False inventory = ./inventory/hosts library = ./library roles_path = ./roles collections_paths = ./collection [galaxy] server = https://old-galaxy.ansible.com cd ansible ansible-galaxy collection install f5networks.f5_modules f5networks.f5_bigip -f Deploy the Ansible Configuration Deploy an Ansible config using the variables file that was created by the accompanying Terraform. This will create an inbound layer 3 SSL Orchestrator topology. From the 'ansible' folder: cp ../terraform-aws-sslo/ansible_vars.yaml . ansible-playbook -e @ansible_vars.yaml playbooks/config-sslo-inbound-l3-complete.yaml Check the Results Login to the BIG-IP GUI and verify SSL Orchestrator has been configured and deployed Conclusion You're done! These templates and configuration files can be cusomized by you and re-used for future SSL Orchestrator deployments in AWS.
