Part III: Tools for Auditing and Defending Your Network

Chapter List

Chapter 13: Firewalls

Chapter 13: Firewalls

Throughout this book, we have indicated that certain network services can be dangerous 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 (IDS), 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 can talk about particular firewall products, we need to make sure you understand exactly what a firewall is, what it can (and cannot) do, and how it fits into the architecture of your network.

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 over 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 based on certain criteria. You see, it is the firewall software that makes the firewall appliance a firewall. Without the software, a firewall appliances 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 on an interface and uses rules or criteria to decide which traffic to allow or deny. Some examples of firewall software are listed here:

• Personal firewalls   Personal firewalls are software packages you can install on your PC or laptop to protect your machine if it is directly 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, routable IP address with little downstream 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 the Internet at large. Personal firewalls can keep those things hidden from snoopers.
• Parental control software   Parental control software blocks web traffic from certain black-listed “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.

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 are generally the same thing. Packet filters, by definition, filter traffic based on packet header characteristics such as protocol, source or destination addresses, and other characteristics. Firewalls are packet filters, but some firewalls may examine more than just packet headers; they may examine packet data (or payloads) as well. 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.

Note

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. Several commercial appliances bill themselves as intrusion prevention systems, such as eEye’s Blink and EcoNet’s Sentinel.

How Do Firewalls Protect Networks?

Firewalls are only as good as the administrators who set them up. As we’ve mentioned several times, firewalls examine particular characteristics of network traffic and decide which traffic to allow and deny based on a ruleset or criteria. It is the system administrator’s job to build that ruleset in such a way that it sufficiently protects the networks behind it. Most firewalls will do one of three things with a packet depending on its ruleset:

• It will accept the packet and pass it on to its intended destination.
• It will deny the packet, sending an Internet Control Message Protocol (ICMP) message or other acknowledgement informing the source that the packet was dropped.
• It will drop the packet entirely without any acknowledgement.

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 IP protocol (TCP, UDP, ICMP, and so on)
• Source IP address and/or port
• Destination IP address and/or port
• ICMP message type and code (see Appendix A)
• TCP flags (SYN, FIN, ACK, and so on)
• Network interface on which the packet is passing

So if you wanted to block incoming Pings (ICMP echo requests) to your home network of 192.168.1.0/24, you could write a rule like this:

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? The answer is yes, it could. It depends on the way the syntax is interpreted by the firewall. Since we’re using a fictional firewall rule syntax for these examples, this rule can mean whatever we want it to mean, but this illustrates an important point: You have to be very careful when writing firewall rules. We know what we were trying to say, but did we say it correctly? You have to make sure that you and your firewall are speaking the same language so that you understand each other correctly. We could write the anti-spoofing rule less ambiguously if we specified where the traffic was coming from on eth1:

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 spells out what we’re trying to say. 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 “remember” what packets have already come across the interface and can examine new packets in that context. This allows stateful firewalls to group individual packets together into connections, sessions, or conversations. A stateful firewall, therefore, can filter traffic based on the characteristics of an entire session or conversation, not just individual packets.

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. Our firewall would have to allow that 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 response through regardless of what port the 192.168.1.0 machine chose to use, but it also opens a rather gaping hole in the firewall. We’re assuming that only return web traffic would be using a source port of 80. However, as we have seen, it is relatively 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 a tool such as FPipe (see Chapter 15) to set up a tunnel. The tunnel would forward any traffic it received to a machine on the 192.168.1.0 network, substituting 80 as the source port midtransit. The hacker could telnet to the tunnel, which could be directed to 192.168.1.50’s telnet server on port 23 for example; FPipe would change the source port to 80 and forward it to 192.168.1.50; and the firewall would let it through. 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 (under 1024), there’s no need to allow traffic coming from port 80 to any port under 1024. This is a much better rule, 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 passed by the firewall, any other packets that are part of that connection should also be passed. 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 utility’s usefulness in testing firewall rules.

What Are Network Address Translation 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, routable IP address while the appliance’s internal interface has a private, nonroutable IP address. You might be wondering what makes an IP address public or private. Okay, we’ll tell you.

It’s not magic; the Internet Assigned Numbers Authority (IANA) has reserved certain IP address blocks to be used by private IP 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 to choose from for your internal network addressing purposes. 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 machines on the private network want to access machines on the Internet. Remember that we said that public Internet routers will not route traffic to or from machines on these private network addresses. You can’t keep the Internet from being able to see you if you want to see the Internet. Or can you?

Through the magic of Network Address Translation, also known as NAT or IP masquerading, you can have your cake and eat it, too. NAT is usually performed by a firewall appliance on its external interface for the benefit of the machines behind it (on its internal interface). Any network device that can perform NAT (this includes routers as well as firewalls) can be referred to as a NAT device. In short, a NAT device allows machines on its private, internal network to “masquerade” as the NAT device itself. Private machines can talk to the Internet just as the NAT device would using the routable, publicly accessible IP address on the NAT device’s external interface. How is this accomplished?

1. When a NAT device receives traffic from the private network that is destined for the external network (or Internet), it first caches the details of where the packet is heading (including address and port information for both the internal source and the external destination).
2. The device then uses software to rewrite the header of the packet so that it replaces the true internal source IP address of the originating private machine with its own external IP address.
3. The device then sends the packet on to its original destination. From the destination’s point of view, the packet looks like it came directly from the NAT device. This allows a private machine to masquerade as the firewall or NAT device that is protecting it.
4. When the NAT device receives a return or response packet from the destination, it checks its NAT cache 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 will be dropped or handled according to any firewall rules operating on the device. If a match is found, the NAT device uses software to rewrite the header of the packet so that it replaces its own IP address with the internal IP address of the machine that originally sent the matching outgoing packet.
5. Finally, the NAT device sends the packet on to its internal destination. The network address translation is completely transparent to the machine on the private network. The private machine can access the Internet without the Internet being able to “see” it or communicate directly with it.

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

NAT does have some limitations. Because packets are being rewritten, any application-level protocol that requires the use of true IP addresses (such as IPSEC) will not function properly through NAT. Also, any application 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 separate FTP data connection is made from the server to the NAT device, the device won’t know what to do with it. Because NAT has become so prevalent in both home and office networks, however, people have found workarounds for many of these limitations (such as Cisco’s IOS IPSec NAT transparency and special kernel modules specifically for handling active mode FTP).

Bottom line, NAT has become a very important part of 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. On the NAT device, you can use software to forward any traffic received on a particular port on the device’s external interface to a particular port on a private internal machine. A machine on the Internet connecting to the NAT device on this port would effectively be connecting to the forwarded port on the internal machine, even though it would appear as if the Internet machine was connecting to 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 slightly more secure, you’re still relying solely on IP-based authentication. And as NAT has shown us, IP addresses on packets can easily be forged or rewritten. On many occasions, users who have built fortified, private networks can suddenly have a reason to open up a lot of their internal network resources to another remote facility. How can we allow access only from that remote facility and not the rest of the Internet? Do we really want to forward dozens of ports and open dozens of holes in our firewall? We could have the telecom companies install a dedicated data line between the two locations, but this is usually not practical. What happens down the road when other facilities also need access to the internal network? This is where Virtual Private Networks come into play.

What Are Virtual Private Networks?

Virtual Private Networks (VPNs) are a complex subject, and we will only touch on them here because so many firewall appliances come with VPN capabilities. The VPN server sits on the appliance device, usually only listening on a single port or two, waiting for connections from VPN clients. VPN clients can be software-based (so that VPNs can be established on demand from your PC just as you might do with a dial-up connection) as well as hardware-based. Remote offices will often install a firewall/VPN appliance at each site and then configure the two so that traffic can pass between the two remote networks as if they were directly connected by a dedicated data line. The only difference is that it’s a virtual data line. The traffic is still passing over the Internet, but the VPN provides many advantages and additional layers of security in comparison to a simple firewall and port forward setup.

Before VPNs can be established, some sort of authentication must usually take place. Remote users or “road warriors” may use a software VPN client and log into the VPN server to establish their connection. Hardware VPN devices will 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 privacy of the data passing between two VPN endpoints from snoopers on the Internet. Even though the data still changes hands in many different places on the Internet, it’s nearly as safe as it would be if it were passing on its own dedicated data line.

VPNs can usually forward all traffic (or as much traffic as you want) between two remote, private 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?

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 a whole lot of convenience or productivity.

What About Demilitarized Zones?

Ah, yes—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 been talking about firewalls and NAT devices that have an external interface with a public, routable IP address and an internal interface with a private, nonroutable IP address. Now, what happens if our organization has an FTP server, web server, and DNS server that we want to make publicly accessible? True, we could simply keep them on the private network and set up port forwards, but what happens if we have multiple web servers? Also, if one of the servers were to be hacked, the hacker would own a box on our private network, potentially allowing her access to all our private machines. Since we want the machines to be publicly accessible, we could just put the servers outside the firewall, but this is also a bad idea. We want our web server’s web service to be publicly accessible, but we don’t necessarily want the Internet to see anything else that might be running on it (such as SMB file sharing, for example). We need to keep these machines behind our firewall, but separate from the rest of the private network.

For this very reason, most firewall appliances come with a third network interface for what is referred to as a DMZ. In all truthfulness, the DMZ interface just allows you to hang another network of your 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. But the DMZ 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 your firewall’s external interface is on, you may be required to get a separate block of public IP addresses for your DMZ. Some appliances, such as SonicWall’s line of firewalls, 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 can be a little trickier 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 your perspective.

When Do We Get to Talk About Actual Firewall Products?

Okay, I guess we’ve gone on long enough about the basics, 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.

---

< Day Day Up >

Chapter 14: Network Reconnaissance Tools