F5 Friday: The Art of Efficient Defense

It’s not enough to have a strategic point of control; you’ve got to use it, too.

One of the primary threats to the positive operational posture of an organization is that of extremely heavy load. Whether it’s from a concerted effort to take down the site (DDoS) or simply an unanticipated flood of legitimate users is really not as important to today’s discussion as understanding the impact both can have not just on your applications, but on their supporting infrastructure.

You know, the network “stuff” that sits between the client and your applications, defending against all manner of vile miscreant-created traffic. Most often these network devices comprise components like IDS and IPS; components that traditionally are configured in a transparent topology requiring the use of mirroring at the network layer. This is most often accomplished by mirror/span port configurations on the physical device. In the face of overwhelming traffic, these components can become, well, overwhelmed. Like firewalls, they can become a bottleneck. Unlike firewalls –which can induce performance degradations in the face of high traffic volumes - the bottleneck for these transparent security devices becomes a slowdown in operational processes and degradation in reaction times to the discovery of malicious content.

The typical reaction to such a potential problem is simple: acquire more resources and/or hardware to beef up capacity. But that’s not always the most efficient means of addressing the problem and in fact a more efficient solution would be to apply an architectural strategy that maintains an agile operational posture capable of reacting quickly to the presence of malicious content.

CONTEXTUAL TRAFFIC MIRRORING

Consider that in a traditional architecture comprising security devices such as IPS and IDS, all application traffic is mirrored to the device. All traffic, whether it needs to be inspected or not. Now that may at first sound like a silly statement.

Of course all traffic needs to be inspected. But does it? Does a request for an image need to go through an IPS or IDS? Stenography has come a long way, sure, but the technique is generally used to hide data for human consumption; it rarely if ever contains malicious code because there’s not a commoditized means by which such data can be exploited to gain access to internal systems or carry out an attack against a data source. But in a traditional architecture, requests for images are going through the security infrastructure no matter what. You’ve got no control over that.

Except you do, if you’ve got the right tools in your strategic arsenal. A tool like a network-side scripting that can leverage the innate capabilities of a full-proxy based application delivery controller. Yeah, I’m talking about iRules on an F5 BIG-IP LTM (Local Traffic Manager). Using the ability of BIG-IP LTM to intercept requests, inspect them, and then enforce routing, security and other application-centric policies upon those requests you can architect a solution that is makes more efficient use of the resources you have even in the face of higher traffic volumes. It’s a force-multiplier, making your limited security infrastructure resources more powerful by focusing them in on the attempts to outflank your information security strategy.

Using the iRules clone command, you can instruct BIG-IP to mirror traffic to a designated pool (collection of resources, most often servers) or pool member (a single resource, such as an application instance – virtual or physical). By taking advantage of iRules ability to inspect incoming requests, you can then leverage this cloning capability to only mirror specified traffic to a pool of security infrastructure components, such as a group of IDS. The decision regarding which requests are mirrored can be based on just about any variable you can think of – URI, host name, client agent data, request type, HTTP headers, cookies, etc… Such decisions could also be used conditionally; that is, if traffic volume suddenly increases a sampling of traffic could be mirrored off instead of all traffic as a means to avoid overwhelming the infrastructure, or perhaps such a policy could be enforced only when it becomes clear that the security infrastructure is about to be overwhelmed.

It’s about context – and the ability to leverage that context to make decisions that are smart, efficient, and consistent with business goals and requirements.

For those of you who’d like to try it out yourself, here’s a sample from our Solution Architects’ collection of “Top 50” iRules. This sample uses the URI as the means of determining whether to clone the request to a pool of IDS but you can use just about any information in the network stack – whatever makes sense to enforce the topological control over the flow of traffic you need to meet business and operational goals.