Introduction

Packet Filtering routers are just one component in securing an organisation's "information assets". In today's lecture we examine "protected host" or "protected subnet" firewall architectures, where packet filtering is used to build a secure interface to the Internet.

Protected Subnet Firewall Configurations

We can think of an organisation as intrinsically having two "zones": inside (the organisation's Intranet, where the trusted workers are, and presumably not the source of security attacks) and the outside Internet, from which all evil (as well as some pretty nifty stuff) eminates. A secure firewall architecture designates a third zone, neither inside nor outside but interposed between them. This has been given a variety of names in the literature, typically "De-Militarised Zone (DMZ)", "Stub Network, "Perimeter Network" and Protected Subnet.

This means that two levels of security are now involved: protecting systems in the DMZ, and protecting inside systems. Typically only specially security-hardened systems, called bastion hosts are in the DMZ. The system diagram is:

Technical note: this "classical" diagram represents the DMZ as a traditional shared-medium LAN, not a common network structure these days.

Configuration of the DMZ-based Firewall Architecture

• The "exterior" (or "border", R1) router is commonly an Access Router. For example, in many Small & Medium Enterprises (SMEs), the access router includes a DSL modem, which interfaces to an ISP's network on the "outside", and may include a small (few ports) built-in Ethernet switch on the "inside", making it simple to build a DMZ-based system. This router usually doesn't play a major part in packet filtering, but may have other important functions, see later.^[1]
• The interior router (R2) does the "heavy lifting" in terms of packet filtering.
  • In general, all incoming connection requests from the external Internet will be blocked at R2.
  • The organisation may permit "inside systems" to have connection-level access (maybe for a small number of application protocols) to the external Internet. This may be problematic, because incoming IP packets have to flow across the DMZ, so simple IP address-based packet filtering isn't possible.
  • Most outgoing connections to the bastion host are permitted, so it can act as an application gateway -- eg, relaying SMTP email. However, few (or no) connections may be permitted from the bastion to the interior network. This protects the internal hosts from attack should the bastion be compromised.

One useful function which can be performed by the exterior router (R1) is that of filtering both incoming and outgoing packets on IP source address, see last lecture.

The Bastion Host

The bastion host (or hosts -- it's perfectly reasonable to have more than one) would normally serve as the organisation's Web, FTP, and SMTP server, and perhaps other services as well. In effect, the bastion is the "public face" of the organisation.

It's obvious that the bastion should be highly secure. In a later lecture, we examine issues of host security in more detail. For the moment, the following are worth noting:

• When building a "proactively-secure" bastion host, the hardware, OS software and physical location should be the subject of a proper "engineering analysis". For example, some operating systems (and software houses) have a very poor security record, and would not be chosen in any rational analysis. Others have been proven to be highly secure over many years, and are obviously a better choice. A physically-secure installation and reliable hardware are equally important.
  • An important aspect of this is software auditing. Some vendors are very good at this, others not so thorough -- perhaps preferring to emphasise "features" over security and robustness. It's also important to note that "Open Source" software is not instrincally better audited than proprietory code.
• The services (ie. open ports) which are provided by the bastion host must be tightly audited and well-defined. Absolutely no "unneeded" services should be visible from the external Internet.
• Maintenance of the bastion is crucial. Security (and other) patches must be applied, logs must be regularly reviewed, etc. See later.

Application Gateways and Proxy Services

A proxy is someone who is authorised to vote on your behalf in a meeting which you cannot attend. In networking, it means any mechanism whereby a client request is passed to an intermediary (the proxy) who fulfills the request on behalf of the client. The bastion host is often used as an application gateway/proxy.

Proxies can be used for two different reasons:

Caching (ie. efficiency)

In Australia many organisations (including universities!) are charged for "download volume" of data across their Internet connection. At La Trobe University, all WWW requests are forwarded to proxy.latrobe.edu.au:8080 which keeps a cache of downloaded objects (pages, images, files, etc). This signifcantly reduces the University's networks costs. A side benefit is that Web access can appear much faster because of caching.

Security

A proxy can enforce complete separation between an "interior" network and the Internet -- they can ensure, for example, that no IP packet originating within the organisation can ever be forwarded to the outside Internet, and vice versa. This means that IP-address filtering can be configured in the interior router to only permit packets to flow to and from the bastion.

In both cases, the proxy function can be provided at either the TCP connection level (eg, outgoing connections requests are re-routed to the proxy transparently, or special software such as SOCKS is used), or at the application layer, where the TCP connection is explicitly made to the proxy server (eg, La Trobe's WWW proxy).

Private IP Addresses

If the bastion is configured as a proxy/application gateway for outgoing access to Internet services, then it's obvious that we can have complete packet-level separation between the Intranet and the external Internet.

In this situation, the machines in the Intranet obviously don't need globally valid IP Addresses -- only the gateway router and the bastion need these "real" addresses. Rather than simply "making up" IP addresses for the internal, we allocate addresses from the RFC1918 Private IP Address range. These addresses have the additional advantage that they don't cost anything -- they're free, whereas "real" IP addresses must be purchased from an ISP (or APNIC) and have signifiant costs associated.

RFC1918 addresses have especially allocated by IANA for private networks, and are not permitted to be forwarded either to, or across, the global Internet. Routing updates showing routes to addresses in these ranges are ignored. The permitted address ranges are:

10.0.0.0    ... 10.255.255.255
172.16.0.0  ... 172.31.255.255
192.168.0.0 ... 192.168.255.255

Where some "packet-level" access is required between the Intranet and the external Internet, the gateway router may be configured to perform Network Address Translation (NAT).

Network Address Translation (NAT)

This works in a similar way to packet filtering: the "border" router is required to do a little extra work. In this case, instead of making a decision to forward or drop a packet, it modifies it and forwards the modified version.

Basic idea: a packet originating from the "inside" network has its source IP address and/or source IP altered at the router. For example, suppose the gateway router has a "real" IP address of, say, 203.195.17.5) and is using private IP addresses on its inside network. An internal host using the IP address 192.168.1.20 wishes to establish a connection to an external server. Its (randomly allocated) source TCP port for the connection is 2057. The initial connection packet/segment arrives at the border router/NAT gateway, which notes the existence of a new, imminent connection. It creates a table entry which maps the source IP address and port number to an externally-known address and port, thus:

An incoming packet with destination IP 203.195.17.5 and destination TCP port 3867 is mapped back to the previous values for "inside" delivery.

Advantages and Disadvantages of NAT

NAT is an excellent technology for utilising scarce IP address space efficiently. The border router can be configured to have one (or more) externally-valid IPs and can support many connections originating from the "inside" network. It fulfills, at the IP level, a similar role to circuit-level translation technologies such as SOCKS and application-level technologies such as proxy servers.

The big advantage of NAT is that, for most practical puposes it's (almost) completely invisible to hosts in the Intranet. The Intranet host simply sends a TCP connection request to a known server in the external Internet, and it's transparently mapped as it's forwarded by the border router.

In terms of security, NAT has one big advantage: it hides the true identity and structure of the inside hosts and network from prying outside eyes. Another advantage is that it rigidly controls incoming packets: only a packet which is associated with an existing NAT translation will be forwarded to the inside.

The (slight) disadvantage of NAT is that if doesn't necessarily handle UDP packets very well -- for example, there's nothing to indicate when a UDP-based transaction is finished, so the NAT router doesn't know when to terminate its corresponding NAT translation. It's also fairly CPU and memory intensive, although this isn't nowadays considered a problem.

Dual-Homed Host "Single-Box" Architectures

In this configuration, the router is replaced with a generic host computer running a general-purpose operating system such as one of the many varieties of Unix/Linux. The situation becomes:

A Unix system, when fitted with two network interfaces (NICs) as shown here will (usually) act as a router by default. This function is explicitly disabled in the dual-homed host firewall role. Instead, the dual-homed host is used as a proxy or application gateway for any desired network services. It doesn't perform, for example, Network Address Translation, which is a packet (router) level operation.

Disadvantages of the Dual-Homed, "Single-Box" Architecture

The dual-homed host idea is very attractive, and is used by many organisations. One obvious disadvantage of the system is that its performance is potentially less than some other architectures. More seriously, it is considered to be a significant security risk!

• It's a classic "single point of failure". For example, if it comes under a Denial of Service attack which crashes the OS, then all access to the Internet is lost. There's no easy way to defend against this.
• Host security for the single Internet-visible host needs to be very strong. If an attacker gets access to the dual-homed host, then he's also probably got access to your internal network, since they're directly connected. In general, any configuration which discards the interior router (R2) is considered dangerous.
• It's regarded as quite dangerous to run general-purpose Web servers (with their attendant complexity) on the dual-homed host -- better to run a minimal version if possible, giving less chance of exposing vulnerabilities. For the same reason, only a minimal set of other services should be configured on the dual-homed host. The dual-homed should be seriously "stripped down"!
• It's regarded as highly dangerous to have actual user accounts on a dual-homed host of this kind, especially if a remote-shell type of service (such as telnet or rlogin) is available on the Internet side. Unfortunately, protocols such as POP require a login (although not a shell) account on the dual-homed host.

For these reasons the dual-homed "single box" solution is not usually recommended as a secure way of connecting an organisation to the global Internet.

Alternative DMZ Configuration #1

It's possible to gain many of the advantages of the DMZ+Bastion configuration using, instead of a "stub network", a dual-homed host with connections to both the interior and border routers. Such a configuration looks like:

The border router could, of course, be simply replaced by a "point-to-point" link to an ISP, thus moving the border router off-site to the provider's premises. This is, of course, almost identical to the dual-homed host configuration above, where the bastion host is explicitly not configured as a router: the difference here is that the interior router (R2) is explicitly used to filter packets to/from the bastion, in a similar manner to the earlier DMZ structure.

Alternative DMZ Configuration #2

A slightly different configuration "collapses" the DMZ even further by the use of a router with multiple (three or more) interfaces.

In this case, the combined border and interior router R1 is configured with port-specific packet filters, instead the simpler "forward/don't forward" rules that can be used in a two-interface router. This configuration can be as secure as the "classic" DMZ+Bastion if packet filtering is properly configured. Note that we have already seen how port-specific filtering rules are implemented in Cisco ACLs, etc.

Things You Can't Do

In previous slides, several alternative firewall architectures were presented -- in each case, various components were "merged" or "collapsed" into a single multi-purpose box. The following are NOT recommended:

• The bastion host should NEVER be merged with the interior router. The interior router is the "last line of defense" against attacks eminating from the external network -- even if the bastion host is compromised, an attacker shouldn't have access to the internal network. A merged bastion and internal router would admit this possibility.
• Only ever use ONE interior router. Two (or more) interior routers would require a separate set of packet filtering rules for each, which would be similar to one another, but different in (eg) the IP ranges. This has the potential for configuration errors. Worse: if the routers are even slightly misconfigured, they may exchange routing information via the DMZ, and decide it's a good "short cut" route between them -- so that supposedly "internal" packets are observed flowing across the DMZ. A compromised bastion could easily "packet sniff" this traffic.