Certification Objective 15.01-Using tcp_wrappers to Secure Services

A network is only as secure as the most open system in that network. Although no system can be 100-percent secure, there are certain basic host measures to enhance the security on any given system and, consequently, your network. When devising security measures, you should plan for two types of security violations: user accidents and break-ins.

Accidents happen because users lack adequate training or are unwilling to follow procedures. If security is too burdensome, productivity may suffer, and your users will try to get around your rules. Password rules are sometimes so rigorous, users end up writing their passwords on their desks.

When a cracker breaks in to your system, he or she may be looking for secrets such as credit card information. Others may just want to bring down your system. You can do several things to keep your network secure. Monitor Red Hat errata for the latest issues. Using yum, you can keep your Red Hat system updated with the latest packages.

On the Job 

Red Hat is moving away from up2date to yum. RHEL 5 still includes the Red Hat Network registration and management tools such as rhn_register and rhn_check. If you use Fedora Core 6 or a rebuild such as CentOS to prepare for the RHCE exam, the Red Hat Network is not available to you. Fortunately, knowledge of the Red Hat Network is not part of the publicly listed Red Hat exam requirements.

As you'll see later in this chapter, you can manage your computer's response to certain requests through the /etc/hosts.allow and /etc/hosts.deny files. You can set up protection within the kernel through firewalls based on iptables or ipchains. One simple way to promote security is to uninstall as many network access programs as possible.

Security by User or Host

The best way to prevent a cracker from using a service is to remove it completely from your Linux system. However, you may want to keep a service loaded because you're planning to use it in the near future.

You can achieve some measure of security by disabling or removing unused services in the /etc/xinetd.d and /etc/init.d directories. With the services you need, you can block access to specific users, computers, or even networks through the hosts.allow or hosts.deny files in the /etc directory. This system is known as tcp_wrappers, which is enabled by default, and is focused on protecting xinetd services described in Chapter 13.

When a system receives a network request for a service, it passes the request on to tcp_wrappers. This system logs the request and then checks its access rules. If there are no limits on the particular host or IP address, tcp_wrappers passes control back to the service.

The key files are hosts.allow and hosts.deny. The philosophy is fairly straightforward: users and clients listed in hosts.allow are allowed access; users and clients listed in hosts.deny are denied access. As users and/or clients may be listed in both files, the tcp_wrappers system takes the following steps:

  1. It searches /etc/hosts.allow. If tcp_wrappers finds a match, it grants access. No additional searches are required.

  2. It searches /etc/hosts.deny. If tcp_wrappers finds a match, it denies access.

  3. If the host isn't found in either file, access is automatically granted to the client.

You use the same access control language in both /etc/hosts.allow and /etc/hosts .deny to tell tcp_wrappers which clients to allow or deny. The basic format for commands in each file is as follows:

 daemon_list : client_list 

The simplest version of this format is


This specifies all services and makes the rule applicable to all hosts on all IP addresses. If you set this line in /etc/hosts.deny, access is prohibited to all services. However, you can create finer filters. For example, the following line in /etc/hosts .allow allows the client with an IP address of to connect to your system through Telnet:

 telnetd : 

The same line in /etc/hosts.deny would prevent the computer with that IP address from using Telnet to connect to your system. You can specify clients a number of different ways, as shown in Table 15-1.

Table 15-1: Sample Commands in /etc/hosts.allow and /etc/hosts.deny




Domain name. Since this domain name begins with a dot, it specifies all clients on the example.com domain.


IP address. Since this address ends with a dot, it specifies all clients with an IP address of 172.16.x.y.

IP network address with subnet mask. CIDR notation not recognized.


Any client, any daemon.


Applies to the specific user on the given computer.

As you can see in Table 15-1, there are two different types of wildcards. ALL can be used to represent any client or service, and the dot (.) specifies all hosts with the specified domain name or IP network address.

You can set up multiple services and addresses with commas. Exceptions are easy to make with the EXCEPT operator. Review the following example excerpt from a /etc/hosts.allow file:

 #hosts.allow ALL : .example.com telnetd : EXCEPT sshd, in.tftpd : 

The first line in this file is simply a comment. The next line opens ALL services to all computers in the example.com domain. The following line opens the Telnet service to any computer on the network, except the one with an IP address of Then the SSH and TFTP services are opened to the computer with an IP address of

The code that follows contains a hosts.deny file to see how lists can be built to control access:

 #hosts.deny ALL EXCEPT in.tftpd : .example.org telnetd : ALL EXCEPT ALL:ALL 

The first line in the hosts.deny file is a comment. The second line denies all services except TFTP to computers in the example.org domain. The third line states that the only computer allowed to access our Telnet server has an IP address of Finally, the last line is a blanket denial; all other computers are denied access to all services controlled by tcp_wrappers.

You can also use the twist or spawn command in /etc/hosts.allow or /etc/hosts.deny to access shell commands; they're primarily intended to send messages, track access, and log problems. For example, take the following line in a /etc/hosts.deny file:

 telnetd : .crack.org : twist /bin/echo Sorry %c, access denied 

This sends a customized error message for Telnet users on the crack.org domain. Different operators such as %c are described in Table 15-2. Some of these operators may be able to help you track the intruder.

Table 15-2: tcp_wrappers Operators






Client address


Client host name


Host address


Server host name


Client information


Process ID


Process name


Server information

Exercise 15-1: Configuring tcp_wrappers

image from book

In this exercise, you will use tcp_wrappers to control access to network resources. Since tcp_wrappers is enabled by default, you shouldn't have to make any modifications to installed services.

  1. Verify that you can telnet to the system using the address localhost. You may need to do several things first:

    1. Install the Kerberos Telnet service, from the krb5-workstation RPM.

    2. Activate the service with the chkconfig krb5-telnet on command.

    3. Allow telnet through any active firewall and SELinux service.

    4. Add the following line to /etc/hosts (substitute your computer's host name for rhel5l1). rhel5l1 localhost.localdomain localhost 

    5. Recognize that the Telnet service included with RHEL 5 does not allow root logins by default.

  2. Edit /etc/hosts.deny and add the following line (don't forget to write the file):

     ALL : ALL 

  3. What happens when you try to telnet to the address localhost?

  4. Edit /etc/hosts.allow and add the following line:

     telnetd : 

  5. Now what happens when you try to telnet to the address localhost?

  6. If you have other systems available to you, try restricting access to the Telnet service using some of the other tcp_wrappers rules.

  7. Undo your changes when finished.

image from book

RHCE Red Hat Certified Engineer Linux Study Guide (Exam RH302)
Linux Patch Management: Keeping Linux Systems Up To Date
ISBN: 0132366754
EAN: 2147483647
Year: 2004
Pages: 227
Authors: Michael Jang

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net