Subscribe to the feed
Linux 

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 192.168.1.0/24 -p tcp --dport 22 -j ACCEPT. This rule allows any system on the 192.168.1.0/24 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 192.168.1.0 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.

ALL: ALL

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.

or 

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

or

SSHD: 192.168.1.*     #Deny SSH access from the 192.168.1.0 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. ]


About the author

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.

Follow him on Twitter: @kenhess for a continuous feed of Sysadmin topics, film, and random rants.

In the evening after Ken replaces his red hat with his foil hat, he writes and makes films with varying degrees of success and acceptance. He is an award-winning filmmaker who constantly tries to convince everyone of his Renaissance Man status, also with varying degrees of success and acceptance.

Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

Browse by channel

automation icon

Automation

The latest on IT automation for tech, teams, and environments

AI icon

Artificial intelligence

Updates on the platforms that free customers to run AI workloads anywhere

open hybrid cloud icon

Open hybrid cloud

Explore how we build a more flexible future with hybrid cloud

security icon

Security

The latest on how we reduce risks across environments and technologies

edge icon

Edge computing

Updates on the platforms that simplify operations at the edge

Infrastructure icon

Infrastructure

The latest on the world’s leading enterprise Linux platform

application development icon

Applications

Inside our solutions to the toughest application challenges

Original series icon

Original shows

Entertaining stories from the makers and leaders in enterprise tech