This document is intended to assist system administrators responsible for any number of Linux hosts to improve the security of their systems thereby making them more resilient against future attacks.

Pre-flight checklist

Here are some issues that you should address before attaching a Linux host to the network.

  1. Consider whether you can trust the operating system installation. Remember that a pre-installed operating system may have been modified in ways that make it less secure or incompatible with the information security policy of your group or department; for example by enabling remote access features, support accounts or back doors. If you are unable to trust the installation then completely reinstall the OS from a known good source.

  2. Ensure that the root password is strong and disable remote access to this account.
  3. Identify all unlocked user accounts and remove or lock any that do not need to login interactively. Ensure that all unlocked user and system accounts have strong passwords.
  4. Identify all running network services that are listening for connections and uninstall or disable everything that is unnecessary.
  5. Configure the iptables firewall to only permit incoming traffic related to established connections and advertised services.

You should perform the following procedures immediately upon attaching a Linux host to the network.

  1. Download and install all relevant security patches for the installed software.
  2. Test the configuration of the box to ensure that no obvious configuration mistakes have been made that could affect its services or security.

Disabling SSH remote access by the root user

Most brute force attacks against SSH will repeatedly attempt to guess the password of the root user so it is essential that this password is strong.

In fact, it is almost always advisable to completely disable the ability to log into a host directly as root.

In /etc/ssh/sshd_config:

PermitRootLogin no

This enforces the best practice that an administrator must first authenticate to SSH using their own unprivileged user account, and then invoke su or sudo from within their shell to elevate to root.

It is occasionally necessary to permit the root user to login by SSH for the purpose of scripting remote automation or data transfer. Scripts should use public-key-based authentication which involves no passwords since access is negotiated based upon both parties possessing the complimentary parts of a pair of keys. They ought never to attempt to emulate interactive password-based authentication which SSH makes purposefully difficult since it inevitably involves storing a plain text password for use by the script.

If such root access is required by scripts then it is preferable to disallow password-based authentication for root whilst leaving public-key-based authentication available.

In /etc/ssh/sshd_config:

PermitRootLogin without-password

More sophisticated brute-force attacks will attempt to guess the passwords of common user names and system accounts.

If you are installing new software then immediately check to ensure that it has not created a new user account with some default password. If it has then change the password or even by locking the account.

On a multi-user service, whilst it is may not possible to ensure that all users of a host choose a strong password, it is possible to greatly cripple the effectiveness of brute force attacks through the use of source-based rate limiting by appropriately configuring the iptables firewall.

Identifying enabled user accounts

You should identify all user accounts (including system accounts) to determine those that are able to log in, then remove or lock the password of any accounts that are unnecessary:

usermod -L username

Modern Linux systems use "shadow passwords"; for every user entry in the world-readable /etc/passwd file there is a corresponding entry in non-world-readable /etc/shadow file that contains a crypt of the user's password.

You should make sure that you understand the role of all of the enabled accounts within both of these files.

The following line from /etc/shadow represents a password-enabled account for the user anc:


Locked accounts

Users with locked passwords will be unable to gain access by password authentication at a login prompt, either locally or remotely.

An account can be locked by replacing the second field of an entry in the /etc/shadow file with either an asterisk or a pling.

These lines represent valid user or system accounts with locked passwords:


Identifying listening network services

You should identify all running software that is listening for incoming connections from the network.

Examine the output of the command:

netstat -tuwlp

This lists the local ports that are listening for new connection and which processes are holding them open.

tcp 0 0 localhost:ipp *:* LISTEN 4694/cupsd
tcp 0 0 *:www *:* LISTEN 7367/apache2
raw 0 0 *:icmp *:* 7 27427/dhcpd3

  • The first line indicates that the cupsd printer daemon is listening on the "ipp" port on only the via the loopback interface, indicated by the "localhost" address. Hence this service could not be attached to from the network and is not ordinarily a security threat.
  • The second line indicates that the apache2 web server is listening on the "www" port on all network interfaces, indicated by the "*" address.
  • The third line indicates that the dhcpd3 daemon is listening to all traffic on all interfaces, as indicated by the "raw" protocol on all interfaces.

Important: depending upon the mechanism by which the dhcpd3 process is receiving messages from the network socket it could well be seeing datagrams prior to filtering by the iptables firewall. This highlights the importance of not naïvely relying on a host-based firewall as your sole line of defence against an inadequately secured service.

You should ensure that you understand the role of every network-attached listening process. Any unnecessary services should be disabled at boot or better still uninstalled.

All necessary network services should be assessed to determine their access requirements and then be configured at the service level to serve no wider audience than absolutely necessary, e.g. a list of specific IP addresses, their local subnet, campus-wide, etc. This configuration should be reinforced or refined by appropriate firewall entries in order to mitigate the consequences of misconfiguration, cracking and to prevent DOS attacks.

Configuring the iptables firewall

Configuring the netfilter/iptables firewall is a very important step in the process of securing a Linux host.

Primarily it prevents you from accidentally presenting new network services as can often happen as a side-effect of automatically satisfying package dependencies when installing new software. It will also prevent the users of a multi-user host from either deliberately or accidentally hosting their own services.

Furthermore, an advanced firewall configuration will guard against brute-force attacks, can protect you from session hijacking, will prevent malformed packets from stressing a host's network stack and allow you to carefully define the perimeter within which services are made available.

For incoming traffic it is strongly recommended that you start with the most secure configuration:

  • Set the default policy of the INPUT chain to DROP
  • Accept all traffic from the local loopback interface
  • Drop traffic that claims to be from a local address that is not from the loopback interface
  • Accept only traffic that is related to already established connection
  • Drop any rogue packets that contain invalid data
  • Log any packets that will then be subsequently dropped, up to a certain rate limit

In iptables parlance this equates to the following rules:

iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -s ! -i lo -j DROP
[ Place here any additional rules to allow incoming connections to specific services. ]
iptables -A INPUT -m limit --limit 1/second --limit-burst 100 -j LOG

In this hardened configuration all remotely initiated connections that originate from the network will be rejected (except for any that you have purposefully allowed), whilst all locally initiated connections that originate from the host will succeed.

It will also be necessary to add ACCEPT rules for various network services such as the recommended ICMP types, any routing protocols, and of course any local services that you intend to host. For example:

... -s -p tcp -m tcp --dport 80 --syn -m state --state NEW -j ACCEPT

The above rule will accept new incoming connections from the "campus network" to TCP port 80 (http) thereby permitting the web service provided by this host to be accessed by users on the University network.

... -s -p udp -m udp --dport 69 -m state --state NEW -j ACCEPT

The above rule will permit new incoming connections from "subnet 123" to the UDP port 69 (tftp) thereby permitting hosts on only that subset access to the TFTP service.

An example iptables template for helping develop your firewall policy for inbound traffic has been made available. This example includes the necessary rules for rate limiting incoming SSH connections and ICMP traffic. It is thoroughly explained and includes what are considered to be amongst some of the best firewall practices at the time of writing.

If you are managing a multi-user machine then you may also need to manage the locally-originating, outbound traffic. In this case take a look at the extensive information for iptables that is available on the Internet.

Use only well-proven remote access software

There are many different ways of gaining legitimate remote control of a Linux host, some of which are much more secure than others.

For command line "terminal" access OpenSSH is the modern and recommended tool. It uses high-strength encryption to provide a secure command channel so that at no time is any information sent over the network connection in a form that can be read by anybody other than the intended recipient. There are several free SSH clients for all major operating systems, such as PuTTY.

For a graphical "remote desktop" session the recommended approaches are the newer, fast NoMachine NX (using SSL encryption) and the old, slower X forwarding over SSH.

NX requires additional software to be installed on the server and the client. The server is free for a limited number of concurrent users [currently two - 15/1/07]. The client is free and exists for all major PC operating systems. It is simple to install and provides a very responsive desktop experience over a slow connection.

FreeNX is an open source alternative to the NX server software that is compatible with the standard NX client software and is not encumbered with the concurrent user access restrictions of the proprietary version. However, it is more complicated to install and configure that the commercial product.

Important: if you choose to install NoMachine NX you should replace the default keys used by clients to actually log into the NX server. This simple process will greatly increase the security of the installation and is thoroughly described in this article.

X forwarding over SSH requires no additional server software, but it is usually unbearably slow except on a LAN. On non-X-based systems (such as Windows) it requires the installation of additional X-server software such as Cygwin/X.

X forwarding over SSH is normally simple to configure requiring only a simple amendment on the server.

In /etc/ssh/sshd_config:

X11Forwarding yes

The use of any other remote access software should be evaluated carefully. You should certainly not use telnet which sends the entire session, including the login credentials, over the network as plain text.

Choose secure services that prevent password sniffing

Many services such as FTP, IMAP and HTTP have "secure" derivatives such as SFTP, IMAPS and HTTPS which require little or no more effort to configure and use.

Wherever possible, these should be used in preference to their more primitive versions especially where their traffic is carried over an insecure network such as the Internet or wireless. Insecure services should be disabled wherever possible.

Most insecure services that do not have a secure equivalent can be effectively tunneled over SSH with the use of a standard SSH client.

If your needs dictate that you must run a service that is inherently vulnerable to network sniffing then you should minimise the scope to which the service is presented, for instance by configuring the service and firewall to provide access from campus-only then using a secured on-campus access point.

For further consideration

If your time and resources permit then taking the following additional steps will further improve the security of a host above the baseline that is set out above.

Remote syslogging

Sending a host's syslogs in real-time to another host that is configured as a syslog collector will help you to identify the means of unauthorised entry if the host is compromised, even if the attacker erases the log files in an attempt to cover their tracks.

Consider using the sudo mechanism

If you are not already familiar with sudo, then it is very worthwhile to investigate the merits of this mechanism which allows you to entirely dispense with remembering the shared-secret of a root password.

This is a versatile system that allows an administrator to specify which users are permitted to elevate their privilege without knowledge of the root password. You can even specify exactly which commands a user can execute on behalf of root or some other user in order to give away only very specific privileges.

sudo adequately addresses the practical conflict that exists between a password being both strong and memorable. Because the root password need not be remembered, it can instead be extremely complex provided that it written down and locked up somewhere (physically) safe. Experienced administrators may wish to entirely dispense with the root password by locking the account, so that there is no longer a shared-secret to guess or steal.

Useful security tools

You should at least consider using the following tools. They have proven to be useful in many circumstances and are reasonably easy to configure and manage.

Samhain is a file integrity checking tool that can be configured to report (via syslog, email) any unanticipated modifications to system files. Tripwire provides similar functionality.

Tiger is an automated host security auditing tool that reports many common point of security weakness including bad file permissions, new SUID binaries and potential vulnerabilities in system configuration.

Cfengine and Puppet are not strictly speaking security tools but rather configuration management systems for maintaining multiple heterogeneous hosts. They require a lot of initial effort to set up but make it simple to update the security policy of all hosts and will report where any single host has diverged from the specified configuration. Once the infrastructure has been installed many tasks that were previously time consuming and prone to omissions become trivial; for instance configuring the firewall, SSH server and mail server for a new host is as simple as just connecting the host into the configuration system.



 Thanks   Ref :