Hardening a SLES server

Customers often request information about how to "harden" a SLES server: in
other words to set it up in such a way that it is less vulnerable to attack or
security threats than in the default installation.

The reasons for such a request vary. Understandably customers are concerned
about security breaches, and often their experience with other operating
systems, particularly in an internet-facing role, may not have been
encouraging.

However, it is not possible to react sensibly to a very general request from
management to "make these servers as secure as possible" without first making
a specific assessment of what the relevant security threats are in a
particular environment and what you want to achieve.

In practice, a fully patched internet-facing SLES system running a firewall
can be considered extremely safe from external and internal attack. Apart
from the threat from external malicious attackers, it is also important to
consider the possible potential threats from internal users and
administrators, both through error and deliberate action.

Fortunately, SLES provides various tools which can assist both in hardening
the system against external attack, and with detecting and auditing
undesirable changes to the system.

Permissions

Permissions on system files need to be set correctly so that a user or process
cannot make unauthorised changes to these files. This is a function of the
operating system installation. In general, provided you do not change
permissions on system files, all should be well. However, SUSE systems have
various levels of pre-set permissions, which are defined in the files
/etc/permissions, /etc/permissions.easy, /etc/permissions.local,
/etc/permissions.secure and /etc/permissions.paranoid. There are also some
permissions settings defined for the operation of particular programs in files
under /etc/permissions.d/

One might ask why it would ever be advisable to set less than the strictest
possible set of permissions. The answer is that on multi-user systems, the
strictest possible set of permissions will have an effect that prevents normal
non-root users from doing certain things that they need to do: accessing
particular devices (for example using a program to write to a CD), on a
desktop system shutting down the system, and so on.

There is an element of balance that has to be struck between locking the
system down tightly so that people cannot do the things that they need to do,
and leaving too many possibilities for bad things to happen.

To set one of the preset system-wide permissions settings, one can use YaST's
"Local Security" module (yast2 security), or they can be set manually in the
file /etc/sysconfig/security. You can create your own list of file
permissions (for example /etc/permissions.mysite) and then refer to this in
/etc/sysconfig/security just using the key word mysite. After making any
changes made in /etc/sysconfig/security, the program SuSEconfig should be run
so that the changes are applied to the system. If using the YaST "Local
Security" module, this will be done automatically on exit.

There are a small number of files that need to have SUID root permissions set:
such programs are a possible attack vector: you can check which files on the
system have SUID permissions with a command such as:

find / -type f -perm -u=s -ls

Files that are both executable and writable by others can be found using

find / -type f -perm -o=w,u=x -ls

seccheck

The file permissions checks mentioned above and a variety of others are
included in the functionality of the seccheck package, which runs various
tests on the system on a regular basis as cron jobs.

Chroot services

Certain services (FTP server, NTP, postfix, dhcpd, etc) can be run optionally
(in most cases this is the default) in a chroot environment. Running such
services chrooted ensures that any access to the server from outside can only
affect the part of the filesystem where that chroot system resides.

Security issues relating to particular services

If you are running services which allow direct access from the outside world,
you should take particular care that they are configured correctly. In
particular any server that allows FTP uploads should be tested and configured
with great care.

Password policies

The built-in tools on SLES already advise strong passwords. In addition
password change can be forced after a specific period of time using the chage
command or options in the useradd command.

Various password cracking tools are available: these can be used against the
encrypted passwords stored in /etc/shadow to check their strength.

The Linux-PAM Guides contain very good information about the use of the PAM
configuration in general, and examples of how to enforce policies regarding
passwords in particular (length, number of non-alphabetic characters required,
similarity to the previous password, etc). See:
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/

sudo

Accidental or malicious damage by systems administrators is a potential risk
that can easily be overlooked. The more people have root access to the
system, the greater the risk that damage can be done, whether deliberately or
accidentally. The sudo mechanism allows you to specify particular users and
particular commands that those users are allowed to run as root. For more
information see the man page for sudo. A short guide to sudo for openSUSE is
available at
http://en.opensuse.org/Administer_with_Sudo

If you wish to have a full audit trail of who has performed which actions on a
server, whether as root or not, you can disable root logins completely, and
insist that all administration is carried out using sudo sessions. In
combination with audit (see below), this provides the capability to maintain a
very full audit trail of who has done what.

Unnecessary programs and services

In general it is good practice to choose the smallest possible installation
set consistent with your intended use of the system. It is certainly not a
good idea to have services running that you are not using, because there is
always a possibility, however remote, that an attacker might be able to target
an open port on the system which does not actually need to be present. If you
are not going to run a service, it is better not to have it installed. So the
best plan is to start with a minimal installation pattern, and progressively
add the items that you know you will need. Do not, however, break package and
pattern dependencies to try to trim down your installation: this could affect
the installation in unexpected ways and render your system unsupported.

Apparmor

Apparmor is a powerful tool which can prevent an application with a security
vulnerability (or a maliciously replaced binary) from writing to files that it
should not be accessing. Profiles can be created for particular executables
on the basis of their normal operation, and then those profiles can be
enforced by Apparmor. If a profiled application is replaced by a malicious
version, or happens to contain a security hole that allows it to write to some
system file, Apparmor will prevent this from happening. Apparmor therefore
provides pre-emptive protection from potential (but still unknown) security
issues, and is an effective way of increasing the security of a server.

There is good documentation for Apparmor: chapter 48 of the SLES
Administration Guide describes the setup of Apparmour.

There is also a specific Apparmor manual which is available as the package
apparmor-admin_en for SLES 10, and a guide (written for SLES 9, but mostly
valid for SLES 10) is available online:

AIDE

AIDE is the Advanced Intrusion Detection Environment. It monitors changes in
files with the particular purpose of detecting changes that have been caused
by malware or security breaches. Typically AIDE creates a database immediately after
the system is installed. When AIDE is run after this, it reports on changes
that have taken place relative to the previous state. A configuration file
controls which files and directories you wish to monitor. Documentation is
included with the package.

logwatch

The logwatch package is available in the SLES 10 SDK. As such it is not a
supported package, but it is useful for parsing and analysing log files and
producing reports. Among other things this can be useful for reporting failed
login attempts, but it can be configured to report on any activity that gets
logged in the various system logs. Documentation is included with the
package.

Network security tools

For analysing network vulnerabilities, the tools nmap (port scanner) nessus (a
network vulnerability scanner, and snort (a network intrusion prevention and
detection system) are also available in the SDK.

For analysing network traffic more generally, the tools tcpdump, wireshark
(previously known as ethereal), iptraf and iftop can be very useful.

Firewalls

A server which is available from the internet should be protected either by
its own firewall or by a third party firewall that forwards packets to it. On
a SLES system you can create a firewall most simply using the SuSEfirewall2
package which creates iptables (netfilter) rules based on your own
specifications. You can also if you wish create your own script to set up the
iptables rules without using SuSEfirewall2. Any firewall rules you set up
should be thoroughly tested: the network security tools mentioned above can be
useful for this. Documentation on SuSEfirewall2 is included with the package,
and is also included in Chapter 43 of the SLES 10 manual. Extensive
documentation on the use of iptables is available at
http://www.netfilter.org/documentation/index.html

SSH configuration

By default SUSE systems install a configuration file for the SSH server
(/etc/ssh/sshd_config) that permits root logins over SSH. For an internet
facing server it is advisable to edit the file so that it contains the entry:
PermitRootLogin no

Automated brute force attacks against the SSH server are quite common: it is
possible to apply firewall rules that detect and prevent more than a defined
number of connection attempts from a particular host in a particular time
period.

These rules will prevent more than 4 connection attempts per 10 minute period
from a particular IP number.

If possible it is advisable to switch off username / password authentication
for SSH with the line

ChallengeResponseAuthentication no

Then only public/private key-pair authentication will be possible, and brute
force attacks cannot take place.

TCP Wrappers

Access to many services, including SSH can be controlled by TCP Wrappers to
limit access particular IP addresses or networks: see man tcpd for information
on how to configure the files /etc/hosts.allow and /etc/hosts.deny to enforce
this.

The audit package

The Linux kernel has auditing capabilities. The user-space tools in the audit
package allow an administrator to specify rules in the file
/etc/audit/audit.rules which will force the logging of matching events. So
any time that a specified program is run, or a particular file is read, the
audit daemon will log that activity to the file /var/log/audit/audit.log. The
tool ausearch will search that log file for specific information, and aureport
can create various report from the log file. The use of these tools together
with careful rules for sudo can create a highly detailed audit trail of all
activities on a server.
Novell documentation for the audit package is available at:
http://www.novell.com/documentation/sled10/pdfdoc/auditqs_sp2/auditqs_sp2.pdfhttp://www.novell.com/documentation/sled10/pdfdoc/audit_sp2/audit_sp2.pdf

compartm

The compartm package (available in the SDK) contains tools to force untrusted
executables to run in a sandboxed environment so that they cannot damage the
system.

chkrootkit

The chkrootkit package checks for signs of a rootkit (malicious software that
allows root access after entering the system via a vulnerability of some kind,
and probably changing certain system files). It is available from
http://www.chkrootkit.org/

Packages are available for openSUSE: it can be built from source for SLES if
necessary.

It is important to be aware, however that rootkits that also install or modify
the kernel as well as installing malicious versions of other files can in
principle be undetectable from the running system, and forensic analysis needs
to be done under the rescue system to detect (for instance) changed file checksums.