14.2 Host Access Control

14.2.1 iptables

iptables is the packet filtering configuration program for Linux 2.4 and above. The 2.4 kernel (2.4.5, to be exact) was first introduced into Slackware (as an option) in version 8.0 and was made the default in Slackware 8.1. This section only covers the basics of its usage and you should check http://www.netfilter.org/ for more details. These commands can be entered into /etc/rc.d/rc.firewall, which has to be set as executable for these rules to take effect at startup. Note that incorrect iptables commands can essentially lock you out of your own machine. Unless you are 100% confident in your skills, always ensure you have local access to the machine.

The first thing most people should do is set the default policy for each inbound chain to DROP:

# iptables -P INPUT DROP
# iptables -P FORWARD DROP

When everything is denied, you can start allowing things. The first thing to allow is any traffic for sessions which are already established:

# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

So as not to break any applications that communicate using the loopback address, it is usually wise to add a rule like this:

# iptables -A INPUT -s -d -i lo -j ACCEPT

This rules allows any traffic to and from ( - on the loopback (lo) interface. When creating rules, it is a good idea to be as specific as possible, to make sure that your rules do not inadvertently allow anything evil. That said, rules that allow too little mean more rules and more typing.

The next thing to do would be to allow access to specific services running on your machine. If, for example, you wanted to run a web server on your machine, you would use a rule similar to this:

# iptables -A INPUT -p tcp --dport 80 -i ppp0 -j ACCEPT

This will allow access from any machine to port 80 on your machine via the ppp0 interface. You may want to restrict access to this service so that only certain machines can access it. This rule allows access to your web service from

# iptables -A INPUT -p tcp -s --dport 80 -i ppp0 -j ACCEPT

Allowing ICMP traffic can be useful for diagnostic purposes. To do this, you would use a rule like this:

# iptables -A INPUT -p icmp -j ACCEPT

Most people will also want to set up Network Address Translation (NAT) on their gateway machine, so that other machines on their network can access the Internet through it. You would use the following rule to do this:

# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

You will also need to enable IP forwarding. You can do this temporarily, using the following command:

# echo 1 > /proc/sys/net/ipv4/ip_forward

To enable IP forwarding on a more permanent basis (i.e. so that the change is kept after a reboot), you will need to open the file /etc/rc.d/rc.inet2 in your favorite editor and change the following line:


...to this:


For more information on NAT, see the NAT HOWTO.

14.2.2 tcpwrappers

tcpwrappers controls access to daemons at the application level, rather than at the IP level. This can provide an extra layer of security at times when IP-level access controls (e.g. Netfilter) are not functioning correctly. For example, if you recompile the kernel but forget to include iptables support, your IP level protection will fail but tcpwrappers will still help protect your system.

Access to services protected by tcpwrappers can be controlled using /etc/hosts.allow and /etc/hosts.deny.

The majority of people would have a single line in their /etc/hosts.deny file to deny access to all daemons by default. This line would be:


When this is done, you can concentrate on allowing access to services for specified hosts, domains, or IP ranges. This can be done in the /etc/hosts.allow file, which follows the same format.

A lot of people would start by accepting all connections from localhost. This can be achieved using:


To allow access to SSHd from, you could use either of the following rules:

sshd :
sshd : 192.168.0.

It is also possible to restrict access to hosts in certain domains. This can be done using the following rule (note that this relies on the reverse DNS entry for the connecting host being trustworthy, so I would recommand against its use on Internet-connected hosts):

sshd : .slackware.com