IPTables is a very powerful security tool used to block unwanted traffic, allow desired traffic, redirect packets to alternate TCP/UDP ports, redirect packets to alternate IP addresses, protect against Denial of Service attacks (DoS) and so much more. However, this article will explain just the basics for the application to assist the common user in basic security for a server installation.
There are some minor differences in the way the Linux maintainers implement the IPTables firewall in the versions of Linux they maintain, but operations are the same. Here are the differences you need to be concerned with.
Rules File Location
There are a few other minor differences in the init script and service configuration but the instructions provided here will function for IPTables installed on any of the mentioed operating systems.
It is possible to have multiple rule sets in IPTables, but the most common configuration is to have a single rule set. In CentOS/Fedora the input rule set is named "RH-Firewall-1-INPUT" or "INPUT" in Debian/Ubuntu the rule set is normally named "INPUT". The rule set name change be changed in the rules file described above if you need the rule set name to be some other name.
A default rules set will be a short list of rules, these rules are just enough not to block management connections on the first boot. An example of a default rule set may be:
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
You can see the hash mark (#) before the first two lines. This means these lines are ignored when loading the rule set and are generally just for human reference.
The next line defines the rules that follow as "filter" rules. This is the type of rule we will address in this article.
The next lines define rule sets. In the basic rules file there are 3 rules sets, INPUT, OUTPUT and FORWARD. The OUTPUT rule sets will filter traffic leaving the server for remote locations. The default configuration allows all traffic and filters no traffic leaving the server.
The FORWARD rule set would be used for various configuration types, but the most common would be if the server running IPTables is used as a firewall for an internal network and it is placed between the internal network and the public network.
The INPUT rule set is the rule set we will address here and it is the rule set that defines what traffic is explicitly allowed into or through the sever and what is explicitly blocked. This rule always ends in a "Reject" statement to reject anything that a rule does not specifically address.
The following lines the the example above are the rules that allow or reject specific types of traffic. These wil be the main topic in the next section of this article.
The last line is a signal to the daemon that there is noting to follow and to commit the previous rules to the active packet filter.
The rules in IPTables can be very complex or very simple. Some of the parameters that the server administrator can use in the rules as a basis for a filter are:
There are 2 ways to enter rules into the IPTables rule set. You can edit the rules set file directly by adding, editing and removing rules, then reload the rule set to make the new set active. Or you can enter the rules directly into IPTables making them immediatly active. Each method has advantages and disadvantages. An advantage of editing the rule set file then reloading it, is that you have time to see how rules will affect each other and you can sort the rules in a specific order to provide tiered security. When entering the rules directly the rules are placed at the end of the rule set and all rules that are in place before the new rule take priority. An advantage of entering the rules directly into the live rules set is that if you lock yourself out with a rule, a rule set reload from the console or a server restart will remove the rules that blocked you and reload the original rule set.
To enter new rules or edit existing rules and not modify the live rule set use your favorite text editor and open the rule set file. An example of this using the text editor "nano" would be "nano /etc/systeconfig/iptables". Once the file is open move your cursor to the INPUT ruleset area and position the cursor in front of the rule you want to follow the rule you will enter. Press the "Enter" key to insert a new line, then the "up arrow" to begin typing on that line.
Once the changes are entered and the rule set file is saved and closed you can make the changes active with "iptables-restore < /PathToRuleSetFile" an example of the full command after changing the file mentioned in the edit command would be "iptables-restore < /etc/sysconfig/iptables".
To enter a rule into the live rule set, making it immediately active you enter the rule using then iptables command directly into the ssh interface. The command would appear similar to this "iptables -I RULESETNAME LINE# rules to match". If the insert is successful and you want to save the live rule set to the rule set file to be loaded each time the daemon starts you would use the "iptables-save" command like this " iptables-save > /PathToRuleSetFile" an example of the full command after changing the file mentioned in the edit command would be "iptables-save > /etc/sysconfig/iptables".
An example of a command to directly enter a rule into the rule set would be:
iptables -I INPUT 1 -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
This would enter a rule into teh active rule set as RULE# 1 to allow connections from all source IP addresses to TCP port 22 (ssh).
Now that you understand the different sections of the rules file and you understand how to load rules we can construct a few rules that might be helpful. The first rule everyone needs is a basic rule to allow connections from any source IP address to any destination IP address on a specific destination port.
This rule is to allow all connections of TCP port 80 (HTTP).
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
The components of this rule are:
What if you wanted to allow connected limited by source IP address, such as connections to the ssh management port. You can restrict connection to a single IP address or even a range or IP addresses. This is handy to block ssh connections to every source IP address except a remote office or a home user whom should have access.
-A INPUT -m state --state NEW -m tcp -p tcp -s 10.10.10.0/255.255.255.0 --dport 22 -j ACCEPT
The added element here is "-s 10.10.10.0/255.255.255.0" indicating the source IP address must be any IP address in 10.10.10.0/24.
You can also allow a range of ports. For example VNC uses a default port of 5900, but if you're running virtual machines the VNC ports increment up from 5900 for as many virtual machine you host. To allow a range of ports a rule like this should be used.
-A INPUT -m state --state NEW -m tcp -p tcp --dport 5900:6000 -j ACCEPT
You can also limit all ports in that range by source IP address by adding the source delimiter into the rule.
-A INPUT -m state --state NEW -m tcp -p tcp -s 10.10.10.0/255.255.255.0 --dport 5900:6000 -j ACCEPT
If you're having trouble with a single user or a range of users trying to access random ports or probing for weaknesses on public ports you may chose explicitly block these IP ranges as well. An example of blocking HTTP access for an IP address range would be:
-A INPUT -m state --state NEW -m tcp -p tcp -s 10.10.10.0/255.255.255.0 --dport 80 -j DROP
You can also allow or deny all connections from specific IP ranges with rules like this:
-A INPUT -p ip -s 10.10.10.0/255.255.255.0 -j ACCEPT
-A INPUT -p ip -s 10.10.10.0/255.255.255.0 -j DROP
Remember that the rules in the file are loaded and applied in the order they are listed. The Reject ALL rule should be the last rule in the rule set. An explicit reject rule should be one of the first rules in the list.
ServerPronto’s Dedicated Servers are the economical choice for providing an exclusive set of resources solely devoted to your IT needs. With our bare metal servers, you will benefit from:.