Integrating SSL Orchestrator with Symantec ProxySG: Explicit Proxy
Introduction The Secure Sockets Layer (SSL) protocol and its successor, Transport Layer Security (TLS), are being widely adopted by organizations to secure IP communications. While SSL/TLS provides data privacy and secure communications, it also creates challenges to inspection devices in the security stack. What if attackers are hiding malware inside the encrypted traffic? An integrated F5 and Symantec/Broadcom ProxySG solution solves the SSL/TLS challenges. F5 BIG-IP SSL Orchestrator centralizes SSL/TLS inspection. The decrypted traffic is then inspected by one or more Symantec ProxySGs, which can block previously hidden threats. This solution eliminates the blind spots introduced by SSL/TLS. Prerequisites This article assumes you have SSL Orchestrator configured with a Topology and Service Chain F5 BIG-IP version 17.1 F5 SSL Orchestrator version 11.0 Symantec/Broadcom ProxySG version 7.3.1.1 Symantec/Broadcom ProxySG 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 Demo Video F5 BIG-IP SSL Orchestrator Network Configuration Create VLANS from Network > VLANs In this example: The 10.0.0.0 vlan is used for egress/ingress connectivity between BIG-IP and ProxySG The north_vlan is used for connectivity to the North of BIG-IP The south_vlan is used for connectivity to the South of BIG-IP Create Self IPs from Network > Self IPs In this example: IP address 10.0.0.1 is on the 10.0.0.0 vlan and is used for egress/ingress connectivity between BIG-IP and ProxySG IP address 192.168.0.1 is on the north_vlan and is used for connectivity to the North of BIG-IP IP address 172.16.0.1 is on the south_vlan and is used for connectivity to the South of BIG-IP NOTE: On the north_vlan there is a test client at IP address 192.168.0.5 On the south_vlan there is a test server at IP address 172.16.0.5 In this example SSL Orchestrator is deployed with an L3 Inbound Topology. That’s what the two north/south Self IPs are for. Your configuration will look different if using an L2 Topology. Symantec/Broadcom ProxySG Configuration Go to the Configuration tab of the ProxySG management console Expand Network and Select Adapters In this example we are configuring Interface 3:0 of the Bridge Group “passthru-3” IP address 10.0.0.5 is assigned to this interface Click Edit to set the IP Address Specify the IP Address to be used for this interface, 10.0.0.5 in this example Click OK when done then click Apply on the next screen Select Routing and add the correct Gateway, 10.0.0.1 (the BIG-IP Self IP) in this example Click Apply when done Expand Services and select Proxy Services Set the Explicit HTTP Service to Intercept and click Apply Create a Policy to Allow the client request As an example, expand Policy then select Policy Options Set the Default Proxy Policy to Allow Click Apply NOTE: Use the Visual Policy Manager to create a more specific, granular Allow policy Troubleshooting You may need to disable “Reflect Client IP” Do this from Proxy Settings > General BIG-IP SSL Orchestrator Configuration This article assumes you have SSL Orchestrator configured with a Topology and Service Chain. Navigate to SSL Orchestrator > Configuration. Create the Symantec ProxySG Service Under Services, click Add. In the Service Catalog select the Inline HTTP tab then double click on Symantec ProxySG HTTP Proxy Give it a name, SYMC in this example Uncheck the option to Auto Manage Addresses Set the Proxy Type to Explicit Under To Service Configuration select Use Existing then choose 10.0.0.1/24 Click Add to configure the HTTP Proxy Device Enter the IP Address, 10.0.0.5 in this example Enter the Port, 8080 in this example Click Done Under From Service Configuration select Use Existing then choose 10.0.0.1/24 Set Manage SNAT Settings to Auto Map Click Save & Next at the bottom. Click the name of the Service Chain. Select the SYMC 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 Symantec ProxySG Testing the Configuration In this example there is a Linux client that connects through the SSL Orchestrator to a Linux server running DVWA: https://172.16.0.5/ Test this connection now and it should look like the following: An Access Log (Statistics > Access Logging) running on the ProxySG should show the connection in plain-text HTTP: Active Sessions (Statistics > Active Sessions) running on the ProxySG should show the connection in plain-text HTTP: Conclusion This completes configuration of BIG-IP SSL Orchestrator with Symantec ProxySG Explicit Proxy. At this point traffic that flows through SSL Orchestrator will be decrypted and sent to the Symantec ProxySG Service and inspected for malicious payloads or policy violations. Related Articles Integrating SSL Orchestrator with Symantec ProxySG: Transparent Proxy
Verified Design: SSL Orchestrator with McAfee Web Gateway-Part 2
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 Perform maintenance on the McAfee Web Gateway device At this point MWG1 has been removed from the Production_Topology and is no longer handling production traffic. MWG2 is now handling all of the production traffic. We can now perform a variety of maintenance tasks on MWG1 without disrupting production traffic. When done with the task(s) we can then safely test/verify the health of MWG1 prior to moving it back into production. Some examples of maintenance tasks: Perform a software upgrade to a newer version. Make policy changes and verify they work as expected. Physically move the device. Replace a hard drive, fan, and/or power supply. Add the McAfee Web Gateway device to the new Topology This will allow us to test its functionality with a single client computer, prior to moving it back to production. From the SSL Orchestrator Configuration Utility click SSL Orchestrator > Configuration > Topologies > sslo_Topology_Staging. Click the pencil icon on the right to edit the Service. Click Add Service. Select the Generic Inline Layer 2 Service and click Add. Give it a name or leave the default. Click Add under Network Configuration. Set the FROM and TO VLANS to the following and click Done. Click Save at the bottom. Click the Service Chain icon. Click the Staging_Chain. Move the GENERIC Service from Available to Selected and click Save. Click OK. Click Deploy. Click OK. Test functionality with a single client We created a policy with source IP = 10.5.9.51 to use the new McAfee Web Gateway Service that we just performed maintenance on. Go to that client computer and verify that everything is still working as expected. As you can see this is the test client with IP 10.5.9.51. The page still loads for one of the web servers. You can view the Certificate and see that it is not the same as the Production Certificate. Add the McAfee Web Gateway device back to the original Topology From the SSL Orchestrator GUI select SSL Orchestrator > Configuration > Service Chains. Select the Staging_Chain. Select ssloS_GENERIC on the right and click the left arrow to remove Selected. Click Deploy when done. Click OK. Click OK to the Success message. From the SSL Orchestrator Guided Configuration select SSL Orchestrator > Configuration > Services. Select the GENERIC Service and click Delete. Click OK to the Warning. When that is done click the ssloS_McAfeeWebGateway Service. Click the Pencil icon to edit the Service. Under Network Configuration click Add Set the Ratio to the same value as MWG2, 65535 in this example. Set the From and To VLAN the following and click Done. Click Save & Next at the bottom. Click OK. Click Deploy. Click OK. Test functionality 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: This McAfee Web Gateway device is actively processing connections. Repeat these steps to perform maintenance on the other McAfee Web Gateway device (not covered in this guide) Related Articles Integrating SSL Orchestrator with McAfee Web Gateway-Explicit ProxyVerified 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 ProxySSL Orchestrator Advanced Use Cases: Fun with SaaS Tenant Isolation
Introduction Introduced in SSL Orchestrator 10.1, you can now seemlessly integrate Microsoft Office 365 Tenant Restrictions as a service function in the decrypted service chain. Before I go any further, you may be asking, what exactly are Tenant Restrictions? And why would I want to use them? Well, I'm so glad you asked. Think of a tenant restriction as a way to isolate a tenant (i.e., a set of enterprise accounts) on a SaaS platform. This is super useful for SaaS resources like Office 365, where your enterprise users will have corporate access to Office 365, but may also have their own personal O365 accounts, or accounts with another corporate entity. An Office 365 Tenant Restriction essentially prevents users from accessing any O365 accounts other than those specifically allowed. Most important, a tenant restriction is a really good way to prevent some forms of data exfiltration -i.e., by preventing users from saving proprietary information to a personal or other non-sanctioned Office 365 account. A tenant restriction essentially works by injecting one or more HTTP headers into an HTTP request for a specific set of request URLs, and enabling this feature in SSL Orchestrator 10.1 is super easy. You just create the service object, apply that service to a service chain, and put that service chain in the path of decrypted traffic. It's important to highlight here that injecting an HTTP header requires decrypted access to the traffic, so your SSL Orchestrator policy configuration must put this in a decrypted (intercept) path. To give you a quick example, for Office 365, you'll look for the following three request URLs: "login.microsoftonline.com" "login.microsoft.com" "login.windows.net" And if you see one of these, you'll inject the following two headers: "Restrict-Access-To-Tenants" "<permitted-tenant-list>" "Restrict-Access-Context" "<directory-id>" The above is all described in great and glorious detail here:https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/tenant-restrictions. Okay, so now that we've established what it is, and how it works, we can now get to the FUN part of this article. As it turns out, there are actually a few SaaS applications that support "tenant isolation", and they all do so in more or less the same way - inject one or more HTTP headers for a specified set of URLs. The common ones include: Webex Google G-Suite Dropbox Youtube Slack I'm sure there are more out there, but the above are what we'll focus on here. Let's see exactly how to set this up. SSL Orchestrator Advanced Use Case: Fun with SaaS Tenant Isolation The basic idea is to perform the following three steps: Deploy Office 365 Tenant Restrictions in SSL Orchestrator 10.1 Replace the iRule that the service generates with a new iRule Configure that iRule with the SaaS tenant isolation values that you require Step 1: Deploy Office 365 Tenant Restrictions in SSL Orchestrator 10.1 Starting in SSL Orchestrator 10.1, in the UI go to Services and click the Add button. Navigate to the F5 tab, click on "Office 365 Tenant Restrictions" and then hit the Add button. You won't actually be using the iRule that this service creates, so put anything you want into the two required header fields and click Save & Next. On the subsequent Service Chains List page, select or create a service chain and add this new service to that service chain. Click Save & Next. At this point, just make sure this service chain is assigned to a security policy rule that intercepts (decrypts) traffic. Deploy and move on to the next step. Step 2: Replace the iRule that the service generates with a new iRule Head over to the following Github repo to get the new iRule:https://github.com/f5devcentral/sslo-script-tools/tree/main/saas-tenant-isolation. In the BIG-IP UI, under Local Traffic, iRules, create a new iRule and paste the content there. Now back in the SSL Orchestrator UI, go to the Services tab, select your Office 365 Tenant Restrictions service to edit, and then at the bottom of the page, replace the selected iRule with your new tenant isolation iRule. Deploy and move on to the next step. Step 3: Configure the new iRule with the SaaS tenant isolation values that you require You're now going to need to make a few modifications to the new iRule. In the BIG-IP UI, under Local Traffic, iRules, click on your new tenant isolation iRule to edit. The iRule comes pre-built to support all of the aforementioned SaaS applications. Step 3a: In the RULE_INIT section, there is a separate array defined for each SaaS application. Inside each array is the required tenant isolation header(s) for that application. If you need to deploy tenant isolation headers for a given SaaS application, replace the "enter-value-here" string next to each header name with the required value. I've provided additional references below to help with those values. Step 3b: At the bottom of the RULE_INIT section, there are a set of static variables that enable or disable header injection for each SaaS application. To enable, set the value to 1. Otherwise to disable set the value to 0. That's basically it. If you've configured the header values correctly, and the service is in the direct path of decrypted outbound traffic through SSL Orchestrator, then the iRule should be doing it's job to prevent data exfiltration in your environment. Good job! Summary With an iRule and just a few configuration changes we have been able to implement a capability on top of SSL Orchestrator to extend the built-in Office 365 Tenant Restrictions service to support a set of additional SaaS applications. This flexibility is just one of the many interesting benefits of and SSL Orchestrator solution. Additional Resources As previously mentioned, there are more than just the described SaaS applications out in the wild that support tenant isolation, but these are the most common. If you know of any that might be useful to add, please let me know. Below is a quick reference for each of the included SaaS applications and the required match-on and send values. Office 365 Ref:https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/tenant-restrictions Match on: "login.microsoftonline.com" "login.microsoft.com" "login.windows.net" Send: "Restrict-Access-To-Tenants" "<permitted-tenant-list>" "Restrict-Access-Context" "<directory-id>" _________________________________________________ Webex Ref: https://help.webex.com/en-us/article/m0jby2/Configure-a-list-of-allowed-domains-to-access-Webex-while-on-your-corporate-network- Match on: identity.webex.com identity-eu.webex.com idbroker.webex.com idbroker-secondary.webex.com idbroker-b-us.webex.com idbroker-au.webex.comatlas-a.wbx2.com Send: CiscoSpark-Allowed-Domains = <enterprise domain> Ex. CiscoSpark-Allowed-Domains:example.com,example1.com,example2.com _________________________________________________ Google / G-Suite Ref: https://support.google.com/a/answer/1668854?hl=en Match on: *.google.com *.googleusercontent.com *.gstatic.com Send: X-GooGApps-Allowed-Domains = <comma separated list of allowed domains> Ex. X-GoogApps-Allowed-Domains: mydomain1.com, mydomain2.com _________________________________________________ Dropbox Ref: https://learn.akamai.com/en-us/webhelp/enterprise-threat-protector/enterprise-threat-protector/GUID-634616ED-28D3-4B23-B2C7-1E12ABE47E4A.html Match on: dropbox.com *.dropbox.com Send: X-Dropbox-allowed-Team-Ids = <dropbox team ID> _________________________________________________ Youtube Ref: https://support.google.com/a/answer/6214622?hl=en Match on: www.youtube.com m.youtube.com youtubei.googleapis.com youtube.googleapis.com www.youtube-nocookie.com Send: YouTube-Restrict = Strict. Provides access to a limited collection of video content. This is the most restricted mode. Moderate. Provides some restricted access but is less strict than Strict mode. Moderate mode allows users to access a larger collection of video content. _________________________________________________ Slack Ref: https://slack.com/help/articles/360024821873-Approve-Slack-workspaces-for-your-network Match on: *.slack.com Send: X-Slack-Allowed-Workspaces-Requester = <workspace or org ID (one value)> X-Slack-Allowed-Workspaces = <comma separated list of allowed workspaces and/or org IDs>
