IPTables: two ways to deny packets

iptables

What are IPTABLES?

IPTables is a net-filter firewall, which is well known in the Linux world. It is based on Linux kernel firewall which stores the chains and rules, based on which the system decides whether a packet should be allowed or denied access to the server/system.

According to Wikipedia:

“Iptables is a user-space application program that allows a system administrator to configure the tables provided by the Linux kernel firewall (implemented as different Net-filter modules) and the chains and rules it stores.”

NOTE: In order to make any changes to the Iptables, a user must have elevated privileges (root user access), otherwise a normal user will be denied the permission to make changes to Iptables.

Scenario:

1. System administrator wants to allow access to SSH port on the server only from one IP address.
2. All other access to the server be denied.

It seems perfectly fine and easy scenario and a novice system administrator can also make that addition to Iptables rules. But there are actually two ways we can implement this. Both ways are quite different from each other and affects the server in different ways.

In order to achieve the above scenario, let’s start with first part. We need to make changes to “INPUT” chain (in FILTER table) as follows:

# iptables -A INPUT -p tcp -s SRC_IP_ADDR --dport 22 -j ACCEPT

You can view the Iptables rules any time using:

# iptables -L

Output:

iptables output

In the above screen-shot, the default policy for INPUT chain is set to ACCEPT. That means if otherwise not mentioned, access will be allowed to the server. With this default policy, no matter what rules you add for accepting the connection, all the connections will be accepted nonetheless. In order to block other connections, a system administrator needs to do one of the following which has different outcomes:

1. Change the default policy for INPUT change to DROP:

This can be achieved by updating the default policy as:

# iptables -P INPUT DROP

When the default policy is changed for INPUT chain, adding the exception rule to accept SSH from a defined IP address will work, but in case the server is rebooted, all SSH access to the server will be denied. This is because server reboot will erase allĀ  Iptables rules that you have added previously. If you have access to some console such as SolusVM etc., then you can gain access to your server by using serial console, but in case your server does not have such console, then you will be logged out of your server unless you find a way to get back in.

2. Keeping the default policy for INPUT chain to ACCEPT, add a rule instead which will drop all the access to your server as follows:

# iptables -A INPUT -j DROP

The plus side of adding a rule instead of changing default policy is that if the server is rebooted for any reason, then the system administrator can log into the server via SSH because even if the Iptables rules will be reset, connection will be allowed due to the default policy.

Along with the plus point discussed above, there is a need for extra step each time system administrator wants to add a new rule. The last rule in Iptables should be the “DROP” rule, hence the DROP rule will have to be deleted and then re-added as:

# iptables -D INPUT -j DROP
# iptables -A INPUT -p tcp --dport 80 -j ACCEPT (this is the new rule)
# iptables -A INPUT -j DROP

Or, you can insert rules that you need at the end of the chain (but prior to the drop) by specifying the line number. To insert a rule at line number 3:

# iptables -I INPUT 3 -p tcp --dport 80 -j ACCEPT (this is the new rule)

In order to reveal the line number, type:

# iptables -L --line-numbers

Iptables is a complex piece of software and new system administrators need to be extra careful otherwise they can lose access to the server and/or do some major damage how the server works.

Have better ideas to implement firewall under Linux? Or better ways to use Iptables? Please share it with us in the comments section below.

 

Leave a Reply

Your email address will not be published. Required fields are marked *