Hosts.all Hosts.deny Example

http://os.51cto.com/art/201611/521409.htm

correctly understand Hosts.allow and Hosts.deny files

When a network request arrives at your host, the TCP wrapper uses Hosts.allow and Hosts.deny (in this order) to determine whether the client should be allowed to use one of the provided services.

By default, the contents of these files are empty, either commented out, or does not exist at all. Therefore, any request is allowed through the TCP filter and your system is placed on a firewall to provide all the protection. Because it's not what we want. Because of the reasons we introduced at the outset, make sure that the following two files are present:

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

The two files are written with the same syntax rules:

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

In the file,

1. Services refers to the service that corresponds to the current rule and is a comma-delimited list.

2. Clients refers to the host name or IP address that is affected by the rule, separated by commas. The following wildcard characters are also acceptable:

1). All means everything, applied to clients and services.

2). LOCAL represents a match to a machine that does not have a fully qualified hostname (FQDN) in the official domain name, such as localhost.

3). Known represents the hostname, the host address, or the user is known (that is, it can be resolved through DNS or other services).

4). UNKNOWN and known are the opposite.

5). PARANOID If a reverse DNS lookup returns a different address to each other, the connection is disconnected (the host name is first resolved based on the IP, and then the IP address is obtained based on the host name).

3. Finally, a colon-delimited list of actions indicates what action is taken when a rule is triggered.

You should remember that the rules in the/etc/hosts.allow file that allow access to a service 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, and in order 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 after the following results, then it can support TCP filters, sshd and vsftpd as an example, the output is as follows.

Find services supported by TCP filters

How to use TCP filters to restrict permissions for a service

When you edit/etc/hosts.allow and/etc/hosts.deny, make sure you add a new row after the last non-empty line with the ENTER key.

In order for the SSH and FTP service to allow only localhost and 192.168.0.102 and deny all other users, add the following in/etc/hosts.deny:

Sshd,vsftpd:all All:all

and add the following in the/etc/hosts.allow file:

Sshd,vsftpd:192.168.0.102,local

These changes take effect immediately and do not require a restart.

In the following image you will see that the FTP server will not be available for localhost after deleting the LOCAL in the last line. After we have added wildcards, the service becomes available again.

Confirm FTP Permissions

To allow all services to be available for host names that contain example.com, add the following line in Hosts.allow:

All:. example.com

To prevent 10.0.1.0/24 machines from accessing the VSFTPD service, add the following line to the Hosts.deny file:

vsftpd:10.0.1.

In the last two examples, notice the point at the beginning and end of each line of the client list. This is used to indicate "all names or hosts or clients with that string in the IP"