Installation of a Secure Web Server by Marc Heuse (marc@suse.de) * Introduction * Security Zones * Scenario * Implementation * More Information ------------------------------------------------------------------------------- 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 dis tributions. ------------------------------------------------------------------------------- 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. 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 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. 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. ------------------------------------------------------------------------------- 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 serve r. Step 1: The Router Every modern router provides functions for filter lists. The following simple rules must be configured: +-----------------------------------------------------------------------------+ | Filter Rules | | | +-------------------------+-------------------------+-------------------------+ | From | To | Services | +-------------------------+-------------------------+-------------------------+ |any location |web server |WWW, HTTPS, UDP highport,| | | |ICMP types 0 + 3 | +-------------------------+-------------------------+-------------------------+ |administrators |web server |SSH | +-------------------------+-------------------------+-------------------------+ |web server |any location |DNS, SMTP | +-------------------------+-------------------------+-------------------------+ |web server |router |SSH or telnet | +-------------------------+-------------------------+-------------------------+ 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. Step 2: Installing the Linux Server 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. Step 3: Updates Before configuring anything check whether updates are available for any of the installed packages and install the updates, if necessary. Update information for SuSE 6.4 can be found at: http://www.suse.de/en/support/download/updates/64_i386.html Step 4: The Local Configuration of Linux 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 /e tc/ 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/firewal l.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 is the net where the administrators connect from. 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. Step 5: The Configuration of Apache 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/ - - - Options FollowSymLinks - AllowOverride None - - @@ -697,9 +685,0 @@ -# cgi-bin for SuSE help system -# using SetHandler - - -AllowOverride None -Options +ExecCGI -Includes -SetHandler cgi-script - - @@ -981,4 +961,4 @@ -# -# Deny from all -# ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi -# + + Deny from all + ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi + 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 Step 6: sudo and the Administrators 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. Step 7: Concluding Adjustments 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_HO STNAME 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: 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" 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. ------------------------------------------------------------------------------- More information The Author 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 p erson. 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: SuSE Security Software Name of Function Included in Works on other Download program (rpm) the SuSE Linux distribution distributions, since too FTP Proxy A very secure 6.3 Yes SuSE FTP server Suite FTP proxy which also supports http:// (fwproxys) SSL proxy-suite.suse.de SuSE Firewall A packet filter 6.3 Yes (for other SuSE FTP server which also distributions, (firewals) creates complex init.d and http://www.suse.de/ firewall startup scripts ~marc (betas) systems and must be which is very adapted) easy to configure Harden SuSE For a very 6.1 No SuSE FTP server secure SuSE (specifically (hardsuse) configuration designed for http://www.suse.de/ SuSE) ~marc (betas) Security A kernel module 6.3 Yes SuSE FTP server Module which prevents symlink, (secumod) hardlink, pipe, and lots of other at tacks Security Checks the 6.2 Usually SuSE FTP server Checker local security on a daily http://www.suse.de/ (seccheck) basis ~marc (betas) Compartment Security planned for Yes http://www.suse.de/ (-) wrapper for 7.0 ~marc (betas) programs, supports chrooting, assignment of privileges and capabilities Auditdisk (-) Secure planned for Yes beta not yet generation of 7.0 available checksums which can not be circumvented (unlike Tripwir e) SCSLogger Kernel module 6.2 Yes SuSE FTP server which logs (scslog) incoming and http://www.suse.de/ outgoing ~thomas (betas) connections Security A library for planned for Yes http://www.suse.de/ Library (-) programmers 7.0 ~thomas (betas) which provides secure function prompts for insecure functions 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 on 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. 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 -------------------------------------------------------------------------------