Getting Started with AFM

tl;dr - BIG-IP AFM is a stateful firewall solution available on BIG-IP infrastructure targeted for datacenter traffic protection.

The BIG-IP Advanced Firewall Manager (AFM) is a high-performance, stateful, full-proxy network security solution designed to guard against incoming threats that enter the network on the most widely deployed protocols. It’s an industry leader in network protection, and one of its most impressive features is the scalability it can handle. It leverages the high performance and flexibility of F5's TMOS architecture in order to provide large data center scalability features that take second place to no one. In this article, we’ll cover the nomenclature and architectural components of the AFM module.

A little history

The truth is, BIG-IP has always had firewall features built-in. By nature, it is a default deny device. The only way to pass traffic through the BIG-IP is through a virtual server, which is an ip and a port. That ip could be 0.0.0.0/0 and that port could be 0, and thus you are allowing all IPs and all protocols, but that still is a configuration choice you made, not a default behavior of the BIG-IP. So given that a) the BIG-IP is already making the decision to allow or deny traffic based on virtual servers, and b) the capacity is far greater than most traditional network firewalls can handle, why not take the necessary steps to achieve certification as a firewall and give customers an opportunity to eliminate a layer of infrastructure for inbound application services?

And thus AFM was born (David Holmes had a great story about the origins in our roundtable last year.) But it was more than just slapping on a brand name and calling it a day. Some things had to happen to make this viable for the majority of customers. A couple show stoppers that are obvious firewall functions are a solid logging solution and an adequate rule building interface. 

Logging 

Any good firewalling function needs logs. What else will Mr 1983 here to the right have to do all night in his mom’s basement if he didn’t have logs to parse? Seriously though, without logs, how could you determine what is being blocked, and more important, what isn’t that should be? And in the event of a compromise, the information to properly handle the incident response.

BIG-IP’s high speed logging (HSL) functionality had been around for a while but it was enhanced over time to have a robust interface from several of the system modules. All the sources, formats, publishers, and destinations are configurable, and what’s cool about the interface is the pool functionality, so logs can be sprayed across a collection cluster so no one server is responsible for being 100% available.

Follow the rules! It’s all about context..

For rule building, some underlying infrastructure had to change. The flexibility of BIG-IP allows for all services to be configured at a virtual server level, but that may not always be desired. So a global context was added to handle policy decisions at a system level.

Just below the global context is the route domain. This level of separation allows administrators to have unique policies by route domain, segmenting strategically at routing boundaries for use cases like tenant deployments. Within the route domain, context rules can be applied to virtual servers and self IPs.

During packet processing, AFM attempts to match the packet contents to criteria specified in its active security rules. These rules are maintained in a hierarchical context. Rules can be global and apply to all addresses on the BIG-IP that match the rule, or they can be specific, applying only to a specific route domain, virtual server, self-IP, or the management port. The first context list of rules a packet passes through are the Global rules. If a packet matches a rule's criteria, then the system takes the action specified. If a packet does not match a rule, then the system compares the packet against the next rule, continuing through the context hierarchy and checking, as appropriate, rules relating to route domains, virtual servers, self-IPs, and the management port. If no match is found, the packet is dropped by the default deny rule. This fall-through is shown well here:

 The Object Model

Several sets of database tables have been created to support AFM rules. For each collection, a table set exists for each type of container. There is a table for global rules, virtual IP rules, self IP rules and management IP rules. There is a table for source addresses for global rules as well as a table for source addresses for virtual server rules. But each table essentially contains the same information, with keys that point at different parent containers. Instead of jamming everything into one table, normalization is done based on the type of parent configuration object that contains rules.

The classification module has two components: a compiler that generates a classifier in compiled form from configuration directives, and a classification engine that uses the compiled classifier to determine the set of rules matching a packet based on the packet contents and other relevant inputs. The compiler resides in the control plane and the classification engine resides in the packet processing path, as part of the TMM process.

Objects that use the classifier are:

  • Whitelists
  • Blacklists
  • SYN-cookies
  • Rate limiters
  • iRules
  • L4-7 signatures
  • ACLs

From a configuration perspective, the following containers of security rules are supported:

  • Global Rules: global rules affect all traffic except for traffic on the management interface. There is only one container object for global rules, and this is the first rule set that a packet is processed against.
  • Context Rules: context rules include rules for self-IP, virtual servers, route domains, SNATs and NATs, and management IP. Note that the management interface is not controlled by TMM, therefore it is handled by iptables in the Linux kernel. There can be multiple container objects for context rules since these rules are applied to specific objects and not globally.
  • Rule Lists are collections of rules that can be referred to by any of the other rule containers listed here. Nesting of rule groups is not supported, and a rule group may not refer to another rule group. Also, a rule group is path/folder aware.

Packet flow

 The packet flow is hinted at in the context section above, but for clarity this is a better visualization.

There is another version of this drawing with even more details which we based one of our Whiteboard Wednesday’s on last year.

Deployment modes

The first mode is ADC mode. This enforcement mode implicitly allow configured virtual server traffic while all other traffic is blocked. In ADC mode the source and destination settings of each virtual server (and self IP) imply corresponding firewall rules. The second is firewall mode. This enforcement mode is a strict default deny configuration. All traffic is blocked through BIG-IP AFM, and any traffic you want to allow through must be explicitly configured in the security rules. On top of these two operation modes there exists a global default. The purpose of the global default is to deny traffic which does not match listener. The global default can not be changed. You must configure explicit rules to allow traffic.

But Wait, There's More!

We've covered some of the core functionality that needed to be enhanced, but what other surprises are up the AFM's sleeve? No rabbits, but the AFM is chock-full of useful features, including:

We will be working on more articles in the near future to futher flesh out the feature list in AFM.

Conclusion

The AFM is quite a powerful security tool to wield for your inbound application services. Hopefully this article has been helpful in breaking down some nomenclature and architecture on the product, and whet your appetite for more firewall goodness. There is a lot more to come in this series, which you can link to from the article listing below.

Published Feb 03, 2017
Version 1.0
AFM
dcsecurity17
devcentral basics
security

Was this article helpful?