110.2 Setting Up Host Security

Candidates should know to set up a basic level of host security

Key Knowledge Areas

Awareness of shadow passwords and how they work.
Turn off network services not in use.
Understand the role of TCP wrappers.

Many network services, such as sshd and httpd, are started at boot time and run continuously. They handle their own network connections, accepting connections from clients and servicing them.

However, some services rely on a super-server to listen for and accept connection requests on their behalf. When a connection is accepted, the super-server starts up the required service and passes the network connection to it via a pair of file descriptors.

This way of working reduces the number or processes in the system which are blocked, awaiting client connections. It can also provide a central place to do access control and logging when service requests are received. There is, however, a small overhead in creating the service processes on demand, so this technique is usually not used for services that can experience a high rate of connection requests.

There are two super-servers. The first is inetd. This is quite old and is not used on any current Linux distributions; however it is included in the LPI-1 objectives. The more modern super-server is xinetd. This adds access controls and logging capabilities.

The inetd daemon (old)

This daemon is started at boot time and listens for connections on specific ports. This allows the server to run a specific network daemon only when needed. For example, the old telnet service has a daemon in.telnetd which handles telnet sessions. Instead of running this daemon all the time inetd is instructed to listen on port 23. As another example, swat (a browser-based configuration tool for samba) also relies on a super-server to listen for connections.

The process of accepting a connection and starting the service is shown below.

inetd is configured in the file /etc/inetd.conf. Each line defines one service for which inetd should listen.

The fields of /etc/inetd.conf contain the following:

service-name	valid name from /etc/services
socket type	stream for TCP and dgram for UDP
protocol	valid protocol from /etc/protocols
flag	nowait if multithreaded and wait if single-threaded
user/group	run application as user or group.
program	The name of the program to run
argument	The arguments to be passed to the program (if any)

Examples:

daytime stream tcp nowait root internal

telnet stream tcp nowait root /usr/sbin/in.telnetd

pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d

The first line shows a simple TCP service that's implemented internally by inetd. There is no external server to start. The second line starts an "inet-aware" version of the telnet server. The third line shows a service that's started via an intermediate program called TCP Wrappers (tcpd). This program adds an access control layer, and is discussed later in this topic.

The service names that appear in the first field of this file are looked up in the /etc/services file to find the associated port numbers. The fields in /etc/services are as follows:

service-name port/protocol [aliases]

For example, the entry for pop3 appears as follows:

pop3110/tcppop-3

If the /etc/inetd.conf file is changed, send a HUP signal to inetd to make it re-read the file:

# pkill -HUP inetd

TCP wrappers

TCP wrappers is a program that adds an access control layer to services, under control of the files /etc/hosts.allow and /etc/hosts.deny. Often, TCP wrappers (the tcpd daemon) is used in conjunction with inetd to add access control. It works like this:

The inetd server listens for and accepts connections to a specified service (pop3 for example)
inetd starts up the program specified in its config file for that service. To use TCP wrappers, that program is specified as /usr/sbin/tcpd
The name of the real server (ipop3d in our example) is passed as an argument to tcpd
tcpd consults the files /etc/hosts.allow and /etc/hosts.deny (discussed below) to decide whether or not to allow the connection.
If the connection is allowed, tcpd starts up the real server and passes it the file descriptors relating to the network connection from the client.

The figure below shows the logic used in checking entries in the hosts.allow and hosts.deny files.

Note that the default situation (if the hosts.allow and hosts.deny files are empty) is to allow access.

The format of the lines in both these files is:

daemon-list : client-host-list [ : shell-command ]

A typical configuration places a single line in hosts.deny:

ALL: ALL

With this file in place, all connections are denied unless they match a rule in hosts.allow.

Here are some sample entries from hosts.allow:

sshd: ALL except 192.168.1.11

pop3: 192.168.1.0/24

In these examples the client hosts are identified by IP address (or IP address block). You can also specify a host name here, or use the keyword ALL to match all hosts.

TCP wrappers will also log each connection to a service. Examining the logs for evidence of unauthorised attempts to connect may provide evidence of an attack on your system.

TCP wrappers is often invoked through the tcpd daemon, via inetd. However, some services such as sshd and vsftpd are linked against the libwrap library (the library that handles the access control checks against hosts.allow and hosts.deny) and therefore honour these access controls.

You can check if a service uses the libwrap library by examining the output from ldd, which shows which dynamic linked libraries (.so files) an executable requires. For example:

$ ldd /usr/sbin/sshd

libwrap.so.0 => /usr/lib64/libwrap.so.0 (0x00002b4c09fe3000)

libpam.so.0 => /lib64/libpam.so.0 (0x00002b4c0a1ec000)

libdl.so.2 => /lib64/libdl.so.2 (0x00002b4c0a3f7000)

libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b4c0a5fc000)

libaudit.so.0 => /lib64/libaudit.so.0 (0x00002b4c0a814000)

libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002b4c0aa29000)

... lines deleted ...

A little command line cunning can find all the files in a directory that use libwrap:

$ find /usr/sbin -type f -exec grep -l libwrap {} \; 2> /dev/null

/usr/sbin/mailstats

/usr/sbin/makemap

/usr/sbin/stunnel

/usr/sbin/conmand

/usr/sbin/sendmail.sendmail

/usr/sbin/smrsh

/usr/sbin/rpc.rquotad

/usr/sbin/praliases

/usr/sbin/sshd

The xinetd Daemon

In modern Linux distributions xinetd has replaced inetd. It performs essentially the same job, but it's also able to enforce access control restrictions, based on the client machine, the time of day, the load on the machine, and so on. It also logs each connection so that the tcpd daemon is no longer used, instead xinetd does everything. Configuration is done either through a single file /etc/xinetd.conf and / or by individual files in /etc/xinetd.d/ named after the services being monitored by xinetd.

In most distributions, the file /etc/xinetd.conf provides default settings which may be over-ridden by the entries in the service-specific files in /etc/xinetd.d

Structure of service file in xinetd.d:

Service-name {

disable = yes/no

socket_type = stream for TCP and dgram for UDP

protocol = valid protocol from /etc/protocols

wait = <yes or no>

user= the user the application runs as

group= the group the application runs as

server= the name of the program to be run for this service

}

Here's an example of the "top level" file, /etc/xinetd.conf

defaults

{

log_type= SYSLOG daemon info

log_on_failure= HOST

log_on_success= PID HOST DURATION EXIT


cps= 50 10

instances= 50

per_source= 10


v6only= no


groups= yes

umask= 002

}

includedir /etc/xinetd.d

In this example, we set the facility and priority at which xinetd will send messages to syslog and specify what information will be included in those messages. We also implement some simple access controls that limit the load on the machine. In this example the cps directive limits the rate of incoming connections to 50 per second. If this rate is exceeded the service will be temporarily disabled for 10 seconds. (You might also think of this as a way for an attacker to mount a denial-of-service attack on the machine!) The instances directive determines the maximum number of servers that can be simultaneously active for a service.

Here's an example of a service-specific file:

service rsync

{

disable = no

socket_type = stream

wait = no

user = root

server = /usr/bin/rsync

server_args = --daemon

log_on_failure += USERID

only_from = 192.168.0.0/24

}

The field you're most likely to need to change here is the "disable" field. Set "disable = no" to turn the service on, or set "disable = yes" to turn it off. After making a change to the xinetd configuration, send it a SIGHUP signal:

# pkill -HUP xinetd

For more detail, see the man page for xinetd.conf(5)

The following is a partial list of the used files, terms and utilities:* /etc/nologin

/etc/passwd
/etc/shadow
/etc/xinetd.d/*
/etc/xinetd.conf
/etc/inetd.d/*
/etc/inetd.conf
/etc/inittab
/etc/init.d/*
/etc/hosts.allow
/etc/hosts.deny

Previous Chapter | Next Chapter