TCP Wrapper Features

Access Control

TCP Wrappers uses /etc/hosts.allow and /etc/hosts.deny files as Access Control Lists (ACLs). These access control files are used to match the client and server entries with the request for a service. These files are based on pattern matching and can be extended via optional extensions like: allowing the spawning of a shell command.

Each access control file consists of a set of access control rules for different services, which use tcpd.

An access control rule is of the following form:

daemon_list:client_list:option:option:..

Where daemon_list contains the list of daemons and client_list contains the list of clients for which this rule is applicable. Each list is a set of items separated by a space. The options are separated by a colon.

The access control module reads the /etc/hosts.allow and /etc.hosts.deny files before granting or denying access to any service. The files are searched in the following order:

Where “daemon” is the name of a network daemon process and “client” is the name and/or address of a host requesting the service.

Access control can be turned off by not providing an access control file.

Examples:

Hostname/Address Spoofing

The wrapper program offers protection against hosts which pretend as some other host. If any discrepancies are noticed in the client address or name, the wrapper program denies access by logging the information. tcpd also disables the source-routing socket options on every connection that it deals with. UDP services benefit from this protection.

Client Username Lookups

tcpd provides information about the owner of the client-side TCP connection using the RFC931 protocol. By default, client username lookup is disabled. If it is enabled through the configuration file /etc/tcpd.conf, tcpd assumes that the client requesting the service supports a RFC931-compliant daemon (like IDENT), running on it.

Setting Traps

This feature is the ability to trigger actions on the host which are based on attempted connections. For example, the following rule in /etc/hosts.deny not only rejects the attempt, but also notifies the system administrator whenever a remote site attempts to access your TFTP server:

tftpd:ALL:spawn (/usr/bin/safe_finger -1 @%h2>&1| \
mailx -s “remote tftp attempt” root)

Banner Messages

This feature provides a mechanism to send some message, when an ACL rule is fired. For example, the following rule in /etc/hosts.deny file sends the message present in telnetd file in /tmp/banner directory and denies access whenever a request comes from any host whose address starts with ‘192.5.2.’.

telnetd:192.5.2.:banners/tmp/banner

The Banner option does not add any service-specific characters while sending the text to the client as specified in the service protocol. To use the banner option successfully, the banners file must contain the necessary protocol parameters in addition to the actual text.

For example, in an ftpd service, each line in the banners file is not automatically prefixed by the status code (220-) as defined in RFC 959 (FILE TRANSFER PROTOCOL). To send the following text to the FTP client:

This is a Welcome text to demonstrate the banners
option in tcpd(1M).

HP recommends that you add the protocol-specific response code to the text as follows:

220-This is a Welcome text to demonstrate the banners
220- option in tcpd(1M).

For the rlogind service, a null character (\0) must be placed at the beginning of the rlogind banner file, as specified in the following example:

# echo "\0 Text to demonstrate the banners" > rlogind 
# echo "    option in tcpd(1M)." >> rlogind

tcpd

The tcpd program will log the client hostname address and the remote username who owns the connection, if applicable and perform some additional access control checks. When it is through with all the checks, the wrapper executes the desired server program and exits.

The following are the methods to use the tcpd program:

libwrap.a

The libwrap.a library provides a set of APIs for stand-alone applications to enforce host access control based on /etc/hosts.allow and /etc/hosts.deny files. The APIs implement a rule-based access control language with optional shell commands that are executed when a rule fires.

In order to enforce the host access control in a stand-alone daemon, it has to include the tcpd.h header file and link with libwrap.a. This library includes the following APIs:

The following are the methods to implement access control checks in a daemon program:

	NOTE: Refer to hosts_access(3) man page for more information on these APIs.

tcpdchk

tcpdchk is a tool that can be used to examine the validity of entries in the /etc/inetd.conf file and ACLs.

tcpdchk examines the tcp wrapper configuration and reports all potential and real problems it can encounter. The program examines the tcpd access control files (by default, these are /etc/hosts.allow and /etc/hosts.deny), and compares the entries in these files against the entries in the /etc/inetd.conf file.

This is executed on the command line as:

/usr/bin/tcpdchk [-a] [-d] [-i inet_conf] [-v]

Where

“-a” option is used to report access control rules that grant access without an explicit ALLOW keyword.

“-d” option is used to examine the hosts.allow and hosts.deny files in the current directory instead of the default ones.

“-i inet_conf” option is used, if you want to specify a different path for the inetd configuration file instead of the default one, i.e. /etc/inetd.conf.

“-v” option is used to display the contents of each access control rule. The daemon lists, client lists, shell commands, and options are shown in a printable format; this helps you spot any discrepancies between what you want and what this program understands.

	NOTE: Refer to the tcpdchk(1) man page for more information.

tcpdmatch

tcpdmatch is a tool that can be used to simulate the Wrappers daemon program, tcpd’s behaviour for a particular host and a particular service.

tcpdmatch predicts how the tcp wrapper daemon would handle a specific service request.The program examines the tcpd access control tables (default /etc/hosts.allow and /etc/hosts.deny) and prints its conclusion. For maximum accuracy, it extracts additional information from the /etc/inetd.conf file.

This is executed on the command line as:

/usr/bin/tcpdmatch [-d] [-i inet_conf] daemon client

/usr/bin/tcpdmatch [-d] [-i inet_conf] daemon@[server] [user@]client

The second syntax can be used when your server has more than one address or name.

Where

“daemon” is a daemon process name.

“client” is a host name or network address, or one of the ‘unknown’ or ‘paranoid’ wildcard patterns.

Optional information specified with the “daemon@server” and “user@client” forms:

“server” is a host name or network address, or one of the ‘unknown’ or ‘paranoid’ wildcard patterns. The default server name is ‘unknown’.

“user” is a client user identifier. Typically, it is a login name or a numeric user id. The default user name is ‘unknown’.

The following example illustrates how tcpd would handle a ftp request from a local system:

tcpdmatch ftpd localhost

Pretending that the hostname lookup fails, the same request would be handled by tcpd as follows:

tcpdmatch ftpd 127.0.0.1

To predict what tcpd would do when the client name does not match the client address:

tcpdmatch ftpd paranoid

	NOTE: Refer to tcpdmatch(1) man page for more information. Refer to hosts_access(5) man page for more information on wildcard patterns.

try-from

try-from is a utility program that can be used to identify the end-point details related to a connection. This program must be called via a remote shell command as given below to find out if the hostname and the address are properly recognized, and also if the username lookup works.

This is executed on the command line as:

# remsh host /usr/bin/try-from

try-from prints the following output on its inception:

“client address (%a):”

“client hostname (%n):”

“client username (%u):”

“client info (%c):”

“server address (%A):”

“server hostname (%N):”

“server process (%d):”

“server info (%s):”

	NOTE: Refer to hosts_access(5) man page for more information on %<letter> expressions.

The client-related information describes how the remote host recognizes the client in terms of address, name, and user name whereas the server-related information describes the remote host.

safe_finger

safe_finger is a wrapper program to finger(1) client which offers protection against possible damages to the data sent by the remote finger server. This command accepts all the options supported by finger(1).

	NOTE: Refer to finger(1) man page for more information.

safe_finger command is executed on the command line as:

# /usr/bin/safe_finger -l @xyz.abc.def.com

This command prints the user information on the remote host “xyz.abc.def.com”.

HP recommends using this program in the implementation of Traps in the access control language of /etc/hosts.allow and /etc/hosts.deny.

	NOTE: Refer to hosts_access(5) man page for more information on setting Traps.