Installation of a Secure Webserver

Marc Heuse

Table of Contents

• Introduction
• Security Zones
• The Infrastructure Zone
• The Network Protocol Zone
• The Service Zone
• The Application Zone
• The Operating System Zone
• The Scenario
• The Implementation
• The Router
• Installing the Linux Server
• Updates
• The Local Configuration of Linux
• The Configuration of Apache
• sudo and the Administrators
• Concluding Adjustments
• Additional Options
• Not to Forget
• In Conclusion
• Linux and Security
• Some Additional Information Regarding SUSE LINUX 7.1
• Links

Introduction

Web servers are the most exposed servers on the Internet. In order for clients/target groups to be able to access the information provided, web servers must be accessible from any point on the Internet. In contrast to other public services like DNS and FTP, the Web is especially tempting for "Crackers": a succesful "hack" of a system can be visualized by changing the appearance of the home page to increase awareness of the hacker's presence. Such an occurence can lead to a significant loss of confidence for a company - and this even more so if sensitive information like credit card details etc. are filched or even published.

Apart from firewalls, which aim at protecting internal networks against attacks from the internet, web servers are the second important field requiring a high degree of security. This article shows how this can be done on a Linux system within just 45 minutes. Of course, the same can also be done on other operating systems. Below is an example based on the SUSE LINUX 6.4 distributions.

Security Zones

The server security comprises a number of security zones. 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 nets 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 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.

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.

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

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.

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.

The Scenario

A web server should be set up with an Internet provider. Since he does not have an own security infrastructure, a router with filter rules should be placed in front of the web server. The web server should offer only WWW and HTTPS, but of course it should also have remote control features. Additionally it should also be able to send mail. Since the Linux server and the web pages are supervised by three administrators, administrative operations should be comprehensible at a later date.

The Implementation

How can the requirements for a secure web server as specified in the preceding paragraphs be implemented? The following example shows how this can be done with a SUSE LINUX 6.4 distribution. In order to implement the scenario, we decide in favor of the SSH administration and the Apache web server.

Every modern router provides functions for filter lists. The following simple rules must be configured:

The router manual should provide detailed information as to how this can be done. I would suggest using a Cisco router which is easy to configure in this regard and which additionally contains the encryption service SSH for the administration in the IOS version 12.

Perform a standard installation of SUSE 6.4. To be on the safe side, at least five partitions should be installed for /, /var, /tmp, /home, and /usr/local. Special mount options can be defined later on for these partitions in order to make the system more secure locally.

Now the time has come to select the packages for installation; choose the minimal system and add the following packages manually:

• from Basis (a): compat
• from Applications (ap): sudo
• from Network (n): apache, bindutil; unselect postfix and sendmail
• from Security (sec): firewals, hardensuse, mod_ssl, scanlogd, seccheck, secumod, tripwire.
• plus anything else you need (e.g. data bases, modules for the Apache)

Complete installation.

Before configuring anything check whether updates are available for any of the installed packages and install the updates, if necessary.

Update information can be found at the Updates, Patches, Bugfixes pages.

Before starting with the actual work, all "standard" Linux configurations such as entering the name server, configuration of the network interface, setting up users, etc. should be executed. Initially all unnecessary services should be inactivated and authorizations withdrawn from privileged programs not absolutely needed. This can easily be done with the harden_suse tool:

erde# harden_suse yes

This causes extensive changes to the system, which are all recorded in /etc/harden_suse.log and which can be undone with the /etc/undo_harden_suse script. Users of other Linux distributions like Red Hat can possibly use the Bastille script or something similar, although these represent a slightly different approach.

Subsequently all services with net access except SSH are deactivated and only the following privileged suid and sgid programs remain:

 erde# find / -perm -04000 -type f -exec ls -ld {} \;
 -rwsr-x---         1 root           trusted     23840 Mar 11 11:26 /bin/ping
 -rwsr-x---         1 root           trusted     30750 Mar 11 11:37 /bin/su
 -rwsr-x---         1 root           trusted     21268 Mar 11 11:10 /usr/bin/crontab
 -rwsr-xr-x         1 man            root        85460 Mar 11 11:24 /usr/bin/man
 -rwsr-xr-x         1 root           root        15308 Mar 11 11:26 /usr/bin/rcp
 -rwsr-xr-x         1 root           root        11052 Mar 11 11:26 /usr/bin/rlogin
 -rwsr-xr-x         1 root           root         8104 Mar 11 11:26 /usr/bin/rsh
 -rwsr-x---         1 root           shadow      38340 Mar 11 11:50 /usr/bin/gpasswd
 -rwsr-x---         1 root           trusted     22184 Mar 11 11:50 /usr/bin/newgrp
 -rwsr-xr-x         1 root           shadow      27920 Mar 11 11:50 /usr/bin/passwd
 -rwsr-x---         1 root           trusted     56600 Mar 11 18:41 /usr/bin/sudo
 -rwsr-xr-x         1 root           root        20300 Mar 11 11:26 /usr/sbin/traceroute
 -rwsr-xr-x         1 root           root         6132 Mar 11 09:36 /usr/lib/pt_chown
 erde# find / -perm -02000 -type f -exec ls -ld {} \;
 -rwxr-sr-x         1 root           tty          9452 Mar 11 11:26 /usr/bin/write
 -rwxr-sr-x         1 root           tty          9796 Mar 11 11:49 /usr/bin/wall

The next stage is to edit the global configuration file /etc/rc.config and change the following lines from "no" to "yes":

START_HTTPD="yes"
START_FW="yes"
START_SCANLOGD="yes"

This ensures that Apache, Scanlogd and the SUSE firewall are automatically started when booting. Now we continue with the configuration of the local firewall and change the following lines in the file /etc/rc.config.d/firewall.rc.config (a detailed description of the individual variables is included in the file):

FW_DEV_WORLD="eth0" # query no. 2
FW_SERVICES_EXTERNAL_TCP="www https" # query no. 9
FW_SERVICES_TRUSTED_NETS="1.1.1.0/24" # query no. 10 (1.1.1.0: net of the administrators)
FW_TRUSTED_SERVICES_TCP="ssh" # query no. 10

The command /sbin/SuSEfirewall updates the rules. These will be loaded with each booting cycle.

Now we integrate the special SUSE security module in the following manner:

erde# cat >> /sbin/init.d/boot.local
insmod secumod hardlink=1 symlink=1 pipe=1 trace=1 systable=1 logging=1
^D

When booting, this module will be loaded with a configuration preventing Symlink, Hardlink, Pipe, and a number of other UNIX-specific attacks.

The web software and the pages are the core of the server. 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.

erde# useradd -m wwwdocs
erde# cat > /etc/cron.daily/wwwdocs
#!/bin/sh
/bin/chown -R -h wwwdocs /usr/local/httpd/htdocs/*
/bin/chmod -R go-w /usr/local/httpd/htdocs/*
/bin/chmod -R a+r /usr/local/httpd/htdocs/*
^D
erde# chmod 700 /etc/cron.daily/wwwdocs

Since the Apache probably has already been pre-configured, few changes will be necessary in the configuration. Of course, in the beginning the right value should be set for MinSpareServers, MaxSpareServers and StartServers in the file /etc/httpd/httpd.conf.

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 option ServerSignature can be switched "off" so that the software and version number is not displayed when a non-existing page is accessed, but this does not bring much since the HTTP header contains this and a lot more information.

The aliases for /hilfe/, /doc/, /cgi-bin-sdb/, /sdb/, and /manual/ should be disabled.

Here an example for what changes to the standard configuration could possibly look like: ("diff -u0")

--- httpd.conf.orig     Sun Apr  9 19:37:44 2000
+++ httpd.conf  Sun Apr   9 19:42:57 2000
@@ -141,2 +141,2 @@
-MinSpareServers 1
-MaxSpareServers 1
+MinSpareServers 3
+MaxSpareServers 10
@@ -148 +148 @@
-StartServers 1
+StartServers 5
@@ -157 +157 @@
-MaxClients 150
+MaxClients 100
@@ -401 +401 @@
-ServerAdmin root@localhost
+ServerAdmin webdocs@echte-domain.de
@@ -415 +415 @@
-#ServerName hawking.suse.de
+ServerName www.echte-domain.de
@@ -485 +485 @@
-UserDir public_html
+#UserDir public_html
@@ -646 +646 @@
-ServerSignature On
+ServerSignature Off
@@ -665,11 +664,0 @@
-Alias /hilfe/ /usr/doc/susehilf/
-Alias /doc/ /usr/doc/
-Alias /cgi-bin-sdb/ /usr/local/httpd/cgi-bin/
-Alias /sdb/ /usr/doc/sdb/
-Alias /manual/ /usr/doc/packages/apache/manual/
-
-<Location /sdb>
-    Options FollowSymLinks
-    AllowOverride None
-</Location>
-
@@ -697,9 +685,0 @@
-# cgi-bin for SUSE help system
-# using SetHandler
-
-<Directory /usr/lib/sdb/cgi-bin>
-AllowOverride None
-Options +ExecCGI -Includes
-SetHandler cgi-script
-</Directory>
-
@@ -981,4 +961,4 @@
-#<Location /cgi-bin/phf*>
-#    Deny from all
-#    ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi
-#</Location>
+<Location /cgi-bin/phf*>
+    Deny from all
+    ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi
+</location>

The activation of SSL and the generation of the certificate is described in the file /usr/doc/packages/apache/README.SUSE.

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 (very unlikely to happen!).

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

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

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 net has already been made impossible as a result of the modifications in the configuration made with the harden_suse script, and the administration itself can only be performed in an encrypted manner with SSH. The next thing that needs to be done 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. A user is set up for each administrator with the help of the following line:

erde# adduser -m -g trusted username

Inclusion in the group "trusted" is essential, since due to security criteria determined by harden_suse, sudo may only be used by a trusted group. Subsequently the administrator is 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.

Having completed all work on the system, the program tripwire should be used to generate a data base containing the checksums of all files:

erde# cp /usr/doc/packages/tripwire/tw.conf.example.linux /var/adm/tripwire/tw.config
erde# /var/adm/tripwire/bin/tripwire -initialize

Before connecting to the Internet, the resulting file /databases/tw.db_HOSTNAME 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 ...

Finally, a system backup and a reboot should be run before the system is attached to the Internet.

But we are not through yet. All administrators should subscribe to the most important mailing lists:

Additional Options

As a local intrusion detection system is missing, successful hacks can only be traced if the attackers leaves behind conspicuous marks. Good ready-made solutions have not been available so far, but a number of tricks and programs can be used to that end. However, a detailed description would go beyond the intended scope of this article.

If several files on the web server need to be changed on a regular basis, scp - the "secure copy" function of SSH - is rather impractical. More appropriate for this purpose is e.g. SSLftp, which has the characteristics of a normal FTP, but which encrypts the data like SSH.

Log data are 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.

Additionally, it is a good idea to integrate the secure linux kernel patch by Solar Designer [13]. This makes it difficult for the attacker to exploit buffer overflows in programs.

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 removing the authorizations manually or starting SuSEconfig.

This can be done until no more sgid programs and only the following suid programs are left:

-rwsr-xr-x         1 root           shadow      27920   Mar 11 11:50 /usr/bin/passwd
-rwsr-x---         1 root           trusted     56600   Mar 11 18:41 /usr/bin/sudo
-rwsr-xr-x         1 root           root        6132    Mar 11 09:36 /usr/lib/pt_chown

If the system has several partitions, the security level can be increased considerably by using the mount options ro (read only), nodev (no devices), nosuid (no privileged suid files) and noexec (no executable files).

Besides, the ext2 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.

If the server also needs to be protected from local attacks, the LILO boot loader must be equipped with a password. This is achieved by entering the following at the top of the file /etc/lilo.conf:

password=something_difficult_to_guess

restricted

And finally: A web server is usually more than an Apache. Generally one or two data bases, additional modules and other programs are employed, or other services are active, e.g. a DNS server. The Linux packet filter (see example under Step 2) helps to protect these effectively and with ease. A wrapper for programs called "compartment" (available at www.suse.de/~marc) supports chroot, the assignment of privileges, the Linux capabilities, etc.

Of course there are other things one could do, but I think so much should do for now.

Not to Forget

Updates. A system which is not updated with the latest security patches will quickly become a target for attackers.

Having done everything that is necessary to set up a secure system, the CGI scripts pose the greatest danger. The majority of successful attacks take place by means of these scripts. A word of advice: Limit your use of CGI scripts to those which have already been publicly available and in use for some time. In case the administrators themselves write scripts, they should have these checked regularly by someone for security issues.

In Conclusion

A web server which is both very secure and usable - something generally regarded to be contradictive - can be set up within less than 45 minutes. Much could be done to increase the level of security even more, but this system should be sufficient for most purposes.

Linux and Security

If you decide for Linux, you are in the lucky position to have a large number of security programs available - especially when compared with other Unix and Windows platforms. There is a host of options to choose from. Two good points to start in order to find appropriate tools are SecurityFocus [9] and Packetstorm [10].

So far, SUSE LINUX has been the only commercial Linux distribution that invests a lot of time and money in the security of the distribution and which makes the results available to the community. The following tools were developed by SUSE and can be downloaded free of charge:

Some other security programs on the CD: Nessus, Saint, nmap, PGP, GNU Privacy Guard, OpenSSH, Tripwire, FreeSWAN, etc.

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.

Of course, there are other alternatives, too! The Trustix Linux distribution [6] which is solely security-oriented, has been made available recently. Unfortunately this distribution is still in the initial stage. Nevertheless, a 150 MB ISO file of the first Alpha version is already available for downloading.

If you do not trust Linux, have a look at OpenBSD [5]. A few years ago the NetBSD distribution was checked for security problems line for line. More than 10 programmers are busy searching for security problems. A comparison of the amount and quality of messages regarding security problems under Unix (and of course Windows) variants reveals that OpenBSD is the undisputed winner. The snag? For one thing, the amount of software. The complete OpenBSD software does not even fill one CD. Everything else needs to be integrated in the system through so-called ports or imported by the user - without having being checked for security. The other problem is that the code basis is BSD, and due to the Linux rush the BSD platforms are not longer a strategic target for the software industry. But still, OpenBSD has a good reputation among security experts. OpenBSD is the right solution for security-dependent servers which do not run outlandish software.

Of course, commercial high-security Unix systems are available, too. They are called Trusted {Solaris, Irix, SCO, ...} and implement the american C2, B1, and B2 security standards. Apart from the fact that these systems are very expensive, their security is not that high after all. Though the implementation of security standards cause a considerable security increase, due to the lack of open source and the well-known "quality" of source codes of commercial Unix systems (still more secure than Windows), it would not be realistic to expect a system which is 100% secure.

Some Additional Information on SUSE LINUX 7.1

The concept of a secure web server itself as described above has not changed that much since SUSE LINUX 6.4. Yet some changes regarding the software deserve to be reported:

• The firewall package known as firewals has now been renamed to SuSEfirewall
• avoid using secumod as it may cause some trouble
• still use a 2.2 kernel for security relevant applications
• currently only an update version of harden_suse is available

For the past five years, the author has been active exclusively in the field of IT. He had been head of the SUSE Security Team for two years. His main job as chief auditor and senior consultant for KPMG includes security checks of Internet home banking, firewall, and e-commerce systems for international customers. He also loves cats and has difficulties writing about himself in the third person.

Links

[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] Trustix: http://www.trustix.com
[7] Bastille Red Hat hardening scripts: http://www.bastille-linux.org
[9] Security focus: http://www.securityfocus.com
[10] Packetstorm: http://packetstorm.securify.com
[11] Apache Group: http://www.apache.org/httpd.html
[12] Powerful SSL encryption for Apache: http://www.modssl.org
[13] Secure Linux kernel patch: http://www.openwall.com