Verified Design: SSL Orchestrator with Palo Alto NGFW Virtual Edition-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 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 Perform maintenance on the Palo Alto VM At this point PaloAlto1 has been removed from the Production_Topology and is no longer handling production traffic. PaloAlto2 is now handling all the production traffic. We can now perform a variety of maintenance tasks on PaloAlto1 without disrupting production traffic. When done with the task(s) we can then safely test/verify the health of PaloAlto1 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 PaloAlto VM 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 Palo Alto 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 PALO-test 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.1.11.52 to use the new PaloAlto 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.1.11.52. 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. To ensure that everything is working as expected you can view the ACC statistics on Palo_Alto1, which was the Palo Alto device removed from the Production network. From ACC select Network Activity then Sessions. A time filter can be set on the left. You should see something like the image below, where Sessions and Bytes sent/received are gradually increasing. Add the Palo Alto VM back to the original Topology From the SSL Orchestrator GUI select SSL Orchestrator > Configuration > Service Chains. Select the Staging_Chain. Select ssloS_PALO-test on the right and click the left arrow to remove it from 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 PALO-test Service and click Delete. Click OK to the Warning. When that is done click the ssloS_PALOALTO Service. Click the Pencil icon to edit the Service. Under Network Configuration click Add. Set the Ratio to the same value as PaloAlto2, 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 To ensure that everything is working as expected you can view the statistics on Palo_Alto1. From the Palo Alto GUI select ACC (Application Command Center). Select Network Activity then Sessions. A time filter can be set on the left. Palo_Alto1 appears to be completely healthy. Repeat these steps to perform maintenance on the other Palo Alto VM (not covered in this guide) Remove a single Palo Alto VM from the Service 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 againVerified 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 ProxyVerified Design: SSL Orchestrator with Cisco Firepower Virtual Edition-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 Virtual Cisco Firepower. This is Part 2 of tis article. 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 Cisco Firepower 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 availableHERE This article is divided into the following high level sections: Part1 (available here) Firepower Virtual Machine configuration Create a new Topology to perform testing Monitor Firepower statistics – change the weight ratio – check Firepower stats again Remove a single Firepower device from the Service Part 2 (available here) Perform maintenance on the Firepower device Add the Firepower device to the new Topology Test functionality with a single client Add the Firepower device back to the original Topology Test functionality again Repeat to perform maintenance on the other Firepower device Perform maintenance on the Firepower device At this point Fireower1 has been removed from the Production_Topology and is no longer handling production traffic. Firepower2 is now handling all of the production traffic. We can now perform a variety of maintenance tasks on Firepower1 without disrupting production traffic. When done with the task(s) we can then safely test/verify the health of Firepower1 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 Firepower 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 Click Add Service Double click Cisco Firepower Threat Defense Inline Layer 2 Give it a name or leave the default. Click Add Set the FROM and TO VLANS to the following, click Done Click Save Click Service Chain Click the Staging_Chain Move the CSCO Service from Available to Selected, click Save Click OK Click Deploy Click OK Test functionality We created a policy with source IP = 10.1.11.52 to use the new Firepower Service that we just performed maintenance on. Go to that computer and verify that everything is still working as expected. As you can see this is the test client with IP 10.1.11.52. The page still loads for one of the web servers You can view the Certificate to see that it is not the same as the Production Certificate Add the Firepower device to the original Topology From the SSL Orchestrator GUI select Service Chains Select the Staging_Chain Select ssloS_CSCO and click the left arrow to remove it from Selected Click Deploy Click OK Click OK From the SSL Orchestrator Guided Configuration select Services Select the CSCO Service, click Delete Click OK Click the ssloS_Firepower Service Click the Pencil icon Click Add Set the Ratio to 65535. Set the From and To VLAN the following, click Done. Click Save & Next Click OK Click Deploy Click OK Test functionality again Make sure Firepower1 is working properly by viewing the Statistics This Firepower device is actively processing connections. Repeat these steps to perform maintenance on the other Firepower device (not covered in this guide) Remove a single Firepower device from the Service Perform maintenance on the Firepower device Add the Firepower device to the new Topology Test functionality with a single client Add Firepower device back to the original Topology Test functionality againVerified Design: SSL Orchestrator with Cisco Firepower 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 Cisco Firepower. It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working. If you need help setting up SSL Orchestrator refer to this Dev/Central article seriesor 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. Cisco Firepower backup files 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 availableHERE This article is divided into the following high level sections: Part1 (available here) Firepower Virtual Machine configuration Create a new Topology to perform testing Monitor Firepower statistics – change the weight ratio – check Firepower stats again Remove a single Firepower device from the Service Part 2 (available here) Perform maintenance on the Firepower device Add the Firepower device to the new Topology Test functionality with a single client Add the Firepower device back to the original Topology Test functionality again Repeat to perform maintenance on the other Firepower device Firepower Virtual Machine configuration Adapter 1 is for Management Adapter 2 is for the Diagnostic interface Adapter 3 corresponds to Firepower interface 0/0 Adapter 4 corresponds to Firepower interface 0/1 The Firepower network settings should look like this For a Layer 2 deployment like this use Ethernet0/0 and Ethernet0/1 to Create an Inline Set Create an Inline Set (Layer 2 bridge). Click Add Inline Set. Give it a name, inlineset1 in this example. Move eth0< - >eth1 to the Selected Interface Pair. Click OK Repeat these steps if configuring SSL Orchestrator deployed with High Availability Configure ESX Networking Create a Port Group for the following Network connectivity to the North (connected to BIG-IP interfaces) Network connectivity to the South (connected to BIG-IP interfaces) Service Egress to Firepower1 Service Ingress from Firepower1 Service Egress to Firepower2 Service Ingress from Firepower2 Create a new Topology A new Topology will be used to test the Service after maintenance is performed. This Topology can be re-used in the future From the BIG-IP Configuration Utility click Add Scroll to the bottom and click Next Give it a name, Topology_Staging Select L2 Inbound as the Topology then click Save & Next Click Save & Next Click Save & Next Click Add. A new Service Chain is needed so we can remove Firepower1 from the Production Service and add it here Give the Service Chain a name, Click Save Note: The Service will be added to this Service Chain later Click Save & Next Click Add Set Conditions to Client IP Subnet Match Enter the Client IP and mask, 10.1.11.52/32. Click New Set the SSL Proxy Action to Intercept Set the Service Chain to the one created previously Click OK Note: This rule is so 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 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 Select Save & Next Click Deploy Monitor Firepower statistics – change weight ratio – check Firepower statistics Check the statistics on the Firepower device we will be performing maintenance on. It’s “Firepower1” in this example. Connect to the CLI via SSH. At the prompt enter ‘capture-traffic’. Select the correct ‘inlineset’ (2 in this example) and hit Enter for no tcpdump options: You should see an output similar to this This Firepower device is actively processing connections Change the Weight Ratio Back to the SSL Orchestrator Configuration Utility. Click Services then the Service name Click the pencil icon Click the pencil icon for Firepower2 Set the ratio to 65535, click Done Click Save & Next Click OK Click Deploy Click OK Check Firepower Statistics With the Weight Ratio change there should be no active connections. It should look like this Note: The connections above represent the health checks from SSL Orchestrator to the inline Service Remove a single Firepower device from the Service From the SSL Orchestrator Configuration Utility. Click Services then the Service name Click the pencil icon Delete Firepower1 Click Save & Next Click OK Click Deploy Click OK Proceed to Part 2Orchestrated 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.Orchestrated Infrastructure Security - Change at the Speed of Business - Cisco Firepower
Editor's Note: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, Protocol Inspection (IPS) with AFM as well as leading Security Solutions like Cisco Firepower and WSA.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 Cisco Firepower can be downloaded fromherefrom GitLab. Please forgive me for using SSL and TLS interchangeably in this article. Click here for a demo video of this Dev/Central article This article is divided into the following high level sections: ·Create a new Topology to perform testing ·Monitor Firepower statistics – change the weight ratio – check Firepower stats again ·Remove a single Firepower device from the Service ·Perform maintenance on the Firepower device ·Add the Firepower device to the new Topology ·Test functionality with a single client ·Add the Firepower device back to the original Topology ·Test functionality again ·Repeat to perform maintenance on the other Firepower device 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 Firepower1 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. 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 Firepower statistics – change the weight ratio – check Firepower statistics again Check the statistics on the Firepower device we will be performing maintenance on.It’s “Firepower1” in this example. Connect to the CLI via SSH.At the prompt enter ‘capture-traffic’.Select the correct ‘inlineset’ (2 in this example) and hit Enter for no tcpdump options: > capture-traffic Please choose domain to capture traffic from: 0 - management0 1 - inlineset1 inline set 2 - inlineset2 inline set Selection? 2 Please specify tcpdump options desired. (or enter '?' for a list of supported options) Options: You should see an output similar to the following: This Firepower device is actively processing connections. Change the Weight Ratio Back to the SSL Orchestrator Configuration Utility.Click SSL Orchestrator > Configuration > Services > then the Service name, ssloS_Firepower in this example. Click the pencil icon to edit the Service. Click the pencil icon to edit the Network Configuration for Firepower2 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 Firepower Statistics Again Check the statistics on “Firepower1” again.With the Weight Ratio change there should be little to no active connections. It should look like the following: Note: The connections above represent the health checks from SSL Orchestrator to the inline Service. Remove a single Firepower device from the Service Back to the SSL Orchestrator Configuration Utility.Click SSL Orchestrator > Configuration > Services > then the Service name, ssloS_Firepower in this example. Click the pencil icon to edit the Service. Under Network Configuration, delete Firepower1. Click Save & Next at the bottom. Click OK if presented with the following warning. Click Deploy. Click OK when presented with the Success message. Perform maintenance on the Firepower device At this point Fireower1 has been removed from the Incoming_Security Topology and is no longer handling production traffic.Firepower2 is now handling all of the production traffic. We can now perform a variety of maintenance tasks on Firepower1 without disrupting production traffic.When done with the task(s) we can then safely test/verify the health of Firepower1 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 Firepower 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 Cisco Firepower Threat Defense 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 CSCO 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.1.11.52 to use the new Firepower 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.1.11.52. 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 Firepower device back to the original Topology From the SSL Orchestrator GUI select SSL Orchestrator > Configuration > Service Chains Select the Staging_Chain. Select ssloS_CSCO on the right and click the left arrow to remove it from 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 CSCO Service and click Delete. Click OK to the Warning. When that is done click the ssloS_Firepower Service. Click the Pencil icon to edit the Service. Under Network Configuration click Add. Set the Ratio to the same value as Firepower2, 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 Make sure Firepower1 is working properly. To ensure that everything is working as expected you can view the Statistics on Firepower1 again. This Firepower device is actively processing connections. Repeat these steps to perform maintenance on the other Firepower device (not covered in this guide) ·Create a new Topology to perform testing ·Monitor Firepower statistics – change the weight ratio – check Firepower stats again ·Remove a single Firepower device from the Service ·Perform maintenance on the Firepower device ·Add the Firepower device to the new Topology ·Test functionality with a single client ·Add Firepower device back to the original Topology ·Test functionality againOrchestrated Infrastructure Security - Getting Started
Note:TheBeaconcapabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latesthere. Introduction A typical daisy-chained security stack is difficult to manage and make changes.All devices in the chain are physically wired to each other in a serial arrangement.Each device performs SSL decryption and re-encryption when needed.All devices in the chain need to have similar performance capabilities.All devices in the chain need to be properly configured to route traffic to their neighboring devices, and likely will need to be manually configured to trust SSL certificates used by neighboring devices for decryption and re-encryption. Failure of any device in the security chain brings the entire chain down.Capacity cannot be increased simply by adding another like-device (i.e. a NGFW) to the chain.Capacity can only be increased by replacing a single device with a higher capacity device. Removing or adding a device to the chain is problematic.For one, the entire security stack will need to be unavailable while removing or adding a device.Proper routing between devices must be maintained or the whole chain will not pass traffic.Certificate trust and other factors may need to be addressed as well. High availability is also problematic.The only way to ensure high availability is to create another daisy-chain, identical to the first.This chain needs to wait in standby mode until the primary chain fails or is taken down, and then the standby chain can take over for the primary. Managing a single daisy chain security stack is not easy.Managing two for high availability is significantly more complicated and overly expensive. Some security devices are deployed differently and cannot operate together in the security stack.Those devices would need their own separate deployment from the devices in the daisy chain, further complicating the configuration.As an example, it’s not an uncommon security practice to employ network TAP devices, explicit proxies, ICAP servers as well as Layer2/3 devices. All of these devices cannot be configured to properly route traffic in a daisy chain. SSL Orchestrator solves almost all of these challenges, and enables you to have a nimble security solution capable of adapting to almost any type of threat. High Level Network Topology The network topology used for this setup is below.BIG-IP-11 and 12 are deployed in Layer 2 mode. The Advanced WAF and AFM devices will also be deployed in Layer 2 and will be physically wired to the SSL Orchestrators.This is a high availability environment where there is one Active BIG-IP and one ready on Standby.The Port Objects (511 & 512) allow traffic to flow through either BIG-IP, in case of a failure.The applications being protected are represented by the Ubuntu servers connected to the South switch. BIG-IP Network Topology A zoomed in view of the BIG-IP devices is below.This shows the physical connectivity and the specific interfaces used by SSL Orchestrator, Advanced WAF and AFM devices. Summary 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. Next Steps Click Next to proceed to the next article in the series.Orchestrated Infrastructure Security - Protocol Inspection with AFM
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 Protocol Inspection (IPS) with AFM deployed as a Layer 2 solution. It covers the configuration of Protocol Inspection on an F5 BIG-IP running version 16.0.0. Configuration of BIG-IP deployed as AFM 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: Protocol Inspection (IPS) with AFM Network Configuration Create an AFM Protocol Inspection Policy Attach Virtual Servers to an AFM Protocol Inspection Policy Protocol Inspection (IPS) with AFM: 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. 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 5.0.Set Tagging to Untagged then click Add.Interface 5.0 (untagged) should be visible like in the image below.Click Repeat at the bottom to create another VLAN. Note: In this example interface 5.0 will receive decrypted traffic from sslo1. Give it a name, egress1 in this example.Set the Interface to 6.0.Set Tagging to Untagged then click Add.Interface 6.0 (untagged) should be visible like in the image below.Click Finished when done. Note: In this example interface 6.0 will receive decrypted traffic from sslo1. 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 3.0 and 4.0 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 Create an AFM Protocol Inspection Policy You can skip this step if you already have an AFM Protocol Inspection policy created and attached to one or more virtual servers.If not, we’ll cover it briefly.In this example we configured Protocol Inspection with Signatures and Compliance enabled. From Security select Protocol Security > Inspection Profiles > Add > New. Give it a name, IPS in this example.For Services, select the Protocol(s) you want to inspect, HTTP in this example. Optionally check the box to enable automatic updates and click Commit Changes to System. Attach Virtual Servers to an AFM Protocol Inspection Policy Attach the Protocol Inspection Profile to the Virtual Server(s) you wish to protect.From Local Traffic select Virtual Servers.Click the name of the Virtual Server you want to apply the profile to, 10.4.11.52 in this example. Click Security > Policies. Set the Protocol Inspection Profile to Enabled, then select the Profile created previously, IPS in this example.Click Update when done. Repeat this process to attach the IPS Profile to the remaining Virtual Servers. 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 AFM Protocol Inspection policy and attach it to your Virtual Servers. Next Steps Click Next to proceed to the next article in the series.Orchestrated Infrastructure Security - BIG-IQ
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 also assumed that BIG-IQ is deployed, and basic network connectivity is working. If you need help setting up BIG-IQ for the first time, refer to the Dev/Central article series Implementing SSL Orchestrator here.That article covers SSL Orchestrator but the procedure to add Advanced WAF and AFM to BIG-IQ is the same. This article focuses on configuring BIG-IQ version 7.1.0 to manage F5 Advanced WAF, AFM and SSL Orchestrator.It covers management of BIG-IP running version 15.1.0.4 and SSL Orchestrator version 7.4.9, and version 16.0.0 with AFM and Advanced WAF. Please forgive me for using SSL and TLS interchangeably in this article. This article is divided into the following high level sections: Import BIG-IP Devices into BIG-IQ Service Import Error Resolution Schedule regular backups of BIG-IP devices Push backups to BIG-IP device Import BIG-IP Devices into BIG-IQ From the BIG-IQ GUI go to Devices > BIG-IP Devices.This is where you add new devices to be managed by BIG-IQ.You should add the two SSL Orchestrator’s using the Dev/Central article above.Click Add Device(s) to add Advanced WAF and AFM devices. Select the option to Add BIG-IP device(s) and automatically discover and import services.Then click Add Devices. Enter the IP Addresses of the Devices you want to add, 192.168.41.3 and 192.168.41.4 in this example (use the Plus sign to add another IP address field).These are the two AFM devices.Enter the username and password to access these devices.Under Services check the box for Network Security (AFM) then scroll down. Check the box to enable Statistics Collection.You can configure a Zone and/or Cluster Display Name if desired.Click Save and Close. Your screen should look like the following.Click Add Devices so we can add the two Advanced WAFs. Enter the IP Addresses of the Devices you want to add, 192.168.41.21 and 192.168.41.22 in this example (use the Plus sign to add another IP address field).These are the two Advanced WAF devices.Enter the username and password to access these devices.Under Services check the box for Web Application Security (ASM) then scroll down. Check the box to enable Statistics Collection.You can configure a Zone and/or Cluster Display Name if desired.Click Save and Close. Click Discover and Import. You should see a Progress screen.Click Close. When complete, your screen should look similar to the following.= Service Import Error Resolution Some devices had errors during Import.Click the first one to resolve it. There was a conflict importing SSM.Check the box to create a snapshot of the configuration then click Import. The following items were changed on the BIG-IP.You can choose to import these into the BIG-IQ by selecting Set all BIG-IP.Click Continue. A dialog screen will present you with more information about what you’re doing.Click Resolve. Click Import to complete the import process.You may want to create a Snapshot of the configuration by checking the box. The BIG-IP Devices screen should look like this.The Advanced WAF device has been successfully imported.Repeat this process for any devices with an import error. When all Devices are successfully imported the screen should look like this. Schedule regular backups of BIG-IP Devices Now is a good time to schedule regular Backups.Check the box next to Status to select all the BIG-IPs.Click the down Arrow next to More and select Schedule Backup. Give the Backup a name, Backup_all in this example.There are several options here that you may wish to enable.For Local Retention Policy, it’s not a bad idea to keep multiple backups, 3 in this example.The Start Date and time can be adjusted to suit your needs. The Devices should automatically be selected.You can optionally enable the Archiving of Backups to an external SCP or SFTP server.Click Save & Close. Push backups to BIG-IP Device At some point you may need to restore one of your BIG-IP devices from a backup.To do this select the Devices tab > Back Up & Restore > Backup Files. From here you can view the different backup files.You can also Compare, Download, Restore or Delete backup files.Select the backup you would like to restore then click Restore. You will be presented with a confirmation message warning you that the configuration of the device is about to be overwritten from the backup.Click Restore to proceed. While the device is being restored you will see the following. Select BIG-IP Devices to check the status of the device when the restore is complete. Summary In this article you learned how to import BIG-IP devices into BIG-IQ, import the BIG-IP Services and schedule regular backups of the BIG-IP devices. Next Steps Click Next to proceed to the next article in the series.
