Re: To chroot or not to chroot?

[darren kirby <bulliver () badcomputer org>]

quoth the Martín Villalba:
> Hi, list! Maybe you can help me with this: I'm about to install a
> webserver, which should have an http server, webmail, php support,
> dns, ftp, remote login and a couple more things. Obviously, with all
> those ports open, I must take every security measure I know (and some
> I don't). But here comes my doubt: should I jail the webserver with
> chroot? My first thought was "Duh, yes!", but thinking about it,
> having all those services running at the same time, do I really make
> any difference? It seems to me that in such environment a cracker (no,
> i'm not writing "hacker") could do anything he (maybe she?) wants...

I am no security expert, but I do run  a setup identical to what you are 
implementing (minus the FTP and webmail) so here's my 2 cents (feel free to 
reply if I say something dumb 'real' experts ...).

My understanding of chroot, is that if the service is compromised, then the 
attacker has a very limited set of commands available, not much more than 
shell builtins. And also, each service would be chrooted individually. So 
unless you help the cracker by putting netcat, wget, and gcc in  your chroot 
it doers offer a lot of advantages.

Why do you need the DNS server? If it is only for the local LAN then simply 
change your firewall to only allow queries on the internal interface. Also, 
be sure to not allow zone transfers. DNS should be chrooted (the named docs 
imply this is the best way).

For FTP I recommend vsftpd in a chroot, but as mentioned, I don't use FTP 
so...

As for login, use sshd (of course) and only allow key-based authentication. 
This way crackers will not even get a login prompt to brute force. Also, be 
sure to disable root logins.

> Ideas? Suggestions? Donations (cash, please)?
> C-you
>
> Martín

HTH,
Darren
-- 
darren kirby :: Part of the problem since 1976 :: http://badcomputer.org
"...the number of UNIX installations has grown to 10, with more expected..."
- Dennis Ritchie and Ken Thompson, June 1972

Attachment: _bin
Description: