Using TCP Wrappers to secure Linux


TCP Wrappers can be used to GRANT or DENY access to various services on your machine to the outside network or other machines on the same network. It does this by using simple Access List Rules which are included in the two files /etc/hosts.allow and /etc/hosts.deny .

Let us consider this scenario: A remote machine remote_mc trying to connect to your local machine local_mc using ssh.When the request from the remote_mc is received by the tcp wrapped service (SSH in this case), it takes the following basic steps:

  1. It checks the /etc/hosts.allow file and applies the first rule specified for that service. If it finds a matching rule , it allows the connection. If no rule is found, it moves on to step 2.
  2. It checks the /etc/hosts.deny file and if a matching rule is found, it deny’s the connection.

Points to remember

  • Rules in hosts.allow takes precedence over rules in hosts.deny . Which means if a matching rule is found in hosts.allow file, the remote_mc is allowed access to the service even if there is a matching deny rule in hosts.deny file.
  • You can have only one rule per service in hosts.allow and hosts.deny file.
  • If there are no matching rules in either of the files or if the files don’t exist, then the remote_mc is allowed access to the service.
  • Any changes to hosts.allow and hosts.deny file takes immediate effect.

Rule Syntax
The syntax for both hosts.allow and hosts.deny file takes the following form:

daemon : client [:option1:option2:…]

Where daemon can be a combination of ssh daemon, ftp daemon, portmap daemon and so on. Basically any service which has support for libwrap.a library compiled into it is a good candidate for utilizing the services of TCP Wrappers.

client is a comma separated list of hostnames, host IP addresses, special patterns or special wildcards which identify the hosts effected by that rule.
options is an optional action like say sending mail to the administrator when this rule is matched, log to a particular file and so on. It can be a colon separated list of actions too.

Examples of using TCP Wrappers

I want to allow SSH access to hosts in a particular domain say xyz.com and deny access to all the others. I enter the following rule in the hosts.allow file.

sshd : .xyz.com

… and in the hosts.deny file I include the rule:

sshd : ALL

The next rule denys FTP access to all the hosts in the abc.co.in domain as well as hosts in the 192.168.1.0 network.

#FILE: /etc/hosts.deny

vsftpd : 192.168.1. , .abc.co.in : spawn /bin/echo  `/bin/date` access denied >> /var/log/vsftpd.log : deny

The backslash (\) in the above rule is used to break the line and prevents the failure of the rule due to length.

spawn and deny are options. Spawn launches a shell command as a child process. In the above rule, spawn logs a message to the vsftpd log file each time the rule matches. deny is optional if you are including this rule in the hosts.deny file.

Note: The last line in the files hosts.allow and hosts.deny must be a new line character. Or else the rule will fail.

For example, you can use spawn option to send mail to the admin when ever a deny rule is matched.

Wildcards

You can use wildcards in the client section of the rule to broadly classify a set of hosts. These are the valid wildcards that can be used.

  •  ALL – Matches everything
  • LOCAL – Matches any host that does not contain a dot (.) like localhost.
  • KNOWN – Matches any host where the hostname and host addresses are known or where the user is known.
  • UNKNOWN – Matches any host where the hostname or host address are unknown or where the user is unknown.
  • PARANOID – Matches any host where the hostname does not match the host address.

Patterns
You can also use patterns in the client section of the rule . Some examples are as follows:

ALL : .xyz.com

Matches all hosts in the xyz.com domain . Note the dot (.) at the beginning.

ALL : 123.12.

Matches all the hosts in the 123.12.0.0 network. Note the dot (.) in the end of the rule.

ALL : 192.168.0.1/255.255.255.0

IP address/Netmask can be used in the rule.

ALL : *.xyz.com

Asterisk * matches entire groups of hostnames or IP addresses.

sshd : /etc/sshd.deny

If the client list begins with a slash (/), it is treated as a filename. In the above rule, TCP wrappers looks up the file sshd.deny for all SSH connections.

sshd : ALL EXCEPT 192.168.0.15

If the above rule is included in the /etc/hosts.deny file, then it will allow ssh connection for only the machine with the IP address 192.168.0.15 and block all other connections. Here EXCEPT is an operator.

Note: If you want to restrict use of NFS and NIS then you may include a rule for portmap . Because NFS and NIS depend on portmap for their successful working. In addition, changes to portmap rules may not take effect immediately.

Suppose I want to log all connections made to SSH with a priority of emergency  I could do the following:

sshd : .xyz.com : severity emerg

Note: You can use the options allow or deny to allow or restrict on a per client basis in either of the files hosts.allow and hosts.deny

in.telnetd : 192.168.5.5 : deny

in.telnetd : 192.168.5.6 : allow

Shell Commands

As mentioned above, you can couple the rules to certain shell commands by using the following two options.

spawn – This option launches a shell command as a child process. For example, look at the following rule:

sshd : 192.168.5.5 : spawn /bin/echo `/bin/date` from %h >> /var/log/ssh.log : deny

Each time the rule is satisfied, the current date and the clients hostname %h is appended to the ssh.log file.

twist – This is an option which replaces the request with the specified command. For example, if you want to send to the client trying to connect using ssh to your machine, that they are prohibited from accessing SSH, you can use this option.

sshd : client1.xyz.com : twist /bin/echo “You are prohibited from accessing this service!!” : deny

When using spawn and twist, you can use a set of expressions. They are as follows :
%a — The client’s IP address.
%A — The server’s IP address.

%c — Supplies a variety of client information, such as the username and hostname, or the username and IP address.

%d — The daemon process name.
%h — The client’s hostname (or IP address, if the hostname is unavailable).
%H — The server’s hostname (or IP address, if the hostname is unavailable).

%n — The client’s hostname. If unavailable, unknown is printed. If the client’s hostname and host address do not match, paranoid is printed.

%N — The server’s hostname. If unavailable, unknown is printed. If the server’s hostname and host address do not match, paranoid is printed.

%p — The daemon process ID.

%s — Various types of server information, such as the daemon process and the host or IP address of the server.

%u — The client’s username. If unavailable, unknown is printed.

Linux Security With TCP Wrappers

The TCP Wrappers package is installed by default on Fedora Linux and provides host-based security separate from that provided by a firewall running on the server itself or elsewhere.

The application relies on two main files:

  • /etc/hosts.allow: Defines the hosts and networks allowed to connect to the server. The TCP Wrappers enabled application searches this file for a matching entry, and if it finds one, then the connection is allowed.
  • /etc/hosts.deny: Defines the hosts and networks prohibited from connecting to the server. If a match is found in this file, the connection is denied. No match means the connection proceeds normally.

The /etc/hosts.allow file is always read first and both files are always read from top to bottom, therefore the ordering of the entries is important.

The TCP Wrappers File Format

The format of the file is as follows:

<TCP-daemon-name>  <client-list>  : <option>

This example allows all traffic from the 192.168.1.0/24 and the 192.168.2.0/255.255.255.0 networks and SSH from only two hosts, 172.16.1.1 and 216.10.119.244. All HTTP Web traffic is allowed. All other TCP traffic to the host is denied. Notice how the subnet masks can use the slash nomenclature or the dotted decimal 255.255.255.0 format.

# File: hosts.allow

ALL:    192.168.1.0/24 192.168.2.0/255.255.255.0

sshd:   172.16.1.1 216.10.119.244

httpd:  ALL

# File: hosts.deny

 ALL:    ALL

Determining the TCP Daemon’s Name

The easiest way of determining the name of a daemon is to use the ps command and then use grep to filter for the name of the service. Here, the example quickly determines the daemon name (/usr/sbin/sshd) for the SSH server process. Because TCP Wrappers only requires the program name and not the path, sshd therefore becomes the entry to place in the TCP-daemon-name column of the configuration file.

[root@server]# ps -ef | grep -i ssh

root     10053    1  0 Nov06 ?        00:00:00 /usr/sbin/sshd

root     14145 10053  0 Nov13 ?        00:00:02 sshd: root@pts/1

root     18100 14148  0 21:56 pts/1    00:00:00 grep ssh

Additional TCP Wrappers Help

For a full explanation of all the options available, refer to section 5 of the man pages for hosts_access.

[root@server~]# man 5 hosts_access

TCP wrappers is simple to implement, but you have to set them on every host. Management is usually easier on a firewall that protects the entire network.

About Alex Hunt

Hi All I am Manish Kumar Jha aka Alex Hunt. I am currently working in VMware Software India Pvt Ltd as Operations System Engineer (vCloud Air Operations). I have around 5 Years of IT experience and have exposure on VMware vSphere, vCloud Director, RHEL and modern data center technologies like Cisco UCS and Cisco Nexus 1000v and NSX. If you find any post informational to you please press like and share it across social media and leave your comments if you want to discuss further on any post. Disclaimer: All the information on this website is published in good faith and for general information purpose only. I don’t make any warranties about the completeness, reliability and accuracy of this information. Any action you take upon the information you find on this blog is strictly at your own risk. The Views and opinions published on this blog are my own and not the opinions of my employer or any of the vendors of the product discussed.
This entry was posted in Linux/CentOS. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s