Secure your Server with hosts.allow and hosts.deny

Managing remote Linux Servers often requires the use of remote shell because typically GUI environment is not available. Therefore things like VNC or other remote desktop connections are not an option. Instead Administrators have two command line options; Telnet or SSH (Secure Shell). Telnet gets a bad reputation because it is not secure; in other words it transmits login credentials in clear text. This is a security concern because anyone sniffing traffic off the wire can capture your login username and password. On the other hand SSH is secure as it encrypts all traffic between client and server keeping your username and password confidential.

While SSH is a great remote administrative option your system is susceptible to brute force attacks if you leave this service open to all Internet hosts. In other words potential attackers may utilize automated tools and guess your password by trying thousands of combinations per minute. But that’s not a problem because you have a very complex password correct?

In case you don’t (I encourage you to change it) however SSH offers several authentication options one of which is Public Key Authentication removing the requirement for username and password. But that’s a discussion for another day; today let’s review a simpler method and filter who may and may not connect. Linux has two interesting text files found in /etc directory called /hosts.deny and /hosts.allow.

So you’re probably wondering how simple text files can secure your server. The magic is in the Linux TCP daemon which filters all incoming packets through hosts.allow then hosts.deny before further packet processing. This offers easy filtering and I know what you’re thinking; What about iptables firewall, wouldn’t it accomplish the same thing? Well yes it would, however to the uninitiated Linux Administrator or Windows Admin with little Linux experience iptables is rather confusing. Navigating two text files is much easier and in my opinion less prone to user entry errors. While iptables is great it takes time to wrap your head around its rule syntax.

Okay, so how do these two text files work?

In simplest form hosts.deny and hosts.allow syntax is the following;

Daemon Name: hostname or ip address

Here is an example:

sshd: 192.168.10.1,10.116.20.54

If we placed above line in hosts.deny both 192.168.10.1 and 10.116.20.54 IP addresses would be denied access. If we placed it in hosts.allow both IP addresses would be allowed. You may be thinking ok, that’s it? Well no, there is more; TCP daemon provides additional options like pattern matching, operators, wildcards and even shell commands which all extend filtering capabilities.

#hosts.deny

sshd: .domain.com

Notice the leading ‘.’ in above example. This wildcard will match anything .domain.com and deny access. www.domain.com, ftp.domain.com and mail.domain.com would all be denied access.

Here is the same example but using an IP address range.

#hosts.deny

sshd: 192.168.5.

Above will deny access to IP addresses between 192.168.5.1 and 192.168.5.255

I’ve already mentioned Telnet isn’t the best option because it uses clear text. Why don’t we block all Telnet connections?

#hosts.deny

telnet: ALL

 For more complex filtering iptables is the way to go but for simple filtering hosts.deny and hosts.allow simply works.