Post-Installation Security Procedures

This article discusses a few of the many procedures we must take after the install is done, so that the system will not be trivial to hack.

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 Kernel

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.

Disabling Processes

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
Send HUP signal to inetd , so it will read the new configuration:
kill -HUP 'ps -aux | grep inetd |
awk '{print $2}' '
Test the new configuration:
$ 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.
We must remember that each of the processes run through inetd has its own configuration file. In these configuration files there are security settings that can be activated. We can set up these security settings so the services will get extra security. Take FTP, for example; we can use tcpd to check FTP requests, but as an extra security we can use the ftpaccess file to disable ftp access for root just in case. If our machine has more than one Network Interface Card, we may want to use daemons that enable us to specify on which NIC they should open a socket. This type of setting can't be done with inetd in a trivial way. Some of the FTP daemons enable these settings via the configuration file. There is another method to force a network daemon to listen only on a certain interface. Suppose our machine is connected to network A and network B, and it has two IP addresses: IA and IB. We want telnetd to listen only on IPA, so we write a simple program that opens port 23 on the IPB interface and make this program run just before telnetd. After telnetd is up and running, we can kill our little program. This won't work with every possible daemon, since certain daemons fail to start unless they can open the socket on each and every NIC on the system.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState