[gentoo-security] Advice about security solution

[gentoo-security] Advice about security solution

[Anders Bruun Olsen]

Hi,

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
missed.

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.

-- 
Anders
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V
PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y?
------END GEEK CODE BLOCK------
PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0
-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[Nathanael Hoyle]

Anders Bruun Olsen wrote:
> Hi,
> 
> 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
> missed.
> 
> 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
compromises.

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.

Good luck,
-- 
Nathanael Hoyle
Systems and Networking
Speed Express Networks, LLC
nhoyle@speedexpress.net
432.837.2811

-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[Anders Bruun Olsen]

On Tue, Nov 08, 2005 at 04:47:49PM -0600, Nathanael Hoyle wrote:
> 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:

Ahh yes, I remember that from playing around with grsecurity some years
back. That would be very nice to have on my server.

> 1) Don't run *anything* setuid root that you don't trust 100%.  Even
> then, avoid it if possible.

I am fairly certain I don't run anything at all setuid.

> 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.

I use the default Gentoo accounts for daemons - fairly certain none of
them use "nobody". I may be wrong?

> 3) Chroot jail daemon processes wherever possible.

Hmm.. any good guides or pointers to get Apache, MySQL, Postfix,
Courier-imap, rsyncd, ventrilo, cs-server, zope and so on to run in
jails?

> 4) Consider a shell for use with ssh which allows for restricting users
> to their home dirs (a la jail-shell).

That's a very good idea, only they still need to be able to start their
programs as they are used to. I can't seem to find jail-shell anywhere.
Is it just a concept for configuring i.e. Bash or is it actually
available somewhere?

> 5) Log everything possible about user logins and commands.  Consider
> moving logs to a second system on a regular basis to avoid potential log
> compromises.

Unfortunately I don't have a second system to move logs to, but I can
see why it would be a very good idea.

> 6) Deny remote root login via ssh.  Further consider using
> public/private key pair authentication for ssh.

All Linux installations with sshd running I have ever setup (quite a
few) have had root-login via ssh blocked :).

> 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.

I see your point - if I get grsecurity up and running, do sensible
configurations and jail as many processes as possible I should be fine.
And anyway, this isn't exactly Pentagon or NASA - my server does not
hold any secrets worth breaking into, so the biggest threat is likely to
be scriptkiddies who should be easily twarted by sensible configuration,
grsec, jails and up-to-date program versions.

Thanks!

-- 
Anders
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V
PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y?
------END GEEK CODE BLOCK------
PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0
-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[Anthony Metcalf]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

On Wed, 9 Nov 2005 09:16:38 +0100
Anders Bruun Olsen <anders@bruun-olsen.net> wrote:

> > 5) Log everything possible about user logins and commands.  Consider
> > moving logs to a second system on a regular basis to avoid
> > potential log compromises.
> 
> Unfortunately I don't have a second system to move logs to, but I can
> see why it would be a very good idea.

Free web hosting sites. I'm sure there must still be a few of those
around. Or gmail, if you have an account, just encrypt and email
yourself the logs.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-security] Advice about security solution

[Anders Bruun Olsen]

On Wed, Nov 09, 2005 at 08:55:42AM +0000, Anthony Metcalf wrote:
> > > 5) Log everything possible about user logins and commands.  Consider
> > > moving logs to a second system on a regular basis to avoid
> > > potential log compromises.
> > Unfortunately I don't have a second system to move logs to, but I can
> > see why it would be a very good idea.
> Free web hosting sites. I'm sure there must still be a few of those
> around. Or gmail, if you have an account, just encrypt and email
> yourself the logs.

Wow, that is a very good idea - I'm gonna go get myself a gmail account
and mail logs to it. Thank you ever so much for that idea :)

-- 
Anders
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V
PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y?
------END GEEK CODE BLOCK------
PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0
-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[Harald Dumdey]

Hi!

2005/11/9, Anders Bruun Olsen <anders@bruun-olsen.net>:
> > Free web hosting sites. I'm sure there must still be a few of those
> > around. Or gmail, if you have an account, just encrypt and email
> > yourself the logs.

Is there a 'solution' for that? Or do i have to write a shellscript...

> Wow, that is a very good idea - I'm gonna go get myself a gmail account
> and mail logs to it. Thank you ever so much for that idea :)

This is great idea, yeah!

Regards, Harry

BTW: If you need a gmail account, send me a pm :-)

-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[Anthony Metcalf]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

On Wed, 9 Nov 2005 11:35:37 +0100
Harald Dumdey <harald.dumdey@gmail.com> wrote:

> 2005/11/9, Anders Bruun Olsen <anders@bruun-olsen.net>:
> > > Free web hosting sites. I'm sure there must still be a few of
> > > those around. Or gmail, if you have an account, just encrypt and
> > > email yourself the logs.
> 
> Is there a 'solution' for that? Or do i have to write a shellscript...
> 

Not that I know of, other than a mail client with gpg support.


> > Wow, that is a very good idea - I'm gonna go get myself a gmail
> > account and mail logs to it. Thank you ever so much for that idea :)
> 
> This is great idea, yeah!
> 

As a disclaimer, I have never done this, it just seems a reasonable
idea for distributing backups, I'm sure I've seen it suggested before.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-security] Advice about security solution

[Darren Davison]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

On Wed, 2005-11-09 at 11:35 +0100, Harald Dumdey wrote:

> Is there a 'solution' for that? Or do i have to write a shellscript...

presumably a script dropped into /etc/cron.daily would do it.  Along the
lines of (nb: totally untested) ..?

#!/bin/sh

# mail address to send compressed logs to
TO=your@remote.mail.address

# the hex ID of your GPG key
KEY=0xaabbcc99

# which logs? *.0 will pick the most recently rotated set.  You
# can probably do better
LOGS="/var/log/*.0"

HOST=`cat /etc/conf.d/hostname`
TODAY=`(date +"%y%m%d")`
OUTFILE=/tmp/$HOST_$TODAY_logs.tbz2

# tar/compress
tar cjf $OUTFILE

# encrypt
gpg -r $KEY --encrypt-files $OUTFILE

# send. Not sure how you do this without mutt..
echo "Logs.." | mutt -s "$HOST logs for $TODAY" -a $OUTFILE.gpg $TO

# clean up
rm -f $OUTFILE $OUTFILE.gpg


-- 
Darren Davison
Public Key: 0xDD356B0D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-security] Advice about security solution

[Darren Davison]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]

On Wed, 2005-11-09 at 11:42 +0000, Darren Davison wrote:

> # tar/compress
> tar cjf $OUTFILE

oops.  try

tar cjf $OUTFILE $LOGS

warned you it was untested :)
-- 
Darren Davison
Public Key: 0xDD356B0D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-security] Advice about security solution

[Harald Dumdey]

Hi Darren,

thanks for that nice little script ;-) I will try that this evening...

Regards, Harry

-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[Brian G. Peterson]

On Wednesday 09 November 2005 05:42 am, Darren Davison wrote:
> On Wed, 2005-11-09 at 11:35 +0100, Harald Dumdey wrote:
> > Is there a 'solution' for that? Or do i have to write a shellscript...
>
> presumably a script dropped into /etc/cron.daily would do it.  Along the
> lines of (nb: totally untested) ..?
>
> #!/bin/sh
>
> # mail address to send compressed logs to
> TO=your@remote.mail.address
>
> # the hex ID of your GPG key
> KEY=0xaabbcc99
>
> # which logs? *.0 will pick the most recently rotated set.  You
> # can probably do better
> LOGS="/var/log/*.0"
>
> HOST=`cat /etc/conf.d/hostname`
> TODAY=`(date +"%y%m%d")`
> OUTFILE=/tmp/$HOST_$TODAY_logs.tbz2
>
> # tar/compress
> tar cjf $OUTFILE
>
> # encrypt
> gpg -r $KEY --encrypt-files $OUTFILE

You should probably ASCII Armor the file.  More mail clients will understand 
it as an OpenPGP attachment that way:

gpg -r $KEY --armor --encrypt-files $OUTFILE

> # send. Not sure how you do this without mutt..
> echo "Logs.." | mutt -s "$HOST logs for $TODAY" -a $OUTFILE.gpg $TO

echo "Logs.." | mutt -s "$HOST logs for $TODAY" -a $OUTFILE.asc $TO

> # clean up
> rm -f $OUTFILE $OUTFILE.gpg

rm -f $OUTFILE $OUTFILE.asc

Also, you should seriously consider making your compressed file in a RAM disk 
instead of in /tmp, to avoid any issues with disk scanning. (I know these are 
system logs that are already on the system disk in plain-text, but it never 
hurts to think about what might get left behind somewhere).

If you happen to be a PHP programmer, the GPG Plugin for Squirrelmail 
(installed with the squirrelmail ebuild) includes all the GPG functions, and 
also includes functions for securely deleting temporary files.

Make sure you store the private key for this gpg keypair off the server in 
question, so that you can decrypt the logs later.

Regards,

   - Brian
-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[unaos]

On 06:30 Wed 09 Nov     , Brian G. Peterson wrote:
> 
> Also, you should seriously consider making your compressed file in a RAM disk 
> instead of in /tmp, to avoid any issues with disk scanning. (I know these are 
> system logs that are already on the system disk in plain-text, but it never 
> hurts to think about what might get left behind somewhere).

How can bash script do malloc() ?
-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[Nathanael Hoyle]

unaos wrote:
> On 06:30 Wed 09 Nov     , Brian G. Peterson wrote:
> 
>>Also, you should seriously consider making your compressed file in a RAM disk 
>>instead of in /tmp, to avoid any issues with disk scanning. (I know these are 
>>system logs that are already on the system disk in plain-text, but it never 
>>hurts to think about what might get left behind somewhere).
> 
> 
> How can bash script do malloc() ?

The poster did not mention malloc.  The poster suggested a RAM disk.
shmfs on a mount point would satisfy this requirement without needing to
introduce the complexity of malloc into the bash script.

-- 
Nathanael Hoyle
Systems and Networking
Speed Express Networks, LLC
nhoyle@speedexpress.net
432.837.2811

-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[Leonid Chaichenets]

Hello,

>>5) Log everything possible about user logins and commands.  Consider
>>moving logs to a second system on a regular basis to avoid potential log
>>compromises.
> Unfortunately I don't have a second system to move logs to, but I can
> see why it would be a very good idea.

Why don`t you mail them to a dummy mail accout (e.g
my_cryptic_mail_address_for_loging@yahoo.com)?

-- 
Good Luck,
Leo.
-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[Dave Strydom]

yeah, I've been looking for a jail-shell thing for a while now

what must i look for, or is it a setting inside bash?

Dave


On 11/9/05, Leonid Chaichenets <spam_lt@gmx.net> wrote:
> Hello,
>
> >>5) Log everything possible about user logins and commands.  Consider
> >>moving logs to a second system on a regular basis to avoid potential log
> >>compromises.
> > Unfortunately I don't have a second system to move logs to, but I can
> > see why it would be a very good idea.
>
> Why don`t you mail them to a dummy mail accout (e.g
> my_cryptic_mail_address_for_loging@yahoo.com)?
>
> --
> Good Luck,
> Leo.
> --
> gentoo-security@gentoo.org mailing list
>
>

-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[unaos]

On 11:22 Wed 09 Nov     , Dave Strydom wrote:
> Date: Wed, 9 Nov 2005 11:22:36 +0200
> From: Dave Strydom <strydom.dave@gmail.com>
> To: gentoo-security@lists.gentoo.org
> Subject: Re: [gentoo-security] Advice about security solution
> 
> yeah, I've been looking for a jail-shell thing for a while now
> 
> what must i look for, or is it a setting inside bash?
> 

have you look to /etc/security/ ?

p.s. also check-out emerge -a {text|html}-howto
and then howto/{text|html}/CHROOT-BIND*
-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[unaos]

On 09:16 Wed 09 Nov     , Anders Bruun Olsen wrote:
> 
> Hmm.. any good guides or pointers to get Apache, MySQL, Postfix,
> Courier-imap, rsyncd, ventrilo, cs-server, zope and so on to run in

recommends mod_chroot for Apache.
-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[Anders Bruun Olsen]

On Wed, Nov 09, 2005 at 09:19:38PM +0200, unaos wrote:
> > Hmm.. any good guides or pointers to get Apache, MySQL, Postfix,
> > Courier-imap, rsyncd, ventrilo, cs-server, zope and so on to run in
> recommends mod_chroot for Apache.

I have tried using mod_chroot just earlier today, but ran into trouble
because I use mod_auth_pam, which of course does not work correctly
inside a chrooted env. I am thinking about going all out and putting my
users in an LDAP directory, which would make it possible to put Apache
and other services in chroots since auth etc. would consist of
connecting to the LDAP daemon and not of asking PAM to look into
/etc/shadow.

-- 
Anders
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V
PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y?
------END GEEK CODE BLOCK------
PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0
-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[xyon]

just curious, by why not use 'net-www/mod_auth_mysql' and store your
users in a MySQL DB?



On Wed, 2005-11-09 at 22:10 +0100, Anders Bruun Olsen wrote:
> On Wed, Nov 09, 2005 at 09:19:38PM +0200, unaos wrote:
> > > Hmm.. any good guides or pointers to get Apache, MySQL, Postfix,
> > > Courier-imap, rsyncd, ventrilo, cs-server, zope and so on to run in
> > recommends mod_chroot for Apache.
> 
> I have tried using mod_chroot just earlier today, but ran into trouble
> because I use mod_auth_pam, which of course does not work correctly
> inside a chrooted env. I am thinking about going all out and putting my
> users in an LDAP directory, which would make it possible to put Apache
> and other services in chroots since auth etc. would consist of
> connecting to the LDAP daemon and not of asking PAM to look into
> /etc/shadow.
> 
> -- 
> Anders
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V
> PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y?
> ------END GEEK CODE BLOCK------
> PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0

-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[Anders Bruun Olsen]

On Wed, Nov 09, 2005 at 05:30:28PM -0500, xyon wrote:
> just curious, by why not use 'net-www/mod_auth_mysql' and store your
> users in a MySQL DB?

Because I want a single place for storing users that all services will
auth against, which also means ssh and so forth. I know that pam_mysql
will bring me most of the way, but I have my doubts about using
nss_mysql (which is also not in Portage). Call me crazy, but I neither
trust the security nor stability of mysql :)
Plus I already have experience with LDAP...

-- 
Anders
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V
PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y?
------END GEEK CODE BLOCK------
PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0
-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[William Yang]

Anders Bruun Olsen wrote:
> On Wed, Nov 09, 2005 at 05:30:28PM -0500, xyon wrote:
> 
>>just curious, by why not use 'net-www/mod_auth_mysql' and store your
>>users in a MySQL DB?
> 
> 
> Because I want a single place for storing users that all services will
> auth against, which also means ssh and so forth. I know that pam_mysql
> will bring me most of the way, but I have my doubts about using
> nss_mysql (which is also not in Portage). Call me crazy, but I neither
> trust the security nor stability of mysql :)
> Plus I already have experience with LDAP...
> 

I run a production ISP environment--http/ftp, e-mail, limited user 
shells, RADIUS dialup auth--using pam_mysql, and have for more than a 
year.  There have been no stability issues and, to date, no security 
problems that we've detected.

The biggest problem has to do with performance, which nscd was excellent 
for.  NSCD does odd things when the MySQL queries return numbers 
significantly smaller than the number of rows in the user auth tables -- 
I found that it would periodically just crash when I had disabled or 
locked-out accounts.  A daemon which checks and restarts core services 
was all I needed to take care of it, though.

	-Bill
-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[Anders Bruun Olsen]

On Sun, Nov 13, 2005 at 08:41:21PM -0500, William Yang wrote:
> >>just curious, by why not use 'net-www/mod_auth_mysql' and store your
> >>users in a MySQL DB?
> >Because I want a single place for storing users that all services will
> >auth against, which also means ssh and so forth. I know that pam_mysql
> >will bring me most of the way, but I have my doubts about using
> >nss_mysql (which is also not in Portage). Call me crazy, but I neither
> >trust the security nor stability of mysql :)
> >Plus I already have experience with LDAP...
> I run a production ISP environment--http/ftp, e-mail, limited user 
> shells, RADIUS dialup auth--using pam_mysql, and have for more than a 
> year.  There have been no stability issues and, to date, no security 
> problems that we've detected.
> The biggest problem has to do with performance, which nscd was excellent 
> for.  NSCD does odd things when the MySQL queries return numbers 
> significantly smaller than the number of rows in the user auth tables -- 
> I found that it would periodically just crash when I had disabled or 
> locked-out accounts.  A daemon which checks and restarts core services 
> was all I needed to take care of it, though.

If you have daemons that crash periodically and needs to be restarted, I
would say that counts as stability issues. At least it does in my book.

But if you can live with it, then it's all good. I prefer the stability
of LDAP however :)

-- 
Anders
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V
PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y?
------END GEEK CODE BLOCK------
PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0
-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[Nathanael Hoyle]

Anders Bruun Olsen wrote:
> On Tue, Nov 08, 2005 at 04:47:49PM -0600, Nathanael Hoyle wrote:
> 
>>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:
> 
> 
> Ahh yes, I remember that from playing around with grsecurity some years
> back. That would be very nice to have on my server.
> 
> 
>>1) Don't run *anything* setuid root that you don't trust 100%.  Even
>>then, avoid it if possible.
> 
> 
> I am fairly certain I don't run anything at all setuid.
> 
> 
>>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.
> 
> 
> I use the default Gentoo accounts for daemons - fairly certain none of
> them use "nobody". I may be wrong?
> 

Can't answer that question for all gentoo ebuilds.  There are probably
some that do.  I haven't run all of the daemons that you are running,
but rather than assume, check them out individually.  As one example, I
was dismayed to realize when I emerged pdns that by default it just runs
root.  I manually added a user and group for pdns and modified the
config to run as those users after binding the port initially (since
port 53 is priviledged).  I'd verify user id's for each daemon.
> 
>>3) Chroot jail daemon processes wherever possible.
> 
> 
> Hmm.. any good guides or pointers to get Apache, MySQL, Postfix,
> Courier-imap, rsyncd, ventrilo, cs-server, zope and so on to run in
> jails?
> 
As another poster has mentioned, mod_chroot for apache is worth looking
into.  rsyncd on gentoo comes with options to chroot in the conf.d as I
recall.  Postfix is quite happy to chroot after setting a config option
as long as the jail is set up properly.  The docs on postfix.org go into
this setup pretty carefully.

> 
>>4) Consider a shell for use with ssh which allows for restricting users
>>to their home dirs (a la jail-shell).
> 
> 
> That's a very good idea, only they still need to be able to start their
> programs as they are used to. I can't seem to find jail-shell anywhere.
> Is it just a concept for configuring i.e. Bash or is it actually
> available somewhere?

Googling "jail shell" turns up several different shells designed for this.
> 
> 
>>5) Log everything possible about user logins and commands.  Consider
>>moving logs to a second system on a regular basis to avoid potential log
>>compromises.
> 
> 
> Unfortunately I don't have a second system to move logs to, but I can
> see why it would be a very good idea.
> 
> 
>>6) Deny remote root login via ssh.  Further consider using
>>public/private key pair authentication for ssh.
> 
> 
> All Linux installations with sshd running I have ever setup (quite a
> few) have had root-login via ssh blocked :).
> 
> 
>>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.
> 
> 
> I see your point - if I get grsecurity up and running, do sensible
> configurations and jail as many processes as possible I should be fine.
> And anyway, this isn't exactly Pentagon or NASA - my server does not
> hold any secrets worth breaking into, so the biggest threat is likely to
> be scriptkiddies who should be easily twarted by sensible configuration,
> grsec, jails and up-to-date program versions.
> 
> Thanks!
> 

Good luck,
-- 
Nathanael Hoyle
Systems and Networking
Speed Express Networks, LLC
nhoyle@speedexpress.net
432.837.2811

-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[Anders Bruun Olsen]

On Wed, Nov 09, 2005 at 02:26:28PM -0600, Nathanael Hoyle wrote:
> > I use the default Gentoo accounts for daemons - fairly certain none of
> > them use "nobody". I may be wrong?
> Can't answer that question for all gentoo ebuilds.  There are probably
> some that do.  I haven't run all of the daemons that you are running,
> but rather than assume, check them out individually.  As one example, I
> was dismayed to realize when I emerged pdns that by default it just runs
> root.  I manually added a user and group for pdns and modified the
> config to run as those users after binding the port initially (since
> port 53 is priviledged).  I'd verify user id's for each daemon.

That's probably a very good idea.

> >>3) Chroot jail daemon processes wherever possible.
> > Hmm.. any good guides or pointers to get Apache, MySQL, Postfix,
> > Courier-imap, rsyncd, ventrilo, cs-server, zope and so on to run in
> > jails?
> As another poster has mentioned, mod_chroot for apache is worth looking
> into.  rsyncd on gentoo comes with options to chroot in the conf.d as I
> recall.  Postfix is quite happy to chroot after setting a config option
> as long as the jail is set up properly.  The docs on postfix.org go into
> this setup pretty carefully.

Now that you mention it, I seem to recall actually having run rsyncd in
a chroot earlier. And for Postfix I'm gonna go run off to postfix.org
asap - or maybe that Postfix book I bought earlier this year has
something about that subject. It's the one by Patrick Koetter and Ralf
Hildebrandt and I seem to recall that they are very security concious.

> > That's a very good idea, only they still need to be able to start their
> > programs as they are used to. I can't seem to find jail-shell anywhere.
> > Is it just a concept for configuring i.e. Bash or is it actually
> > available somewhere?
> Googling "jail shell" turns up several different shells designed for this.

Of course, I should have tried thinking a little there - I'll go google
it :)

> Good luck,

Thank you.

-- 
Anders
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V
PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y?
------END GEEK CODE BLOCK------
PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0
-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[Nathanael Hoyle]

Anders Bruun Olsen wrote:
> On Wed, Nov 09, 2005 at 02:26:28PM -0600, Nathanael Hoyle wrote:
> 
>>>I use the default Gentoo accounts for daemons - fairly certain none of
>>>them use "nobody". I may be wrong?
>>
>>Can't answer that question for all gentoo ebuilds.  There are probably
>>some that do.  I haven't run all of the daemons that you are running,
>>but rather than assume, check them out individually.  As one example, I
>>was dismayed to realize when I emerged pdns that by default it just runs
>>root.  I manually added a user and group for pdns and modified the
>>config to run as those users after binding the port initially (since
>>port 53 is priviledged).  I'd verify user id's for each daemon.
> 
> 
> That's probably a very good idea.
> 
> 
>>>>3) Chroot jail daemon processes wherever possible.
>>>
>>>Hmm.. any good guides or pointers to get Apache, MySQL, Postfix,
>>>Courier-imap, rsyncd, ventrilo, cs-server, zope and so on to run in
>>>jails?
>>
>>As another poster has mentioned, mod_chroot for apache is worth looking
>>into.  rsyncd on gentoo comes with options to chroot in the conf.d as I
>>recall.  Postfix is quite happy to chroot after setting a config option
>>as long as the jail is set up properly.  The docs on postfix.org go into
>>this setup pretty carefully.
> 
> 
> Now that you mention it, I seem to recall actually having run rsyncd in
> a chroot earlier. And for Postfix I'm gonna go run off to postfix.org
> asap - or maybe that Postfix book I bought earlier this year has
> something about that subject. It's the one by Patrick Koetter and Ralf
> Hildebrandt and I seem to recall that they are very security concious.
> 
> 
That would be "The Book of Postfix".  I'm an active participant in the
Postfix users' list, and I've corresponded with Patrick and Ralf several
times, they know their stuff and I've heard very good things about the
book, planning to pick up a copy one of these days.  I'd expect the
coverage of security aspects to be quite good.


>>>That's a very good idea, only they still need to be able to start their
>>>programs as they are used to. I can't seem to find jail-shell anywhere.
>>>Is it just a concept for configuring i.e. Bash or is it actually
>>>available somewhere?
>>
>>Googling "jail shell" turns up several different shells designed for this.
> 
> 
> Of course, I should have tried thinking a little there - I'll go google
> it :)
> 
> 
>>Good luck,
> 
> 
> Thank you.
> 


-- 
Nathanael Hoyle
Systems and Networking
Speed Express Networks, LLC
nhoyle@speedexpress.net
432.837.2811

-- 
gentoo-security@gentoo.org mailing list

Re: [gentoo-security] Advice about security solution

[Shane Hickey]

Anders Bruun Olsen <anders@bruun-olsen.net> [2005-11-09 09:16]:
> > 3) Chroot jail daemon processes wherever possible.
> 
> Hmm.. any good guides or pointers to get Apache, MySQL, Postfix,
> Courier-imap, rsyncd, ventrilo, cs-server, zope and so on to run in
> jails?

Here's some helpful links for hardening Apache/PHP (mod_security and
chrooting)

Apache/PHP4/Mysql hardening techniques (including chroot)
http://www.howsyournetwork.com/index.php/cID/cca7317a/ID/a0dee364ae857df2f18a78e6679733c1/fuseaction/base.detail.htm

How to get php's mail() function to work with mod_security chroot
http://www.howsyournetwork.com/index.php/cID/cca7317a/ID/3c12dbef741f39e9e8f609f19ed455e0/fuseaction/base.detail.htm

If those links wrap weird, try to go to the knowledge base on our site
(http://www.howsyournetwork.com) and then click on "Web Servers"

Shane

-- 
Shane Hickey <shane@howsyournetwork.com>: Network/System Consultant
GPG KeyID: 777CBF3F
Key fingerprint: 254F B2AC 9939 C715 278C  DA95 4109 9F69 777C BF3F
-- 
gentoo-security@gentoo.org mailing list