Section 40.4. Objective 5: TCP Wrappers


40.4. Objective 5: TCP Wrappers

TCP 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:

  1. Do the service and origin have a match in /etc/hosts.allow? If so, allow the connection to continue at once.

  2. Do they have a match in /etc/hosts.deny? If so, the connection is closed without reading any input.

  3. Otherwise, the connection is allowed to continue.

40.4.1. /etc/hosts.allow and /etc/hosts.deny

The 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 services

When 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 control

xinetd 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:

  • An IP address. Any zeros to the right in the number are treated as wildcards: thus, 10.1.2.0 matches the entire 10.1.2 subnet. 0.0.0.0 matches the whole Internet.

  • An IP address with a shell style {} wildcard. This can be only on the right side of the IP number, but any octets to the right of it may be dropped. Thus, 10.1.{2,3,4} matches the three subnets 10.1.2, 10.1.3, and 10.1.4.

  • A network name from /etc/networks.

  • A hostname. When xinetd receives a connection, a reverse lookup is performed and matched to the name. Incomplete names such as .example.com are allowed in the configuration and match all hosts in the example.com domain.

  • An IP address with a netmask in the /n format: for instance, 10.0.0.0/24 for the 10.0.0.x network.



LPI Linux Certification in a Nutshell
LPI Linux Certification in a Nutshell (In a Nutshell (OReilly))
ISBN: 0596005288
EAN: 2147483647
Year: 2004
Pages: 257

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net