Using TCP wrappers to enhance network service security under Linux

In this article, we will explain what TCP wrappers are and how to configure them on a Linux server to limit the permissions of network services. Before we begin, we must clarify that TCP wrappers do not eliminate the need for a properly configured firewall.

At this point, you can think of this tool as a host-based access control list, and not as the ultimate security measure for your system. By using a firewall and TCP wrapper, rather than favoring just one over the other, you will ensure that your service is not a single point of failure.

Understand hosts.allow and hosts.deny files correctly

When a network request reaches your host, the TCP wrapper will use hosts.allow and hosts.deny (in this order) to determine whether the client should be Allows use of a provided service. .

By default, the contents of these files are empty, commented out, or do not exist at all. So, any request will be allowed through the TCP filter and your system is placed relying on the firewall to provide all protection. Because that's not what we want. For the reasons we introduced at the beginning, make sure that the following two files exist:

# ls -l /etc/hosts.allow /etc/hosts.deny

The writing syntax rules of the two files are the same:

<services> : <clients> [: <option1> : <option2> : ...]

In the file,

1. services refers to the current rule corresponding The services are a comma-separated list.

2. clients refers to the host name or IP address affected by the rule, separated by commas. The following wildcards are also accepted:

1).ALL means everything and applies to clients and services.

2).LOCAL means matching machines that do not have a fully qualified host name (FQDN) in the official domain name, such as localhost.

3).KNOWN means that the host name, host address, or user is known (that is, it can be resolved through DNS or other services).

4).UNKNOWN is the opposite of KNOWN.

5).PARANOID If reverse DNS lookups return different addresses, the connection will be disconnected (first resolve the host name based on IP, and then obtain the IP address based on the host name).

3. Finally, a colon-separated action list represents what actions will be taken when a rule is triggered.

You should remember that the rules in the /etc/hosts.allow file that allow a service to access take precedence over the rules in /etc/hosts.deny. Also, if two rules apply to the same service, only the first rule will be taken into account.

Unfortunately, not all network services support TCP filters. To see if a given service supports them, you can execute the following command:

# ldd /path/to/binary | grep libwrap

If the above command is executed and the following results are obtained, then it is OK TCP filters are supported, sshd and vsftpd as examples, the output is shown below.

sshd,vsftpd : ALL 
ALL : ALL

sshd,vsftpd : 192.168.0.102,LOCAL

In the last two examples, notice the dots at the beginning and end of each line in the client list . This is used to mean "all hosts or clients whose names or IPs contain that string"