From MicroFocusInternationalWiki
Revision as of 22:00, 8 November 2016 by Kgroneman (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Micro Focus International Wiki  |  SUSE  |  SLES  |  Hardening


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 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/ 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


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.

The following daily checks are done:

/etc/passwd check : length/number/contents of fields, accounts with same uid
                       accounts with uid/gid of 0 or 1 beside root and bin
/etc/shadow check : length/number/contents of fields, accounts with no password
/etc/group check  : length/number/contents of fields
user root checks  : secure umask and PATH
/etc/ftpusers     : checks if important system users are put there
/etc/aliases      : checks for mail aliases which execute programs
.rhosts check     : checks if users' .rhosts file contain + signs
homedirectory     : checks if homedirectories are writable or owned by
                       someone else
dot-files check   : checks many dot-files in the homedirectories if they
                       are writable or owned by someone else
mailbox check     : checks if user mailboxes are owned by user and unreadable
NFS export check  : exports should not be exported globaly
NFS import check  : NFS mounts should have the "nosuid" option set
promisc check     : checks if network cards are in promiscious mode
list modules      : just lists loaded modules
list sockets      : just lists open ports

The following weekly checks are done:

password check    : runs john to crack the password file, user will get an
                       email notice to change his password asap
rpm md5 check     : checks for changed files via rpm's md5 checksum feature
suid/sgid check   : lists all suid and sgid files
exec group write  : lists all executables which are group/world writeable
writable check    : lists all files which are world writable (incl. above)
device check      : lists all devices

The following monthly things are done:

The monthly file is not a diff like the daily/weekly ones but the full
reports in one file.

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:


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

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 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:

Installing a Secure Server with SUSE Linux Enterprise Server 9 and Novell AppArmor

There is also a FAQ:

The AppArmor project page

See also:


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.

Note: AIDE replaces tripwire(tm).


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.

The sites for the upstream projects are:

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


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

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.

For example:

iptables -N external

iptables -A external -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH

iptables -A external -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 600 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH BRUTE FORCE PROTECTION "

iptables -A external -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 600 --hitcount 4 --rttl --name SSH -j DROP

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:


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.


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

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.

Other resources

Unofficial hardening guides for SLES 8 and SLES 9 are available at

US National Security Agency (NSA) security materials for RHEL (Red Hat Enterprise Linux 5) is available. Although this has been written for RHEL rather than SLES, much of the material is applicable to SLES (but note that SELinux is not available in SLES 10). See: