Hi, On 25 January 2011 09:29, Sean Rodden <s...@rodden.net> wrote: > Hi folks, > > I have a web app (served by Tomcat) that was intended for intranet use. As > such I assume that the security is only basic and it is not suitable for > facing the public internet. When seeking a product to stand between my app > and the world, haproxy was recommended to me. I understand that this is not > the primary function of haproxy so if anyone can suggest a product more > suitable (open or commercial), then I'm all ears.
Personally if the application isn't designed with security in mind I wouldn't put it on the Internet or consider paying a developer to review the application for just this purpose. Depending upon how the application was developed, reviewing it and updating its security can sometimes be extremely quick and far less costly than expected. Having said that: Other options: (a) Apache HTTPD preferably with mod_security (b) NGINX (haven't used it but it has a reverse proxy mode) (c) HAproxy (d) Let Tomcat serve data directly. Caveat 1: If you're running an old version of Tomcat and/or Java you should _definitely_ upgrade - newer versions of Tomcat and the Java JVM can all run older applications with little / no change in configuration. Major version leaps (e.g. Tomcat 5.x to 6.x) will require changes to Tomcat configuration but not necessarily to the application's configuration. Tomcat itself has several security options in the more recent versions (e.g. 6.0.3x) which you should consider enabling (cross site scripting protection). The tomcat documentation and users mailing list will help here. Caveat 2: Ensure the application is configured to login using HTTPS only and _stay_ on HTTPS once logged in. Its far too easy to 'hijack' sessions when applications login using HTTPS but then keep the session in HTTP. If you can't do this, run the entire application from HTTPS only. Recommendation: My recommendation would be Apache HTTPD in reverse proxy mode with mod_security installed and configured correctly. A properly hardened Apache HTTPD server is very difficult to hack and when placed in a DMZ gets the hacker hardly anywhere. mod_security compares requests against a series of rules. There are a general set of rules provided with mod_security (and kept up-to-date with known hacks, including DoS, script-kiddies etc) but you can add your own local rules as well. It all depends upon how 'valuable' the data the application has access to is. Note: This is not to say that HAproxy isn't capable of performing the task, merely to say that in this instance I believe, mod_security with Apache HTTPD might be a better fit, as long as you have the technical knowledge to configure mod_security properly. HAproxy is a _fantastic_ product and I use it to cluster Tomcat for my clients. > > I have spoken briefly with Willy who has very kindly set me on the right > track for a couple of issues but I'm still not grokking haproxy yet. I have > the following set in my haproxy.cfg. haproxy is correctly proxying my > application but I am not challenged for a password at any point. Would > someone kindly point out where I have made errors? > > Also, Willy suggested that I could use haproxy 1.5(dev) to harden the > connection, preventing brute force attacks and the like. I have reviewed the > configuration.txt file and most of the concepts are foreign to me. Has > anyone a sample config file for this purpose they would share? > > Thanks, > Sean > > userlist L1 > group G1 users sean > user sean insecure-password abc123 > > backend sleds > mode http > acl auth_ok http_auth(L1) G1 > http-request auth unless auth_ok > timeout connect 10s > timeout server 30s > balance roundrobin > server sled1 127.0.0.1:10001 weight 1 maxconn 512 > > frontend http_proxy #arbitrary name for the frontend > bind :80 #all interfaces at port 80 > mode http > option forwardfor > option http-server-close > option http-pretend-keepalive > default_backend sleds #by default forward the requests to sled > > Note that with the option forwardfor above you will probably need to configure Tomcat's Remote IP valve otherwise your application will think that all requests are coming from the proxy server. Hope this helps -- Best Regards, Brett Delle Grazie
