Optional Access Control Language Extensions

If tcpd is compiled with PROCESS_OPTIONS enabled in the Makefile, the syntax of the access control language is changed and extended. The extended command syntax is not limited to three fields. The extended syntax is services : clients : option : option

The services field and the clients field are defined in exactly the same way as they were in the original Wrapper syntax. The option field is new and so is the fact that multiple options are allowed for each rule. There are several possible options:

allow Grants the requested service. This option must appear at the end of a rule.

deny Denies the requested service. This option must appear at the end of a rule.

spawn shell-command Executes the shell command as a child process.

twist shell-command Executes the shell command instead of the requested service.

keepalive Sends keepalive messages to the client. If the client does not respond, the connection is closed.

linger seconds Specifies how long to try to deliver data after the server closes the connection.

rfc931 [timeout] Uses the IDENT protocol to look up the client username. timeout defines how many seconds the server should wait for the client's response. The default timeout period is specified as a compiler option.

banners path Displays the contents of a message file to the client. path is the name of a directory that contains the banner files. The file displayed is the file that has the same name as the network daemon process.

nice [number] Sets the nice value for the network service process. The nice value is used to calculate a scheduling priority. The default value is 10.

umask mask Sets a umask value for files created by the process. The value defined by umask turns off bits in the default file mode to produce the new permission. For example, assuming that the default file mode is 0666 and the umask value is 022, removing the bits defined by 022 from 0666 produces a file permission of 0644.

user user[.group] Runs the network service process with the specified user ID and group ID regardless of what is defined in inetd.conf.

setenv name value Sets an environment variable for the process runtime environment.

A few examples based on previous examples illustrate the differences in the new syntax. Using the new syntax, a hosts.allow file might contain

ALL : LOCAL, .foobirds.org : ALLOW in.ftpd,in.telnetd : sr1.sybex.com : ALLOW ALL : ALL : DENY

With the new syntax, there is no need to have two files. The options ALLOW and DENY permit everything to be listed in a single file. The function of the first two lines is identical to the first host.allow example described earlier. The third line is the same as having the line ALL : ALL in the hosts.deny file. Everything done with the basic syntax can be done in a single file with the extended syntax.

Using the ALLOW and DENY options, this command

ALL: .foobirds.org EXCEPT crow.foobirds.org can be rewritten as

ALL: crow.foobirds.org : DENY ALL: .foobirds.org : ALLOW

The shell command example using the original syntax is almost identical in the new syntax:

in.rshd : ALL: spawn (safe_finger -l @%h | A/usr/sbin/mail -s %d - %h root) & : DENY

A more interesting variation on the shell command theme comes from using the twist option. Instead of passing a command to the shell for execution, the twist command executes a program for the client—but not the program the client expects. For example:

in.ftpd : ALL: twist /bin/echo 421 FTP not allowed from %h : DENY

In this case, when the remote system attempts to start the FTP daemon, echo is started instead. The echo program then sends the message to the remote system and terminates the connection.

Other programs, such as portmapper, use the host.allow and host.deny file. Not all of these programs understand the extended syntax. For this reason, most system administrators stick with the basic syntax. See the sidebar "Realistic Wrapper Rules" for an example of a common tcpd wrapper configuration.

Realistic Wrapper Rules

The most important thing you can do to secure your system is to keep the software up-to-date. This is essentially a passive activity—you depend on the software developer for the update. A more active approach to security is access control—it is something you can do even before problems are detected. The two basic rules you use to configure access controls are very simple:

• Don't provide service to anyone to whom you don't need to provide service.

These rules lead to the following simple tcpd configuration that is put on many ser-vers immediately after installing the system software. First, to prevent access from everyone in the outside world, make this entry in the /etc/hosts.deny file:

Next, make an entry in /etc/hosts.allow to permit access to the necessary services by clients in the local domain:

ALL : LOCAL, .foobirds.org

This example assumes that the local domain is foobirds.org and that this server provides all of its services to the local domain. This is often the case because unneeded software is either not installed or blocked from running. Therefore, all of the software left running on the server is intended to serve clients.

This simple configuration is effective against many attacks. Attack scripts look for simple targets, and they are often discouraged by the first sign of resistance. Of course, a skilled and determined attacker can find his way around any defense. Luckily, most of us don't really attract attacks from highly skilled people.

Was this article helpful?

0 0

Post a comment