Ict-innovation/LPI/110.2

= 110.2 Setting Up Host Security =
"Candidates should know to set up a basic level of host security"
Key Knowledge Areas
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:
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:
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 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:
A little command line cunning can find all the files in a directory that use libwrap:
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 = &lt;yes or no&gt;
 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:
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
Previous Chapter | Next Chapter