Giving your users access to the Internet is relatively simple. You do, obviously, have to put security measures in place (usually a firewall) to protect them from the outside world but that is easy to cater for. The trouble arises when you have to allow total strangers access to your company’s services and still protect them.

Whether it’s an online ordering service, a public information website, or a customised database for partners, you have to make sure that they can reach those services, do only what they are supposed to and not gain access to the rest of your internal network.

If you could create two discrete networks, for internal and external use, that would be fine. But your own users will have to access those public-facing services too, so you have to link them somehow. And that’s where it gets to be a pain.

So you have to build a half-way house — a network that is (relatively) open to the outside world, can also be reached from the internal one, but which remains isolated from your private network. This is called a DMZ (short for ‘demilitarised zone’) and it is a network that can be built in several ways. But what are the risks involved?

Network design
The most basic design involves putting the DMZ outside the firewall that protects your internal users, so that it is exposed to the public Internet connections. The firewall prevents traffic from the DMZ getting to the private network but allows your internal hosts to access the Internet. This is not recommended for two reasons. Firstly, you can offer very little protection to your ‘public’ servers, apart from what you can do on the router that connects to your ISP. Secondly, all traffic between your users and the Internet has to flow over the DMZ, which sits directly in the path. If a DMZ server should be compromised, it would be easier for a hacker to carry out, for instance, a ‘man-in-the-middle’ attack on your internal-to-Internet traffic.

A marginally more secure design is to still have the DMZ outside the firewall, but, instead of it being in the direct switch path between private and public networks, have it connected on a separate interface on the Internet-connected router. This means that while it is still only secured by that router, traffic from your private network no longer has to traverse the DMZ, so the firewall is itself more protected.

However, more secure, and hopefully more common, is the three-legged firewall design. Here, the DMZ does hide behind the firewall, which has three connections. In order of increasing security, these link to the Internet, the DMZ, and the private network. This allows for some basic security to be carried out by the Internet router, and then the full power of firewall rules to restrict traffic both to the DMZ, and, to a greater extent, your internal environment. Typically you configure each firewall interface to have a security ‘level’, and then allow traffic to flow from a more secure interface to a lesser one, but not vice versa, thus protecting your most secure network — your internal one — from those outside.

A further layer of security can be created by ‘stacking’ firewalls; having the DMZ behind one firewall, then another behind it to further secure your private network. This adds to the security, the complexity and the cost (companies that deploy such a design often go one step further and insist that the two firewalls are from different manufacturers, to really give potential hackers a hard time). This design does have one drawback in that again the DMZ is in the private-to-Internet path, which does lend itself more to hijack-type attacks.

Mitigation techniques
One way to mitigate the effect of someone compromising one of your servers is to use multiple DMZs. There’s no reason (apart from simplicity of configuration) why you need only have one, as long as your firewall can support enough interfaces. You could create several DMZs, with varying levels of security, depending on the services they support. With each logically isolated from the others, the impact of one becoming affected by malicious influences is lessened.

Carrying this to extremes, one DMZ per server is perhaps the most secure option. But it’s also the least manageable and really not practical. An alternative is to segregate ports within each DMZ, by configuring Private VLANs (or Super VLANs to use an alternative name), that in effect logically isolate each switch port within the VLAN from all others, except the link to the firewall.

Mail servers
One last point. We have said that firewalls should permit traffic from the most secure network to the less secure ones but not the other way round. In other words, from your internal network to either the DMZ or Internet, but from the DMZ only to the Internet not back into the internal network.

This isn’t strictly true. Obviously you’ll have to let the responses back in, otherwise there’s no traffic flow, but that is usually based on established flows. The one time you can’t have this is if you have your mail server out on the DMZ (which seems a sensible place to house it). Unless you have some complicated pull mechanism from the clients, you have to allow the mail server to originate traffic flows into your private internal network.

Either you need to keep the server itself on the internal network, and site a proxy server on the DMZ so that the server can initiate transfer, or you need to make sure your firewall understands things like mail servers and has something inbuilt to cope (often known as fixup support, such as you might also need to pass Voice over IP traffic over a firewall without requiring huge holes punched in its security).

The mail server scenario may not be the only one, depending on the services you run on your publicly visible servers, if they have to signal back to another corporate server. Make sure you know how each application works, before deployment, or you may be forced to open up your security to allow it to work and risk the integrity of your network.