Sun One web server 6.x Lockdown - Part I
So after all your evaluations of the web servers out there you decided to use Sun One Web Server 6.1. So lets jump right into things and talk about getting this webserver ready for use. Installing the software and setting up a basic webserver instance is beyond the scope of this, if you need that info checkout the docs first. At the time of this writing they can be found here:
http://docs.sun.com/app/docs/coll/S1_websvr61sp2_en?q=schedulerd
Install the Software
--------------------
RULE #1: Don't run software as root
So I have on Solaris 8 - Tomcat, MySQL, an Sun One Web server. I created a user 'www' for the webserver to run as since our first part of the lockdown is not to run any software as root. You need to have the user added before the software install since the software will ask you, and 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 later on which we will cover in Part II.
Create the Instance
-------------------
RULE #2: Disable unused features
So create a webserver instance via the GUI. Since I am running a multi-tier environment, keeping the app-server (Tomcat) content off the webserver for security & scalability reasons I disable the J2EE features of the Sun One product.
General Instance Lockdown
-------------------------
Since web server instances are very specific in nature to application 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. I've noticed that Sun One web server 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 is:
chown -R root:www /opt/netscape/live/$instance (this is the path to my live instance)
chown -R root:www /opt/netscape/live/httpacl/*$instance* (for acl files)
chmod 640 root:www /opt/netscape/live/httpacl/*$instance*
chmod 755 /opt/netscape/live/$instance (so www can read and write into it where it needs)
chown www:www /opt/netscape/live/$instance/logs (so the webserver can log)
Now that the software itself is somewhat locked down we can move on to some of the specific configs.
Starting with the magnus.conf to see exactly what these do refer the manual above.
Rule #4: Hide your identity
- Ensure TempDirSecurity is set to on.
- Ensure you set ServerString to something that does not disclose the version of your webserver. Numerous tools start by attempting to fingerprint your webserver first, don't make it any easier for them hide this info!
The next file we will look at is the server.xml (new to version 6) the server.xml provides information for the web server sockets.
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, its not strong ssl2="off". Be sure to change any + to - next to ssl2ciphers else you will get warning messages to the effect of SSL version 2 ciphers are enabled when ssl2 is disabled.
- 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 changing the + to a - for all the ciphers you don't need/use.
ssl3tlsciphers="-fortezza,-fortezza_rc4_128_sha, -fortezza_null, +rsa_rc4_128_md5 ,+rsa_3des_sha ,-rsa_des_sha,-rsa_rc4_40_md5, -rsa_rc2_40_md5,-rsa_null_md5, -rsa_des_56_sha, -rsa_rc4_56_sha, -fips_des_sha,-fips_3des_sha"
The last file we'll talk about in this section is the obj.conf.
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.
A critical one to block is TRACE. This provides more information that anyone honest needs to know about your systems. Add it to the top of your obj.conf default object.
<Client method="TRACE"\>
AuthTrans fn="set-variable" remove-headers="transfer-encoding" set-headers="content-length: -1" error="501"
</Client>
The above will block TRACE and set a nice error code you can monitor in your log files to watch the TRACE attempts.
This could arguably be a instance specific option but I add it to all of my obj.conf. Microsoft doesn't play nicely with keepalive, and rather than fixing their poor implementation they had most vendors come up with a workaround not to send a close_notify for MSIE.
AuthTrans fn="match-browser" browser="*MSIE*" SSL-unclean-shutdown="true"
Adding this to the top of the default object 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.
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.
Other than blocking trace restrict any Service method, the default config comes with cgi-bin references that are unprotected and more. If you need GET/POST/HEAD which most web apps that all they need append method="(GET|HEAD|POST)" to the end of all of your service tags. I hope in the future Sun One defaults to something more restrictive!
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: Block bad requests
Stop wasting time processing requests that are bad before anything else! The following blocks all sorts of requests we know are just bad. Customize the string to your liking this is just an example, add it to the default object in your obj.conf before any processing.
<Client uri="*(system32|root.exe|ConsoleHelp|SERVER.INI
|Samples|WEB-INF|_mem_bin|_vti_bin|iishelp|iisadmpwd|iissamples
|default.ida|cmd.exe)*">
AuthTrans fn="set-variable" abort="true" error="412"
</Client>
I again specify a different error code so I can keep track of these responses and take action if I need to. Note the lines in the client tag wrap!
Rule #8: Have logs and process them.
Be sure you get all the info you need our of your webserver 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.
More to come in Part II!
