Thursday, June 11, 2009

Running tomcat on port 80 as non-root

  • Use IPtables. This requires a kernel version of 2.4.x or higher. If you’re running an older version of the kernel take a look at IPChains and consider a command something like: ipchains -I input --proto TCP --dport 80 -j REDIRECT 8080

    The IPtables solution allows Tomcat to run as an independent server as a non-privileged user and listen on port 80. IPtables will redirect all requests coming in on port 80 to port 8080 or whatever port you have Tomcat running under.The first step for this solution is to make sure your firewall allows TCP requests on port 8080 (or whatever port your Tomcat configuration has specfied). Essentially you need to duplicate all the firewall rules you have configured for port 80 since you will be redirecting those requests to 8080. The second step is to use the iptables command (usually installed by default on linux distributions) to redirect all packets on port 80, to port 8080. Here is a an example of the command you would use to do this:

    iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j REDIRECT --to-port 8080

    To redirect local requests use the following command:iptables -t nat -A OUTPUT -p tcp -d --dport 80 -j REDIRECT --to-port 8080
    This is handy if you’re running Tomcat on your workstation and debugging an application that’s required to run on port 80.
  • Use rinetd. rinetd is a dedicated port redirector program that receives a packet and redirects it to a different port or address. Since rinetd redirects packets after they’ve gone through IPtables, this solution can be used for local and non-local requests.There are two things you should consider when using rinetd. First, rinetd cannot be used to redirect FTP requests because FTP requires more than one socket. Secondly, rinetd makes all packets appear as though they originated from the local machine. This obviously will impact things like web server logs and setting permissions based on IP address.Although rinetd has these side effects, using a combination of iptables and rinetd may be another option but seems like a more complicated solution from a debugging and maintenance perspective.

1 comment: