In modern Enterprise networks, you typically have many clusters of firewalls protecting assets in your network. Since we use two or more layers of firewalls, we can put our DMZ for intermediate security zones in different places in our network. Lets gather together the different options and consider the merits or not, and sometimes how they ‘self-build’.
Zones and Separation
For many networks, you need to separate different areas of the network. When separated for security reasons, these zones typically have a firewall put in to provide security and control that traffic that flows between these. It gets more complicated when there are services that needs to belong to two or more zones and so we have DMZ1. DMZ have been around for along time, but there are many more choices for implementation.
Lets look into some of these implementation and design ideas.
Zones
For this document, I will focus on just two zones, an external and internal. The external zone will be untrusted and where evil must be stopped (like the Internet for example), and the internal zone is where the users are.
Of course you can have more than one Internal Zone or more than one External Zone.
For a normal network, the traffic flows could be demonstrated to go between all zones at any time.
But when you add a firewall, security is enforced.
Two Firewall Layers
For all large companies, it is policy to use two firewalls for the gateway to the Internet. This fundamental idea is a long held belief in the security community that firewalls aren’t really secure. It’s probably is based on the fact that Checkpoint firewalls, the only firewall vendor at the time, had a major problem in the late nineties which meant they didn’t actually work, and could be easily bypassed. Ever since this time, security policy has mandated the use of two firewalls to remove this risk [slider title="but question of whether it is more secure remains unclear"]One of my favourite ways to upset security consultants from the major global firms, is to demand that clearly document how much more securetwo firewalls would be. For example, if I have a Cisco ASA and Nokia/Checkpoint, is it ten percent better ? Twenty percent ? Of course there is no answer for this, and the contortions that they will go to justify the statement is quite delightful. Sadly, most of these so-called security consultants have never even thought about it.[/slider]
What about product selection ?
For most people the choice has already been made as the firewalls have been in place for many years and then had the external firewall grafted in (or less commonly, the internal firewall). My recommendation is always to use a Cisco ASA as the external firewall and Juniper NetScreen as the internal firewall.
What ? No Checkpoint ?
Definitely not. The capital cost, operational cost and stupid-assed complexity of a Checkpoint/Nokia solution is horrendous. Not only are they expensive to buy, but very expensive to operate because they are so complicated. I haven’t seen a ‘proper and secure’ Checkpoint firewall in large companies because no one can make them work properly. As soon as problems start, all of the security features are turned off to get things working, and then they are never turned back on because of change control. This makes them the worst firewall product around.
And while it’s true that you COULD make Checkpoint secure, in the real world, you don’t want to be hiring Checkpoint experts just to manage firewalls, you need network people who are multi-skilled and part of cross-functional multidiscipline team. The days of the “firewalls only” team have passed. People who manage Checkpoint firewalls will need to be completely focussed on that one product, and will not usually have enough time to work on other parts of the network. This is poor value for money for most organisations.
Location – Where do you put the DMZ ?
Now DMZ are often specified by security people as a intermediate security zone for hosting systems that need to exposed to external parties, but also need to send data to the internal network. In a dual layer firewall, you could choose create a DMZ in a number of the different places.
To create a DMZ you need to
- create some VLAN’s on your switch infrastructure
- an IP interface on Firewalls with an address from a IP Subnet that you have allocated
- firewall rules that permit / deby traffic to and from the DMZ
Lets look at the different options for where you might want to locate the DMZ
DMZ on the External Firewall
You could choose to put the DMZ on the external firewall, like so:
It is my opinion that this is probably not the right place. If you believe in having two firewalls for security, then putting your services behind a single firewall from the external and untrusted zone is not consistent. In fact, you see this reasonably often when the external firewall was the ‘original’ firewall, and the internal firewall was added later.
DMZ on the Internal Firewall
You could choose to the put the DMZ on the internal firewall, like so:
The reasons that I most prefer this design is:
- traffic from the external and untrusted source passes through two firewalls thus meeting the intention of dual firewalls.
- traffic to the internal network is always more complicated, and has more flows. Consider all of the administration traffic to the servers in the DMZ. Therefore, passing internal traffic through a single firewall reduces the cost of ownership by reducing the numbers rules needed in the firewalls.
- its easier to understand. Because all external flows pass through the external firewalls, it is consistent with operational troubleshooting.
DMZ between the Firewall’s
This is starting to get clever, and is actually very common. You see, once you start adding DMZ’s to your network, you can’t have just one, you always end up with a quite few.
This type of DMZ Design looks really attractive, and people without a lot of design experience think that this is simply brilliant. I mean, it looks really marvellous when you draw it, and and it JUST LIKE THE RIGHT THING. Here is what is wrong with this idea:
- Routing – the servers in the DMZ need to have routing tables to decide which interface to send traffic. My life is too short to spend time explaining routing to server engineers (even when Microsoft includes it in their curriculum).
- Routing – on the firewall. Your firewall is not a router, and should’nt be used like one
- Testing and Service – you cannot access the outside DMZ interfaces from the internal network without really painful procedures
Accessing the outside interfaces
Let me draw accessing the outside interface. After all, you are monitoring these services for availability aren’t you ?
As you can see, sending data to that external network means quite a lot of work. Routing, firewall rules and this all adds up to something that can easily go wrong and costs extra money to build and maintain.
DMZ bridges from the External to the Internal (Servers as a Firewall)
Now this idea usually comes from someone on the server team, because they sometimes think that servers are a firewall. In fact, the entire security world believes that servers are the very thing we are trying to protect and that operating systems such as Windows and Linux are not to be trusted. Still, I’ve seen it a few times and it’s always been a bad idea.
So, some recommendations.
For the reasons I have outlined, the DMZ on the Internal Firewall makes the most sense. It’s easy to operate, and keeps the complexity on the internal firewall. I haven’t discussed it here, but it also works better when you have HA firewalls.
Footnotes
- de-militarized zones [back]
Loading ...
About Greg Ferro
Hi,
I believe that the location of the DMZ’s will be dependent on their use, i agree that the dmz’s should not sit across the two firewalls and also that the hosts should never be able to bridge, ie hosts should only ever have one interface linking to one firewall. That being said if you have a multi-tiered firewall complex, i believe that you should design the dmz’s accordingly, ie your first tier of firewall could be used to protect connectivity, so all the dmz’s within this tier separate all your connectivity ie internet, 3rd party, vpn’s etc.
Your next tier can be your front end tier, eg,all your presentation servers, ie web servers etc. You might even have 3rd tier, backend servers. Placing your dmz’s all within the “internal” zone limits your control to some respects. Logically you can achieve the same amount of control just using a single tier with lot of dmz’s if you’re on a budget and cannot afford multi-tier-multi-vendor.
I like the way you are thinking, and it’s sound reasoning. The problem is that having two different procedures for implementing DMZ is usually too complex for large companies to handle. In a large company, the operations team might have ten or twenty engineers who would make the DMZ changes, and probably only five of them who understand the differences. In the end, you should only choose one, either external or internal DMZ to keep it consistent and easy to support.
Hi,
First, I’m a fun of your schema
The DMZ place in your schema has, in my opinion, some advantages :
1- If you have a heavy Ext DMZ traffic you may prefer to not overload the internal firewall with such noisy traffic.
2- The DMZ servers are subject of security threats, If one of them is hacked, I suppose the external firewall is not doing the job correctly, then it’s a good idea that the internal firewall handls DMZ Internal traffic.
Have a nice day
Thanks very much.
Hi Greg,
I’d like to hear your comments on load-balancers as front-end filtering devices. Depending on your needs, a hardened load-balancer which serves a limited number of Services eg. 80/443 can replace the need for a front end firewall. If you need a front-end loadbalancer anyway (and most orgs do) why incur the performance penalty of a firewall to do the same job?
I’m not suggesting the front-end firewall be removed entirely, but that it is not used to terminate inbound sessions.
/John H
John, its a good point and will write something up sooner or later.
As a former “pin dropping” firewall engineer who also used Checkpoint in the 90s ( I’m also a Checkpoint Certified Engineer ) I think you missed mentioning a technology that I first encountered in the Gauntlet product or FWTK – application aware/specific firewalls.
Products like those sold by Palo Alto Networks for instance can easily do the same thing as my ASA-55xxs but are also smart enough to notice that someone is running telnet on port 80 … not just the default http over port 80.
I don’t know what firewalls will look like in 5 or 10 years but I hope that they aren’t just more of the same ACLs – as the Black Eyed Peas sing “your so 2000 & late”
Robertr
You are right, and I did like the Cyberguard TSP before it got merged into Secure Computing and then merged into McAfee. Lets face it, you aren’t going to buy a proper firewall from McAfee are you. At the moment, firewalls are routers that don’t work with some value add around configuration management, and administrative management.
In the future, security isn’t in firewalls but in IPS and Threat Mitigation Systems. Which, I’m pleased to say, will upset most Firewall people out there today. They may have to learn something…..
Hi Greg,
I disagree, firewalls in my opinion will always be the foremost solution in permiter/DMZ defence. Most of them also include IPS functionality as standard now and as I said above, application inspection. The ASA and Check Point firewalls will both restrict web traffic to RFC compliant HTTP browsing if configured to do so, they are far from being routers that don’t work with some value add.. in my opinion.
I now work for a large network integrator who are a gold/platinum partner across many networking vendors and at present the requirement for firewalls is far outweighing IPS appliances and when IPS is sold it’s often as a firewall software or hardware module. IPS will and is becoming more prevalent but as a complement to a firewall I believe.
Ian
p.s. The site is looking good.
“can easily do the same thing as my ASA-55xxs but are also smart enough to notice that someone is running telnet on port 80″
The ASA will perform application inspection and ensure HTTP traffic is RFC compliant.. or have I missed something here?
Ian
Hi Greg,
What is your view on separate physical switches vs vlans for connectivity within the various zones?
Vendor designs will often use separate switches at each zone but, especially with distributed HA firewalls, this can quickly add up to a lot of physical devices with only 2-4 active ports. However given a (correctly configured) outside firewall should it not be safe to assume that the control plane of any (correctly configured) switch behind it should be “secure”? It would therefore be valid to use the same physical switch for outside-failover/inside-failover/internaFWl-ExternalFW connectivity, segmented using vlans?
Effecitvely the FWSM uses the same switch for all functions, but I still read documents stating that seperate switches should be used.
I have read some interesting posts on your blog and would be keen to see your response.
Cheers
Dave
The idea of using separate switches has its roots in the fact that VLAN’s are inherently insecure. You can configure switches to be secure however, which removes the risk. See this white paper published in 2003 http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/tech/stake_wp.pdf for full details about the underlying problem.
I believe that the Security Industry has not really grown up and moved on from 1999 when the issue was ‘publicised’. The IEEE clearly identified the problem in its documents and the risk was deemed acceptable. Since Cisco now has features that block VLAN hopping (VACLs, set Default Untagged VLAN, PVLANs etc etc) the risk is easily mitigated.
Exploiting VLANs requires that you compromise a server, elevate or gain root/administrator level access, download and install software and commence VLAN injection attacks. OK, not so hard but requires a high level of competence on the attacker’s part, AND a low level of competence on the administrator’s part.
The underlying problem is that Security People are often inflexible, and unreasonable. The ‘VLAN insecurity’ topic is like fundamental faith issue. I don’t agree with it, and don’t believe that selling separate switches (that are low MTBF, low reliability, low performance, and generally poor operational practice) improves the risk profile. It does shift the risk profile from the Security side to Operational side since multiple switches means more failures. I would always make the point that operational failure is a greater risk than security (your mileage may vary).
Although there are reasons where using individual switches might be a good idea, this would be a truly exceptional corner case, rather than standard best practice.
Why do you want to have the DMZ’s on the internal firewall, when you claim that two firewalls are not more secure than one? Isn’t the eksternal firewall waste then? All the rules on the eksternal firewall have to be applied on the internal as well?
Well, it also true that if the DMZ was on the external firewall then rules would have to be on two firewalls anyway. Further more, the rules from internal network are more complicated than those from the external side because of network management and administration.
While I don’t specifically agree that two firewalls are more secure than one, its a very common idea. The original purpose was to have each firewall controlled by a different team or people. In practice, this doesn’t work.
Interesting read!
You state: “My recommendation is always to use a Cisco ASA as the external firewall and Juniper NetScreen as the internal firewall.”
I’d be interested in knowing why you recommend the above. Is there something inherently better about putting the ASA externally and the NetScreen internally?
I can understand recommending the ASA based on your Cisco background, but why do you recommend the NetScreen? Are there others you have tested?
Also, based on your reply to one of the comments, I get the impression you would have no problem putting an internal VLAN and DMZ VLAN on the same switch. Is this still your position as I didn’t pick up on that in the third Packet Pushers podcast?
Thanks
JR
The internal firewall is the critical firewall since it connect your DMZs to your core network and thats where you end up doing ‘unusual’ technical things.. The external firewall is more likely to be a simple packet filter, or dumb firewall and this is well suited to the ASA function (as I’ve said before, Cisco doesn’t get Security).
The Juniper NetScreenOS is far superior to ASA and has better routing, easier administration, better performance. However. the NetScreen are being replaced with the new device and you may need to do some research to check it’s what you need. I have been told it’s just as good as NetScreen but I personally can’t say that I know.
Excellent article and, nice illustrations!
The article was probably aimed at a logical design level above this but I am struggling to find a best practice guide for IP addressing in DMZs. In the preferred scenario (where the DMZ hangs off the internal firewall), would you give a server a private address range then NAT at the external firewall? For example, a web proxy for internal clients would be hosted in the dmz with a private IP address and then it would be NAT’d outbound?
Thanks,
Duncan
Excellent article thanks a lot for your great work on your blog.
I do agree with your point of view and Internal Firewall DMZ is the best. Still, a question came to my mind:
In your example, there is only one access to/from external zone. How would you manage the multiple ISPs, and the fact you have links dedicated to certain services hosted in DMZ ?
Ex: You host web servers in a DMZ at the Internal Firewall, and let’s say a Web proxy for users web access in another DMZ on the same firewall. Web servers have to talk with ISP A, and wou want your users to browse the web through ISP B.
From a routing point of view, you must define the next hop based on the source, so policy based routing, which by experience on screenos and ios is not a valuable solution (side effects and/or difficult to maintain and troubleshoot at a certain point). Or maybe some equipment/firewall can have several routing instance / routing table and DMZs could use different ones ? Or maybe another solution that do not come to my mind ?
Of course, if you use DMZ on your external firewall, the problem is solved, with all the cons of doing this you have described.
Let me know what you think and thanks again for the article.