Chapter 5. Firewall Technologies
In Part I, we introduced Internet firewalls and summarized what they can and cannot do to improve network security. In this chapter, we present major firewalls concepts. What are the terms you will hear in discussions of Internet firewalls? What are the components that can be put together to build these common firewall architectures? How do you evaluate a firewall design? In the remaining chapters of this book, we’ll describe these components and architectures in detail.
Some Firewall Definitions
You may be familiar with some of the following firewall terms, and some may be new to you. Some may seem familiar, but they may be used in a way that is slightly different from what you’re accustomed to (though we try to use terms that are as standard as possible). Unfortunately, there is no completely consistent terminology for firewall architectures and components. Different people use terms in different — or, worse still, conflicting — ways. Also, these same terms sometimes have other meanings in other networking fields; the following definitions are for a firewalls context.
Here are some very basic definitions; we describe these terms in greater detail elsewhere:
- Firewall
A component or set of components that restricts access between a protected network and the Internet, or between other sets of networks.
- Host
A computer system attached to a network.
- Bastion host
A computer system that must be highly secured because it is vulnerable to attack, usually because it is exposed to the Internet and is a main point of contact for users of internal networks. It gets its name from the highly fortified projections on the outer walls of medieval castles.[1]
- Dual-homed host
A general-purpose computer system that has at least two network interfaces (or homes).
- Network address translation (NAT)
A procedure by which a router changes data in packets to modify the network addresses. This allows a router to conceal the addresses of network hosts on one side of it. This technique can enable a large number of hosts to connect to the Internet using a small number of allocated addresses or can allow a network that’s configured with illegal or unroutable addresses to connect to the Internet using valid addresses. It is not actually a security technique, although it can provide a small amount of additional security. However, it generally runs on the same routers that make up part of the firewall.
- Packet
- Packet filtering
The action a device takes to selectively control the flow of data to and from a network. Packet filters allow or block packets, usually while routing them from one network to another (most often from the Internet to an internal network, and vice versa). To accomplish packet filtering, you set up a set of rules that specify what types of packets (e.g., those to or from a particular IP address or port) are to be allowed and what types are to be blocked. Packet filtering may occur in a router, in a bridge, or on an individual host. It is sometimes known as screening.[2]
- Perimeter network
A network added between a protected network and an external network, in order to provide an additional layer of security. A perimeter network is sometimes called a DMZ, which stands for De-Militarized Zone (named after the zone separating North and South Korea).
- Proxy
A program that deals with external servers on behalf of internal clients. Proxy clients talk to proxy servers, which relay approved client requests on to real servers, and relay answers back to clients.
- Virtual private network (VPN)
A network where packets that are internal to a private network pass across a public network, without this being obvious to hosts on the private network. In general, VPNs use encryption to protect the packets as they pass across the public network. VPN solutions are popular because it is often cheaper to connect two networks via public networks (for instance, getting them both Internet connections) than via private networks (like traditional leased-line connections between the sites).
The next few sections briefly describe the major technologies associated with firewalls: packet filtering, proxy services, network address translation, and virtual private networks.
There are legitimate questions about how to distinguish between packet filtering and proxying, particularly when dealing with complex packet filtering systems and simple proxies. Many people believe that systems that pay attention to individual protocols and/or modify packets should not be considered packet filters, and may even refer to these systems as transparent proxies. In fact, these systems don’t behave much like older, simpler packet filtering systems, and it’s a good idea not to apply generalizations about packet filtering to them blindly. On the other hand, they don’t behave much like proxying systems, either.
Similarly, a number of proxying systems provide generic proxies, which essentially function like packet filters, accepting all traffic to a given port without analyzing it. It’s advisable to pay close attention to the individual technology a product uses, without making assumptions based on whether it claims to be a packet filter or a proxy. However, many systems still are clearly packet filters or clearly proxies, so it is worth understanding what these technologies are and how they work.
Packet Filtering
Packet filtering systems route packets between internal and external hosts, but they do it selectively. They allow or block certain types of packets in a way that reflects a site’s own security policy, as shown in Figure 5.1. The type of router used in a packet filtering firewall is known as a screening router.
As we discuss in Chapter 8, every packet has a set of headers containing certain information. The main information is:
IP source address
IP destination address
Protocol (whether the packet is a TCP, UDP, or ICMP packet)
TCP or UDP source port
TCP or UDP destination port
ICMP message type
Packet size
The router can also look past the packet headers at data further on in the packet; this allows it, for instance, to filter packets based on more detailed information (like the name of the web page that somebody is requesting) and to verify that packets appear to be formatted as expected for their destination port. The router can also make sure that the packet is valid (it actually is the size that it claims to be and is a legal size, for instance), which helps catch a number of denial of service attacks based on malformed packets.
In addition, the router knows things about the packet that aren’t reflected in the packet itself, such as:
The interface the packet arrives on
The interface the packet will go out on
Finally, a router that keeps track of packets it has seen knows some useful historical facts, such as:
Whether this packet appears to be a response to another packet (that is, its source was the destination of a recent packet and its destination is the source of that other packet)
How many other packets have recently been seen to or from the same host
Whether this packet is identical to a recently seen packet
If this packet is part of a larger packet that has been broken into parts (fragmented)
To understand how packet filtering works, let’s look at the difference between an ordinary router and a screening router.
An ordinary router simply looks at the destination address of each packet and picks the best way it knows to send that packet towards that destination. The decision about how to handle the packet is based solely on its destination. There are two possibilities: the router knows how to send the packet towards its destination, and it does so; or the router does not know how to send the packet towards its destination, and it forgets about the packet and returns an ICMP “destination unreachable” message, to the packet’s source.
A screening router, on the other hand, looks at packets more closely. In addition to determining whether or not it can route a packet towards its destination, a screening router also determines whether or not it should. “Should” or “should not” are determined by the site’s security policy, which the screening router has been configured to enforce.
Packet filtering may also be performed by devices that pay attention only to “should” and “should not” and have no ability to route. Devices that do this are packet filtering bridges. They are rarer than packet filtering routers, mostly because they are dedicated security devices that don’t provide all the other functions that routers do. Most sites would rather add features to routers that they need anyway, instead of adding a dedicated device. However, being a dedicated device provides advantages for packet filtering bridges; in particular, they are harder to detect and attack than packet filtering routers. They provide the same general features that we discuss for packet filtering routers.
Once it has looked at all the information, a straightforward packet filtering router can do any of the following things:
Send the packet on to the destination it was bound for.
Drop the packet—just forget it, without notifying the sender.
Reject the packet—refuse to forward it, and return an error to the sender.
Log information about the packet.
Set off an alarm to notify somebody about the packet immediately.
More sophisticated routers might also be able to do one or more of these things:
Modify the packet (for instance, to do network address translation).
Send the packet on to a destination other than the one that it was bound for (for instance, to force transactions through a proxy server or perform load balancing).
Modify the filtering rules (for instance, to accept replies to a UDP packet or to deny all traffic from a site that has sent hostile packets).
The fact that servers for particular Internet services reside at certain port numbers lets the router block or allow certain types of connections simply by specifying the appropriate port number (e.g., TCP port 23 for Telnet connections) in the set of rules specified for packet filtering. (Chapter 8, describes in detail how you construct these rules.)
Here are some examples of ways in which you might program a screening router to selectively route packets to or from your site:
Block all incoming connections from systems outside the internal network, except for incoming SMTP connections (so that you can receive electronic mail).
Block all connections to or from certain systems you distrust.
Allow electronic mail and FTP services, but block dangerous services like TFTP, the X Window System, RPC, and the “r” services (rlogin, rsh, rcp, etc.). (See Chapter 13, for more information.)
Packet filtering devices that keep track of packets that they see are frequently called stateful packet filters (because they keep information about the state of transactions). They may also be called dynamic packet filters because they change their handling of packets dynamically depending on the traffic they see. Devices that look at the content of packets, rather than at just their headers, are frequently called intelligent packet filters. In practice, almost all stateful packet filters also are capable of looking at the contents of packets, and many are also capable of modifying the contents of packets, so you may see all these capabilities lumped together under the heading “stateful packet filtering”. However, something can legitimately be called a “stateful packet filter” without having the ability to do advanced content filtering or modification.
A packet filtering system is also a logical place to provide virtual private network or network address translation services. Since the packet filter is already looking at all of the packets, it can easily identify packets that are intended for a destination that is part of the virtual private network, encrypt those packets, and encapsulate them in another packet bound for the appropriate destination.
Advantages of Packet Filtering
Packet filtering has a number of advantages.
One screening router can help protect an entire network
One of the key advantages of packet filtering is that a single, strategically placed packet filtering router can help protect an entire network. If only one router connects your site to the Internet, you gain tremendous leverage on network security, regardless of the size of your site, by doing packet filtering on that router.
Simple packet filtering is extremely efficient
Because simple packet filtering requires paying attention only to a few packet headers, it can be done with very low overhead. Proxying is a fairly time-consuming operation, and adding proxying means directing connections through another program, usually on a machine that otherwise wouldn’t be necessary to the routing process. Packet filtering takes place on a machine that was already in the critical path, and introduces a much smaller delay.
However, there is no free lunch; the more work your packet filters do, the slower they will be. If your packet filters behave like proxies, doing complicated data-driven operations that require keeping track of multiple packets, they will tend to perform like proxies as well.
Packet filtering is widely available
Packet filtering capabilities are available in many hardware and software routing products, both commercial and freely available over the Internet. Most sites already have packet filtering capabilities available in the routers they use.
Most commercial router products include packet filtering capabilities. Packet filtering capabilities are also available for a number of general-purpose computers. These are discussed further in Chapter 8.
Disadvantages of Packet Filtering
Although packet filtering provides many advantages, there are some disadvantages to using packet filtering as well.
Current filtering tools are not perfect
Despite the widespread availability of packet filtering in various hardware and software packages, packet filtering is still not a perfect tool. The packet filtering capabilities of many of these products share, to a greater or lesser degree, common limitations:
The packet filtering rules tend to be hard to configure. Although there is a range of difficulty, it mostly runs from slightly mind-twisting to brain-numbingly impossible.
Once configured, the packet filtering rules tend to be hard to test.
The packet filtering capabilities of many of the products are incomplete, making implementation of certain types of highly desirable filters difficult or impossible.
Like anything else, packet filtering packages may have bugs in them; these bugs are more likely than proxying bugs to result in security problems. Usually, a proxy that fails simply stops passing data, while a failed packet filtering implementation may allow packets it should have denied.
Packet filtering reduces router performance
Doing packet filtering places a significant extra load on a router. As we discussed previously, more complex filters place more load on the router, but in some cases, simply turning on packet filtering on a given interface can also cost you a lot of performance on some routers, because the filtering is incompatible with certain caching strategies commonly used for performance enhancement. Cisco’s “fastpath” functionality is an example of this; normally, fastpath can perform basic routing functions completely on the interface card, without involving the main CPU, but using some forms of filtering requires involving the main CPU for each packet, which is much slower. What enables/disables fastpath depends on the hardware and software version.
Some policies can’t readily be enforced by normal packet filtering routers
The information that a packet filtering router has available to it doesn’t allow you to specify some rules you might like to have. For example, packets say what host they come from but generally not what user. Therefore, you can’t enforce restrictions on particular users. Similarly, packets say what port they’re going to but not what application; when you enforce restrictions on higher-level protocols, you do it by port number, hoping that nothing else is running on the port assigned to that protocol. Malicious insiders can easily subvert this kind of control.
This problem is eased by using more intelligent packet filters; however, in each case, you have to give up some of the advantages of normal packet filtering. For instance, a packet filter can insist that users authenticate themselves before sending packets, and then it can filter packets by username. However, this removes the transparency advantage of normal packet filtering. A packet filter can also do protocol validity checking, but this is less than perfect and also increases filtering overhead.
Proxy Services
In general, a proxy is something or someone who does something on somebody else’s behalf. For instance, you may give somebody the ability to vote for you by proxy in an election.
Proxy services are specialized application or server programs that take users’ requests for Internet services (such as FTP and Telnet) and forward them to the actual services. The proxies provide replacement connections and act as gateways to the services. For this reason, proxies are sometimes known as application-level gateways.[3] In this book, when we are talking about proxy services, we are specifically talking about proxies run for security purposes, which are run on a firewall host: either a dual-homed host with an interface on the internal network and one on the external network, or some other bastion host that has access to the Internet and is accessible from the internal machines.
You will also run into proxies that are primarily designed for network efficiency instead of for security; these are caching proxies, which keep copies of the information for each request that they proxy. The advantage of a caching proxy is that if multiple internal hosts request the same data, the data can be provided directly by the proxy. Caching proxies can significantly reduce the load on network connections. There are proxy servers that provide both security and caching; in general, they are better at one purpose than the other.
Proxy services sit, more or less transparently, between a user on the inside (on the internal network) and a service on the outside (on the Internet). Instead of talking to each other directly, each talks to a proxy. Proxies handle all the communication between users and Internet services behind the scenes.
Transparency is the major benefit of proxy services. It’s essentially smoke and mirrors. To the user, a proxy server presents the illusion that the user is dealing directly with the real server. To the real server, the proxy server presents the illusion that the real server is dealing directly with a user on the proxy host (as opposed to the user’s real host).
How do proxy services work? Let’s look at the simplest case, where we add proxy services to a dual-homed host. (We’ll describe these hosts in some detail in Section 6.1.2 in Chapter 6.)
Tip
Proxy services are effective only when they’re used in conjunction with a mechanism that restricts direct communications between the internal and external hosts. Dual-homed hosts and packet filtering are two such mechanisms. If internal hosts are able to communicate directly with external hosts, there’s no need for users to use proxy services, and so (in general) they won’t. Such a bypass probably isn’t in accordance with your security policy.
As Figure 5.2 shows, a proxy service requires two components: a proxy server and a proxy client. In this illustration, the proxy server runs on the dual-homed host (as we discuss in Chapter 9, there are other ways to set up a proxy server). A proxy client is a special version of a normal client program (e.g., a Telnet or FTP client) that talks to the proxy server rather than to the “real” server out on the Internet; in some configurations, normal client programs can be used as proxy clients. The proxy server evaluates requests from the proxy client and decides which to approve and which to deny. If a request is approved, the proxy server contacts the real server on behalf of the client (thus the term proxy) and proceeds to relay requests from the proxy client to the real server, and responses from the real server to the proxy client.
In some proxy systems, instead of installing custom client proxy software, you’ll use standard software but set up custom user procedures for using it. (We’ll describe how this works in Chapter 9.)
There are also systems that provide a hybrid between packet filtering and proxying where a network device intercepts the connection and acts as a proxy or redirects the connection to a proxy; this allows proxying without making changes to the clients or the user procedures.
The proxy server doesn’t always just forward users’ requests on to the real Internet services. The proxy server can control what users do because it can make decisions about the requests it processes. Depending on your site’s security policy, requests might be allowed or refused. For example, the FTP proxy might refuse to let users export files, or it might allow users to import files only from certain sites. More sophisticated proxy services might allow different capabilities to different hosts, rather than enforcing the same restrictions on all hosts.
Some proxy servers do in fact just forward requests on, no matter what they are. These may be called generic proxies or port forwarders. Programs that do this are providing basically the same protections that you would get if you had a packet filter in place that was allowing traffic on that port. You do not get any significant increase in security by replacing packet filters with proxies that do exactly the same thing (you gain some protection against malformed packets, but you lose by adding an attackable proxying program).
Some excellent software is available for proxying. SOCKS is a proxy construction toolkit, designed to make it easy to convert existing client/server applications into proxy versions of those same applications. The Trusted Information Systems Internet Firewall Toolkit (TIS FWTK) includes proxy servers for a number of common Internet protocols, including Telnet, FTP, HTTP, rlogin, X11, and others; these proxy servers are designed to be used in conjunction with custom user procedures. See the discussion of these packages in Chapter 9.
Many standard client and server programs, both commercial and freely available, now come equipped with their own proxying capabilities or with support for generic proxy systems like SOCKS. These capabilities can be enabled at runtime or compile time.
Most proxy systems are used to control and optimize outbound connections; they are controlled by the site where the clients are. It is also possible to use proxy systems to control and optimize inbound connections to servers (for instance, to balance connections among multiple servers or to apply extra security). This is sometimes called reverse proxying.
Advantages of Proxying
There are a number of advantages to using proxy services.
Proxy services can be good at logging
Because proxy servers can understand the application protocol, they can allow logging to be performed in a particularly effective way. For example, instead of logging all of the data transferred, an FTP proxy server can log only the commands issued and the server responses received; this results in a much smaller and more useful log.
Proxy services can provide caching
Since all requests are passing through the proxy service anyway, the proxy can provide caching, keeping local copies of the requested data. If the number of repeat requests is significant, caching can significantly increase performance and reduce the load on network links.
Proxy services can do intelligent filtering
Since a proxy service is looking at specific connections, it is frequently able to do filtering more intelligently than a packet filter. For instance, proxy services are much more capable of filtering HTTP by content type (for instance, to remove Java or JavaScript) and better at virus detection than packet filtering systems.
Proxy systems can perform user-level authentication
Because a proxy system is actively involved in the connection, it is easy for it to do user authentication and to take actions that depend on the user involved. Although this is possible with packet filtering systems, it is much more difficult.
Proxy systems automatically provide protection for weak or faulty IP implementations
As a proxy system sits between a client and the Internet, it generates completely new IP packets for the client. It can therefore protect clients from deliberately malformed IP packets. (You just need a proxy system that isn’t vulnerable to the bad packets!)
Disadvantages of Proxying
There are also some disadvantages to using proxy services.
Proxy services lag behind nonproxied services
Although proxy software is widely available for the older and simpler services like FTP and Telnet, proven software for newer or less widely used services is harder to find. There’s usually a distinct lag between the introduction of a service and the availability of proxying servers for it; the length of the lag depends primarily on how well the service is designed for proxying. This makes it difficult for a site to offer new services immediately as they become available. Until suitable proxy software is available, a system that needs new services may have to be placed outside the firewall, opening up potential security holes. (Some services can be run through generic proxies, which will give at least minimal protection.)
Proxy services may require different servers for each service
You may need a different proxy server for each protocol, because the proxy server may need to understand the protocol in order to determine what to allow and disallow, and in order to masquerade as a client to the real server and as the real server to the proxy client. Collecting, installing, and configuring all these various servers can be a lot of work. Again, you may be able to use a generic proxy, but generic proxies provide only the same sorts of protection and functionality that you could get from packet filters.
Products and packages differ greatly in the ease with which they can be configured, but making things easier in one place can make it harder in others. For example, servers that are particularly easy to configure can be limited in flexibility; they’re easy to configure because they make certain assumptions about how they’re going to be used, which may or may not be correct or appropriate for your site.
Proxy services usually require modifications to clients, applications, or procedures
Except for services designed for proxying, you will need to use modified clients, applications, and/or procedures. These modifications can have drawbacks; people can’t always use the readily available tools with their normal instructions.
Because of these modifications, proxied applications don’t always work as well as nonproxied applications. They tend to bend protocol specifications, and some clients and servers are less flexible than others.
Network Address Translation
Network address translation (NAT) allows a network to use one set of network addresses internally and a different set when dealing with external networks. Network address translation does not, by itself, provide any security, but it helps to conceal the internal network layout and to force connections to go through a choke point (because connections to untranslated addresses will not work, and the choke point does the translation).
Like packet filtering, network address translation works by having a router do extra work. In this case, not only does the router send packets on, but it also modifies them. When an internal machine sends a packet to the outside, the network address translation system modifies the source address of the packet to make the packet look as if it is coming from a valid address. When an external machine sends a packet to the inside, the network address translation system modifies the destination address to turn the externally visible address into the correct internal address. The network address translation system can also modify the source and destination port numbers (this is sometimes called Port and Address Translation or PAT). Figure 5.3 shows a network address translation system modifying only addresses, while Figure 5.4 shows port and address translation.
Network address translation systems can use different schemes for translating between internal and external addresses:
Allocate one external host address for each internal address and always apply the same translation. This provides no savings in address space, and it slows down connections; it is normally a temporary measure used by sites that have been using illegal address spaces but are in the process of moving to using valid addresses.
Dynamically allocate an external host address each time an internal host initiates a connection, without modifying port numbers. This limits the number of internal hosts that can simultaneously access the Internet to the number of available external addresses.
Create a fixed mapping from internal addresses to externally visible addresses, but use port mapping so that multiple internal machines use the same external addresses.
Dynamically allocate an external host address and port pair each time an internal host initiates a connection. This makes the most efficient possible use of the external host addresses.
Advantages of Network Address Translation
The main purpose of network address translation is to economize on address space, but it can also have some security advantages.
Network address translation helps to enforce the firewall’s control over outbound connections
Since individual hosts have addresses that won’t work on the external network, they require the assistance of the network address translation system to connect. If a host finds a way to connect to the Internet without going through the address translation, the connection won’t work.
Network address translation can help restrict incoming traffic
Depending on how you configure a network address translation system, it can provide stronger restrictions on incoming traffic than packet filtering. A network address translation system that’s doing dynamic translation will allow only packets that are part of a current interaction initiated from the inside. This is similar to the protection that a dynamic packet filter offers, but the changing IP addresses put stronger time constraints on attackers. Not only can they attack only certain ports, but if they wait too long, the address translation will have gone away, and the entire address will have disappeared or been given to another host.
Many people assume that all network address translation systems provide this sort of protection, but this is not true. If you configure a network address translation system to do static translations, it may provide no restrictions at all on incoming traffic. Even doing dynamic translations, the simplest implementations allocate an entire externally visible address to the internal host and translate all traffic sent to that address. This does limit the time that an attacker has, but otherwise provides no protection at all.
Network address translation helps to conceal the internal network’s configuration
The less an attacker knows about you, the better off you are. A network address translation system makes it much more difficult for an attacker to determine how many computers you have, what kind of machines they are, and how they’re arranged on the network. Note, however, that many protocols leak useful information (for instance, they may include the client’s IP address or hostname in places where the network address translation system doesn’t need to change it). When we discuss the network address translation properties of protocols, we attempt to mention leaks of this sort.
Disadvantages of Network Address Translation
While network address translation is a very useful way of conserving network address space, it presents some problems.
Dynamic allocation requires state information that is not always available
It is very easy for a network address translation system to tell whether or not a host has stopped using a TCP connection, but there’s no way to know at the packet header level whether a UDP packet is part of an ongoing conversation or is an isolated event. This means that a network address translation system has to guess how long it should keep a particular translation. If it guesses incorrectly, responses may be lost or delivered to unexpected hosts.
Embedded IP addresses are a problem for network address translation
Network address translation systems normally translate the addresses in the headers of packets (see Chapter 4, for more information about packet layout). Some protocols also hide addresses in other places, and in order to find those addresses, the network address translator has to understand the protocol enough to find and modify the address, while preserving the validity of the packet. Most network address translation systems are capable of doing this for at least some protocols (for instance, FTP) but not for all protocols.
Network address translation interferes with some encryption and authentication systems
Systems for encrypting data often attempt to ensure the integrity of the data, so that the systems that are communicating know that packets have not been tampered with in transit. Network address translation is a form of tampering with the data in transit. If the protocol that’s being translated does not protect the data that the network address translation system modifies, it will work. Otherwise, the integrity checking will be violated, and connections will fail. In most cases, protocols that do not have embedded IP addresses are compatible (the packet headers are not part of the protocol’s protected data). The major exception to this rule is IPsec, which protects the entire packet, including headers. Network address translation is almost guaranteed to fail for protocols that combine embedded IP addresses with data integrity protection.
Dynamic allocation of addresses interferes with logging
If you are logging information after the network address translation happens, the logs will show the translated addresses, and you will have to correlate the logs with information from the network address translation system to figure out what internal system is actually involved. For instance, if you have a screened subnet architecture (discussed in Chapter 6), and you are doing network address translation on the interior router, the translated addresses will be in logs from the exterior router or from a caching web proxy server on the screened subnet. Although log correlation is theoretically possible, it may be difficult, and clock synchronization will be critical.
Dynamic allocation of ports may interfere with packet filtering
Packet filtering systems pay attention to source and destination port numbers in order to try to figure out what protocol a packet should be using. Changing the source port may change the packet’s acceptability. In most cases, this is not a problem because address translation systems are translating for clients, which are usually allowed to use any port above 1023. However, if ports above 1023 are translated to ports below 1023, traffic may be dropped.
Virtual Private Networks
A virtual private network (VPN) is a way of employing encryption and integrity protection so that you can use a public network (for instance, the Internet) as if it were a private network (a piece of cabling that you control). Making a private, high-speed, long-distance connection between two sites is much more expensive than connecting the same two sites to a public high-speed network, but it’s also much more secure. A virtual private network is an attempt to combine the advantages of a public network (it’s cheap and widely available) with some of the advantages of a private network (it’s secure).
Fundamentally, all virtual private networks that run over the Internet employ the same principle: traffic is encrypted, integrity protected, and encapsulated into new packets, which are sent across the Internet to something that undoes the encapsulation, checks the integrity, and decrypts the traffic.
Virtual private networks are not exactly a firewall technology, but we discuss them here for several reasons:
If you’re using virtual private networking, you need to be careful about how it interacts with the firewall. In many cases, the firewall can’t control traffic that comes in over the virtual network, which makes it a way to avoid the firewall controls and open new insecurities.
A firewall is a convenient place to add virtual private networking features.
We will frequently mention virtual private networking as a way to provide remote services that cannot be provided securely using other firewall techniques.
Where Do You Encrypt?
Virtual private networks depend on encryption. That encryption can be done as a transport method, where a host decides to encrypt traffic when it is generated, or as a tunnel, where traffic is encrypted and decrypted somewhere in between the source and the destination. The question of where you do the encryption and decryption relative to your packet filtering is an important one. If you do the encryption and decryption inside the packet filtering perimeter (i.e., on your internal net), then the filters just have to allow the encrypted packets in and out. This is especially easy if you’re doing tunneling, because all the tunneled packets will be addressed to the same remote address and port number at the other end of the tunnel (the decryption unit). On the other hand, doing the encryption and decryption inside your filtering perimeter means that packets arriving encrypted are not subject to the scrutiny of the packet filters. This leaves you vulnerable to attack from the other site if that site has been compromised.
If you do the encryption and decryption outside the packet filtering perimeter (i.e., on your perimeter net or in your exterior router), then the packets coming in from the other site can be subjected to the full scrutiny of your packet filtering system. On the other hand, they can also be subjected to the full scrutiny of anyone who can read traffic on your perimeter net, including intruders.
Key Distribution and Certificates
As with any encryption and integrity protection system, key distribution can be a very sticky problem. A number of choices are available, including sharing keys or using a public key system; see Appendix C, for descriptions of these systems and the advantages and disadvantages of each.
Advantages of Virtual Private Networks
Most of the advantages of virtual private networks are economic; it’s cheaper to use shared public networks than it is to set up dedicated connections, whether those are leased lines between sites or modem pools that allow individual machines to connect to a central site. On the other hand, virtual private networks also provide some security advantages.
Virtual private networks provide overall encryption
A virtual private network conceals all the traffic that goes over it. Not only does it guarantee that all the information is encrypted, but it also keeps people from knowing which internal machines are being used and with what protocols. You can protect information from snooping by using individual encrypted protocols, but attackers will still have some idea what machines are talking and what kind of information they’re exchanging (for instance, if you use an encrypted mail protocol, they will know that things are being mailed). A virtual private network conceals more information.
Virtual private networks allow you to remotely use protocols that are difficult to secure any other way
Some protocols are extremely difficult to provide securely through a firewall. For instance, a number of protocols used on Microsoft systems are based on SMB, which provides a wide variety of services with different security implications over the same ports and connections. Packet filtering and proxying both have trouble adding security to SMB. Virtual private networking provides a way to give remote access for these protocols without letting people attack them from the Internet at large.
Disadvantages of Virtual Private Networks
Although virtual private networks are an important security tool, they also present problems in a firewall environment.
Virtual private networks involve dangerous network connections
A virtual private network runs over an actual network, which is presumably not a private network. The hosts on the virtual private network must be connected to that actual network, and if you’re not careful, they will be vulnerable to attack from that network. For instance, if you use a virtual private network to provide connectivity to your internal network for mobile users who connect to the Internet, their machines may be attacked from the Internet.
Ideally, a virtual private network system will disable all other uses of the network interface. It’s important to choose a system that will allow you to force this on the remote system. It’s not good enough to have a system where the remote system is able to turn off other uses because the user on the remote system may turn networking back on. It’s very tempting as a way to get rapid access to Internet resources.
Virtual private networks extend the network you must protect
When you attach something via a virtual private network, you are making it part of your internal network. If a machine on the virtual private network is broken into, the attacker will then be able to use the virtual private network to attack the rest of your site, from something that’s treated as if it were inside of your local network. Virtual private networking is commonly used to give access to machines that are much more vulnerable than those that are physically on the network—for instance, laptops that are carried around in public, home machines that curious children have physical access to, and machines owned by other sites with interests and policies that are not identical to yours.
Even if the virtual private network disables other uses of the network interface it is running over, the machine may have other network interfaces. This can make it into a gateway between your network and others, inside your network’s security perimeter.
Because of this, you want to be careful how you attach the virtual private network to your real private network, and how you secure the remote end. It may not be appropriate to make the virtual private network a seamless part of your internal network. Consider putting in a subsidiary firewall or at least special intrusion detection to watch for problems.
[1] Marcus Ranum, who is generally held responsible for the popularity of this term in the firewalls professional community, says, “Bastions . . . overlook critical areas of defense, usually having stronger walls, room for extra troops, and the occasional useful tub of boiling hot oil for discouraging attackers”.
[2] Some networking literature (in particular, the BSD Unix release from Berkeley) uses the term “packet filtering” to refer to something else entirely (selecting certain packets off a network for analysis, as is done by the etherfind or tcpdump programs).
[3] Firewall terminologies differ. Whereas we use the term proxy service to encompass the entire proxy approach, other authors refer to application-level gateways and circuit-level gateways. Although there are small differences between the meanings of these various terms, which we’ll explore in Chapter 9, in general our discussion of proxies refers to the same type of technology other authors mean when they refer to these gateway systems.