Feature request: SSL/TLS client/server negotiation 🔗 link

The subject pretty much says it all :)  The top item on my hobbit wish
list is to see some sort of client/server authentication & encryption.
This will take care of three of my largest hobbit worries/problems:

1.  Having to poke a hole in my hobbit server's firewall every time I
add a new hobbit client.

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.

3.  Prevent tender bits of info (such as my log files) that would
otherwise traverse the network unencrypted.

Of course, this would break a lot of existing scripts (devmon, bb-xsnmp,
etc); perhaps it would be possible to have the secure server listen on a
different port?

I know I could do all of this with stunnel, but that's one more thing
I'd have to install and setup (and one more thing that could break) on
all of my hobbit clients. Plus, there's always the laziness factor :)

Food for thought.

-Eric

On Thu, Oct 12, 2006 at 04:00:41PM -0400, Schwimmer, Eric E *HS wrote:

I agree this would be a good thing. However, I am not sure that it
really solves the problems you refer to:

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.

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.

True.

Perhaps. My ideas for implementing this have always been that this
would best fit into the bbproxy utility; so you would have bbproxy
handling the SSL-enabled connections from clients, then forwarding 
the data in plain text (via the loopback interface or a unix domain
socket that cannot be eavesdropped upon) to the Hobbit daemon. That
would avoid changing anything in the core daemon which I believe is
a good thing.


Regards,
Henrik

On Fri, 2006-10-13 at 08:31 +0200, Henrik Stoerner wrote:

But you could use the client certificates to limit who can send updates
for a particular host.  Thus bar.example.com could not send a status
message for foo.example.com. That would go a long way to solving Eric's
problem.  
You would still need some sort of method for trusted proxies - for
example, I run bb-mrtg which provides updates for 600 "hosts" that can't
report on their own.


--
Daniel J McDonald, CCIE #2495
Linux mcdonalddj-dc.austin-energy.net 2.6.17-5mdv #1 SMP Wed Sep 13
14:32:31 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 3.40GHz GNU/Linux

1. ssl or no ssl, a hole needs to punched if you have deny-by-default
packet-filter firewall. Conceivably, you could use SSL to authenticate
client using client certificate in lieu of a packet-filter firewall.
However, Both have their own merits and may serve your need best if you use
both.
2. If you have a server (Hobbit's typical client) compromised, you have
serious problem. DoS to the Hobbit server is much lesser a concern,  since
it can be done as long as the target has public service (or is reachable
over the net).  Potential compromise of the Hobbit server by a rogue client
is more of an issue here.
So, question to Henrik,  how well Hobbit server protects itself  from a
misbehaving client ( bad-code, or malicious) with the bbd listening to
client traffic via TCP/1984 and parsing (potentially malformed/malicious)
data from the client. Any security audit has been done?
3. This can be done pretty easily by PGP or GPG. The client has server's
public key and encrypt report data with it. Server (or a new server
extension) decrypts the data then process it as usual.

On 10/12/06, Schwimmer, Eric E *HS <user-1e1008b069d5@xymon.invalid> wrote:

On Fri, Oct 13, 2006 at 10:40:42AM -0400, Jerry Yu wrote:

The only "authentication" that Hobbit has is that you can limit - by
IP-address - who is allowed to send status updates and administrative
requests (the --status-senders, --maint-senders, --www-senders and 
--admin-senders options to hobbitd). All except --admin-senders are
not enabled by default (admin requests are only allowed from the
local host where Hobbit is installed). The --status-senders option does
add some security against compromised clients (they can only affect the
status reports for the compromised host itself, not others).

There hasn't been any real audit done. I wouldn't mind if someone did a code 
review of the hobbit daemon - but I cannot do it, since I wrote it. It must 
be someone who looks at the code with fresh eyes.

hobbitd does try to protect itself from malicious traffic - checking
that the messages adhere the proper syntax for messages, dropping
connections that attempts to do data flooding. But there has to be some
bugs in that code; whether they can be found and exploited I probably
won't know until someone does. There have been a couple of security-
related bugs that got fixed during the 4.2 beta period.

I've tried to write code that is fairly robust against attacks. But
I have assumed that Hobbit is located on a fairly "friendly" network.
I would not recommend that you make port 1984 publicly available on
the Internet; at the very least, do some sort of firewalling to protect
your server from anonymous attacks.


Regards,
Henrik

I

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

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

On Fri, Oct 13, 2006 at 11:41:02AM -0400, Schwimmer, Eric E *HS wrote:

Enable the --status-senders option (see hobbitd man-page) and make sure 
you've got the right IP's listed in the bb-hosts file.


Regards,
Henrik

It should be fairly easy to mod the hobbit code so that it does a really simple scramble (XOR) of the data stream. If you do that, plus running it on a non-standard port, should sufficiently confuse most people running a sniffer. At least the data wouldn't be in plaintext and the attacker would have to code up a custom app to decode the data. If they have time to do that, they are probably good enough to own your network anyway.