Apache/IBM Http Server Lockdown
Let’s take a look at locking down apache and/or the IBM http server. Installing the software and setting up a basic web server instance is beyond the scope of this, if you need that info checkout the docs first. They do a great job of explaining next, next, finish.
Install the Software
--------------------
RULE #1: Don't run software as root
So I have on Solaris 8 - Tomcat, MySQL, and the IBM HTTP server, yup same as my Iplanet install. I created a user 'www' for the web server to run as since our first part of the lockdown is not to run any software as root. You should have the user added before the software install it can be changed at any point in the httpd.conf file, be sure to secure this account such as setting the account to No password and a false shell. I suggest giving the software its own account not one of the default system ones so you can permission it accordingly and Jail/Chroot it.
Create the Instance
-------------------
RULE #2: Disable unused features
Such as mod_cgi, mod_userdir and more. Since I am running a multi-tier environment, keeping the app-server (Tomcat) content off the web server for security & scalability reasons I disable most of the modules, modify it to your own specific needs.
General Instance Lockdown
-------------------------
Since web server instances are very specific in nature to the applications they host I'm going to breakup the rest into things that could be done to lockdown all instances vs. ones that are more specific in nature.
RULE #3: Don't allow the software to modify itself.
Suppose via a php or some server side script an attacker was able to run commands on your server. We have seen this happen before, a great example is the cmd.exe exploits that came out for IIS. Ideally we don't want the attacker to get in at all but if he does we want to limit what he can do. One step in doing this is to permission the software so it can not modify itself. Apache installs new instances in my environment as Owner:www Group:www then the permissions on the files vary from 775 to 644 and so on. These default permissions would allow a vulnerable script to modify itself.
The first things I do are:
chown -R root:www /opt/IBM/live/https-instancename-443 (this is the path to my live instance)
chown www:www /opt/IBM/live/https-instancename-443/logs (so the web server can log)
Now that the software itself is somewhat locked down we can move on to some of the specific configs. If you are on windows, GWG (go with god). Hopefully you will find the correct (right click , properties.. settings to do this)
Starting with the httpd.conf to see exactly what these do refer the manual above.
Rule #4: Hide your identity
- Ensure you set ServerTokens to Prod. I must admit, I would really like the ability to set this to nothing, but IBM HTTP server does not allow this yet. IBM, at least allow me to something that does not disclose the brand of the web server. Numerous tools start by attempting to fingerprint your web server first, don't make it any easier for them hide this info! In addition set ServerSignature Off as well so you don’t disclose any more information that needed. If you really want the admin email published, use custom error pages.
Rule #5: Use strong encryption
- If you can use SSL. Not sending information in clear text makes it much more difficult to eavesdrop on.
- When using SSL disable version 2, it’s not strong.
- Use only 128 bit ciphers if you can! Only a few sites should allow less than 128bit encryption, and those should be limited too. Disable anything less than 128bit by adding the following in your IfModule
SSLCipherSpec 27
SSLCipherSpec 21
SSLCipherSpec 23
SSLCipherSpec 3A
SSLCipherSpec 34
SSLCipherSpec 35
Rule #6: Block unneeded HTTP Methods
You have your choice of options to allow browsers to use. I haven't found many others to allow than GET,HEAD, and POST. Production sites shouldn't allow webdav components or other types of features that development sites should so block them in each virtual host.
<limit>
order allow,deny
allow from all
</limit>
A critical one to block is TRACE. This provides more information that anyone honest needs to know about your systems. Add it to the main area of your httpd.conf , note you must have mod rewrite enabled.
# Disable HTTP Trace and Track and OPTIONS
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACETRACKOPTIONS)
RewriteRule .* - [F]
The above will block TRACE, you should monitor your log files to watch the TRACE attempts.
This could arguably be a instance specific option but I add it to all of my web server configs. Microsoft doesn't play nicely with keepalive (certain versions), and rather than fixing their poor implementation they had most vendors come up with a workaround not to send a close_notify for MSIE. Some other things like realplayer had this issue as well.
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0
Adding this to the httpd.conf will save you issues going forward in more ways than one!
Checkout http://docs.sun.com/source/817-6248-10/crobjsaf.html for all the details on this. I know it’s the sun site but you will get an idea of the problem.
Having the Web Server not send the close_notify packet may make MSIE vulnerable to a truncation attack, but that's Microsoft's Issues now isn't it.
Specific Instance Lockdown
-------------------------
So this section will contain things that you need to ensure meet your application needed. They might be tighter than you need or in the opposite direction! Modify as needed.
Rule #7: Have logs and process them.
Be sure you get all the info you need our of your web server logs. I obtain not only the request but the content length, referrer, user-agent, the processing time and cookies such as the JSESSIONID cookie for Tomcat. Keeping this info in the logs help identify problems, its important to process these logs as well with tools such as WebTrends if you have some cash to buy or Aw stats which I use here.
Here is my custom log format:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D %{JSESSIONID}C" secretagentsdefault
I also rotate my logs using cronolog, it rotates daily and does not require a restart of the web server. Previous versions used to leave cmd windows open in the background but that was fixed in the latest version. Not more fd leaks!
ErrorLog "/mycronologpath/cronolog ..path..to..logs../logs/error.%Y%m%d.log"
CustomLog "/mycronologpath/cronolog ..path..to..logs../logs/access.%Y%m%d.log" secretagentsdefault
Read more!
