Linux Firewall iptables – Part 3: Kernel space plays a crucial role when configuring iptables, as it is responsible for processing network packets. Understanding how iptables operates within the kernel space is essential for implementing
In our previous two articles, we have thoroughly introduced iptables. Today, we’ll discuss a practical application of iptables at layer 7. As we mentioned before, iptables/netfilter operates in the kernel space and does not support application layer protocols. However, applications such as QQ, MSN, and Thunder are difficult to completely block at the transport or network layer. This is because they cleverly switch to other open ports once their default ports are blocked. Therefore, blocking them is effective only at layer 7. In response to this, some have developed patches for iptables/netfilter, allowing iptables to support layer 7 protocols by enhancing its capabilities.
Since the author of iptables-l7 has not updated the patch since 2009, the required kernel version and iptables package are relatively old. To use it, we must compile the kernel and iptables by ourselves.
We need the following packages:
Install the compilation environment:
Create the necessary user for compilation, and extract the kernel files:
Patch the kernel for layer 7:
Configure and compile the kernel:
To save time, we use the system’s default config file as a template and modify it accordingly.
Select network features:
Select network options:
Select netfilter modules:
Select core netfilter configurations:
Add support for the layer 7 module:
Disable RedHat kernel module verification:
Since RedHat introduced a module signature mechanism to prevent others from modifying its kernel modules for redistribution and our modules lack the signature, this feature must be disabled to compile successfully.
#yum install screen -y
#screen
#make –j 4
#make modules_install
#make install
Check if the new kernel is installed successfully:
Boot using the new kernel:
Preparatory work before compilation:
Compile and install:
Set up the accompanying scripts and configuration files:
Install the layer 7 patch:
Enable connection tracking function:
Construct experimental topology:
NAT Server: 192.168.1.0/24, 192.168.23.0/24
Client: 192.168.23.0/24
Create NAT entries:
It can be seen that the client is indeed accessing the internet through the NAT Server:
Now, QQ can also log in:
Set layer 7 entry to deny QQ:
Login has already failed:
Matched layer 7 rule:
Still able to access the internet:
Matched NAT rule:
Principle of rejecting QQ connection:
OK, our experiment was successful. We can effectively prevent QQ login, but still access the internet. Although we are capable of restricting such functionalities and even more at layer 7, I do not advocate for companies to use it. Only open and free companies are truly dynamic – relying on authority to prohibit certain things is not a fundamental solution. Please point out any errors.