jump to navigation

TCP Wrappers on Linux December 22, 2010

Posted by Tournas Dimitrios in Linux.
trackback

The TCP Wrappers package (tcp_wrappers) is installed by default on almost all BSD / UNIX / LINUX like operating systems .It is a host-based network ACL system which provides simple control and standardized logging for supported applications which accept connections over the network . The most important component within the package is the /usr/lib/libwrap.a library. In general terms, a TCP-wrapped service is one that has been compiled with support for  the libwrap.a library.

When a connection attempt is made to a TCP-wrapped service, the service first references the host’s access files (/etc/hosts.allow and /etc/hosts.deny) to determine whether or not the client is allowed to connect. In most cases, it then uses the syslog daemon (syslogd) to write the name of the requesting client and the requested service to /var/log/secure or /var/log/messages.In addition to acl and logging , tcp_wrappers can execute commands to interact with the client before denying or releasing control of the connection to the requested network service .

If a client is allowed to connect, TCP Wrappers release control of the connection to the requested service and take no further part in the communication between the client and the server.

tcp_wrapper is not a replacement for firewalls ( iptables )  or xinetd. It has one strong advantage over firewall . It works on the application layer . It can filter requests when encryption is used . Basically , you need to use both host based and network based security . Common services such as pop3 , sshd , telnet , r-services ar supported by tcp_wrappers . The following picture demonstrates how these tools work together to protect network services .

TCP Wrappers Configuration Files :

To determine if a client is allowed to connect to a service, TCP Wrappers reference the following two files, which are commonly referred to as hosts access files:

  • /etc/hosts.allow
  • /etc/hosts.deny

When a TCP-wrapped service receives a client request, it performs the following steps:

  • It references /etc/hosts.allow. — The TCP-wrapped service sequentially parses 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 not, it moves on to the next step.
  • It references /etc/hosts.deny. — The TCP-wrapped service sequentially parses the /etc/hosts.deny file. If it finds a matching rule, it denies the connection. If not, it grants access to the service.

Note: To determine if a network service binary is linked to libwrap.a, type the following command as the root user:

ldd  /path/to/deamon | grep libwrap.so

Replace with the name of the network service binary. If the command returns straight to the prompt with no output, then the network service is not linked to libwrap.a.

The following example indicates that /usr/sbin/sshd is linked to libwrap.a:

[root@myserver ~]# ldd /usr/sbin/sshd | grep libwrap

libwrap.so.0 => /usr/lib/libwrap.so.0 (0x00655000)

[root@myserver ~]#

Access Rules Formation :

The format for both /etc/hosts.allow and /etc/hosts.deny is identical. Each rule must be on its own line. Blank lines or lines that start with a hash (#) are ignored.

Each rule uses the following basic format to control access to network services:

: [: : : …]

The following is a basic sample hosts access rule:

sshd : .xyz.com

This rule instructs TCP Wrappers to watch for connections to the SSH daemon (sshd) from any host in the

xyz.com domain. If this rule appears in hosts.allow, the connection is accepted. If this rule appears in hosts.deny, the connection is rejected.

The next sample hosts access rule is more complex and uses two option fields:

sshd : .xyz.com  : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log  : deny

This sample rule states that if a connection to the SSH daemon (sshd) is attempted from a host in the example.com domain, execute the echo command to append the attempt to a special log file, and deny the connection. Because the optional deny directive is used, this line denies access even if it appears in the hosts.allow file.

Wildcards :

Wildcards allow TCP Wrappers to more easily match groups of daemons or hosts. They are used most frequently in the client list field of access rules.

The following wildcards are available:

  • ALL — Matches everything. It can be used for both the daemon list and the client list.
  • LOCAL — Matches any host that does not contain a period (.), such as localhost.
  • KNOWN — Matches any host where the hostname and host address 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.

NOTE: The KNOWN, UNKNOWN, and PARANOID wildcards should be used with care, because they rely on functioning DNS server for correct operation. Any disruption to name resolution may prevent legitimate users from gaining access to a service.

Some more examples:

#The following example applies to any host within the example.com domain:

ALL : .example.com

#The following example applies to any host within the 192.168.x.x network:

ALL : 192.168.

#The following example applies to any host with an

#address range of 192.168.0.0 through 192.168.1.255:

ALL : 192.168.0.0/255.255.254.0

#The following example would apply to any host within the example.com domain:

ALL : *.example.com

#The slash (/) — If a client list begins with a slash, it is treated as a file name.

#This is useful if rules specifying large numbers of hosts are necessary.

#The following example refers TCP Wrappers to the /etc/telnet.hosts file

#for all Telnet connections:in.telnetd : /etc/telnet.hosts#The following example applies to any host e.g. 0.0.0.0/255.255.255.255 :

ALL : ALL

Shell Commands :

Option fields allow access rules to launch shell commands through the following two directives:

  1. Spawn

    Launches a shell command as a child process. In the following example, clients attempting to access ssh services from the example.com domain are quietly logged to a special file:

    sshd : .example.com \

    : spawn /bin/echo `/bin/date` from  %h>>/var/log/sshdallowed.log \

    : allow

    # %h Returns the client’s hostname or IP address

  2. Twist

    Replaces the requested service with the specified command. This directive is often used to set up traps for intruders (also called “honey pots”). It can also be used to send messages to connecting clients. The twist directive must occur at the end of the rule line.

    In the following example, clients attempting to access FTP services from the example.com domain are sent a message using the echo command:

    vsftpd : .example.com \

    : twist /bin/echo “421 This domain has been black-listed. Access denied!”

    Note: For more information about shell command options, refer to the hosts_options man page.

Comments»

No comments yet — be the first.

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