[Csync2] Public cluster -- Letting a pre-shared key escape

[Andreas J. Koenig]

>>>>> On Thu, 13 Apr 2006 13:01:01 +0200, Clifford Wolf <clifford at clifford.at> said:

  > Hi,
 >> group communityportal {
 >> host masterhost (slave1) (slave2) (slave3);
 >> key /home/ftp/pub/pre-shared-key-for-csync2.txt
 >> ...
 >> }
 >> 
 >> [..]
 >> 
 >> But there is a time window between the moment when a new slave
 >> finishes the configuration of his csync2 setup and the moment the
 >> master connects for the first time. This time window could be
 >> exploited by an attacker by pretending to be the masterhost.

  > csync2 also checks the ip-address of incoming connection. When a host
  > connects it first identifies to the peer. so when in your example the
  > 'masterhost' connects to 'slave1', 'slave1' will lookup the ip-address
  > of 'masterhost' and return an "Identification failed!" error when the
  > ip-addresses do not match.

My peers are run by hardboiled sysadmins, they might be unconvinced by
this answer. A hostname lookup can be spoofed or otherwise undermined.
What I tried to express in my previous posting: the one thing that
(with today's technology) cannot be undermined would be to add the
visitor to the database *before* the first datatransfer.

So I just tested the following which seems to work:

On the prospective new slave run a csync2 command that connects to the
masterhost *before* you even tell the masterhost that you want to
become a slave. I did this with a csync2.cfg file that had the
masterhost in it and then I started

  csync2 -x -N myname

This gave me a lot of (expected) "permission denied" errors but the
side effect was: this initialized the database file for the slave and
inserted the certdata for the master into the x509_cert table. I could
verify that with this perl snippet:

perl -le '                
 use DBI; my $db = shift or die;
 my $dbh = DBI->connect("dbi:SQLite2:dbname=$db","","") or die;
 my $sth = $dbh->prepare("select * from x509_cert");
 $sth->execute;
 while (my @row = $sth->fetchrow){
   print "row[@row]";
 }' /var/lib/csync2/XXX.db


COOOOL! This is much better than relying that the first contact with
the master will do the right thing automatically.

A variant of the above which pleases me even more, is to publish the
INSERT command to SQLite2. In this case I could even remove csync2
from inetd.conf. But it has the disadvantage that it breaks if the
database schema changes.

Thanks,
-- 
andreas