Choosing a Personal Firewall

Discover everything you never knew about personal firewalls and how you can choose the one that is best for you. You will learn the growing features of personal firewalls and how those features will better protect you.

This chapter is from the book 

This chapter is from the book

Personal Firewalls for Administrators and Remote Users

Learn More Buy

This chapter is from the book

This chapter is from the book 

Personal Firewalls for Administrators and Remote Users

Learn More Buy

Personal firewalls make use of all the same methods as more robust, and expensive, enterprise firewalls. However, they simplify the operation of the product to meet the needs of a less technically savvy consumer. Where an enterprise firewall may require full-time supervision, a personal firewall is often installed and forgotten.

In order to better understand how personal firewalls work, we're going to examine each of the current standard firewall methods individually: network address translation, static packet filtering, stateful inspection, and application proxy. Personal firewalls often combine these standard methods to provide a more complete product, and even include additional features such as blocking on attack signature and intrusion detection.

We also briefly touch on a new effort to certify personal firewalls. It is believed that consumers will benefit from certified products, knowing that they have been compared against a set standard.

Network Address Translation

I would like to start off by saying that network address translation, or NAT, is not a firewall. NAT was never meant to protect computers. Network address translation is a method used to allow many computers to connect to the Internet with one (or few) public IP addresses. In essence, NAT is used when the number of hosts that need Internet access exceeds the number of public IP addresses that an organization has been assigned. The internal IP addresses come from a private pool as designated by RFC 1918, and a NAT device translates those private IP addresses to a public IP address that is routable on the Internet. The NAT device keeps track of the translations in an address translation table.

Private Address Ranges

RFC 1918 reserves these three address ranges for private use:

10.0.0.0–10.255.255.255 (10/8 prefix)

172.16.0.0–172.31.255.255 (172.16/12 prefix)

192.168.0.0–192.168.255.255 (192.168/16 prefix)

As an example of how this works, let's take your computer with an IP address of 10.1.1.1. This address is not routable on the Internet, based on the rules laid out in the RFC. In order for you to communicate outside your own network, you must route your traffic through a NAT device (NAT-capable firewall, router, switch, etc.). The NAT device then takes your IP packet, from 10.1.1.1:12345 to http://www.example.com:80, and translates your address to your routable IP address of 224.1.1.1:12346 (see Figure 3–1). When traffic returns from http://www.example.com:80 destined for 224.1.1.1:12346, the NAT device knows to forward it to

FIGURE 3–1 Dynamic translation. Host A with an IP address of 10.1.1.1:12345 requests the Web page http://www.example.com:80. The router translates this address to the public IP address of 224.1.1.1:12346 and sends the packet on to http://www.example.com:80.

10.1.1.1:12345 (Figure 3–2). It is the combination of address and port that ensures traffic gets back to the correct requesting host. Once the communication session has ended, the table entry is deleted. This type of translation is dynamic.

FIGURE 3–2 Dynamic translation. The host http://www.example.com:80 sends its reply to 224.1.1.1:12346. The router translates this back to the private address of 10.1.1.1:12345 and sends the packet on.

Static NAT is also possible and is used to allow contact to a specific host behind the NAT device. Static NAT would be used in the case of a Web server that has a private IP address but needs to be contacted by Internet users. The NAT device would have a specific translation defined for the Web server. For example, internally the Web server may be known as 10.1.1.2, but externally as 224.1.1.2. When Internet traffic is seen for 224.1.1.2, the NAT redirects it to 10.1.1.2. (Figure 3–3)

FIGURE 3–3 Static translation. The host lisa.example.com:12356 tries to contact 224.1.1.2:80. The router translates the public address to the private IP address of 10.1.1.2:80 according to the defined table and passes the packet on. When traffic returns from 10.1.1.2:80 for lisa.example.com:12356, the router will change the private IP address back to the public IP address of 224.1.1.2

Dynamic NAT provides some protection for users behind the NAT device. When the translation tables are dynamic, there is no easy way for an external user (on the Internet) to initiate contact with a host behind the NAT device since the table entry is created when the internal host initiates an outgoing session and is deleted at the end of that session. Static NAT provides no real protection for the hosts behind it. Direct communication can be initiated with hosts having static translation information.

How NAT Is Implemented in Personal Firewalls

In order to perform network address translation, you must begin with a device that is able to route traffic from one network to another. This device will be "multi-homed," having one network connection on the private network and one on the public network. In addition to routing, this device will translate addresses from private to public. It uses a table to keep track of the translations.

Personal firewall software itself doesn't usually perform these functions. Some early hardware devices marketed as firewalls really only performed NAT, though. You still can find hardware devices that rely primarily on NAT as their method of protection. The consumer must be aware of how NAT works in order to judge whether this technology provides adequate protection.

Typically you find NAT functionality in a hardware router. Companies like Linksys, 3COM, SMC, Netgear, and even Cisco have products for the home market. Using a hardware device is simple since devices targeting home users generally come preconfigured for dynamic NAT. The device can serve out private IP addresses to the hosts connected to its internal network ports and it gets its public IP address from your Internet service provider. So, simply plug everything in and you're up and running in a dynamic NAT state. Dynamic NAT, as stated earlier, does provide a measure of security. It is difficult to establish a connection where the NAT mappings change regularly.

Static NAT requires more configuration. If you do wish to allow external hosts to connect to something on your private network, you will need a static route to provide the pathway. You would do this if you have a Web or mail or FTP server that you want others to be able to connect to. Static mapping is required to allow anyone to connect back in to one of your hosts.

If you can control the static mapping by port—only mapping traffic on port 80 back to the Web server, for example—it is better than having to map all traffic back to the Web server then hoping your host won't respond to requests on other ports. You are still at risk for non-HTTP applications tunneled over port 80.

If you cannot control the static mapping by port (eek), any type of traffic can be directed at your host. Hosts listen on the darndest of ports—ports you wouldn't expect. You can use netstat –an to see which ports your host is listening on in both Windows and Linux. The following is a sample from a default install of Windows XP.

C:\ >netstat -an
Active Connections
Proto   Local Address        Foreign Address    State
TCP     0.0.0.0:135          0.0.0.0:0          LISTENING
TCP     0.0.0.0:445          0.0.0.0:0          LISTENING
TCP     0.0.0.0:1025         0.0.0.0:0          LISTENING
TCP     0.0.0.0:1030         0.0.0.0:0          LISTENING
TCP     0.0.0.0:5000         0.0.0.0:0          LISTENING
TCP     69.254.132.171:139   0.0.0.0:0          LISTENING
UDP     .0.0.0:68            *:*
UDP     .0.0.0:135           *:*
UDP     .0.0.0:162           *:*
UDP     .0.0.0:445           *:*
UDP     .0.0.0:1026          *:*
UDP     .0.0.0:1029          *:*
UDP     .0.0.0:1035          *:*
UDP     .0.0.0:1174          *:*
UDP     27.0.0.1:123         *:*
UDP     27.0.0.1:1900        *:*
UDP     69.254.132.171:123   *:*
UDP     69.254.132.171:137   *:*
UDP     69.254.132.171:138   *:*
UDP     69.254.132.171:1900  *:*

Pretty interesting the number of ports that are waiting for connections by default. Ports 135, 139, and 445 are used to allow file sharing on Windows systems. They are automatically opened, even on this host with no internal network. Add to this concern the fact that Windows boxes also have administrative shares automatically created, and you learn why it is so dangerous to connect a Windows computer up to the Internet without some form of protection.

Who knows what application some of the ports identified as listening relate to. So, if you allow all traffic to your static NATed box, an external user could connect to an open share or some other unidentified application, unless you take other steps to protect your machine.

Let's look at a specific product. I have an older Linksys EtherFast Cable/DSL router at home. This product primarily performs NAT, allowing me to connect more than one computer to the Internet simultaneously. It assigns internal, private IP addresses using Dynamic Host Configuration Protocol (DHCP). I can filter outgoing connections, denying everything to specific IP addresses (destination IP 1.2.3.4 deny all), or denying specific ports to all IP addresses (destination any deny port 80). I can configure static mappings to specific port ranges and IP addresses or place specific IP addresses in "DMZ hosting" mode and allow all ports to that host (no restrictions). And all this is configured through a simple Web interface. I can get it up and running in dynamic NAT mode without any of the fancy options by simply plugging it in.

Sounds marvelous, doesn't it? We should be concerned about all this functionality, though. For one, no risk information is given in the manual for any features available. So, in the end it's up to you, the end user, to know what is happening and where there is risk.

There is no configuration screen on the Web interface for dynamic NAT, this just happens automatically. For static NAT, you use either the forwarding configuration settings or the DMZ hosting settings. Forwarding allows you to take traffic destined for a particular port on the public interface of the router, say traffic to port 80, and forward it through to a host on the private side of your router (Table 3–1). Setting a DMZ host, on the other hand, allows all traffic destined to your router to be passed on to the internal host.

TABLE 3–1 NAT Forwarding

Let's review the risks, starting with the administration interface itself. First, the administration page is accessible with a published password. The documentation does encourage you to change this password. Question to you—will you change it? I've met IT professionals who fail to set or change default passwords, so I'm afraid I don't hold out much hope for the rest of the world.

The administration interface can be set to allow remote (i.e., over the Internet) configuration. Can you think of any problems with enabling this feature? Well, first off, did you set a password on the administration interface? Good, you did. How hard will it be to crack that password? That easy, huh? I was afraid of that. Remote management of your router should be seriously considered before being enabled. The only control over who can administer your router remotely is the password. If I find your router, and I guess the password (say, the default password—admin), I own your router. I can change the settings to put all your hosts into the "DMZ hosting" mode and then I can connect to them however I want. If you're an average, everyday computer user who simply set up the router and forgot about it, when do you think you'll figure out that I changed the settings on your router remotely? Maybe when someone complains that your host has hacked him or her. Maybe not even then.

The DMZ hosting feature is designed to allow a host to quickly and easily use an Internet service such as gaming or video conferencing. Rather than trying to sort out the correct packet filters (if it's even possible), you just allow all ports to a host. My attempt to be a hacker in the remote management paragraph above is a little inaccurate, then. I could only place one host on your internal network in the DMZ, not all of them. That should make you sleep better. You do recognize sarcasm, right?

So, if you really, really, really need to play Internet games or videoconference, you will need to enable the DMZ hosting feature for the one computer from which you will be performing these tasks. I wouldn't leave this feature enabled all the time, though; you should definitely deactivate the DMZ when you are done with your games. To be honest, I wouldn't even activate the DMZ feature unless I had another method of protection for my host (like a software firewall running on it). Call me paranoid. OK, to come completely clean, I even run a personal firewall on my computer at work (which is behind a corporate firewall) so I guess I am paranoid.

Those are my two big concerns with my Linksys, really. Remote configuration protected only by a password and this DMZ stuff that ends up being no protection for a specific host while it is enabled. Don't get me wrong, I love my Linksys router, it does exactly what I need it to do. I just don't want you to choose this device, or any other one like it, until you understand how it works. You might want more protection than network address translation can provide.

Another big factor for me is logging. Can a NAT device log? Of course. Are the logs of any value? That's a little more difficult to answer. The good news, for me, is that my router will log and can send those logs to a remote device. Great. In fact, my router logs incoming and outgoing traffic to separate files. Let's see what the outgoing log looks like.

Date         Time         Src            Src_Port   Dest                 Dest_Port
05/31/2002   12:13:24     192.168.1.100  4121       Webssl.example.com   443
05/31/2002   14:07:50     192.168.1.100  4135       Qtpix.apple.com      80
05/31/2002   14:07:52     192.168.1.100  4137       a772.g.akamai.net    80
05/31/2002   14:08:53     192.168.1.100  4138       Webssl.example.com   443

Knowing what is coming and going doesn't necessarily tell me anything useful. Will I recognize a Nimda scan entering or exiting with this information? No. I'll only know that a packet destined for port 80 traveled through the router. The ability to capture the full packet would be much more useful. We'll discuss logs in detail in a later chapter.

Products That Use This Method

We know that the Linksys Cable/DSL router employs NAT. It is an easy, inexpensive hardware device, and there are others like it available from various manufacturers. What other products are there? You can get more sophisticated devices—hardware appliances like a Netscreen or Pix firewall, for example—but now you start playing with the big guys—we've left the realm of personal firewalls far behind.

Cisco has products aimed at the home market with a firewall that can be purchased as an option. A basic 800 series router goes one step beyond NAT when you purchase the firewall option. However, you need to understand Cisco IOS to configure the router and firewall. For the corporate users out there, this may make sense, both from the expense and expertise perspectives. A hardware device that builds the VPN tunnel back to the corporate office, forcing all network traffic through the tunnel, might be even more useful for a corporate environment. This device effectively cuts off traffic from the outside world, and could allow such wonderful features as remote control of the home devices by corporate IT staff.

Network address translation is available in software as well. Typically, the functionality is part of the operating system, but it may need to be configured. Windows 2000 and XP have the Internet Connection Sharing (ICS) feature that works much like NAT. The documentation doesn't really cover any security aspects of this feature, though. The notes actually say that you must disable any personal firewall software you have running; no specifics are given on whether this is just on the ICS host, the clients, or both. Newsgroup postings mention that Internet Security System's BlackICE_ Defender, now called BlackICE_ PC Protection, does work with ICS, but others may have problems. Think long and hard before traveling down this road. Table 3–2 lists some NAT product options.

Linux provides a function called IP masquerade, or ipmasq. Ipmasq allows for dynamic NAT, or what the documentation refers to as one-to-many NAT. Static NAT is not possible with this package. The function is tied in with the firewall packages of ipchains and iptables, although it can be enabled without using any of the firewall's packet filtering features.

TABLE 3–2 NAT Product Options

Advantages

One nice thing about a hardware device NAT is that it is platform-independent. You can plug any host in, request the IP configuration (DHCP client), and it will communicate. The NAT device is just passing packets. Really, the same can be said of any hardware-based firewall solution. As long as the firewall box is separate from your client boxes, it can manage the traffic for any operating system. So, if you have a network consisting of multiple operating systems at home, here's one product that will look after all of them, if your risk assessment will allow you to use NAT only.

Network address translation provides a way for multiple hosts to share a single IP address. In reality, this is why NAT exists; this is the problem NAT was meant to solve. That you gain any amount of protection from the "bad guys" through NAT is really just a side effect. As long as you require this functionality, NAT will have a place in your environment.

With the hardware devices being sold to the home market, NAT is fast, simple, and forgettable. It might actually even be enough protection for you. At the very least, you could probably argue that by employing NAT you were trying to protect your resources if you found you ever needed to defend yourself to someone else.

Disadvantages

Static NAT alone provides no protection. If you provide a static translation, then your internal host is no longer protected—you have given hosts on the Internet a way to contact your host directly. It is at this point that all the arguments about NAT making you invisible fall apart. And if you aren't invisible on the Internet, you are asking for someone to take advantage of your resources.

What about the ability to block outgoing traffic? NAT alone cannot do that for us. NAT does not really block traffic at all; it just doesn't know where to send requests from the Internet. This inability to block outgoing traffic leaves you vulnerable to anything that can be installed on your system that then connects out. Something like a virus that's designed to call home and hold a connection open might allow for remote control of your system.

Where NAT Fits in the Design of a Secure Environment

A NAT device at the perimeter is a good place to start. Think of network address translation as a networking technology, a communication enabler, rather than firewall. NAT provides some protection, but it was not designed to satisfy a security need; it was designed to solve a networking problem (see Figure 3–4).

FIGURE 3–4 Network design with NAT. Multiple internal hosts are connected to the Internet by a hardware device that performs dynamic network address translation. It is hoped that this way the internal hosts can remain invisible to the Internet.

It's true, for many home users NAT may be all they need. I have a NAT device, and my personal firewall software is remarkably quiet; I am obviously being protected. With no picture of what is leaving my network, though, I worry. If an infection by a virus opens a back door, my NAT device doesn't protect me.