Everyone in the IT industry is concerned with security, especially Linux administrators. Many Linux distributions come with several services that you may not use or ever need, but they're running on your server anyways. This can cause many security threats.
With the slightest knowledge of Linux firewalls, you can secure your Linux server very quickly and efficiently. In this article, I will either introduce you into iptables for your first time, or help you become more efficient with iptables if you've worked with them in the past.
As network packets flow in and out of the network interface card, they are intercepted, analyzed and manipulated, as ruled through the Linux firewall. As the packet flows through the firewall rules and it reaches a rule that is matches, it stops there and doesn't continue through the rest of the rule set.
For instance, there are two rules; one rule is to drop all packets coming in through port 25, then there is a rule directly after that says to accept 192.168.1.25 on port 25. That packet will be dropped once it hits the first rule. It won't even know there is a second rule. The first example is continued further down in this article. There have been three main Linux firewalls that are widely used as follows:
- Ipfwadm was merged into the Linux 2.0 kernel. It can filter TCP, UDP and ICMP packets only. It also does not support QoS. You can "insert" and "remove" rules. This doesn't make it the most user-friendly Linux firewall on the planet.
- Ipchains was merged into the Linux 2.2 kernel. It supports QoS, is very flexible with the configuration, since it has "replace," "insert" and "remove." This can make ipchains more user-friendly. Ipchains also has the ability to filter any IP protocol explicitly, not just TCP, UDP and ICMP.
- Iptables was a project that was begun in 1998 by Rusty Russell. This was merged into the Linux 2.3 kernel in 2000, and is still widely used today. It supports stateful IPv4, and IPv6 protocol tracking and IPv4 application tracking. Iptables has built-in PORTFW functionality and is extremely user-friendly.
Let's take a look at what is under the iptables list.
/sbin/iptables –L -n
That will show your complete iptables rule list, with as much information as possible about each rule. Let's break down what you're looking at. You should see something similar to the table below, although it should be noted that the table in the example is an empty table, whereas you will have rules in your table.
Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
Flushing your list of rules can be good if you would like to rewrite your rules completely as I've done plenty of times in the past. You can "flush" every rule under iptables by doing:
However, you may want to only flush all the rules under the INPUT, FORWARD or OUTPUT chain. You can specify which chain to flush by each of the following:
/sbin/iptables -F INPUT /sbin/iptables -F FORWARD /sbin/iptables -F OUTPUT
Additionally, you can save your rules so that when you restart your Linux server, the current rules will become active once again. You can save by doing:
All Red Hat Enterprise Linux (RHEL) versions, unless specified, come with iptables installed and started automatically the first time you turn on your server. There just may not be any rules to abide by. If there are no rules to follow, then iptables will not do anything with the network packets. It will act as if there is no firewall at all.
If you want iptables to STOP running, you can initiate the following command:
You should get the following:
|Flushing firewall rules:|
[ OK ]
|Setting chains to policy ACCEPT: filter|
[ OK ]
|Unloading iptables modules:|
[ OK ]
Of course, you can START iptables by doing:
You should see:
Applying iptables firewall rules: [ OK ]
If you don't want iptables to be started when you start your RHEL server, do the following:
- Go to "System Services"
- Scroll down to "iptables" (everything is sorted alphabetically)
- Uncheck by hitting the space bar.
- Enter on "Okay" and then "Quit"
See the example below.
Scenario: You want to simply deny every IP address a connection to your SMTP server (tcp port 25), except for the IP: 192.168.1.25. Two commands for this, are as follows:
/sbin/iptables –I INPUT –p tcp –dport 25 –j DROP /sbin/iptables –I INPUT –s 192.168.1.25 –p tcp –dport 25 –j ACCEPT
The reason I put the "DROP" command in before the "ACCEPT" is because a rule has already been entered into the database and when a rule is added next, it is added directly above the last one entered. Putting the DROP command before the ACCEPT lets the ACCEPT rule be read before the DROP command. Let's break the rest of these commands down:
The first command:
- -I is to "input" the rule into the chain. (Note: you can do "–D" instead to delete the rule from the chain, as well.)
- INPUT is the chain name. Input is the chain that is followed by "incoming" packets.
- -p is the protocol argument. You specify the protocol type with this command. Notice the "tcp" after the "-p"
- --dport is what specifies which port to filter. In this case, it is 25 because that is what port SMTP runs on (by default).
- -j is the argument that specifies what to do with the packet. In this case, it's going to be "DROPPED."
The second command:
- The only difference between this command and the first one, is there is a (-s) "src" IP address specified and the –j argument is "ACCEPT".
- Since an (-s) "src" address was not specified in the first argument, it assumed that every address is to be dropped.
Don't forget to save your current work.
Now, let's look at our table:
/sbin/iptables –L –n
|Chain INPUT (policy ACCEPT)|
|target||prot opt source||destination|
|ACCEPT||tcp -- 192.168.1.25||0.0.0.0/0 tcp dpt:25|
|DROP||tcp -- 0.0.0.0/0||0.0.0.0/0 tcp dpt:25|
Notice how the "ACCEPT" rule is above the "DROP" rule.
Practicing with iptables will improve your proficiency and speed with Linux firewalls. I've used iptables in Linux environments with nearly 50 servers. Many rules running on a single Linux server will not slow down the system at all.
This was first published in July 2007