Stateful firewall

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 67.184.129.23 (talk) at 01:51, 28 December 2010 (Fixing typos). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

In computing, a stateful firewall (any firewall that performs stateful packet inspection (SPI) or stateful inspection) is a firewall that keeps track of the state of network connections (such as TCP streams, UDP communication) travelling across it. The firewall is programmed to distinguish legitimate packets for different types of connections. Only packets matching a known connection state will be allowed by the firewall; others will be rejected.

Early attempts at producing firewalls operated at the application level of the seven-layer OSI model but this required too much CPU speed. Packet filters operate at the network layer (layer-3) and function more efficiently because they only look at the header part of a packet. However, pure packet filters are stateless - they have no memory of previous packets - which makes them vulnerable to spoofing attacks.

History

Credit to the inventor of the stateful firewall is usually given to Nir Zuk and his team at Check Point in the mid-1990s.[1][2]

Before the advent of stateful firewalls, a stateless firewall, a firewall that treats each network frame (or packet) in isolation, was normal. Such a firewall has no way of knowing if any given packet is part of an existing connection, is trying to establish a new connection, or is just a rogue packet. Modern firewalls are connection-aware (or state-aware), offering network administrators finer-grained control of network traffic.

The classic example of a network operation that may fail with a stateless firewall is the File Transfer Protocol (FTP). By design, such protocols need to be able to open connections to arbitrary high ports to function properly. Since a stateless firewall has no way of knowing that the packet destined to the protected network (to some host's destination port 4970, for example) is part of a legitimate FTP session, it will drop the packet. Stateful firewalls solve this problem by maintaining a table of open connections and intelligently associating new connection requests with existing legitimate connections.

Description

A stateful firewall is able to hold significant attributes of each connection in memory, from start to finish. These attributes, which are collectively known as the state of the connection, may include such details as the IP addresses and ports involved in the connection and the sequence numbers of the packets traversing the connection. The most CPU intensive checking is performed at the time of setup of the connection. All packets after that (for that session) are processed rapidly because it is simple and fast to determine whether it belongs to an existing, pre-screened session. Once the session has ended, its entry in the state-table is discarded.

The stateful firewall depends on the three-way handshake of the TCP protocol when the protocol being used is TCP; when the protocol is UDP, the stateful firewall does not depend on anything related to TCP. When a client initiates a new connection, it sends a packet with the SYN bit set in the packet header. All packets with the SYN bit set are considered by the firewall as NEW connections. If the service which the client has requested is available on the server, the service will reply to the SYN packet with a packet in which both the SYN and the ACK bit are set. The client will then respond with a packet in which only the ACK bit is set, and the connection will enter the ESTABLISHED state. Such a firewall will pass all outgoing packets through but will only allow incoming packets if they are part of an ESTABLISHED connection, ensuring that hackers cannot start unsolicited connections with the protected machine.

In order to prevent the state table from filling up, sessions will time out if no traffic has passed for a certain period. These stale connections are removed from the state table. Many applications therefore send keepalive messages periodically in order to stop a firewall from dropping the connection during periods of no user-activity, though some firewalls can be instructed to send these messages for applications. It is worth noting that the most common Denial of Service attack on the internet these days is the SYN flood, where a malicious user intentionally sends large amounts of SYN packets to the server in order to overflow its state table, thus blocking the server from accepting other connections.[citation needed]

Many stateful firewalls are able to track the state of flows in connectionless protocols, like UDP. Such sessions usually get the ESTABLISHED state immediately after the first packet is seen by the firewall. Sessions in connectionless protocols can only end by time-out.

By keeping track of the connection state, stateful firewalls provide added efficiency in terms of packet inspection. This is because for existing connections the firewall need only check the state table, instead of checking the packet against the firewall's rule set, which can be extensive. Also, the concept of deep packet inspection is unrelated to stateful firewalls, because of its stateful feature, which checks incoming traffic against its state table first instead of jumping to the firewall's rule set. In this case if the state table is matched, then it doesn't need deep packet inspection.

Application-level filters

However, packet filtering alone is not regarded as providing enough protection. In order to effectively block peer-to-peer-related network traffic, what is needed is a firewall that does application filtering, which can be regarded as an extension to stateful packet inspection. Stateful packet inspection can determine what type of protocol is being sent over each port, but application-level filters look at what a protocol is being used for. For example, an application-level filter might be able to tell the difference between HTTP traffic used to access a Web page and HTTP traffic used for file sharing, whereas a firewall that is only performing packet filtering would treat all HTTP traffic equally.

Application layer firewalls differ from stateful packet-filtering and circuit-level gateways in several ways. Application-layer firewalls support multiple application proxies on a single firewall. The proxies sit between the client and server, passing data between the two endpoints. Suspicious data is dropped and the client and server never communicate directly with each other. Because application-level proxies are application-aware, the proxies can more easily handle complex protocols like H.323, which is used for videoconferencing and VoIP (Voice over IP). Application proxies can be transparent to the client and server, as no configuration is required on the client or the server; or can be non-transparent, letting the client and server address the proxy server directly. Transparency versus non-transparency is a matter of implementation and address hiding, rather than about security.

Pitfalls

Incompatibilities

Microsoft's latest operating systems, Windows 7 and Windows Vista, use TCP window scaling for non-HTTP (web) connections. So do Linux kernels from versions 2.6.8 on. This behavior is incompatible with some firewalls that use SPI (Stateful Packet Inspection) as found in firewalls like the Check Point NG R55, Cisco PIX earlier than v6.3.1, NetApp Cache Appliances, SonicWall, D-Link DI-724U, Netgear WGR614, and Linksys WRT54GS.[3] This may be related to previous failures to work properly. Pre-released (beta) versions of Vista allegedly had more problems, including failed http (web) connections through SPI firewalls.[4]

Vulnerabilities

There is a risk that vulnerabilities in individual protocol decoders could allow an attacker to gain control over the firewall. This concern highlights the need to keep firewall software updated.[5]

Stateful firewalls also raise the possibility that individual hosts can be tricked into soliciting outside connections. This possibility can only be completely eliminated by auditing the host software. Some firewalls can be defeated in this way by simply viewing a web page (either with JavaScript enabled, or after clicking on a button).[6]

See also

References

  1. ^ "Who Invented the Firewall?". TechWeb. 2008-01-15.
  2. ^ "Check Point Software Technologies Ltd. Awarded Patent For Stateful Inspection Technology". Check Point. 1997-03-17. {{cite web}}: |access-date= requires |url= (help); Check date values in: |accessdate= (help); Missing or empty |url= (help)
  3. ^ "Network connectivity may fail when you try to use Windows Vista behind a firewall device".
  4. ^ "A painful Vista networking bug".
  5. ^ Review of Tomato firewall "...both L7-Filter and IPP2P are explicitly unmaintained. Given the steady stream of security updates for protocol dissectors in WireShark, your editor has a hard time believing that these other classifiers can be completely free of security issues."
  6. ^ Hacker pierces hardware firewalls with web page