In the esoteric sense, components of a firewall exist in the mind of the person constructing them. A firewall, at its inception, is a concept rather than a product; it's the idea surrounding the access control mechanism that enables traffic to and from your network.

In the more general sense, a firewall consists of software and hardware. The software can be proprietary, shareware, or freeware. The hardware can be any hardware that supports the software.

Firewall technologies can generally be classified into one of three categories:

· Packet-filter–based (usually routers, Cisco IOS, and so on)

· Stateful packet-filter–based (Checkpoint FW-1, PIX, and so on)

· Proxy-based (NAI Gauntlet, Axent Raptor, and so on)

Let's briefly examine each.

Packet-Filter–Based Firewalls

Packet filtering firewalls are typically routers with packet-filtering capabilities. Using a basic packet-filtering router, you can grant or deny access to your site based on several variables, including

· Source address

· Destination address

· Protocol

· Port number

Router-based firewalls are popular because they're easily implemented. (You simply plug one in, provide an access control list, and you're done.) Moreover, routers offer an integrated solution. If your network is permanently connected to the Internet, youneed a router anyway. So, why not kill two birds with one stone?

On the other hand, router-based firewalls have several deficiencies. First, they usually aren't prepared to handle certain type of denial of service attacks. Many of the denial of service tactics used on the Internet today are based on packet mangling, SYN flooding, or forcing other TCP/IP-based anomalies. Basic routers aren't designed for handling these types of attacks. Second, most routers can't keep track of session state data. Administrators are forced then to keep all ports above 1024 open in order to handle TCP sessions and session negotiations properly. Although this is arguably not a huge security concern (because there shouldn't be any listening services running on those ports anyway), it's not generally a good practice to leave unused ports open to the outside.

Finally, using ACLs (access control lists) on high-end routers that are supporting extremely busy networks can contribute to performance degradation and higher CPU load. However, for most low-speed connections (such as T1 circuits) on lower-end routers (such as Cisco 2500 series routers), normal packet filtering will not tax the router to any significant degree.

Note

For a long time, it was believed that putting access control lists (ACLs) on routers would greatly degrade their performance. Although sticking a 100 rule ACL on a Cisco 7000 supporting a dozen ATM connections might not be the best of ideas, placing basic ACLs on routers supporting low-speed (10Mbps or lower) connections doesn't usually degrade their performance noticeably. Two members of the underground, rfp and NightAxis, published some basic findings on this subject that can be found at http://www.wiretrip.net/rfp/. Since then, other studies have also been performed (your mileage can vary). Remember, even the low-end Cisco 2500 series routers were based on Motorola 68030 and 68040 chip sets, and the newer ones are using even more advanced RISC-based chips. Routers are more powerful then many people give them credit for. Test it yourself—see what you find.

Tip

Many network administrators will use ACLs on their perimeter routers in conjunction with a more advanced firewall to create a multitier approach to network access control.

Stateful Packet-Filter–Based Firewalls

Stateful packet filtering builds on the packet filtering concept and takes it a few steps further. Firewalls built on this model keep track of sessions and connections in internal state tables, and can therefore react accordingly. Because of this, stateful packet-filtering–based products are more flexible than their pure packet-filtering counterparts. In addition, most stateful packet-filtering–based products are designed to protect against certain types of DoS attacks, and to add protection for SMTP-based mail and an assortment of other security-specific features.

Checkpoint pioneered the technique called "stateful inspection" (SI), which takes stateful packet filtering up one notch. SI enables administrators to build firewall rules to examine the actual data payload, rather then just the addresses and ports.

Note

Because stateful packet-filtering–based firewalls track session states, they can keep the ports above 1024 closed by default and only open the high ports on an as-needed basis. As simple as this might sound, this is why most administrators consider stateful packet filtering to be the minimum technology they will implement for their firewall solutions.

Proxy-Based Firewalls

Another type of firewall is the proxy-based firewall (sometimes referred to as an application gateway or application-proxy). When a remote user contacts a network running a proxy-based firewall, the firewall proxies the connection. With this technique IP packets are not forwarded directly to the internal network. Instead, a type of translation occurs, with the firewall acting as the conduit and interpreter.

How does this differ from stateful packet filtering and generic packet filtering, you ask? Good question—and one that many people ask. Both packet filters and stateful filtering processes examine incoming and outgoing packets at the network and session levels. They examine IP source and destination addresses along with ports and status flags, compare them to their rule sets and table information, and then decide whether the packet should be forwarded. Proxy-based firewalls, on the other hand, inspect traffic at the application level in addition to lower levels. A packet comes into the firewall and is handed off to an application-specific proxy, which inspects the validity of the packet and application-level request itself. For example, if a Web request (HTTP) comes into a proxy-based firewall, the data payload containing the HTTP request will be handed to an HTTP-proxy process. An FTP request would be handed to an FTP-proxy process, Telnet to a Telnet proxy process, and so on.

This concept of a protocol-by-protocol approach is more secure then stateful and generic packet filtering because the firewall understands the application protocols themselves (HTTP, FTP, SMTP, POP, and so on). It's more difficult for intruders to sneak past something that is watching more than just the ports and IP addresses. However, notice that I used the word "concept" in reference to it being more secure. The truth of the matter is that in real-world applications, this approach has had its fair share of problems.

Proxy-based firewalls have always been slower then stateful packet-filtering–based ones. Now, for most networks (10Mbps or slower), this difference is moot. However, for heavily loaded networks (T3s at 45Mbps, multiple T3s approaching 100Mbps, and so on), this becomes a much larger issue. As technology improves, the gap might close, but for now the use of pure proxy-based technology is still a concern for high-volume networks.

In addition to the performance problem, the proxy-based solution also has some adaptability issues. Suppose, for example, that a new protocol is invented to manage your coffeemakers at home. For the sake of example, we'll call this protocol the Percolation Control System, or PCS for short. Now, let us also assume that PCS uses TCP and runs over port 666. Administrators of stateful packet-filtering–based firewalls will simply have to build a new rule into their firewall allowing traffic over TCP on port 666, and it's a done deal. Administrators of proxy-based firewalls, however, have a new problem: They don't have a proxy (yet) for PCS. It's a brand new protocol. Although some proxy-based firewalls (such as NAI's Gauntlet) have a generic proxy for such problems, now we're back to basic packet filtering, which defeats the purpose of having a proxy to begin with.

However, taking this example one step further, let's say the proxy-based firewall vendor eventually writes a PCS-proxy, and all is well in Coffeeville. Soon after, some mischievous helpdesk contractors resurrect their old copies of network DOOM, which also runs over port 666, and they attempt to start abusing an old addiction. Low-and-behold, network DOOM won't make it through the proxy-based firewall, but it will through the stateful packet-filtering–based one.