Set up simple host-based security on Linux. hosts.allow and hosts.deny

Are you new to Linux? Maybe you’re a Windows netadmin and you’re curious about the best way to implement basic security on Linux systems.

Enterprise-wide security strategies require far more explanation than I can possibly include in a 101 series (or even a single article), so I'll just run through a simple method of locking down a machine on a LAN that is not behind a firewall and that needs quick and cheap protection from unwanted guests. Oh yes; I’ll also keep in mind you’ll be doing so with limited Linux knowledge.

In the beginning
Linux security can be as simple or as advanced as you want. A Linux system can be locked down (relatively speaking) with a simple one-two punch of /etc/hosts.deny and /etc/hosts.allow, or you can go as far as running a strong ipchain-style firewall ruleset and PortSentry.

The threat of a system break-in is distressing enough that most would want the whole nine yards' worth of security, and you’d be best-served to think along those lines. However, we're going to first learn how to very simply not allow anyone into a machine.

hosts.*
The /etc/hosts.* files are crucial to a simple network. (In fact, the /etc/hosts.deny file is crucial to the very powerful portsentry application.) The /etc/hosts.allow and /etc/hosts.deny files inform the system who can and who cannot enter the machine.

/etc/hosts.allow
The first stop for all incoming network traffic is /etc/hosts.allow. This particular file is set up in the following fashion:
daemon_list : client_list

Let's say you want to allow certain users to have access to telnet (which isn’t advisable, as the method requires the transmission of insecure, plain text passwords). In order to allow telnet access, you must have an entry in your hosts.allow file that looks like this:
telnetd:ALLOWED.HOST

The first section, telnetd, is the daemon for the telnet application. The second section, ALLOWED.HOST, is either the IP address or the alias of the host.

Please note that if an alias is used, that alias must be present in the /etc/hosts file. The /etc/hosts file contains both the IP address and alias of a given host. For example:
172.22.1.2 mybuddy

would allow you to use mybuddy in place of the IP address. Aliases come in handy when there are specific IP addresses you visit frequently.

From the above, it would seem that the daemon listing could get quite extensive when a certain host is completely trusted. Imagine having entries for telnet, ping, traceroute, ftp, ssh, rlogin, etc.! In order to overcome this issue, the /etc/hosts.* system allows the use of all-inclusive keywords. So:
ALL:ALL

would allow any host to use any daemon. Bad idea. Very bad idea! Leaving the system wide open (which is how it is set up by default) basically gives backstage passes to anyone wanting to conduct whatever nasty business they want.

Don't be so trusting. Instead, use a trusted hosts only approach to the hosts files.

A very simple way to use this approach is to have your /etc/hosts.allow file set up to read as follows:
ALL:TRUSTED.HOSTS

Configuring your /etc/hosts.allow file in such a manner allows all trusted IP addresses to use any service they need.

/etc/hosts.deny
Should an IP address make it through the first check, /etc/hosts.allow, it then must pass the second test, which is the /etc/hosts.deny file.

The hosts.deny file is set up in the same fashion as the hosts.allow file, except that it sets up rules for those hosts not allowed a connection. In direct opposition of hosts.allow, an entry of:
ALL:ALL

will allow no host to use any service. This is the best method to use if you have no intention of allowing anyone into your system. With the above hosts.deny entry, no one will be able to invade the privacy of your computer, except portscans, rootkits, and packet sniffers.

Use the log
The final issue to deal with is that of log files. No administrator working with Linux systems is worth a single cent unless he or she takes advantage of Linux’s amazing log system. Within the /var/log directory, you will see the following critical files (to network and security administration):

* messages
* messages.1
* messages.2
* messages.3
* messages.4
* secure
* secure.1
* secure.2
* secure.3
* secure.4


Each of these files is in chronological order, with .4 being the oldest and the files without the .x (where x = 1-4) being the newest. The first set of files, messages, contains all information from bootup messages to networking messages.

It is possible to view only the messages files and still receive security information because all of the secure files' data will be encapsulated within the messages files. However, it is always best to view them separately. Why? Take a look at this outtake from /var/log/messages:
Mar 5 12:41:33 willow portsentry[15782]: adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 901
Mar 5 12:41:33 willow portsentry[15782]: adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 113
Mar 5 12:41:33 willow portsentry[15782]: adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 139
Mar 5 12:41:33 willow portsentry[15782]: adminalert: PortSentry is now active and listening.
Mar 5 12:41:36 willow uptimed: created bootid: 951847364
Mar 5 12:42:10 willow kernel: Packet log: input DENY eth0 PROTO=17 ***.***.***.***:** 255.255.255.255:68 L=333 S=0x00 I=13813 F=0x0000 T=248 (#28)
Mar 5 12:42:10 willow kernel: Packet log: input DENY eth0 PROTO=17 ***.***.***.***:** 255.255.255.255:68 L=333 S=0x00 I=13814 F=0x0000 T=248 (#28)

Please note that the IP addresses have been converted to ***s to protect the guilty.

And now an excerpt from /var/log/secure:
Mar 4 20:05:09 willow in.ftpd[14056]: connect from ***.***.***.***
Mar 4 20:07:46 willow in.ftpd[14069]: connect from ***.***.***.***
Mar 4 21:10:44 willow in.ftpd[14169]: refused connect from ***.***.***.***
Mar 5 00:28:12 willow in.ftpd[14408]: refused connect from ***.***.***.***

You will notice there are two types of entries: connect and refuse connect. The connect entries are trusted entries from the /etc/hosts.allow file. The refuse connect are all other connection attempts that were denied by the system.

With the above file it is possible to report attempted attacks to abuse@your.isp (where your.isp is your ISP’s domain name).