| 1 |
On Tue, Nov 08, 2005 at 04:47:49PM -0600, Nathanael Hoyle wrote: |
| 2 |
> grsecurity does offer several things that I would look into here, |
| 3 |
> notably the things dealing with restricting users to only see their own |
| 4 |
> processes and the like. In general though, you need to be careful about |
| 5 |
> the security basics: |
| 6 |
|
| 7 |
Ahh yes, I remember that from playing around with grsecurity some years |
| 8 |
back. That would be very nice to have on my server. |
| 9 |
|
| 10 |
> 1) Don't run *anything* setuid root that you don't trust 100%. Even |
| 11 |
> then, avoid it if possible. |
| 12 |
|
| 13 |
I am fairly certain I don't run anything at all setuid. |
| 14 |
|
| 15 |
> 2) Don't use a global 'nobody' account for daemons (as this allows one |
| 16 |
> daemon running as nobody to compromise another one if compromised). Use |
| 17 |
> separate uids/gids for each daemon process and make sure they have |
| 18 |
> minimal priviledges to run. |
| 19 |
|
| 20 |
I use the default Gentoo accounts for daemons - fairly certain none of |
| 21 |
them use "nobody". I may be wrong? |
| 22 |
|
| 23 |
> 3) Chroot jail daemon processes wherever possible. |
| 24 |
|
| 25 |
Hmm.. any good guides or pointers to get Apache, MySQL, Postfix, |
| 26 |
Courier-imap, rsyncd, ventrilo, cs-server, zope and so on to run in |
| 27 |
jails? |
| 28 |
|
| 29 |
> 4) Consider a shell for use with ssh which allows for restricting users |
| 30 |
> to their home dirs (a la jail-shell). |
| 31 |
|
| 32 |
That's a very good idea, only they still need to be able to start their |
| 33 |
programs as they are used to. I can't seem to find jail-shell anywhere. |
| 34 |
Is it just a concept for configuring i.e. Bash or is it actually |
| 35 |
available somewhere? |
| 36 |
|
| 37 |
> 5) Log everything possible about user logins and commands. Consider |
| 38 |
> moving logs to a second system on a regular basis to avoid potential log |
| 39 |
> compromises. |
| 40 |
|
| 41 |
Unfortunately I don't have a second system to move logs to, but I can |
| 42 |
see why it would be a very good idea. |
| 43 |
|
| 44 |
> 6) Deny remote root login via ssh. Further consider using |
| 45 |
> public/private key pair authentication for ssh. |
| 46 |
|
| 47 |
All Linux installations with sshd running I have ever setup (quite a |
| 48 |
few) have had root-login via ssh blocked :). |
| 49 |
|
| 50 |
> How secure you want to be is up to you in the end. vservers, while |
| 51 |
> nice, are usually not required if you are diligent about the basics. |
| 52 |
|
| 53 |
I see your point - if I get grsecurity up and running, do sensible |
| 54 |
configurations and jail as many processes as possible I should be fine. |
| 55 |
And anyway, this isn't exactly Pentagon or NASA - my server does not |
| 56 |
hold any secrets worth breaking into, so the biggest threat is likely to |
| 57 |
be scriptkiddies who should be easily twarted by sensible configuration, |
| 58 |
grsec, jails and up-to-date program versions. |
| 59 |
|
| 60 |
Thanks! |
| 61 |
|
| 62 |
-- |
| 63 |
Anders |
| 64 |
-----BEGIN GEEK CODE BLOCK----- |
| 65 |
Version: 3.12 |
| 66 |
GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V |
| 67 |
PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y? |
| 68 |
------END GEEK CODE BLOCK------ |
| 69 |
PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0 |
| 70 |
-- |
| 71 |
gentoo-security@g.o mailing list |
Archives