Post-Installation Security Procedures

Installing a Linux system is a relatively easy task. Most of the distributions provide automatic installation tools; these tools take care of the installation procedure from beginning to end. The problem with these automatic installation tools is that they tend to make the wrong assumptions about your system. When it comes to security considerations, these wrong assumptions can cause problems.

Securing Linux is not an easy task. You never know who is trying to gather information from your servers or even from your desktop. Some people do not even try to gather information; they just love it when they bring your web server down or have it show their latest work of art.

The first thing to do after installation is remove unneeded kernel features and services. The Linux kernel has many nice networking features; some of these features are needed by our system, some are not. Here are some kernel networking features we should compile into our kernel: IP-firewalling, Tcp Syn Cookies, Drop Source routed frames. The IP-firewalling option enables the setup of IP access lists from the command line. The Tcp Syn Cookies helps to prevent the known SYN flooding denial-of-service attack. Source-routed frames allow an attacker to bypass the normal routing decisions by specifying the routers the packet should go through within the packet data: this is a very bad idea but is sometimes needed. When compiling the kernel we need to go over all the options and enable only the options needed by our system. If a kernel option is needed we can compile it as a part of the kernel, or we can compile the kernel to support this option as a module. New kernels have new features; when compiling a new kernel we must make sure we know what each and every option we have enabled does.

Listing 1

We can view what processes run in our system by typing ps aux. The network sockets that are open in our system, can be displayed by typing netstat -an. Listing 1 shows some of the open sockets on a Linux machine.

The fewer services our system gives, the better. The inetd process listens on the TCP/UDP sockets specified by its configuration file. The configuration file, /etc/inetd.conf by default, tells inetd what sockets it should open and what processes it should execute once a connection is made on the socket. We should go through all services in the /etc/inetd.conf and disable those that we don't need on our system. The best way to disable a service is to put a comment sign # at the beginning of the line that configures the service we want to disable. It is a good idea to comment all /etc/inetd.conf services and use secure services instead. As an example, we can disable TELNET and FTP and enable ssh and FTP through ssh.

If we must enable a service, we should configure the service in the most secure way it can be provided. The Linux system has many tools to help an administrator provide services securely.

One of these tools is the IP-Firewalling that the kernel supports. Another tool is the tcpd, a program that monitors requests for services on the system. It logs and checks the request, and if all the checks show the client can receive the service, it will open the right service for the client. There are two files that tcpd consults when it checks for authorization: /etc/host.allow and /etc/hosts.deny. To enable tcpd checks before a service begins, we simply tell inetd to run tcpd in the configuration file. Most Linux distributions are configured to run inetd with tcpd for most services by default. Here is a line from an inetd.conf that enables the tcpd checks whenever a TELNET connection request from a client arrives:

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

Whenever a telnet connection request arrives, tcpd is activated by inetd. tcpd logs the connection request via the syslogd service, then consults the hosts.allow file. If the hosts.allow file contains a match of telnetd and the requesting client, the telnet connection is considered authorized and the connection is established. If there is no such line, the /etc/hosts.deny file is consulted. There must be a line specifing telnetd and client X in the /etc/hosts.deny files if we don't want client X to be answered by our system.

There are more complicated options available in the tcpd configuration files, such as running shell commands after a certain connection request occurs. For further information on the format of the files, look at Section 5 of the manual for hosts_access and hosts_options.

Another way to disable services run via inetd is to run a shell script instead of the process. Let's have a look at a simple shell script. Please note that it is not always safe to use this method

$ cat > /usr/sbin/telnetd.new
#!/bin/sh
echo "Please do not use telnet to this computer.\
Use ssh only if you have the correct public key"
$ chmod +x /usr/sbin/telnetd.new

We then edit the /etc/inetd.conf file so it will execute our new script instead of in.telnetd. The line should look like this:

telnet stream tcp nowait root /usr/sbin/tcpda\
   telnet.new

kill -HUP 'ps -aux | grep inetd |
awk '{print $2}' '

$ telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Please do not use telnet to this computer. Use ssh only
if you have the correct public key.