Shulou(Shulou.com)05/31 Report--

This article introduces how to analyze the state mechanism of iptables. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

1.6 status mechanism

Stateful mechanism is a special part of iptables, which is also one of the big differences between iptables and the older ipchains. The firewall running stateful mechanism (connection tracking) is called firewall with stateful mechanism, hereinafter referred to as stateful firewall. Stateful firewalls are more secure than stateless firewalls because they allow us to write stricter rules.

There are four states on iptables, which are called NEW, ESTABLISHED, INVALID, and RELATED. These four states are valid for TCP, UDP, and ICMP protocols. Next, let's elaborate on the characteristics of the four states.

NEW:NEW indicates that this package is the * package we have seen. This means that this is the packet of a connection seen by the conntrack module, and it is about to be matched. For example, if we see a SYN package, which is the connected package we are paying attention to, we need to match it.

ESTABLISHED: ESTABLISHED has noticed the transfer of data in both directions and will continue to match the connected packets. Connections in the ESTABLISHED state are very easy to understand. As long as you send and receive a reply, the connection is ESTABLISHED. To change a connection from NEW to ESTABLISHED, you only need to receive a reply packet, whether the packet is sent to the firewall or forwarded by the firewall. Packets such as ICMP errors and redirects are also considered ESTABLISHED, as long as they are responses to the messages we send.

RELATED: RELATED is a troublesome state. When a connection is related to a connection that is already in the ESTABLISHED state, it is considered RELATED. In other words, for a connection to be RELATED, you must first have a connection to ESTABLISHED. This ESTABLISHED connection produces a connection other than the main connection, and the new connection is RELATED, provided, of course, that the conntrack module can understand RELATED. Ftp is a good example. FTP-data connections are associated with FTP-control. If RELATED status is not configured in the iptables policy, FTP-data connections cannot be established correctly. There are other examples, such as DCC connections through IRC. With this state, ICMP reply, FTP transport, DCC, and so on can work properly through the firewall. Note that most other UDP protocols rely on this mechanism. These protocols are very complex. They put the connection information in the packet and require that the information be understood correctly.

INVALID:INVALID indicates that the packet cannot be identified as belonging to which connection or without any state. There are several reasons for this, such as a memory overflow and an ICMP error message that you don't know which connection you belong to. In general, we DROP anything in this state because the firewall considers it insecure.

Each state is slightly different from a different layer 4 protocol. For TCP protocol, when the firewall receives * packets, that is, SYN messages, mark the session as NEW state. In the / proc/net/ directory of the system, you can consult the file ip_conntrack, which is a temporary file that stores the firewall current state table in memory space. The record of NEW status is as follows:

Tcp 6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 use=1

From the above record, you can see that the SYN_SENT status has been set, which means that the connection has sent a SYN packet, but the reply has not been sent. As can be seen from the [UNREPLIED] flag, when the server responds to the SYN/ACK packet, the status table is rewritten as follows:

Tcp 6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 use=1

Now that we have received the corresponding SYN/ACK packet, the status has also changed to SYN_RECV, which means that the original SYN packet has been transmitted correctly and the SYN/ACK packet has arrived at the firewall. This means that there is data transmission on both sides of the connection, so it can be considered that there is a corresponding response in both directions.

Next, the following message of the TCP three-way handshake, the ACK packet, also arrives at the firewall, and the state table on the firewall becomes:

Tcp 6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 use=1

Now, let's look at the state description method of the UDP protocol. From the nature of the protocol itself, the UDP connection is stateless because it does not have any connection establishment and closure process. It is impossible to determine the order in which two packets are received in a certain order. However, the kernel can still set the state of the UDP connection. Let's take a look at how UDP connections are tracked and related records in the core directory / proc/net/ip_conntrack.

When * UDP packets arrive at the firewall, the firewall leaves this record in his state table:

Udp 17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 [UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 dport=137 use=1

UNREPLIED indicates that this is a packet with a status of NEW, and when the echo packet of this connection arrives at the firewall, the firewall will immediately modify the status record:

Udp 17 160 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 dport=137 use=1

In this new state record, UNREPLIED has been deleted, which means that the firewall has established a session of the UDP protocol, but the ESTABLISHED flag is not displayed here as in the TCP protocol. This is where the state record of TCP is slightly different from that of UDP. Of course, it is also important to note that during the test, some packets need to pass through before the firewall will rewrite the state record as:

Udp 17 179 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 dport=137 [ASSURED] use=1

The ASSURED status indicates that there is data currently being transferred, and the current connection status on the surface is ACTIVE. If the data stops transmitting in this state, the record will have a timer, which is the third field in the record. The third field of the record above is 179, which means that the current ASSURED status can be maintained for 179 seconds. If there are new packets passing by, the timer will be reset to the default 180 seconds, if there is no traffic within 180 seconds. Then the status record is deleted from the status table.

* We are looking at how Linux kernel marks the status of the ICMP protocol. ICMP is also a stateless protocol that is only used to control rather than establish connections. There are many types of ICMP packets, but only four types have reply packets: echo request and reply (Echo request and reply), timestamp request and reply (Timestamp request and reply), information request and reply (Information request and reply), and address mask request and reply (Address mask request and reply). These packets have two states, NEW and ESTABLISHED. Timestamp requests and information requests have been abolished, echo requests are still commonly used, such as the ping command, address mask requests are not very common, but can sometimes be useful and worthwhile. Take a look at the figure below to get an overview of the NEW and ESTABLISHED status of the ICMP connection.

As shown in the figure, the host sends an echo request to the target, and the firewall considers the packet to be in the NEW state. The target responds with an echo reply, and the firewall assumes that the packet is in ESTABLISHED. When an echo request is sent, it is recorded in ip_conntrack as follows:

Icmp 1 25 src=192.168.1.6 dst=192.168.1.10 type=8 code=0 id=33029 [UNREPLIED] src=192.168.1.10 dst=192.168.1.6 type=0 code=0 id=33029 use=1

You can see that the record of ICMP is a little different from that of TCP and UDP. The protocol name, timeout and source and destination addresses are all the same. The difference is that there is no port, and three new fields are added: type,code and id. The field type describes the type of ICMP. Code describes the code for ICMP, which is described in the appendix ICMP type. Id is the ID of the ICMP package. Each ICMP packet is assigned an ID when it is sent, and the receiver assigns the same ID to the reply packet so that the sender can recognize the reply to the request.

The meaning of [UNREPLIED] is the same as before, indicating that the transmission of numbers occurs only in one direction, that is, no reply is received. After that, there are the source and destination address of the reply packet, and the corresponding three new fields. Note that the type and code vary with the reply packet, and the id is the same as the request packet. As before, the answer package is considered to be ESTABLISHED. However, after the packet is answered, there is no data transmission for this ICMP connection. Therefore, once the reply packet passes through the firewall, ICMP's connection tracking record is destroyed. Therefore, it is not easy to capture the status record of the ICMP protocol in the / proc/ip_conntrack file. You can try to get these records with the following command:

# cat / proc/net/ip_conntrack | grep icmp

If there is no output, repeat the command again and again until the record of icmp is found.

In all of the above cases, the request is considered NEW and the reply is ESTABLISHED. In other words, when the firewall sees a request packet, it assumes that the connection is in the NEW state, and when there is a reply, it is the ESTABLISHED state.

-

State matching: state matching is very important in firewall configuration. If there is no state configuration, we need to configure two-way rules to meet the needs of communication. But since the firewall has stateful detection, why don't we make good use of it?

There are four states of state:state. Specify the state of the package to match. Currently, there are four states available: INVALID,ESTABLISHED,NEW and RELATED. We have described the status of the four packets in detail earlier. In this section, we will only describe the usage of state, as shown in the following example:

# iptables-A FORWARD-p tcp-m state-- state RELATED,ESTABLISHED-j ACCEPT

This example shows that all tcp packets with a packet status of "RELATED" or "ESTABLISHED" are allowed to pass through the firewall. In general, state-based policies are configured at the front of each chain, because when the packet is matched, it can be processed directly, which is a more efficient configuration method. The keyword ESTABLISHED is relatively easy to understand, that is, a packet with a matching status of "connection has been established". How to understand "RELATED"? RELATED means that it does not belong to the established connection, but it is related to that connection. For example, ftp,ftp will first establish a ftp-control connection to transmit instructions in the process of establishing a connection. What really transmits data is a connection called ftp-data. The connection to transmit data is related to the connection to transmit control signals, so "RELATED" is used for special services like these. Under normal circumstances, status policies can be configured separately for each protocol: TCP, UDP, and ICMP, but a relatively simple and efficient approach is:

# iptables-An INPUT-p all-m state-- state RELATED,ESTABLISHED-j ACCEPT

Multiport: this matching option solves how to match services with discontiguous ports in a policy. In general, the security policy of a company or enterprise is to allow the internal network to use limited Internet services, such as sending and receiving email, browsing the web, msn chat, etc., take a look at the following example:

# iptables-A FORWARD-I eth0-p tcp-m multiport-- dports 25 ACCEPT 80, 110 eth0 443 1863-j ACCEPT#iptables-A FORWARD-I eth0-p udp-- dport 53-j ACCEPT

Only two commands can solve the needs of internal users to send and receive E_mail, browse the web and chat with msn. How about that? it's as simple as that.

How to analyze the state mechanism of iptables is shared here. I hope the above content can be helpful to you and you can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.