Explain: Linux and UNIX TCP Wrappers – Find Out If a Program Is Compiled With TCP Wrappers

by on June 10, 2009 · 10 comments· LAST UPDATED February 24, 2014

in , ,

What are TCP Wrappers? How do I find out if a program or server (service) is compiled with TCP Wrappers? What are the advantages and disadvantages of TCP Wrappers over firewalls like Netfilter or PF? How do I protect my Mac OS X or Sun Solaris or Linux workstation by using TCP Wrappers?

A TCP Wrapper is a library that provides simple access control and standardized logging for supported applications that accept connections over a network. Linux and other Unix-like operating systems are compiled with TCP Wrappers (also known as "TCPD"). For example, Solaris, Linux, *BSD, and Mac OS X have TCP Wrappers configured to run right out of the box.
Tutorial details
DifficultyEasy (rss)
Root privilegesYes
RequirementsNone
Estimated completion time15m

A TCP Wrapper is a host-based networking access control list (ACL) system and used to filter network access to Internet. TCP Wrappers were original written to monitor and stop cracking activities on the UNIX workstation in the 1990s. It was the best solution in the '90s to protect the UNIX workstations over the Internet. However, it has few disadvantages:

  1. All UNIX apps must be compiled with the libwrap library.
  2. The wrappers do not work with RPC services over TCP.
  3. The user name lookup feature of TCP Wrappers uses identd to identify the username of the remote host. By default, this feature is disabled, as identd may appear hung when there are a large number of TCP connections.

Nevertheless, TCP Wrappers present one strong advantage over firewall: it works on the application layer. It can filter requests when encryption is used. Basically, users need to use both host-based and network-based security. Common services such as pop3, ftp, sshd, telnet, and r-services are supported by TCP Wrappers.

TCPD (TCP Wrappers) Benefits

  1. Logging - Connections that are monitored by TCPD are reported through the syslog facility.
  2. Access Control - TCPD supports a simple form of access control that is based on pattern matching. You can even hook the execution of shell commands/script when a pattern matches.
  3. Host Name Verification - TCPD verifies the client host name that is returned by the address->name DNS server by looking at the host name and address that are returned by the name->address DNS server.
  4. Spoofing Protection.

How do I Find Out Whether a Program Is Compiled with TCP Wrappers or Not?

To determine whether a given executable daemon/path/to/daemon supports TCP Wrappers, type:

 $ ldd /path/to/daemon | grep libwrap.so

If this command returns any output, then the daemon probably supports TCP Wrappers. In this example, find out if SSHD supports TCP Wrappers on not. First, locate the SSHD program location on the disk:
$ whereis sshd
Sample Output:

sshd: /usr/sbin/sshd /usr/share/man/man8/sshd.8.gz

Next, run the good old ldd command as follows to find out whether SSHD daemon supports TCP Wrappers or not:
$ ldd /usr/sbin/sshd | grep libwrap.so
Sample Output:

	libwrap.so.0 => /lib64/libwrap.so.0 (0x00002b759b381000)

The ldd command is used to see if libwrap.so is a dependency or not. An alternative to TCP Wrapper support is packet filtering using iptables.

Important Files

  • tcpd daemon - Access control facility for Internet services.
  • /etc/hosts.allow - This file describes the names of the hosts which are allowed to use the local INET services, as decided by the /usr/sbin/tcpd server.
  • /etc/hosts.deny - This file describes the names of the hosts which are NOT allowed to use the local INET services, as decided by the /usr/sbin/tcpd server.
  • If the same client/user/ip is listed in both hosts.allow and hosts.deny, then hosts.allow takes precedence, and access is permitted. If the client is listed in hosts.allow, then access is permitted. If the client is listed in hosts.deny, then access is denied.
  • tcpdchk and tcpdmatch commands - Test programs for tcpd.

Syntax (format) Of Host Access Control Files

Both /etc/hosts.allow and /etc/hosts.deny use the following format:

daemon_list : client_list [ : shell_command ]

Where,

  • daemon_list - a list of one or more daemon process names.
  • client_list - a list of one or more host names, host addresses, patterns, or wildcards that will be matched against the client host name or address.

WildCards

The access control language supports explicit wildcards (quoting from the man page):

       ALL    The universal wildcard, always matches.
       LOCAL  Matches any host whose name does not contain a dot character.
       UNKNOWN
	      Matches  any  user  whose  name is unknown, and matches any host
	      whose name or address are unknown.  This pattern should be  used
	      with  care:  host names may be unavailable due to temporary name
	      server problems. A network address will be unavailable when  the
	      software	cannot	figure	out what type of network it is talking
	      to.
       KNOWN  Matches any user whose name is known, and matches any host whose
	      name  and  address  are  known. This pattern should be used with
	      care: host names may be unavailable due to temporary name server
	      problems.   A network address will be unavailable when the soft-
	      ware cannot figure out what type of network it is talking to.
       PARANOID
	      Matches any host whose name does not match  its  address.   When
	      tcpd  is built with -DPARANOID (default mode), it drops requests
	      from such clients even before  looking  at  the  access  control
	      tables.	Build  without	-DPARANOID  when you want more control
	      over such requests.

TCPD Configuration Examples

In this example, I will set default policy to deny access. Only explicitly authorized hosts are permitted access. Update /etc/hosts.deny file as follows:

 # The default policy (no access) is implemented with a trivial deny file
ALL: ALL
 

The ALL: ALL config will deny all service to all hosts unless they are permitted access by entries in the allow file. For example, allow access as follows via /etc/hosts.allow file:

 
  ALL: LOCAL @devels
  ALL: .nixcraft.net.in EXCEPT boobytrap.nixcraft.net.in
 

Log and deny access (booby traps) - we do not allow connections from crackers.com:

 
ALL : .crackers.com \
    : spawn (/bin/echo %a from %h attempted to access %d >> \
      /var/log/connections.log) \
    : deny
 

A Typical UNIX Example

Allow access to various services inside LAN only via /etc/hosts.allow:

popd : 192.168.1.200 192.168.1.104
imapd : 192.168.1.0/255.255.255.0
sendmail : 192.168.1.0/255.255.255.0
sshd : 192.168.1.2 172.16.23.12

Deny everything via /etc/hosts.deny:

 ALL : ALL

Reject All Connections

Restrict all connections to non-public services to localhost only. Suppose SSHD and FTPD are the names of services which must be accessed remotely. Edit /etc/hosts.allow. Add the following lines for sshd and ftpd:

sshd ,ftpd : ALL
ALL: localhost

Save and close the file. Edit /etc/hosts.deny. Add the following line:

ALL: ALL

Default Log Files

TCP Wrappers will do all logging via syslog according to your /etc/syslog.conf file. The following table lists the standard locations where messages from TCP Wrappers will appear:

  1. AIX - /var/adm/messages
  2. HP-UX - /usr/spool/mqueue/syslog
  3. Linux - /var/log/messages
  4. FreeBSD / OpenBSD / NetBSD - /var/log/messages
  5. Mac OS X - /var/log/system.log
  6. Solaris - /var/log/syslog

Use the following command to view logs:
# tail -f /path/to/log/file
# grep 'ip' /path/to/log/file
# egrep -i 'ip|hostname' /path/to/log/file

How Do I Predict How the TCP Wrapper Will Handle a Specific Request For Service?

Use the tcpdmatch command to predict how the TCPD would handle an SSHD request from the local system:
tcpdmatch sshd localhost
The same request, pretending that the hostname lookup failed:
tcpdmatch sshd 192.168.1.5
To predict what TCPD would do when the client name does not match the client address:
tcpdmatch sshd paranoid
Replace sshd with in.telnetd, or ftpd and so on. You can use all daemon names specified in the inetd.conf or xinetd.conf file.

How Do I Examine My TCP Wrapper Configuration File?

Use the tcpdchk command to examine your TCP Wrapper configuration and report all of the potential and real problems it can find.
tcpdchk
tcpdchk -v

A Note About TCP Wrappers and Firewall

  • You need to use both (firewall and tcpd) to fight against crackers.
  • TCP Wrappers are most commonly employed to match against IP addresses and host level protection.
  • Never configure TCP Wrappers on firewall host.
  • Put TCP Wrappers on all UNIX / Linux / BSD workstations.
  • Do not use NIS (YP) netgroups in TCP Wrappers rules.
  • Put TCP Wrappers behind a firewall systems as TCP Wrappers is no substitute for netfilter or pf firewall.
  • TCP Wrappers does provide increased security as firewall cannot examine encrypted connections (read as packets).

A Note about TCP Wrappers and Firewall

  • You need to use both (firewall and TCPD) to fight against crackers.
  • TCP Wrappers are most commonly employed to match against IP addresses and host level protection.
  • Never configure TCP Wrappers on the firewall host.
  • Put TCP Wrappers on all UNIX / Linux / BSD workstations.
  • Do not use NIS (YP) netgroups in the TCP Wrappers rules.
  • Put TCP Wrappers behind a firewall system, as TCP Wrappers are no substitute for Netfilter or PF firewalls.
  • TCP Wrappers provide increased security, as the firewall cannot examine encrypted connections (read as packets).
References:
  1. man pages - tcpd(8), tcpdchk(8), tcpdmatch(8), and hosts_access(5).
  2. TCP Wrappers Release Notes from HP-UX
  3. TCP Wrappers configuration under FreeBSD operating systems.
  4. What are TCP Wrappers in Red Hat Enterprise Linux / CentOS Linux? What are some of the best practices and known issues?

# Additional correction requested by John K H; Editing by VG - log #

TwitterFacebookGoogle+PDF versionFound an error/typo on this page? Help us!

{ 10 comments… read them below or add one }

1 wao June 10, 2009 at 10:33 am

got typo in text, “Host Mame Verification”. btw, nice article!

Reply

2 nixCraft June 10, 2009 at 11:31 am

Thanks for the heads-up!

Reply

3 Shoaibi June 18, 2009 at 8:28 am

actually if you are just looking for sshd:
which sshd
would save you typing and output parsing.

Reply

4 Shoaibi June 18, 2009 at 8:32 am

and btw nice article… my personal security suite is:
firewall+ tcpwrapper + denyhosts + snort + rkhunter
have never been knocked out of business.

Reply

5 kamarul March 7, 2012 at 7:02 am

Hi,
We also can take this simpler step identifying the binary supported or not.

ldd $(which sshd) |grep -i libwrap –color
libwrap.so.0 => /lib64/libwrap.so.0 (0x00002b51d5a7c000)

Reply

6 askar December 25, 2012 at 11:46 am

nice article

Reply

7 Karthikeyan July 25, 2013 at 6:48 am

Guys, I have a doubt if you know answer mean please share with us. I already tried IP addresses and host-name in TCP Wrapper but i don’t know how to use mac addresses in this method please help me

Reply

8 aa February 13, 2014 at 8:06 am

tnxxxxxxxxxxxxxxxxxxxxx

Reply

9 Loadedmind February 21, 2014 at 2:15 pm

Karth->http://lmgtfy.com/?q=hosts.allow+mac+address
From the very first link, it looks like using hosts.allow/hosts.deny for MAC addresses is not a viable option. You’re looking at either an iptables entry such as:
iptables -A INPUT -p tcp –mac-source XX:XX:XX:XX:XX:XX –dport 22 -j ACCEPT
–OR–
using something like shorewall which has the capability to filter this way.
Remember, search engine usage is free.

Reply

10 Abhishek February 25, 2014 at 6:03 pm

Thanks for this info. It was helpful.

Reply

Leave a Comment

Tagged as: , , , , , , , , , , ,

Previous Faq:

Next Faq: