Many companies engage in marketing hype to try to prove that their technology is better. Despite the hype, all firewall security technology can be broken down into three basic types: packet filtering (stateful or otherwise), application layer gateways, and Stateful Inspection.
Packet filters screen all network traffic at the network and transport layer of the TCP/IP packet. This means they look at source and destination IP addresses, protocol number, and, in the case of TCP and UDP, source and destination port numbers. Packet filtering is built into routers as well as some UNIX kernels. Usually, when site administrators start thinking about network security, they start with packet filtering because it is inexpensive. Most routers on the market today, even consumer-grade models, support some form of packet filtering. Because routers are needed to connect different networks together (especially when connecting to the Internet), the additional cost for using this technology is minimal. Packet filtering requires very little extra memory and processing power, so even a low-end router can handle a fairly moderate load. Packet filtering is also fairly transparent to legitimate users.
Traditional packet filtering is static, that is, the only criteria for allowing packets are whether or not the IP addresses or port numbers match those specified in the packet filter configuration. Many packet filters today implement some concept of the "state" of a connection, using a table and additional information in the TCP headers to track previously allowed packets within a connection. This makes it much easier to allow only, for instance, outbound connections from a trusted network to an untrusted network without inadvertently allowing unrelated packets from the untrusted network to the trusted network.
The biggest downside to packet filters is that they are difficult to maintain. Although this point is certainly arguable, even an expert can have trouble configuring a moderately complex set of access lists or Linux ipchains rules. Many consumer-grade routers that have packet filtering do not have an adequate interface or are very limited in what they can filter.
Packet filters also do not screen above the network and transport layers. This means they cannot do things like:
Provide content security (e.g., virus scanning or filtering based on specific sites and Web pages accessed)
Authenticate services (i.e., make sure only authorized users use a service)
Dynamically open and close ports for applications as they require them (necessary for applications like RealAudio, FTP, and H.323 applications)
Validate a particular port that is used only for a specific service (e.g., making sure that only valid HTTP traffic traverses port 80)
Application layer gateways, also known as proxies or application proxies, take requests from clients and make them connect to servers on the client's behalf. In some cases, the client explicitly connects to the proxy server. In other cases, the proxy intercepts the connection with help from the underlying operating system or network architecture. Because an application proxy is usually specific to the network service, it can be fully aware of the session. This means the proxy can do content screening, provide authentication, and ensure that only the particular service is used (e.g., an HTTP proxy can make sure that only HTTP traffic is allowed through), or it can provide other application-specific services such as caching. It also provides a well-formed connection to servers on the other side of the firewall because it opens up connections on behalf of the clients.
However, this extra capability comes at a price. Application proxies require memory and CPU cycles just like any other application. Generally speaking, application proxies use more memory and CPU cycles than packet filtering, although how much they use depends on the specific circumstances. If you want to use application proxies to provide services to the Internet, each application you want to run through your firewall must have a proxy written for it, or the application must be compatible with a "generic" proxy that will work with simple TCP or UDP connections. Because many applications are not being developed to work with an application proxy, some applications simply cannot be proxied. The client/server model is somewhat broken by application proxies because the application proxy will always originate the connection from the server's point of view. In large environments, the poor throughput of application proxies is another drawback.
 Some would argue that this is actually not a problem. Whether or not this is a problem depends on the specific application and what you are trying to track down.
Another important drawback of a proxy, particularly for internal use, is that it becomes very difficult to track who is going where for how long because the proxy often masks the original source or destination of the traffic. You might be able to track this on the firewall, but from any other vantage point on the network, how do you know?
Stateful Inspection combines the best features of stateful packet filtering and application layer gateways. Check Point's Stateful Inspection engine rests be tween the data link and network layers (e.g., between the network interface card and the TCP/IP driver). TCP/IP packets from the network layer and higher are scanned according to your security policy and will be either allowed through or stopped. The TCP/IP stack will not see dropped or rejected packets, which can provide an extra layer of protection. Stateful Inspection can look at the entire packet and make security policy decisions based on the contents and the context of the packet, using a state table to store connection state and using knowledge of how specific protocols are supposed to operate. In the case of FTP, FireWall-1 can dynamically open ports between two hosts so that the communication will succeed and then close the ports when the connection is done. Stateful Inspection is what gives FireWall-1 "Application Intelligence" (e.g., NG with Application Intelligence, or NG AI).
Stateful Inspection requires slightly more memory and CPU cycles than packet filtering because it has to do more, but it takes substantially less memory and CPU usage than does an application proxy. Stateful Inspection is best when the engine is made aware of how a protocol functions, although Check Point does not make use of Stateful Inspection for every protocol. Because Stateful Inspection does track connection state regardless of the service, it is better than a packet filter, but you are limited to opening specific ports and allowing the traffic through without further checking.
It is useful to compare how the different technologies handle complex connection types. One such connection type is Passive FTP, which is used by Web browsers when they initiate an FTP connection. Passive FTP requires:
A TCP connection from a client to port 21 on the FTP server.
A TCP connection from a client to some random high port on the FTP server for data communication. The ports used for this communication are communicated to the client when it requests passive mode via the PASV command.
For this comparison, assume that the FTP server is behind your firewall and that you need to allow people on the Internet to FTP to this machine.
Packet filtering can handle standard FTP quite nicely because it uses fixed TCP ports (20 and 21). However, in order to allow Passive FTP, the packet filter has to open all TCP ports above 1024 to allow Passive FTP to work with the FTP server. This is a gaping hole that can be used by programs other than FTP to compromise your systems.
An application proxy is aware of the FTP connection and opens all the necessary ports and connections to complete the FTP connection. However, each TCP or UDP connection through an application proxy requires twice the normal number of connections on the proxy server (one for each side of the connection). A normal Passive FTP connection requires two open connections on a client machine. On the application layer gateway, this translates to four open TCP connections.
Most operating systems have a limit to the number of simultaneous connections they can handle. If enough connections are going through the machine at the same time, this limit will be reached, and no further connections will be allowed through. In high-performance, high-capacity networks, using a proxy for FTP connections is simply asking for trouble.
Stateful Inspection understands connection context. When the PASV command is sent from the client to the server, Stateful Inspection reads the server's response and opens the ports necessary to complete the connection. It also restricts the IP addresses that can use these ports to the client and server. The connection then goes through the firewall normally. Because Stateful Inspection allows the native operating system to route, no connections are established on the firewall itself. Once the connection is terminated, the ports opened by the PASV command are closed.
Traceroute is used to show the particular path a connection will take through the various routers and gateways within the network and gives you a basic idea of the latency between any two hosts on a network. It is a common troubleshooting tool used by network administrators. There are two varieties of traceroute: UDP and ICMP. UDP traceroute is used by almost every UNIX implementation. ICMP traceroute is typically used by Microsoft operating systems, though some UNIX implementations also allow you to perform an ICMP traceroute. How traceroute functions can be used to show the strengths of Stateful Inspection and the weaknesses of packet filters and application proxies.
UDP traceroute involves sending out packets to high-numbered ports above 31000?the actual ports used will vary based on the implementation. ICMP traceroute uses ICMP Echo Requests instead. In both cases, the client generates a number of packets (usually three) over a period of time (usually one second) to the server using a time to live (TTL) value of 1. Each subsequent set of packets will have an increasingly higher TTL value, which allows the packets to get closer and closer to the server.
During a traceroute session, any of the following can occur.
The server responds with an ICMP Echo Reply message or an ICMP Port Unreachable packet (i.e., the traceroute has finally reached the server).
An intermediate router or gateway gets a packet with a TTL value of 1; it decrements the TTL to 0. Because a router or gateway cannot route a packet with a TTL of 0, it sends back an ICMP Time Exceeded message.
An intermediate router or gateway determines it has no route to the server and sends back an ICMP Destination Unreachable message.
An intermediate router or gateway fails to respond either because it is configured to not respond to or pass traceroute traffic or because it is down.
The client decides it has sent too many sets of traceroute packets (the default is 30) and stops.
For any firewall solution to securely allow traceroute through, it must take all of these situations into account. Let's explore how each of the firewall technologies can address passing traceroute.
 Most firewall administrators do not want to allow traceroute into their network from the outside but do wish to allow internal hosts to initiate it outbound and then allow only appropriate reply traffic back in.
With packet filtering, you would have to allow the following types of traffic to pass through your packet filter:
All UDP ports above 31000
ICMP Echo Request
Conversely, you would also have to allow the following types of packets to enter your network from any host:
ICMP Echo Reply
ICMP Time Exceeded
ICMP Destination Unreachable
ICMP Port Unreachable
Although these rules would allow legitimate traceroute traffic, they can also allow network access by packets that were not in response to a valid traceroute request. In the past, these kinds of unsolicited packets were used in denial-of-service (DoS) attacks. It is important that you allow in only those packets that are in response to a traceroute or ping query. Packet filtering alone is not an adequate tool to allow traceroute to function yet protect you from possible DoS attacks. It is important to note that the UDP ports allowed could also be used for something other than traceroute.
UDP can be proxied to some degree, but due to its nature, ICMP cannot be proxied, though some versions of SOCKS can proxy ICMP using special SOCKS-aware ICMP programs. In a relatively small, controlled, homogeneous environment, this may be feasible. In a large, heterogeneous environment protected by application proxies, it may not be possible to allow all clients to trace route through the firewall.
With Stateful Inspection, you can watch for either a UDP packet with a low TTL value or an ICMP Echo Request packet coming from a particular client. Once this happens, you can temporarily permit the necessary ICMP packets to return to the client initiating the outgoing traceroute request. After you have received the appropriate response (i.e., an ICMP Echo Reply, Port Unreachable, or Destination Unreachable message) and/or after a specific period of time (e.g., 60 seconds), you can stop allowing the necessary ICMP packets to the client.
FireWall-1 statefully inspects ICMP.