Thanks to unSpawn, and my realization that I am security-challenged, I will be frequenting this forum quite often!

I have been reading documentation from unSpawn's security post and I've come across my first security newbie question.

Do I want to run Apache in a chrooted jail environment?

My server requires three users - Myself, root, and jakarta (to run Tomcat). I always log in as myself and su - when necessary, but prefer to log in as root at the console. There is also another user 'nobody' to run apache.

The only thing I can say for sure is that web site users come to our firewall first which allows www and ssl traffic through a DMZ to my web server on a separate network. Whether or not my firewall and switch will provide additional protection down the road I can't say for sure - but what I can say is that since they don't do anything else except block all other traffic, then my installations have not been secure enough to prevent someone coming in through web traffic from manipulating (and bringing down) my server.

I am not sure if this jail constrains users coming in over web traffic in the same manner as users actually logging on to the system. So I guess my second question is -

Does running Apache and Tomcat in a chrooted jail environment provide any additional security in preventing hackers from messing with my filesystem/service?

Any feedback / opinions are greatly appreciated.

Do I want to run Apache in a chrooted jail environment?
The minimum you should do wrt Apache is run network facing services under lesser privileged system accounts (restricts resource access), remove or disable unnecessary configuration options and features (risks, exploitable conditions). Apache starts up as root to be able to bind to a privileged port (below 1024), then it's children run under a lesser privileged user account to handle requests. So in effect only it's children are exposed to the network. If not flawed, the docroot should be the webusers "root". A properly configured chroot jail can provide an extra layer of security in that it constrains the user, but the feasability of it all depends on wether your complete Apache/Tomcat setup can be run from one without crippling functionality.


Whether or not my firewall and switch will provide additional protection down the road I can't say for sure - (...) my installations have not been secure enough to prevent someone coming in through web traffic from manipulating (and bringing down) my server.
Don't forget the possibility of them gaining access tru an already subverted box on the network. Until you get a clear picture from the access database, system and application logs, fw logs and analysis of the cold system you really can't tell, unless you know you've been running vulnerable, publicly accessable services or have allowed a user, service or application to do things it should not (like remotely excute system commands).


I am not sure if this jail constrains users coming in over web traffic in the same manner as users actually logging on to the system.
No. A properly configured chroot jail constrains users more compared to unprivileged local accounts.


Does running Apache and Tomcat in a chrooted jail environment provide any additional security in preventing hackers from messing with my filesystem/service?
Yes. Definately. Feasable? Maybe.


*Before you go ahead, I think it would save you energy if you list your current box SW specs and what you plan to do to harden the box. We may be able to help you curb risks in other ways.

My server (for now) is a Dell PowerEdge 1650. I am still waiting on approval for an upgraded machine but here are my specs:

1.3GHZ, 512MB RAM, 20GB SCSI HD, 2 NIC cards.

I am about to install the following software (from thge Securing and Optimizing Linux Guide posted in your reference post):

RH 9
Apache
Tomcat
iptables
mod_ssl
openssl
openssh
Tripwire
GnuPG
sXid
Logcheck
PortSentry
Xinetd
qmail or sendmail (? not sure which one)
BIND/DNS (not sure I need this? I use the DNS server on our other subnet)

There is an IIS web server and will be my server on their own network separated by a DMZ behind the firewall. The other server appears to be absolutely fine from what I can tell - this one just serves static pages and does not transmit any data.

Basically my web server will host both static and dynamic data. Part of my site initializes a secure transaction with our back end UNIX system (through the use of a trusted third party interpreter) where data is displayed to the user (no login required). At the end of the transaction, an email needs to be send to the user reiterating the information they viewed.

The third party interpreter uses fast-cgi scripts to display the transaction. While I am personally not a fan of anything related to cgi - I unfortunately have absolute no choice in this matter. This is the application that I have to use.

My plans for hardening the box are not 100% clear yet (my desk is covered with books and I have about 50 web pages bookmarked). A few things are:

1) The only place on my server that anyone needs to access is /usr/local - so I'd like to somehow restrict everyone except root and maybe one privileged user from getting outside that area.
2) remove setuid and setgid permissions wherever I can and if I can't restrict users from running them from the home dirs.
3) disable pinging, broadcasts, ip forwarding,
4) I've read about the Bastille hardening tool.... is this worth exploring?
5) I haven't decided if I am going to use X or not, but if I do I will wrap SSH around it.
6) Another thing I was thinking about was configuring iptables as a second line of defense for traffic that goes through my firewall, or a first line of defense for traffic coming from other computers on the network.

Of course then I have to deal with intrusion detection, monitoring, etc.

Just a few random notes as the caipirina starts to kick in :-]


I am about to install the following software (from thge Securing and Optimizing Linux Guide posted in your reference post):

RH 9
Apache
Tomcat
iptables
mod_ssl
openssl
openssh

Tripwire
Alternatives are Aide and Samhain. I prefer Aide cuz it's easier configurable. When you did your initial install of the OS, make sure to save a copy of the db and binary on readonly media. Save a copy of the rpm database too.

GnuPG
sXid
Logcheck
... plus Chkrootkit and Tiger

PortSentry
I vote for Snort. Portsentry doesn't compare. Prelude is an alternative.

Xinetd
qmail or sendmail (? not sure which one)
Whatever you're comfortable with if you really need your own MTA, on RHL Sendmail only listens on the loopback device. Make sure it uses Smrsh tho.

BIND/DNS (not sure I need this? I use the DNS server on our other subnet)
Then you don't, unless you explicityl need to speed up by caching requests. DJBDNS is an alternative, but be warned it got "quirks".


The third party interpreter uses fast-cgi scripts to display the transaction. While I am personally not a fan of anything related to cgi - I unfortunately have absolute no choice in this matter. This is the application that I have to use.
Make sure it's well tested.


My plans for hardening the box are not 100% clear yet (my desk is covered with books and I have about 50 web pages bookmarked). A few things are:

1) The only place on my server that anyone needs to access is /usr/local - so I'd like to somehow restrict everyone except root and maybe one privileged user from getting outside that area.
You don't need to. Just make sure you load a Grsecurity kernel with TPE set for all users.

2) remove setuid and setgid permissions wherever I can and if I can't restrict users from running them from the home dirs.
Mount flags noexec, plus TPE against execs from home dirs.

3) disable pinging, broadcasts, ip forwarding,
respectively a permission, firewall, kernel thing.

4) I've read about the Bastille hardening tool.... is this worth exploring?
Yes. Load it, plus Tiger (+NSAT/USAT). I did the spec file for Tiger, if you want rpm's for Chkrootkit, Tiger and LSAT, just say so.


6) Another thing I was thinking about was configuring iptables as a second line of defense for traffic that goes through my firewall, or a first line of defense for traffic coming from other computers on the network.
Just follow the route: kernel > account restrictions / filesystem access > application configs > network restrictions. Yes, blocking all unwanted traffic is cool, but be sure to set up LOG target rules to *know* what's going on and to debug access if necessary.

or how about I just hire you to come and make my server hack proof!!

It is amazing the stuff that you know... I have to re-read all this to digest... but yes, those rpms would definitely be nice...

Thanks, as usual, for your replies.