Restricting Access with TCP Wrappers

The formats for both /etc/hosts.allow and /etc/hosts.deny are identical, although the same entry has opposite effects in the two control files. The general format for these entries is as follows:

service-names : client-list [: shell-command ]

The service-names may be one server name, such as in.ftpd or in.telnetd; or it may be several names, separated by commas or spaces. You can also use the ALL keyword, which stands for all services. The optional shell-command is a command you can run when access is attempted. You can use this feature to mail a notification to an address, present a failure message on the port, or take some other action.

The client-list is potentially much more complex than the service-names. As with the service-names, the client-list may be a single entry or many, separated by commas or spaces. You can specify clients in any of several different ways:

IP Address You can provide a single IP address, such as 172.24.45.102, to block or allow access from that IP address.

IP Address Range If you want to block or allow access by an entire network based on its IP address range, you can do so. The simplest approach is to provide a partial IP address (ending in a dot), such as 172.24.45., which matches all systems in the 172.24.45.0/24 subnet. You can also provide the complete network address and add the number of bits or a complete netmask after a slash, as in 172.24.45.0/24 or 172.24.45.0/255.255.255.0.

Hostname If you don't want to use IP addresses, you can block or authorize an individual computer by providing its hostname, as in trex.pangaea.edu. This approach is riskier than using an IP address, though, because it relies on a successful and accurate DNS lookup. If a cracker compromises your (or potentially even somebody else's) DNS server or if your DNS server goes down, the TCP Wrappers rules may not work as you expect.

Domain Name To block or authorize access based on a domain name, you list the domain name preceded by a dot. For instance, .pangaea.edu blocks or authorizes all computers in the pangaea.edu domain. As with hostname authentication, this approach is dependent upon accurate and reliable DNS resolution.

NIS Netgroup Name If your network runs a Network Information Services (NIS) netgroup server, you can specify an NIS netgroup name by preceding it with an at sign (@). As with hostname and domain name specifications, this approach puts your system at the mercy of another system—in this case, the NIS server.

Wildcards You can use any of several wildcards that match particular groups of computers. Examples of wildcards include ALL (all computers), LOCAL (all computers whose hostnames resolve without dots—normally those on the same domain as the server), UNKNOWN (computers whose hostnames or IP addresses aren't known, or users whose names can't be verified via identd), KNOWN (computers whose hostnames and IP addresses are known, and users whose names are returned by a client's identd server), and PARANOID (systems whose hostnames and IP addresses don't match). All of these options except for ALL are somewhat risky because they depend upon proper DNS functioning.

Usernames You can match individual users by preceding a hostname or IP address by the username and an at sign, as in [email protected].

In addition to these rules, you can use the EXCEPT keyword to create a list with exceptions. For instance, 172.24.45.0/24 EXCEPT 172.24.45.72 excludes 172.24.45.72 from the client list.

As an example of several of these rules in operation, consider Listing 20.3, which shows a sample /etc/hosts.allow file. This file should be used in conjunction with an /etc/hosts.deny file that restricts access for some or all servers. If Listing 20.3 were used with an empty hosts.deny file, it would have no effect, because no systems would be denied access.

Listing 20.3: A Sample /etc/hosts.allow File in.telnetd : 172.24.45.2 trex.pangaea.edu vsftpd : 172.24.45. EXCEPT 172.24.45.1 imapd : .pangaea.edu EXCEPT router.pangaea.edu ipop3d : [email protected]

If used in conjunction with a very restrictive /etc/hosts/deny file (say, one containing the line ALL : ALL), Listing 20.3 grants access to only four servers, and it allows only a few hosts to access those services:

Telnet The in.telnetd line tells the system to accept Telnet connections only from 172.24.45.2 and trex.pangaea.edu. Presumably, these are local hosts for which Telnet's risks are minor.

FTP The vsftpd line tells TCP Wrappers to accept FTP connections from every computer on the 172.24.45.0/24 network except for

172.24.45.1. Perhaps 172.24.45.1 is a router or some other host that should never need to use an FTP client.

I MAP The Internet Message Access Protocol (IMAP) is a mail retrieval protocol, and the imapd line restricts access to this protocol. All the computers in the pangaea.edu domain exceptforrouter.pangaea.edu may access this server.

POP The ipop3d line enables [email protected] to use the Post Office Protocol (POP) to retrieve e-mail. Other users of that system and users of other systems (even sue on other systems) can't access the ipop3d server.

Warning Remember that TCP Wrappers protects only those servers that use its features. Many servers aren't launched through inetd and don't use TCP Wrappers.

TCP Wrappers provides more features than I can present here, and some of its features can have very subtle effects. For this reason, you should thoroughly test any /etc/hosts.allow and /etc/hosts.deny files you create. If you have problems, type man 5 hosts_access to read the official documentation on the TCP Wrappers control file format.

Team LiB

1 previous

Team LIB

^ previous

0 0

Post a comment