Using Your Firebox’s Optional Interface

by Fred Avolio , Avolio Consulting, Inc.

If you use a Firebox, you’ve seen the Ethernet ports on the back. You know that the port labeled Trusted is for “us,” or “inside.” External is for the untrusted “them” on the “outside.” There is also a port marked Optional, but when it comes to securing our Internet-facing servers, you might consider it Essential.

Optional network defined

The network interface labeled Optional should be used (but doesn’t have to be — more on that later) to access a network called a DMZ, or sometimes “service network.” Dr. Steve Bellovin of Bell Labs, who co-authored the seminal tome Firewalls and Internet Security, coined the term DMZ from demilitarized zone, a phrase familiar to those of us who remember the Vietnam War. In January 1999, on the “firewall-wizards” mailing list, he defined a DMZ in this way: “Conceptually, the DMZ is a partially-protected zone — not exposed to the full fury of the Internet, but not fully behind the firewall. The point, in general, is not to protect the service hosts — they should be capable of protecting themselves … — but to allow the inside firewall component to make certain assumptions about the impossibility of outsiders forging DMZ addresses. That, in turn, allows more stringent access controls through the inside component.”

The rest of this article explores his definition. In our discussion, we’ll use the terms DMZ and Optional interchangeably.

“A partially-protected zone”

What does “not fully behind the firewall” signify? With the Firebox, you can protect the DMZ as well as you protect the Trusted network. But, typically, you will configure more restrictive rules for access to your Trusted network than to the Optional network. So, while you might not allow, for example, HTTP traffic from anywhere on the External to anywhere on the Trusted, you probably would allow it from anywhere to the Web servers on the Optional.

What to put on the DMZ and what to allow

Okay, we’ve established that the DMZ is a “not fully trusted, not fully untrusted” network. That makes it a good place to put your Internet-facing Web server. If you have an FTP server meant for people outside your network to reach, it should also go here. Your e-mail gateway to the Internet should go here, too. Oh, I know you allow SMTP connections from anywhere on the Internet through your Firebox to your mail hub on your Trusted net (and only to your mail hub, right?). But for those of us who are paranoid (security professionals, which should include firewall administrators), we feel better knowing that an Internet-reachable system is separated from the Trusted net by a firewall. With a DMZ, that is logically and physically what we get.

Picture the flow of packets. Someone from the Internet accesses our Web server, as anyone can. The Firebox makes sure that only HTTP and SSL packets can get through, because those are the only kinds of packets that should be coming from a legitimate user of our Web site. If he turns out to be an attacker, he may launch an attack against our sturdy Firebox since he can, of course, reach it. He may attempt to attack our Web server, but he is limited to using HTTP and SSL, since that is all we allow through from the outside (and we allow them to our Web server only).

Let’s dwell on this point for a moment. When we configure our Firebox, we should be as specific as possible with our rules. So, we specify the IP address (or addresses) of the Web server. And we deny everything except that which is needed for Web service. This limits the attack vectors, making an attacker’s job more difficult.

Now, back to our attacker. Suppose he is successful and gains a foothold on our Web server. (No, I don’t know how, but just suppose. This is what we do in risk analysis.) What’s the situation of our Trusted net? We still have a firewall between the attacker and us, protecting us.

Can you picture that in your mind? This is why the “allow” and “deny” rules for DMZ (Optional) to Trusted are just as important as those from External to Trusted. We would never have a rule from External to Trusted for inbound connections of any kind that permitted connections from “Any” to “Any.” Neither should we from the DMZ to the Trusted.

Why not? First of all, unlike the vast Internet, we have a limited number of hosts on the DMZ. So, there should be no “Any” rules here. Our rules on what to allow from the DMZ should always specify the IP addresses of the hosts on the DMZ. Second, since the hosts on the DMZ are set up to be reachable from “Any” on the Internet, we want to treat them as untrusted from the point of view of the Trusted net.

Configuring this correctly delivers tremendous benefit for just a little planning. So, draw a map or a table. Figure out what must be allowed from the DMZ to the Trusted net. Nothing should be allowed that is initiated from the Web server on the DMZ. The same should go for an FTP server. The mail hub needs to be able to initiate SMTP connections to the internal mail hubs (on the Trusted net), and probably nothing else. It should not even need to access your Trusted-side DNS name servers. After all, it only needs to connect with your already-known inside mail hubs. You might even put your authentication server or certificate server on the DMZ.

Another “option”

What if you don’t have a need for a DMZ? You can still put the Optional interface to great use, allowing the Firebox to act as a simple interdepartmental firewall. As in the previous example — and as for most of our set-ups — the External interface is the Internet, and the Trusted is most of your inside network. Plug your accounting group network into the Optional slot, and configure the Firebox to protect both sides from the Internet, and you have a single firewall doing the job of two for the price of one! Since the idea of selling fewer Fireboxes won’t make my editor very happy, I’ll point out that using the Optional interface is also a great way to nest multiple Fireboxes, breaking up your corporate network into security compartments (described in ” Interdepartmental Firewalls : Where to Put Them and Why”).

Rather than making things more complex, putting the right machines on the Optional network, with the correct minimalist and granular rules, will simplify your security tasks by cutting down the attack vectors available to a potential assailant. The Firebox comes with three interfaces for a reason. For better — and ultimately, easier — security, using those interfaces smartly is more Essential than Optional. ##

References

The full text of Dr. Bellovin’s above-referenced posting is at http://list.nfr.com/pipermail/firewall-wizards/1999-January/004500.html.

Was this article useful to you? Is there a security topic you want our experts to tackle? Let us know at lsseditor@watchguard.com .

For more helpful articles, log into the LiveSecurity Archive .

Copyright© 2002, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.