Feature request: SSL/TLS client/server negotiation
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:
Having to poke a hole in my hobbit server's firewall every time I add a new hobbit client.
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.
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:
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:
I agree this would be a good thing. However, I am not sure that it really solves the problems you refer to:
- 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.
- 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.
- Prevent tender bits of info (such as my log files) that would otherwise traverse the network unencrypted.
True.
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?
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:
On Thu, Oct 12, 2006 at 04:00:41PM -0400, Schwimmer, Eric E *HS wrote:
- 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.
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
- 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
- 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
On Fri, Oct 13, 2006 at 11:41:02AM -0400, Schwimmer, Eric E *HS wrote:
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 :)
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
- 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.
- 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?
- 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 <EES2Y at hscmail.mcc.virginia.edu> wrote:
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:
Having to poke a hole in my hobbit server's firewall every time I add a new hobbit client.
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.
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
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
On Fri, Oct 13, 2006 at 10:40:42AM -0400, Jerry Yu wrote:
- 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?
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
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.
participants (5)
-
dan.mcdonald＠austinenergy.com
-
EES2Y＠hscmail.mcc.virginia.edu
-
henrik＠hswn.dk
-
jjj863＠gmail.com
-
jonescr＠cisco.com