Apache Setup

Chroot Apache

Chrooting. This is probably the most intensive hardening step that you can take. You will create a special directory structure to house Apache and its modules and then when it runs it will not be able to access files outside of that structure. Even if the server were somehow compromised it will not be able to access anything outside of the structure that you have created. I am not going to cover chrooting in this document because it has already been covered extensively in Securing Linux.

I will briefly list the commands I issued to setup the chroot jail on my system. (Which is creating a slightly different structure than the one in Securing Linux.)

          cd /home/www
          mkdir lib sbin tmp etc cgi dev bin var var/lock var/log var/run share files/home
          ln -s . usr
          for file in $(rpm -ql apache | grep sbin); do cp -v $file sbin; chmod -v a-x $file; done
          cp -av /usr/lib/apache modules
          chmod -v a-x /usr/lib/apache/*
          cp -av /usr/lib/php4 lib
          cp -av /usr/share/php share
          for file in bash ls more pwd strace cvs grep; do cp -v $(which --skip-alias --skip-dot --skip-tilde $file) bin; done
          for lib in $(ldd modules/* sbin/* bin/* lib/php4/* | perl -e 'while(<>) { print "$_\n" if ($_, $_) = (/(=>) (\S+).*/); }' | sort | uniq); do cp -v $lib lib/; done
          cp -v /lib/libnss_dns.so.2 /lib/libnss_files.so.2 lib/
          for file in localtime php.ini httpd/conf/* mime.types resolv.conf hosts; do cp -av /etc/$file etc; done
          for file in passwd group; do egrep ^\(apache\|root\|www\) /etc/$file > etc/$file; done
          mknod dev/null c 1 3
          mknod dev/random c 1 8
          chmod u=rwx,go=x etc dev lib modules cgi bin sbin
          chmod u=rwx,go= etc/ssl* var var/lock var/log var/run
        

Something that confused me very much is that I set everything up like I thought it was supposed to be but it didn't work. Apache would die when it was starting, complaining that the "user apache didn't exist." I used ldd to get all the libraries necessary to run everything but unbeknownst to me there were other libraries being loaded. To find them I first started a chrooted shell in the environment that Apache would be running in:

          /usr/sbin/chroot /home/www /bin/bash
        

Then I watched the system calls that Apache would be making using:

          strace /sbin/httpd
        

Specifically I was interested in seeing files that it attempted to open that failed:

          strace /sbin/httpd 2>&1 | grep "No such file"
        

And from that I found that libnss_files is needed for uid to username mapping and libnss_dns is needed for host lookups. This same basic process though could be used to diagnose other problems.

Once you have done any diagnostics that require a shell within the chrooted environment you can safely remove bash and the associated symlinks. This will make it more difficult for someone to start a shell in an exploit of the chrooted apache:

Having created the basic file structure necessary it takes now changing the configuration files to reflect the changes. So far as Apache is concerned when it is running the root of the filesystem, /, is /home/www and everything has to be relative to that.

• Changes in etc/httpd.conf

  • Changed ServerRoot to /

  • Changed occurrences of /old.document.root/ to /files/html

  • Changed occurrences of /var/log/httpd/ to /var/log

  Items that access other parts of the filesystem like "Alias /doc /usr/share/doc" cannot work in this setup. We are going to put the cvs repository inside the chroot specifically so that it can be accessed by web-based cvs browsers like cvsweb and viewcvs.

• Changes in /etc/sysconfig/apache (which is sourced into /etc/rc.d/init.d/httpd)

  • Added OPTIONS="-f /etc/httpd.conf" (echo "OPTIONS=\"-f /etc/httpd.conf\"" > /etc/sysconfig/apache)

• Changes in /etc/rc.d/init.d/httpd

  • Changed httpd=/usr/sbin/httpd to httpd="/usr/sbin/chroot /home/www /sbin/httpd"

  • Changed moduledir=/usr/lib/apache to moduledir=/home/www/modules

  • Added lock=/home/www/var/lock/httpd and replaced /var/lock/subsys/httpd with $lock

  • Added pid=/home/www/var/run/httpd.pid and replaced /var/run/httpd.pid with $pid

  • Changed killproc $httpd to killproc $prog (otherwise it tries to kill chroot)

• Changes in /etc/sysconfig/syslog (in the chroot jail Apache can no longer see /dev/log to write to syslog)

  • Changed SYSLOGD_OPTIONS="-m 0" to SYSLOGD_OPTIONS="-m 0 -a /home/www/dev/log"

Having done these things it should be possible to restart syslog with:

          /sbin/service syslog restart
        

And then restart Apache using:

          /sbin/service httpd restart
        

And then if it restarts properly you can test your setup with:

          for pid in $(/sbin/pidof httpd); do dir /proc/$pid/root; done;
        

And instead of seeing the normal root of your filesystem you should see the chroot environment you created.

Script Configuration

Dynamic and interactive content is the way of the future and allowing users to produce it is a good way to allow them to create more interesting and creative work. Also however it allows for a variety of security exploits since your webpages are in essence becoming programs and since your maintenance is remote it is letting people from all over run programs on your computer. There are ways to prevent the affects that these programs can have on your computer however. Chrooting is a major one, even if someone manages to get a malicious script onto your computer it will be restricted to /home/www. The main Apache process is running as root (in order to be able to bind port 80) but it does not serve content or run scripts itself, rather subprocesses are created that run as the apache user, so though root can possibly break out of a chroot jail the apache user (and thus scripts) cannot.

There are two primary ways that content is generated that I am going to deal with. One is a cgi program (often written in perl, python, or C) that runs and generates content. The other is preprocessed files (like php) where the code is often intermixed with html and the file is interpreted by a server module to generate the content.

            <Directory />
              Options SymLinksIfOwnerMatch IncludesNOEXEC
              AllowOverride None
              Order deny,allow
              Deny from all
            </Directory>
          

            <Directory "/files/html">
              Options +Indexes
              AllowOverride AuthConfig
              <Limit GET POST OPTIONS PROPFIND>
                Order allow,deny
                Allow from all
              </Limit>
            </Directory>
          

            ScriptAlias /cvsweb/ "/cgi/cvsweb/"
            <Directory "/cgi/cvsweb">
              AllowOverride None
              Options ExecCGI
              <Limit GET POST OPTIONS PROPFIND>
                Order allow,deny
                Allow from all
              </Limit>
            </Directory>
          

mod_vhost Configuration

The next bit of setup is not security related exactly, but it is a very convenient way to maintain the site. The server will be serving out a variety of dns aliases to the same ip. There will be one for each committee as well as a primary one for the site as a whole. Using the Apache vhost_alias you can just create a simple directory structure and then Apache will work out finding the proper directory.

The directory structure will have a primary directory for the honors program and then separate directories for each committee:

          /home/www/files/html/honors.tntech.edu/
          /home/www/files/html/honors.tntech.edu/computer
          /home/www/files/html/honors.tntech.edu/ecology
          /home/www/files/html/honors.tntech.edu/service
          /home/www/files/html/honors.tntech.edu/leadership
        

Apache then will contain a vhost directive:

          <VirtualHost 149.149.47.115>
            UseCanonicalName Off
            VirtualDocumentRoot /files/html/%3+/%1
          </VirtualHost>
        

When a request comes in (ecology.honors.tntech.edu) Apache tries to match a directory in DocumentRoot with the last 3 parts of the name (honors.tntech.edu) and then a subdirectory under that with the first part (ecology). In /home/www/files/html/honors.tntech.edu/ there is a symlink to . called www. This means that requests for www.honors.tntech.edu and honors.tntech.edu map to the same place. This also means that www.honors.tntech.edu/ecology, honors.tntech.edu/ecology and ecology.honors.tntech.edu all map to the same place.

This setup will not work correctly for honors.tntech.edu because the search for the first part fails. It is therefore necessary to have a single normal NameVirtualHost to catch that special case.

          NameVirtualHost 149.149.47.115
          <VirtualHost honors.tntech.edu>
            DocumentRoot /files/html/honors.tntech.edu
            ServerName www.honors.tntech.edu
          </VirtualHost>