High Performance Intrusion Prevention

Overview

Utilizing the F5 BIG-IP ability to reliably load balance a high volume of concurrent connections to application services is further improved with integrations with IPS equipment providers. In this article I will articulate details pertaining to how the F5 BIG-IP along with the Cisco/Sourcefire Next Generation Intrusion Prevention System (NGIPS) managed device solutions can be utilized to provide a secure application delivery platform. This platform is secure and provides advanced client / server application monitored visibility.

This solution is not limited to just utilizing Cisco/Sourcefire. It can also be extended to other IPS providers. This article will focus on the functional demonstration that we are presenting at the 2014 RSA Conference.

The demo that was presented at the 2014 RSA conference is a functional demo. It does not stress the performance bounds of the joint solution. It is meant to demonstrate how the solution is built, monitored, and operated.

Solution

IPS deployments have limited bandwidth per sensor node. The traffic to be analyzed may require different sized IPS sensors depending on the traffic profiles. With BIG-IP these different traffic profiles can be sent to the properly sized IPS sensor. BIG-IP can also perform SSL offload. Be that as it may, the NGIPS will then inspect the traffic in the clear.

Scale-out Flexibility

Utilizing the BIG-IP Load Balancing capabilities, IPS inspection bandwidth can be increased by increasing the IPS Sensor node count within the load balanced pool. BIG-IP will load balance the traffic across all nodes within the pool. If sensors need to be serviced, they can be removed from the pool without affecting the end user. Multiple IPS Pools can be configured to address the varying bandwidth needs of your applications. Properly configured, the BIG-IP can selectively choose which traffic flows that will be sent to the IPS pool nodes for inspection.

Configuration

For the RSA conference we built a functional demonstration to load balance traffic to two Sourcefire NGIPS managed devices. The sensor receives the traffic using the BIG-IP Clone pool capabilities. As traffic patterns match IPS rules, and signatures. The Sourcefire Remediation API communicates to BIG-IP to enforce a denylist on the violating source IPs. To perform these tasks, BIG-IP uses two iRules. The first iRule is the Command iRule. And, the second is the Protection iRule. We will touch upon these aspects in the follow-on dialog.

Demonstration Network Topology Overview

Network Topologies

The flexibility that BIG-IP provides for traffic steering and load balancing allows for multiple ways to deploy the sensors. The sensors can be deployed as transparent in-line devices, Load balanced through Gateway Pools, and Load Balanced as cloned traffic. Leveraging the excellent capabilities and strength of BIG-IP to perform SSL Offload can be implored with either of these deployment topologies.

In-Line Transparent

The in-line deployment places the NGIPS managed devices in between the BIG-IP and the application servers. We use an interim VLAN to pass the traffic through the NGIPS devices. Health monitoring transparent IPS sensors is challenging. By design these devices do not directly respond to pings or other direct unicasted packets. If a sensor goes offline the remaining sensors will carry on inspecting traffic.

In-line Transparent Topology

In-Line utilizing Gateway Pools

An alternative way to deploy the sensors is to use Gateway Pools. Gateway Pools is a feature that allows traffic forwarding decisions to be performed through a pool of gateways (IP forwarding) devices. BIG-IP has nineteen different load balancing techniques that can be selected. The benefit this brings is that each gateway pool member can be health monitored. And, intelligent node selection based on concurrent connection and performance measurements. The network topology is similar to the in-line transparent setup with the addition of multiple NGIPS managed devices. Each of the NGIPS managed devices are configured with IP addresses. A virtual router is defined in order to address these sensors much in the same was as BIG-IP would forward traffic through a router.

Using Clone Pools

BIG-IP Clone Pool feature provides the ability to send a copy of traffic to a pool for inspection. The clone pool is directional in the sense the user can decide to just clone the client side traffic, server side traffic, or both. The NGIPS managed devices are on a side VLAN. The benefit this provides is the ability to apply the IPS inspection based on a per Virtual Server basis. This is the topology we chose to demonstrate at the RSA conference.

Example Deployment Topology

SSL Off-load assists with inspection

BIG-IP has a huge capacity to perform SSL Offload. This is the ability for the BIG-IP to decrypt the SSL traffic from the clients in order for the NGIPS managed devices to see the un-encrypted traffic content. Many intrusion inspection devices are un-able to decrypt the SSL traffic, or the performance degradation of enabling SSL decryption severely impacts the overall application performance capabilities. All of the previously mentioned topologies can be deployed with SSL Offload as long as the BIG-IP is not re-encrypting the traffic to the server pools. If this is the case then a sandwich approach can be deployed.

Detection and Enforcement

IPS Blocking for in-line operation

The NGIPS managed devices can be configured to block the offending traffic. This alone will not relieve the individual sensors from continuing to receive more violating traffic. However, the NGIPS signals the offending source IPs to the BIG-IP. The BIG-IP can perform the blocking enforcement on behalf of the intelligence that the NGIPS managed devices had detected. In turn the NGIPS is not burdened with the offensive traffic.

Remediation API

The Sourcefire NGIPS with Defense Center has a Remediation API that is used to signal the BIG-IP which sources to denylist. The remediation API is coupled with F5 iRule technology to handle the control communications and perform enforcement. The Defense Center communicates with a HTTP Request containing the offending source IP and a time out period. The time out period is the time before the offending source is allowed back in.

iRule overview

The iRules are utilized to perform both control and enforcement. The first iRule will receive source IP and timeout information from the Sourcefire Defense Center. This information is submitted into an internal data table. The second iRule will perform the enforcement to reject connection requests from the aforementioned source IPs. In turn time passes, and these clients can come back in to the playground. If they play nicely they are allowed to stay. Once, they violate the rule base. These source IPs will be reapplied and maintain an entry within our denylist table and continue to be rejected access.

Command iRule

The command iRule is applied to a Virtual Server that listens on the IPS VLAN. This virtual has no pool members associated to it. It’s there to catch the HTTP traffic from the Sourcefire Defense Center remediation API. The remediation API will send to the BIG-IP the offending Source IP and a configurable timeout period in seconds when a client trips an IPS rule. This iRule will also log to the ‘/var/log/ltm’ log file that the IP address has been added to the denylist table.

 

when HTTP_REQUEST {
if { [URI::query [HTTP::uri] "action"] equals "denylist" } {
set blockingIP [URI::query [HTTP::uri] "sip"]
set IPtimeout [URI::query [HTTP::uri] "timeout"]
table add -subtable "denylist" $blockingIP 1 $IPtimeout
HTTP::respond 200 content "$blockingIP added to denylist for $IPtimeout seconds"
return
}
HTTP::respond 200 content "You need to include an ?action query"
}

 

Command iRule

Enforcement iRule

The enforcement iRule is applied to the Application Virtual Servers. The internal table of IP addresses that is maintained by the BIG-IP is queried when a new connection request is initiated. If the initiator is on the denylist the connection request is dropped. The iRule will also log to that the client attempted to access a protected Virtual Server. After sufficient time (timeout period provided by the Remediation API from above) has passed the source IP is removed from the table to allow new connections to be established. As mentioned before if the client trips a blocking rule it will again be rejected.

 

when CLIENT_ACCEPTED {
set srcip [IP::remote_addr]
if { [table lookup -subtable "denylist" $srcip] != "" } {
drop
log local0. "Block IP on black list"
return
}
}

 

Enforcement and Protection iRule

Management Interface

This solution is managed and monitored with both the BIG-IP as well as the Sourcefire Defense Center. The Defense Center Content Explorer is a dashboard with a series of charts reporting traffic content details. BIG-IP Virtual Server and Pool statistics will report the traffic distribution of the NGIPS managed devices.

Cisco / Sourcefire Defense Center

These graphics are some screen shots of the Defense Center reporting.

Context Explorer: Events over time

Application Protocol distribution

Client Application Information distribution

F5 Dashboard: Sensor activity

Traffic Overview Dashboard

Web Application Traffic Risk

BIG-IP Virtual Server and Pool Statistics

BIG-IP Statistics show that the IPS Pools members are receiving the clone pool traffic.

IPS Pool Statistics

Virtual Server Statistics

Conclusion

Combining BIG-IP with Intrusion Prevention appliances is a very compelling solution. This demonstration was built utilizing the existing product feature sets of our currently released products. The demonstration is a functional representation to show how BIG-IP can load balance traffic to IPS sensors. The flexibility that both products provide, allows for improvements to the overall solution. The iRule code can be added to existing iRules. Utilizing the Sourcefire FireAMP features will extend this solution to also monitor for Malware. If a Server should become compromised Sourcefire will detect that from the Server Clone Pool traffic flows.