Installation of a Secure SuSE Linux
Enterprise Server 9
Marc Heuse, SuSE Security Team, <marc (at) suse (dot) de>
Table of Contents
- 0
Introduction
- 1
Preparing the Infrastructure
- 2 Installing SLES9
- 3
Customizing the installation
- 4
The Running System
- 5 Last Words
- 6 Appendix
- Tools, Alternatives and Links
- 7 The
Author
Linux servers have proven themself as reliable and secure
bastions in the Internet world today. While many administrators do know
a lot about configuring their common systems, rarely all efficient
mechanisms are known or deployed - especially true if those are new
features.
This goal of this workbook therefore is to inform administrators about
the tuning parameters of the SuSE Linux Enterprise Server 9 (SLES9),
provided in an easy step-by-step guide, which gives guidance on various
issues. Any part can be skipped if the risk/threat scenario does not
apply to the server, to allow a customized security instalation. It
should be noted however, depending on the installation and your
specific needs security considerations of your system may not be
covered in this document in their full completeness. Therefore, system
administrators are encouraged to always closely evaluate their
configuration changes they make on their systems.
Please note that Linux offers a wide range of security
options, which you can use to fine-tune for system security. As this
guide can not cover all mechanisms, we will focus on the most efficient
ones.
If you want to install your SLES 9 conforming to the EAL 3+
certification, disregard this guide, and read through the "SLES
Security Guide" which is part of Service Pack 3, and use the script /usr/lib/eal3/bin/sles-eal3
for automatic reconfiguration.
1 Preparing
the infrastructure
A server is never installed without a purpose (or at least
should be). Such a purpose is usually providing one or more network
services to a user group. A server and the services it provides must be
placed in a proper environment. This part gives a short introduction
into the different zones and what security considerations should be
made within these. In order to guarantee the highest possible degree of
protection, security must consistently be implemented in each zone.
The infrastructure zone defines the position of the server within the network. This area must be protected from threats like data sniffing, network mapping, and port scanning. Furthermore, following a successful attack on an exposed web server, it should not be possible to use this server as a base for attacks on other important servers.
To this end it is important that all servers offering Internet
services are positioned in such a way that they are protected by a
central component and are located in a separate net. Such separated
networks are known as demilitarized zones (DMZ). The protective
component may be a complex firewall or a simple router for which
restrictive filter rules are configured - a measure which should
normally be adequate. Thereby access is only permitted to certain
server services. A very basic filter list might look like this, with a
web server as an example (whereof anything else should be denied):
| Filter Rules | |||
| Action |
From | To | Services |
|---|---|---|---|
| ALLOW |
any location | web server | HTTP, HTTPS, UDP highport, ICMP type 8 |
| ALLOW |
administrators | web server | SSH |
| ALLOW |
web server | router |
SSH (or telnet if not supported) |
| DENY |
any location |
router |
any service |
| ALLOW |
web server | any location | DNS, SMTP, ICMP type 0 |
| DENY |
any location |
any location |
any service |
A switch with port security and flood protection for the DMZ should be used by those endeavoring to establish an exceptionally high degree of security in this area.
If you are concerned about physical security you should make sure the server is installed in a secure room or data processing center and that all power, telephone, and network lines are physically protected from access.
2. The Network Protocol ZoneInternet communication takes place almost exclusively by means of TCP/IP. The kernel of the operating system is responsible for communication and ensures a transparent communication flow. However, some functions and vulnerable points of the protocols can be misused for attacks or sabotage. Therefore the kernel must be configured in such a way that it can ward off such attacks. Though a firewall or router in front of the server may help to prevent many attacks, some web server settings need to be adjusted.
The prevention of SYN flooding attacks is essential. Among all operating systems, Linux provides the most effective solution, which is called SYN cookies. Moreover, ICMP redirects and pings on broadcast addresses should not be accepted and IP source routed packets should be declined. Use of additional kernel filter functions will increase the security level.
3. The Service ZoneThe service zone defines which services are required. Only services necessary for operation should be configured on servers, since otherwise the attacker will be provided with additional vulnerable spots.
Only services guaranteeing a sufficient level of security should be used: Services with insufficient authentification (e.g. rexec) or services transmitting sensitive data without encryption (e.g. telnet, ftp, or credit card details via WWW) should be replaced with secure services (e.g. SSH, SSLftp, or HTTPS).
4. The Application ZoneEach service must individually be configured for security. An incorrectly configured mail service can be used for spamming, a web server for the execution of all kinds of commands. High-privilege services (root) should not be established.
Available manuals of the software being used should be checked for any information on this subject.
5. The Operating System ZoneThe final protective mechanism is the operating system itself.
If the security measures for the application zone are applied
consistently, the attacker will not have any administrative
authorization even if he succeeds to penetrate the computer.
Installation of programs, especially privileged programs, should be
limited to those absolutely necessary for the operation of the system.
Many privileged programs can also be deprived of high-level
authorizations, since these are not needed by the standard user
accounts in the system. But that is not enough. In case an attacker
successfully penetrates the system, there should be mechanisms that
detect the intrusion. This is called "host-based intrusion detection."
It should also be possible to monitor and record file manipulations in
the system. Regular backups should not be neglected, whereas old
backups are not to be discarded! This not only helps to configure
backup servers and to avoid data losses, it also enables tracking of
manipulations in the system. If several administrators supervise the
server, a mechanism recording who executed which action should be
available for later reference.
After booting from CD and selecting "New Installation", there are three install options we can choose which can enhance the security of the system: Partitioning and Software.
For each filesystem you should use either ext3 ot reiserfs for
enhanced reliability. The following six partitions should be
created: /, /var, /tmp, /home, /svr, and
/usr/local. More can be created if necessary.
If the log files are flooded, neither the service nor the system should
be impaired, therefore /var should be a seperate partition.
If logging is mandatory for the application for security reasons, it
should stop providing it's service until it can log again. The /tmp
directory can be flooded by accident or on purpose as it is writable by
everyone, and therefore could impair system and service stability as
well. User /home and the service directories /svr should
be separated for the same reason. And finally keeping /usr/local
seperate makes updating the Installation easy, if you want to reinstall
the system from scratch with the upcoming SLES9.
The following table gives you an indication on the special
security flags you might set on each partition. A questionmark
indicates that some software might not work if this flag is set.
| Mount point |
Mount options |
| / |
|
| /var |
nosuid |
| /tmp |
nosuid |
| /home |
nosuid, nodev, noexec? |
| /svr |
nosuid?, nodev?, noexec?,
ro? [after installation] |
| /usr/local |
nosuid?, nodev?, ro? [after installation] |
Please note that proprietary software might fail with it's
installation process if files in /tmp can not be suid,
devices do not work in /usr/local, etc. - however this is a
very bad and insecure habit of software producers.
In such cases, remount those paritions temporarily with security
deactivated.
| Package |
Description |
| acct |
Process accounting (for
auditing purposes) |
| arpwatch |
Detect ARP spoofing on the
LAN |
| compartm |
Tool to run services in a
security compartment |
| laus pam-laus |
LAUS (Linux
Auditing-Subsystems), enables fine-grained auditing mechanisms on SLES |
| checkpolicy policycoreutils |
SELinux (Secure Linux
Enhancements) |
| freeswan ipsec-tools |
IPSEC (VPN) software |
| logsurfer |
Check logs, perform
automatic actions, etc. |
| scanlogd |
Detect port scanning |
| seccheck |
Daily, weekly and monthly
security checks |
| snort |
A powerful network
intrusion detection tool |
| stunnel |
An SSL wrapper for
unencrypted services |
| sudo |
Replacement for su -
define which administrator is allowed to do what |
| tripwire |
A file integrity checker |
| xntp |
Network time tools |
| yast2-online-update |
For online updates |
Hint: also select a text editor which suits you!
When you are finnished with selecting the software, start installing the system.
2.3 System Settings
After the basic installation is done, you are asked for a root password. Select a strong and hard to guess password and then press "Expert Options". In this sub menu, choose MD5 encryption/hashing of the passwords.
In a later screen, you can then add an user account. Here go into the "Password Settings" and change the settings for the maximum number of days for a password to a value between 30 and 100, and the value for how many days a login with an expired password is usable to a number less than 30.
3 Customizing the Installation
3.1 Software Packages3.1.1 Removing Packages
After the installation process is finnished, you might want to remove some unnecessary software packages.
With "rpm -e PACKAGE" you can remove the following:
- cpp
- rsh (insecure)
3.1.2 Updating Packages
Before configuring anything check whether updates are
available for any of the installed packages and install the updates, if
necessary. You can do this with an online update (just start yast2
-> software -> online update) as well, however it is recommended
that you do not connect the server to the network, until all packages
are up to date.
Therefor downloading the relevant rpms, writing them to a media, and
installing the updates from there onto the server is the secure way to
go.
Update information can be found at the Updates, Patches, Bugfixes pages.
3.2.1 Disabling Services
If your server is neither offering nor accessing any RPC service, you can disable portmap by:
3.2.2 Enabling Services
If you want to enable the following services, you can perform this by typing "insserv SERVICE"
| Service |
Description |
| acct |
Activate process accounting |
| arpwatch |
ARP spoof detector |
| scanlogd |
Port scan detector |
| snort |
Network intrusion detection |
| SuSEfirewall2_init SuSEfirewall2_setup SuSEfirewall2_final |
Firewalling |
3.2.3 Harden Services
Beside the services you enabled in the section before, there should be just one other service running now, and this is SSH.
Hardening OpenSSH service requires two steps:
1. TCP Wrapper Setup
First of all, deny any access to any service with TCP wrapper support which is not from localhost:
And in the next step, add the IP addresses from which logins a permitted, e.g. from a single host and a subnet:
Please note that you should only use IP addresses and not DNS names!
For more information, please check out "man 5 hosts_access".
2. SSHD config
Then edit /etc/ssh/sshd_config and add/change the following lines:
X11Forwarding no
UsePrivilegeSeparation yes
Banner /etc/issue.net # Do not forget to perform step 3.3.1 below!
3.3 System Hardening
3.3.1 Login
Now we set login and password security parameters. Edit /etc/login.defs and change the following lines:
PASS_MIN_LEN 7
UMASK 077
Then we want to display a warning message for authorized usage. Please change this example message to your corporate standard and local law requirements.
# cat > motd
Unauthorized logins and misuse of this system is prohibited!
^D
# rm issue issue.net
# ln -s motd issue
# ln -s motd issue.net
3.3.2 Permissions
In a default SLES9 installation, about 50 suid binaries are installed. All these provide a security risk for local attackers. Therefore the filesystem permissions have to be hardened. Thankfully, this is easy on SuSE Linux:
Just change the PERMISSION_SECURITY parameter line in /etc/sysconfig/security to
and then run "SuSEconfig".
The system can be stripped of further privileged suid and sgid programs. This is simply done by entering programs which are not supposed to have these privileges any longer in /etc/permissions.local and subsequently starting SuSEconfig.
3.3.3 PAMAll login mechanisms (should) use the Pluggable Authentication Mechanism (PAM). The default configuration is fine except that it allows logins with accounts that have no passwords set. This is no a good security thing to do, therefore this has to be changed by:
perl -pi -e 's/nullok//' /etc/security/pam_pwcheck.conf
perl -pi -e 's/nullok//' /etc/security/pam_unix2.conf
3.3.4 sudo
Each of the administrators should have an own user account, since it would be impossible to know who did what when working under the root identity. Besides, the incorrect entry of a command under root can effect the whole system. Therefore, operations with high levels of authority should only be done when really necessary. A direct root login over the network has already been made impossible as a result of the modifications of the SSH service, and the administration itself can only be performed in an encrypted manner with SSH. The next step in this process is to configure sudo - a program which helps the administrators to do their job while at the same time keeping a record of the commands. This program also enables a detailed authorization structure, e.g. as user oracle, user A is entitled to restart the data base and view the system log files under root, but nothing else. Subsequently the administrators' user accounts are admitted to sudo by means of the visudo program. The following line which allows the administrator to do whatever he wishes is added in the editor
username ALL=(ALL) ALL
"man 5 sudoers" defines a host of settings with which the authorizations can be restricted.
Of course it is important that the administrators use sudo and do not shift to the root identity with "su root"; for this reason, the root password should be disclosed to as few people as possible.
3.3.5 SyslogLog data is very important. All important log messages from the web server and the router should be sent to a central log host from where the status of the computers can be monitored. In this way it will be difficult for an attacker to hide his trail.
To send all log messages to a central loghost, add the following line to /etc/syslog.conf :(Please note that you have to enable remote reception at the central loghost by adding the -r switch to syslogd. You can do this in /etc/sysconfig/syslog.)
3.3.6 ntp
There is a saying which is "logs are only as good as their timestamp". If you want to correlate events from different machines or log sources (e.g. router, firewall, proxy logs, etc.) this can be impossible to do.
Therefore one server should provide the time for all other servers. The easiest way to connect to this time server is by running a cron job which syncronizes the time.
cat > /etc/cron.hourly/ntpdate
#!/bin/bash
MAILTO=""
/usr/sbin/ntpdate <IP address of time server>
^D
chmod 700 /etc/cron.hourly/ntpdate
3.3.7 Boot Security
If the server also needs to be protected from local attacks,
the Grub boot loader must be equipped with a password, to protect from
selecting different root systems, init processes etc.
This is achieved by entering the grub commandline interface, and then:
# grub
grub> md5crypt
Password: **********
Encrypted: $1$4f34f...some.hash...
grub> quit
# echo 'password --md5
$1$4f34f...some.hash...' >> /boot/grub/menu.lst
Note that the echo command uses single quotes!
Hint: If you start gpm ("rcgpm start")
beforehand, the copy paste mechanism will be easier with a mouse.
Please read the grub information pages ("info grub") on more security
features, e.g. menu locking.
In this section we explore some not so common security measures.
First we edit /etc/inittab. You should disable the crlaltdel and keyboardrequest functionality by commenting them out:
#kb::kbrequest:.........
If you want to have a last resort login via the seriell port, add the following line:
S0:1235:respawn:/sbin/agetty -L 57600 ttyS0 xterm
Note that you have to put the seriell port into root's allowed login list, e.g. by "echo ttyS0 >> /etc/securetty".
If you are not using SuSEfirewall2 (which you should), create this script to secure your TCP/IP settings:
#!/bin/sh
#
# /etc/init.d/interface_security
#
### BEGIN INIT INFO
# Provides: interface_security
# Required-Start: $network $local_fs
# X-UnitedLinux-Should-Start: route dhclient dhcpcd named
# Required-Stop: $local_fs
# X-UnitedLinux-Should-Stop:
# Default-Start: 3 4 5
# Default-Stop: 0 1 2 6
# Short-Description: Secure TCP/IP settings
# Description: This script performs extensive TCP/IP security settings
### END INIT INFO
# basic security
echo 0 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 1 > tcp_secure_pmtu 2> /dev/null
echo 0 > /proc/sys/net/ipv4/tcp_ecn 2> /dev/null
for i in /proc/sys/net/ipv4/conf/*; do
echo 0 > $i/accept_redirects
echo 0 > $i/secure_redirects
echo 0 > $i/accept_source_route
# The following line should be commented out, if you use IPSEC !!!
echo 1 > $i/rp_filter
echo 0 > $i/mc_forwarding 2> /dev/null
done
# For more security
for i in /proc/sys/net/ipv4/conf/*; do
echo 1 > $i/log_martians
echo 0 > $i/bootp_relay
echo 0 > $i/proxy_arp
done
# Configure the following values to your needs!
echo 16384 > /proc/sys/net/ipv4/ip_conntrack_max
echo 5 > /proc/sys/net/ipv4/icmp_echoreply_rate
echo 5 > /proc/sys/net/ipv4/icmp_destunreach_rate
echo 5 > /proc/sys/net/ipv4/icmp_paramprob_rate
echo 6 > /proc/sys/net/ipv4/icmp_timeexceed_rate
echo 20 > /proc/sys/net/ipv4/ipfrag_time
echo 1 > /proc/sys/net/ipv4/igmp_max_memberships
echo "1024 29999" > /proc/sys/net/ipv4/ip_local_port_range
^D
# insserv interface_security
3.4 Service Hardening
3.4.1 Apache
The web software and the pages are the core to protect. We need to make sure nobody gains unauthorized access to data or even changes the pages. For this purpose the pages are equipped with a special protection and then the Apache is furnished with a secure configuration.
All pages must be supervised by the site administrator and should be locally write-protected for everybody except him. It is important that the web server is run under a different user than the one supervising the pages. In this way an attacker who manages to leak through the web will not be able to change the pages. Therefore a user is set up and a cron job is generated which makes sure every day that all pages belong to the site supervisor and have the correct authorizations.
# useradd -m wwwdocs
# cat > /etc/cron.daily/wwwdocs
#!/bin/sh
/bin/chown -R -h wwwdocs /srv/www/*
/bin/chmod -R go-w /srv/www/*
/bin/chmod -R a+r /srv/www/*
^D
# chmod 700 /etc/cron.daily/wwwdocs
Since the Apache probably has already been
pre-configured, few changes will be necessary in the configuration.
If you use Apache 2.x, you should
reconfigure it as follows:
First we edit /etc/sysconfig/apache2, and change the following paramter to:
APACHE_MODULES="access actions
aliases autoindex auth env expires include log_config mime negotiation
setenvif ssl"
APACHE_SERVERSIGNATURE=off
APACHE_SERVERTOKENS=ProductOnly
After this, run "SuSEconfig" and "rcapache2 start"
If you use Apache 1.x, you should
reconfigure it as follows:
First we edit /etc/sysconfig/apache, and change the following paramter to:
ENABLE_SUSECONFIG_APACHE=no
This way, we can tighten down the
configuration file ourselves.
Then we change /etc/httpd/httpd.conf file. Most
important is that we hide the server signature, disable all CGI
executes and remove all unnecessary modules. You can save the following
diff -u0 output into a file, and use it for patching (cd /etc/httpd/httpd.conf; patch < PATCH).
Please note that some parts of this patch will fail - depending on the
modules you installed. The failed junks can safely be ignored.
---
httpd.conf.orig 2005-01-23 18:06:55.095112792 +0100
+++ httpd.conf 2005-01-23 18:17:32.999136640 +0100
@@ -238,2 +238,2 @@
-LoadModule status_module
/usr/lib/apache/mod_status.so
-LoadModule info_module
/usr/lib/apache/mod_info.so
+#LoadModule status_module
/usr/lib/apache/mod_status.so
+#LoadModule info_module
/usr/lib/apache/mod_info.so
@@ -243 +243 @@
-LoadModule cgi_module
/usr/lib/apache/mod_cgi.so
+#LoadModule cgi_module
/usr/lib/apache/mod_cgi.so
@@ -247 +247 @@
-LoadModule speling_module
/usr/lib/apache/mod_speling.so
+#LoadModule speling_module
/usr/lib/apache/mod_speling.so
@@ -250,1 +250,1 @@
-LoadModule rewrite_module
/usr/lib/apache/mod_rewrite.so
+#LoadModule rewrite_module
/usr/lib/apache/mod_rewrite.so
@@ -257,2 +257,2 @@
-LoadModule proxy_module
/usr/lib/apache/libproxy.so
-LoadModule cern_meta_module
/usr/lib/apache/mod_cern_meta.so
+#LoadModule proxy_module
/usr/lib/apache/libproxy.so
+#LoadModule cern_meta_module
/usr/lib/apache/mod_cern_meta.so
@@ -268 +268 @@
-Include /etc/httpd/suse_loadmodule.conf
+#Include /etc/httpd/suse_loadmodule.conf
@@ -285,2 +285,2 @@
-AddModule mod_status.c
-AddModule mod_info.c
+#AddModule mod_status.c
+#AddModule mod_info.c
@@ -288 +288 @@
-AddModule mod_autoindex.c
+#AddModule mod_autoindex.c
@@ -290 +290 @@
-AddModule mod_cgi.c
+#AddModule mod_cgi.c
@@ -292 +292 @@
-AddModule mod_imap.c
+#AddModule mod_imap.c
@@ -297,1 +297,1 @@
-AddModule mod_rewrite.c
+#AddModule mod_rewrite.c
@@ -304,2 +304,2 @@
-AddModule mod_proxy.c
-AddModule mod_cern_meta.c
+#AddModule mod_proxy.c
+#AddModule mod_cern_meta.c
@@ -321 +321 @@
-Include /etc/httpd/suse_addmodule.conf
+#Include /etc/httpd/suse_addmodule.conf
@@ -329 +329 @@
-ExtendedStatus On
+ExtendedStatus Off
@@ -467 +467 @@
- Options Indexes -FollowSymLinks +Includes
MultiViews
+ Options None
@@ -847,2 +847,2 @@
-Options +ExecCGI -Includes
-SetHandler cgi-script
+Options None
+#SetHandler cgi-script
@@ -1346,2 +1346,2 @@
-SSLRandomSeed startup builtin
-SSLRandomSeed connect builtin
+#SSLRandomSeed startup builtin
+#SSLRandomSeed connect builtin
@@ -1349 +1349 @@
-#SSLRandomSeed startup file:/dev/urandom 512
+SSLRandomSeed startup file:/dev/urandom 512
@@ -1351 +1351 @@
-#SSLRandomSeed connect file:/dev/urandom 512
+SSLRandomSeed connect file:/dev/urandom 512
@@ -1387 +1387 @@
-SSLCipherSuite
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
+SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM
@@ -1555 +1555 @@
-Include /etc/httpd/suse_include.conf
+#Include /etc/httpd/suse_include.conf
You might need to disable mod_user if this was enabled before.
After you hardened the configuration, enable CGI/PHP modules and
directories if required. Of course you also should change the
MinSpareServers, MaxSpareServers, StartServers, and MaxClients options
to have a good performing web server!
The option MaxClients helps to ward off connect-denial-of-service attacks. A word of caution: if this option is set to low, regular visitors will be denied access, if too high, the administrator will have difficulties logging on and taking countermeasures in the event of an attack. In order to find the correct value there is no other way than just trying.
The activation of SSL and the generation of the certificate is described in the files /usr/share/ doc/packages/apache/README.SUSE and /usr/share/ doc/packages/apache/README.SSL .
Clue: The SSL certificate should be protected with a
password so that an attacker does not have the possibility to copy and
misuse it following a successful invasion (this is unlikely to happen,
howerver ...!). However, this requires the web administrator to log on
to start/restart apache.
As a general rule, make sure that no Symlinks are used anywhere, so disable the option FollowSymLinks. CGI should only be found in the cgi-bin directory and should not be permitted or even executed anywhere else (therefore do not use the configuration option ExecCGI on any other directory).
In case certain document areas are to be off-limits, the following lines can be added in a file called .htaccess in the individual directories:
order deny,allow
deny from all
3.4.2 Postfix
If you want to run a mail server on your system, make your
necessary configuration (domains accepted, relays, etc.) and then make
the following changes to /etc/sysconfig/postfix
to chroot postfix and configure medium SPAM protection:
POSTFIX_CHROOT="yes"
POSTFIX_UPDATE_CHROOT_JAIL="yes"
POSTFIX_RBL_HOSTS="blackholes.mail-abuse.org, relays.ordb.org,
relays.osirusoft.com"
POSTFIX_BASIC_SPAM_PREVENTION="medium"
3.4.3 Squid
For security squid, which provides web and ftp proxy service,
edit /etc/squid/squid.conf.
By default, squid does only proxy for localhost clients. So first make
your necessary configuration changes for your requirements.
If this is a stand-alone proxy, means it does not need to
communicate to other proxies, disable the ICP feature. Add the
following line:
icp_access deny all
3.4.4 DHCPD
Thankfully, the DHCP service is already secure out-of-the-box
within SLES, and you don't have to configure anything else than your
DHCP network setup.
However, if you want to use DHCP in your network, beware of the
following security hazards:
- It is easy for an attacker in the LAN to deplete the IP ressources with tools like thcrut. New (valid) clients requesting an IP address can not be served then, and won't be able to connect to any resource.
- It is even easier for an attacker in the LAN to set-up a fake dhcp service, which competes with your valid server. This too can disrupt your network.
Given that the mentioned denial-of-service attacks are rare, it is recommended to use it for workstations and mobile equipment.
There are no really interesting security settings for DHCP
clients, however the risks of receiving wrong IP addresses, default
routers, time and dns servers should be kept in mind.
3.5.1
Firewalling with SuSEfirewall2
In the following example, we have just one interface, and provide web and web via SSL services to the public, and SSH access to an administrator subnet. Change the following values:
FW_SERVICES_EXT_TCP="80 443" # Config/Query number 9
FW_TRUSTED_NETS="10.10.0.0/24, tcp,22" # Config/Query number 10
The command /sbin/SuSEfirewall2 updates the rules. These will be loaded with each booting cycle.
3.5.2 seccheckIf you install the seccheck package your system is automatically checked for system changes. Most are performed daily and the more time and resource consuming ones weekly. When run for the first time, you get an overview of the system, and thereafter a change to the snapshot before.
Monthly a complete overview is generated.
All reports are sent via email to root.
3.5.3 compartment
Compartment is a tool to securely run untrusted services and programs. It support chrooting, changing user/group IDs, linux capabilities, init scripts, etc.
You can use this tool to securely run all your network services, which are not running in a chroot enviroment already. The /usr/share/doc/packages/compartm/README also shows some examples for squid and bind.
3.5.4 tripwire
Having completed all work on the system, the program tripwire
should be used to generate a data base containing the checksums of all
files.
First, create the /etc/tripwire directory. The configuration is not
easy, see "man twconfig" and "man twadmin" on how configure tripwrite
to your installation.
Before connecting to the Internet, the /etc/tripwire/ directory and contents plus the tripwire.rpm should be saved on a secure medium (e.g. CD-ROM).
In case an attacker is suspected of having manipulated the
system, tripwire can be used to track the manipulations.
However, this should be done in regular intervals, since there is no
other way to bust intelligent attackers ...
If you have the suspicion that the server was compromised, you
should boot from the SLES CD1, mount the CD-ROM with the tripwire
information, install the tripwire.rpm, and copy the database and config
file to their corresponding directories. Only then perform the
integrity verification!
Otherwise an attacker can hide his modifications, e.g. by changing the
tripwire database, the tripwire binary, libc, installing a kernel
module, etc.
You have the option to run a process and permission audit system, called "laus".
As it is very powerful, an introduction would go to far for this document. Please check out the it's documentation with "man 7 laus".
3.5.6 Miscellaneous
What else can be done:
- The ext2/ext3 file system flags "append-only" and "imutable" (by means of the chattr command) can be used for defining the kernel capabilities in order to protect log or boot files etc. from changes.
All log messages should be sent to a central loghost - this includes application file logs.
These have to be reviewed regulary to identify attacks and intrusions. As the amount of messages can be overwhelming, tools like swatch and others can help you removing all the unintersting stuff.
If you do not check your logs, system stability and security will not be strong!
4.2 Updates
Update regulary. Subscribe to the important mailing lists (see below) and install security patches as soon as possible. This can be done by starting yast2 and then select software, and then online update.
Without in-time updates, your system will be compromised sooner or later! 98% of all successful intrusions can be prevented if security patches are installed asap!
4.3 Staying up to date with security information
But we are not through yet. All administrators should subscribe to the most important mailing lists:
suse-security: SUSE discussion list containing security-related subjects; security announcements - to subscribe, send a blank e-mail to suse-security-subscribe@suse.comsuse-security-announce: only security announcements - to subscribe, send a blank e-mail to suse-security-announce-subscribe@suse.com
bugtraq: Discussion list addressing the latest security problems - to subscribe, send a blank e-mail with the following content to listserv@securityfocus.com: "subscribe bugtraq surname@firstname"
Keep an eye on your system and logs - and have a lot of fun!
6 Appendix - Tools,
Alternatives and Links
The following tools were developed by SUSE and can be downloaded free of charge:
|
SUSE Security Software |
||||
| Name of program (rpm) | Function | Included in the SUSE distribution since | Works on other Linux distributions, too | Download |
| SUSE Firewall2 (firewall) | A packet filter which also creates complex firewall systems and which is very easy to configure | 6.3 | Yes (for other distributions, init.d and startup scripts must be adapted) | SUSE FTP server |
| Security Checker (seccheck) | Checks the local security on a daily basis | 6.2 | Usually | SUSE FTP server |
| Compartment (compartm) | Security wrapper for programs, supports chrooting, assignment of priviledges and capabilities | 7.0 | Yes | SUSE FTP server |
| laus | Kernel audit module |
SLES8 SP3 |
Yes | SUSE FTP server |
| Security Library (-) | A library for programmers which provides secure function prompts for insecure functions | planned for ? |
Yes | SUSE FTP server |
Additionally, there are the security mailing lists suse-security and suse-security-announce as well as a comprehensive chapter about security in the SUSE LINUX Manual accompanying the distribution.
|
[1] SUSE security page: http://www.suse.de/security |
 |
For the past eight years, the author has been active
exclusively in the field of IT-Security. He had been head of the SUSE
Security Team for two years. In his main job, he is team leader of
n.runs, the european leading company for application audits and
software reverse engineering. He also loves cats and has difficulties
writing about himself in the third person.