Iptables status detection mechanism

1. What is status detection?
Each network connection includes the following information: Source Address, Destination Address, source port, and destination port, called socket pairs, protocol type, connection status (TCP protocol), and timeout time. The firewall calls this information stateful. A firewall that can detect each connection status is called a status packet filtering firewall. In addition to completing the packet filtering of the simple packet filtering firewall, it also maintains a table that tracks the connection status in its own memory, which is more secure than the simple packet filtering firewall.
The status detection function in iptables is implemented by the state option. This option is described as follows on the iptables manual page:
State
This module can track the connection status of the group (that is, status detection ).
-- State
Here, state is a comma-separated list, indicating the connection status to be matched. Valid status options include: INVAILD, indicating that the connection to the group is unknown; ESTABLISHED, indicating that the connection to the group has been transmitted by two-way group, that is, the connection has been ESTABLISHED; NEW, this indicates that the group needs to initiate a connection, or the connection corresponding to the group has not been transmitted by group in both directions. RELATED indicates that the Group wants to initiate a new connection, however, this connection is RELATED to an existing connection. For example, the RELATED relationship is between the FTP data transmission connection and the control connection.
For local production groups, you can track the connection status in the PREROUTING or OUTPUT chain. Before performing status detection, You need to reorganize the parts of the group. This is why ip_always_defrag of ipchains is no longer used in iptables.
The status table of UDP and TCP connections is maintained by/proc/net/ip_conntrack. We will introduce it later.
The maximum number of connections that can be saved in the status table is stored in/proc/sys/net/ipv4/ip_conntrack_max. It depends on the physical memory of the hardware.
2. How does iptables status check work?
2.1.iptables Overview
Before discussing iptables status detection, let's take a general look at the entire netfilter framework. If you want to forward a group between two network interfaces, this group will receive the inspection of the Rule chain in the following order:
PREROUTING chain
If necessary, perform the destination network address translation (DNAT) and mangle processing for this group. At the same time, the status detection mechanism of iptables will reorganize the group and track its status in the following ways:
Whether the group matches an implemented connection in the status table.
Whether it is an ICMP group associated with a UDP/TCP connection (RELATED) in the status table.
Whether to initiate a NEW connection for this group.
If the group has nothing to do with any connection, it is considered INVALID (INVALID.
FORWARD chain
Matches the group status with the rules in the filter table. If the group does not match all rules, the Default policy is used for processing.
POSTROUTING chain
If necessary, convert the source network address (SNAT) of the group ),
Note: all groups must be compared with the filter table rules. If you have modified the rule and want to reject all network traffic, the group will be rejected even if the group status matches an ESTABLISHED entry in the status table.
Next, we analyze the UDP, TCP, and ICMP protocols respectively.
2.2.UDP connection
UDP (user data packet Protocol) is a stateless protocol that has no serial number. However, this does not mean that we cannot track UDP connections. Although there is no serial number, we can also use other information to track the status of UDP connections. The following are UDP connection entries in the status table:
Udp 17 19 src = 192.168.1.2 dst = 192.168.1.50 sport = 1032 dport = 53 [UNREPLIED] src = 192.168.1.50 dst = 192.168.1.2 sport = 53 dport = 1032 use = 1
This status table item can be created only when the iptables filter rule allows a new connection. The following rules can generate such status table items. The two rules only allow Outbound UDP connections:
Iptables-a input-p udp-m state -- state ESTABLISHED-j ACCEPT
Iptables-a output-P udp-m state -- state NEW, ESTABLISHED-j ACCEPT
The preceding status table items contain the following information:
The connection protocol is UDP (IP Protocol Number 17 ).
This status table item times out in 19 seconds.
Source, Destination Address, source, and destination port in the connection direction.
Source, Destination Address, source, and destination port in the response direction. The connection uses the UNREPLIED flag, indicating that no response has been received.
The UDP connection timeout value is set in the/usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_udp.c file. If this value is changed, the linux kernel source code needs to be re-compiled to take effect. The following is the source code of UDP connection Timeout:
# Define UDP_TIMEOUT (30 * HZ)
# Define UDP_STREAM_TIMEOUT (180 * HZ)
The wait time for a UDP request to respond is 30 * HZ (this value is generally 30 seconds ). In the preceding example, the waiting time has been 11 seconds, and the remaining 19 seconds remain. If no response group is received within this period, this table item will be deleted. Once a response is received, this value is reset to 30, and the UNREPLIED flag is also deleted. This table item is programmed as follows:
Udp 17 28 src = 192.168.1.2 dst = 192.168.1.50 sport = 1032 dport = 53 src = 192.168.1.50 dst = 192.168.1.2 sport = 53 dport = 1032 use = 1
If multiple requests and responses occur on the source, Destination Address, source, and destination ports, this table item serves as a data flow table item and the timeout value is 180 seconds. In this case, the table entry is in the following format:
Udp 17 177 src = 192.168.1.2 dst = 192.168.1.50 sport = 1032 dport = 53 src = 192.168.1.50 dst = 192.168.1.2 sport = 53 dport = 1032 [ASSURED] use = 1
Then we can see that this table item uses the ASSURED flag. Once the connecting table item uses the ASSURED flag, it will not be discarded even if the network is heavy. If the status table is saturated, the table items that use the UNREPLIED flag will be discarded when a new connection arrives.
2.3.TCP connection
A TCP connection is completed by three handshakes. First, the client program sends a synchronous request (sends a SYN group). Then, the server responds to a SYN | ACK group, and returns an ACK group. The connection is complete. The process is as follows:
Client Server
SYN --->
<--- SYN + ACK
ACK --->
<--- ACK
ACK --->
.........
.........
SYN and ACK are determined by the TCP grouping header flag. Each TCP group header has a 32-bit serial number and a response number used to trace sessions.
To track the status of a TCP connection, you need to use the following rules:
Iptables-a input-p tcp-m state -- state ESTABLISHED-j ACCEPT
Iptables-a output-p tcp-m state -- state NEW, ESTABLISHED-j ACCEPT
2.3.1. Status table changes during connection Establishment
Next, we will discuss in detail the changes in the status table during each phase of connection establishment:
Once an initial SYN group enters the OUTPUT chain and the OUTPUT rule allows this group to establish a new connection, the related table items of the status table are as follows:
Cp 6 119 SYN_SENT src = 140.208.5.62 dst = 207.46.230.218 sport = 1311 dport = 80 [UNREPLIED] src = 207.46.230.218 dst = 140.208.5.62 sport = 80 dport = 1311 use = 1
The TCP connection status is SYN_SENT, and the connection is marked as UNREPLIED.
Now, we are waiting for the response from the SYN + ACK group. Once a response is received, the TCP connection table entry is changed:
Tcp 6 57 SYN_RECV src = 140.208.5.62 dst = 207.46.230.218 sport = 1311 dport = 80 src = 207.46.230.218 dst = 140.208.5.62 sport = 80 dport = 1311 use = 1
The connection status changes to SYN_RECV, And the UNREPLIED flag is cleared.
Now we need to wait for the ACK group to complete the handshake. When the ACK group arrives, we first check its serial number. If it is correct, the connection status changes to ESTABLISHED and ASSURED is used to mark the connection. The connection status is as follows:
Cp 6 431995 ESTABLISHED src = 140.208.5.62 dst = 207.46.230.218 sport = 1311 dport = 80 src = 207.46.230.218 dst = 140.208.5.62 sport = 80 dport = 1311 [ASSURED] use = 1
2.3.2. View status table
Above, we have involved a lot of CP connection statuses. Now, let's analyze the TCP connection status detection. In fact, the status table only knows NEW, ESTABLISHED, RELATED, and INVALID.
Note: The status detection status is not equal to the TCP status. When a SYN group responds to the SYN + ACK group, the Netfilter status detection module considers that the connection has been established. However, the three-way handshake is not completed yet, so the TCP connection has not yet been established.
In addition, the packet filtering rule cannot delete table items in the status table. The corresponding status table items are deleted only when the connection times out. An ACK group can create a NEW status table item. An ACK group is sent to a host that does not exist after the firewall, and no RST group is returned. This conclusion can be proved. Therefore, you need to use the following rules to clarify that the new TCP connection should be established by the SYN group:
Iptables-a input-p tcp! -- Syn-m state -- state NEW-j DROP
This prevents empty sessions from continuing.
2.3.3. Timeout
The timeout value of a state table item refers to the maximum time for each table item to exist, the size of these timeout values is set in the/usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c file. The following is the relevant code:
Static unsigned long tcp_timeouts []
= {30 MINS,/* TCP_CONNTRACK_NONE ,*/
5 DAYS,/* TCP_CONNTRACK_ESTABLISHED ,*/
2 MINS,/* TCP_CONNTRACK_SYN_SENT ,*/
60 SECS,/* TCP_CONNTRACK_SYN_RECV ,*/
2 MINS,/* TCP_CONNTRACK_FIN_WAIT ,*/
2 MINS,/* TCP_CONNTRACK_TIME_WAIT ,*/
10 SECS,/* TCP_CONNTRACK_CLOSE ,*/
60 SECS,/* TCP_CONNTRACK_CLOSE_WAIT ,*/
30 SECS,/* TCP_CONNTRACK_LAST_ACK ,*/
2 MINS,/* TCP_CONNTRACK_LISTEN ,*/
};
2.3.4. Connection interruption
You can close a TCP connection in two ways. The first type is similar to the three-way handshake that establishes a TCP connection. Once a TCP session is completed, the party that wants to terminate the session first sends out a group with FIN as 1. The receiver TCP confirms this FIN group, and the application on its own side should not receive data. This process can be as follows:
Client Server
.........
.........
FIN + ACK --->
<--- ACK
<--- FIN + ACK
ACK --->
During or after this process, the connection status of the status table changes to TIME_WAIT. By default, the table is deleted from the status table two minutes later.
In addition, there are other ways to disable interruption. When either party of a TCP session issues a Group marked as 1 (RST), a TCP connection can be quickly disconnected. In addition, the RST group does not need to respond. In this case, the status table item changes to CLOSE and is deleted 10 seconds later. And http connections are often interrupted in this way. If a connection has not been requested for a long time, the server will issue an RST group to interrupt the connection.
2.4.ICMP
In iptables's view, there are only four ICMP groups, which can be classified as NEW and ESTABLISHED:
ECHO Request (ping, 8) and ECHO response (pong, 0 ).
Timestamp Request (13) and response (14 ).
Information Request (15) and response (16 ).
Address Mask Request (17) and response (18 ).
Among these ICMP group types, the request group belongs to NEW, and the Response Group belongs to ESTABLISHED. All ICMP groups of other types are classified as RELATED, not based on the request/response method.
Let's take a look at a simple example:
Iptables-a output-p icmp-m state -- state NEW, ESTABLISHED, RELATED-j ACCEPT
Iptables-a input-p icmp-m state -- state ESTABLISHED, RELATED-j ACCEPT
The chain rules are filtered as follows:
An ICMP echo request is a NEW connection. Therefore, ICMP echo requests are allowed to pass the OUTPUT chain.
When the corresponding response is returned, the connection status is ESTABLISED, so the INPUT chain is allowed. The INPUT chain does not have the NEW state, so the echo request is not allowed to pass the INPUT chain. That is to say, these two rules allow internal hosts to ping external hosts, rather than external hosts to ping internal hosts.
A redirection ICMP (5) group is RELATED because it is not based on the request/response method. Both the INPUT and OUTPUT links allow connections in the RELATED State. Therefore, the redirection (5) group can use the INPUT and OUTPUT links.
3. FTP protocol status detection
We have introduced in detail the iptables state detection mechanism. Now, we take FTP status detection as an example to describe how to use iptables for connection status detection.
First, you need to load the ip_conntrack_ftp module. Use the following rules to allow the establishment of FTP control connections (IMCP is not considered here ):
Iptables-a input-p tcp -- sport 21-m state -- state ESTABLESED-j ACCEPT
Iptables-a output-p tcp -- dport 21-m state -- state NEW, ESTABLISED-j ACCEPT
In addition to control connections, FTP also requires a data channel. However, data connections can be established in active and passive modes. We need to discuss them separately.
3. 1. Active Mode
In active mode, the client program uses the PORT command on the control channel to tell the FTP server its own data transmission PORT, and then FTP initiates a connection from PORT 20 to the PORT. After the connection is established, the server and the client can use this connection to transmit data, for example, the results of commands such as the file and ls commands. Therefore, in active mode, the FTP data transmission channel is created in reverse mode and is initiated from the FTP server to the client.
In active mode, the data transmission port used by the client is not fixed, so we need to use the port range in the rule. Because the client uses ports greater than 1024, this does not reduce the security of the system.
In iptables, there is a module dedicated to tracking FTP status-ip_conntrack_ftp. This module can identify the PORT command and extract the PORT number from it. In this way, the FTP data transmission connection is classified into the RELATED state, which is RELATED to the external FTP control connection. Therefore, we do not need to use the NEW State in the INPUT chain. The following rules can achieve our intention:
Iptables-a input-p tcp -- sport 20-m state -- state ESTABLISED, RELATED-j ACCEPT
Iptables-a output-p tcp -- dport 20-m state -- state ESTABLISED-j ACCEPT
3. 2. Passive Mode
In passive mode, the PORT command for specifying the connection PORT is issued by the server. The FTP server uses the PORT command to tell the client its own FTP data transmission PORT, and then waits for the client to establish a data transmission connection. In passive mode, the direction for establishing a data transmission connection is the same as that for establishing a control connection. Therefore, the passive mode provides better security than the active mode.
Because the ip_conntrack_ftp module can extract ports from the PORT command, we do not need to use the NEW status in the OUTPUT chain. The following rules can detect the FTP status in passive mode:
Iptables-a input-p tcp -- sport 1024: -- dport 1024:-m state -- state ESTABLISHED-j ACCEPT
Iptables-a output-p tcp -- sport 1024: -- dport 1024:-m state -- state ESTABLISHED, RELATED-j ACCEPT
Based on the above analysis, we can obtain the FTP connection status detection rules. For FTP in active mode, the following iptables rules are required:
Iptables-a input-p tcp -- sport 21-m state -- state ESTABLESED-j ACCEPT
Iptables-a output-p tcp -- dport 21-m state -- state NEW, ESTABLISED-j ACCEPT
Iptables-a input-p tcp -- sport 20-m state -- state ESTABLISED, RELATED-j ACCEPT
Iptables-a output-p tcp -- dport 20-m state -- state ESTABLISED-j ACCEPT
For FTP connections in passive mode, use the following iptables rules
Iptables-a input-p tcp -- sport 21-m state -- state ESTABLESED-j ACCEPT
Iptables-a output-p tcp -- dport 21-m state -- state NEW, ESTABLISED-j ACCEPT
Iptables-a input-p tcp -- sport 1024: -- dport 1024:-m state -- state ESTABLISHED-j ACCEPT
Iptables-a output-p tcp -- sport 1024: -- dport 1024:-m state -- state ESTABLISHED, RELATED-j ACCEPT
The status detection mentioned in this article is actually called Connection tracking in iptables. Due to my own habits, I will change it to status detection in this article.