Part III: Tools for Auditing and Defending Your Network

Chapter List

Chapter 13: Firewalls

Chapter 14: Network Reconnaissance Tools

Chapter 15: Port Redirection

Chapter 16: Sniffers

Chapter 17: Wireless Tools

Chapter 18: War Dialers

Chapter 19: TCP/IP Stack Tools

Chapter 13: Firewalls

Throughout this book, we have indicated that certain network services have great potential for compromise and should be run only from behind a firewall. We've talked about how firewalls can allow you to provide services to internal users without allowing access to external users. Coupled with an intrusion detection system, a firewall device can be the first line of defense for a network administrator. In this chapter, we'll cover the basic concepts behind firewalls and packet filters and some free and commercial firewall implementations.

FIREWALLS AND PACKET FILTERS—THE BASICS

Before we dive into firewall configuration methods and guidelines, we should review the capabilities of a firewall and its place in a network architecture.

What Is a Firewall?

Many people think firewalls are strictly hardware devices. When people think of purchasing and installing a firewall, they inevitably picture a magic black box that gets plugged in at the entry point of their network, fending off would-be hackers and bad guys. Actually, a firewall is a software program that carefully examines network traffic (or packets) passing through a network interface. Because firewall software is useless without a hardware network interface to protect, firewall software often comes bundled and pre-installed on specially built hardware devices. Throughout this chapter, we will refer to these hardware devices as firewall appliances to distinguish them from the firewall software itself.

Now that we know what a firewall is, what exactly is a firewall appliance? A firewall appliance is a network device that separates two or more networks and has firewall software running on at least one network interface. The appliance uses the firewall software to determine what traffic should be forwarded between networks. It is the firewall software and its associated rule base that makes the appliance perform the commonly imagined functions of a firewall. Without the software, a firewall appliance is just a simple router, gateway, or packet forwarder.

Let's firm up our definition of firewall software before we move on. Firewall software is any software that examines traffic passing through an interface and makes routing decisions based on a set of criteria. Some examples of firewall software are listed here:

• Personal firewalls Personal firewalls are software packages you can install on your system to protect it from attacks—most often necessary when it's connected to the Internet. If you are a cable modem or DSL subscriber and you plug your PC directly into the cable modem or DSL router, your PC is more than likely given a public IP address with little protection from other users on the provider's network. In this case, any shared files, folders, and printers, as well as any network services running on your PC, will be visible to, and exploitable by, just about anyone on the Internet. Personal firewalls are designed to block access to vulnerable ports.
• Parental control software Parental control software blocks web traffic from certain blacklisted adult web sites, preventing users from accessing these sites without authorization.

Other filtering software such as spam blockers and virus scanners are similar to firewall software but not quite the same. Spam blockers and virus scanners operate on larger entities (e-mail messages and files), whereas firewalls are usually filtering only network packets. Some firewalls have emerged that claim to block attacks that packet inspection can't identify. Many of these firewalls are referred to as application-layer firewalls because they can inspect the syntax of an application (such as an e-commerce web site) rather than just the packet-level information (such as HTTP). For example, an e-commerce web site uses HTTP to communicate with web browsers. A packet-level firewall could look at the HTTP requests to see if they are correctly formed and adhere to the protocol specification. An application-layer firewall can understand how the web site is constructed and what types of requests legitimate users should be permitted to make and what types of requests represent an attack. This is important because legitimate requests and malicious web hacks can both consist of well-formed HTTP requests, which is where a packet-level firewall stops its inspection. This chapter focuses on packetand network-layer firewalls.

What's the Difference Between a Firewall and a Packet Filter?

Throughout the book, we mention firewalls and packet filters rather interchangeably. Firewalls and packet filters generally perform the same function. Packet filters inspect traffic based on characteristics such as protocol, source or destination addresses, and other fields in the TCP/IP (or other protocol) packet header. Firewalls are packet filters, but some firewalls may examine more than just packet headers; they may examine packet data (or payloads) as well. For example, a packet filter may monitor connections to ports 20 and 21 (FTP ports), whereas a firewall may be able to establish criteria based on the FTP port numbers as well as FTP payloads, such as the PORT command or filenames that include the text passwd.

Normally, the term packet filter refers to the software running on network devices that perform other network functions such as complex routing. The packet filter provides some additional security to the router; however, the software is simplistic because the device's main focus is routing traffic to its proper destination. The term firewall is usually reserved for devices that have the sole function of protecting an internal network from outsiders.

Sometimes you may also hear the phrase intrusion prevention system. This usually refers to a hardware appliance that has packet filtering, content filtering, intrusion detection capabilities, and other security software bundled into one package. Alerts from your IDS automatically trigger certain firewall rules.

How Do Firewalls Protect Networks?

Firewalls are only as effective as the rules with which they are configured. As we've mentioned several times, firewalls examine particular characteristics of network traffic and decide which traffic to allow and deny based on some criteria. It is the system administrator's job to build the ruleset in such a way that it sufficiently protects the networks behind it, while still permitting legitimate traffic. Most firewalls have three ways to handle traffic that matches a particular rule:

• Accept the packet and pass it on to its intended destination.
• Deny the packet and indicate the denial with an Internet Control Message Protocol (ICMP) message or other acknowledgment. This provides explicit feedback to the packet's sender that such traffic is not permissible through the firewall.
• Drop the packet without any acknowledgment. This ends the packet's life on the network. No information is sent to the packet's sender. This reduces the sender's ability to deduce information about the protected network, but it may also adversely impact network performance for certain types of traffic.

Most firewalls are set up to drop packets as their default policy. It's safer to start with a closed firewall ruleset and open only the necessary holes than to start with an open firewall ruleset that then needs to be tightly locked down.

What Type of Packet Characteristics Can You Filter in a Ruleset?

Most firewalls and packet filters have the ability to examine the following characteristics at a minimum:

• Type of protocol (IP, TCP, UDP, ICMP, IPSec, etc.)
• Source IP address and port
• Destination IP address and port
• ICMP message type and code (see Appendix A)
• TCP flags (SYN, FIN, ACK, etc.)
• Network interface on which the packet arrives

So, if you wanted to block incoming Ping packets (ICMP echo requests) to your home network of 192.168.1.0/24, you could write a rule like this. Don't worry about the specific syntax yet.

deny proto icmp type 8:0 from any to 192.168.1.0/24

Or if you wanted to allow incoming web traffic to 192.168.1.50 but deny everything else:

allow proto tcp from any:any to 192.168.1.50:80
deny proto all from any to 192.168.1.0/24

You can also use a firewall to protect your network from IP spoofing. For example, let's say your firewall's external interface (called eth1) has an IP address of 10.0.0.1 with a netmask of 255.255.255.0. Your firewall's internal interface (called eth0) has an IP address of 192.168.1.1 with a netmask of 255.255.255.0. Any traffic from the 192.168.1.0 network destined to the 10.0.0.0 network will come in to the eth0 interface and go out of the eth1 interface, as shown in the following illustration.

Conversely, traffic from the 10.0.0.0 network destined for the 192.168.1.0 network will come in on the eth1 interface and go out of the eth0 interface. Therefore, you should never see traffic with a source address of 192.168.1.x coming inbound on the eth1 interface. If you do, it means someone on the external 10.0.0.0 network is attempting to spoof an address in your local IP range. Your firewall can stop this kind of activity by using a rule like this:

deny proto any from 192.168.1.0/24 to any on eth1

Now, if we look carefully at this rule, it looks a little ambiguous. Couldn't this rule match legitimate traffic coming from 192.168.1.0 heading out to the external network? It could, but it depends on the firewall's interpretation of the syntax. Since we're using a fictional firewall rule syntax for these examples, this rule remains ambiguous and possibly ineffective. This illustrates an important point: You have to be very careful when writing firewall rules. We know what we were trying to block, but did we implement it correctly? You have to make sure that you understand how the firewall applies rules and what its default or assumed behavior might be. We could write the anti-spoofing rule less ambiguously if we specified the network interface on which to apply the rule:

deny proto any from 192.168.1.0/24 to any in on eth1
allow proto any from 192.168.1.0/24 to any out on eth1

The combination of these two rules clearly indicates our intention. We'll talk more about writing good firewall rules when we start looking at some of the actual firewall products later in this chapter.

What's the Difference Between Stateless and Stateful Firewalls?

Back in Chapter 4, we mentioned that tools such as nmap can be used to determine whether a firewall is stateful or not. What exactly is a stateful or stateless firewall? A stateless firewall can examine only one individual packet at a time in isolation, regardless of other packets that have come before it. A stateful firewall, on the other hand, can place that packet in the context of other traffic and within the particular protocol, such as TCP/IP or FTP. This allows stateful firewalls to group individual packets together into connections, sessions, or conversations. Consequently, a stateful firewall can filter traffic based not only on the characteristics of an individual packet, but also on the context of a packet according to a session or conversation.

Stateful firewalls also allow for more dynamic rulesets. For example, suppose an internal machine on the internal 192.168.1.0 network wanted to connect to a web server on the Internet. The following steps demonstrate the drawbacks of trying to apply simple packet inspection to the traffic:

allow proto tcp from 192.168.1.0/24:any to any:80 out on eth1

So far, so good. But what happens when the web server responds? We need to make sure the response packet gets accepted by our firewall. Unfortunately, since a web browser usually chooses a source port at random, we won't know which destination port to open for the response packet until after the initial packet is sent. The only thing we know for certain is that the response packet from the web server will have a source port of 80, so we can write a rule to allow that through:

allow proto tcp from any:80 to 192.168.1.0/24:any in on eth1

This allows the web server's response to reach any host on the 192.168.1.0 network, but it also opens a rather gaping hole in the firewall. The rule assumes that only return web traffic would be using a source port of 80. However, as we have mentioned in other chapters, it is trivial for any kind of Internet traffic to designate a specific source port. If a hacker were aware that any packet with a source port of 80 could pass through the firewall, he could use port redirection to set up a tunnel (see Chapter 15). The tunnel would forward any traffic it received to a machine on the 192.168.1.0 network, substituting 80 for the packet's the source port in order to traverse the firewall rule. The hacker could telnet to the tunnel, which could be directed to 192.168.1.50's telnet server on port 23, for example; the port redirector would change the source port to 80 and forward it to 192.168.1.50; and the firewall would accept it. To prevent this, perhaps we should take an additional precaution:

allow proto tcp from any:80 to 192.168.1.0/24:1024-65535 in on eth1

Since most web browsers won't be able to choose a source port in the reserved range (less than 1024), there's no need to allow traffic coming from port 80 to any port under 1024. This is an improvement, but it still leaves a large unnecessary hole in the firewall. Wouldn't it be better if the firewall could instead remember the details of our outgoing connection? That way, we could say that if the initial outgoing packet is allowed by the firewall, any other packets that are part of that session should also be allowed. This dynamic rule prevents us from having to poke potentially exploitable holes in our firewall. This is the power stateful firewalls have over stateless firewalls. We'll cover this again in the next chapter when we discuss the hping's usefulness in testing firewall rules.

Understanding Network Address Translation (NAT) and Port Forwarding

Many firewall appliances are used to separate external networks with publicly accessible IP addresses from internal networks with private IP addresses. The appliance's external interface has a public IP address while the appliance's internal interface has a private one. Public addresses are also referred to as routable and private (or nonpublic) addresses are often referred to as unroutable. In actual practice, packets from either a public or private address space are routable, but with a specific distinction: private addresses are not intended (or acceptable) to be used for Internet addressing. Private addresses are reserved for organizations to create internal networks.

The Internet Assigned Numbers Authority (IANA) reserved certain IP address blocks for private networks. This means that public Internet routers will not (or at least should not) route traffic to and from machines in these network ranges. The network ranges are as follows:

• 192.168.0.0 through 192.168.255.255 (written 192.168.0.0/16 or 192.168.0.0/255.255.0.0)
• 172.16.0.0 through 172.31.255.255 (written 172.16.0.0/12 or 172.16.0.0/255.240.0.0)
• 10.0.0.0 through 10.255.255.255 (written 10.0.0.0/8 or 10.0.0.0/255.0.0.0)

As you can see, this gives you a large number of IP addresses and subnets for internal network addresses. Any private networks whose systems should not be accessible to machines on the Internet at large should use a subset of one of these ranges as their subnet.

This poses a problem, however, if any of the systems on the private network want to access the Internet. Remember that the recommended behavior states that public Internet routers will not route traffic to or from systems with these private addresses. This seems to imply that a private address can never access some Internet web site.

Network address translation (NAT) solves this routing problem by translating packets from private to public addresses. NAT is usually performed by a firewall appliance on its external interface for the benefit of the systems on its internal interface. Many network devices can perform NAT, including routers. A NAT device allows machines on its private, internal network to masquerade as the IP address assigned to NAT device. Private systems can communicate with the Internet using the routable, publicly accessible IP address on the NAT device's external interface.

When a NAT device receives traffic from the private network destined for the external network (Internet), it records the packet's source and destination details. The device then rewrites the packet's header such that the private source IP address is replaced with the device's external, public IP address.

Then the device sends the packet to the destination IP address. From the destination system's point of view, the packet appears to have come directly from the NAT device. The destination system responds as necessary to the packet, sending it back to the NAT device's IP address.

When the NAT device receives the response packet, it checks its address translation table to see if the address and port information of the packet match any of the packets that had been sent out. If no match is found, the packet is dropped or handled according to any firewall rules operating on the device. If a match is found, the NAT device rewrites the packet's destination IP address with the private IP address of the system that originally sent the packet.

Finally, the NAT device sends the packet to its internal destination. The network address translation is completely transparent to the systems on the internal, private IP address and the Internet destination. The private system can access the Internet, but an Internet system cannot directly address it.

If you're having trouble visualizing what's going on, perhaps the following illustration will help:

NAT does have limitations. The packet header manipulation will interfere with any protocol that requires the use of true IP addresses, such as IPsec. Also, any protocols that require a separate, reverse incoming connection, such as active mode FTP, will not work. The outgoing FTP control connection to the FTP server will make it through the NAT just fine, but when the FTP server attempts to establish the data connection, the NAT device won't know what to do because it doesn't have a corresponding entry in its translation table. NAT's prevalence has influenced people to create workarounds to resolve these limitations.

In the end, NAT has become integral to firewalls and network security. It provides an added layer of security to a firewall appliance, as it not only protects machines behind its internal interface, but it also hides them. But what happens if you decide you'd like to expose a particular service on your private network to the Internet? What if you wanted someone across the country to be able to look at something you had posted on your internal web server? Is there any way to allow Internet machines to initiate communication with a private machine?

For this, you can use a technique called port forwarding. The NAT device can forward any traffic received on a particular port on the device's external interface to a port on a private internal machine. A system on the Internet that connects to the NAT device on this port would effectively connect to the port on the internal system, even though it only needs to know the IP address of the NAT device.

This is all well and good, but now you've made your private network a little less private by opening this port forward. Now anyone on the Internet can access your internal web server by connecting to the port on your NAT device. If your NAT device is a firewall, you can use firewall rules to limit what IP addresses are allowed to access it. While this is more secure, you're still relying solely on IP-based authentication. On many occasions, users who have built fortified, private networks may find it necessary to open up internal network resources to another remote facility. There are many ways to restrict access from that remote facility and prohibit the rest of the Internet. But do we really want to forward dozens of ports and open dozens of holes in our firewall, or dozens of rules and exceptions? This is where Virtual Private Networks come into play.

The Basics of Virtual Private Networks

Virtual Private Networks (VPNs) are a complex subject. We touch on them here because so many firewall appliances provide some measure of VPN capabilities. The VPN server resides on the appliance and waits for connections from VPN clients. These clients can be software-based, such as a laptop, or hardware-based solutions, such as a peer appliance. Remote offices often install a firewall/VPN appliance at their peers and configure the devices so that traffic passes between them as if they were connected by a dedicated data line. The only difference is that it's a virtual data line. The traffic still transits the Internet, but the VPN provides additional layers of security via encryption and firewall protection.

A major aspect of VPNs is user authentication. Remote users use a software VPN client and log into the VPN server to establish their connection. Hardware VPN devices usually use some kind of shared key authentication scheme. This is much stronger in both security and convenience than relying on an IP address for authentication.

VPN traffic is usually encrypted. This protects the confidentiality of the data in transit between the VPN endpoints. Even though the data still passes through many routers, switches, or other devices on the Internet, it's nearly as safe as if it were using a dedicated data line.

VPNs can usually forward all traffic (or as much traffic as desired) between the networks over a single set of ports. Imagine how many port forwards and firewall rules you'd have to write if you had to open up several internal network resources to a remote location? File sharing, printer sharing, code repositories, web sites, and other services would create a NAT and port forwarding configuration nightmare.

By combining the capabilities of a firewall, NAT device, and a VPN in one network appliance, you can greatly improve the external security of your internal network without losing convenience or productivity.

Inside the Demilitarized Zones

A discussion about firewalls wouldn't be complete without mentioning the Demilitarized Zone, or DMZ. The DMZ has become an unfortunate buzzword that many people use when talking about networks and firewalls, but few understand what it's about.

We've discussed firewall and NAT devices that have an external interface with a public, routable IP address and an internal interface with a private, nonroutable IP address. What happens if our organization has an FTP server, web server, and DNS server that we want to make publicly accessible? Well, we could keep them on the private network and set up port forwards, but what happens if we have multiple web servers? We can't bind one external port 80 to several internal systems. Also, if one of the servers were compromised, the attacker would own a system on our private network, potentially allowing her access to all of the systems. Since we want the systems to be publicly accessible, we could just put the servers outside the firewall, but this is also a Bad Idea (and deserving of capital letters to make the point). We want our web server's web service to be publicly accessible, but we don't want the Internet to access anything else on the server (such as SMB file sharing, perhaps). We need to keep these systems behind a firewall, but separate from the rest of the private network.

For this very reason, most firewall appliances come with a third network interface for these restricted, but public servers. In all truthfulness, the DMZ interface just allows you to hang another network off the firewall. You could make it a second, separate private network, or you could tell your firewall to pass all traffic on that interface, making it completely open and public. In DMZ terminology, this third interface is intended for a publicly accessible yet protected network.

Some firewall appliances handle DMZs differently. Since the DMZ network is technically a separate network from the public network connected to your firewall's external interface, you may need a separate block of public IP addresses for your DMZ interface. Some appliances allow you to use IP addresses from your current public IP block and map them to machines on the DMZ, even though the DMZ is physically a separate network.

One thing to keep in mind is that firewall rules become a little trickier and a lot more complex when dealing with more than two interfaces. Most commercial firewalls will mask all these details for you by simplifying their rule syntax, but the freeware packet filters that come by default on Unix systems may require you to understand these concepts. Take a look at the following diagram detailing the network interfaces on our firewall. The private network hangs off the internal interface (eth0), the public network hangs off the external interface (eth1), and the DMZ hangs off the DMZ interface (eth2).

Now, in a two-interface configuration, if we wanted to protect our firewall device as well as the machines behind it, we'd want the firewall software to examine packets on the external interface eth1. On eth1, outgoing traffic is coming through the firewall and out eth1 and incoming traffic is coming in through eth1 to the firewall. If we add a third interface and we want to protect our machines on that interface (the DMZ), we might want our firewall software to examine packets on the DMZ interface eth2 as well. On eth2, outgoing traffic is coming through the firewall and out eth2 and incoming traffic is coming in through eth2 to the firewall. If you look again at the diagram, this is backward from the way eth1 is set up. On eth1, the machines hanging off eth1 (the Internet) are considered untrusted. On eth2, the machines hanging off eth2 (the DMZ) are considered trusted. This is something we need to consider when writing firewall rules for the DMZ interface. If a machine on the public Internet wanted to talk to a machine on the DMZ, our firewall device would first receive a packet inbound on eth1 and decide whether that incoming packet should be passed on to the DMZ. If it passes, the packet will be forwarded to eth2. That packet will then be sent outbound on eth2 to the DMZ. The firewall on eth2 will then have to decide whether that outgoing packet should be passed on to the DMZ machine. Even though the packet is inbound from the public Internet to the DMZ, the packet appears outbound from the perspective of eth2.

Pretty crazy, isn't it? In most cases like this, you can configure the firewall on eth1 to protect both your internal and DMZ networks without having to watch traffic on either eth0 or eth2 as well. However, it's an important concept to grasp if you ever find yourself firewalling two interfaces on one device. The concept of incoming and outgoing can change depending on which side of the interface you place your trusted network. When writing firewall rules, you always have to consider the perspective of what the rules are intended to prevent or permit.

When Do We Get to Talk About Actual Firewall Products?

We've gone on long enough about the basics of firewalls and traffic manipulation, but the concepts discussed in this section are necessary for you to understand our discussions of the firewall products. And now, without further ado, let's take a look at actual firewall products.