- 1 Hardening a SLES server
- 1.1 Permissions
- 1.2 seccheck
- 1.3 Chroot services
- 1.4 Security issues relating to particular services
- 1.5 Password policies
- 1.6 sudo
- 1.7 Unnecessary programs and services
- 1.8 Apparmor
- 1.9 AIDE
- 1.10 logwatch
- 1.11 Network security tools
- 1.12 Firewalls
- 1.13 SSH configuration
- 1.14 TCP Wrappers
- 1.15 The audit package
- 1.16 compartm
- 1.17 chkrootkit
- 1.18 Other resources
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.paranoid. There are also some
permissions settings defined for the operation of particular programs in files
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
/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.
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.
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/
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 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: http://developer.novell.com/wiki/index.php/Apparmor_FAQ
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.
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.
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
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.
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
Then only public/private key-pair authentication will be possible, and brute force attacks cannot take place.
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.deny to enforce
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
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 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.
Unofficial hardening guides for SLES 8 and SLES 9 are available at http://www.suse.de/~thomas/SLES-Hardening/
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: http://www.nsa.gov/notices/notic00004.cfm?Address=/snac/os/redhat/rhel5-pamphlet-i731.pdf http://www.nsa.gov/notices/notic00004.cfm?Address=/snac/os/redhat/rhel5-guide-i731.pdf