Agent Communication

[ckatterl]

Hi,

is there a possibility for encrypted communication between agent and server? Maybe SSL or so...

Is it possible/how is it possible to monitor services from "outside" (ssh/imap/pop3/smtp/http/https)

Best regards,

Chris

[netod]

One way to do this would be to use IPSEC in transport mode to encrypt communication between hosts. But I am also very interested in knowing when zabbix would be able to do this internally.

[ckatterl]

building up an IPSec tunnel would be a possibility, but it's not very nice...
built in encryption would be useful for "external" checks...

[bbrendon]

I don't know much about puppet yet, but the way it works with agents seems like a good approach for zabbix.

The problem is, puppet is written in python, so the code isn't re-usable.

It has good ideas though...

[globifrosch]

Encrypted communication

is there a possibility for encrypted communication between agent and server? Maybe SSL or so...

maybe make a port redirection with SSH?

ssh -L port:hostname:port hostname

or have a look at:

http://www.stunnel.org/

[netod]

Re: Encryption

Yeah stunnel is possible, so is port redirection via SSH. These are all good ideas. The problem is when you scale this type of system to n nodes. The workload becomes a nightmare trying to maintain all these connections. Makes sure stunnel process is running, or SSH tunnel is up etc. I think using IPSEC in transport mode is quote a good option as its easier to configure than IPSEC in tunnel mode. Having said that, nothing would beat Zabbix having internal support for SSL. The implementation wouldn't be that hard as you could have server/client certificates and deploy them with the zabbix agent. This way when a host becomes unreachable (reboots whatever) zabbix would internally be able to re-establish the connection.

So my question is, are there plans for implementing SSL into zabbix and what are the timeframes for this feature?

[DaveHowe]

Relay agent?

It would be nice if there were a zabbix-controlled remote agent, rather than a tunnel point; there are lots of things (snmp polls, traps, that sort of thing) which could do with a relatively light relay agent that could be run as (for example) a windows service; if some prefiltering could be done at that point to minimise network traffic and eliminate redundant messages (such as the standard filtering dependency example, server down/router down)that would be good, but probably exceeds the remit of a lightweight "point of presence" service.

One solution we are currently evaluating has this sort of setup as a standard feature - but then, they host their service centrally, and the POP agents collect the actual data onsite and relay via (proxy capable) https to their central server, where it is collated and displayed as pretty graphs and red/yellow/green "traffic light" status bars.

[richb]

I thought about this, though I came to the conclusion that it wasn't really worth it - I'm not particularly bothered if somebody knows that my hard disk is filling up (if it were my credit card number I might be more concerned).

The solution you are looking for is Stunnel (http://www.stunnel.org/ ) which will wrap anything inside SSL - I use it for MySQL replication between sites amongst other things. The documentation is very good but basically:

Install stunnel at both ends
Point the client to 127.0.0.1 port [whatever you configure]
Point port [whatever] on the server to 10051

The client will then connect to itself, the message gets wrapped inside SSL, then sent to the server which unencrypts it and forwards it to Zabbix.

[schneck]

Overhead

Currently, I'm also using

zabbix_server <--> stunnel <--> (internet) <--> stunnel <--> zabbix_agent.

While this setup works fine, there is a problem with Zabbix sending each item in a separate TCP connection. So if you have many (n) agents with many (m) items, you also have many (n*m) RSA calculations on the server side ... and these eat up cpu cycles.

In the ``Santa Claus Wish List For 1.6'' thread, someone asked for multiplexing several items over one TCP connection ... which would help in this situation. (Also, someone else proposed adding TLS natively to Zabbix, which would make configuring everything easier, but not reduce the load on the server)

On the other hand, cpu cycles come pretty cheap these days and Alexei's brain cycles are certainly better spent on more important stuff!

\B.

[qix]

Perhaps a somewhat simpler, shared secret based encryption would be less complicated to integrate in the current source?