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!
Environment
------------
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
Docs
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"
</Client>
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"
</Client>
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.
ACL secure_GETPOST (GET, HEAD, POST) {
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!
