Perhaps the most simple and trivial way to increase security is to have different paths to the same web item depending on whether it is accessable from the web or from a shell. In spite of how simple it is to impliment, you would be surprised how few system administrators use it.
When you have your web-files in
/var/www
and CGI scripts in
/var/www/cgi-bin
an attacker to your server will have little difficulty in tracking down where to place a malicious CGI, or SSI-laiden document. Using the simple Alias directives in httpd.conf, you can at least make an attacker have to work to find where these files are located. For example, if I had my CGI files accessable via /cgi-bin/ from the web, I could hide them in a hard to find location on the server such as /usr/share/local/apache/bin/ using the following directive:
<Directory /usr/share/local/apache/bin/>
AllowOverride? None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>
Obfuscate or Mung File Extensions
Often there are very specific types of attacks which certain types of server side applications or documents are more susceptable than others. For example, PHP is prone to certain types of DoS attacks, most Perl scripts will be vulnerable to data tainting, and some JSP implimentations can be coaxed into executing arbitrary Java on the underlying system.
So how do we combat this? The simplest way is to simply obfuscate what the application or document is. If a PHP page claims to be ASP, then an attacker will waste time attacking it with ASP-prone attacks and there is a good chance they'll get frustrated and just move on (though, of course, there is no guarantee).
The Apache directive that allows you to redefine or augment existing data types is the MIME handler AddType. It's format is:
AddType MIME-type extension [extension] ...
and it's context can be in global, virtual hosts, directory, or even in .htaccess. This means you can obfuscate on a directory by directory or even a virtual host by vurtial host basis.
Here is a simple example in which PHP pages can be referenced as ASP:
Naturally, you could extend this obfuscation further to documents and images, but the most critical component would be server side scripting.
Limit Where CGI Programs are Run
One of the easy traps for a system administrator to fall into is to allow CGI files to be executed from anywhere on their system. This usually appeases the users, and might even make web-design easier, but it is a huge security threat.
Restrict CGI applications to be run only from some system-wide, easily controllable location. Only grant those users that absolutely need it access to this directory.
There are some situations where multiple large CGI suites may require their own (such as Mailman, see UNIX02/Introduction To GNUMailman). Try to limit these applications as much as possible. If you have the resources, you may even wish to split up services like these on multiple systems.
