13.2. Locking Down DMZ Outbound Internet Access

We've limited DMZ hosts' accessibility to the LAN, but we can lock it down a step further using egress filtering. Many DMZ hosts don't need to be able to talk out to the Internet at all, or possibly only while you are running updates or doing maintenance or need to download software.

If we can keep our DMZ hosts from accessing the Internet, we can make an attacker's job much more difficult. Many exploits rely on the target being able to pull files from a machine the attacker controls, or in the case of a worm, from the infected host. I'll use Code Red and Nimda as an example. Infected hosts exploited the vulnerability, and the remote host pulled the infected admin.dll via TFTP from the already infected host. If you were running vulnerable web servers, but did not allow TFTP traffic outbound from your webservers, you could not have been infected. (reference)

Attackers most always try to pull in a tool kit or root kit of some sort onto machines they exploit. There are ways around this, but it just makes it that much more difficult. This will merely slow down a knowledgeable attacker (who'll find a way to get in one way or another), but it could stop a script kiddie dead in their tracks and keep some worms from infecting your network.

This is not a replacement for proper patching and other security measures, it's just good practice in a defense-in-depth strategy.

How does this work?

You might be wondering how your servers will be able to serve content while not being able to talk out to the Internet. I'll use web servers as an example. When packets come in on the WAN interface through firewall rules you have entered to permit HTTP traffic, there is a state entry that permits any return traffic from that connection to traverse the firewall.

Remember this only affects the ability to initiate connections outbound, not the ability to respond to incoming traffic requests.

Recommended configuration

As with all firewall rules, limit the accessibility as much as possible. Mail servers that must send outbound mail will need to initiate connections to destination TCP port 25 to any host. If the DNS servers your DMZ hosts use reside outside of the DMZ, you'll need to allow UDP port 53 to the DNS servers being used.

I typically put in rules for upgrade purposes to permit outbound traffic to the ports required. For FreeBSD, TCP 5999 (cvsup) and TCP 80 (HTTP) will generally suffice. When I'm not upgrading the system, I use the "disable" checkbox to disable the rule, but leave it in place to easily enable it when needed. Just always remember to disable it when you're done updating the system.