40.4. Objective 5: TCP WrappersTCP wrappers allows you to check the origin of a connection when another machine connects to your own, because you may not want to talk to that machine. Using the /etc/hosts.allow and /etc/hosts.deny configuration files, you can specify who can and cannot use specific services. TCP wrappers is most commonly used to protect services that are controlled by inetd, but other services such as SSH and the portmapper, as well as most of the NFS service suite, also respect the settings. If you use xinetd instead of inetd, there is another way to restrict access, described later in this Objective. To activate checks by TCP wrappers of access to services, make sure that your /etc/inetd.conf has tcpd in the command line, as shown here: ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/vsftpd When a connection request arrives at a service guarded by TCP wrappers, the request origin and the service name will be checked against the contents of /etc/hosts.allow and /etc/hosts.deny. The checking works as follows:
40.4.1. /etc/hosts.allow and /etc/hosts.denyThe entries in the /etc/hosts.allow and /etc/hosts.deny files have the general syntax of service: granted_to, where service specifies the name of the service and granted_to specifies which hosts have permission to use the service. 40.4.1.1. Specifying servicesWhen specifying a service to provide access to, you have the option of specifying the particular service, such as ftpd, or to specify all services. To specify a particular service, just insert its name. Unfortunately, some services use names you didn't quite expect. When TCP wrappers is invoked from inetd, the service name is always the same as the executable name. ALL matches all services. To grant access to a service, such as ftpd, to everyone on your local 10.0.0.x network, you need an entry in your /etc/hosts.allow file that looks like this: vsftpd: 10.0.0.0/255.255.255.0. With this entry, TCP wrappers will allow access to a vsftpd daemon connecting from any IP in the subnet. To grant access to all services from your network, simply put ALL as the service name. When granting or denying access to a service to a host, you have the option of specifying a specific domain, an IP address, a range of IP addresses, or all hosts. In addition, you can use an EXCEPT argument that allows you to single out domains and IP addresses from which you want to withhold access. To specify all services' access to a specific domain, such as lpi.org, use the first entry in the following example. With this entry, any host in lpi.org can access all available services on your machine. To specify an additional domain, such as oreilly.com, you can just add the second line of the example. ALL: .lpi.org ALL: .oreilly.com Or put the two together: ALL: .lpi.org, .oreilly.com To specify permission to all services to a specific IP address such as 10.0.0.1, use ALL: 10.0.0.1. With this entry, users from 10.0.0.1 can access all services on the machine. To specify an additional IP address, separate them with commas as just shown. To specify permission to all services to all users, use ALL: ALL. You can specify EXCEPT cases with any of the previously mentioned arrangements. For instance, ALL: ALL EXCEPT 10.0.0.5 would grant access to everyone but the host at 10.0.0.5. In addition, ALL: ALL EXCEPT .redhat.com grants access to all except anyone connecting from a system on the redhat.com domain. An additional use of EXCEPT is in the services specification ALL EXCEPT vsftpd: ALL. Any combination of services and hosts can be used in these files. A sample /etc/hosts.allow file follows: # # hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # vsftpd:ALL EXCEPT 10.28.2.23, 10.28.0.1 in.telnetd: .example.com lockd: fileserver.example.com statd: fileserver.example.com, localhost The following is a reasonable /etc/hosts.deny that bars all other access to the services granted in the allow file, and makes TCP wrappers paranoid about the rest. PARANOID makes TCP wrappers check the reverse lookup of an incoming connection based on the IP address. The name obtained is then checked in a forward lookup. If TCP wrappers gets back the same IP address as it started with, the host passes the PARANOID check. ALL: PARANOID statd: ALL lockd: ALL in.telnetd: ALL vsftpd: ALL By default, TCP wrappers is actually compiled to default all checks to PARANOID in such a way that it cannot be disabled. For this reason, it's very important to keep your DNS forward and reverse databases consistent. 40.4.1.2. xinetd and access controlxinetd was introduced in Chapter 20. It is used by some distributions, among them Red Hat. It has the functionality of TCP wrappers built in, with a different user interface. The xinetd daemon is configured in /etc/xinetd.conf or perhaps by several files in /etc/xinetd.d. A typical stanza for a service looks like this: service rsync { disable = no socket_type = stream wait = no user = root server = /usr/bin/rsync server_args = --daemon --server . log_on_failure += USERID } Two keywords can be added for access restrictions by host: only_from grants exclusive access to the enumerated hosts and nets, whereas no_access excludes the enumerated hosts and nets. If neither keyword is present for a service, all hosts get access. If both are present, the most specific match gets priority. Thus, given this configuration: service rsync { disable = no socket_type = stream wait = no user = root server = /usr/bin/rsync server_args = --daemon --server . log_on_failure += USERID no_access = 10.0.0.0/16 only_from = 0.0.0.0/0, 10.0.0.0/24 } everyone on the whole Internet gets access, excluding anyone from the 10.0.x.x network, but the 10.0.0.x network on the other hand gets access. That is because 10.0.0.x is more specific than the others, and 10.0.0.0/16 is more specific than 0.0.0.0/0. These two keywords accept host specifications in many different formats:
|