Build the Next-Generation Data Center
6 week online course starting in spring 2017

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.

21 comments:

  1. What about traditional defense at the perimeter to control outside access, and VM FWs to control inter-server traffic? This way you don't have to apply the same global rules to every VM FW, and you don't need traditional FWs between server tiers.

    ReplyDelete
  2. This is a "centralization of the de-cetralization"... I don't like it so much...

    ReplyDelete
  3. Honestly I don't see the difference between the VM NIC firewalls and the host based firewalls. The basic premise for both being the protection of individual vm's or physical servers yet the host based fw is half the cost.

    ReplyDelete
    Replies
    1. I am entirely on board here. I was reading through this and thinking, "why not just use a host based firewall", how is this any better?

      Delete
    2. Well, also per-port ACLs doing the same thing. Let the DevOps guys do whatever VM stuff they want, but I wouldn't rely on this as the sole method of protection, when ACLs are wire-speed. Perimeter ACLs, port ACLs, host firewalls (of direct iptables, VM, or any sort). If you keep management traffic on a different network, it's very easy to tell if a system is compromised, because it's almost impossible to not trip an anomaly-centric detection strategy. You only have to worry about protocol tunneling at that point, but that's something you can look for as well. Well, and MITM attacks, but there are ways to detect someone playing around before they can do damage.

      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...

      Delete
    3. The viability of host-based firewall depends on whether your security team or your auditor trust the VM administrator to do the proper thing.

      Also, if someone breaks into the VM, he can disable the host-based firewall (whether you care at that point is a different story).

      Delete
    4. I can definitely see some advantages of this versus traditional host-based firewalls. First, as Ivan mentioned, an intruder within a VM cannot (practically speaking, at least) disable or modify the policy of the local firewall as it exists outside the VM.

      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.

      Delete
  4. This is the future. I have been advocating this architecture for 5 years. I am excited to see it gaining traction.

    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

    ReplyDelete
  5. Brian: One of the key differences between Host Based firewalls and vNIC/hypervisor filters is the ability for separation of duties. This is even more important in Multi-tenant environments where the provider wishes to enforce policies that the tenant cannot change.

    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.

    ReplyDelete
    Replies
    1. ok, that makes some sense. Multi-tenant environments would have a definite use-case for this. A traditional single tenant / corporate DC, I just don't see it still.

      Delete
  6. If I'm an intruder that can own a server and have access to the hypervisor, I'm sure a can easily disable a vm nic firewall. Seems to me host to host access rules need to be independent from hypervisor, done in hardware, but that is not very efficient.

    ReplyDelete
    Replies
    1. 1. You can't get from a VM guest into the hypervisor. Period.
      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.

      Delete
    2. Search escape to hypervisor.. yes it has been mitigated. There is still a risk, virtual host fw are a crutch and not a solution.

      Delete
  7. I like this a lot and I'm not even slightly interested in security most of the time. I assume this could be as tight (per guest) or loose (per VM host) as you might want. I wonder if you would also want to do this with IDS and WAF functions and implement/enable features based on the make up of the guests on any one VM. Very interesting. I think you'd definitely want to keep the perimeter defenses in place but simplified somewhat, otherwise you might be carrying a fair deal of invalid or attack traffic far into your networks.

    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.

    ReplyDelete
  8. Ivan,

    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.

    ReplyDelete
  9. Hypervisor fw (and other virtualized security services) are most definately something we are interrested in. Advantages as I see them are:
    - 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?

    ReplyDelete
  10. I disagree that a compromised security zone is game over. Security is built in layers. Those host in a compromised security zone should be hardened, have complex authentication requirements to get in them, etc. Just because a compromised host in a security zone can get at additional ports on the other hosts doesn't mean an attacker will be more successful. More often than not an attacker only needs to get to that one port that that firewall is already exposing to get the job done. (such as HTTP on port 80 or HTTPS on port 443)

    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).

    ReplyDelete
  11. I have not yet seen redundant VNIC-level firewall implementations (admittedly, I didn't look too hard), which stopped me from using those we have that have that option. For context - we deal with "traditional" production workloads.

    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

    ReplyDelete
  12. I'd like to have my cake and eat it two, please. Create security zones with traditional firewalls, create VM firewalls per VM, and use host based firewalls.

    ReplyDelete
  13. Assuming there's a decent centralized console, the management and auditing capabilities would almost be worth it alone.

    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.

    ReplyDelete
  14. The idea is appealing, but it is very much centred around VMWare. In real life, all sorts of systems live on the network: Solaris, IBM P7 and even mainframes. This means that this new type of firewall has only a limited value.
    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.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.