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.
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit