TCP Wrappers and xinetd.
Controlling access to network services is one of the most important security tasks facing a server administrator. Fortunately, under Red Hat Linux there are a number of tools which do just that. For instance, an iptables-based firewall filters out unwelcome network packets within the kernel's network stack. For network services that utilize it, TCP wrappers add an additional layer of protection by defining which hosts are allowed or not allowed to connect to "wrapped" network services. One such wrapped network service is the xinetd super server. This service is called a super server because it controls connections to a subset of network services and further refines access control.
This topic focuses on the role of TCP wrappers and xinetd in controlling access to network services and reviews how these tools can be used to enhance both logging and utilization management.
TCP Wrappers
The TCP wrappers package (tcp_wrappers) is installed by default under Red Hat Linux and provides host-based access control to network services. The most important component within the package is the /usr/lib/libwrap.a library. In general terms, a TCP wrapped service is one that has been compiled against the libwrap.a library.When a connection attempt is made to a TCP wrapped service, the service first references the hosts access files (/etc/hosts.allow and /etc/hosts.deny) to determine whether or not the client host is allowed to connect. It then uses the syslog daemon (syslogd) to write the name of the requesting host and the requested service to /var/log/secure or /var/log/messages.
If a client host is allowed to connect, TCP wrappers release control of the connection to the requested service and do not interfere further with communication between the client host and the server.
In addition to access control and logging, TCP wrappers can activate commands to interact with the client before denying or releasing control of the connection to the requested network service.
Because TCP wrappers are a valuable addition to any server administrator's arsenal of security tools, most network services within Red Hat Linux are linked against the libwrap.a library. Some such applications include /usr/sbin/sshd, /usr/sbin/sendmail, and /usr/sbin/xinetd.
To determine if a network service binary is linked against libwrap.a, type the following command as the root user:
|
Advantages of TCP Wrappers
TCP wrappers provide the following advantages over other network service control techniques:- Transparency to both the client host and the wrapped network service. — Both the connecting client and the wrapped network service are unaware that TCP wrappers are in use. Legitimate users are logged and connected to the requested service while connections from banned clients fail.
- Centralized management of multiple protocols. — TCP wrappers operate separately from the network services they protect, allowing many server applications to share a common set of configuration files for simpler management.
TCP Wrappers Configuration Files
To determine if a client machine is allowed to connect to a service, TCP wrappers reference the following two files, which are commonly referred to as hosts access files: - /etc/hosts.allow
- /etc/hosts.deny
- The service references /etc/hosts.allow. — The TCP wrapped service sequentially parses the /etc/hosts.allow file and applies the first rule specified for that service. If it finds a matching rule, it allows the connection. If not, it moves on to step 2.
- The service references /etc/hosts.deny. — The TCP wrapped service sequentially parses the /etc/hosts.deny file. If it finds a matching rule is denies the connection. If not, access to the service is granted.
- Because access rules in hosts.allow are applied first, they take precedence over rules specified in hosts.deny. Therefore, if access to a service is allowed in hosts.allow, a rule denying access to that same service in hosts.deny is ignored.
- Since the rules in each file are read from the top down and the first matching rule for a given service is the only one applied, the order of the rules is extremely important.
- If no rules for the service are found in either file, or if neither file exists, access to the service is granted.
- TCP wrapped services do not cache the rules from the hosts access files, so any changes to hosts.allow or hosts.deny take effect immediately without restarting network services.
Formatting Access Rules
The format for both /etc/hosts.allow and /etc/hosts.deny are identical. Any blank lines or lines that start with a hash mark (#) are ignored, and each rule must be on its own line.Each rule uses the following basic format to control access to network services:
<daemon list>: <client list> [: <option>: <option>: ...]
|
- <daemon list> — A comma separated list of process names (not service names) or the ALL wildcard (see wildcards). The daemon list also accepts operators.
- <client list> — A comma separated list of hostnames, host IP addresses, special patterns or special wildcards which identify the hosts effected by the rule. The client list also accepts operators listed in to allow greater flexibility.
- <option> — An optional action or colon separated list of actions performed when the rule is triggered. Option fields support expansions (Expansions), launch shell commands, allow or deny access, and alter logging behavior (see Option Fields).
vsftpd : .example.com
|
The next sample hosts access rule is more complex and uses two option fields:
sshd : .example.com \
: spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \
: deny
|
| Warning | ||
|---|---|---|
If the last line of a hosts access file is not a newline character (created by pressing the [Enter] key), the last rule in the file will fail and an error will be logged to either /var/log/messages or /var/log/secure. This is also the case for a rule lines that span multiple lines without using the backslash. The following example illustrates the relevant portion of a log message for a rule failure due to either of these circumstances:
|
Wildcards
Wildcards allow TCP wrappers to more easily match groups of daemons or hosts. They are used most frequently in the client list field of access rules.The following wildcards may be used:
- ALL — Matches everything. It can be used for both the daemon list and the client list.
- LOCAL — Matches any host that does not contain a period (.), such as localhost.
- KNOWN — Matches any host where the hostname and host address are known or where the user is known.
- UNKNOWN — Matches any host where the hostname or host address are unknown or where the user is unknown.
- PARANOID — Matches any host where the hostname does not match the host address.
| Caution | |
|---|---|
| The KNOWN, UNKNOWN, and PARANOID wildcards should be used with care as a disruption in name resolution may prevent legitimate users from gaining access to a service. |
Patterns
Patterns can be used in the client list field of access rules to more precisely specify groups of client hosts.The following is a list of the most common accepted patterns for a client list entry:
- Hostname beginning with a period (.) — Placing a period at the beginning of a hostname, matches all hosts sharing the listed components of the name. The following example would apply to any host within the example.com domain:
ALL : .example.com - IP address ending with a period (.) — Placing a period at the end of an IP address matches all hosts sharing the initial numeric groups of an IP address. The following example would apply to any host within the 192.168.x.x network:
ALL : 192.168. - IP address/netmask pair — Netmask expressions can also be used as a pattern to control access to a particular group of IP addresses. The following example would apply to any host with an address of 192.168.0.0 through 192.168.1.255:
ALL : 192.168.0.0/255.255.254.0 - The asterisk (*) — Asterisks can be used to match entire groups of hostnames or IP addresses, as long as they are not mixed in a client list containing other types of patterns. The following example would apply to any host within the example.com domain:
ALL : *.example.com - The slash (/) — If a client list begins with a slash, it is treated as a file name. This is useful if rules specifying large numbers of hosts are necessary. The following example refers TCP wrappers to the /etc/telnet.hosts file for all Telnet connections:
in.telnetd : /etc/telnet.hosts
| Warning | |
|---|---|
| Be very careful when creating rules requiring name resolution, such as hostnames and domain names. Attackers can use a variety of tricks to circumvent accurate name resolution. In addition, any disruption in DNS service would prevent even authorized users from using network services. It is best to use IP addresses whenever possible. |
Operators
At present, access control rules accept one operator, EXCEPT. It can be used in both the daemon list and the client list of a rule.The EXCEPT operator allows specific exceptions to broader matches within the same rule.
In the following example from a hosts.allow file, all example.com hosts are allowed to connect to all services except cracker.example.com:
ALL: .example.com EXCEPT cracker.example.com
|
ALL EXCEPT vsftpd: 192.168.0.
|
| Note | |
|---|---|
| Organizationally, it is often easier to use EXCEPT operators sparingly, placing the exceptions to a rule in the other access control file. This allows other administrators to quickly scan the appropriate files to see what hosts should are allowed or denied access to services, without having to sort through the various EXCEPT operators. |
Portmap and TCP Wrappers
When creating access control rules for portmap, do not use hostnames as its implementation of TCP wrappers does not support host look ups. For this reason, only use IP addresses or the keyword ALL when specifying hosts is in hosts.allow or hosts.deny.In addition, changes to portmap access control rules may not take affect immediately.
Widely used services, such as NIS and NFS, depend on portmap to operate, so be aware of these limitations.
Option Fields
In addition to basic rules allowing and denying access, the Red Hat Linux implementation of TCP wrappers supports extensions to the access control language through option fields. By using option fields within hosts access rules, administrators can accomplish a variety of tasks such as altering log behavior, consolidating access control, and launching shell commands.Logging
Option fields let administrators easily change the log facility and priority level for a rule by using the severity directive.In the following example, connections to the SSH daemon from any host in the example.com domain are logged to the the default authpriv facility (because no facility value is specified) with a priority of emerg:
sshd : .example.com : severity emerg
|
sshd : .example.com : severity local0.alert
|
| Note | |
|---|---|
| In practice, this example will not work until the syslog daemon (syslogd) is configured to log to the local0 facility. See the syslog.conf man page for information about configuring custom log facilities. |
Access Control
Option fields also allow administrators to explicitly allow or deny hosts in a single rule by adding the allow or deny directive as the final option.For instance, the following two rules allow SSH connections from client-1.example.com, but deny connections from client-2.example.com:
sshd : client-1.example.com : allow
sshd : client-2.example.com : deny
|
Shell Commands
Option fields allow access rules to launch shell commands through the following two directives:- spawn — Launches a shell command as a child process. This option directive can perform tasks like using /usr/sbin/safe_finger to get more information about the requesting client or create special log files using the echo command.
In the following example, clients attempting to access Telnet services from the example.com domain are quietly logged to a special file:
in.telnetd : .example.com \ : spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \ : allow - twist — Replaces the requested service with the specified command. This directive is often used to set up traps for intruders (also called "honey pots"). It can also be used to send messages to connecting clients. The twist command must occur at the end of the rule line.
In the following example, clients attempting to access FTP services from the example.com domain are sent a message via the echo command:
vsftpd : .example.com \ : twist /bin/echo "421 Bad hacker, go away!"
Expansions
Expansions, when used in conjunction with the spawn and twist directives provide information about the client, server, and processes involved.Below is a list of supported expansions:
- %a — The client's IP address.
- %A — The server's IP address.
- %c — Supplies a variety of client information, such as the username and hostname, or the username and IP address.
- %d — The daemon process name.
- %h — The client's hostname (or IP address, if the hostname is unavailable).
- %H — The server's hostname (or IP address, if the hostname is unavailable).
- %n — The client's hostname. If unavailable, unknown is printed. If the client's hostname and host address do not match, paranoid is printed.
- %N — The server's hostname. If unavailable, unknown is printed. If the server's hostname and host address do not match, paranoid is printed.
- %p — The daemon process ID.
- %s — Various types of server information, such as the daemon process and the host or IP address of the server.
- %u — The client's username. If unavailable, unknown is printed.
It instructs TCP wrappers that if a connection to the SSH daemon (sshd) is attempted from a host in the example.com domain, execute the echo command to log the attempt, including the client hostname (using the %h expansion), to a special file:
sshd : .example.com \
: spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \
: deny
|
vsftpd : .example.com \
: twist /bin/echo "421 %h has been banned from this server!"
|
Comments
Post a Comment