Iptables status Mechanism

This article is excerpted from:

Linux security applications-build a firewall-centric Security Management System

-- NETFILTER/IPTABLES Manual

[Document No. SS-ver001]

Shanghai

Tel: 13817668606

Contact: little_eyes@citiz.net

Internet URL: None

1.6 status Mechanism

The status mechanism is a special part of iptables. This is also one of the major differences between iptables and older ipchains. The running status mechanism is used for connection tracking) the firewall is called a firewall with A status mechanism. State firewall is safer than non-State firewall because it allows us to write more rigorous rules.

There are four statuses on iptables, namely NEW, ESTABLISHED, INVALID, and RELATED. These statuses are valid for TCP, UDP, and ICMP protocols. The following describes the features of the four States.

Each status is slightly different from the layer-4 protocol. For TCP, when the firewall receives the first packet, that is, the SYN packet, it marks the session as NEW, in the/proc/net/directory of the system, you can view the file ip_conntrack. This is a temporary file that stores the current Firewall Status table in the memory space. The NEW status record 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, we can see that the SYN_SENT status is set. This indicates that the connection has sent a SYN packet, but the response has not been sent yet. This can be seen from the [UNREPLIED] Mark, after the server responds to the SYN/ACK packet, the status table is changed:

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 we have received the corresponding SYN/ACK package and the status changes to SYN_RECV. This indicates that the original SYN package has been correctly transmitted and the SYN/ACK package has reached the firewall. This means that the two sides of the connection have data transmission, so we can think that both sides have a corresponding response.

Next, an ACK packet after TCP three-way handshake also arrives at the firewall, and the status table on the firewall changes:

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 take a look at the description of the UDP protocol's status. From the characteristics of the Protocol itself, UDP connections are stateless because they do not have any connection establishment or closure processes. Two packets received in a certain order cannot determine their sending order. However, the kernel can still set the UDP connection status. Let's take a look at how we track UDP connections and related records in the core directory/proc/net/ip_conntrack.

When the first UDP packet arrives at the firewall, the firewall leaves such a record in its status 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 NEW packet. When the response packet of this connection arrives at the firewall, the firewall immediately modifies this 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 status record, UNREPLIED is deleted. This indicates that a UDP session has been ESTABLISHED in the firewall, but the ESTABLISHED mark is not displayed as shown in the TCP protocol, this is a slightly different part of TCP status record and UDP status record. Of course, there is also a need to note that some data packets need to pass through the test, the firewall will rewrite the status record:

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 data is being transmitted, and the current connection status on the surface is ACTIVE. If data transmission stops in this state, a timer is generated for this record, that is, the third field in the record. The third field of the above record is 179, it indicates that the current ASSURED status can still be maintained for 179 seconds. If a new packet passes through, the timer will be reset to the default 180 seconds. If no traffic is generated within 180 seconds, this status record will be deleted from the status table.

Finally, let's take a look at how the Linux kernel identifies the status of the ICMP protocol. ICMP is also a stateless protocol, which is only used to control rather than establish a connection. There are many types of ICMP packets, but there are only four types of response packets: Echo request and reply), Timestamp request and reply ), information request and response Information request and reply), as well as Address mask request and response Address mask request and reply), these packets have two statuses: NEW and ESTABLISHED. The time stamp request and information request have been abolished, and the echo request is still commonly used. For example, the ping command is used, and the address mask request is not commonly used, but it may sometimes be useful and worth using. Take a look at the figure below to get a general idea of the NEW and ESTABLISHED statuses of ICMP connections.

When the host sends a echo request to the target, the firewall considers the package to be in the NEW State. When the target responds to an explicit response, the firewall considers the package to be in ESTABLISHED. When the echo request is sent, ip_conntrack contains the following records:

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

As you can see, the ICMP record is a little different from TCP and UDP. The protocol name, timeout time, source, and destination address are the same. The difference is that there is no port, three new fields are added: type, code, and id. Field type indicates the ICMP type. The code indicates the ICMP code, which is described in the Appendix ICMP type. Id is the ID of the ICMP packet. Each ICMP packet is assigned an ID when it is sent, and the receiver assigns the same ID to the response packet, so that the sender can identify the request response.

The meaning of [UNREPLIED] is the same as that in the previous section. It indicates that the number is transmitted only in one direction, that is, no response is received. Next, there are three new fields, namely the Source and Destination Address of the response packet. Note that the type and code change with the response packet, the id is the same as that of the Request package. As before, the response packet is considered ESTABLISHED. However, after the response packet, the ICMP Connection will no longer have data transmission. Therefore, once the response packet passes through the firewall, the ICMP Connection trace records are destroyed. Therefore, it is not easy to capture ICMP protocol status records in the/proc/ip_conntrack file. You can use the following command to obtain these records:

#cat /proc/net/ip_conntrack | grep icmp

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

In the above cases, the request is regarded as NEW and the response is ESTABLISHED. In other words, when the firewall sees a request packet, it considers the connection to be in the NEW State. When there is a response, it is in the ESTABLISHED state.

---------------------------

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

-- State: There are four States available: INVALID, ESTABLISHED, NEW, and RELATED. The status of the package to be matched is specified. We have already described the status of the four data packets in detail. In this section, we only describe the usage of the 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 in the "RELATED" or "ESTABLISHED" status can pass through the firewall. In general, the status-based policy is configured at the beginning of each chain, because when the packet is matched, it can be directly processed, this is an efficient configuration method. The keyword ESTABLISHED is easier to understand, that is, matching data packets in the "ESTABLISHED connection" status. How can we understand "RELATED"? RELATED indicates that it does not belong to the ESTABLISHED connection, but it is related to the connection. For example, ftp and ftp will first establish an ftp-control connection to transmit commands, what actually transfers data is a connection called ftp-data, and the connection to transmit data is RELATED to the connection to transmit control signals. Therefore, "RELATED" is used for similar special services. Under normal circumstances, for each protocol: TCP, UDP, and ICMP, The Status policy can be configured separately, but a simple and efficient method is as follows:

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

Multiport: This matching option solves the problem of how to match services with Discontinuous 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 emails, surfing the Internet, and chatting with msn. Take a look at the following example:

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

Only two commands have solved the need for internal users to send and receive E_mail, browse webpages, and use msn to chat online. How is this simple ~