If everyone is thinking the same, someone isn't thinking

Lori MacVittie

Subscribe to Lori MacVittie: eMailAlertsEmail Alerts
Get Lori MacVittie via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Mergers & Acquisitions on Ulitzer, Married to Chocolate

Blog Feed Post

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.



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. 

#  Clone Pool Based on URI
#  CPU impact:   Minimal
#  Requirement:  HTTP profile
#  A clone pool is a pool of transparent devices such as Intrusion
#  Detection Systems.  Instead of cloning (copy or mirroring) all
#  traffic to the IDS pool, this iRule more granularly clones only
#  traffic destined for sensitive areas of a web site.
  if { [HTTP::uri] starts_with "/secure" } {
    clone pool clone_pool
  pool real_pool


The advantage of using a strategic point of control like BIG-IP is its visibility and management of an application as a holistic unit. Because it is the primary interface for clients when interacting with a web application, BIG-IP sees the total load on an application and its supporting infrastructure.

That allows operations to codify policies that dynamically adjust the flow of traffic based on current capacity against current request load. It can collaborate with provisioning and management systems to further initiate provisioning of additional security resources if they’re virtualized, providing the means by which an application can be truly scaled to meet demands. Too often application scalability focuses solely on the application and its servers/instances, but operations does so at its own peril, as failing to properly also scale up supporting infrastructure such as IDS or IPS can cause failures if not of the application then of the security or other supporting infrastructure systems. Consider a failure of the identity and access management supporting web applications, for example. Such a failure ultimately means a failure of the application, even though operationally there may be more than enough “web” resource capacity to fulfill all incoming requests. It is paramount to a successful scaling strategy to ensure that all components directly or indirectly impacted by increases in traffic volume are either able to scale along with the application or there are policies in place to effectively manage the incoming requests such that no topological segment of the architecture is overwhelmed.

There’s no single “best” way to architect such a solution because it’s highly dependent on an organization’s operational goals and policies and the business’ tolerance for risk. The flexibility of iRules and ability to strategically apply policies governing resource utilization affords organizations the means to architect a solution that meets or exceeds operational goals using the resources at hand. It is in part this agility that makes BIG-IP a strategic point of control; enabling organizations to apply and enforce a broad range of operational policies in a way that makes the most of limited resources.

Connect with Lori: Connect with F5:
o_linkedin[1] o_rss[1] o_facebook[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]

AddThis Feed Button Bookmark and Share

Related blogs & articles:

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.