Are you ready to change your security paradigm?
Most application stacks built today rely on decades-old security paradigm: individual components of the stack (web servers, app servers, database servers, authentication servers ...) are placed in different security zones implemented with separate physical devices, VLANs or some other virtual networking mechanism of your choice.
The security zones are then connected with one or more firewalls (when I was young we used routers with packet filters), resulting in a crunchy edge with squishy core architecture.
This age-old architecture has a major flaw: once an intruder owns one of the servers in a security zone, the game is usually over (at least for that security zone) ... but it’s the best we’ve been able to build for a long time.
The problem is exacerbated by the usual “best current practice” of placing servers hosting numerous applications in the same security zone to simplify the VLAN and firewall provisioning. Once an intruder breaks into the weakest application, he often has a free lunch trying to break into all other application servers in the same security zone.
Numerous firewalls vendors offer an enticing alternative in the virtualized world: VM NIC firewall. These firewalls are transparent (bump-in-the-wire) constructs implemented as a loadable hypervisor modules, traffic interception VMs, or service insertion solutions.
Regardless of how the VM NIC firewalls are implemented (although the implementation details greatly affect their performance), they offer a totally different security paradigm: each VM is protected with a firewall and everything outside of the VM is the outside world that needs to be tightly controlled (think of them as iptables implemented outside of the VM). Even the traffic between two VMs in the same security zone (using the legacy terminology – there are no security zones in the brave new world) is inspected and filtered.
Obviously the VM NIC firewalls idea needs a central management interface to be viable (you wouldn’t want to configure each one of the VM-level firewalls manually), and there are tons of implementation details and considerations, but even assuming these things work as promised, the fundamental questions remain:
- Would you trust this new architecture?
- Are you willing to jump into the brave new world and get rid of traditional firewalls?
- Would you prefer to combine the old with the new ... and face double complexity?
- What would your auditor say?
Please share your thoughts in the comments!
More information
You’ll find a more detailed overview of virtual firewall solutions (including VM NIC firewalls) and description of individual products for VMware, Hyper-V and Linux environments in the Virtual Firewalls webinar.
1. Someone is going to compromise your system through a web app. It's inevitable.
2. This is your chance to detect it at the zone where it was compromised , so the real issue here is not where you run your firewalls, but how you detect these attacks.
side note - decentralization with centralized management is good for scalability (think 10s or 100s of gigabits), so it's here to stay...
Also, if someone breaks into the VM, he can disable the host-based firewall (whether you care at that point is a different story).
Second, and perhaps more importantly, it provides a uniform approach to firewalling individual hosts. Where you might have a mix of Windows, Linux, and even miscellaneous 3rd party-managed servers to protect, a VM-based firewall would be implemented using the exact same configuration across all hosts to achieve far superior scalability. As far as protecting hosts which share a common security zone, this seems like an excellent augmentation of traditional zone-based controls.
As virtualization empowers mobility and dynamic services, the securing of those services must become more finite and flexible. A policy director will need to be established, but the policy will be applied per VM object, rather than by IP address only. Combined with SDN, we will soon be able to create a VM(s), apply policy, and have the orchestration establish network segments, firewall policy, IDS/IPS integration, and logging/reporting.
Another opportunity is that most host based or virtualization based firewalls process up to layer 7. The added visibility can increase filter accuracy and provide greater post intrusion indicators in the logged events.
I believe we will most likely retain the border firewall as a loose gatekeeper (or maybe ACLs on routers), but the true guardian will move the individual systems within the datacenter.
-Donny
Visibility and integration between the hypervisor, guest VMs and the physical infrastructure as offered by some vendors hypervisor security solution greatly increases the security model while allowing for flexible policy control.
2. Hypervisor access should have much tighter controls than VM guests. We cannot get to the hypervisor level without using two-factor VPN, even if we're within the data center. I wish an attacker good luck at getting to our hypervisors.
With some SDN or orchestration 'magic' I'd image you could have your distributed firewall/IDS/WAF functions reporting to a central 'controller' which implements simple perimeter controls (i.e. if a guest specific WAF logs attack attempts, the perimeter starts to drop traffic from the source for a specified time).
Very interesting.
I just wanted to say that I'm grateful for your very increased posting this year.
On this topic, I am skeptical it will work in practice. If you use the argument that there is not enough security in Web, App, DB DMZ structure and so VMs need their own firewalls - then that means you need rules for the VMs to talk to each other. How many ports are required for app to app, db to db, and web to web communications with large scale apps like EBS, SAP, Exchange, Lync, etc? There could be up to 100. How often do they change? With every patch it seems. Who can keep up with that? Who wants to? Who's going to force them to do that? The Dilbert cartoon posted earlier this week becomes no longer a joke.
If the security posture of db, web, app DMZ is no good then I advocate DB, Web, App ---- Per system. SAP gets its own firewalls, EBS gets its own firewalls, Exchange, Lync, Company Home Page, and so on.
- not modifyable from within a compromised guest (unlike a host fw)
- don't represent a bottleneck (unlike a hw fw);
- can scale linearly with the rest of the servers (vm hosts/guests)
- allow for seperation of duties
- can be provisionned dynamically at very little cost
- allow for rules based on vm attributes instead (or in addition) of IPs, thus relieving of the burdon of static IPs (careful addressing and constant acl updating), per server group subnetting (subnets,vlans,acls...), switchport (port assignments,acls);
-combined with overlay as vxlan, allows for statefully firewalled server vmotion without having to exend L2 to physical firewall.
-oh and did I say scales linearly with the rest of the datacenter?
Be very careful in thinking that VM NIC firewalls are the same thing as physical firewalls (including firewall contexts). These things are really just transparent firewalls. You're talking apples and oranges where there is likely a lack of feature parity. Unless something has recently changed, the Cisco and VMware VM NIC firewalls don't support IPv6.
Also be careful with the difference between a VM NIC firewall (fast path, transparent) and a virtual firewall (slow path, routed).
One could argue that vSwitches are also non-redundant, but a vSwitch usually has to do stuff much less complex than what a firewall would, meaning chances or things going south are lower.
And the question of complexity also brings us to the second issue - of scalability: there's a non-insubstantial risk of firewall module consuming too much of the host resources, and either slowing down network for collocated VMs, or starving them of CPU (or both). I hope I don't have to explain why would a firewall all of the sudden might need a lot of grunt.
Cheers,
-- Dmitri
I'd like to imagine a world where you can logically group machines into security zones independent of their IP/subnet. Restructuring zones to adapt to the changing a security/business landscape becomes much easier to implement with fewer resources. It could decouple the IP+security tie just like virtualization decoupled the OS+hardware upgrades & maintenance.
That said, I can still see one set of hardware firewalls for drawing a line in the sand to the outside world. Mostly for managing externally visible services and mitigating things that a virtual firewall can't cope with.
Even for systems that run on VMware it is not always a good option. Applications span multiple systems and often the communication between the parts of the applications is not well documented.
Finally, the management of the rule-sets will be labour intensive. A centralized console would be an absolute minimum requirement, but even then having more than a couple of hundreds of systems would make the management quite challenging.