Orion Server: Running on Linux/UNIX
This is a Java/J2EE tutorial for Orion Application Server.
Running Server as Non Root User
Ok, the most obvious first task for
deploying to a production server is to
ensure Orion does not run as
root
. The most obvious reason
for this is security… firstly an error on
behalf of the application developer could
potentially take down the entire system, not
just the application… secondly it is
feasible that an exploit could be discovered
allowing a malicious remote hacker to
execute commands - restricting them to the
permissions of a single user can at least
keep the damage down.
Another problem with running Orion as root is that it often needs to write or modify configuration files. As it is a pure Java application, it has no concept of file-permissions and uses the defaults of the operating system. This can result in files being owned by root for which the application developer does not have permission to access.
Solution… to create a new user under
which Orion runs, place the application
developers and Orion in the same group, and
set the umask
for both Orion
and the developers so all new files are set
group read/writeable.
File Permissions
For this example, a user
(orion
) and group
(j2ee
) are created.
[root@myhost]$ useradd orion
[root@myhost]$ groupadd j2ee `
The orion
user and all
application developers whom use
orion
, then have their primary
group (GID) set to that of
j2ee
.
[root@myhost]$ usermod -g j2ee orion
[root@myhost]$ usermod -g j2ee joe
[root@myhost]$ usermod -g j2ee bob
Note: the commands for adding and modifying users and groups differ from system to system. The commands above work for most distributions of Linux.
Finally, these users must have their
umask set to 007
(new files
will default to owner/group read/write).
This is probably best done by modifiying the
users’ profile files which are sourced when
they login. If the user uses bash, this can
be done by appending the following line to
.bash_profile
in their home
directory, or to /etc/profile
for it to affect all users of the
system.
# (append to .bash_profile or /etc/profile)
umask 007
The Port 80 Problem
The obvious drawback to running Orion as
a non-root user is that root is the only
user allowed to listen for socket
connections on ports less than
1024
. Web-servers typically
listen for sockets on port
80
.
The easiest way around this is to tell
Orion to run the web-server on a different
port (higher than 1024
) and
then redirect IP packets destined for port
80
to this other port. For this
example we use port 10080
.
To change the port the web-server is
listening on, edit the appropriate
web-site.xml
for every web-site
on the server.
How the packets are forwarded depends on the system, but here are 3 approaches:
Option 1: IP Chains (ipfw)
IP Chains is a program that comes with recent versions of Linux that uses the ipfw library to specify rules for TCP/IP packets. For information about using it, refer to the Linux ipchains howto.
Here’s a simple rule to tell all incoming TCP packets destined for port 80 to be forwarded to port 10080:
[root@myhost]$ ipchains -A input --destination-port 80 -p tcp -j REDIRECT 10080
Warning: Use ipchains at own risk… You are recommended to read the documentation first, and have the machine in easy reach.
This command needs to be executed each time the system is booted, so you may want to place it in a startup file somewhere.
Option 2: External Firewall or Reverse Proxy
If your server is sitting behind a
firewall, reverse proxy, or even certain
routers, it may be possible to configure the
firewall to redirect packets from port
80
to a certain host to another
destination. Consult the documentation for
your firewall to find this out.
Option 3: TCP Port Redirector
Another option is to run a process (as
root) that listens on port 80
of the server and for every connection
received, makes a second connection to the
port Orion is listening on and all traffic
is forwarded inbetween.
Note: This should be considered a last resort if no other methods work as it poses 2 problems. Firstly, there’s some extra overhead as for every single connection to the web-server, a second connection must then be made. Secondly, from Orion’s point of view, all incoming connections appear from localhost - this may or may not be a problem.
There are many programs out there that can accomplish this. Here is how to do it using netpipes:
[root@myhost]$ faucet 80 -io hose localhost 10080 --slave
Configuring redirect host
Orion sometimes needs to send HTTP
redirects to the client browser (such as
when a directory is requested with the
trailing slash ommited) and to do this it
will recreate the URL it thinks the
requested page was on. As Orion thinks it is
listening on a different port, it will
return a different URL to the browser
(e.g. http://myhost.blah.com:10080/somedir/
).
Thankfully, there is a
<frontend>
option to
available in web-site.xml
to
tell Orion otherwise.
web-site host="[ALL]" port="10080">
<
frontend port="80" />
<
... rest of web-site-config ...
web-site>` </
Starting and Stopping
Just to round it all off nicely, a shell script can be used for starting, stopping, and checking the status of Orion safely. This script should also perform basic checks such as not starting Orion if it’s already running.
Here’s one I wrote earlier. Filename: orion.sh
Download it and place it somewhere in the
path available to root and the orion user.
It should only ever be executed by these 2
users. Edit the file and customise the
settings for the first few lines. This
script can be used in
/etc/rc(.d)
to startup/shutdown
Orion on reboots.
Also see User Security