On 5/20/05, Fernando Maior <fernando.souto.maior@xxxxxxxxx> wrote:
> On 5/19/05, Nils Toedtmann <xen-users@xxxxxxxxxxxxxxxxxx> wrote:
> > Am Donnerstag, den 19.05.2005, 19:49 -0400 schrieb John A. Sullivan III:
> > > Ah, perhaps I didn't make something sufficiently clear. Although
> > > several domUs will have access to the partition, only one should have it
> > > mounted at any time. In other words, the system first mounts it read
> > > only simply to check to see if anyone else has it mounted and, if they
> > > do not, they remount it as rw. There is the possibility that, in
> > > between the check and the remount as rw, something could sneak in. And
> > > there is the brief moment when it is mounted ro that another device
> > > could be writing to it in which case it is immediately unmounted.
> > >
> > > Network exchange with a big firewall does sound technically safer from
> > > corruption even if less safe from intrusion. Thanks - John
> > [...]
> > Do you want to protect the CA domU only from the outside world, or has
> > it to be protected from the other (networked, hence potentially r00ted)
> > domUs (with which the CA domU exchanges data), too?
> >
> > In the latter case, the other domU could try to attack the filesystem
> > driver of the CA domU by writing malicious fs metadata (like currupt
> > inode tables/superblocks/whatever) to that partition. I'd consider a nfs
> > relay between them safer!
> >
> > And you could make firewalling much easier if you use a "virtual DMZ"
> > toppology (all interfaces marked with a * shall use private rfc1918 ip
> > addresses):
> >
> > evil internet
> > |
> > |
> > dom0-eth0
> > |
> > |xen-br0
> > |
> > dom1-eth0
> > networked domU, maybe compromised, has to exchange data with dom3
> > dom1-eth1*
> > |
> > |xen-br1 (has no ip in dom0)
> > |
> > dom2-eth0*
> > nfs-server, no ip-forwarding
> > dom2-eth1*
> > |
> > |xen-br2 (has no ip in dom0)
> > |
> > dom3-eth0*
> > CA-domU
> >
> > Even without any firewalling: to break into the CA domU, an attacker has
> > to overtake dom1, then the nfs-service on dom2 and finally the nfs-
> > client on dom3.
> >
> > I think it would be easier to attack the sshd on dom0 to compromise them
> > all ;)
> >
> > /nils.
> >
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-users
> >
>
> Excuse my lack of knowledge, but I believe there is another
> way to get to the thing done.
>
> You want:
>
> 1) A number o domUs to write files to a place;
> 2) Make sure to have the most secure way to do it.
>
> What if...
>
> You set up a one bridge without IP number {
> brctl addbr xen-sw1
> brctl stp xen-sw1 off
> brctl setfd xen-sw1 0
> sleep 3
> ifconfig xen-sw1 up
> }
>
> Then you config your domUs to connect to the bridge,
> each one implementing a RFC 1918 ip number and
> same network for all of them. You see, any one can
> see the other, but no one can reach dom0 or the LAN.
>
> Now you configure a vsftpd to allow just one connection
> at any time. You will NOT have more then one domU
> accessing that file, for sure. And you enhance the security
> with all features on vsftpd you can, so making it very
> restricted.
>
> And you configure a firewall on each domU, accepting
> NO input/forward on the ethernet connected to the
> bridged. Except for the domU where you have vsftpd,
> which can be opened ONLY for ftpclients.
>
> Is that good?
> --
> Bye,
> Fernando Maior
> LPIC/1 31908
>
To enhance security on domUs that are ftpclients, you can
make iptables filter out any packets not related to the
domU that is the ftpserver.
--
Bye,
Fernando Maior
LPIC/1 31908
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home