Linux Hardening

This article aims to provide a general list of security issues that should be considered when you are auditing a Linux system or when you are hardening an existing Linux system. With a significant number of Linux web servers deployed around the world, security is quoted as the main reason for using them.

Linux is relatively secure compared to other platforms like Windows, but what we need to remember is it's only as secure as we configure it to be. In other words, a Linux server can also be compromised if it is not properly configured. Even if the system is completely patched, it does not stop the system from being compromised due to a weak configuration. Depending on the underlying requirements, the configuration might change from system to system but the administrator needs to keep in mind the security aspects of allowing or disallowing the controls.

Let us now proceed and look at a few measures we need to take to harden a Linux-based server.

Identifying and disabling unnecessary services

Hardening the system by disabling unnecessary services increases the overall security of the system and also improves its performance. So first, it's important to identify all the running services we need and then disable the unnecessary ones. Services run in different ways, so an administrator needs to know how to look out for these.

ps –ax : Lists all the currently running processes.

To stop running service, # service stop nfs.

netstat –a : Lists all the open ports.

Disable the ports which are not required by the system.

chkconfig –list : Lists current start-up status of all processes known by chkconfig.

Password Policy

It's important to align the password policy of the system with the password policy of the organization. These settings (mostly expiration related settings) are generally stored in /etc/login.defs. Open the /etc/login.defs file which defines the site-specific configuration for the shadow password suite in your favourite editor and modify the parameters. Parameters like PASS_MAX_DAYS, PASS_MIN_DAYS, PASS_WARN_AGE etc. are provided under this file.

Please note that much of the functionality that used to be provided by the shadow password suite is now handled by PAM (Pluggable Authentication Module). Thus, /etc/login.defs is no longer used by programs such as login(1) and passwd(1). On RedHat, you have a file named /etc/pam.d/system-auth where you can set the rules for the password strength etc. To make an account inactive after the expiration of a password, use the file /etc/default/useradd and change 'INACTIVE' to a number of days.

Prevent information revealed through system scanning

Attackers can scan Linux servers from both inside and outside the network to gather as much information as they can. Services running on the system sometimes give away very valuable information like versions of the software, IP addresses, usernames, emails etc. When an attacker knows the running services, the next thing he would look for is the exact versions of the software or service so that he can search for the associated vulnerabilities and exploit them, so it's helpful to scan the network yourself and verify all the information revealed by the system.

To start with, a normal port scan would give you the results of all services that are running. Now you cannot completely prevent system scanning but with proper countermeasures, you can minimize the information which an attacker could otherwise access. Disable the services you don't need including RPC, FTP and Telnet (Telnet and FTP send the traffic in clear text and their login can be brute forced). If they are enabled, you need to make sure that there is a business justification for it. Sometimes, FTP's are configured with anonymous logins which do not prompt for user credentials. So it's also important to look for the simple stuff.

.rhosts and hosts.equiv file

The first thing an attacker does after getting access to a Linux based system is to look for the list of users trusted by the system. This information is available in /etc/hosts.equiv and .rhosts files. Here is a short description of these files:

hosts.equiv

The /etc/hosts.equiv file doesn't provide any information about root access but it tells which accounts on the system can access services on the system. For instance, if host1 is listed in this file, all users on that system would be allowed access. So an attacker can read this file and then spoof their IP address and hostname to gain unauthorized access to the local system. The .rhosts and hosts.equiv files also provide names of other computers to attacks.

.rhosts

The "rhosts" mechanism allows one system to trust another system. In other words, if a user logs into one Linux system, they can further log into any other system that trusts it. This file is used by rsh, rlogin etc. The rsh tells the system to open a remote shell and run the specified program while rlogin creates an interactive Telnet session on the other computer. Rhosts file may contain something like this.

host1 tom

host1 jack

This file allows users Tom and Jack on the remote-system host1 to log in to the local host with the same privileges as the local user. If a plus sign (+) is entered in the remote-host and user fields, any user from any host could log in to the local system. An attacker can manually modify this file and allow access from any system across the network. If this file is enabled, it would result in a huge security vulnerability for a hacker to exploit. You can prevent this by disabling the BSD r commands. This can be done by commenting out the lines starting with shell, login, and exec in inetd.conf. You can also disable it by editing the rexec, rlogin, and rsh files located in the /etc/xinetd.d directory. Open each file in a text editor and change disable=no to disable=yes. If you do not like to disable this, you can set the read permissions for each file's owner only.

Remote Access and SSH Settings

Telnet is not recommended for remote access because it does not provide encrypted transmission and transmits passwords in plain text, so it is susceptible to interception and disclosure using packet analysis. Secure Shell (SSH) provides remote access and is a secure alternative to telnet. Older versions of SSH have published vulnerabilities and hence should not be used. Changes can be made by modifying the sshd_config file.

Protocol 2

PermitRootLogin no

PermitEmptyPasswords no

Banner /etc/issue

IgnoreRhosts yes

RhostsAuthentication no

RhostsRSAAuthentication no

HostbasedAuthentication no

LoginGraceTime 1m

SyslogFacility AUTH (provides logging under syslog AUTH)

AllowUser [list of users allowed access]

DenyUser [list of system accounts not allowed]

You might also consider the option of running SSH on a different port. Although many people do not agree with this, this would avoid port scanners which are looking specifically for port 22.

System Logging and Auditing

System logging is important not just for troubleshooting and resolving network problems but also for security incidents. Linux systems support system logging through the daemonSysLog. The logging configuration file which is stored at /etc/syslog.conf identifies the level of logging and location of the log files. The log files are located under /var/log directory. You can change to this directory using the cd command but you need to be the root user. Make sure that these log files can only be accessed by the root user and the corresponding group and not by all users.

To further tighten security, log files can be sent to a centralized server over SSH. This is to ensure that the log files are not deleted or tampered with by an attacker. Logging the files isn't enough though; a continuous review of the log entries is also important. The following is a general list of Linux log file names and their usage:

/var/log/message: General message and system related stuff

/var/log/auth.log: Authenication logs

/var/log/kern.log: Kernel logs

/var/log/cron.log: Crond logs (cron job)

/var/log/maillog: Mail server logs

/var/log/qmail/ : Qmail log directory (more files inside this directory)

/var/log/httpd/: Apache access and error logs directory

/var/log/lighttpd: Lighttpd access and error logs directory

var/log/boot.log : System boot log

/var/log/mysqld.log: MySQL database server log file

/var/log/secure: Authentication log

/var/log/utmp or /var/log/wtmp : Login records file

/var/log/yum.log: Yum log files

There are some tools which can help you with this. For example, LogWatch tool allows you to set some details like services to include, log file names etc. and reports that can be sent to the configured mail. Swatch is another active log file monitoring tool which uses regular expressions to find some malicious patterns. With these, you have the information about the system start time, user responsible for event, type of event, modifications to network settings etc. This could be valuable information indeed if you are to trace an attacker after an unexpected event.

Integrity Checking Software

Integrity checking software is very important to maintain as it checks and monitors critical files at regular intervals and notifies the system administrator of any changes. If there is any unauthorized change to important services, configuration files or log files, this option would help you. There are several integrity checking packages available, both commercial and non-commercial. Tripwire is a well-known option which combines Tripwire Enterprise, Tripwire Log Center and the new VIA platform to help organizations manage incident detection, security policy enforcement, reduce the attack surface and automate regulatory compliance. It has both commercial and open source editions to choose from.

Hard disk Encryption

Many enterprises, small businesses, government offices and also users have a lot of sensitive and confidential information stored on their systems. Even though the system password prevents the attacker from getting access to files on the disk, it does not help when the hard disk is removed or stolen. Hence it's more secure to encrypt the contents of the hard disk so that even if the disk is stolen, the data cannot be retrieved. This mechanism works by maintaining a key in the memory and decrypting the data dynamically as it is used. You might want to look at this option if you think it is necessary.

Backups

Hard disk encryption wouldn't help you if someone wipes off the data on your hard disk so it is also important to maintain backup of the data that is critical to the organization. There are both commercial and non-commercial tools which can help you with this purpose. Tools like tar, gzip and bzip2 have been around for along time and are still considered good options by many users. Almost all the *nix systems contain tar and it doesn't require any special installation or configuration. However, they may not be suitable if you want to backup large amounts of data as it might be slow. Dump is another tool specially used for backups. It backs up the entire file system and allows multiple levels of backups. Using the 'restore' command, you can restore from a dump backup.

Apply Security Patches

Applying security patches is a very important part of keeping the system secure. Linux has necessary tools to keep the system updated and also allows upgrading to different versions easily. Security updates should be reviewed and updated in a timely and effective manner. You can use package managers such as 'yum' to apply all security updates and you can also configure Red hat/CentOS/Fedora Linux to send yum package update notifications through email. Another option is to apply all security updates via a cron job. With Debian/Ubuntu Linux, you can use apticron to send security notifications.

These are just a few tips to make sure that the underlying Linux system or server is secure. Be sure to remember the saying, 'A chain is only as strong as its weakest link.'