Stateful firewall
In computing, a stateful firewall is a network firewall that tracks the operating state and characteristics of network connections traversing it. The firewall is configured to distinguish legitimate network packets for different types of connections. Only packets matching a known active connection are allowed to pass the firewall. In contrast, a stateless firewall does not take context into account when determining whether to allow or block packets.
Stateful packet inspection (SPI), also referred to as dynamic packet filtering,[1] is a security feature often included in business networks.
History
Stateful firewall technology was introduced by Check Point Software with the FireWall-1 product in 1994.[2][3]
Before the development of stateful firewalls, firewalls were stateless. A stateless firewall treats each network frame or packet individually. Such packet filters operate at the OSI Network Layer (layer 3) and function more efficiently because they only look at the header part of a packet.[4] They do not keep track of the packet context such as the nature of the traffic.[5] 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 with application inspection solve this problem by maintaining a table of open connections, inspecting the payload of some packets and intelligently associating new connection requests with existing legitimate connections.
Early attempts at producing firewalls operated at the application layer, which is the very top of the seven-layer OSI model. This method required exorbitant amounts of computing power and is not commonly used in modern implementations.[6]
Description
A stateful firewall keeps track of the state of network connections (such as TCP streams or UDP communication) and is able to hold significant attributes of each connection in memory. These attributes are collectively known as the state of the connection and may include such details as the IP addresses and ports involved in the connection and the sequence numbers of the packets traversing the connection. Stateful inspection monitors incoming and outgoing packets over time, as well as the state of the connection, and stores the data in dynamic state tables. This cumulative data is evaluated so that filtering decisions would not only be based on administrator-defined rules, but also on context that has been built by previous connections as well as previous packets belonging to the same connection.
The most CPU intensive checking is performed at the time of setup of the connection. Entries are created only for TCP connections or UDP streams that satisfy a defined security policy. After that, all packets (for that session) are processed rapidly because it is simple and fast to determine whether it belongs to an existing, pre-screened session. Packets associated with these sessions are permitted to pass through the firewall. Sessions that do not match any policy are denied, as packets that do not match an existing table entry.
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.
Depending on the connection protocol, maintaining a connection's state is more or less complex for the firewall. For example, TCP is inherently a stateful protocol as connections are established with a three-way handshake ("SYN, SYN-ACK, ACK") and ended with a "FIN, FIN-ACK, ACK" exchange. This means that all packets with "SYN" in their header received by the firewall are interpreted to open new connections. If the service requested by the client is available on the server, it will respond with a "SYN-ACK" packet which the firewall will also track. Once the firewall receives the client's "ACK" response, it transfers the connection to the "ESTABLISHED" state as the connection has been authenticated bidirectionally. This allows tracking of future packets through the established connection. Simultaneously, the firewall drops all packets which are not associated with an existing connection recorded in its state table (or "SYN" packets), preventing unsolicited connections with the protected machine by black hat hacking.
Other connection protocols, namely UDP and ICMP, are not based on bidirectional connections like TCP, making a stateful firewall somewhat less secure. In order to track a connection state in these cases, a firewall must transfer sessions to the ESTABLISHED state after seeing the first valid packet. It can then only track the connection through addresses and ports of the following packets' source and destination. Unlike TCP connections, which can be closed by a "FIN, ACK" exchange, these connectionless protocols allow a session to end only by time-out. This, for example, enables UDP hole punching.
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. Additionally, in the case of a match with the state table, the firewall does not need to perform deep packet inspection.
Application-level filters
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 are generally slower than stateful inspection. Application-layer firewalls are sometimes implemented using application proxies. Two TCP connections are established: one between the packet source and the firewall, another between the firewall and the packet destination. Application proxies intercept arriving packets on behalf of the destination, examine application payload, and then relay permitted packets to the destination. Suspicious data is dropped and the client and server never communicate directly with each other. Proxies necessarily involve more protocol stack overhead than inspecting packets at the network layer. Furthermore, because a unique proxy is required for each application, proxy firewalls can be less flexible and slower to upgrade than stateful inspection firewalls. Nevertheless, because application-level proxies are application-aware, the proxies can more easily handle complex protocols like H.323 or SIP, which are used for videoconferencing and VoIP (Voice over IP).
Pitfalls
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.[7]
Some 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).[8]
See also
- Comparison of firewalls
- Computer security
- Netfilter
- Network layer firewall
References
- Goralski, Walter, author. The illustrated network : how TCP/IP works in a modern network. ISBN 978-0-12-811027-0. OCLC 986540207.CS1 maint: multiple names: authors list (link)
- United States Patent 5,606,668
- Check Point's Press Release Archived 2006-10-18 at the Wayback Machine “Check Point Introduces Revolutionary Internet Firewall Product Providing Full Internet Connectivity with Security; Wins 'BEST OF SHOW' Award at Networld+Interop ‘94”. 1994-05-06
- Suehring, Steve (Jan 29, 2015). Linux Firewalls: Enhancing Security with Nftables and Beyond (Iillustrated ed.). Pearson Education. p. 25. ISBN 0134000021.
- Shinder, Thomas W. Shinder, Cheri Amon, Robert J. Shimonski, Debra Littlejohn (2003). Best damn firewall book period. Rockland, Mass.: Syngress. p. 233. ISBN 0080476066.
- Sherri Davidoff and Jonathan Ham, Network forensics: tracking hackers through cyberspace, Prentice hall, 2012
- 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."
- Hacker pierces hardware firewalls with web page