TCP Wrapper

n this regard, 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
wrappers, instead of favoring one over the other, you will make sure that your server
is not left with a single point of failure.
Understanding hosts.allow and hosts.deny
When a network request reaches your server, TCP wrappers
uses hosts.allow and hosts.deny (in that order) to determine if the client should
be allowed to use a given service.
By default, these files are empty, all commented out, or do not exist. Thus, everything
is allowed through the TCP wrappers layer and your system is left to rely on the
firewall for full protection. Since this is not desired, due to the reason we stated in the
introduction, make sure both files exist:

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

The syntax of both files is the same:

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

where,

1. services is a comma-separated list of services the current rule should be applied

to.
2. clients represent the list of comma-separated hostnames or IP addresses affected
by the rule. The following wildcards are accepted:
1. ALL matches everything. Applies both to clients and services.
2. LOCAL matches hosts without a period in their FQDN, such as localhost.
3. KNOWN indicate a situation where the hostname, host address, or user are
known.
4. UNKNOWN is the opposite of KNOWN.
5. PARANOID causes a connection to be dropped if reverse DNS lookups (first
on IP address to determine host name, then on host name to obtain the IP
addresses) return a different address in each case.
 3. Finally, an optional list of colon-separated actions indicate what should happen
when a given rule is triggered.
You may want to keep in mind that a rule allowing access to a given service
in /etc/hosts.allow takes precedence over a rule
in /etc/hosts.deny prohibiting it. Additionally, if two rules apply to the same
service, only the first one will be taken into account.
Unfortunately, not all network services support the use of TCP wrappers. To
determine if a given service supports them, do:

# ldd /path/to/binary | grep libwrap

If the above command returns output, it can be TCP-wrapped. An example of this

are sshd and vsftpd, as shown here:

Find Supported Services in TCP Wrapper

How to Use TCP Wrappers to Restrict Access to

Services
As you edit /etc/hosts.allow and /etc/hosts.deny , make sure you add a
newline by pressing Enter after the last non-empty line.
To allow SSH and FTP access only to 192.168.0.102 and localhost and deny all
others, add these two lines in /etc/hosts.deny :

sshd,vsftpd : ALL

ALL : ALL

and the following line in /etc/hosts.allow :

sshd,vsftpd : 192.168.0.102,LOCAL

TCP Wrappers – hosts.deny File

# hosts.deny This file contains access rules which

are used to

# deny connections to network services that

either use

# the tcp_wrappers library or that have been

# started through a tcp_wrappers-enabled xinetd.

# The rules in this file can also be set up in

# /etc/hosts.allow with a 'deny' option instead.

# See 'man 5 hosts_options' and 'man 5

hosts_access'

# for information on rule syntax.

# See 'man tcpd' for information on tcp_wrappers

#
sshd,vsftpd : ALL
ALL : ALL
TCP Wrappers – hosts.allow File

# hosts.allow This file contains access rules which

are used to

# allow or deny connections to network services

that

# either use the tcp_wrappers library or that

have been

# started through a tcp_wrappers-enabled xinetd.

# See 'man 5 hosts_options' and 'man 5

hosts_access'

# for information on rule syntax.

# See 'man tcpd' for information on tcp_wrappers

sshd,vsftpd : 192.168.0.102,LOCAL
These changes take place immediately without the need for a restart.

In the following image you can see the effect of removing the word LOCAL from the
last line: the FTP server will become unavailable for localhost. After we add the
wildcard back, the service becomes available again.
 Verify FTP Access

To allow all services to hosts where the name contains example.com , add this line
in hosts.allow :

ALL : .example.com

and to deny access to vsftpd to machines on 10.0.1.0/24, add this line

in hosts.deny :

vsftpd : 10.0.1.

On the last two examples, notice the dot at the beginning and the end of the client list.
It is used to indicate “ALL hosts and / or clients where the name or the IP contains
that string”.
Was this article helpful to you? Do you have any questions or comments? Feel free to
drop us a note using the comment form below.

Restrict Access To Linux Servers

Using TCP Wrappers
Configuration
TCP Wrappers implements the access control with the help of two
configuration files: /etc/hosts.allow and /etc/hosts.deny. These two access
control list files decides whether or not the specific clients are allowed to
access your Linux server.
The /etc/hosts.allow file
This file contains the list of allowed or non-allowed hosts or networks. It
means that we can both allow or deny connections to network services by
defining access rules in this file.

The /etc/hosts.deny file

This file contains the list of hosts or networks that are not allowed to access
your Linux server. The access rules in this file can also be set up in
/etc/hosts.allow with a ‘deny’ option.
The typical syntax to define an access rule is:

daemon_list : client_list : option : option ...

Where,

 daemon_list – The name of a network service such as SSH, FTP,

Portmap etc.
 clients_list – The comma separated list of valid hostnames, IP addresses
or network addresses.
 options – An optional action that specifies something to be done
whenever a rule is matched.
The syntax is same for both files.

Rules to remember
Before using TCP Wrappers, you need to know the following important rules.
Please be mindful that the TCP Wrapper consults only these two files
(hosts.allow and hosts.deny).

 The access rules in the /etc/hosts.allow file are applied first. They takes
precedence over rules in /etc/hosts.deny file. Therefore, if access to a
service is allowed in /etc/hosts.allow file, and a rule denying access to
that same service in /etc/hosts.deny is ignored.
 Only one rule per service is allowed in both files (hosts.allow and
hosts.deny).
 The order of the rules is very important. Only the first matching rule for a
given service will be taken into account. The same applies for both files.
 If there are no matching rules for a service in either files or if neither file
exist, then access to the service will be granted to all remote hosts.
 Any changes in either files will come to effect immediately without
restarting the network services.
The recommended approach to secure your
server
Generally, the best practice to secure a Linux server is to block all incoming
connections, and allow only a few specific hosts or networks. To do so,
edit /etc/hosts.deny file:

$ sudo vi /etc/hosts.deny

Add the following line. This line refuses connections to ALL services and ALL
networks.

ALL: ALL

Then, edit /etc/hosts.allow file:

$ sudo vi /etc/hosts.allow

and allow the specific hosts or networks of your choice.

sshd: 192.168.43.192 192.168.43.193

Also, you can specify valid hostnames instead of IP address as shown below.
sshd: server1.ostechnix.lan server2.ostechnx.lan

Alternatively, you can do the same by defining all rules (both allow and deny)
in /etc/hosts.allow file itself.

Edit /etc/hosts.allow file and add the following lines.

sshd: 192.168.43.192 192.168.43.193

sshd: ALL: DENY

You don’t need to specify any rule in /etc/hosts.deny file.

As per above rule, all incoming connections will be denied for all hosts except
the two hosts 192.168.43.192, 192.168.43.193.

Now, try to SSH to your Linux server from any hosts except the above hosts,
you will get the following error.

ssh_exchange_identification: read: Connection reset by

peer

You can verify this from your Linux server’s log files as shown below.

$ cat /var/log/secure

Sample output:

Jun 16 19:40:17 server sshd[15782]: refused connect from

192.168.43.150 (192.168.43.150)
Similarly, you can define rules for other services, say for example vsftpd,
in /etc/hosts.allow file as shown below.

vsftpd: 192.168.43.192

vsftpd: ALL: DENY

Again, you don’t need to define any rules in /etc/hosts.deny file. As per the
above rule, a remote host with IP address 192.168.43.192 is allowed to
access the Linux server via FTP. All other hosts will be denied.
Also, you can define the access rules in different formats in /etc/hosts.allow
file as shown below.

sshd: 192.168.43.192 #Allow a single

host for SSH service

sshd: 192.168.43.0/255.255.255.0 #Allow a /24

prefix for SSH

vsftpd: 192.168.43.192 #Allow a single

host for FTP

vsftpd: 192.168.43.0/255.255.255.0 #Allow a

/24 prefix for FTP

vsftpd: server1.ostechnix.lan #Allow a

single host for FTP

Allow all hosts except a specific host

You can allow incoming connections from all hosts, but not from a specific
host. Say for example, to allow incoming connections from all hosts in
the 192.168.43 subnet, but not from the host 192.168.43.192, add the
following line in /etc/hosts.allow file.
ALL: 192.168.43. EXCEPT 192.168.43.192

In the above case, you don’t need to add any rules in /etc/hosts.deny file.

Or you can specify the hostname instead of IP address as shown below.

ALL: .ostechnix.lan EXCEPT badhost.ostechnix.lan

For more details, refer the man pages.

$ man tcpd