Implementation of LINUX2.2.x status detection

Article title: Implementation of LINUX2.2.x status detection. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
1. Introduction
　　
Status detection is one of the essential functions of the firewall system. It works on the IP layer, checks the packets forwarded by the firewall, and creates the corresponding structure to record the connection status. Its check items include various information on the link layer, network layer, transport layer, and application layer, and decide whether to allow the forwarding packet to pass according to the rule table or status table.
　　
The open source project SIFI (Web site http://www.ifi.unizh.ch/ikm/SINUS/) implements a firewall that includes the state detection function. The code of this firewall kernel is built on the LINUX2.2.x network security framework and is an example of a good analysis and learning status detection technology. The following describes how to implement status detection in terms of data structure, status check, serial number check, timeout, and application protocol data check.
　　
2. Overview
　　
First, let's look at several important data structures in SIFI.
　　
2.1. sf_fw_ops
　　
The SIFI kernel code is implemented on the LINUX2.2.x network security framework. Therefore, it must define the referenced structure on the check point, as shown below:
　　
Struct firewall_ops sf_fw_ops =
{
NULL,
Sf_forward_chk,
Sf_input_chk,
Sf_output_chk,
PF_INET,
2
}
　　
　　
　　
In the structure, the sf_forward_chk, sf_input_chk, and sf_out_chk functions are called on the checkpoint call_fw_firewall, call_in_firewall, and call_out_firewall respectively. All three functions call the sf_check_packet function to complete the real action. The structure has a priority of 2, which is higher than the ipfw_ops defined in the LINUX2.2.x Kernel. therefore, call the function defined in this structure at the check point. The function defined in ipfw_ops is called only when the return value of its function is FW_SKIP.
　　
2.2. rule table
　　
A rule table is a one-way linked list used to match the packages to be processed and determine the action after matching. 2.1.
　　
2.3. connection table
　　
A join table is a hash table. The structure with the same hash value is linked to a two-way linked list. All the connection structures are linked into a two-way linked list. the pointer conns points to the head of the linked list, and lastc points to the end of the linked list. 2.1.
　　　
2.4. Status definition
　　
Each structure in the join table has a definite state at a certain moment. In SIFI, only the TCP and UDP connection structures are created. Check for other protocols is implemented by matching the rule table, and no connection structure is created. The status is defined as follows:
　　　
[Table 2.1]
　　
The status marked with Gray in the table is not used during the status check.
　　
SF_TCP_ESTABLISHEDFTP is the status defined for the control connection of the FTP protocol. the purpose of defining this status is to check the FTP protocol, find the address and port, and create a new connection structure, the FTP data connection can also be established without corresponding rules. Other states define the valid state in the process of TCP connection change. The State conversion process is described below.
　　
3. basic process
　　
Next let's take a look at how SIFI handles different protocol packages.
　　
For an ICMP or IGMP Packet, it checks the packet length and searches in the rule table. if a matching rule is found, the operation specified by the rule is executed; if no matching rule is found, this package is disabled by default. It does not record the status of ICMP or IGMP protocol.
　　
Check the UDP protocol package according to the following process:
　　　
[. 1]
　　
First, search in the connection table. If yes, UDP communication in this direction is allowed by the rule. If no, search in the rule table. if a matching rule exists, if no matching rule is found, this package is disabled by default. When the rule is checked, if the matched rule allows this package to pass, a new connection structure will be added to the connection table. the status value is SF_UDP_STATE, and subsequent packages will not be checked by the rule, until the structure is deleted. It is worth noting that UDP packets use one-way matching when checking the connection table, which is different from TCP processing.
　　
Check the TCP packet according to the following process:
　　　
[. 2]
　　
First, check whether the connection structure exists in the connection table. The search here uses bidirectional matching (interchange the destination address, destination port, source address, and source port), so a TCP connection corresponds to a connection structure. If the corresponding connection structure is found, the status changes (how the status changes will be described later); if not found, check whether the package is a syn position, however, ack does not have a set of packets (packets that initiate a TCP connection). If yes, use the source port to calculate the hash value from zero, find the corresponding structure in the connection table (this structure is created when processing the dynamic addresses and dynamic ports in the application protocol data, similar to the processing in address translation, delete the zero source port structure and re-calculate the hash value with the package address and port to create a new structure, the package is not allowed to pass.
　　
4. status check
　　
4.1. status check
　　
Status Check defines the valid status during TCP connection change and the type of packets allowed to pass in a specific status. The status check also checks the validity of the packets allowed to pass, such as determining whether the serial number conforms to the TCP protocol.
　　
Changes between states:
　　　
　　
　　
[. 1]
　　
The initial status of the connection structure is SF_TCP_ACCEPT_SYN. this is created when the TCP packet with a syn position and an ack without a position is returned when the rule checks that the return value is FW_ACCEPT. After the structure is created, check the connection creation status. The procedure is as follows:
　　
(1) If the syn is set for the CLIENT (the initiator) and the ack is not set for the packet, the connection status changes to SF_TCP_CLIENT_SYN.
　　
(2) in the SF_TCP_CLIENT_SYN state, if the SERVER (connection receiver) responds to the syn or syn/ack packet, the connection status changes to SF_TCP_SYN_ACK. In this status, the CLIENT's syn or syn/ack packets are also allowed, and the connection status remains unchanged.
　　
(3) in the SF_TCP_SYN_ACK status, if the CLIENT responds to a packet with an ack or syn/ack position, the connection status changes to SF_TCP_ESTABLISHED3. In this status, the connection status of the syn/ack packets of the SERVER remains unchanged, but the syn positions of the SERVER and the syn packets of the CLIENT are not allowed to pass through.
　　
The above is the check of the syn or ack position package in three statuses: SF_TCP_ACCEPT_SYN, SF_TCP_CLIENT_SYN, and SF_TCP_SYN_ACK. This check supports enabling TCP connections at the same time, provided that the rules are allowed.
　　
To disable the connection status check, follow these steps:
　　
(4) the connection status changes to SF_TCP_CLIENT_FIN if it is the fin position package of the CLIENT.
　　
(5) if it is the SERVER's fin location package, the connection changes to SF_TCP_SERVER_FIN.
　　
(6) If the changes in the preceding two steps have been completed, the connection status is SF_TCP_TERMINATED or greater than SF_TCP_TERMINATED (if it is the structure created for the FTP control connection ).
　　
(7) If the status is greater than or equal to SF_TCP_TERMINATED, the connection will be deleted and the rule will be checked.
　　
If you receive the rst package in any status, the connection will be deleted. In addition, if you receive a syn, fin, or syn, rst, or fin or rst packet (Christmas tree packet), this packet will not pass through.
　　
4.2. timeout
　　
The timeout value is set for each non-ESTABLISHED status, as shown in the following table:
　　
　　
　　
[Table 4.1]
　　
Timeout is implemented through the kernel timer, and the timeout connection is deleted. No timeout value is defined for SF_TCP_ESTABLISHED3 and SF_TCP_ESTABLISHEDFTP by default. However, you can define the SF_TCP_IDLE compilation option to set the timeout value to 8*3600 * HZ for 8 hours.
　　
4.3. check the serial number
　　
Serial number is an important means for TCP to ensure data reliability. Each byte of data transmitted in a TCP connection is identified by a serial number. The initial serial number of the connection is negotiated when the connection is established. The party receiving the package will send an ack-position response packet, telling the other party what the next serial number is, so as to confirm the data received before the next serial number. TCP also uses the serial number window to limit the length of data packets that can be sent by the other party to control traffic. The window size is a 16-bit positive integer. you can use the TCP scale option to expand the window size. With the scale option, the window value is shifted left in the computing window to increase the window value.
　　
In TCP, packets that negotiate the syn position of the initial serial number occupy a serial number, and packets that disconnect the fin position occupy a serial number. SIFI checks the serial number of the forwarding packet to determine whether the packet is valid. In the implementation of SIFI, you can configure parameters to check the serial number of each TCP connection. The steps are as follows:
　　
(1) for packets without syn positions (fin or ack positions), first determine that the sender's maximum serial number is within the recipient's window, and then if it is an ack position package, the confirmed serial number should be after the serial number of the other party.
　　
(2) the serial number, window size, and scaling factor of the CLIENT are recorded in the SF_TCP_CLIENT_SYN state. In the SF_TCP_SYN_ACK status, record the SERVER serial number, window size, and scaling factor, and increase the CLIENT serial number by 1.
　　
(3) when SF_TCP_TERMINATED is in the SF_TCP_TERMINATED state, if a syn-based package is received, its serial number should be after the serial number of this party.
　　
(4) in the SF_TCP_SYN_ACK status, the SERVER's repeated syn/ack placement package should ensure that the serial number should be equal to the serial number of the connection record CLIENT.
　　
4.4. Application Protocol Data check
　　
The application protocol data check is to check the address and port passed by the application protocol in the control connection, and create the corresponding connection structure so that subsequent data connections can be established. Generally, unless the rules allow all ports, the dynamic ports transmitted in these protocols are disabled by default. If the connection structure can be dynamically created, check rules should be avoided and transparent to users. Of course, this can also be achieved by creating dynamic rules, but the rule is