Linux

Securing Linux network services with TCP_wrappers

This Daily Drill Down focuses on the process of installing and configuring the <I>tcpd</I> service on a Linux server. It also shows you how you can allow and deny access to <I>inetd</I>-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.
Table A: Compile-time options for TCP_wrappers
Option
Function
Red Hat default
REAL_DAEMON_DIR Full path to the directory where the network daemons are located. /usr/sbin
TLI Used to activate System V.4-style Transport Layer Interface (TLI) support. No
RANLIB Sets up an index for faster library linking. Default
ARFLAGS Specifies the flags to use with ar. Default
AR Creates, modifies, and extracts archives, or libraries. None
AUX_OBJ Specifies additional objects for linking. None
Strings Specifies various string-manipulation routines. No
LIBS Specifies object libraries to include at linktime. None
SYSTYPE Sets system-specific compiler options. None
BUGS Specifies macros that provide solutions to known system bugs. Default
NETGROUP Specifies the use of NIS netgroups. Select this option when using netgroups. No
VSYSLOG Use this option if your system supports the vsyslog function calls. Turned on by default, this option will not create problems if your system does not use vsyslog function calls. Yes
STYLE Activates language extensions as described in the host_options man page. Uses the macro PROCESS_OPTIONS. Yes
FACILITY Specifies the syslog facility used for logging. Default is LOG_MAIL, as specified in /etc/syslog.conf. LOG_AUTHPRIV
SEVERITY The syslog level. Default is LOG_INFO, as specified in /etc/syslog.conf. Default
DOT Appends a "." to all hostnames to reduce DNS search time. Red Hat enables this feature, so if you’re not using DNS, you should deactivate it and recompile. Yes
AUTH Always attempt to look up a remote hostname with an RFC931 call. The default is off. This allows RFC931 calls to be made when required by access control files. No
RFC931_TIMEOUT Sets the default timeout for RFC931 queries to 10 seconds. Default
UNAMSK Sets the umask for processes run under tcpd. The default is 022. Default
ACCESS Enables host access control. The default is on.  

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 B: Syntax used in /etc.allow and /etc.deny
Syntax
Function
Hostname Specifies the hostname or IP address of the system. When the hostname is used, it must be resolved to an IP address through /etc/hosts, DNS, or NIS.
.domain This syntax assumes DNS. Any hostname that resolves to hostname .domain is given access. For example, if .domain is .techrepublic.com, then any host in the domain techrepublic.com is given access.
net_number This syntax allows partial matching of IP addresses. For example, if net_number. is 146.14, then any IP address beginning with 146.14 is given access, regardless of the subnet mask (netmask) being used.
@netgroup The @ indicates that a netgroup is being specified. This allows access for every hostname in that netgroup. Netgroups are used only to match clients.
net_number/ netmask This entry is used to specify subnetworks (subnets). For example, 146.14.16.0/255.255.240.0 will match all the IP addresses from 146.14.16.0 to 146.31.255, inclusive.

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

Table C: Optional keywords used in allow and deny files
Keyword
Function
nice value Specifies the nice value for a process.
keepalive Used to periodically send messages from the server to the client. If there is no response from the client, the connection is assumed to be broken and is terminated. Used for TCP services only.
linger seconds Specifies how long a server will attempt to send undelivered data after a connection is terminated.
facility.level Severity Allows the syslogd logging daemon to place log messages in various locations. Red Hat normally logs to auth_prov.info. This option allows you to change both the facility and the level. If this option is used, an entry may be required in /etc /syslog.conf for the change to take effect.
allow deny Enables the use of ALLOW and DENY rules in the same file. Discussed in more detail later in this Daily Drill Down.
spawn Executes the specified shell command as a child process.
twist Executes the specified shell command as a replacement process for the process specified in the last field in the /etc/inetd.conf file.
rfc931 seconds Allows the server to execute a call to the client to obtain the username making the request. A timeout for the call is specified in seconds. The default is 10 seconds.
banners dir Specifies the PATH to a directory that contains the BANNER files for each daemon wrapped by tcpd. These banners are normally a security advisory, displayed prior to the login prompt. Banners are usable only with TCP services.
setting var Allows a shell environment to be created or modified. Usually followed by the SPAWN option.
umask value Sets the umask value for operations in a rule.
user Allows privileges set by a rule to be set to the specified user and the specified group.

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.

Table D: Variables used in allow and deny files
Variable
Function
%a Client IP address
%A Server IP address
%c user@host, user@IPaddress, hostname, or IPaddress
%d Daemon name
%h Client hostname or IP address
%H Server hostname or IP address
%n Client hostname. Resolves to unknown if host is unknown and to PARANOID if the hostname provided by DNS does not match the hostname being used by the client.
%N Server hostname
%p Process ID (PID) for the daemon
%s daemon name, daemon@host, or daemon@IPaddress, depending on availability
%u Client username
%% Represents %

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.

Table E: Wildcard characters for use in allow and deny files
Wildcard
Function
ALL Matches everything.
LOCAL Matches any hostname that does not contain a period (.).
KNOWN Matches any user whose username is known.
UNKNOWN Matches any user whose username is unknown.
PARANOID Matches any host showing a hostname/IPaddress mismatch. If the option –DPARANOID is used when TCP_wrappers is compiled, all connections with a hostname/IP address mismatch are dropped. By default, the Red Hat implementation of TCP_wrappers does not compile with this option.
EXCEPT An operator that may be used in daemon or client lists.

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.

    Table F: Flags used with tcpdchk
    Flag
    Function
    -a Displays additional information if access is allowed without an allow keyword.
    -v Verbose output.
    -d Uses the allow and deny files in the current directory.
    -I Specifies a filename other than /etc/inetd.conf.

    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.
    0 comments