• CGI with Apache suexec

DSPAM CGI with Apache suexec

About this document

Original author: JasonBradleyNance < aitrus@tresgeek.net >

This document outlines the setup of the DSPAM CGI using Apache's suExec feature. Specifically, it covers the recommended method of using a virtual host that does nothing more than serve up the DSPAM CGIs.

Please read the documents that ship with the DSPAM source before attempting an install. This guide is merely step-by-step instructions adapted from the documentation and my own experiences.

Introduction

These instructions are known to work for the 3.2 and 3.4 series of DSPAM.

Additionally, these instructions are specifically for Apache 1.3. You can get more information and download Apache from http://httpd.apache.org/. There is a great guide to suExec here: http://httpd.apache.org/docs/suexec.html.

In this guide I will refer to web server user as apache. Substitute your Apache user (ie - www) where applicable.

Disclaimer

This document has been written in good faith as a guide to setting up a service on your server. That being said, I cannot be held responsible for any actions described within that result in damage, data loss, or any other undesired effects. This is a guide, not a bible. Do research, read other documentation, use common sense, have backups, follow basic system administration standards and practices - including security - and above all, think about what you are doing.

Requirements

• a working Apache 1.3 server with suExec and virtual hosting support

• a working DSPAM installation

• root privileges on the system that the DSPAM CGI is to be installed on

All of the commands in this guide should be run with root privileges. I recommend you use sudo.

Preparing your system

First, let's setup the directory tree where the DSPAM CGIs will live. For the purposes of this guide, let's assume that your Apache Server Root (see httpd.conf) is /usr/local/apache/ and your web sites all live off of directories in /usr/local/apache/htdocs/. On Debian Sarge your Server Root is /var/www and this is used for suEXEC. All files must be below that folder!

NOTE: suExec does NOT work with a symbolically linked DocumentRoot. This is a security feature.

# cd /usr/local/apache/htdocs
# mkdir dspam.example.com
# chmod 555 dspam.example.com
# chown dspam.dspam dspam.example.com
# cd dspam.example.com
# mkdir etc
# chmod 550 etc
# chown apache.dspam etc
# mkdir html
# chmod 555 html
# chown dspam.dspam html

All of the CGIs are going to live in the html directory. The etc directory is for your password file (assuming you use basic password file authentication). We make the directory permissions all 555 for security purposes. 550 will NOT work. Apache will complain about not being able to traverse the directory tree. The exception to this is the etc directory that we created. Since it is owned by the apache user we can set its permissions to 550 (and you definately want to for reasons that will become clear later).

Setting up DSPAM's web interface

The CGIs are located in the cgi directory off the top level of the DSPAM source.

# cp -r /path/to/dspam-3.2.3/cgi/* /usr/local/apache/htdocs/dspam.example.com/html/
# cd /usr/local/apache/htdocs/dspam.example.com/html
# rm Makefile*
# chown -R dspam.dspam *
# chmod 444 *.*
# chmod 554 *.cgi
# chmod 555 templates
# chmod 444 templates/*

Edit configure.pl and check the settings in there. Everything should be pretty good if you passed the correct arguments during your DSPAM build. The one thing you do need to check is $CONFIG{'LOCAL_DOMAIN'}.

Setting up the virtual host

It is highly recommended that you use SSL for the DSPAM CGI, since your users will be sending their passwords across the connection. SSL will encrypt the password, making it very difficult to sniff off the network. Without SSL, it is trivial for an attacker to capture a user's password, and then use it to compromise that accont (and susequently your whole system).

The httpd.conf configuration file that ships with modern versions of Apache is extremely well documented and comes with good examples (and decent defaults). Make sure you read the comments and look at the defaults if you get confused.

Open up httpd.conf in your favorite browser and add the following along with your other virtual hosts:

<VirtualHost *>
    DocumentRoot "/usr/local/apache/htdocs/dspam.example.com/html"
    ServerName dspam.example.com
    ServerAdmin webmaster@example.com
    ErrorLog /usr/local/apache/logs/dspam.example.com-error_log
    TransferLog /usr/local/apache/logs/dspam.example.com-access_log

    User dspam
    Group dspam

    <Directory "/usr/local/apache/htdocs/dspam.example.com/html">
        Options FollowSymLinks ExecCGI
        AllowOverride None
        Order deny,allow
        Deny from all

        SSLRequireSSL


        AuthType Basic
        AuthName "DSPAM Control Center"
        AuthUserFile /usr/local/apache/htdocs/dspam.example.com/etc/htpasswd
        Require valid-user
        Satisfy Any
    </Directory>
</VirtualHost>

NOTE: this will not work with Apache 2.x. You must use

SuexecUserGroup dspam dspam

instead of the

User dspam
Group dspam

lines. Also, you must read the apache 2.x suexec page; it is very likely your setup will not work with the suexec that is provided out of the box, and all of the options are compiled in for security reasons. So read the docs at http://httpd.apache.org/docs-2.0/suexec.html, get the source, and recompile suexec with the setup you need.

Once you save that file and restart Apache, you are pretty much set, with one exception - the password file.

This is where it gets uncomfortable...

Authentication methods

Apache typically runs as a www or http user. This presents a problem with user authentication, since most Unix systems these days make /etc/shadow readable only to root (this is a good thing, as it presents a large barrier to would-be password crackers). All is not lost, however; there are at least two ways to work around this.

The secure, easy way

Since you are running an SMTP server, chances are good that you also have an IMAP or POP server. If so, you can run mod_auth_imap (http://ben.brillat.net/projects/mod_auth_imap/) or mod_authn_pop3 (http://mod-auth.sourceforge.net/), which allows users to authenticate against these servers.

This has an especially big advantage for site with users who don't have actual accounts, since admins can re-use any customizations they've already done to their IMAP or POP servers; all that Apache requires is for you to compile, install, and configure the appropriate module.

The less-secure, difficult way

The most basic way to do authentication is to supply Apache with a copy of /etc/shadow. This presents some security concerns, since it makes available to the web user your list of hashed passwords. A rogue CGI or PHP script could expose your password database to the web, allowing anyone with a cracking tool a chance to log in as one of your users.

First, let's talk about how you do it.

cp /etc/shadow /usr/local/apache/htdocs/dspam.example.com/etc/htpasswd
chmod 440 htpasswd
chown www.dspam htpasswd

Now you need to edit that htpasswd file and do two things:

1. Delete root and every other system or special account in the file that is not a normal user with an email account.

2. Delete everything after the second field on every remaining line.

The result should be a file with lines that look something like:

username:$1$fjkdslfs.Encrypted.Password.jfkdlsfs

If you do go this route, I recommend a perl script or a script in the language of your choice that creates this file for you so that you can run it regularly to keep the passwords sync'd up.

I do NOT recommend that you just give Apache read access to /etc/shadow.

What are the dangers here? Well, the file is out of the web root, so it can't be browsed directly, but as mentioned earlier, there are situations where the web server could still display it. The permissions and ownership forbid local users from reading it.

Conclusion

You should now have a working setup. You should be able to browse to http://dspam.example.com/dspam.cgi. When you do, an http authentication box should popup. Enter your system username and password to continue.

You might want to redirect the index of that web root as a courtesy to your users. If you have PHP installed and configured you could simply place this in an index.php file:

<?php
header( "Location: http://dspam.example.com/dspam.cgi" );

exit( 0 );
?>

Or you can add following to virtual host config:

DirectoryIndex dspam.cgi

---

question: in the Introduction and Requirements sections you state that Apache 1.3 is required, but later on you refer to changes necessary to make suExec on Apache 2.x work. are there any other changes necessary if hosting on Apache 2.x? - SteveHuff