Restricting Access with xinetd

Many of the xinetd access control tools mirror those in TCP Wrappers, although xinetd uses different names. You'll also find these controls spread across files, which can make it harder to review your system's overall security settings. On the other hand, xinetd offers a few security options that TCP Wrappers doesn't offer. Broadly speaking, the xinetd options fall into several categories:

Host and Network Access Restrictions You can use the only from and no_access options much as you would use entries in TCP Wrappers' /etc/hosts.allow and /etc/hosts.deny files, respectively. If you include an only_from line, though, all systems not explicitly listed are denied access. You can specify hosts by IP address, network address with or without netmask (as in 172.24.45.0 or 172.24.45.0/24), hostname, or a network name listed in /etc/networks. If you use a hostname, xinetd does a single hostname lookup whenever you start the server, so this option is likely to be unreliable if a client's IP address changes at all frequently. If a system matches both only_from and no_access lines, xinetd applies the rule associated with the more specific line. For instance, if only_from enables access from 172.24.45.0/24 and no_access denies access to 172.24.45.7, then 172.24.45.7 will not be able to access the system.

Interface Restrictions If your computer has multiple network interfaces, you can bind a server to just one of those interfaces with the bind or interface options, which are synonymous. These options take the IP address on the local computer associated with an interface as an option. For instance, bind = 172.24.45.7 ties the server to the interface with the 172.24.45.7 address. When you use this feature, xinetd doesn't even listen for connections on other interfaces, which can greatly enhance security; a miscreant can't take advantage of a bug, even in xinetd, if xinetd isn't listening on the interface the cracker is using.

Temporal Restrictions If you want a server to be available at some times of day but not others, you can configure temporal restrictions using the access_times feature. This keyword takes two times, separated by a dash (-), as an option. The times are specified in 24-hour format. For instance, access_times = 07:30-18:00 restricts the server's availability to between 7:30 a.m. and 6:00 p.m. This restriction applies to the original connection; users can continue using the server past the curfew period. For instance, if a user logs into a Telnet server that's restricted to 7:30 a.m. to 6:00 p.m. at 5:57 p.m., the person could remain connected well past 6:00 p.m.

As a general rule, xinetd can be an improvement over TCP Wrappers on systems with multiple network interfaces or if you want to implement temporal restrictions. The host-based restrictions in xinetd are slightly less sophisticated than those in TCP Wrappers, but for the most part you can accomplish the same goals with either system. If your distribution uses xinetd but you find you must use a TCP Wrappers feature, you can use TCP Wrappers in conjunction with xinetd, much as you can use TCP Wrappers with inetd. Specifically, you use server = /usr/sbin/tcpd to get xinetd to call TCP Wrappers; then pass the server name and arguments on the server_args

Team LIB

Team LiB

^ previous

0 0

Post a comment