Iptables-1.1.9 Guide (Super classic) (3) -- Linux Enterprise Application-Linux server application information, below is read details. The TTL operation is used to change the TTL of a data packet. We can make all data packets have only one special TTL. There is a good reason for its existence, that is, we can cheat some ISPs. Why cheat them? Because they don't want us to share a connection. The ISPs will look for whether a single computer uses different TTL values and use these to determine whether the connection is shared.
MARK is used to set a special MARK for the package. Iproute2 can identify these tags and decide different routes based on different tags (or no tags. We can use these tags for bandwidth restrictions and request-based classification.
3.3. nat table
This table is only used for NAT, that is, the source or target address of the conversion package. Note: As we mentioned earlier, only the first package of the stream will be matched by this link, and the subsequent package will be automatically processed in the same way. The actual operations are divided into the following types:
*
DNAT
*
SNAT
*
MASQUERADE
DNAT operations are mainly used in this case. You have a valid IP address, and you need to redirect access to the firewall to other hosts (such as DMZ ). That is to say, we changed the destination address so that the packet can be rerouted to a host.
SNAT changes the source address of the package, which can greatly hide your local network or DMZ. A good example is that we know the external address of the firewall, but we must replace the local network address with this address. With this operation, the firewall can automatically perform SNAT and De-SNAT (reverse SNAT) on the packet so that the LAN can be connected to the Internet. If you use an address like 192.168.0.0/24, you will not receive any response from the Internet. Because IANA defines these networks (and others) as private, they can only be used inside the LAN.
The role of MASQUERADE is exactly the same as that of MASQUERADE, but the computer load is a little more. For each matching packet, MASQUERADE needs to find available IP addresses, unlike the IP addresses used by SNAT. Of course, this also has the advantage that we can use addresses obtained through dialing such as PPP, PPPOE, and SLIP. These addresses are randomly allocated by the ISP's DHCP.
3.4. Filter table
The filter table is used to filter data packets. We can match and filter packets at any time. Here, we will DROP or ACCEPT the package based on the package content. Of course, we can also do some filtering in advance in other places, but this table is designed for filtering. Almost all targets can be used here. A lot of details are provided later. Now you only need to know That filtering is done here.
Chapter 4. Status Mechanism
This chapter describes the status mechanism in detail. After reading this chapter, you will have a comprehensive understanding of how the status mechanism works. We use some examples to illustrate the status mechanism. Practice.
4.1. Overview
The status mechanism is a special part of iptables. In fact, it should not be called the status mechanism because it is only a connection tracking mechanism. However, many people recognize the status mechanism name. In this article, I also use this name more or less to indicate the same meaning as the connection trace. This should not cause any confusion. Connection Tracing allows Netfilter to know the status of a specific connection. The firewall that runs Connection Tracing is called a firewall with a State mechanism. State firewall is safer than non-State firewall because it allows us to write more rigorous rules.
In iptables, a package is related to four different states of the tracked connection. They are NEW, ESTABLISHED, RELATED, and INVALID. We will discuss each status in depth later. With the -- state match operation, we can easily control "Who or what can initiate a new session ".
All connection traces made by the framework specified by Netfilter in the kernel are called conntrack ). Conntrack can be installed as a module or a part of the kernel. In most cases, we want to have more detailed Connection Tracking than the default conntrack. Because of this, conntrack has many components used to process TCP, UDP, or ICMP protocols. These modules extract detailed and unique information from data packets, so they can keep track of each data stream. This information also informs the current status of the conntrack stream. For example, UDP streams are generally determined by their destination address, source address, destination port, and source port.
In the previous kernel, we can enable or disable the reorganization function. However, this option has been canceled since iptables and Netfilter, especially Connection Tracing, are introduced to the kernel. Connection Tracing does not work properly because there is no package reorganization. Now the reorganization has been integrated into the conntrack and is automatically started when the conntrack starts. Do not disable the reorganization function unless you want to disable Connection Tracing.
Except for locally generated packets processed by the OUTPUT chain, all connection traces are processed in the PREROUTING chain, meaning that iptables will calculate all the statuses in the PREROUTING chain. If we send the initialization package of a stream, the status will be set to NEW in the OUTPUT chain. When we receive the response packet, the status will be set to ESTABLISHED in the PREROUTING chain. If the first package is not generated locally, it will be set to NEW in the PREROUTING chain. In summary, all state changes and calculations are completed in the PREROUTING chain and OUTPUT chain in the nat table.
4.2. conntrack records
Let's take a look at how to read the conntrack records in/proc/net/ip_conntrack. These records indicate the currently tracked connections. If the ip_conntrack module is installed, the display of cat/proc/net/ip_conntrack is similar:
All information maintained by the conntrack module is included in this example, so that you can know the status of a specific connection. First, the Protocol is displayed. Here it is tcp, followed by 6 in decimal format (note: the protocol type code of tcp is 6 ). The next 117 is the survival time of this conntrack record, which will be consumed regularly until more packets of this connection are received. At that time, this value will be set to the default value of the current state. Next is the status of the connection at the current time point. The preceding example shows that the package is in the SYN_SENT state. The value is displayed in iptables so that we can understand it. The internal values are slightly different. SYN_SENT indicates that the connection we are observing only sends a tcp syn Packet in one direction. The following are the source address, Destination Address, source port, and destination port. There is a special word UNREPLIED, indicating that this connection has not received any response. Finally, it is the information of the response packet to be received. Their address and port are opposite to the previous one.
The connection trace information varies according to the protocol included in the IP address. All corresponding values are defined in the header file linux/include/netfilter-ipv4/ip_conntrack *. h. The default values of IP, TCP, UDP, and ICMP protocols are defined in linux/include/netfilter-ipv4/ip_conntrack.h. You can view the corresponding protocols for specific values, but we cannot use them here, because most of them are used only within conntrack. As the status changes, the survival time also changes.
Note
Recently, patch-o-matic has a new patch, which can take the time-out mentioned above as a system variable, so that we can change their values when the system is idle. In the future, we don't have to re-compile the kernel to change these values.
These can be changed through some special system calls under/proc/sys/net/ipv4/netfilter. Take a closer look at the variables in/proc/sys/net/ipv4/netfilter/ip_ct.
When a connection is transmitted in both directions, the conntrack record deletes the [UNREPLIED] flag and resets it. There is a [ASSURED] record at the end, indicating that there is no traffic in both directions. This record is determined. When the connection trace table is full, it will not be deleted, and records without [ASSURED] will be deleted. The number of records that the connection trace table can hold is controlled by a variable, which can be set by the ip-sysctl function in the kernel. The default value depends on your memory size. 8192 MB can contain 16376 directories, and MB is. You can also view and set it in/proc/sys/net/ipv4/ip_conntrack_max.
4.3. Status of data packets in user space
As mentioned above, the packet status varies according to the protocol included in the IP address, but there are only four States outside the kernel, namely, in the user space: NEW, ESTABLISHED, RELATED and INVALID. They are mainly used together with status matching. The following describes the following statuses:
Table 4-1. The status of the data packet in the user space
State (State) Explanation (comment)
NEW indicates that this package is the first package we see. This is the first package of a connection seen by the conntrack module. It will be matched soon. For example, if we see a SYN packet, it is the first packet of the connection we pay attention to, and we need to match it. The first packet may not be a SYN packet, but it will still be considered as NEW. This may cause some problems, but it is very helpful for some situations. For example, when we want to restore a connection lost from another firewall, or a connection has timed out, but it is not actually closed.
ESTABLISHED has noticed the data transmission in both directions and will continue to match the connected package. It is easy to understand connections in the ESTABLISHED state. As long as the request is sent and received, the connection is ESTABLISHED. To change a connection from NEW to ESTABLISHED, you only need to receive a response packet, whether it is sent to the firewall or forwarded by the firewall. ICMP errors, redirection, and other information packages are also considered as ESTABLISHED, as long as they are responses to the information we send.
RELATED is a troublesome status. When a connection is RELATED to a connection already in the ESTABLISHED status, it is considered as a RELATED connection. In other words, to create a RELATED connection, you must first have an ESTABLISHED connection. This ESTABLISHED connection then generates a connection other than the primary connection. This new connection is RELATED, provided that the conntrack module can understand the RELATED. Ftp is a good example. The FTP-data connection is RELATED with FTP-control. There are other examples, such as using the irc dcc connection. With this status, ICMP response, FTP transmission, DCC, and so on can work normally through the firewall. Note that most UDP protocols depend on this mechanism. These protocols are complex. They place connection information in data packets and require that the information be correctly understood.
INVALID indicates that the data packet cannot be identified as a connection or has no status. This may occur for several reasons, such as memory overflow, and the ICMP error message of the unknown connection. Generally, we DROP anything in this state.
These statuses can be used together to match data packets. This can make our firewall very strong and effective. In the past, we often opened all ports above 1024 to allow the response data. Now, with the state mechanism, you do not need to do this again. Because we can only open ports with response data, and other ports can be closed. This makes it much safer.
4.4. TCP Connection
In this section and the following sections, we will discuss in detail these statuses and how to operate them in TCP, UDP, and ICMP basic protocols. Of course, other protocols will also be discussed. We should start with TCP because it is a stateful protocol and has a lot of details about the iptables status mechanism.
A TCP connection is established after three handshakes and negotiation of the connection information. The entire session starts with a SYN packet, then a SYN/ACK packet, and finally an ACK packet. In this case, the session is established successfully and data can be sent. The biggest problem is how Connection Tracing controls the process. It is actually very simple.
By default, Connection Tracing basically performs the same operation on all connection types. Take a look at the following picture to see what the stream is in at different stages of the connection. As you can see, The Connection Tracing Code does not look at the process of establishing a TCP connection from the user's point of view. When the connection trace sees the SYN packet, it considers the connection to be in the NEW State. when it sees the returned SYN/ACK packet, it considers the connection to be in the ESTABLISHED state. If you think about Step 2, you should be able to understand why. With this special processing, the NEW and ESTABLISHED packages can be sent out of the local network, and only the connection of ESTABLISHED can have response information. If we regard all data packets transmitted during the entire connection process as NEW, the packages used for the three-way handshake are all in the NEW State, so that we cannot block connections from the external network to the local network. Even if the connection is in the external direction, the packet used by the connection is also in the NEW State, and for other connections to be transmitted normally, we have to allow the NEW status package to return and enter the firewall. What's more complicated is that many internal states are used for the TCP connection kernel. Their definitions are listed on page 21-23 of RFC 793-Transmission Control Protocol. But fortunately we cannot use it in the user space. We will introduce this in detail later.
As you can see, from the user's point of view, this is very simple. However, from the kernel perspective, it is still difficult. Let's look at an example. Consider how the connection status changes in/proc/net/ip_conntrack.
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.
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. Of course, this is hypothetical.
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 we have sent out the last three-step handshake package, namely the ACK package, and the connection enters the ESTABLISHED status. Transmit several more packets, and the connection is [ASSURED.
The following describes the status of a TCP connection when it is closed.
For example, the connection (in two directions) will not be closed before the last ACK packet is sent. Note that this is only applicable to general cases. The connection can also be closed through sending, which is used to reject a connection. After the RST packet is sent, the connection can be disconnected only after a preset period of time.
After the connection is closed, it enters the TIME_WAIT state. The default time is 2 minutes. The reason for leaving this time is to allow the data packet to pass the check of various rules completely, and also to allow the data packet to pass through the crowded router to reach the destination.
If the connection is reset by the RST package, the connection is directly closed. This means that the default time is only 10 seconds before the function is disabled. The RST package does not need to be confirmed. It will directly close the connection. For TCP connections, we have not discussed other statuses. The following shows a complete status list and an extra value.
Table 4-2. Internal status
State Timeout value
NONE 30 minutes
ESTABLISHED 5 days
SYN_SENT 2 minutes
SYN_RECV 60 seconds
FIN_WAIT 2 minutes
TIME_WAIT 2 minutes
CLOSE 10 seconds
CLOSE_WAIT 12 hours
LAST_ACK 30 seconds
LISTEN> 2 minutes
These values are not absolute. They can be changed with the kernel revision or through the variable/proc/sys/net/ipv4/netfilter/ip_ct_tcp. These default values are proven in practice. They are measured in jiffies (1% seconds), So 3000 represents 30 seconds.
Note
Note that the status mechanism does not check the flag of the TCP packet in the user space (that is, the TCP flag is transparent to it ). If we want to allow the NEW status package to pass through the firewall, We need to specify the NEW status. We understand that the NEW status refers to the SYN packet, but iptables does not check these flag bits. This is the problem. Some packets without SYN or ACK are considered as NEW. Such a package may be used by the redundant firewall, but the network with only one firewall is very unfavorable (may be attacked ). So how can we not be affected by such a package? You can use the command in the NEW status package without SYN set. Another way is to install the tcp-window-tracking Extension function in patch-o-matic, which enables the firewall to track the status based on some TCP flag.
4.5. UDP connection
UDP connections are stateless because they do not have any connection establishment or closure processes, and most of them do not have serial numbers. 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 of conntrack.
From the perspective of users, the establishment of UDP connections is almost the same as that of TCP. Although the conntrack information looks a little different, it is essentially the same. Next let's take a look at the conntrack record after the first UDP packet is sent.
The previous two values show that this is a UDP packet. The first is the protocol name, the second is the Protocol number, and the third is the survival time of the status. The default value is 30 seconds. Next is the package source, destination address and port, as well as the source, destination address and port of the expected response package. [UNREPLIED] indicates that no response has been received.
Once the response to the first packet is received, the [UNREPLIED] Mark will be deleted, and the connection will be considered as ESTABLISHED, but the ESTABLISHED mark will not be displayed in the record. Correspondingly, the status timeout time also changes to 180 seconds. In this example, there are only 170 seconds left. After 10 seconds, it will be reduced to 160 seconds. There is one thing that is indispensable. Although it may change, it is the [ASSURED] mentioned above. To change to the [ASSURED] status, there must be more traffic on the connection.
It can be seen that the [ASSURED] status record is not much different from the previous one, except that the mark is changed from [UNREPLIED] to [ASSURED]. If the connection lasts for less than 180 seconds, it will be interrupted. 180 seconds is a little shorter, but it is enough for most applications. As long as the connection package passes through the firewall, the timeout value will be reset to the default value, and all statuses will be like this.
4.6. ICMP Connection
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, which are Echo request and reply, Timestamp request and reply ), information request and reply, as well as Address mask request and reply, 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 content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
A Free Trial That Lets You Build Big!
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
