Controlling Access with TCP Wrappers | Building Tablet PC Applications (Pro-Developer)

The best way to protect your system from crackers is to disable or uninstall as many services as possible. For example, a cracker can t use the telnet command to break into your computer if you don t have the Telnet server RPM installed.

If don t need an xinetd service immediately, one option is to deactivate it in the /etc/xinetd.d directory. In most cases, it s sufficient to leave all but required services disabled in the associated configuration files.

But some users need to get to their e-mail when they re in remote locations, and some need Telnet. For those who need access to larger files from remote locations, FTP servers are still the most effective way to transfer files over the Internet.

You can configure access control to all of these services using TCP Wrappers.

Regulating Access

You can minimize risks to your Linux computer in two different ways. First, you can regulate users and/or computers allowed to access a service through its configuration files, some of which are located in the /etc/xinetd.d directory. Other files are associated with different services and we address them in later chapters. Alternatively, you can use TCP Wrappers to regulate computer access through the /etc/ hosts .allow and /etc/hosts.deny files.

You can add various rules to these files. These rules are read in the following order:

TCP Wrappers reads the /etc/hosts.allow file. If access is explicitly allowed, access is granted.
TCP Wrappers reads the /etc/hosts.deny file. If access is explicitly denied , users from the specified computer are not allowed to start the service.
If the computer or IP address is not found in either file, access is automatically granted, and xinetd starts the service.
If the computer or IP address is found in both files, the rule in /etc/hosts.allow comes first.

For example, if you configure rules that explicitly open a service to computer A in /etc/hosts .allow and then denies it in /etc/hosts.deny , computer A gets access.

In addition, any changes that you save to either file take effect immediately. You don t need to restart or reload the xinetd daemon.

The xinetd Firewall

A specific type of syntax is associated with /etc/hosts.allow and /etc/hosts.deny . First, as with other scripts, blank lines and comments that start with a # are not read. Each command line in these files should follow this configuration:

  daemon  :  client  : spawn  command

In other words, when you specify a server daemon, you can associate it with a group of hostnames or IP addresses. When there is a match, you can also trigger a command, such as a message to the user or a log entry.

The simplest version of this command line is

 ALL: ALL

which applies to all xinetd daemons and all computers. The options are complex, so it s easiest to examine the options one at a time.

TCP Wrapper Daemons

You can specify individual daemons, but keep in mind that the name of the daemon may not be what you expect. For example, the name of the Telnet daemon is in.telnetd .

If you want to specify multiple daemons, just cite them together and separate the names of the daemons with a space. For example, the following line in /etc/hosts.deny blocks access to local Telnet and RSH servers to all users:

 in.telnetd in.rshd: ALL

If in doubt on daemon names, refer to the configuration file in the /etc/xinetd.d directory. Each of these files includes the name of the daemon as the server variable.

TCP Wrapper Clients

You can specify the names of different computers, or client names, in TCP Wrappers commands by host or by IP address. Several wildcard parameters are available as well.

There are several ways to specify hostnames. You can specify them one at a time; for example, the following command prevents access to local RSH and Telnet servers from the computers named sugaree and delilah:

 in.rshd in.telnetd: sugaree delilah

Or you can specify the fully qualified domain name (FQDN) of a computer, such as sugaree .mommabears.com . Wildcards are allowed with FQDNs; for example, just include the leading dot in .mommabears.com to apply the rule to all computers on the mommabears.com network.

It s possible to specify different computers; for example, the following line applies the rule to all computers on the mommabears.com network except delilah.mommabears.com :

 in.rshd: .mommabears.com EXCEPT delilah.mommabears.com

You can apply these principles to IP addresses; for example, the following line applies the rule to all computers on the 192.168.0.0 network except 192.168.0.102. Note the trailing dot in 192.168.0.; it applies to all computers with IP addresses between 192.168.0.0 and 192.168.0.255:

 in.rshd: 192.168.0. EXCEPT 192.168.0.102

Note	CIDR notation such as 192.168.0.0/24 does not work in the /etc/hosts.allow or /etc/hosts .deny files .

Table 23.3 lists the wildcards that can be used in place of hostnames, FQDN, or IP addresses. They are fairly self-explanatory.

Table 23.3: TCP Wrapper Wildcards
Wildcard	Application
ALL	All computers, including the localhost.
EXCEPT	Exceptions to the rule.
KNOWN	Known computers ”e.g., from DNS or /etc/hosts .
LOCAL	Computers with a single hostname; the name can t include a dot.
PARANOID	Computers where the hostname or FQDN does not match the IP address.
UNKNOWN	Computers not in the /etc/hosts or DNS databases.

TCP Wrappers Commands

Normally, all attempts to start an xinetd service are automatically added to /var/log/messages . You can use the spawn command to run another shell command as well. For example, use the following command to send an alert e-mail to the noted address:

 in.telnetd: ALL: spawn /bin/mail -s "Telnet security alert" mj@example.com

Another common use is to send a special message to a log file in /var/log that identifies the date and time when someone tried to access the service.