Linux Server Security (2nd Edition( [Electronic resources] نسخه متنی

2.2. Types of Firewall and DMZ Architectures

In the
world of expensive commercial firewalls (the world in which I earn my
living), the term
"firewall"
nearly always denotes a single computer or dedicated hardware device
with multiple network interfaces. This definition can apply not only
to expensive rack-mounted behemoths, but also to much lower-end
solutions: network interface cards are cheap, as are PCs in general.

This is different from the old days, when a single computer typically
couldn't keep up with the processor overhead
required to inspect all ingoing and outgoing packets for a large
network. In other words, routers, not computers, used to be
one's first line of defense against network attacks.

This is no longer the case. Even organizations with high-capacity
Internet connections typically use a
multihomed firewall (whether commercial
or open source-based) as the primary tool for securing their
networks. This is possible thanks to Moore's law,
which has provided us with inexpensive CPU power at a faster pace
than the market has provided us with inexpensive Internet bandwidth.
It's now feasible for even a relatively slow PC to
perform sophisticated checks on a full T1's-worth
(1.544 Mbps) of network traffic.

2.2.1. The "Inside Versus Outside" Architecture

The most common firewall architecture one tends to see nowadays is
the one illustrated in Figure 2-1. In this diagram,
we have a packet-filtering router that acts as
the initial, but not sole, line of defense. Directly behind this
router is a "proper"
firewallin this case, a Sun SparcStation running, say, Debian
Linux with iptables. There is no direct connection from the Internet
or the "external" router to the
internal network; all traffic to or from it must pass through the
firewall.

In my opinion, all external routers should use some level of packet
filtering, a.k.a. "Access Control
Lists" in the Cisco lexicon. Even when the next hop
inwards from such a router is a sophisticated firewall, it never
hurts to have redundant enforcement points. In fact,
when several Check Point vulnerabilities were demonstrated at a
recent Black Hat Briefings conference, no less than a Check Point
spokesperson mentioned that it's foolish to rely
solely on one's firewall, and he was right. At the
very least, your Internet-connected routers should drop packets with
non-Internet-routable source or destination IP addresses, as
specified in RFC 1918 (
What's missing or wrong about Figure 2-1? (I said this architecture is common, not
perfect!) Public services such as SMTP (email),
Domain Name Service (DNS),
and HTTP (WWW) must either be sent through the firewall to internal
servers or hosted on the firewall itself. Passing such traffic to an
internal server doesn't directly expose other
internal hosts to attack, but it does magnify the consequences of the
internal server being compromised.

While hosting public services on the
firewall isn't necessarily
a bad idea on the face of it (what could be a more secure server
platform than a firewall?), the performance issue should be obvious:
the firewall should be allowed to use all its available resources for
inspecting and moving packets.

Furthermore, even a painstakingly well-configured and patched
application can have unpublished vulnerabilities. (All
vulnerabilities start out unpublished.) The ramifications of such an
application being compromised on a firewall are frightening.
Performance and security, therefore, are impacted when you run any
service on a firewall.

Where, then, to put public services so that they
don't directly or indirectly expose the internal
network and don't hinder the
firewall's security or performance? Answer: in a DMZ
(demilitarized zone) network.

2.2.2. The "Three-Homed Firewall" DMZ Architecture

At its simplest, a DMZ is any network reachable by the public but
isolated from one's internal network. Ideally,
however, a DMZ is also protected by the firewall. Figure 2-2 shows my preferred firewall/DMZ architecture.

Figure 2-2. Single-firewall DMZ architecture

In Figure 2-2, we have a
three-homed host as our firewall. Hosts
providing publicly accessible services are in their own network with
a dedicated connection to the firewall, and the rest of the corporate
network faces a different firewall interface. If configured properly,
the firewall uses different rules in evaluating traffic:

From the Internet to the DMZ From the DMZ to the Internet From the Internet to the internal network From the internal network to the Internet From the DMZ to the internal network From the internal network to the DMZ
This may sound like more administrative overhead than that associated
with internally hosted or firewall-hosted services, but
it's potentially much simpler since the DMZ can be
treated as a single logical entity. In the case of internally hosted
services, each host must be considered individually (unless all the
services are located on a single IP network whose address is
distinguishable from other parts of the internal network).

2.2.3. A Weak Screened-Subnet Architecture

Other architectures are sometimes used, and Figure 2-3 illustrates one of them. This version of the
screened-subnet
architecture made a lot of sense back when routers were better at
coping with high-bandwidth data streams than multihomed hosts were.
However, current best practice is not to rely
exclusively on routers in one's firewall
architecture.

Figure 2-3. Screened-subnet DMZ architecture

2.2.4. A Strong Screened-Subnet Architecture

The architecture in Figure 2-4 is therefore better: both the DMZ and the
internal networks are protected by full-featured firewalls that are
almost certainly more sophisticated than routers.

The weaker screened-subnet design in Figure 2-3 is
still used by some sites, but in my opinion, it places too much trust
in routers. This is problematic for several reasons.

First, routers are often under the control of a different person from
the firewall, and this person may insist that the router have a weak
administrative password, weak access-control lists, or even an
attached modem so that the router's vendor can
maintain it! Second, some
routers are more
hackable than well-configured computers (for example, by default,
they nearly always support remote administration via Telnet, an
insecure service).

Finally, packet filtering alone is a crude and incomplete means of
regulating network traffic. Simple packet filtering seldom suffices
when the stakes are high, unless performed by a well-configured
firewall with additional features and comprehensive logging.

The architecture in Figure 2-4 is useful when very
high volumes of traffic must be supported, as it addresses a
significant drawback of the three-homed firewall architecture in
Figure 2-2: if one firewall handles all traffic
between three networks, a large volume of traffic between any two of
those networks will negatively impact the third
network's ability to reach either. A screened-subnet
architecture distributes network load better.

It also lends itself well to
heterogeneous firewall
environments. For example, a packet-filtering firewall with high
network throughput might be used as the
"external" firewall; an
application-gateway (proxying) firewall, arguably more secure but
probably slower, might then be used as the
"internal" firewall. In this way,
public web servers in the DMZ would be optimally available to the
outside world, and private systems on the inside would be most
effectively isolated.