I did some research on netfilter. I found that there were various differences in recognition, so I will record it.
With CentOS8 (but not limited to), we found the following. ** iptables is nftables, not iptables ** ** Rules set by firewall-cmd are not displayed in iptables ** ** Use nft for all rule checks **
netfilter netfilter is a basic rule for processing packets on Linux It is the process of processing the packets received on the interface.
According to netfilter.org
netfilter is a set of hooks in the Linux kernel that allows kernel modules to register callback functions on the network stack. The registered callback function is called back for every packet that goes through each hook in the network stack.
That's right. Thank you google translate!
In other words, when a packet passes through the network stack, some processing can be inserted by a "hook" defined by netfilter. Does that mean?
A series of processes that pass through the network stack is called a chain. The chain consists of the following:
name | meaning |
---|---|
hook | In what part (of the network stack) |
priority | In what order |
type | What to do |
The basic figure is below.
Reference: https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg
A hook is a representation of "which part (of the network stack)" where processing is done. In other words, it expresses the timing of catching.
You can see that the processing has changed in the part of routing decision
near the center of the above figure.
The hook used depends on whether the inflow packet is "locally addressed" or "not locally addressed (= forwarded)".
Below is the focus on the hook part.
Local
process
^ | .-----------.
.-----------. | | | Routing |
| |-----> input / \---> | Decision |----> output \
--> prerouting --->| Routing | .-----------. \
| Decision | --> postrouting
| | /
| |---------------> forward ---------------------------
.-----------.
Reference: https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks
In other words, depending on the destination, the hooks used are the following two types.
For local prerouting -> input -> output -> postrouting
When transferring prerouting -> forward -> postrouting
(In addition to this, there seems to be a hook for packets to L2 called ingress.)
Priority expresses the "in what order" the processing is performed. In other words, it expresses the order of processing in each hook.
Priority is represented by a positive or negative number, but an alias is defined. dstnat and scrnat are only available for prerouting and postrouting hooks, respectively.
However, the substance is a numerical value until it gets tired.
Known as | Definition | priority | Available hooks |
---|---|---|---|
- | NF_IP_PRI_RAW_BEFORE_DEFRAG | -450 | all |
- | NF_IP_PRI_CONNTRACK_DEFRAG | -400 | all |
raw | NF_IP_PRI_RAW | -300 | all |
- | NF_IP_PRI_SELINUX_FIRST | -225 | all |
- | NF_IP_PRI_CONNTRACK | -200 | all |
mangle | NF_IP_PRI_MANGLE | -150 | all |
dstnat | NF_IP_PRI_NAT_DST | -100 | prerouting |
filter | NF_IP_PRI_FILTER | 0 | all |
security | NF_IP_PRI_SECURITY | 50 | all |
srcnat | NF_IP_PRI_NAT_SRC | 100 | postrouting |
- | NF_IP_PRI_SELINUX_LAST | 225 | all |
- | NF_IP_PRI_CONNTRACK_HELPER | 300 | all |
Reference: http://git.netfilter.org/nftables/tree/include/linux/netfilter_ipv4.h Reference: https://manpages.debian.org/testing/nftables/nft.8.en.html
It's similar to the so-called "table".
The type expresses what kind of processing is to be performed. In other words, it expresses what to do with packets specifically.
type | Available hooks |
---|---|
filter | all |
nat | prerouting,postrouting,input,output |
route | output |
that? This one is also similar to a "table". That's why it's confusing!
Reference: https://www.netfilter.org/projects/nftables/manpage.html
I explained above what constitutes netfilter, but how do you operate netfilter? So, it's about the software that operates them.
firewalld is at the top and iptables or nftables is running on the backend. Iptables or nftables running on the backend are operating netfilter.
Older versions of firewalld have iptables on the backend, The new version of firewalld uses nftables as the backend.
Very easy to understand. I wonder if this one is the title of this article.
Reference: https://firewalld.org/documentation/concepts.html
iptables is a tool that allows you to manipulate netfilter. In the old CentOS before firewalld was introduced, iptables was daemonized (serviced?) With iptables-service. In other words, I was doing filtering or NAT by directly changing the iptables rules with the iptables command or by loading a specific file.
CentOS8 also has iptables, but the entity runs on nftables.
# iptables --version
iptables v1.8.2 (nf_tables)
That said, iptables is no longer iptables.
# ll /usr/sbin/iptables
lrwxrwxrwx.1 root root 17 November 9 03:40 /usr/sbin/iptables -> xtables-nft-multi
# man xtables-nft
NAME
xtables-nft ― iptables using nftables kernel api
DESCRIPTION
xtables-nft are versions of iptables that use the nftables
API. This is a set of tools to help the system administra‐
tor migrate the ruleset from iptables(8), ip6tables(8),
arptables(8), and ebtables(8) to nftables(8).
When you hit iptables, you can see the rules in a format like that. However, from iptables, I can't see the table added by nftables described later. Therefore, the rules displayed by iptables -L -nv -t nat | filter may not match the actual behavior.
For example, when you use firewall-cmd --add-masquerade
to forward a port from a Docker host to a container connected to a bridge. If you check the chain with nft, you can see the following operation.
# nft list chain ip firewalld nat_POST_public_allow
table ip firewalld {
chain nat_POST_public_allow {
oifname != "lo" masquerade
}
}
But I can't see the table called firewalld from iptables.
# iptables -L -t firewalld
iptables v1.8.2 (nf_tables): table 'firewalld' does not exist
Perhaps iptables or your kernel needs to be upgraded.
If you look at the TABLES part with man iptables
, you can only check the table with the specified keywords in iptables.
TABLES
There are currently five independent tables (which tables are present at any time depends on the kernel configuration options and which modules are
present).
-t, --table table
The tables are as follows:
filter:
nat:
mangle:
raw:
security:
In other words, if nftables is running on the firewalld back, the rules displayed in ** iptables are incorrect! ** ** So, for rule confirmation, use nft instead of ** iptables! ** **
nftables is also an alternative to iptables that allows you to manipulate netfilter. It seems that nftables can be made into a service with the same feeling as iptables mentioned above, but ...
# systemctl status nftables
● nftables.service - Netfilter Tables
Loaded: loaded (/usr/lib/systemd/system/nftables.service; disabled; vendor preset: disabled)
Active: inactive (dead)
Docs: man:nft(8)
In CentOS8, firewalld is running and nftables is running behind the scenes, so it seems that the daemon as nftables is resting.
The contents are flushed (= removed) of the rule and read the configuration file with the nft
command as shown below.
It's similar to daemonizing iptables.
# cat /usr/lib/systemd/system/nftables.service | grep nft
Documentation=man:nft(8)
ExecStart=/sbin/nft -f /etc/sysconfig/nftables.conf
ExecReload=/sbin/nft 'flush ruleset; include "/etc/sysconfig/nftables.conf";'
ExecStop=/sbin/nft flush ruleset
In debian / arch / ubuntu / fedora, nftables daemon behavior seems to be the default.
Reference: https://wiki.nftables.org/wiki-nftables/index.php/Nftables_from_distributions
nft
nftables are provided by the command nft
.
The rules set in nft are expressed as a chain, which is the process itself, and a table that groups the chains together.
A chain is a collection of processes expressed by a specific type in a specific hook, and there is only one "what part (of the network stack)", "in what order", and "what kind of processing". It is put together in the chain of. A table can be thought of as a virtual group of multiple chains.
Use the command nft list
to check the settings.
nft list table(s)
Only the names of all the tables that have been set are displayed.
# nft list tables
table ip filter
table ip6 filter
(Or a lot)
Displays all the configured chains of the specified table.
# nft list table ip nat
table ip nat {
chain PREROUTING {
type nat hook prerouting priority -100; policy accept;
fib daddr type local counter packets 0 bytes 0 jump DOCKER
}
(All chains contained in table ip nat are displayed)
nft list chain(s) For all the set chains, it is displayed which table each chain is included in, and in what order the processing is performed in "which part (of the network stack)" which is the activation condition. Will be done. (Specific processing details are not displayed)
# nft list chains
table ip filter {
chain INPUT {
type filter hook input priority 0; policy accept;
}
chain FORWARD {
type filter hook forward priority 0; policy drop;
}
(A lot is displayed)
Display the specified chain
# nft list chain ip filter FORWARD
table ip filter {
chain FORWARD {
type filter hook forward priority 0; policy drop;
counter packets 0 bytes 0 jump DOCKER-USER
(A lot is displayed)
All the rules that have been set are displayed.
# nft list ruleset
table ip filter {
chain INPUT {
type filter hook input priority 0; policy accept;
}
chain FORWARD {
type filter hook forward priority 0; policy drop;
counter packets 0 bytes 0 jump DOCKER-USER
(A lot of them are displayed)
The handling of packets, including netfilter, is profound. You may still have the wrong understanding, and even if you set it to texto, it may work. I want to incorporate the correct knowledge as much as possible.
Recommended Posts