Securing Linux network services with TCP_wrappers

by Jim McIntyre | Nov 08, 2000 8:00:00 AM

Tags: Jim McIntyre

Takeaway: This Daily Drill Down focuses on the process of installing and configuring the tcpd service on a Linux server. It also shows you how you can allow and deny access to inetd-run services.

The inetd daemon is often referred to as the Internet "super server" because it provides many of the most common Internet services, such as FTP, Telnet, POP3, and finger. The TCP_wrappers service provides access control list restrictions and logging for all service requests to the service it wraps.

This Daily Drill Down will provide a step-by-step process for installing and configuring the tcpd service on a Linux server. I’ll also look at ways of allowing and denying access to inetd-run services, and I’ll show how to log attempts to access these services.

Getting TCP_wrappers
TCP_wrappers is available from all Linux vendors as well as from several sites that offer security software. TCP_wrappers is also packaged with Red Hat 5.2/6.2. The default installation of TCP_wrappers is fine, but the first section of this Daily Drill Down will look at methods for customizing a TCP_wrappers installation by compiling the source code.

Building TCP_wrappers
There are three formats available when downloading TCP_wrappers:

• Gzipped—Requires source-code compilation.
• RPM source code—Requires source-code compilation.
• RPM binary—No compilation required. Uses default settings.

The RPM binary is fine for most purposes. As your network grows in size and complexity, however, you’ll probably need to compile TCP_wrappers with options that reflect your requirements.

For this Daily Drill Down, I’ve assumed that you’ve downloaded the source code to /usr/src/tcp_wrappers.

Compile-time options for TCP_wrappers are controlled through the Makefile. In case you aren't familiar with the name Makefile, this is a filename used by the make command to read configuration options for compiling source code.

To configure a TCP_wrappers installation to match your system needs, you must edit the Makefile. Any text editor may be used for this purpose. Table A lists compile-time options for TCP_wrappers and the Red Hat Linux default for each option.
In Table A, No means that the indicated option was not used or was commented out by a # character in the Makefile. Yes means that the option was used or was turned on by uncommenting it in the Makefile. Default means that the Makefile includes more than one value for this option and that the one that was originally uncommented was used.

Running make Linux for TCP_wrappers
Once you’ve decided which options you want to use, select these options by editing the Makefile in any text editor. Even if you want to use the defaults, you must still edit the Makefile and make the following changes before you run make.

First, change the line
CFLAGS = -O -DFACILITY=$(FACILITY) $(ACCESS) $(PARANOID) $(NETGROUP) \

to
CFLAGS = -DFACILITY=$(FACILITY) $(ACCESS) $(PARANOID) $(NETGROUP) \

Next, change the entry
Linux:
 @make REAL_DAEMON_DIR=$(REAL_DAEMON_DIR) STYLE=$(STYLE) \
 LIBS= RANLIB=ranlib ARFLAGS=rv AUX_OBJ= setenv.o \
 NETGROUP= TLI= EXTRA_CFLAGS="-DBROKEN_SO_LINGER" all

to
Linux:
 @make REAL_DAEMON_DIR=$(REAL_DAEMON_DIR) STYLE=$(STYLE) \
 LIBS= RANLIB=ranlib ARFLAGS=rv AUX_OBJ= \
 NETGROUP= TLI= \
 EXTRA_CFLAGS="-DBROKEN_SO_LINGER" -DSYS_ERRLIST_DEFINED" all

After these changes are completed, run the commands
make Linux
make install
make clean

In addition, you may want to copy the following files to a standard TCP_wrappers directory:

• BLURB
• CHANGES
• README
• DISCLAIMER
• Banners.Makefile

Normally, this directory would be /usr/sbin/tcp-wrappers_7.6.

Access control with TCP_wrappers
TCP_wrappers implements access by using two files:

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

These files use the same syntax, and both files are considerably more flexible than a simple allow or deny list.

A simple /etc/host/allow file is shown in Example A. In this example, access to in.ftpd is allowed from any host on the 10.28.3.0 network and the 192.168.2.14 subnetwork.

Telnet access is allowed for any host in the .finance.bigbank.com subdomain. Finger requests are accepted only from the list of hosts shown.

Example A: A simple /etc/hosts.allow file#
# 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.
#

in ftpd: 10.28.3,192.168.14.0/255.255.255.0
in telnetd: .finance.bigbank.com
in.fingerd finance1, finance2, admin,

Example B shows a simple /etc/hosts.deny file. The ALL:ALL line in this file will deny all access that is not explicitly allowed in the /etc/hosts.allow file.

Example B: A simple /etc/hosts.deny file#
# 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.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow. In particular
# you should know that NFS uses portmap!

ALL:ALL

These two files work together to form a complete set of restrictions imposed on all services invoked through tcpd. All lines beginning with # are comments and are ignored by tcpd, as are all blank lines. The syntax when creating entries (also called rules) for these files is
daemon [,daemon,...] : client[client[,client,...] [: option : option ...]
The use of these options is possible only when the -DPROCESS_OPTIONS flag is used when compiling TCP_wrappers. If this flag is not set when compiling, the syntax becomesdaemon[,daemon,...]: client[,client,...][: shell_command]
where shell_command is any single shell command.

• In either file, the daemon listed must precisely match a daemon as it is entered in /etc/inetd.conf, and the daemon must be run through tcpd.
• Commas must separate multiple daemons on the same line.
• After the daemon list, a colon (:) must appear, followed by a comma-separated list of clients. If a comma follows the client list, it specifies optional keywords.
• A colon delimits each keyword.

Table B shows the syntax used to specify clients in the /etc allow and deny files.


Table C lists the optional keywords used in allow and deny files.


Using variables in allow and deny files
Several of the options in Table C use information gathered by the TCP wrapping daemon, tcpd. This information is utilized via any of the variables from a predefined set. The information to be used is specified by letters, preceded by a percent (%) sign. These variables are listed in Table D.


Turning off all access to wrapped services
The tcpd program stops when it finds a client/daemon match. Access is granted when a matching pair is found in /etc/hosts.allow, and access is denied if a matching pair is found in /etc/host.deny. Under any other circumstances, access is allowed. This means that the deny file must be configured correctly, because the default for this file is to allow access unless it is specifically directed not to. If neither file exists, however, all wrapped daemons will be denied access. This makes it possible to deny all access, except for the localhost, by simply renaming the allow and deny files.

Using wildcards in allow and deny files
Table E lists wildcards that may be used in allow and deny files.


Using banners with TCP_wrappers
Banners are used to display a message to anyone trying to connect to a system prior to logging in. This is accomplished by using the BANNERS option in either the allow file or the deny file or both. Example C shows an entry in the /etc/hosts.allow file for the telnet server, in.telnetd.

Example C: BANNERS entry for ftpd in /etc/hosts.allow#
# 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.
#
in.ftpd:      10.28.3,192.168.14.0/255.255.255.0
in.telnetd:   .finance.bigbank.com : banners /etc/security/banners/allow
in.fingerd    finance1, finance2, admin,

When tcpd reads the hosts.allow file, it will look for the file /etc/security/banners/allow, and the contents of this file will be displayed before the login prompt.

A sample banner file for in.telnetd is shown in Example D. This file may be created with any text editor. The contents are a combination of text and the variables listed in Table D.

Example D: Sample banner file for in.telnetd#in.telnetd BANNER message
Welcome to %H
You are logging from %c
The date, time, and duration of your login
are recorded.
If you don't agree with this policy,
please don't log in.

Using the banners Makefile
TCP_wrappers also includes a Makefile that may be used to create banner files. On Red Hat systems, the location of this file is /usr/doc/tcp_wrappers-7.6/banners.Makefile. If you’re using a downloaded version of TCP_wrappers, the Makefile is located in the tcp_wrappers_7.6 subdirectory. In either case, copy Banners.Makefile to the banners directory. For this Daily Drill Down, we’ll use /etc/security/banners.allow for the allow message files and /etc/security/banners.deny for the deny message files. Below is a listing of the commands used to complete these steps:
cd /usr/doc/tcp_wrappers-7.6 OR cd /usr/src/tcp_wrappers_7.6
cp Banners.makefile /etc/security/banners/allow/Makefile
cp Banners.makefile /etc/security/banners/allow/Makefile

Once these files are copied to the appropriate directory, create a prototype file in the allow and deny subdirectories, using any text editor.

A prototype file is used to provide input when the make command is used to generate banner messages. Example E shows a typical prototype message.

Example E: A typical prototype file#Allow prototype
Welcome, @u@h
You are attempting to connect to @d
Please note that your login time and your activities while logged in
are recorded.
Logging in signifies acceptance of these conditions.

By adding an entry like the one in Example F to the /etc/hosts.allow file, this message will be displayed whenever a login to the ftp daemon is attempted.

Example F: Banner entry in the /etc/hosts.allow filein.ftpd: ALL: banners /etc/security/banners/allow

An entry like the one in Example G might be used to run a banner message when a connection to the FTP server is refused.

Example G: Banner entry in the /etc/hosts.deny file#Deny prototype
Login denied from %h
%d does not allow access from %
This login attempt will be logged.

Now when a login is attempted from an unauthorized host, the message will be produced in the /var/log/secure file.

You may also require banner messages for clients whose IP address or hostname cannot be resolved. A common way to accomplish this is to place an entry like the one in Example H in the /etc/hosts.deny file.

Example H: Setting a banner message for UNKNOWN hostALL: UNKNOWN: banners /etc/security banners/unknown

This entry will cause a message to be displayed whenever a hostname or IP address cannot be resolved.
Banners do not work with UDP services or with certain TCP services such as in.rshd or in.talkd.
Using spawn to set traps for crackers
The spawn command is used to execute shell commands from within a TCP_wrappers rule. One of the best uses for spawn is to execute the safe_finger program.

The safe_finger program is included with the TCP_wrappers package. Safe_finger is used to protect your server against finger probes. The security measures used by safe_finger include:

• Setting limits on the amount of data accepted.
• Implementing time-out limits.
• Setting limits on the maximum line length accepted.

The safe_finger program uses the same arguments as finger. Safe_finger is used to get more information from whoever is trying to connect to your server. If the client requesting a connection responds to a safe-finger probe, the output from this probe may be piped to any log file, creating a record of login attempts.

The TCP_wrappers documentation refers to this procedure as setting a booby trap. Example I shows an entry made in the /etc/hosts.deny file. This entry will activate safe_finger and then pipe the output from safe_finger to a mail message, which is sent to root.

Example I: Using spawn to execute safe_finger from /etc/hosts.denyALL EXCEPT in.fingerd: ALL: spawn 9/usr/sbin/safe_finger -lp @%h |
/bin/mail -s "Login attempted from %h using %d" root &:\
banners /etc/security/banners/deny

Notice that the entry on the first line states
ALL EXCEPT in.fingerd

This prevents the server from responding to incoming finger attempts, which in turn prevents infinite finger loops. These can occur when the client responds with its own finger attempt.

Because spawn will allow any shell command to be executed, there are many actions that any rule can invoke. These include:

• Replacing the execution of /bin/mail with a script that logs the connection attempts made by a particular user.
• Shutting down a service.
• Automatically informing root of login attempts via /bin/mail.

Using twist
The twist function in TCP_wrappers is used to execute a daemon or command other than the one specified in /etc/inetd.conf. If /etc/inetd.conf contains an entry like the following:
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -a -1

then /usr/sbin/in.ftpd will be executed whenever a successful login occurs. Often, the system security policy will require all systems to run inetd, but the requirement for internal access to FTP servers is also recognized. Using TCP_wrappers to take action depending on whether or not a user is known to the system satisfies this requirement. The/etc/hosts.allow file shown in Example J shows how twist may be used.

Example J: Using twist in /etc/hosts.allow#/etc/hosts.allow

in.ftpd:KNOWN@KNOWN
Section 1
in.ftpd: UNKNOWN@KNOWN :banners \
       /etc/security/banners/deny: spawn (bin/echo "Unauthorized Login attempt")\
       | /bin/mail -s "%h "is not using identd" root@H,root@h)&:\
       twist PATH=/usr/sbin/safe;exec in.ftpd -i -o –l
Section 2
in.ftpd: PARANOID: banners /etc/security/banners/deny/paranoid:\
       spawn (/bin/echo "n discovered from %u@%h trying to connect using %d" | \
       /bin/mail -s "Alert ! Hostname Lookup Failure!" root@%H)& :deny
Section 3
in.ftpd: ALL: deny

Now, let's look at how this file functions.

Section 1

• The first uncommented line, in.ftpd: KNOWN@KNOWN, applies to both rules. This line provides a match only if the hostname and IP address are known. This option forces a reverse lookup, regardless of how TCP_wrappers was compiled. When an incoming FTP login request occurs, tcpd will execute an RFC931 call to confirm the name of the user attempting to log in. If the RFC931 call is successful, then in.ftpd is executed from the source directory specified in the Makefile when TCP_wrappers was compiled.
• If the username is unknown, the connection is allowed, but a banner message is displayed, stating that the client is not using identd.
• A message is then e-mailed to root on both the server and the client, informing them of a security violation.
• Twist is then used to execute /usr/sbin/safe/in.ftpd, instead of the normal FTP daemon, /usr/sbin/in.ftpd.

Section 2

• If the reverse lookup of IP address to hostname does not match the forward lookup of hostname to IP address, then the client is classified as PARANOID.
• tcpd then displays a banner message and e-mails a message to root, announcing the problem.
• Access is then denied by the deny keyword.
• PARANOID reports will often occur as a result of network problems, but they should always be investigated.

Section 3

This line denies access under all other circumstances.

Putting all TCP_wrappers rules in one file
Using the deny option allows administrators to use a single file for access control. This approach works best when the rules being implemented are fairly simple.

Example K shows a single-file access control list. This example uses /etc/hosts.allow. Using the keyword LOCAL in this file provides a match for any host that does not have a period (.) in its hostname. The last line denies access under all other circumstances.

Example K: Using a single /etc/hosts.allow file for access control#/etc/hosts.allow file

in.ftpd: KNOWN@LOCAL: banners /etc/security/banners/allow
in.telnetd: KNOWN@LOCAL: banners /etc/security/banners/allow
ALL: ALL: banners /etc/security/banners/deny: deny
As your rules grow more complex, it’s probably a good idea to keep rules for deny and allow in separate files.
Using TCP_wrappers with multiple network interfaces
When multiple network interfaces are employed on a server, TCP_wrappers may be used to control daemon execution based on the IP address of the interface being used for a request. Example L demonstrates a simple implementation of this procedure, using the syntax
server@IPaddress

Example L: Using TCP_wrappers with multiple network interfaces#/etc/hosts.allow
in.ftpd@192.168.1.100:     ALL EXCEPT .ScriptKiddie.com: twist in.ftpd
in.ftpd@192.168.2.100:     ALL EXCEPT .ScriptKiddie.com: twist in.wuftpd
EXCEPT cannot be used with network number in client lists 192.168. EXCEPT 192.168.1.30 will not work.
Creating the /etc/hosts.allow and /etc/hosts.deny files
Creating these files takes a lot of planning. The easiest way to simplify the process is to use a systematic approach to security. Here are some guidelines to use when deploying TCP_wrappers:

• First, learn what the system is expected to do for its users. Make a list of required services and a list of clients who will use these services.
• When in doubt, deny a service—you can always add it later.
• Remember that tcpd stops when the first match is made, so the order of rules in these files is important.
• Plan on providing more security around FTP. This service is a very common source of security breaches.
• If possible, create a firewall system or a demilitarized zone (DMZ). You may then leave any services that are likely to be attacked open on this server and booby-trap them with TCP_wrappers.
• When processes such as in.ftpd and in.rlogind are left open, the /etc/syslog.conf file may be configured to generate log messages for activity associated with these services. These logs can then be analyzed with a separate utility such as logcheck or swatch.

TCP_wrappers utilities
There are three utility programs included with each TCP_wrappers distribution:

• tcpdchk
• tcpdmatch
• try-from

tcpdchk
tcpdchk is used to check the syntax of the /etc/hosts.allow and /etc/hosts.deny files. tcpdchk should always be run when you first create these files and whenever they are modified. Table F lists the flags used with tcpdchk.


tcpdmatch
tcpdmatch checks a service/client pair and checks the rules applied to this pair for a match. Access is allowed or denied, depending on the resolution. This program is useful for checking modifications made to the allow and deny files.

try-from
The try-from utility tests the hostname and username lookup process. Running try-from involves setting up an entry in either the allow or deny file and then making an entry in /etc/hosts.equiv or the $HOME/.rhosts file on the server. Ensure that rsh is closed after the tests are performed.

Potential security breaches with TCP_wrappers
Other programs it relies on to function, such as DNS and identd, usually cause potential security holes related to TCP_wrappers. Here are some possible problems:

• ·          The identd daemon on a remote system may give false data.
• ·          If DNS names and IP addresses are spoofed, then TCP_wrappers will not be able to detect a PARANOID condition.
• ·          If the server running TCP_wrappers is breached, then there is no defense.
• ·          DoS (Denial of Service) attacks can overwhelm the logging facility.

Summary
TCP_wrappers should be in every system administrator's toolkit. This program is a very flexible tool for system security. In this Daily Drill Down, we discussed the installation of TCP_wrappers and the procedures to follow when creating rules for TCP_wrappers on your own system. We also discussed potential security problems with TCP_wrappers and examined some utilities used to test a TCP_wrappers installation.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Print/View all Posts Comments on this article

real ****!conejo-estylo@...  | 05/28/01