Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

 The TCP Wrappers configuration language

The TCP Wrappers system has a simple but powerful language and a pair of configuration files that allow you to specify whether incoming connections should be accepted.

If TCP Wrappers is compiled with the -DPROCESS_OPTIONS flag, then each line of the /etc/hosts.allow and /etc/hosts.deny files have the following format:

daemon_list : client_host_list : option [ : option ...]

in which:

daemon_list

Specifies the TCP daemon (e.g., telnetd). More than one daemon can be specified by separating them with blanks or commas. The reserved keyword "ALL" matches all daemons; "ALL EXCEPT" matches all daemons except for the specific one mentioned (e.g., "ALL EXCEPT in.ftpd").

client_host_list

Specifies the hostname or IP address of the incoming connection. More than one host can be specified by separating them with blanks or commas. Incomplete hostnames and IP addresses can be used for wildcarding . The keyword ALL matches all clients;

option [ : option ...]

Specifies one or more options that are executed for the particular service.

 If TCP Wrappers is compiled with the -DPROCESS_OPTIONS flag, shell commands must be specified with the spawn option. A limited amount of token expansion is available within the shell command;

The EXCEPT operator may also be used for specifying an Internet service.

Theoretically the TCP Wrappers are vulnerable to IP spoofing because it uses IP addresses for authentication. In practice, this is not a significant concern, because TCP protocols as a rule require bidirectional communications to do anything useful. Furthermore, most TCP/IP implementations now use unpredictable sequence numbers, significantly reducing the chances of a successful spoofing attack.

TCP Wrappers also provides only limited support for UDP servers, because once the server is launched, it will continue to accept packets over the network, even if those packets come from "blocked" hosts, unless the UDP server is linked with the TCP Wrappers library and has been specially written to consult the TCP Wrappers access control lists after each new request is received.

Making sense of your TCP Wrappers configuration files

The configuration files we have shown so far are simple; unfortunately, sometimes things get more complicated. The TCP Wrappers system comes with a utility called tcpdchk that can scan through your configuration file and report on a wide variety of potential configuration errors. This is important because the TCP Wrappers system relies on many configuration files (/etc/services, /etc/inetd.conf, /etc/hosts.allow, and /etc/hosts.deny) and requires that the information between these files be consistent.

Here is an example of using the tcpdchk program; each line in this example represents a potential security problem:

% tcpdchk
warning: /etc/hosts.allow, line 24: ipop3d: no such process name in /etc/inetd.conf
warning: /etc/hosts.allow, line 39: sshd: no such process name in /etc/inetd.conf

We'll explore these "warnings" one at a time.

The first line of output refers us to line 24 of the file /etc/hosts.allow, which is shown here:

ipop3d : ALL : ALLOW

To understand the error no such process name in /etc/inetd.conf, we need to now refer to the file /etc/inetd.conf. This file has a line for the ipop3d daemon, but as the warning from tcpdchk implies, the process is not named ipop3d—it is named popper:

# example entry for the optional pop3 server
#                                                                                        
------------------------------
pop3    stream  tcp  nowait root /usr/local/libexec/ipop3d       popper

We must either change line 24 to refer to the process name popper, or change the entry in /etc/inetd.conf to use the name ipop3d. We'll change the file /etc/hosts.allow and rerun the tcpdchk program. Here is the new line 24:

popper : ALL : ALLOW

Now let's rerun the tcpdchk program:

r2# tcpdchk
warning: /etc/hosts.allow, line 24: popper: service possibly not wrapped
warning: /etc/hosts.allow, line 39: sshd: no such process name in /etc/inetd.conf
r2#

We are now told that the service is "possibly not wrapped." This is because tcpdchk is reading through the /etc/inetd.conf file and looking for "tcpd," the name of the TCP Wrappers executable. Because support for TCP Wrappers is compiled into the version of inetd that this computer is using, tcpd is not used, so tcpdchk reports a warning (which we ignore).

The second warning is that there is a rule in the /etc/hosts.allow file for the sshd service, but there is no matching daemon listed in the /etc/inetd.conf file. This is actually not an error: the sshd service is started up directly at boot time, not by inetd. Nevertheless, the program is linked with the TCP Wrappers library and honors the commands in the /etc/hosts.allow file.

The TCP Wrappers system comes with another utility program called tcpdmatch, which allows you to simulate an incoming connection and determine if the connection would be permitted or blocked with your current configuration files. In the following example, we will see if the user simsong@k1.vineyard.net is allowed to ssh into our machine:

r2# tcpdmatch
usage: tcpdmatch [-d] [-i inet_conf] daemon[@host] [user@]host
        -d: use allow/deny files in current directory
        -i: location of inetd.conf file
r2# tcpdmatch sshd simsong@k1.vineyard.net
warning: sshd: no such process name in /etc/inetd.conf
client:   hostname K1.VINEYARD.NET
client:   address  204.17.195.90
client:   username simsong
server:   process  sshd
matched:  /etc/hosts.allow line 39
option:   allow 
access:   granted
r2#

Ignoring the warning in the first line, we can see that permission would be granted by line 39 of the /etc/hosts.allow file. This line reads:

sshd : ALL : allow

Programs such as tcpdchk and tcpdmatch are excellent complements to the security program TCP Wrappers because they help you head off security problems before they happen. Wietse Venema should be complimented for writing and including them in his TCP Wrappers release; other programmers should follow his example.

Before answering this question, let's first provide a little background. TCP Wrappers has been around for many, many years. It is used to restrict access to TCP services based on host name, IP address, network address, etc. For more detailed on what TCP Wrappers is and how you can use it, see tcpd(1M). TCP Wrappers was integrated into Solaris starting in Solaris 9 where both Solaris Secure Shell and inetd-based (streams, nowait) services were wrapped. Bonus points are awarded to anyone who knows why UDP services are not wrapped by default.

TCP Wrappers support in Secure Shell was always enabled since Secure Shell always called the TCP Wrapper function host_access(3) to determine if a connection attempt should proceed. If TCP Wrappers was not configured on that system, access, by default, would be granted. Otherwise, the rules as defined in the hosts.allow and hosts.deny files would apply. For more information on these files, see hosts_access(4). Note that this and all of the TCP Wrappers manual pages a stored under /usr/sfw/man in Solaris 10. To view this manual page, you can use the following command:

$ man -M /usr/sfw/man -s 4 hosts_access

inetd-based services use TCP Wrappers in a different way. In Solaris 9, to enable TCP Wrappers for inetd-based services, you must edit the /etc/default/inetd file and set the ENABLE_TCPWRAPPERS parameter to YES. By default, TCP Wrappers was not enabled for inetd.
 

New usage of TCP Wrappers in Solaris 10

In Solaris 10, two new services were wrapped: sendmail and rpcbind.

• sendmail works in a way similar to Secure Shell. It always calls the host_access function and therefore TCP Wrappers support is always enabled. Nothing else needs to be done to enable TCP Wrappers support for that service.
• TCP Wrappers support for rpcbind must be enabled manually using the new Service Management Framework ("SMF"). Similarly, inetd was modified to use a SMF property to control whether TCP Wrappers is enabled for inetd-based services.

To enable TCP Wrappers support for inetd-based services:

# inetadm -M tcp_wrappers=true
# svcadm refresh inetd

This will enable TCP Wrappers for inetd-based (streams, nowait) services like telnet, rlogin, and ftp (for example):

# inetadm -l telnet | grep tcp_wrappersdefault tcp_wrappers=TRUE

You can see that this setting has taken effect for inetd by running the following command:

# svcprop -p defaults inetd
defaults/tcp_wrappers boolean true

Note that you can also use the svccfg(1M) command to enable TCP Wrappers for inetd-based services.

# svccfg -s inetd setprop defaults/tcp_wrappers=true
# svcadm refresh inetd

Whether you use inetadm(1M) or svccfg is really a matter of preference. Note that you can also use inetadm or svccfg to enable TCP Wrappers on a per-service basis. For example, let's say that we wanted to enable TCP Wrappers for telnet but not for ftp. By default, both the global and per-service settings for TCP Wrappers are disabled:

# inetadm -p | grep tcp_wrappers
tcp_wrappers=FALSE

# inetadm -l telnet | grep tcp_wrappers
default tcp_wrappers=FALSE

# inetadm -l ftp | grep tcp_wrappers
default tcp_wrappers=FALSE

To enable TCP Wrappers for telnet, use the following command:

# inetadm -m telnet tcp_wrappers=TRUE

Let's check out settings again:

# inetadm -p | grep tcp_wrappers
tcp_wrappers=FALSE

# inetadm -l telnet | grep tcp_wrappers
tcp_wrappers=TRUE

# inetadm -l ftp | grep tcp_wrappers
default tcp_wrappers=FALSE

As you can see, TCP Wrappers has been enabled for telnet but none of the other inetd-based services. Pretty cool, eh?

You can enable TCP Wrappers support for rpcbind by running the following command:

# svccfg -s rpc/bind setprop config/enable_tcpwrappers=true
# svcadm refresh rpc/bind

This change can be verified by running:

# svcprop -p config/enable_tcpwrappers rpc/bind
true

Old News ;-)

[Sep 30, 2007]  How to Secure Your RHEL5 Server Power Systems IBM Systems Magazine by Ken Milberg

xinetd

How exactly can we secure RHEL5? Let’s start with xinetd. xinetd is an Internet service daemon that’s more secure than its predecessor, inetd, which is no longer used in Linux. Instead of having many different servers running at the same time, only xinetd is loaded, and it handles all requests and starts up the appropriate server. It verifies the connection is allowed and can even ensure that the services don’t consume more than the allotted amount of system resources. It’s commonly referred to as a super-service of sorts, as it controls access to all network services, including telnet and ftp. The xinet.conf is the global configuration file.

Here is a snapshot of it, taken from an RHEL5 partition on a System p platform.

[root@172_29_138_30 etc]# more xinetd.conf
#
# This is the master xinetd configuration file. Settings in the
# default section will be inherited by all service configurations
# unless explicitly overridden in the service configuration. See
# xinetd.conf in the man pages for a more detailed explanation of
# these attributes.

defaults
{
# The next two items are intended to be a quick access place to
# temporarily enable or disable services.
#
# enabled =
# disabled =

# Define general logging characteristics.
log_type = SYSLOG daemon info
log_on_failure = HOST
log_on_success = PID HOST DURATION EXIT

# Define access restriction defaults
#
# no_access =
# only_from =
# max_load = 0
cps = 50 10
instances = 50
per_source = 10

# Address and networking defaults
#
# bind =
# mdns = yes
v6only = no

# setup environmental attributes
#
# passenv =
groups = yes
umask = 002

The /etc/xinetd.d directory contains the configuration files for all services managed by the xinetd daemon. This example shows a configuration for a kerberized telnet server:

[root@172_29_138_30 xinetd.d]# ls
chargen-dgram daytime-stream echo-stream klogin rsync
chargen-stream discard-dgram eklogin krb5-telnet tcpmux-server
cvs discard-stream ekrb5-telnet kshell time-dgram
daytime-dgram echo-dgram gssftp ktalk time-stream
[root@172_29_138_30 xinetd.d]# more ekrb5-telnet
# default: off
# description: The kerberized telnet server accepts only telnet sessions, \
# which use Kerberos 5 authentication and encryption.
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/kerberos/sbin/telnetd
server_args = -e
log_on_failure += USERID
disable = yes

If you want to turn ftp on, you’ll need to change disable to no, start your ftp services and then restart your xinetd daemon.

 

TCP Wrappers

Implementation of TCP wrappers is a much more effective way of denying access to services than anything you can do without it. This can help you send special security-type banners and also warn of impending attacks by specific host machines. The logging features are also advanced. TCP wrappers make use out of the /etc/hosts.allow and /etc/hosts.deny file. When TCP wrappers are configured, only authorized systems may utilize the services of the host machine. TCP wrappers provide transparency to the client and to the wrapped network service, as both are unaware that TCP wrappers are in use. Because they operate separately from the actual services they protect, they allow many applications to share this common set of configuration files, making easier to manage.

Recommended Links

Using TCP Wrappers to secure Linux