Skip to main content

Give your Linux system's firewall a security boost

Firewalls are great but they're ineffective if something goes wrong with them. The /etc/hosts.allow and /etc/hosts.deny files are the second line of defense against intruders.

Firewalls such as firewalld and iptables are a great first line of defense against intrusions but they're not flawless. They can be hacked and also suffer from occasional vulnerabilities. But you must have a host-based firewall running. It's just one of the things that you install and configure on every system. And you should configure your firewall before doing any work on your system. In other words, lock down your system as soon as it's online.

Once your new system is up and running and you've secured it with a firewall, then it's time to create that second line of defense with corresponding entries in the  /etc/hosts.allow (hosts.allow) and /etc/hosts.deny (hosts.deny) files. If the firewall is stopped, for any reason, then the hosts.allow and hosts.deny entries would continue to protect your system from intrusion. It's this added layer that enhances your system's security by providing a failsafe for your firewall.

Create the ALLOW entries

I hope that you've read my, "Sysadmin tools: How to use iptables" article. If not, please take a few minutes to read it before plunging into your hosts.allow and hosts.deny files because I'm going to use the iptables article as a reference for making the corresponding entries.

Note: It bears stating here that entries made in hosts.allow can lock you out of your system, which isn't what you want. If it happens, you'll have to gain access to the system console via KVM, virtual KVM, iLO, or virtual machine console.

The SSH rule from the article mentioned above reads, iptables -I INPUT -s -p tcp --dport 22 -j ACCEPT. This rule allows any system on the network to connect to the local system via SSH. The corresponding entry in hosts.allow is:

SSHD: 192.168.1.*

This entry allows all systems from the network to connect to the system via SSH.

Note: You need to add a blank line at the end of your hosts.allow file for it to operate as designed. I struggled with this for a couple of days and it was very frustrating.

The hosts.allow file is read before the hosts.deny file is, so place all allowed entries in this file before placing anything into the hosts.deny file. You can place DENY entries in the hosts.allow file but I prefer to keep the two separate from each other. I think it would confuse me to have both types of entries in the hosts.allow file. 

Once you make your changes to the hosts.allow and host.deny files, they're live. There's no daemon to restart to make them active, which is another reason to warn you to make your entries with great care unless you live near your data center, that is.

Create the DENY entries

After you create all of your iptables corresponding hosts.allow entries, it's time to create the hosts.deny entries. Like iptables, hosts.allow and hosts.deny files are read from top to bottom, so add the so-called DENY ALL entry at the bottom of the hosts.deny file.


This simple entry means to deny all protocols from all hosts. You can be more specific if you want to only deny one particular protocol or network.

SSHD: ALL     #Deny SSH access from all networks but allowing other protocols.


ALL: 192.168.1.*     #Deny all protocols from the network.


SSHD: 192.168.1.*     #Deny SSH access from the network.

Wrapping up

As you can see from these examples and from those given in the iptables article, the two share similarities in structure and in behavior. They are both read from top to bottom and ALLOW entries are read before DENY entries. The one thing to remember when creating hosts.allow/deny entries and iptables entries is that they correspond to one another. If they're in conflict, it will significantly increase the complexity of your troubleshooting efforts. For test purposes, turn off your firewall and observe connectivity behavior of your hosts.allow and hosts.deny files. 

[ Want more on networking and network security? Check out the Linux networking cheat sheet. ]

Topics:   Networking   Linux  
Author’s photo

Ken Hess

Ken has used Red Hat Linux since 1996 and has written ebooks, whitepapers, actual books, thousands of exam review questions, and hundreds of articles on open source and other topics. Ken also has 20+ years of experience as an enterprise sysadmin with Unix, Linux, Windows, and Virtualization. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.