Installation of a Secure Server with SLES8

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 8 (SLES8), 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 8 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.

1. The Infrastructure 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 Zone

Internet 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 Zone

The 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 Zone

Each 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 Zone

The 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.

2 Installing SLES8

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.

2.1 Partitioning

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, nodev
/tmp	nosuid, nodev
/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.

2.2 Software Packages

Select minimal system, and then add manually the rpm packages you require for the services. Might also want to select the following packages:

Package	Description
acct	Process accounting (for auditing purposes)
arpwatch	Detect ARP spoofing on the LAN
compartm	Tool to run services in a security compartment
scanlogd	Detect port scanning
seccheck	Daily, weekly and monthly security checks
snort	A powerful network intrusion detection tool
sslwrap	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.

The next screen then offers you to add a 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 Packages
3.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
dhcpcd (if the server is not needing DHCP for receiving its IP address - a server should never use client DHCP)
finger
gfxboot
rsh (insecure)

Several more packages can be removed if not required by your needs or usability. So check out the remaining packages with the command "rpm -qa"

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 Standard Services

3.2.1 Disabling Services

If your server is neither offering nor accessing any RPC service, you can disable portmap by:

# insserv -r portmap

As atd is usually not used either, remove this as well:

# insserv -r atd

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:

# echo "ALL : ALL" >> /etc/hosts.deny

And in the next step, add the IP addresses from which logins a permitted, e.g. from a single host and a subnet:

# echo "sshd : 10.0.0.10 10.10.10.0/24" >> /etc/hosts.allow

And finally, allow everything which comes from the localhost. This can be required for portmap local mounts and other things:

# echo "ALL : 127.0.0.1" >> /etc/hosts.allow

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:

PermitRootLogin no
X11Forwarding no
UsePrivilegeSeparation yes

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_MAX_DAYS 60 # a value between 30 and 100
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.

# cd /etc
# 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

You can further fine tuning of user and login security by using the access.conf, chroot.conf and limits.conf files in the /etc/security directory. Here you can define which users are allowed to login from where, to chroot to which directory and what system resource limits to apply to them.

3.3.2 Permissions

In a default SLES8 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

PERMISSION_SECURITY="secure local"

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 PAM

All 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//' cd /etc/pam.d && perl -pi -e 's/nullok//' *
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 Syslog

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

*.* @IP-ADDRESS-OF-LOGHOST

(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.

3.3.8 Miscellaneous

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:

#ca:.ctrlaltdel:......
#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:

# cat > /etc/init.d/interface_security
#!/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.

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	2003-11-27 11:17:44.000000000 +0100
+++ httpd.conf	2003-11-27 11:55:59.000000000 +0100
@@ -238,4 +238,4 @@
-LoadModule status_module      /usr/lib/apache/mod_status.so
-LoadModule info_module        /usr/lib/apache/mod_info.so
-LoadModule includes_module    /usr/lib/apache/mod_include.so
-LoadModule autoindex_module   /usr/lib/apache/mod_autoindex.so
+#LoadModule status_module      /usr/lib/apache/mod_status.so
+#LoadModule info_module        /usr/lib/apache/mod_info.so
+#LoadModule includes_module    /usr/lib/apache/mod_include.so
+#LoadModule autoindex_module   /usr/lib/apache/mod_autoindex.so
@@ -243 +243 @@
-LoadModule cgi_module         /usr/lib/apache/mod_cgi.so
+#LoadModule cgi_module         /usr/lib/apache/mod_cgi.so
@@ -245,3 +245,3 @@
-LoadModule imap_module        /usr/lib/apache/mod_imap.so
-LoadModule action_module      /usr/lib/apache/mod_actions.so
-LoadModule speling_module     /usr/lib/apache/mod_speling.so
+#LoadModule imap_module        /usr/lib/apache/mod_imap.so
+#LoadModule action_module      /usr/lib/apache/mod_actions.so
+#LoadModule speling_module     /usr/lib/apache/mod_speling.so
@@ -257 +257 @@
-LoadModule proxy_module       /usr/lib/apache/libproxy.so
+#LoadModule proxy_module       /usr/lib/apache/libproxy.so
@@ -268 +268 @@
-Include /etc/httpd/suse_loadmodule.conf
+#Include /etc/httpd/suse_loadmodule.conf
@@ -285,4 +285,4 @@
-AddModule mod_status.c
-AddModule mod_info.c
-AddModule mod_include.c
-AddModule mod_autoindex.c
+#AddModule mod_status.c
+#AddModule mod_info.c
+#AddModule mod_include.c
+#AddModule mod_autoindex.c
@@ -290 +290 @@
-AddModule mod_cgi.c
+#AddModule mod_cgi.c
@@ -292,3 +292,3 @@
-AddModule mod_imap.c
-AddModule mod_actions.c
-AddModule mod_speling.c
+#AddModule mod_imap.c
+#AddModule mod_actions.c
+#AddModule mod_speling.c
@@ -321 +321 @@
-Include /etc/httpd/suse_addmodule.conf
+#Include /etc/httpd/suse_addmodule.conf
@@ -329 +329 @@
-ExtendedStatus On
+ExtendedStatus Off
@@ -409 +409 @@
-ServerAdmin webmaster@linux.local
+ServerAdmin WEBMASTER@YOURDOMAIN.COM
@@ -430 +430 @@
-ServerName linux.local
+ServerName SERVERNAME
@@ -451 +451 @@
-    Options -FollowSymLinks +Multiviews
+    Options -FollowSymLinks -Multiviews
@@ -476 +476 @@
-    Options Indexes -FollowSymLinks +Includes MultiViews
+    Options -Indexes -FollowSymLinks -Includes -MultiViews -ExecCGI
@@ -488,0 +489 @@
+    # Add "Deny from ..." hereh if you want to restrict access based on IP addresses
@@ -504 +505 @@
-	Options -FollowSymLinks +Includes +MultiViews
+	Options -FollowSymLinks -Includes -MultiViews
@@ -757 +758 @@
-ServerSignature On
+ServerSignature Off
@@ -809 +810 @@
-    Alias /manual/ "/srv/www/htdocs/manual/"
+#    Alias /manual/ "/srv/www/htdocs/manual/"
@@ -811,6 +812,6 @@
-    
-        Options Indexes FollowSymlinks MultiViews
-        AllowOverride None
-        Order allow,deny
-        Allow from all
-    
+#    
+#        Options Indexes FollowSymlinks MultiViews
+#        AllowOverride None
+#        Order allow,deny
+#        Allow from all
+#    
@@ -856,2 +857,3 @@
-Options +ExecCGI -Includes
-SetHandler cgi-script
+# Remove the hashes below to enable CGIs. First clean up the CGI directory of default scripts!
+#Options +ExecCGI -Includes
+#SetHandler cgi-script
@@ -1172 +1174,3 @@
-#ErrorDocument 500 "The server made a boo boo.
+# 
+# Change the message or use the local/external redirect feature.
+ErrorDocument 500 "Not found. Do not try this again.
@@ -1386,2 +1390,2 @@
-SSLRandomSeed startup builtin
-SSLRandomSeed connect builtin
+#SSLRandomSeed startup builtin
+#SSLRandomSeed connect builtin
@@ -1389 +1393 @@
-#SSLRandomSeed startup file:/dev/urandom 512
+SSLRandomSeed startup file:/dev/urandom 512
@@ -1391 +1395 @@
-#SSLRandomSeed connect file:/dev/urandom 512
+SSLRandomSeed connect file:/dev/urandom 512
@@ -1595 +1599 @@
-Include /etc/httpd/suse_include.conf
+#Include /etc/httpd/suse_include.conf

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"

After this, restart postfix with "rcpostfix restart".

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_port 0
icp_access deny all

3.4.4 DHCPD

Thankfully, the DHCP service is already secure out-of-the-box within SLES8, 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.

On the other hand, you can easily change DNS and default router configuration on DHCP client machines. Note that the tool arpwatch makes no sense when DHCP is used within a network.
Given that the mentioned denial-of-service attacks are rare, it is recommended to use it for workstations and mobile equipment.

3.4.5 dhcpcd

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 Security Tools

3.5.1 Firewalling with SuSEfirewall2

To edit the firewall configuration, point your favorite editor to /etc/sysconfig/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_DEV_EXT="eth0"   # Config/Query number 1
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 seccheck

If 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 bind8.

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:

# mkdir /etc/tw
# cp /usr/doc/packages/tripwire/tw.conf.example.linux /etc/tw.config
# cd /etc/tw
# /bin/tripwire -initialize
# mv /etc/tw/databases/* /etc/tw

Before connecting to the Internet, the resulting file /etc/tw/tw.db_HOSTNAME the tripwire.rpm and /etc/tw.config 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 SLES8 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.

3.5.5 laus

With Service Pack 3 of SLES8, you have the ability 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.

4 The Running System

4.1 Logfiles

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.com
suse-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"

5 Last Words

Finally, a system backup and a reboot should be done before the system is attached to the Internet.
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
FTP Proxy Suite (fwproxys)	A very secure FTP proxy which also supports SSL	6.3	Yes	SUSE FTP server http://proxy-suite.suse.de
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 http://www.suse.de/~marc (betas)
Security Checker (seccheck)	Checks the local security on a daily basis	6.2	Usually	SUSE FTP server http://www.suse.de/~marc (betas)
Compartment (compartm)	Security wrapper for programs, supports chrooting, assignment of priviledges and capabilities	7.0	Yes	http://www.suse.de/~marc (betas)
laus	Kernel audit module	SLES8 SP3	Yes	http://www.suse.de/~thomas (betas)
Security Library (-)	A library for programmers which provides secure function prompts for insecure functions	planned for ?	Yes	http://www.suse.de/~thomas (betas)

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
[2] Private page of Marc Heuse at SuSE: http://www.suse.de/~marc
[3] Private page of Thomas Biege at SuSE: http://www.suse.de/~thomas
[4] SUSE updates: http://www.suse.de/de/support/download/updates
[5] OpenBSD: http://www.openbsd.org
[6] Security focus: http://www.securityfocus.com
[7] Packetstorm: http://packetstormsecurity.org
[8] Apache Group: http://www.apache.org/httpd.html
[9] Powerful SSL encryption for Apache: http://www.modssl.org
[10] Secure Linux kernel patch: http://www.openwall.com

7 The Author

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 heading the IT-Security Services Germany of Unisys, hence performing security checks and implementations of Internet home banking, firewall, and e-commerce systems for international customers with his team. He also loves cats and has difficulties writing about himself in the third person.