1. iptables and netfilter
In fact, iptables is not a real firewall. We can understand it as a client proxy. Through the iptables proxy, users implement the user's security settings into the corresponding "security framework". This "security framework" is the real firewall. , the name of this framework is netfilter
Netfilter is the real security framework of the firewall, and netfilter is located in the kernel space.
iptables is actually a command line tool located in user space. We use this tool to operate the real framework.
netfilter/iptables (hereinafter referred to as iptables) constitutes a packet filtering firewall under the Linux platform. Like most Linux software, this packet filtering firewall is free. It can replace expensive commercial firewall solutions to complete packet filtering and packet sealing. Features such as redirection and Network Address Translation (NAT).
Netfilter is a packet processing module within the core layer of the Linux operating system. It has the following functions:
- Network Address Translate
- Modification of data packet content
- and firewall functions for packet filtering
2. The concept of chain
Now, let's imagine why these "levels" are called "chains" in iptables? We know that the function of a firewall is to match "rules" for passing packets and then perform corresponding "actions". Therefore, when packets pass through these levels, they must match the rules on this level. However, this level There may not only be one rule, but many rules. When we string these rules into a chain, a "chain" is formed. Therefore, we imagine each "level" as shown in the figure below , in this way, it is more appropriate to call them "chains". Each packet passing through this "level" must match all the rules on this "chain". If there are rules that meet the conditions, then Execute the action corresponding to the rule.
3. The concept of table
Let's think about another problem. We have placed a series of rules on each "chain", but some of these rules are very similar. For example, type A rules filter IP or ports, and type B rules modify reports. Wen, at this time, can we put together the rules to achieve the same function? It must be possible.
We call the set of rules with the same function "table", so we can place rules with different functions in different tables for management, and iptables has defined 4 types of tables for us, each table corresponds to different functions, and the rules we define cannot escape the scope of these four functions. Therefore, before learning iptables, we must first understand the role of each table.
iptables provides us with the following classification of rules, or in other words, iptables provides us with the following "table"
- filter table: responsible for filtering functions, firewall; kernel module: iptables_filter
- nat table: network address translation, network address translation function; kernel module: iptable_nat
- mangle table: the function of disassembling packets, making modifications, and re-encapsulation; iptable_mangle
- Raw table: Turn off the connection tracking mechanism enabled on the NAT table; iptable_raw
means that all our customized rules are rules in these four categories, or in other words, all rules exist in these four "tables" .
4. Chain relationship
But what we need to pay attention to is that some "chains" are destined not to contain "certain types of rules", just like some "levels" inherently do not have certain functions. For example, "level A" is only responsible for attacking land enemies. , there is no air defense capability. "Level B" is only responsible for attacking air enemies and has no ability to defend against infantry. "Level C" may be more NB, as it can defend against both air and land enemies. "Level D" is the most powerful and can be used by sea, land and air. Defend.
Then let's take a look at what abilities each "level" has, or in other words, let's take a look at which "tables" the rules on each "chain" exist in.
Let's take the picture as an example and first look at which tables the rules on the prerouting "chain" exist in.
Note: The following figure is only used to illustrate which tables the rules on the prerouting chain exist in, and does not describe the order of the tables.
What does this picture mean? It means that the prerouting "chain" only has the functions corresponding to the nat table, raw table and mangle table. Therefore, the rules in prerouting can only be stored in the nat table, raw table and mangle table.
So, based on the above ideas, let's summarize what functions each "level" has,
or in which "tables" the rules in each "chain" exist.
- PREROUTING rules can exist in: raw table, mangle table, nat table.
- INPUT rules can exist in: mangle table, filter table, (there is also a nat table in centos7, but not in centos6).
- FORWARD rules can exist in: mangle table, filter table.
- OUTPUT rules can exist in: raw table, mangle table, nat table, filter table.
- POSTROUTING rules can exist in: mangle table, nat table.
In fact, we need to pay attention to one more thing, because when the data packet passes through a "chain", all the rules of the current chain will be matched, but there must always be an order when matching. We should match one by one, and we have said, Rules of the same functional type will be gathered in a "table", so which rules in the "table" will be executed at the front of the "chain". At this time, there needs to be a priority issue. We also take prerouting "chain" as shown.
The rules in the prerouting chain are stored in three tables, and the execution priorities of the rules in these three tables are as follows:
raw –> mangle –> nat
But we know that iptables has defined 4 "tables" for us. When they are in the same "chain", the execution priority is as follows.
Priority order (from high to low):
raw –> mangle –> nat –> filter.
But as we said before, some chains inherently cannot use the rules in certain tables, so the rules in the four tables are in the same chain. Currently there is only the output chain, which is the legendary level that can be defended by sea, land and air.
For more convenient management, we can also create a custom chain in a table and place the rules set for a certain application in this custom chain. However, the custom link cannot be used directly and can only be used by a certain The default chain can only work when called as an action. We can imagine that a custom chain is a relatively "short" chain. The rules on this "short" chain are all formulated for a certain application, but this The short chain cannot be used directly, but needs to be "welded" to the default chain defined by iptables before it can be used by IPtables. This is why the default defined "chain" needs to refer to the "custom chain" as an "action". . This is something for later, we will talk about it later, we can understand it more clearly when using it in practice.
5. The process of data passing through the firewall
Combining all the above descriptions, we can summarize the process of data packets passing through the firewall as follows:
When we write Iptables rules, we must always keep this routing sequence diagram in mind and configure the rules flexibly.
We will rewrite the frequently used correspondences here to facilitate viewing of corresponding legends.
In which tables are chain rules stored (correspondence from chain to table):
PREROUTING rules can exist in: raw table, mangle table, nat table.
INPUT rules can exist in: mangle table, filter table, (there is also a nat table in centos7, but not in centos6).
FORWARD rules can exist in: mangle table, filter table.
OUTPUT rules can exist in: raw table, mangle table, nat table, filter table.
POSTROUTING rules can exist in: mangle table, nat table.
Which chains can the rules in the table be used by (correspondence from table to chain):
Which chains can the rules in the raw table be used by: PREROUTING, OUTPUT
mangle Which chains can the rules in the table be used by: PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING
Which chains can the rules in the nat table be used by: PREROUTING, OUTPUT, POSTROUTING (INPUT is also available in centos7, but not in centos6)
Which chains can be used by the rules in the filter table: INPUT, FORWARD, OUTPUT
nat in the figure below The table is no longer marked in centos7.
6. The concept of rules
I’ve said it all in a circle and come back again. In the above description, we have been mentioning the rules, but we have not elaborated on them. Let’s talk about it now.
Let’s first talk about the concept of rules, and then explain it in layman’s terms.
Rule: Try to match each packet flowing here according to the specified matching conditions. Once the match is successful, it will be processed by the processing action specified after the rule;
So let’s explain in a layman’s terms what the rules of iptables are. I made an analogy before. Each “chain” is a “level”, and every packet passing through this “level” must match the rules on this level. If there is a match, the message will be processed accordingly. For example, you and I are like two "messages" at the moment. We both have to enter the customs at this moment, but the city lord has a destiny, and only the powerful person Those who do not meet these conditions cannot enter, so the guards guarding the gate began to look at you and me according to the "rules" set by the city lord. In the end, you successfully entered the gate, but I was turned away. Because you meet the criteria of "Qiyu Xuanang", you are "released", but I do not meet the standards, so I am not released. In fact, "Qiyu Xuanang" is a "matching condition", and "release" is a "Actions", "matching conditions" and "actions" form rules.
Now that we understand the concept of rules, let’s talk about the components of rules. Here we only briefly list the structure of rules. The rules will be summarized separately in a later article.
Rules consist of matching conditions and processing actions.
7. Matching conditions
Matching conditions are divided into basic matching conditions and extended matching conditions.
Basic matching conditions:
source address Source IP, destination address Destination IP.
The above contents can be used as basic matching conditions.
Extended matching conditions:
In addition to the above conditions, there are many other conditions that can be used for matching. These conditions are generally called extended conditions. These extended conditions are actually part of netfilter and only exist in the form of modules. If you want to To use these conditions, you need to rely on the corresponding extension modules.
Source Port, Destination Port,
and the above contents can be used as extended matching conditions.
8. Processing actions
The processing action is called target in iptables (this is not accurate, let's call it that for now), and the action can also be divided into basic actions and extended actions.
Here are some commonly used actions, and subsequent articles will provide detailed examples and summaries of them:
- ACCEPT: Allow the packet to pass.
- DROP: Directly discard the data packet without giving any response information. At this time, the client will feel that its request has been thrown into the sea, and it will not respond until the timeout period has elapsed.
- REJECT: Refuse to pass the data packet. If necessary, a response message will be sent to the data sender. The client will receive the rejection message as soon as it requests.
- SNAT: Source address translation, which solves the problem of intranet users using the same public address to access the Internet.
- MASQUERADE: It is a special form of SNAT, suitable for dynamic and temporary IP addresses.
- DNAT: Destination Address Translation.
- REDIRECT: Do port mapping on this machine.
- LOG: Record log information in the /var/log/messages file, and then pass the data packet to the next rule, which means that it does not do any other operations on the data packet except recording, and still allows the next rule to match.
Article reference from: Zhu Shuangyin’s blog