CAcert System Admins discussion list

[Mendel Mobach <cacert AT leercoden.nl>]

On Mar 27, 2009, at 7:03 PM, Philipp Gühring wrote:

> Hi,
>
> > does someone on this list have sufficient technical objections  
> > against
> > the following setup:
>
> > 1) A server with linux as Xen dom0
>
> Xen isn't used anywhere else yet. Why do we need it?

Because it does more separation than vserver.

> >   * filesystems and swap encrypted with dm-crypt
>
> Yes, that's our standard.
>
> >   * iscsi server with passwords, ACL and so on
>
> Please explain.

Because it makes the setup expandable.

> >   * local firewall preventing bad stuff from hapening
>
> Yes, as usual.
>
> > 2) A linux domU on it with an ssh server open to 'the internet'
>
> Ok.
>
> >   * supporting only key based logins (openssh doesn't support x509  
> > that
> > well)
>
> No.

Why not? Is there something against key logins? If there is a good  
reason
we should disable key logins completely.

> >   * supporting no remote root login
>
> Ok.
>
> >   * having it's root filesystem on iscsi
>
> I'll have to review iscsi ...
>
> >   * encrypted (encryption is done in the domU, not the dom0)
>
> Ok.
>
> >   * having also some ACL's to prevent bad stuff hapening from the  
> > local
> > network and the internet
>
> Ok.
>
> >   * having sudo enabled for some users
>
> Ok.
>
> >   * having iptables with -m owner allowing specific users to only ssh
> > trough to specific hosts
> >     Since this host is meant to replace some service delivered by  
> > some
> > linux at the moment
> >     it will be the host allowed in the local firewalls to connect to
> > any server.
>
> Please explain.

If we allow every 'local' user that needs access to let's say 'dns'
also have access to possibly the webserver it's not so good. the  
iptables
owner match can match on local users outgoing traffic. Meaning you
can give specific users specific access to specific machines (besides
the whole password, keys, ... thing) it's more an extra layer of
usefull security.

> >   * disallowing local keys (users have to use ssh-agent!)
>
> Please explain.

If the box get compromized for any reason the attacker has no possibilty
to use password sniffing or local authorization information from that or
any other machine.

from the ssh-agent manual:
     The agent will never send a private key over its request channel.
     Instead, operations that require a private key
     will be performed by the agent, and the result will be returned
     to the requester.  This way, private keys are not
     exposed to clients using the agent.

To disallow (by default, users can always override with stupid
actions, but policies forbid stupid things I hope).

> > 3) A linux domU unreachable for almost any user/admin
> >   * harddiskspace the same as above
> >   * running syslog-ng =>3.0.1
> >     Most clients don't yet but 3.0.1 can encrypt the logs over  
> > network
> > using TLS
>
> Ok.
>
> >   * storing and zipping those logs when needed.
>
> Ok.
>
>
> > Xen over vserver:
> > Separate memory, separate network configurations possible, possible  
> > ipv6
> > support
> > local firewalls: it's just the extra layer of security. Definitely  
> > not
> > the only one.
>
> Please explain.

It's about the advantages. vserver still doesn't support ipv6 and
I don't see it coming in the coming years in debian stable (which is
what we run at the moment).

> > Having iscsi unencrypted is almost not interesting since:
> > 1) it's only local (not routable over the internet)
> > 2) it's only local (on the box!)
> > 3) we can mirror it to a future second server using raid1 in
> >   the domU's (raid1 over the encrypted partitions).
> >   Meaning that the encrypted data won't be the same on
> >   both servers. Breaking the connection, doing
> >   something on the half part doesn't help you with
> >   running some form of attacks.
>
> Best regards,

Hope we don't break too much tomorrow ;-)

Kind Regards,

Mendel Mobach - no we're not going to build this tomorrow.

Attachment: smime.p7s
Description: S/MIME cryptographic signature