[hobbit] Feature request: SSL/TLS client/server negotiation

Schwimmer, Eric E *HS EES2Y at hscmail.mcc.virginia.edu
Fri Oct 13 17:41:02 CEST 2006


> > 1.  Having to poke a hole in my hobbit server's firewall every time
I
> > add a new hobbit client.
> 
> You'd still need to open the firewall for your clients, whether you
run
> SSL or plain text across the wire. If you just open the firewall to
> allow anyone to connect to the ssl-enabled hobbit daemon, then an
> attacker may try to DoS the SSL service. And SSL protocol
implementations
> have had security problems as well.

True, however if the the client/server had a used a unique signed cert
pair (i.e. one server/client cert pair for every hobbit client), and the
server admin set up connection throttling using iptables/pf, would that
resolve those problems?

I use a modular IDS called Prelude that supports TLS secured clients in
a similar fashion.  When you want to install a new client, you run a
script on the server that waits for a connection from the new client,
using a random one-time password to authenticate.  You then run the
registration script on the client side, type in the one-time password
and authorize adding the new client on the server side.  At that point
the signed certificates are sent from the server to client, and all
subsequent interactions between the two are encrypted using those
certifications.

The process that Prelude uses is documented here:
https://trac.prelude-ids.org/wiki/RegisteringASensor

> 
> > 2.  The possibility that someone might compromise one machine
running a
> > hobbit client and use that machine to send false reports or DOS the
> > hobbit server.
> 
> Someone with access to a machine with the Hobbit client could still
run
> the "bb" program and send in a status report.  Unless you protect the
> client-side certificate with a passphrase that is kept only in memory
> - i.e. you'll have to enter it on the console whenever the machine is
> rebooted or the Hobbit client is restarted - then an attacker will
have
> access to the client certificate, and therefore he can send forged
data
> to the Hobbit server.
> 
> The client certificate does provide authentication, though - so you
know
> what server the (forged) data originates from. And rogue clients -
i.e.
> anyone with a network connection to your Hobbit server - are kept out.

Yep, I'm not sure how you could protect a machine once it had been
compromised, but as long as we could keep one compromised machine from
altering the status of tests on other machines, I'd be happy :)

-Eric




More information about the Xymon mailing list