Stateful packet inspection
Under stateful packet inspection ( SPI , German state oriented packet inspection ) refers to a dynamic packet filter , wherein each data packet of a certain active session is assigned.
The data packets are analyzed and the connection status is included in the decision. In this technique, which in firewalls (: actually is used, the data packets are segments ) during the transmission on the network layer (3rd layer of the OSI model analyzed) and stored in the dynamic state tables. The decisions for forwarding the data packets are made on the basis of the status of the data connections. Data packets that cannot be assigned to certain criteria or that may belong to a DoS attack are discarded. Firewalls with SPI technology are therefore superior to pure packet filter firewalls in security-relevant applications.
The company Check Point Software Technologies Ltd. claims to have invented this technique in 1993.
functionality
If a computer A communicates with a computer B via a simple packet filter (i.e. without stateful packet inspection), it must allow two connections in its set of rules :
- Source A to destination B with the HTTP service (for the request, e.g. "Send me website www.example.com")
- Source B to destination A with the HTTP service (for the response packets, in this example the content of www.example.com)
As a result, the set of rules is less secure than actually necessary, because B can send to A at any time , even if A has not requested a website at all (with Netfilter, the 'Sync flag' can be used to prevent B from establishing a connection to A ).
With state- controlled filtering (i.e. with Stateful Packet Inspection), only one rule is required (or the second is allowed via a general rule (ESTABLISHED / RELATED)). This makes the rule set much clearer:
- Source A to destination B
The packet filter remembers when computer A to computer B communicates, and only allowed answers from computer B to computer A . Computer B cannot start without request from A.
The rules for response packets are generated dynamically and automatically deleted after the response has been received or after a timeout .
Even more advanced systems also check whether a packet is allowed at all in the communication at a certain point in time (for example, send further packets even though the other participant has already completed the communication).
Stateful inspection of UDP packets
At first glance, Stateful Packet Inspection for UDP packets looks like a contradiction, since UDP, unlike TCP, works statelessly. Most implementations (e.g. Linux Netfilter) still treat UDP as stateful, in the sense that when a request is sent via UDP, a dynamic firewall rule is generated for the response packets for a short time. In the example of DNS requests, this means that only response packets from the name servers that you have asked yourself are allowed.
Some programs - e.g. B. Skype - use this in a process called hole punching to establish point-to-point connections through firewalls. Both participants learn from the Skype server on which IP address and which port Skype is working on the other side. Then both send a UDP packet to the other side. There these packets are discarded when they arrive because there is no input rule, but they generate a rule on the firewall of the outgoing computer that then allows 'responses'. Then both sides can communicate with each other. This would (trivially) not work with TCP, as the firewall can recognize real response packets based on sequence numbers.
Stateful inspection at ICMP
If you want to send ping requests but do not want to respond to ping , you first define an outgoing rule for ICMP , and then an incoming rule that generally allows all incoming packets for which there are already outgoing connections (RELATED). The answer is allowed through when the firewall detects an existing connection. Then he can ping himself, but does not allow an incoming ping . This works even though ICMP, unlike TCP, is a connectionless protocol. Connectionless means that the individual packages are not related to each other.
Stateful inspection with FTP
FTP is problematic. Two ports, 'ftp' and 'ftp-data' (21 and 20) are used. 'ftp' is used for the transfer of commands, while ftp-data is used for data transfer (file contents or directory contents). There are two different ways (active mode and passive mode) in which direction the data connection (ftp-data) is established. In the Linux kernel there is a kernel module that controls the interaction of both ports.
Time-out
With Stateful Packet Inspection, both TCP and UDP connections always have an assigned timeout . With UDP, because it cannot be seen when a connection has been terminated; with TCP, because it can happen that connections are not cleared down properly. The UDP timeout is usually in the range 20–40 seconds, with TCP 15–60 minutes.
If the timeout is not long enough and legitimate connections are terminated by the firewall, there are two possible solutions. Extending the timeout helps, but it also increases the storage requirements of the system and reduces security. The preferred method should therefore be to use keep-alive packages. These can be configured in some applications such as SSH clients or in the operating system.
Setting the TCP keep-alive under Linux to every 120 seconds:
echo 120 > /proc/sys/net/ipv4/tcp_keepalive_time
Stateful firewall implementations
- Check Point Firewall-1 (Solaris, Windows, IPSO, RHEL , SPLAT )
- Pf (packet filter) ( OpenBSD )
- Ipfw (FreeBSD)
- Iptables (Linux from 2.4)
- Fritzbox
- OPNsense (based on FreeBSD and ASLR from HardenedBSD)