VMware Paper

VMWare have a white paper on how to use their product with DMZs.  This is interesting, although doesn't address how the DMZ should be used to provide security.  It also irritatingly repeatedly avoids the big question:

Should I trust the hypervisor to separate my security zones.  And which architectures minimise the risk from an error by VMware in their software.

Instead they deflect it with a Gartner quote: 

Gartner research supports this view by suggesting that security risks primarily emanate from administrative misconfiguration and not from the virtual infrastructure.

Gartner are probably right. But if you fix your administrative configuration issues then the virtual infrastructure is surely worth worrying about, no?

More on the big question

So, should you trust the hypervisor? Well, CESG, who tend to err on the side of caution have made a fairly positive announcement with VMware.   Note that it only applies to vSphere, and that the security procedures they recommend don't appear to be public - which is a shame. 

So I don't have a firm answer on this one.  It probably depends on your threat profile.  If you are a major target for hackers - you are probably best having separate virtual server farms for different zones - possibly with more segregation than is even suggested in the VMWare papers Partially Collapsed model.

On the other hand, if you are a less interesting target, keep your hypervisor patched and keep an eye on the security news to make sure the situation doesn't change.

Segregation of duties

The most substantial point VMware also make is about staff.  Can you maintain security if you go the full virtual server route for your environment, with virtual firewalls, switches and all the various zones on a single virtual server platform.

The virtual server deployment is probably led by your IT staff.  You would be lucky if they apply the same level of diligence to the network security architecture as your networking teams.  In fact, perhaps the networking teams will lose control entirely with virtual switch, router and firewall management becoming an IT function.  IT staff are pressured to deploy things quickly. They may not have the same background in network security either.  What's going to keep network security policy enforced?  Who will audit it?

Even if control of the virtual firewalls is kept to a separate firewall team, are there people who can move a server to a different security zone to avoid going through the firewall at all?  Or to put a second interface on a virtual server to bypass a slow security review process?

This is important stuff.

Further Reading

Also, a useful VMWare hardening guide on SANS.

Reverse Proxy

I have seen a number of DMZ implementations which have a reverse proxy in there, forwarding traffic to a more secure zone somewhere else.  It isn't obvious why this is a good idea.  In fact it's so subtle it probably shouldn't have ever happened.

And in fact the reverse proxy might just make things worse if it isn't done correctly.

I think the IT people I've spoke to just find it a convenient way to publish otherwise internal applications onto the Internet without much consideration for security.

Does the reverse proxy stop those systems getting hacked?  Probably not.  If you wanted security, you might want a web application firewall instead of a reverse proxy.  You could look at mod_security for apache, or if budget is no object there are some serious appliances available. 

Using a reverse proxy:

1. The servers that it forwards connections to need to be considered vulnerable and placed into a DMZ. 
2. You need to enable the security features.
3. You need to secure the reverse proxy. 
4. You could usefully use the proxy to add authentication to applications, terminate SSL and log requests.  The logs may still be valid if the server it is protecting gets hacked, which may be useful. 

It will protect your back-end web server from attacks at the TCP and IP stack layer.  But we don't see many of those these days.

So, in general:

• Don't do it. 
• If you do it, remember the web servers behind it still need to be in a segregated network.
• If you want security, deploy a web application firewall, not a straight forward reverse proxy. 

Papers on Zoning and DMZs

A round up of papers on security zoning, addressing DMZ architecture and protection.  People who ought to know what they are talking about:

• 2001: SANS: http://www.sans.org/reading-room/whitepapers/firewalls/designing-dmz-950?show=designing-dmz-950&cat=firewalls
• 2010: Tufin's Chief Security Architecture: http://www.eweek.com/c/a/Security/How-to-Design-a-Secure-DMZ/


• Unfortunately it's a very short article.  Michael does make some great points: "The temptation is to create rules allowing inbound access from the DMZs to the internal network. This should never be allowed. All the services that are needed should be moved into DMZs so that internal networks are never exposed" and his classification of DMZ designs into Levels 1-4 is a good start. 
• http://www.cse-cst.gc.ca/its-sti/publications/itsg-csti/itsg38-eng.html - Canada's high level abstraction of DMZ architecture into a security zoning policy  The DMZ, if one exists, forms part of the PAZ in this documentation.

Vendor product papers: 

• http://www.redcannon.com/vDefense/VMZoning_wp.pdf
• IBM have written an entire book: http://www.redbooks.ibm.com/redbooks/pdfs/sg246014.pdf  It's called Enterprise Security Architecture, but handily for this blog it dives in, Chapter 2, with a whole section on network architecture.  Unfortunately it doesn't say anything very useful.  It has another terrifying suggestion: put a reverse proxy in the DMZ and use it to forward connections to a web server in a more secure zone. 

Things I need to read still:

• http://csrc.nist.gov/publications/nistpubs/800-82/SP800-82-final.pdf
• http://www.intel.co.uk/content/dam/www/public/us/en/documents/white-papers/cloud-security-and-secure-virtualization-paper.pdf
• 
  

DMZ: terminology

I hate this term, but I'm going to use it anyway because everyone has a bit of a grasp on it.  Think of it as a small security zone, fenced off with firewalls, protecting some servers that provide a particular service.

Do not think that the DMZ security discussion only applies to a network connecting the internet to your internal network.

Do not think that you are only permitted one such network: The DMZ.

Definitely do not use a cheap home router where you can enter a single IP address as the DMZ. This is just terrifying.   All the internet traffic gets routed to the internal host you specify without any further protection. Strangely NetGear acknowledge this in their documentation and say it should be called 'Exposed Host' instead.  Why do you not just rename it then NetGear!!

Secure DMZ Infrastructure Management

Secure DMZ Infrastructure Management is a paper from the Meta Group.  It's old, but covers a favourite topic, securing the DMZ.

The paper is here: 

http://www.glennodonnell.com/documents/sr016-DMZ.pdf

Unfortunately it's not very useful.  It has all the right words in it, but why, for example is FTP considered a minor topic, whilst SNMP from the inside to the servers a risk?  What's going to happen?  A reverse attack on the SNMP management client might be a possibility.  I expect it's a reaction to this vulnerability announcement, which I remember caused a lot of heart ache at the time: http://www.kb.cert.org/vuls/id/107186


But the first proposed solution is to use a separate management network, with ideally a separate NIC in each server.

There's then Figure 5, which separates the management server into a separate secured network between two new firewalls.  Good news for firewall vendors.  I think this could help a little, if the server is only providing monitoring.  But if the management server can control the servers on the internal and external network this hasn't really helped at all.  The attack could proceed:

1. DMZ server is compromised. 
2. Attacker uses management LAN connectivity and launches an attack on the management server. 
3. Management server has privileged control over servers on the internal network. 
4. Owned. 

With Figure 6 we are now back to the terrifying.  There's a management server inside the DMZ, only with a tunnel(!) back to the internal network.  He writes: "This forwarding is carried over a secure tunnel (e.g., VPN, secure socket) that is allowed passage by the firewall. No separate management network is required, and complex routing issues do not exist."

So - there's perhaps a VPN between the DMZ and the internal central management server.  The attack is becoming easier.  Encryption doesn't make for security alone. 

Bottom line - don't base your network security on this one.  The internet would be safer without it.

There's some slightly better analysis of the SNMP problem here:
http://www.tavve.com/wp-content/uploads/2011/05/trapping-from-dmz.pdf