Popular about iptables

In the Linux operating system, there is a powerful tool for traffic management - the firewall, called iptables. In addition to basic security features, iptables and its associated kernel modules can be used for various applications: enabling address and port translation, setting priorities, and more. Let’s look at examples of using iptables for fundamental tasks. First, here’s the general, basic syntax for invoking iptables to set rules:

iptables -A queue -s source -j action

To remove all rules from a specific queue, use the -F flag:

iptables -F queue

The simplest task of a firewall is blocking all traffic to our server from a specific IP. To do this, you need to execute the following command:

iptables -A INPUT -s 1.2.3.4 -j DROP

By setting this filter, all IP packets from the address 1.2.3.4 will be discarded upon entry. If the sender needs to indicate that the host is unavailable, you should use a slightly modified rule:

iptables -A INPUT -s 1.2.3.4 -j REJECT

When using REJECT, the system will generate a special response to each incoming packet, informing the sender of the impossibility of delivery. Use REJECT only when necessary - forming these responses uses server resources, so in most cases, using DROP is sufficient.

You can also filter rules by protocols. For example, you can block only UDP from a certain sender:

iptables -A INPUT -p UDP -s 1.2.3.4 -j DROP

In the next example, we will see how to specify port numbers. We will use the --dport (destination port) flag to prevent host 1.2.3.4 from connecting to our server via SSH on the standard port 22:

iptables -A INPUT -p TCP -s 1.2.3.4 --dport 22 -j DROP

There is an option to log the operation of certain rules. Let’s make it so that the log file (usually in /var/log/messages) has records of the filter’s operation. The first rule will log the incoming packets, and the second will drop them:

iptables -A INPUT -p TCP -s 1.2.3.4 --dport 22 -j LOG --log-prefix "SSH Filter:"
iptables -A INPUT -p TCP -s 1.2.3.4 --dport 22 -j DROP

In iptables, you can specify not just a single address, but an entire network. For example, let’s block connections to our web server (port 80) from the address range 10.1.2.* (in CIDR notation 10.1.2.0/24):

iptables -A INPUT -p TCP -s 10.1.2.0/24 --dport 80 -j DROP

The next example will show how to use iptables to check the contents of IP packets. For instance, you can log or discard packets that contain a specific sequence of characters, in this case, hack.php:

iptables -I INPUT -p TCP -m string --string "hack.php" -j LOG --log-prefix "HACK:"

Let’s consider another practical task - limiting the number of connections to our server over time. This can be useful for combating flooding or simple attacks. The following rule will set a limit of 5 simultaneous connections from one IP to our server via SSH:

iptables -A INPUT -p TCP --syn --dport 22 -m connlimit --connlimit-above 5 -j REJECT

Another construct can be used - the next rule will limit new connections to the web server to 25 per minute, and this limit will engage if there were 100 connections in the previous minute:

iptables -A INPUT -p TCP --dport 80 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT

You can limit connections not just by individual addresses or across the system, but also by using masks. In the example below, we will block for an entire /24 network if more than 20 connections come in from it:

iptables -A INPUT -p TCP --dport 80 -m iplimit --iplimit-above 20 --iplimit-mask 24 -j REJECT

Finally, let’s look at how to save the programmed iptables rules so they are restored upon rebooting the operating system. In CentOS, you just need to execute the command:

service iptables save

For Debian, it is recommended to install the helper package iptables-persistent, which should be installed using the standard package manager:

aptitude install iptables-persistent

After installing iptables-persistent, the system will automatically save the current rules when the operating system stops and restore them upon startup.

Lastly, we would like to give an important recommendation: when setting rules, errors may occur that can lock you out. We recommend gaining access to your server’s console before configuring the firewall (for dedicated servers—request an IP KVM, for VDS—use the built-in VNC client). If needed, you can always restore access from the console by “resetting” erroneous rules.