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:
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.


White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState