F5 Firewall Like No Other - Ruling the Application
“Vive la différence!” I’ve been here in Europe at our Agility Conference in Monte Carlo (the theme: GO BIG) talking with customers and partners about what makes the F5 firewall different.
F5’s European Conference at Monte Carlo Bay, Monaco
Old School Excel
As I made my presentation to a packed room of customers, I noticed that one story really got them nudging each other.
We had an early customer of the Advanced Firewall Manager (AFM) module. This customer used to organize their firewall rules in an old-school way – with an Excel spreadsheet. The spreadsheet was 300 pages long! This is how that happens:
Imagine a new firewall operator. A bizdev team builds a new application and asks him to open a hole in the firewall for it. He checks, and sees that there is already a working rule for an existing marketing application, so he doesn’t create a new one.
Six months later, the bizdev application is retired, and he is asked to remove the firewall rule. By now he has forgotten that he didn’t create a rule for this application and he removes the one that is there. This stops traffic to the original marketing application as well. When the marketing team realizes that they have stopped receiving traffic, they come and yet at him.
He quickly learns that it is “safe” to create a firewall rule but “unsafe” to remove one. This is the opposite of good security posture but it is a scenario that many, many, many organizations face today. This explains why so many in the audience were nodding and nudging each other.
Ruling the Application
The reason that F5’s firewall is different is because we build the application firewall rule into the application itself. It is part of the definition of the application, right there next to the http options, the pool definition and the tcp profile parameters.
ltm virtual bizdev1 {
ip-protocol tcp
pool bizdev_pool
profiles { http tcp }
fw-rules {
reject1020 {
action reject
log yes
source { addresses { 10.128.20.0/24 } }
}
allow_http {
action accept
destination { ports { http } }
ip-protocol tcp
}
}
}
When the application is retired, the associated firewall rules are automatically retired with it.
This has three benefits.
- No accretion of stale rules. While the initial management overhead may be the same for defining the network, over time the active set of firewall rules will remain identical to the active set of applications.
- Performance. This automatic pruning process will have performance benefits because, as firewall operators should know, the smaller the rule set, the faster the firewall.
- Application Mobility. As applications moves between datacenters and/or clouds, the firewall rules move with them. This makes application migration easier and less error prone.
Changing the Firewall World
That’s just one way that F5 is changing the firewall world. There are other benefits associated with this “application-centric firewall policy management." If you want to see them all in one place, check out the white paper: “Replacing Abstract Zones with Real Application Security Policy.”
- Gordon_Bailey-MHistoric F5 AccountThe problem is - when administrators of the F5s become like firewall admins and don't clean up applications. And for all techies, admin is the bane of their existence. It all comes down to how lazy your people are. Perhaps some development should be done on adding a feature that reports via email when an app (or vs & associated pool members/nodes) has not been used in a while.