Anders Bruun Olsen wrote:
> I have a server that's doing just about everything a server can do. It's
> serving webpages with Apache, running mysql, handling mail for around 30
> people with Postfix, running subversion for a couple of development
> projects, running both a Ventrilo and a CounterStrike server as well as
> having a bunch of local users via ssh which use it to run mutt,
> centericq, irssi and stuff like that. In general a very active server.
> I have been having my doubts about the security on this server lately
> however, and have been looking into different solutions.
> A quick analysis will show that the solution needs to take into account
> both attacks from outside and local attacks since local users can't be
> trusted 100%.
> My first idea was to use linux-vserver, put everything into their own
> vservers and have users log into a vserver with just the programs they
> need there to minimize the threat from them. Unfortunately screen does
> not work inside vservers so this solution is no good as most users have
> their mailclient, irc client, icq client etc. running in a screen and
> just reattach to it when they log in.
> Now I could run everything in vservers and just let users login to the
> host as they do now. That would certainly limit the threat from security
> bugs in things like the CS server, and would limit the users ability to
> mess with running processes. Not that they have rights to do that
> anyway, but a layer of protection has been added. I would have liked
> this solution to use SELinux or grsecurity to give me access control to
> further boost security, but it seems that there aren't any current
> vserver+grsec patches available and the don't apply cleanly on top of
> each other. And SELinux is incompatible with vserver (I have read).
> Yet another solution would be to drop vserver and just use grsecurity or
> SELinux, but I am uncertain how good the protection against security
> holes in i.e. CS-server would be in contrast with the vserver solution.
> Yet another solution would of course be Xen, but since 3.0 is not yet in
> stable, I don't really think that's a viable solution yet.
> I might be missing some possible solution scenarios and would very much
> appreciate advice. Both regarding my ideas so far, and anything I have
> And no, buying a second server to isolate users on is not an option.
> This is a private server and I am not a rich guy :)
> Thanks in advance.
grsecurity does offer several things that I would look into here,
notably the things dealing with restricting users to only see their own
processes and the like. In general though, you need to be careful about
the security basics:
1) Don't run *anything* setuid root that you don't trust 100%. Even
then, avoid it if possible.
2) Don't use a global 'nobody' account for daemons (as this allows one
daemon running as nobody to compromise another one if compromised). Use
separate uids/gids for each daemon process and make sure they have
minimal priviledges to run.
3) Chroot jail daemon processes wherever possible.
4) Consider a shell for use with ssh which allows for restricting users
to their home dirs (a la jail-shell).
5) Log everything possible about user logins and commands. Consider
moving logs to a second system on a regular basis to avoid potential log
6) Deny remote root login via ssh. Further consider using
public/private key pair authentication for ssh.
How secure you want to be is up to you in the end. vservers, while
nice, are usually not required if you are diligent about the basics.
Systems and Networking
Speed Express Networks, LLC
email@example.com mailing list