Hack64.Allow or Deny Access by IP Address

Hack 64. Allow or Deny Access by IP Address

Using the power of your text editor, you can quickly lock out malicious systems.

When running secure services, you'll often find that you want to allow and/or deny access to and from certain machines. There are many different ways you can go about this. For instance, you could implement access control lists (ACLs) at the switch or router level. Alternatively, you could configure iptables or ipchains to implement your access restrictions. However, a simpler method of implementing access control is via the proper configuration of the /etc/hosts.allow and /etc/hosts.deny files. These are standard text files found in the /etc directory on almost every Linux system. Like many configuration files found within Linux, they can appear daunting at first glance, but with a little help, setting them up is actually quite easy.

7.3.1. Protecting Your Machine with hosts.allow and hosts.deny

Before we jump into writing complex network access rules, we need to spend a few moments reviewing the way the Linux access control software works. Inbound packets to tpcd, the Linux TCP daemon, are filtered through the rules in hosts.allow first, and then, if there are no matches, they are checked against the rules in hosts.deny. It's important to note this order, because if you have contradictory rules in each file you should be aware that the rule in hosts.allow will always be implemented, as the first match is found there. This ceases the filtering, and the incoming packets are never checked against hosts.deny. If a matching rule is not found in either file, access is granted.

In their most simple form, the lines in each of these files should conform to the following format:

 daemon-name: hostname or ip-address 

Here's a more recognizable example:

 sshd: 192.168.1.55,192.168.155.56 

If we inserted this line into hosts.allow, all SSH traffic between our local host and 192.168.1.55 and 192.168.1.56 would be allowed. Conversely, if we placed it in hosts.deny, no SSH traffic would be permitted from those two machines to the local host. This would seem to limit the usability of these files for access controlbut wait, there's more!

The Linux TCP daemon provides an excellent language and syntax for configuring access control restrictions in the hosts.allow and hosts.deny files. This syntax includes pattern matching, operators, wildcards, and even shell commands to extend the capabilities. This might sound confusing at first, but we'll run through some examples that should clear things up. Continuing with our previous SSH example, let's expand the capabilities of the rule a bit:

 #hosts.allow sshd: .foo.bar 

In the example above, take note of the leading dot. This tells Linux to match anything with .foo.bar in its hostname. In this example, both www.foo.bar and mail.foo.bar would be granted access. Alternatively, you can place a trailing dot to filter anything that matches the prefix:

 #hosts.deny sshd: 192.168.2. 

This would effectively block SSH connections from every address between 192. 168.2.1 and 192.168.2.255. Another way to block a subnet is to provide the full network address and subnet mask in the xxx.xxx.xxx.xxx/mmm.mmm.mmm.mmm format, where the xs represent the network address and the ms represent the subnet mask.

A simple example of this is the following:

 sshd: 192.168.6.0/255.255.255.0 

This entry is equivalent to the previous example but uses the network/subnet mask syntax.

Several other wildcards can be used to specify client addresses, but we'll focus on the two that are most useful: ALL and LOCAL. ALL is the universal wildcard. Everything will match this, and access will be granted or denied based on which file you've used it in. Being careless with this wildcard can leave you open to attacks that you would normally think you're safe from, so make sure that you mean to open up a service to the world when you use it in hosts.allow. LOCAL is used to specify any hostname that doesn't have a dot (.) within it. This can be used to match against any entries contained in the local /etc/hosts file.

7.3.2. Configuring hosts.allow and hosts.deny for Use

Now that we've mastered all that, let's move on to a more complex setup. We'll set up a hosts.allow configuration that allows SSH connections from anywhere and restricts HTTP traffic to our local network and entries specifically configured in our hosts file. As intelligent sysadmins, we know that telnet shares many of the same security features as string cheese, so we'll use hosts.deny to deny telnet connections from everywhere as well.

First, edit hosts.allow to read:

 sshd: ALL httpd: LOCAL, 192.168.1.0/255.255.255.0 

Next, edit hosts.deny to read:

 telnet: ALL 

As you can see, securing your machine locally isn't that hard. If you need to filter on a much more complicated scale, employing network-level ACLs or using iptables to create specific packet-filtering rules might be appropriate. However, for simple access control, the simplicity of hosts.allow and hosts.deny can't be beat.

One thing to keep in mind is that it is typically bad practice to perform this kind of filtering upon hostnames. If you rely on hostnames, you're also relying on name resolution. Should your network lose the ability to resolve hostnames, you could potentially leave yourself wide open to attack, or cause all your protected services to come to a screeching halt as all network traffic to them is denied. Usually, it's better to play it safe and stick to IP addresses.

7.3.3. Hacking the Hack

Wouldn't it be cool if we could set up a rule in our access control files that alerted us whenever an attempt was made from an unauthorized IP address? The hosts.allow and hosts.deny files provide a way to do just that! To make this work, we'll have to use the shell command option from the previously mentioned syntax. Here's an example hosts.deny config to get you started:

 sshd: 192.168.2. spawn (/bin/echo illegal connection attempt from %h %a to  %d %p at 'date' >>/var/log/unauthorized.log | tee /var/log/unauthorized.log|  mail root 

Using this command in our hosts.deny file will append the hostname (%h), address (%a), daemon process (%d), and PID (%p), as well as the date and time, to the file /var/log/unauthorized.log. Traditionally, the finger or safe_ finger commands are used; however, you're certainly not limited to these.

7.3.4. See Also

• man tcpd

• http://www.die.net/doc/linux/man/man5/hosts.allow.5.html

Brian Warshawsky