Stateful Packet Inspection

Our firewalls come with a default security policy which blocks all "inbound" connections (from the Internet to the LAN), and allows all "outbound" connections (from the LAN to the Internet). The desired effect is that LAN users can continue to access Internet resources, while hackers on the Internet cannot access the internal LAN resources.

Our firewalls provide this protection as a network appliance. Since user-level applications such as FTP and the Web can create complex patterns of network traffic, it is necessary for the firewall to analyze groups of network connection "states".

A central cache within the firewall keeps track of the state information associated with all network connections. All traffic passing through the firewall is analyzed against the state of these connections in order to determine whether or not it will be allowed to pass through or rejected.

Below is a brief technical description of how these connections are tracked. Connections may either be defined by the upper protocols (for instance, TCP), or by the firewallitself (as with the "virtual connections" created for UDP and ICMP).

TCP Security
Our firewalls use the state information embedded in TCP packets. The first packet of any new connection has its SYN flag set and its ACK flag cleared; we call these "initiation" packets. All packets which do not have this flag structure are called "subsequent" packets, since they represent data which occurs later in the TCP stream.

If an initiation packet originates on the WAN, this means that someone is trying to make a connection from the Internet into the LAN. Except in a few special cases (see "Upper Layer Protocols" below), these packets are dropped and logged.

If an initiation packet originates on the LAN, this means that someone is trying to make a connection from the LAN to the Internet. Assuming that this is an acceptable part of the security policy (as is the case with the default policy), the connection will be allowed through. A cache entry is added which includes connection information such as IP addresses, TCP ports, sequence numbers, etc.

When any subsequent packet hits the box (from the Internet or from the LAN), its connection information is extracted and checked against the cache. A packet is only allowed to pass through if it corresponds to a valid connection (that is, if it is a response to a connection which originated on the LAN).

UDP/ICMP Security
UDP and ICMP do not themselves contain any connection information (such as sequence numbers). However, at the very minimum, they contain an IP address pair. UDP also contains port pairs, and ICMP has type and code information. All of these data can be analyzed in order to build "virtual connections" in the cache.

For instance, a cache entry will be created by any UDP packet which originates on the LAN. Its IP address and port pairs will be stored. For a short period of time, UDP packets from the WAN which have matching IP and UDP information will be allowed back in through the firewall.

An analogous situation exists for ICMP, except that our firewall is even more restrictive. Specifically, only outgoing echoes will allow incoming echo replies, outgoing address mask requests will allow incoming address mask replies, and outgoing timestamp requests will allow incoming timestamp replies. No other ICMP packets are allowed in through the firewall, simply because they are too dangerous and contain too little tracking information. For instance, ICMP redirect packets are never allowed in, since they could be used to reroute traffic through attacking machines.

Upper Layer Protocols
Some higher layer protocols (such as FTP and RealAudio) utilize multiple network connections simultaneously. In general terms, they usually have a "control connection" which is used for sending commands between endpoints, and then "data connections" which are used for transmitting bulk information.

Consider the FTP protocol. A user on the LAN opens a control connection to a server on the Internet and requests a file. At this point, the remote server will open a data connection from the Internet. For FTP to work properly, this connection must be allowed to pass through even though a connection from the Internet would normally be rejected.

In order to achieve this, our firewalls inspect the application-level FTP data. Specifically, it searches for outgoing "PORT" commands, and when it sees these, it adds a cache entry for the anticipated data connection. This can be done safely, since the PORT command contains address and port information which can be used to uniquely identify the connection.

Any protocol which operates in this way must be supported on a case-by-case basis