Tuesday, April 04, 2006

Sun One Proxy Server 4.x - Lockdown for reverse proxies

Every now and then I come across some uses for reverse proxy servers to protect devices, app servers, IIS web servers, and more. This should cover some of the basic things to do to the default proxy instances to lock them down and clean them up. So lets dive in!

I'll be doing this work on a Netra T-1 with Solaris 8 installed front ending an IIS 5 server.

Installing the Software
Rule #1 Don't run software as root

If you have ready some of my other posts you'll know the first rule I have is don't run as root. I created a user wsproxy for the proxy server to run as. You need to have the user added before the software install since the software will ask you, be sure to secure this account such as setting the account to no password, false shell.. the usual. So you can audit processes (such as C2 level accounting) I suggest not using one of the default system account such as nobody.

Sun's urls:
Product Info

These should guide you through the install rather than me.

Create the Instance
RULE #2: Disable unused features

If you create a proxy instance from the gui you want to review what features it has added. You might want to disable the cache, SOCKSv5 (firewall traversal and more.. you know what you need anything else you don't!

General Instance Lockdown
RULE #3: Don't allow the software to modify itself.

Ensure critical config files for the proxy server can not be modified by the user you run the proxy server as! This is to prevent a bug in the proxy allowing access for an attacker to modify the proxy server itself. As a general rule the proxy server should probably only need read access to its own config files. It will need access to write logs and such so watch what you modify.

Rule #4: Hide your identity

Proxy Server 4 allows us to modify the server name being sent back to the user. Be sure you set the ServerString making it more difficult for attackers to fingerprint the software you run.

Rule #5: Use strong encryption where needed

If you're running SSL you should:
-Be running at least 128 bit
-not have any weak ciphers enabled (MD5 is a weak cipher now).
-SSL2 should be completely disabled.

Rule #6: Block unneeded HTTP Methods

Similar to web server 6 you can use client tags to block unwanted methods like trace.

<Client method="TRACE">
AuthTrans fn="set-variable" remove-headers="transfer-encoding" set-headers="content-length: -1" error="501"

IIS also has other similar methods specific to IIS such as TRACK which provide the same information as TRACE. Its important to know what methods are available to services you are looking to protect.

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. I spend a lot of time tuning this based on the IIS Logs. When I see new bad requests I expand this.

Client abort seems to be a little known but powerful feature! Play with it!

<Client uri="*(system32root.exeConsoleHelpSERVER.INISamplesWEB-INF_mem_bin_vti_biniishelpiisadmpwdiissamplesdefault.ida)*">
AuthTrans fn="set-variable" abort="true" error="412"

Rule #8: Process and Review logs

Its important to review and monitor your logs. For capacity reasons as well as security! The only want to tighten you server even more is to see how its being attacked. If the default logging is not enough customize your log format to obtain the information you need.

Rule #9: Service Function

By default the reverse proxy servers allow many http methods to be executed upon resources. Due to this issues its critical to review the Service functions set in the configs and limit the HTTP methods that are available to only the ones required.

Service fn="proxy-retrieve" allow="POST,GET,HEAD"

Rule #10: Password files

In a production environment don't use a password.conf file for secure sites. Passwords to certificates should be kept safe and entered manually on startup.

Rule #11: Ldap authentication

In version 3.6 it was not support to use a group to query users for act protection.
Heres an example of an acl which works against a group called proxy users in the ldap.

# ACL to forces authentication and only allows GET/POST/ and HEAD.
Default deny anyone;
Default authenticate in {
Database "default";
Method basic;
Prompt "Private Area";
Default allow proxy;

This was unsupported last I knew, but it works great. Hopefully they will honor my RFE and support it soon! I'm not going to hold my breath though since I just got ldap fail over supported!

Rule #12: Error directives

Its important to check the docs when manually modifying functions in general. I tend to see send-error incorrectly defined. The proxy server can behaved unexpectedly when paths defined do not exist or functions do not have the required arguments.

Rule #13: Mime matching

Ensure the proxy server matches the mime types as close as it can to the web server. I have seen some cases where applications behaving abnormally due to a mismatch between the servers.

That's all I got for now on this!

Read more!

Monday, April 03, 2006

Discovering Portals - Jetspeed with WebSphere 5.1

After I tackled getting Jetspeed up and running under tomcat which was mostly effortless, I wanted to get it running under WebSphere 5.1. This process was not an install and go as I hoped it would be! After tackling everything I must say it wasn't jetspeeds fault, it was IBM's, but I did get it running and some demo portlets deployed. Here's how!

Staring notes.

I did all this work on my Netra T1 (Solaris 8). The database I wanted to use was mysql version 5 also running on the netra. I have a default install of WebSphere

Install the Software
I downloaded Jetspeed2.0-MultiDb-install.jar from the Apache Portal site just like for the Tomcat install. As I noted I wanted to use mysql so I needed the MultiDb installer. I needed to install ant and Maven since this server was a fresh install. Once that was complete and installed I kicked off the jar installer.

java -jar Jetspeed2.0-MultiDB-install.jar

During the installed it did ask for the database information. I also opted in of all the demo apps this time, since with the tomcat install I didn't. For mysql I used the following info:

-username/password (root/mypassword for the install)
-The connection url:jdbc:mysql://localhost:3306t/jetspeed
-The driver: com.mysql.jdbc.Driver
-The path to the driver file I'm using: mysql-connector-java-3.0.17-ga-bin.jar.

So this created a db added a jetspeed user/password. I then modified some of the permissions to this user. Probably more than you would do if you are just playing with this.

Note: The installer as I noted with tomcat didn't like the version 5 connector.

We should now be able to bring up the install using tomcat which gets installed by default. I'm not going to though!

WebSphere Setup
On the WebSphere side of things we need to prep the environment for the install of the portal.

Add the following jars to the WebSphere lib directory or create a shared library. Personally I used a shared library (note they are not part of the java specs yet), since these are not part of the WebSphere package and I might have different installs of jetspeed going forward which I would need to version these jars as they change.


Add a J2C Authentication Data Entries for the Jetspeed Datasource.

Security=>JAAS Configuration=> J2C Authenticaiton Data
Set the userid/alias and password to the jetspeed user you created. If you left the default from the script install its jetspeed/jetspeed.

After this create a MySQL JDBC Provider.

Resources=> JDBC Providers => New.
Name: MySQL
ClassPath: /www/global/lib/mysql-connector-java-3.0.17-ga-bin.jar
Implementation Classname: com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource

Once complete add a Data Source for Jetspeed.

Name: JetspeedDS
JNDI Name: jdbc/JetspeedDS
Datasource Helper Classname:com.ibm.websphere.rsadapter.ConnectJDBCDataStoreHelper
Container-managed Authentication Alias: JetspeedDS or the alias you used for J2C above.

Go to custom Properties and set the following:

databaseName: jetspeed?autoReconnect=true
serverName: localhost
Apply, OK and Save!

The last bit of prep work we need to do is remove jdom.jar from the WebSphere lib directory. WebSphere uses a very old version of jdom.jar. If you want to replace it you may but jetspeed comes with its own packaged. Currently version 1.0 is available (http://www.jdom.org/). Without making this change portlets will not be deployed from the deploy folder and register inside the container. This was the big show stopper in my install. When you load the portal you get errors like /demo not found.

JetSpeed Deployment
So we have everything ready now and can deploy jetspeed into an application server. I have a spare one created so I will be using that, its basically a default container with the memory bumped up to 1GB.

Applications=> Install New Application
Path: /jetspeedtmp/jetspeed.war (this should be the path to your war file on the server)
Context Root:/jetspeed (I just used this for testing)

The rest is basically a next,next,next finish routine. Just ensure you bind the datasource settings when prompted.
Click Ok and save.

JetSpeed Startup
Check the WEB-INF/deploy directory to ensure all the demo apps reside in there. If not add them in.

Start the Application Server you deployed jetspeed into. Upon startup it should deploy all the demo applications into the ear. You should now be able to hit your portal and see some error messages as follows:
Failed to find Servlet context for Portlet Application: /demo

Stop the portal and go back to the Install New Application. For each "demo" (meaning portlet demo) war you want to install and have deployed we need to install it manually into the container as we did jetspeed itself.

You should be able to see all the portlet wars in the jetspeed_war.ear folder in installedApps. Start with demo.war and move on from there. You can start the portal after you install demo to ensure everything looks ok.

Post Issues:
I have found some issues with the default portlets such as j2-admin. Im looking at getting those running now.

Some references:

Read more!

Last posts