Incident Remediation with Cisco Firepower and F5 SSL Orchestrator
SSL Orchestrator Configuration steps
This guide assumes you have a working SSL Orchestrator Topology, either Incoming or Outgoing, and you want to add a Cisco Firepower TAP Service. Both Topology types are supported, and configuration of the Cisco Remediation is the same.
If you do not have a working SSL Orchestrator Topology you can refer to the BIG-IP SSL Orchestrator Dev Central article series for full configuration steps.
In this guide we will outline the necessary steps to deploy the Cisco FTD with SSL Orchestrator. FTD can be deployed as a Layer 2/3 or TAP solution. SSL Orchestrator can be deployed as a Layer 2 or 3 solution. SSL Orchestrator gives you the flexibility to deploy in the manner that works best for you. As an example, SSL Orchestrator can be deployed in Layer 2 mode while FTD is deployed in Layer 3 mode, and vice versa.
A familiarity with BIG-IP deployment concepts and technology as well as basic networking is essential for configuring and deploying the SSL Orchestrator components of the BIG-IP product portfolio. For further details on the configuration and networking setup of the BIG-IP, please visit the F5 support site at https://support.f5.com .
The SSL Orchestrator Guided Configuration will walk you through configuration of the Services (Firepower nodes), Security Policy and more. Lastly, iRules will be applied.
Guided Configuration: Create Services
We will use the Guided Configuration wizard to configure most of this solution, though there are a few things that must be done outside of the Guided Configuration. In this example we will be working with an existing L2 Outbound Topology.
From the BIG-IP Configuration Utility click SSL Orchestrator > Configuration > Services > Add.
For Service properties, select Cisco Firepower Threat Defense TAP then click Add.
Give it a name. Enter the Firepower MAC Address (or 12:12:12:12:12:12 if it is directly connected to the SSL Orchestrator).
For the VLAN choose Create New, give it a Name (Firepower in this example) and select the correct interface (2.2 in this example). If you configured the VLAN previously then choose Use Existing and select it from the drop-down menu.
Note: A VLAN Tag can be specified here if needed.
Enabling the Port Remap is optional. Click Save & Next.
Click the Service Chain name you wish to configure, sslo_SC_ServiceChain in this example.
Note: If you don’t have a Service Chain you can add one now.
Highlight the Firepower Service and click the arrow in the middle to move it to the Selected side. Click Save.
Click Save & Next. Then click Deploy.
Configuration of iRules and Virtual Servers
We will create two iRules and two Virtual Servers. The first iRule listens for HTTP requests from the Firepower device. Firepower then responds via its Remediation API and sends an HTTP Request containing an IP Address and a timeout value. The address will be the source IP that is to be blocked by the SSL Orchestrator; the SSL Orchestrator will continue to block for the duration of the timeout period. For details and tutorials on iRules, please consult the F5 DevCentral site at https://devcentral.f5.com.
Create the first iRule on the SSL Orchestrator. Within the GUI, select Local Traffic > iRules then choose Create.
Give it a name (FTD-Control in this example) then copy/paste the iRule text into the Definition field. Click Finished.
This iRule will be associated with the Control Virtual Server.
iRule text
when HTTP_REQUEST { if { [URI::query [HTTP::uri] "action"] equals "blocklist" } { set blockingIP [URI::query [HTTP::uri] "sip"] set IPtimeout [URI::query [HTTP::uri] "timeout"] table add -subtable "blocklist" $blockingIP 1 $IPtimeout HTTP::respond 200 content "$blockingIP added to blocklist for $IPtimeout seconds" return } HTTP::respond 200 content "You need to include an ? action query" }
Create the second iRule by clicking Create again.
Give it a name (FTD-Protect in this example) then copy/paste the iRule text into the Definition field. Click Finished.
This iRule will be associated with the Protect Virtual Server.
iRule text
when CLIENT_ACCEPTED { set srcip [IP::remote_addr] if { [table lookup -subtable "blocklist" $srcip] != "" } { drop log local0. "Source IP on block list " return } }
Create the Virtual Servers from Local Traffic select Virtual Servers > Create.
Give it a name, FTD-Control in this example. The type should be Standard. Enter “0.0.0.0/0” for the Source Address Host. This indicates any Source Address will match. The Destination Address/Mask is the IP address the SSL Orchestrator will listen on to accept API requests from Firepower. In this example it’s “10.5.9.77/32” which indicates that the SSL Orchestrator will only respond to connections TO that single IP address.
Note: The Destination Address/Mask must be in the same subnet as the 2nd Management Interface on the Firepower Management Center. We’ll go over this later.
For VLANS and Tunnels Traffic it is preferred for this to be enabled on the specific VLAN that the Firepower 2nd Management Interface will be using, rather than All VLANs and Tunnels.
Choose Enabled on…
Select the same VLAN that the Firepower 2nd Management Interface will be using, in this example vlan509. Click the double << to move the vlan to Selected.
In the Resources section click the FTD-Control iRule created previously. Click the double << to move it to Enabled.
Click Finished when done.
Click Create again.
Give it a name, FTD-Protect in this example. Set the Type to Forwarding (IP). The Source Address in this example is set to 10.4.11.152/32. This Virtual Server will only accept connections with a Source IP of 10.4.11.152. It is being done this way for testing purposes to make sure everything works with a single test client. With an Incoming Topology the Source Address might be set to 0.0.0.0/0 which would allow connections from anywhere.
The 10.5.11.0 network is the Destination the 10.4.11.0 network must take to pass through SSL Orchestrator.
Under Available, select the ingress VLAN the SSL Orchestrator is receiving traffic on, Direct_all_vlan_511_2 in this example. Click the double << in the middle to move it from Available to Selected.
In the Resources section click the FTD-Protect iRule created previously. Click the double << to move it to Enabled.
Click Finished when done.
Steps Performed:
1. Firepower TAP Service created
2. iRules created
3. Virtual Servers created
4. iRules attached to Virtual Servers
Cisco Firepower (FTD) Setup and Configuration
This Guide assumes you have Cisco Firepower and Firepower Management Center (FMC) deployed, licensed and working properly.
After logging into the Firepower Management Center you will see the Summary Dashboard.
Click System > Configuration to configure the Management settings.
Click Management Interfaces on the left.
A Management Interface on FMC must be configured for Event Traffic. This interface MUST be on the same subnet as the Control Virtual Server on SSL Orchestrator (10.5.9.77). If using a Virtual Machine for FMC you need to add a 2nd NIC within the Hypervisor console, like this:
Refer to your Hypervisor admin guide for more information on how to do this.
To configure the 2nd Management Interface click the pencil icon.
Click Save when done.
Firepower Access Policy
This guide assumes that Intrusion and Malware policies are enabled for the Firepower device. The Policy should look something like the image below.
Firepower Remediation Policies
Next, we need to create a Firepower Remediation Policy. A Remediation policy can take a variety of different actions based on an almost infinite set of criteria. For example, if an Intrusion Event is detected, Firepower can tell SSL orchestrator to block the Source IP for a certain amount of time.
From FMC click Policies > Responses > Modules.
The F5 Remediation Module is installed here. Click Browse to install the Module. Locate the Module on your computer and select it, click Open then Install. Click the magnifying glass on the right after it’s installed.
Note: The F5 Remediation Module can be downloaded from a link at the bottom of this article.
Click Add to Configure an Instance.
Give it a name, Block_Bad_Actors in this example. Specify the IP address of the SSL Orchestrator Control Virtual Server, 10.5.9.77 in this example. Optionally change the Timeout and click Create.
Next, configure a Remediation by clicking Add.
Give it a name, RemediateBlockIP in this example and click Create.
Select Policies > Correlation > Create Policy to create a Correlation Policy to define when/how to initiate the Remediation.
Give it a name, Remediation in this example and click Save.
From the Rule Management tab click Create Rule.
Give it a name, RemediateRule in this example.
For the type of event select ‘an intrusion event occurs’ from the drop-down menu.
For the Condition select Source Country > is > North Korea > Save
Note: FMC can trigger a Remediation for a variety of different events, not just for Intrusion. In fact, while configuring Remediation you might want to use a different Event Type to make it easier to trigger an event and verify it was successfully Remediated. For example, you could choose ‘a connection event occurs’ then set the Condition to URL > contains the string > “foo”. In this way the Remediation rule should trigger if you attempt to go to the URL foo.com.
Go back to Policy Management and click the Policy created previously, Remediation in this example. Click Add Rules.
Select the RemediateRule and click Add.
Click Save.
Correlation policies can be enabled or disabled using the toggle on the right. Make sure the correct policy is enabled.
Remediated Policy Reporting
The status of Remediation Events can be viewed from Analysis > Correlation > Status.
Here we can see the “Successful completion of remediation” message.
Conclusion
This concludes the recommended practices for configuring F5 BIG-IP SSL Orchestrator with the Cisco FTD. The architecture has been demonstrated to address both the SSL visibility and control and IPS Policy Based Traffic Steering and Blocking user scenarios. With the termination of SSL on the SSL Orchestrator, FTD sensors are provided visibility into both ingress and egress traffic to adapt and protect an organization’s applications, servers and other resources. By leveraging the Security Policy Based Traffic Steering, an organization can leverage this configuration and can continue to scale through the addition of more FTD managed devices in order to provide more traffic capacity for the protected networks and applications. This policy based flexibility which can be provided by the SSL Orchestrator, can also be leveraged to selectively direct traffic to different pools of resources based on business, security or compliance requirements.
- dragonflymrCirrostratus
Hi,
Thanks for confirmation.
Piotr
- KevinGallaugherEmployee
That should work. I was more concerned with demonstrating the remediation capabilities with Firepower.
- dragonflymrCirrostratus
Hi,
Probably I could but let's assume setup like that:
- Single L2 Outbound Topology protecting internal users access to Internet - so any internal source IP/VLAN should be intercepted
- Additional protection using described setup should be used for the same traffic
In this case there is no clear differentiation that can be used in configuration of FTD-Protect VS in compare to topology ingress VS. So question is if adding FTD-Protect iRule to topology ingress VS (and not creating FTD-Protect VS at all) could cause any issues or this is a way to go. At first look I can't see any issues but maybe I am wrong?
Piotr
- KevinGallaugherEmployee
Hi Piotr,
Couldn't you use the interception rule to specify the source vlan?
Kevin
- dragonflymrCirrostratus
Hi,
I wonder how this should be implemented in cease we need to protect outbound traffic to the Internet. To intercept such traffic FTD-Protect VS will have to be full wildcard, the same as Ingress VS created by Topology wizard (sslo_Outbound-in-t-4 if I Am not wrong) so there will be conflict, no way to configure two VSs with the same settings.
Should then FTD-Protect iRule be added in Interception Rule section of the Topology in iRules property?
Piotr
- dragonflymrCirrostratus
Hi Kevin,
Thanks for explanation, was just unsure if I Am missing something important here, now everything is clear.
Piotr
- KevinGallaugherEmployee
Hi Piotr, great question. This is an error on may part. The only key here is the connection passing thru SSL Orchestrator, internet bound or not, so the Protect VS can enforce the block. I would not consider this to be a best practices guide. This is merely a demonstration of some very cool capabilities.
- dragonflymrCirrostratus
HI,
Great article! As I am not routing expert I am not sure about this statement related to FTD-Protect VS: The 10.5.11.0 network is the Destination the 10.4.11.0 network must take to pass through SSL Orchestrator and get to the internet.
I assumed following:
- SSLO configured in L2 mode (vWire)
- L2 Outbound Topology is configured
As far as I understand in such config SSLO is transparent to other devices (but of course still process traffic in L3-L7).
How traffic destined to the Internet can be destined to 10.5.11.0 network? If dst IP in traffic passing via SSLO is in 10.5.11.0 network (so FTD-Protect VS can capture and process it) then it can only reach anything that is in this network not Internet destination - Am I missing something here?
It could work if 10.5.11.0 network would be kind of overlay network carrying client traffic inside, but if client initiates traffic to 10.5.11.0 network then it can't be directed to Internet but only to anything in this network.
Would really appreciate few words of explanation about traffic flow.
Piotr