Wrap a Security Blanket Around Your Computer

TCP_wrappers provide a simple, elegant and effective means to safeguard your network services.
Tracking Usage with Wrappers

TCP_wrappers write a message into your system logs every time a connection is requested, whether it is granted access or not. These entries in the logs above are reason enough to have TCP_wrappers installed on your system. The messages are written through the standard syslog facility and by default go to the same place as mail transactions. On my Linux distribution, Caldera Network Desktop based on Red Hat Linux, the default has been changed so that the messages are written to the same log file as other daemons (LOG_DAEMON facility).

In any event, when someone accesses my machine via telnet, a message like this is placed in the /var/log/messages:

Apr  9 17:24:58 ads in.telnetd[15339]: connect from somewhere.else.com

If the connection was refused, the message would read:

Apr  9 17:25:15 ads in.telnetd[15604]: refused connect from someother.place.com
If I want to see all the telnet attempts in my log, I can simply type the command:
grep telnetd /var/log/messages
TCP_wrappers can give me even more information through the use of “booby traps”. TCP_wrappers can be configured to run shell commands when certain services are requested. Let's assume I have reason to suspect someone at nasty.badguy.com is trying to use the Trivial FTP program (TFTP) to steal my password file. In my /etc/hosts.deny file, I can put the following line (this example is straight from the hosts_access(5) man page that comes with TCP_wrappers):
in.tftpd : nasty.bad-guy.com : ( /usr/sbin/safe_finger -l @%h |\
        /bin/mail -s %d->%h root) &
Access to TFTP is denied to all users from nasty.badguy.com. In addition, the command:
safe_finger @nasty.badguy.com
is run, and the results are piped into a mail message sent to the root user with the subject line:
in.tftpd->nasty.bad-guy.com
safe_finger is a command provided along with the TCP_wrappers that strips out any “bad” characters, like control sequences and data overruns. Running safe_finger @hostname generates a list of everyone currently logged into that system. The strings %h and %d are called expansions, and tcpd replaces them with the corresponding text for the host name and daemon process, respectively. Other expansions include %a for the client Internet address and %u for the client user name.

Now, this isn't a perfect solution, since our cracker friend may have disabled his finger service or altered it to give false information; however, this example does show us the power of the TCP_wrappers program.

Using Advanced Options

The access control language in the /etc/hosts.allow and /etc/hosts.deny files is quite simple, yet powerful, but TCP_wrappers can be compiled to include even more powerful extensions to the normal access controls. Instead of having the line:

service : host

in the configuration files, you can have the line:

service : host : option : option ...
Where option can be allow, deny or many other advanced options.

To enable the advanced options, compile the wrapper programs with the -DPROCESS_OPTIONS. The wrappers are compiled in this way by my Caldera/Red Hat distribution. To check your distribution for the advanced options, run tcpdchk<\!s>-a. On my system, I see the following output:

warning: /etc/hosts.allow, line 6: implicit "allow" at end of rule
warning: /etc/hosts.allow, line 7: my.isp.net: host not found
warning: /etc/hosts.allow, line 7: implicit "allow" at end of rule
warning: /etc/hosts.allow, line 8: implicit "allow" at end of rule

The message implicit<\!s>"allow" indicates my version of the wrappers is looking for additional options in the /etc/hosts.allow file. If your distribution does not have PROCESS_OPTIONS compiled in, you will not see this message.

Using the advanced options, we can do away with the /etc/hosts.deny file entirely, since the options for "allow" and "deny" can be added to any rule. We can change the logging level, control the priority (“niceness”) of the network service, look up user names with the RFC 931 “ident” protocol and display customized “banners” for each service.

More information on these advanced features can be found in the hosts_options(5) man page included with TCP_wrappers, or in the Garfinkel & Spafford book cited above (a must-read for anyone concerned with network security). For now, let's convert our /etc/hosts.allow and /etc/hosts.deny files to use the advanced options. The etc/hosts.deny file is no longer needed. In /etc/hosts.allow we rewrite the rules as follows:

ALL        : localhost               : allow
in.telnetd : my.isp.net              : allow
in.fingerd : ALL EXCEPT .cracker.org : allow
in.tftpd   : nasty.bad-guy.com       : spawn \
        (/usr/sbin/safe_finger -l @%h |\
        /bin/mail -s %d-%h root) &
                                     : deny
ALL        : ALL                     : deny

In English, this says the following:

  1. All services from our own machine are allowed.

  2. telnet is allowed from my.isp.net.

  3. finger is allowed from everywhere except hosts in the cracker.org domain.

  4. tftp is not allowed from nasty.badguy.com, and if they try, we will spring a “booby trap” to find the guilty party.

  5. All other services from everywhere else are denied.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix