Customer Service and Booking Hotline: +44 (0) 845 672 0175

Search

Platform Hardening to Improve Security

Any IT system that is visible to the public, such as a web server or mail server, must be "hardened" to minimise the risk of successful attacks against it. This article outlines some of the key tasks and techniques...


Hardening is the process of preparing an operating system for use as a firewall or other public server by removing as many vulnerabilities as possible. The following areas need careful attention when hardening an operating system:

  • File System Security
  • User Account Security
  • Logging and Auditing
  • Removing Unnecessary Services
  • Running Essential Services with Unprivileged Accounts
  • Physical Security
  • Network Protocol Vulnerabilities

Traditionally services such as corporate firewalls, IDS, etc, have been installed and operated on UNIX systems, because of the higher reliability and “cleaner” implementation achieved. Increasingly Windows machines are being used to run these security applications also, and Linux is also a very popular choice as the base platform.

In the following sections, hardening of a Linux system is used as an example of some of the steps necessary. It is not possible to give a comprehensive or detailed treatment of system hardening in the time available; however examples of several key techniques are given. Fedora Linux is used in these examples.

Minimal Package Installation

Linux distributions commonly use the Redhat Package Management (RPM) structure to package executable and source code in a wrapper which makes installation, uninstalls, version control and management of dependencies easier for system administrators. A hardened system should contain only the packages necessary for its defined function, and overall management. Generally a critical server should be installed with a minimum server configuration, and then packages should be added as needed to implement the necessary functions.

The RPM utility allows installed packages to be identified, upgraded, added and removed, and also has a mode to test dependencies.

System Patching

Security patches must be tested and installed onto operational systems in a short time-frame once a patch becomes available. Microsoft provides an automatic update feature via a web site, and other operating systems provide a similar model. The Fedora Linux releases used in this course include the Yellowdog Update Manager (YUM) which simplifies the patching process and includes a schedule for checking repositories for updates, typically once per day.

The security policy and Standards for these systems should specify the process for obtaining, testing and deploying patches. Testing must be carried out on a captive system before deployment to ensure no functional problems are introduced by the patch; one argument for keeping such systems as simple as possible is the reduced risk of interoperability problems when such patches are deployed.

Detecting Listening Ports

It is important that tcp ports which are not required for normal operation are detected and closed; leaving these ports in listening mode is a major assistance to attackers attempting to compromise the system.

The netstat command can be used to identify listening ports, as shown in the example opposite.



Closing Unneeded Ports and Disabling Services

Services which are installed but should not be enabled by default should disabled in the system startup scripts. To check which services start at boot time, the following command can be used.

chkconfig --list | grep on

A service can be disabled interactively using the same utility, for example to disable telnet,

chkconfig telnet off

Services can also be started and stopped interactively using the various scripts in the /etc/init.d directory, and enabled and disabled at boot time using the /etc/rc files

Tuning The Linux Kernel

Linux has various kernel settings which improve security of the system. Some of the main ones are listed here. These parameters are stored in the /etc/sysctl.conf file

Enable SYN Cookies, to prevent DoS attacks using half-open connections.

net.ipv4.tcp_syncookies = 1

Disable IP Source Routing, to prevent diversion of traffic via an untrusted host

net.ipv4.conf.all.accept_source_route = 0

Disable ICMP Redirect, so that traffic cannot be diverted via an untrusted host

net.ipv4.all.accept_redirects = 0

Enable IP Spoofing Protection

net.ipv4.conf.all.rp_filter = 1

Ignore Ping Requests, as these can be used to verify machine address and operation

net.ipv4.icmp_echo_ignore_all = 1

Enable Logging of Suspicious Packets

net.ipv4.conf.all.log_martians = 1

Check File Permissions

Linux has a built in default set of permissions for file creation, and various scripts can be run to check for files with unexpected permissions.

Disable and Secure Accounts and Passwords

All system and third party accounts should be locked unless required. Linux implements a shadow password file, which holds encrypted versions of the plain-text passwords for accounts, rather than the plain-text versions. Historically, attackers would attempt to get a copy of the UNIX/Linux password file, giving complete access to the system. With shadow password files, this is no longer possible. Various scripts are available to check for accounts which are unlocked, and for accounts which are not using the shadow password file.

Password Ageing

System passwords should not include an expiry time, otherwise outages in key services can occur, however individual passwords should implement an ageing and re-use policy, and this policy should be in line with the security policy and standards for the system.

In Linux systems, the etc/login.defs file includes parameters to control the number of days a password is valid for, how often a user can change their password, the number of days after reminder that a password is disabled, etc. The settings for a specific account are visible in the shadow password file. Separate configuration files include options for enforcing passwords of arbitrary strength, and limiting password re-use.

Displaying Login Banners

It is important for practical and legal reasons that intruders onto systems for which they do not have rights of access are warned of the consequences.

To display a banner after a user logs onto a system successfully, the /etc/motd file should be used to show a suitable warning banner.





Bookmark this article

Share this article using the following sites:

Courses by category...

Glossary Search

Newsletter Sign-up

Our RSS Feeds...