1 |
Anders Bruun Olsen wrote: |
2 |
> Hi, |
3 |
> |
4 |
> I have a server that's doing just about everything a server can do. It's |
5 |
> serving webpages with Apache, running mysql, handling mail for around 30 |
6 |
> people with Postfix, running subversion for a couple of development |
7 |
> projects, running both a Ventrilo and a CounterStrike server as well as |
8 |
> having a bunch of local users via ssh which use it to run mutt, |
9 |
> centericq, irssi and stuff like that. In general a very active server. |
10 |
> I have been having my doubts about the security on this server lately |
11 |
> however, and have been looking into different solutions. |
12 |
> A quick analysis will show that the solution needs to take into account |
13 |
> both attacks from outside and local attacks since local users can't be |
14 |
> trusted 100%. |
15 |
> My first idea was to use linux-vserver, put everything into their own |
16 |
> vservers and have users log into a vserver with just the programs they |
17 |
> need there to minimize the threat from them. Unfortunately screen does |
18 |
> not work inside vservers so this solution is no good as most users have |
19 |
> their mailclient, irc client, icq client etc. running in a screen and |
20 |
> just reattach to it when they log in. |
21 |
> Now I could run everything in vservers and just let users login to the |
22 |
> host as they do now. That would certainly limit the threat from security |
23 |
> bugs in things like the CS server, and would limit the users ability to |
24 |
> mess with running processes. Not that they have rights to do that |
25 |
> anyway, but a layer of protection has been added. I would have liked |
26 |
> this solution to use SELinux or grsecurity to give me access control to |
27 |
> further boost security, but it seems that there aren't any current |
28 |
> vserver+grsec patches available and the don't apply cleanly on top of |
29 |
> each other. And SELinux is incompatible with vserver (I have read). |
30 |
> Yet another solution would be to drop vserver and just use grsecurity or |
31 |
> SELinux, but I am uncertain how good the protection against security |
32 |
> holes in i.e. CS-server would be in contrast with the vserver solution. |
33 |
> Yet another solution would of course be Xen, but since 3.0 is not yet in |
34 |
> stable, I don't really think that's a viable solution yet. |
35 |
> |
36 |
> I might be missing some possible solution scenarios and would very much |
37 |
> appreciate advice. Both regarding my ideas so far, and anything I have |
38 |
> missed. |
39 |
> |
40 |
> And no, buying a second server to isolate users on is not an option. |
41 |
> This is a private server and I am not a rich guy :) |
42 |
> |
43 |
> Thanks in advance. |
44 |
> |
45 |
|
46 |
grsecurity does offer several things that I would look into here, |
47 |
notably the things dealing with restricting users to only see their own |
48 |
processes and the like. In general though, you need to be careful about |
49 |
the security basics: |
50 |
|
51 |
1) Don't run *anything* setuid root that you don't trust 100%. Even |
52 |
then, avoid it if possible. |
53 |
|
54 |
2) Don't use a global 'nobody' account for daemons (as this allows one |
55 |
daemon running as nobody to compromise another one if compromised). Use |
56 |
separate uids/gids for each daemon process and make sure they have |
57 |
minimal priviledges to run. |
58 |
|
59 |
3) Chroot jail daemon processes wherever possible. |
60 |
|
61 |
4) Consider a shell for use with ssh which allows for restricting users |
62 |
to their home dirs (a la jail-shell). |
63 |
|
64 |
5) Log everything possible about user logins and commands. Consider |
65 |
moving logs to a second system on a regular basis to avoid potential log |
66 |
compromises. |
67 |
|
68 |
6) Deny remote root login via ssh. Further consider using |
69 |
public/private key pair authentication for ssh. |
70 |
|
71 |
How secure you want to be is up to you in the end. vservers, while |
72 |
nice, are usually not required if you are diligent about the basics. |
73 |
|
74 |
Good luck, |
75 |
-- |
76 |
Nathanael Hoyle |
77 |
Systems and Networking |
78 |
Speed Express Networks, LLC |
79 |
nhoyle@××××××××××××.net |
80 |
432.837.2811 |
81 |
|
82 |
-- |
83 |
gentoo-security@g.o mailing list |