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 ProxyVerified 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 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 - Change at the speed of Business
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 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 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 BIG-IP deployed as Advanced WAF and AFM and 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: ·Create a new Topology to perform testing ·Monitor server statistics – change the weight ratio – check server stats again ·Remove a single AFM device from the Service ·Perform maintenance on the AFM device ·Add the AFM device to the new Topology ·Test functionality with a single client ·Add AFM device back to the original Topology ·Test functionality again ·Repeat to perform maintenance on the other AFM 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 AFM2 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 server statistics – change the weight ratio – check server statistics again Check the Virtual Server statistics on the BIG-IP we will be performing maintenance on.It’s “AFM2” in this example. Under Local Traffic click Virtual Servers. Then select Statistics > Virtual Server. Set Auto Refresh to 10 seconds. In this example you can see we have 5 Virtual Servers.The statistic counters should increment every time the screen refreshes.These servers appear to be healthy. Change the Weight Ratio Back to the SSL Orchestrator Configuration Utility.Click SSL Orchestrator > Configuration > Services > then the Service name, ssloS_IPS in this example. Click the pencil icon to edit the Service. Click the pencil icon to edit the Network Configuration for AFM1. 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 Server Statistics Again Check the Virtual Server statistics on “AFM2” again.With Auto Refresh on, the statistics should no longer increment.Current Connections should eventually reach zero for all Virtual Servers. Remove a single AFM device from the Service Back to the SSL Orchestrator Configuration Utility.Click SSL Orchestrator > Configuration > Services > then the Service name, ssloS_IPS in this example. Click the pencil icon to edit the Service. Under Network Configuration, delete AFM2. 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 AFM device At this point AFM2 has been removed from the Incoming_Security Topology and is no longer handling production traffic.AFM1 is now handling all of the production traffic. We can now perform a variety of maintenance tasks on AFM2 without disrupting production traffic.When done with the task(s) we can then safely test/verify the health of AFM2 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 AFM 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.1.11.52 to use the new AFM 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 Virtual Server Statistics on AFM2, which was the AFM device removed from the Production network. From Local Traffic select Virtual Servers > Statistics > Virtual Server. Statistics can be cleared by checking the box and selecting Reset.After a reset, you should see Bits and Packets for 10.4.11.56, assuming you reload the browser a few times from the test client. It is advisable to check that all of the Virtual Servers are working this way. Add AFM 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 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 GENERIC Service and click Delete. Click OK to the Warning. When that is done click the ssloS_IPS Service. Click the Pencil icon to edit the Service. Under Network Configuration click Add. Set the Ratio to the same value as AFM1, 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 AFM2 is working properly. To ensure that everything is working as expected you can view the Virtual Server Statistics on AFM2. From Local Traffic select Virtual Servers > Statistics > Virtual Server. Click Refresh or set Auto Refresh to 10 seconds.When the statistics reload it should look something like the following. Repeat these steps to perform maintenance on the other AFM device (not covered in this guide) Remove a single Adv.WAF device from the Service Monitor server statistics – change the weight ratio – check server statistics again ·Remove a single Adv.WAF device from the Service ·Perform maintenance on the Adv.WAF device ·Add the Adv.WAF device to the new Topology ·Test functionality with a single client ·Add Adv.WAF device back to the original Topology ·Test functionality again ·Repeat to perform maintenance on the other Adv.WAF device Check the Virtual Server statistics on the BIG-IP we will be performing maintenance on.It’s “Adv.WAF2” in this example. Under Local Traffic click Virtual Servers. Then select Statistics > Virtual Server. Set Auto Refresh to 10 seconds. In this example you can see we have 5 Virtual Servers.The statistic counters should increment every time the screen refreshes.These servers appear to be healthy. Change the Weight Ratio Back to the SSL Orchestrator Configuration Utility.Click SSL Orchestrator > Configuration > Services > then the Service name, ssloS_AdvWAF in this example. Click the pencil icon to edit the Service. Click the pencil icon to edit the Network Configuration for WAF1. 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 Server Statistics Again Check the Virtual Server statistics on “Adv.WAF2” again.With Auto Refresh on, the statistics should no longer increment.Current Connections should eventually reach zero for all Virtual Servers. Remove a single Adv.WAF device from the Service Back to the SSL Orchestrator Configuration Utility.Click SSL Orchestrator > Configuration > Services > then the Service name, ssloS_AdvWAF in this example. Click the pencil icon to edit the Service. Under Network Configuration, delete WAF2. 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 Adv.WAF device At this point Adv.WAF2 has been removed from the Incoming_Security Topology and is no longer handling production traffic.Adv.WAF1 is now handling all of the production traffic. We can now perform a variety of maintenance tasks on Adv.WAF2 without disrupting production traffic.When done with the task(s) we can then safely test/verify the health of Adv.WAF2 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 Adv.WAF 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.1.11.52 to use the new Adv.WAF 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 Virtual Server Statistics on Adv.WAF2, which was the Adv.WAF device removed from the Production network. From Local Traffic select Virtual Servers > Statistics > Virtual Server. Statistics can be cleared by checking the box and selecting Reset.After a reset, you should see Bits and Packets for 10.4.11.56, assuming you reload the browser a few times from the test client. It is advisable to check that all of the Virtual Servers are working this way. Add Adv.WAF 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 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 GENERIC Service and click Delete. Click OK to the Warning. When that is done click the ssloS_AdvWAF Service. Click the Pencil icon to edit the Service. Under Network Configuration click Add. Set the Ratio to the same value as Adv.WAF1, 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 Adv.WAF2 is working properly. To ensure that everything is working as expected you can view the Virtual Server Statistics on Adv.WAF. From Local Traffic select Virtual Servers > Statistics > Virtual Server. Click Refresh or set Auto Refresh to 10 seconds.When the statistics reload it should look something like the following. Repeat these steps to perform maintenance on the other Adv.WAF device (not covered in this guide) Summary In this article you learned how to use SSL Orchestrator as a tool to assist with simplifying Change Management processes, procedures and shortening the duration of the entire process. Next Steps That's it, you're done!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.Orchestrated Infrastructure Security - Guided Configuration
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 SSL Orchestrator to decrypt inbound SSL and pass the decrypted content to F5 Advanced WAF and Protocol Inspection (IPS) with AFM for enhanced protection from threats.It covers the configuration of the SSL Orchestrator Topology, Services and more on an F5 BIG-IP running version 15.1.0.4 and SSL Orchestrator version 7.4.9. Configuration of BIG-IP deployed as SSL Orchestrator can be downloaded from here from GitLab. Please forgive me for using SSL and TLS interchangeably in this article. In this article we will walk you through the SSL Orchestrator Guided Configuration which covers the following: Inbound L2 Topology creation Certificate and Key used for SSL Decryption Adding the Advanced WAF and AFM devices Creating a Security Policy Creating an Interception Policy SSL Orchestrator Guided Configuration From the BIG-IP Configuration Utility select SSL Orchestrator > Configuration from the menu on the left. Note: There are Required Configuration options on the right you may need to configure.A Route is not needed when SSL Orchestrator is deployed in Layer 2 mode. The Configuration screen presents all of the configuration options that are available.Scroll to the bottom of the page and click Next. Give the Topology a name, InboundAppProtection in this example.You can optionally configure the Protocol and IP Family you want the Topology to support.We’re using the default of TCP and IPv4.Select L2 Inbound and click Save & Next. Configure the Certificate Key Chain by clicking the Pencil icon on the right. Choose the correct Certificate and Key from the drop menu.In this example we use subrsa.f5labs.com for the Certificate and Key.Click Done. There are Server-side SSL settings that you can optionally configure.Click Save & Next. On the next screen click Add Service. Scroll to the bottom, select Generic Inline Layer 2 and then Add. Give it a name, Advanced_WAF in this example.Under Network Configuration click Add. Here we create the VLANs & select the Interfaces the Advanced WAF devices are connected to.For the From and To VLAN options select Create New.Give them a unique name, egress_WAF1 and ingress_WAF1 in this example.Select the interfaces connected to the first WAF device, 4.1 and 4.2 in this example. Then click Done. Repeat this process for the 2 nd Advanced WAF device using interfaces 4.3 and 4.4.It should look like this when done. Note: In this case the SSL Orchestrator interfaces 4.1 and 4.2 are connected to Advanced WAF1 interfaces 2.1 and 2.2.SSL Orchestrator interfaces 4.3 and 4.4 are connected to Advanced WAF2 interfaces 2.3 and 2.4. You can optionally configure the Device Monitor and Service Down Action.Enable the Port Remap option and click Save. Click Add Service to add the AFM devices. Scroll to the bottom, select Generic Inline Layer 2 and then Add. Give it a name, AFM in this example.Under Network Configuration click Add. Here we create the VLANs & select the Interfaces the AFM devices are connected to.For the From and To VLAN options select Create New.Give them a unique name, egress_AFM1 and ingress_AFM1 in this example.Select the interfaces connected to the first AFM device, 5.1 and 5.2 in this example.Then click Done. Repeat this process for the 2 nd AFM device using interfaces 5.3 and 5.4.It should look like this when done. Note: In this case the SSL Orchestrator interfaces 5.1 and 5.2 are connected to AFM1 interfaces 5.0 and 6.0.SSL Orchestrator interfaces 5.3 and 5.4 are connected to AFM2 interfaces 5.0 and 6.0. You can optionally configure the Device Monitor and Service Down Action.Enable the Port Remap option and click Save. Click Save & Next at the bottom. Click Add to create the Service Chain. Give it a name, Inbound_Protect1 in this example.Select ssloS_AFM and ssloS_Advanced_WAF Services then click the arrow to move them to the right.Click Save. Note: It is recommended that AFM be placed first in the Service Chain Order.That way intrusion attempts are detected and blocked before they ever get to the Advanced WAF.This saves resources on the Advanced WAFs because they don’t have to process any of the attempted intrusion connections. Click Save & Next. For the Security Policy click the Pencil icon on the lower right to edit the rule. Set the Service Chain to the one created previously.Click OK. Click Save & Next at the bottom. For the Interception Rule, define the Destination Address or subnet of the application servers you wish to protect.In this example the application servers are all in the 10.4.1.0/24 subnet.Specify the correct port, typically 443. For the Ingress Network select the VLAN(s) that will be receiving traffic from external users, Direct_all in this example.Set the L7 Profile to http.Click Save & Next. Make any changes to the Log Settings if needed.Click Save & Next. On the Summary screen you can review and change any of the settings.Click Deploy when ready. You should get a Success message. If you receive an error you will need to go back into the configuration to resolve it.If successful, you should see a screen like this: Notice the Service Health status is indicated by the small green circle. Summary In this article you learned how to use the SSL Orchestrator Guided Configuration to create a Topology, select the certificate and key used for SSL Decryption, add the Advanced WAF and AFM devices, create a Security Policy and an Interception Policy. Next Steps Click Next to proceed to the next article in the series.
