Detailed explanation of Netfilter and iptables commands, from entry to mastery

Netfilter is an important framework of the network part in the Linux kernel. The kernel completes some operations on IP packets through netfilter. Iptables is the front-end command line tool of netfilter. Linux system administrators can use the iptables tool to tell netfilter how to process received, forwarded and outgoing IP packets. Netfilter usually provides the function of IP packet processing with five tables and four chains + rules in the chain, and the two most important functions are packet filtering and address translation (NAT). Netfilter works on the TCP/IP protocol stack of Linux. In essence, netfilter is a set of callback functions inserted at each processing point of each layer of the TCP/IP protocol stack of Linux, so that users can process IP packets at specified points. .

1. Introduction to netfilter architecture and working principles

  1. The working process of Netfilter:
  • Users tell netfilter through iptables how to process packets entering and leaving Linux.
  • Netfilter analyzes the IP headers of all IP packets
  • If there is a matching rule, process the message according to the method specified by the rule
  1. It seems very simple, but the realization of the actual processing process is more complicated. netfilter contains a series of tables, each table contains some default rule sets called chains, and each chain contains one or more rules, so netfilter is composed of tables-chains-rules three-tier structure. This is what we usually call five tables and four chains. The default table is filter table, which contains the following 3 chains:
  • INPUT: The rules for processing the IP address whose target address is the IP address of Linux itself are placed in this chain.
  • FORWARD: For the target address is the IP address of other hosts, the processing rules of the IP packets that the Linux host needs to forward are placed in this chain.
  • OUTPUT: The rules for processing IP packets generated by this Linux and to be sent to other hosts are placed in this chain.

There are also commonly used nat tables, mangle tables, the chains contained in these tables can be found in: Introduction to each table of netfilter

  1. In general, the processing process of IP packets in netfilter is shown in the figure below
  • It is first processed by the prerouting chain in each table, and then sent to the input/forward chain for processing. When sending, it is processed by the output and postrouting chain successively.

figure 1

  • For the specific processing path, see the colored part in the figure below. According to whether the message enters the link or directly enters the IP layer for processing, it is divided into different paths for middle layer processing and IP layer processing.
    insert image description here
  • The IP layer processing flow without considering the raw table is as follows:
    insert image description here
    Step 1 : After the message reaches the TCP/IP protocol stack, it is checked by the bridge check, and it is determined that the message is transferred to the IP layer for processing, and then the mangle table's PREROUTING The rules in the chain are analyzed. Here, all operations supported by the mangle table can be performed on the IP message (for example: modification of the TOS byte, marking the message, etc.).
    Step 2 : The message is transferred to the pre-routing chain of the nat table for analysis and processing. In addition, SNAT, DNAT, port remapping, etc. can be performed. Because DNAT (destination network address translation) modifies the destination address of the received message, it is logically determined that it must be completed before the message enters the routing and forwarding decision processing module of the kernel, so that the routing and forwarding processing module can follow the modified Target IP address, forward the message to the correct target host according to the modified target address.
    The third step : the routing and forwarding module of the kernel determines how to forward the message in the future (forwarding or that the message is sent to the local machine). This is not a function of netfilter.
    the fourth step: If the IP message is sent to the local machine, the message will enter the INPUT chain of the mangle table (modify TOS, mark, etc.) for processing. Then enter the INPUT chain of the filter table for processing (can be accepted, rejected or dropped, etc.). If the message is received, it will be sent to the upper layer application for processing (such as a WEB request), and the upper layer application will generate a response message (such as a web browsing response) message, which will be sent to the OUPUT chain of the mangle table Then the OUTPUT chain of the nat table is processed by the OUTPUT chain of the filter table (after the processing is completed, there is a recheck route rerouting process, see the second figure at the beginning of the article). Finally, it is sent to the POSTROUTING chain of the mangle table and the POSTROUTING chain of the nat table for processing, and finally reaches the network card for sending.

This describes how the message is processed in the preset chain of the preset table. In the actual network, users can customize their own chain, and then transfer the message to the customized user chain through the preset chain for processing. For example: we can create a user-defined chain named SSH-chain for the SSH login connection, and then tell the kernel in the INPUT chain to send the received TCP message with the destination port 22 to the SSH-chain for processing.

2. iptables operation command description

The operation of iptables on chain supports the following operation commands:

  • List the rules in the specified chain (iptables -L CHAIN).
  • Modify the processing action policy of the specified chain (iptables –P CHAIN ​​ACCEPT).
  • Create a user-defined chain (iptables –N CHAIN).
  • Delete all rules in the specified chain (iptables -F CHAIN).
  • Delete the specified chain (iptables –D CHAIN), it can only be operated when the chain is already empty
  • Clear the counter of the specified chain (iptables –Z CHAIN). Each rule in the chain has a counter to count the number of packets that hit the rule. This command is used to reset the counter.

For the above operations –L, –F, –D, –Z, if no chain name is specified, it will take effect on all chains in the table by default, and if no table is specified, it will default to filter table.
If you want to specify a table, you need to specify it with -t: iptables –t nat  …

The operation of iptables on rules supports the following operation commands:

  • Add a rule to the specified chain, put it at the bottom ------(iptables –A)
  • Insert a rule into the specified chain and place it at the top ------(iptables –I)
  • Replace an existing rule in the specified chain------------------(iptables –R)
  • Delete the specified rule in the specified chain------------------------(iptables –D)

iptables -A adds a rule to the specified chain, and the added rule is placed in the last rule list; iptables -I inserts a rule into the specified chain as the first rule in the rule list. Of course, you can also insert a rule to the specified position of the rule list, such as iptables –I CHAIN ​​4 can insert a new rule at the fourth position of the rule list.

iptables -D can delete the specified rule by specifying the rule or by specifying the location of the rule.
The command format for adding a rule is as follows:

iptables –A <CHAIN_NAME><filtering specifications>… -j <TARGET>

Use the rules specified in the Filtering specifications field to analyze IP packets, and use the actions specified in the TARGET field to operate on the hit packets.

2.1 、Filtering Specifications

The rules of iptables support the analysis and identification of IP packets through the specified network card, specified protocol, specified port and other filter conditions. These filter conditions can also be used in combination, which provides the best flexibility and extensiveness for filter rules.

  1. Filtering specifications for Layer2:

-i and -o are used to specify the network interface device, -i is the abbreviation of "–in-interface", indicating the network card that receives the data packet, -o is the abbreviation of "–out-interface", indicating the network card that sends the data packet.
+ is a wildcard, for example -i eth+ means all network card devices switched with the three letters eth, using wildcards allows us to configure rules to multiple network cards at one time.

"!" means negation or negation, for example -i ! eth1 means that the packets received by eth1 will not be analyzed and hit by the specified rules.

注意OUTPUT和POSTROUTING chains没有输入网络设备接口,所以这二个chains中的规则不能使用 -i 选项。同样INPUT和PREROUTING chains 没有输出网络设备接口,所以这二个chains中的规则不能使用 -o 选项。
  1. Filtering specifications for Layer3:

At the IP layer, it supports source IP address (-s, --src, or --source), and destination IP address (-d, --dst, or --destination). Note that the source IP address and destination IP address here can be the host IP address, IP subnet or domain name (such as "-s 217.207.125.58", "-s www.packtpub.com", or "-s 217.207.125.58/ 32”).
When using the domain name to filter, if the domain name with multiple IP addresses is concerned, the effect of using the domain name to filter is equal to adding all the IPs resolved by the DNS server for this domain name when adding the rule.

  1. Filtering specifications for Layer4:
    In the transport layer, the -p parameter is the abbreviation of "–protocol", and the protocol name tcp, udp, or icmp can be used to specify the protocol type.
  • If it is ICMP, you can also use "–icmp-type" to further specify the type of ICMP message.

  • If it is UDP, you can use "--source-port" or "--sport" and "--destination-port" and "--dport" to further specify the source and destination port numbers.

  • If it is TCP, TCP, in addition to the above source and destination ports, you can also use "--tcp-flags", "--syn" and "--tcp-option" options, where TCP flags can use "SYN ACK FIN RST URG PSH ALL NONE"; --syn" is used to identify the packet that initiates a TCP connection, which is equivalent to: "--tcp-flags SYN,RST,ACK SYN". "--tcp-option" is used to filter the specified tcp option field value message.

      注意L2, L3, L4既链路层,IP层和传输层的Filtering specifications可以在同一条规则里联合使用。
    

netfilter/iptables also has a special project to develop and implement additional analysis rules. This project is called "patch-o-matic", which can be found on the project's official website http://www.netfilter.org/projects/ patch-o-matic/index.html See details.

iptables/netfilter also plans to expand the rules filtering rules to support all levels of the OSI 7-layer model, called l7-filter. Later, we can create an article to specifically talk about the function of this l7-filter.

2.2、Target Specifications

In the filter table, the most commonly used Target actions are DROP and ACCEPT. If a packet hits a rule described in the previous chapter, and the target action of this rule is DROP , then the kernel will simply discard the packet, and then will not match other rules. If the target action is ACCEPT , then the same packet will be received instead of continuing to match other rules in the current chain in the current table. There is also a target action of REJECT . If the target action is REJECT, the kernel will discard the message and send an ICMP message to the source IP address of the discarded message, telling the sender that this is an ICMP 'port unreachable' Error, if you want to customize the ICMP error message, you need to use " --reject-with " option instead of REJECT.
Of course, in addition to the above DROP, REJECT, ACCEPT, REJECT-WITH, the action target of the target can also be to forward the specified message to the user-defined chain for further processing . For example: we have used

iptables -N SSH

Created a user-defined chain called SSH, then we can use the following command to forward all TCP packets whose destination port is 22 to the SSH chain for further processing.

iptables -A INPUT -p tcp --dport 22 -j SSH

There is also a very useful target action called LOG . When a message hits a rule, it will be recorded in the kernel log (dmesg or syslogd). LOG target provides multiple configurable sub-items:

  • –log-level level: Define the log level as debug, info, notice, warning, err, crit, alert, and emerg (corresponding numbers are 7-0)
  • --log-prefix prefix: Provide a log prefix string of up to 29 bytes,
  • --log-tcp-sequence: Logs TCP sequence number
  • –log-tcp-options: the value of the option field of Logs TCP
  • –log-ip-options: the value of the option field of Logs IP
  • –log-uid: Logs The process number of the user process that generated the message. The
    target action target is LOG, which is different from the above ACCEPT, DROP, REJECT. After the message hits the rule with LOG as the target, it will Continue to match other rules in the same chain of the same table. Note that in order to prevent log flood attacks, we should only perform the LOG target action on limited packets.

The following is an example use case with user-defined chain SSH:

  1. We have created the SSH chain with the following two commands before, and forwarded the received TCP packets with the destination port 22 to the SSH chain for processing
iptables -N SSH
iptables -A INPUT -p tcp --dport 22 -j SSH
  1. Now we only receive ACCEPT SSH requests from the following two network segments: 192.168.0.0/27 and 10.10.15.0/24, record SSH requests from other addresses in the LOG, and limit the number of LOGs to 5 times per second to prevent Flooding LOG attack. So we add the following two rules to the SSH chain:
iptables -A SSH -s 192.168.0.0/27 -j ACCEPT
iptables -A SSH -s 10.10.15.0/24 -j ACCEPT
  1. Add a LOG target action to record other SSH requests, and then discard SSH requests from untrusted hosts
iptables -A SSH -m limit --limit 5/s -j LOG
iptables -A SSH -j DROP
  1. The following is to verify that the configuration was successful:
sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
SSH        tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain SSH (1 references)
target     prot opt source               destination         
LOG        all  --  0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4
ACCEPT     all  --  192.168.3.0/24       0.0.0.0/0           
ACCEPT     all  --  10.0.0.0/24          0.0.0.0/0           
DROP       all  --  0.0.0.0/0            0.0.0.0/0 
  1. Then you can use the -v option to see the number of hits:
sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  760 53836 SSH        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain SSH (1 references)
 pkts bytes target     prot opt in     out     source               destination         
  376 22344 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4
  659 45536 ACCEPT     all  --  *      *       192.168.3.0/24       0.0.0.0/0           
    0     0 ACCEPT     all  --  *      *       10.0.0.0/24          0.0.0.0/0           
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0   
  1. Then use the dmesg command to see the following log records, indicating that we have received an SSH connection from 192.168.3.88.
[26915.359507] IN=eth0 OUT= MAC=00:e0:99:62:ec:b6:70:b5:e8:4b:95:a9:08:00 SRC=192.168.3.88 DST=192.168.3.66 LEN=52 TOS=0x10 PREC=0x00 TTL=64 ID=10784 DF PROTO=TCP SPT=41118 DPT=22 WINDOW=501 RES=0x00 ACK URGP=0 

Later, we will describe the use of the targets target actions of nat table and mangle table. Note that this article only describes the most commonly used targets. If you need more target details, you can query the patch-o-matic project by yourself.

2.3. A configuration example of a basic Linux-based firewall

Below we create a basic firewall rule for the Linux system. By default, the default target action of Linux is ACCEPT on all chains of all tables.

#!/bin/bash
#assign variable $IPT with the iptables command
IPT=/sbin/iptables
#set policies on each chain
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT ACCEPT #default, but set it anyway
#flush all rules in the filter table
$IPT -F
#allow traffic on the loopback interface
$IPT -A INPUT -i lo -j ACCEPT
#allow icmp traffic
$IPT -A INPUT -p icmp -j ACCEPT
#allow incoming DNS traffic
$IPT -A INPUT -p udp --sport 53 -j ACCEPT
#allow established TCP connections
$IPT -A INPUT -p tcp ! --syn -j ACCEPT
  1. Set the overall strategy of INPUT and FORWARD chains to DROP
  2. Set the OUTPUT chain to ACCEPT
  3. This host does not enable the forwarding function, so no rules are added in the FORWARD chain.
  4. Do not add any rules to the OUTPUT chain, because we can send any message by default
  5. Delete all the rules in the filter table
  6. Some programs also use TCP/IP to communicate in the host, so it uses the lo port. We believe that all messages on the lo port are safe, so set the target action target of the lo port to ACCEPT in the INPUT chain
  7. It is allowed to receive ICMP messages, so that the machine can be pinged by other hosts on the network, and also traceroute, mtr, MTU path discovery and other functions based on ICMP protocol can work
  8. The DNS service works on port 53, so we receive connections from source port 53 (if you have the IP address of the DNS server, then we can replace it with the following command to only allow packets from the source port 53 initiated by the IP address of the DNS server, In order to achieve more security, it is assumed that the DNS servers are 1.1.1.1 and 1.1.2.1.
$IPT -A INPUT –s 1.1.1.1 -p udp --sport 53 -j ACCEPT 
$IPT -A INPUT –s 1.1.2.1 -p udp --sport 53 -j ACCEPT 
  1. Finally, we only allow TCP packets to be received from TCP connections initiated by our own host. Any active TCP connection request from the outside will be rejected (deny
    TCP SYN message).

Guess you like

Origin blog.csdn.net/meihualing/article/details/130552810