Introduction to Network Security

This chapter is from the book

Network Security: Private Communication in a Public World, 3rd Edition

Learn More Buy

This chapter is from the book

This chapter is from the book 

Network Security: Private Communication in a Public World, 3rd Edition

Learn More Buy

1.12 Security Gateway

A security gateway (see Figure 1-3) sits between your internal network and the rest of the network and provides various services. Such a box usually provides many functions, such as firewall (§1.12.1), web proxy (§1.12.2), and network address translation (§1.14). We will describe these features in the next few sections.

Figure 1-3. Security Gateway

1.12.1 Firewall

There was a time when people assumed that their internal network and all the users and systems on the internal network were trustworthy. The only challenge was connectivity to the Internet. Users need to communicate with publicly available services. The company needs to make some of its own services available to customers located outside the corporate network. So the thought was to install a box between your network and the scary Internet that can keep things secure, somehow.

The belief that a firewall between your internal network and the scary Internet is all you need to protect you has long been discredited. Even if you had the most secure firewall, i.e., a box that blocked any traffic between your network and the Internet, malware inside your network could do arbitrary damage. And even carefully configured firewalls often break legitimate usage.

A recent buzzword is zero trust. It basically means the opposite of the previous thinking. Although firewalls can add some amount of extra security, all applications must protect themselves. They must authenticate everything they are talking to and enforce access control rules. The buzzword defense-in-depth means having multiple stages of security, so if one fails, hopefully another will protect you. Although people pretty much agree that the old firewall-will-protect-you model is no longer the right way to think about security, a lot of the mechanisms supporting that model are still deployed.

Firewalls centrally manage access to services in ways that individual systems should, but often don’t. Firewalls can enforce policies such as systems outside the firewall can’t access file services on any systems inside the firewall. With such a restriction, even if the internal systems are more open than they should be, or have bugs, they can’t be attacked directly from systems outside the firewall.

Note that a firewall need not be a physical box that the company buys. It could instead be software on each machine that does the same sorts of filtering that a firewall box would do. This concept is sometimes called a distributed firewall. Both “firewall” and “distributed firewall” are buzzwords, and, as with most buzzwords, the definitions evolve and are used by different vendors in different ways. Usually distributed firewall implies that all the components doing “firewall stuff” are centrally managed. Otherwise, it would just be multiple firewalls.

The simplest form of firewall selectively discards packets based on configurable criteria, such as addresses in the IP header, and does not keep state about ongoing connections. For example, it might be configured to only allow some systems on your network to communicate outside, or some addresses outside your network to communicate into your network. For each direction, the firewall might be configured with a set of legal source and destination addresses, and it drops any packets that don’t conform. This is known as address filtering.

Packet filters usually look at more than the addresses. A typical security policy is that for certain types of traffic (e.g., email, web surfing), the rewards outweigh the risks, so those types of traffic should be allowed through the firewall, whereas other types of traffic (say, remote terminal access), should not be allowed through.

To allow certain types of traffic between host A and B while disallowing others, a firewall can look at the protocol type in the IP header, at the ports in the layer 4 (TCP or UDP) header, and at anything at any fixed offset in the packet. For web traffic, either the source or destination port will likely be 80 (http) or 443 (https). For email, either the source or destination port will likely be 25.

Firewalls can be even fancier. Perhaps the policy is to allow connections initiated by machines inside the firewall, but disallow connections initiated by machines outside the firewall. Suppose machine A inside the firewall initiates a connection to machine B outside the firewall. During the conversation, the firewall will see packets from both directions (A to B as well as B to A), so it can’t simply disallow packets from B to A. The way it manages to enforce only connections initiated by A, is to look at the TCP header. TCP has a flag (called ACK) that is set on all but the first packet, the one that establishes the connection. So if the firewall disallows packets from B without ACK set in the TCP header, then it will usually have the desired effect.

Another approach is a stateful packet filter, i.e., a packet filter that remembers what has happened in the recent past and changes its filtering rules dynamically as a result. A stateful packet filter could, for instance, note that a connection was initiated from inside using IP address s, to IP address d, and then allow (for some period of time) connections from IP address d to IP address s.

1.12.2 Application-Level Gateway/Proxy

An application-level gateway, otherwise known as a proxy, acts as an intermediary between a client and the server providing a service. The gateway could have two network adaptors and act as a router, but more often it is placed between two packet-filtering firewalls, using three boxes (see Figure 1-4). The two firewalls are routers that refuse to forward anything unless it is to or from the gateway. Firewall F₂ refuses to forward anything from the global net unless the destination address is the gateway and refuses to forward anything to the global net unless the source is the gateway. Firewall F₁ refuses to forward anything from your network unless the destination address is the gateway, and refuses to forward anything to your network unless the source address is the gateway. To transfer a file from your network to the global network, you could have someone from inside transfer the file to the gateway machine, and then the file is accessible to be read by the outside world. Similarly, to read a file into your network, a user can arrange for it to first get copied to the gateway machine. To log into a machine in the global network, you could first log into the gateway machine, and from there you could access machines in the remote network. An application-level gateway is sometimes known as a bastion host. It must be implemented and configured to be very secure. The portion of the network between the two firewalls is known as the DMZ (demilitarized zone).

Figure 1-4. Application-Level Gateway

The gateway need not support every possible application. If the gateway does not support an application, either the firewalls on either side of the gateway should block that application (based on layer 4 port), or both firewalls would need to allow that application, depending on whether you want that application to work through the firewall. An example strategy is to allow only electronic mail to pass between your corporate network and the outside world. The intention is to specifically disallow other applications, such as file transfer and remote login. However, electronic mail can certainly be used to transfer files. Sometimes a firewall might specifically disallow very large electronic mail messages, on the theory that this will limit the ability to transfer files. But often, large electronic mail messages are perfectly legitimate, and any file can be broken down into small pieces.

Sometimes an application might specifically be aware of proxies running on an application gateway. For example, browsers can be configured with the address of a proxy, and then all requests will be directed to the proxy. The proxy might be configured with which connections are allowed and which are disallowed, and could even inspect the data passing through to check for malware.

1.12.3 Secure Tunnels

A tunnel (see Figure 1-5) is a point-to-point connection created between nodes A and B, where the connection is a path across a network. A and B can treat the tunnel as a direct link between each other. An encrypted tunnel is when A and B establish a secure session. An encrypted tunnel is sometimes called a VPN (virtual private network). We think that’s a really bad term, and a more accurate term would be VPL (virtual private link). Whoever decided to call it a VPN imagined that the encrypted tunnel becomes an extra link in your private network, so a network consisting of a combination of private links and encrypted tunnels across the Internet becomes your private network. If we just use the acronym VPN for the encrypted tunnel (like the industry seems to) and don’t think about what VPN expands to, I₂ guess we can live with the term.

Figure 1-5. Connecting a Private Network over a Public Internet

Suppose the only reason you’ve hooked into the Internet is to connect disconnected pieces of your own network to each other. Instead of the configuration in Figure 1-5, you could have bought dedicated links between G₁, G₂, and G₃, and trusted those links as part of your corporate network because you owned them. But it’s likely to be cheaper to have the Gs pass data across the Internet. How can you trust your corporate data crossing over the Internet? You do this by configuring G₁, G₂, and G₃ with security information about each other (such as cryptographic keys), and creating secure tunnels between them.

The mechanics of the tunnel between G₁ and G₂, from the IP (network layer 3) point of view, is that when A sends a packet to C, A will launch it with an IP header that has source=A, destination=C. When G₁ sends it across the tunnel, it puts it into another envelope, i.e., it adds an additional IP header, treating the inner header as data. The outer IP header will contain source=G₁and destination=G₂. And all the contents (including the inner IP header) will be encrypted and integrity protected, so it is safe to traverse the Internet.

1.12.4 Why Firewalls Don’t Work

Firewalls alone (without also doing end-to-end security) assume that all the bad guys are on the outside, and everyone inside can be completely trusted. This is, of course, an unwarranted assumption. Should employees have access (read and write) to the salary database, for instance?

Even if the company is so careful about hiring that no employee would ever do anything bad intentionally, firewalls can be defeated if an attacker can inject malicious code into a machine on the corporate network. This can be done by tricking someone into downloading something from the Internet or launching an executable from an email message. It is quite common for an attacker to break into one system inside your firewall, and then use that system as a platform for attacking other systems. Someone once described firewall-protected networks as “hard and crunchy on the outside; soft and chewy on the inside.”

Firewalls often make it difficult for legitimate users to get their work done. The firewall might be configured incorrectly or might not recognize a new legitimate application. And if the firewall allows one application through (say email or http), people figure out how to do what they need to do by disguising it as traffic that the firewall is configured to allow. The ironic term for disguising traffic in order to fool a firewall is to carry your traffic in a firewall-friendly protocol. Since firewalls commonly allow http traffic (since it’s the protocol used for browsing the web), there are many proposals for doing things over http. The most extreme example is to carry IP over http, which would allow any traffic through! Firewall-friendly? The whole point is to defeat the best efforts of the firewall administrator to disallow what you are doing! It isn’t somehow “easier” for the firewall to carry http traffic than any other. The easiest thing for the firewall would be to allow everything or nothing through!

Just as breaking a large file into lots of pieces to be individually carried in separate emails is inefficient, having protocols run on top of http rather than simply on top of IP is also inefficient in terms of bandwidth and computation.