The 2/9 Virtualization Security Podcast held a discussion on when would one use a virtual firewall. This was in response to being told that there are some people that would never use a virtual firewall for anything, and that got me thinking. Outside of the politics involved with using virtual vs physical firewalls, when would you use one? What are the cut offs, and best practices around using virtual firewalls. We were joined by Rob Randell of VMware to discuss this point.
||Where FW Sits
|Edge||Sits between two or more virtual portgroups or virtual switches|
||Resides within the hypervisor side of each virtual NIC|
Some background first, there are two types of virtual firewalls available to day, one that is a traditional Edge firewall and one that is more ‘introspective’ using introspection APIs to do their work. We discussed both types of these firewalls with respect to defence in depth. So the first best practice that came out of our discussion was:
Use Virtual Firewalls to Provide defence in depth
However, one could argue that in guest firewalls can also provide defence in depth, but that could lead to issues of how to manage each of those in-guest firewalls, the resources that each in-guest firewall takes up, hacks that attack the in-guest firewalls, as well as how to handle transient and dormant (powered-off, suspended) VMs for firewall rule updates.
Using an introspective approach provides a well managed way to keep each VM protected regardless of virtual machine state. Lastly, in-guest firewall attacks would fail, as the firewall is not running in-guest but outside the guest.
Throughput of introspective firewalls was also brought up, but well written rules can assist with such performance. With vShield App, for example, up to 5000 rules cause no impact to throughput.Â However, this will depend mostly on how the rules are written and perhaps even their order. Unfortunately, no one on the podcast knows of any introspective firewalls for any hypervisors except VMware vShield App and the third party VMsafe firewalls from Trend Micro, Reflex Systems, Juniper, Checkpoint, etc.
|> 15000 Sessions/sec
> 10GB/s throughput
|Use Physical or at least a Physical Load balancer with distributed virtual firewalls behind|
> 5GB/s throughput
|Use combination of physical and virtual|
|< 2000 Sessions/Sec
< 5GB/s throughput
The alternative firewall is an Edge firewall, these can be used at the Edge of your data centre or between trust zones within your virtual or cloud environments.Â But, the real question arises to when you can use such an Edge firewall and when you should use a physical firewalls. So we discussed the difference size workloads and organization types to set some ground rules. We broke the types of workloads into three based on sessions per second and throughput requirements. Why these? Because we also measure physical firewalls by these values. Refer to the table to the left, but in most cases a virtual firewall can also be used, but for the higher end workloads, there is quite a bit more architecture to be done to make use of a virtual firewall, as there are limits with nearly any technology.
Let’s take an example brought up during the podcast, if you had a need to 1B queries per day that exceed 15K sessions per second, you could use either a bigger physical firewall or you could distribute the load acrossÂ multiple virtual firewalls, but if you distributed this workload over virtual firewalls, you most likely need a physical load balancer to handle the incoming sessions and queries. So while virtual firewalls may be possible, you still need something physical to make it work properly. As a side note, most in-guest firewalls would be crushed with this type of workload even when distributed.
These numbers seem fairly high but are not unreasonable for certain industries, so if we reduce the workload, we run into the middle ground where you can go in either direction based on the specifications of the virtual firewall chosen. So this leads to our next best practice rule for when to use virtual firewalls.
Compare Virtual and Physical Firewall Specifications
When choosing to use a virtual firewall or not, it is not about the fact that the firewall is virtual, but what that firewall offers. We can easily get specifications for all physical firewalls, those same specifications should be available for virtual firewalls. However, we still have to manage these virtual firewalls, and in most cases, this leads to a political discussion about changing how anyone does business but there are solutions to this as well. Choose a virtual firewall that is an extension of your existing physical environment or at least integrates into your existing environment either using vendor tools or tools specifically designed to keep disparate firewall constructs in sync. All major firewall and switch vendors have virtual versions of their firewall that can be controlled via the same interface as their physical firewalls and switches such as Juniper vGW, CheckPoint, Cisco vASA, etc. However, there is one more best practice that should be considered:
Do not limit yourself to just one breed of firewall, choose best of breed.
I would not ignore virtual firewall vendors such as Catbird, Vyatta, Trend Micro, etc. but instead include them in any discussion to determine the best fit for your needs. In many cases, a virtual firewall can exceed the expectations of any physical firewall due to its placement within the network. We can do more with a virtual firewall than we have ever been able to do with physical firewalls. Granted, the Next Gen physical firewalls will also exceed our expectations, but expect virtual versions of the same things very soon.
In conclusion, there are times when a fully virtual solution does not make sense, but there are other times when they do. It depends on your needs. We just looked at two key numbers, throughput and sessions/second, but there are others equally important depending on your workloads. I wouldÂ chooseÂ to go with a virtual firewall based on requirements and workload needs. When can you use a virtual firewall? Nearly everywhere with the proper architecture.