I have a customer who is concerned that anyone could send data messages to the xymon server with one of his host names and Xymon would accept it as real thus potentially masking an attack.
Note that this is in a university environment, so even if data can come only from campus addresses we might not necessarily trust the data.
Is there a way to get Xymon to check the IP address on incoming data packets to verify that it is coming from the host it claims to be?
Thanks, Steve Holmes Purdue University
Not sure that can be done in Xymon currently.
So, is the concern that one of the configured hosts could pretend to be one of the other configured hosts? If not, a nice packet filter/firewall allowing tcp:1984 from only the Xymon hosts -> Xymon server would provide a possible fix for that.
Regards, Tim
From: xymon-bounces at xymon.com [xymon-bounces at xymon.com] on behalf of Steve Holmes [sholmes42 at mac.com] Sent: Wednesday, December 05, 2012 9:14 AM To: xymon at xymon.com Subject: [Xymon] Xymon security concern raised
I have a customer who is concerned that anyone could send data messages to the xymon server with one of his host names and Xymon would accept it as real thus potentially masking an attack.
Note that this is in a university environment, so even if data can come only from campus addresses we might not necessarily trust the data.
Is there a way to get Xymon to check the IP address on incoming data packets to verify that it is coming from the host it claims to be?
Thanks, Steve Holmes Purdue University
I believe the concern is that a student or other 'non-admin' could send a packet from an unconfigured workstation masquerading as a configured host. I think I need to do a little more research on the problem. Thanks! Steve
On Wed, Dec 5, 2012 at 12:30 PM, Tim McCloskey <tm at freedom.com> wrote:
Not sure that can be done in Xymon currently.
So, is the concern that one of the configured hosts could pretend to be one of the other configured hosts? If not, a nice packet filter/firewall allowing tcp:1984 from only the Xymon hosts -> Xymon server would provide a possible fix for that.
Regards, Tim
From: xymon-bounces at xymon.com [xymon-bounces at xymon.com] on behalf of Steve Holmes [sholmes42 at mac.com] Sent: Wednesday, December 05, 2012 9:14 AM To: xymon at xymon.com Subject: [Xymon] Xymon security concern raised
I have a customer who is concerned that anyone could send data messages to the xymon server with one of his host names and Xymon would accept it as real thus potentially masking an attack.
Note that this is in a university environment, so even if data can come only from campus addresses we might not necessarily trust the data.
Is there a way to get Xymon to check the IP address on incoming data packets to verify that it is coming from the host it claims to be?
Thanks, Steve Holmes Purdue University
-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958)
I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
My understanding is that it's fairly easy to do, also. I don't know if having a proxy in between helps at all or any of that, but my understanding is that what's sent is fairly simple and plain text (I believe there's info about the protocol in the manual).
That said, I'm not 100% sure what nefarious thing someone could do with that information. I guess they could open the rlogin port or something and then send a status message to indicate it's still closed?
On 12/05/2012 03:20 PM, Steve Holmes wrote:
I believe the concern is that a student or other 'non-admin' could send a packet from an unconfigured workstation masquerading as a configured host. I think I need to do a little more research on the problem. Thanks! Steve
On Wed, Dec 5, 2012 at 12:30 PM, Tim McCloskey <tm at freedom.com <mailto:tm at freedom.com>> wrote:
Not sure that can be done in Xymon currently.
So, is the concern that one of the configured hosts could pretend to be one of the other configured hosts? If not, a nice packet filter/firewall allowing tcp:1984 from only the Xymon hosts -> Xymon server would provide a possible fix for that.
Regards, Tim ________________________________________ From: xymon-bounces at xymon.com <mailto:xymon-bounces at xymon.com> [xymon-bounces at xymon.com <mailto:xymon-bounces at xymon.com>] on behalf of Steve Holmes [sholmes42 at mac.com <mailto:sholmes42 at mac.com>] Sent: Wednesday, December 05, 2012 9:14 AM To: xymon at xymon.com <mailto:xymon at xymon.com> Subject: [Xymon] Xymon security concern raised
I have a customer who is concerned that anyone could send data messages to the xymon server with one of his host names and Xymon would accept it as real thus potentially masking an attack.
Note that this is in a university environment, so even if data can come only from campus addresses we might not necessarily trust the data.
Is there a way to get Xymon to check the IP address on incoming data packets to verify that it is coming from the host it claims to be?
Thanks, Steve Holmes Purdue University
-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958)
I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
- ---- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer |$&| |__| | | |__/ | \| _| |novosirj at umdnj.edu - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC 450, Newark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC/sNIACgkQmb+gadEcsb5FcgCfck8FSSTUeliU9HOmiN+FlFbA 3WEAnioFl9s0Y+08N6V6ox5f4tNH5F6G =1fR8 -----END PGP SIGNATURE-----
On a side note I actually do this on purpose in my environment.
I got a Solaris Cluster running cluster resources in zoneclusters.
Instead of running ext/scripts in the zone I run them in the globalzone and fake the delivery hostname to be the zoneclusters logicalhostname.
Eg. Xymon $XYMSRV "status <zoneclusterhostname>.clustertest $COLOR date $Message"
Works brilliantly.
I remember a while back there was a discussion on how to encrypt the message over the xymon port 1984, that will surely prevent any false messages going through. (as false clients can't encrypt with the right key) Can't remember the outcome of the discussion.
- Roland
-----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Novosielski, Ryan Sent: Thursday, 6 December 2012 7:39 AM To: Steve Holmes Cc: xymon at xymon.com Subject: Re: [Xymon] Xymon security concern raised
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
My understanding is that it's fairly easy to do, also. I don't know if having a proxy in between helps at all or any of that, but my understanding is that what's sent is fairly simple and plain text (I believe there's info about the protocol in the manual).
That said, I'm not 100% sure what nefarious thing someone could do with that information. I guess they could open the rlogin port or something and then send a status message to indicate it's still closed?
On 12/05/2012 03:20 PM, Steve Holmes wrote:
I believe the concern is that a student or other 'non-admin' could send a packet from an unconfigured workstation masquerading as a configured host. I think I need to do a little more research on the problem. Thanks! Steve
On Wed, Dec 5, 2012 at 12:30 PM, Tim McCloskey <tm at freedom.com <mailto:tm at freedom.com>> wrote:
Not sure that can be done in Xymon currently.
So, is the concern that one of the configured hosts could pretend to be one of the other configured hosts? If not, a nice packet filter/firewall allowing tcp:1984 from only the Xymon hosts -> Xymon server would provide a possible fix for that.
Regards, Tim ________________________________________ From: xymon-bounces at xymon.com <mailto:xymon-bounces at xymon.com> [xymon-bounces at xymon.com <mailto:xymon-bounces at xymon.com>] on behalf of Steve Holmes [sholmes42 at mac.com <mailto:sholmes42 at mac.com>] Sent: Wednesday, December 05, 2012 9:14 AM To: xymon at xymon.com <mailto:xymon at xymon.com> Subject: [Xymon] Xymon security concern raised
I have a customer who is concerned that anyone could send data messages to the xymon server with one of his host names and Xymon would accept it as real thus potentially masking an attack.
Note that this is in a university environment, so even if data can come only from campus addresses we might not necessarily trust the data.
Is there a way to get Xymon to check the IP address on incoming data packets to verify that it is coming from the host it claims to be?
Thanks, Steve Holmes Purdue University
-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958)
I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
- ---- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer |$&| |__| | | |__/ | \| _| |novosirj at umdnj.edu - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC 450, Newark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC/sNIACgkQmb+gadEcsb5FcgCfck8FSSTUeliU9HOmiN+FlFbA 3WEAnioFl9s0Y+08N6V6ox5f4tNH5F6G =1fR8 -----END PGP SIGNATURE-----
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
I know this is offtopic, but how did you get them to not end up as ghost clients with differing hostnames and sent-from values? I'd really love to do this for monitoring multiple ESXi machines on the internal network from one server. I tried using multihomed in hosts.cfg, but was not having much luck.
----- Original Message ----- From: "Roland Soderstrom" <Rolands at logicaltech.com.au> To: xymon at xymon.com Sent: Wednesday, December 5, 2012 12:51:41 PM Subject: Re: [Xymon] Xymon security concern raised
On a side note I actually do this on purpose in my environment.
I got a Solaris Cluster running cluster resources in zoneclusters.
Instead of running ext/scripts in the zone I run them in the globalzone and fake the delivery hostname to be the zoneclusters logicalhostname.
Eg. Xymon $XYMSRV "status <zoneclusterhostname>.clustertest $COLOR date $Message"
Works brilliantly.
I remember a while back there was a discussion on how to encrypt the message over the xymon port 1984, that will surely prevent any false messages going through. (as false clients can't encrypt with the right key) Can't remember the outcome of the discussion.
- Roland
-----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Novosielski, Ryan Sent: Thursday, 6 December 2012 7:39 AM To: Steve Holmes Cc: xymon at xymon.com Subject: Re: [Xymon] Xymon security concern raised
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
My understanding is that it's fairly easy to do, also. I don't know if having a proxy in between helps at all or any of that, but my understanding is that what's sent is fairly simple and plain text (I believe there's info about the protocol in the manual).
That said, I'm not 100% sure what nefarious thing someone could do with that information. I guess they could open the rlogin port or something and then send a status message to indicate it's still closed?
On 12/05/2012 03:20 PM, Steve Holmes wrote:
I believe the concern is that a student or other 'non-admin' could send a packet from an unconfigured workstation masquerading as a configured host. I think I need to do a little more research on the problem. Thanks! Steve
On Wed, Dec 5, 2012 at 12:30 PM, Tim McCloskey <tm at freedom.com <mailto:tm at freedom.com>> wrote:
Not sure that can be done in Xymon currently.
So, is the concern that one of the configured hosts could pretend to be one of the other configured hosts? If not, a nice packet filter/firewall allowing tcp:1984 from only the Xymon hosts -> Xymon server would provide a possible fix for that.
Regards, Tim ________________________________________ From: xymon-bounces at xymon.com <mailto:xymon-bounces at xymon.com> [xymon-bounces at xymon.com <mailto:xymon-bounces at xymon.com>] on behalf of Steve Holmes [sholmes42 at mac.com <mailto:sholmes42 at mac.com>] Sent: Wednesday, December 05, 2012 9:14 AM To: xymon at xymon.com <mailto:xymon at xymon.com> Subject: [Xymon] Xymon security concern raised
I have a customer who is concerned that anyone could send data messages to the xymon server with one of his host names and Xymon would accept it as real thus potentially masking an attack.
Note that this is in a university environment, so even if data can come only from campus addresses we might not necessarily trust the data.
Is there a way to get Xymon to check the IP address on incoming data packets to verify that it is coming from the host it claims to be?
Thanks, Steve Holmes Purdue University
-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958)
I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
- ---- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer |$&| |__| | | |__/ | \| _| |novosirj at umdnj.edu - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC 450, Newark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC/sNIACgkQmb+gadEcsb5FcgCfck8FSSTUeliU9HOmiN+FlFbA 3WEAnioFl9s0Y+08N6V6ox5f4tNH5F6G =1fR8 -----END PGP SIGNATURE-----
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On 12/5/2012 1:38 PM, Novosielski, Ryan wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
My understanding is that it's fairly easy to do, also. I don't know if having a proxy in between helps at all or any of that, but my understanding is that what's sent is fairly simple and plain text (I believe there's info about the protocol in the manual).
That said, I'm not 100% sure what nefarious thing someone could do with that information. I guess they could open the rlogin port or something and then send a status message to indicate it's still closed?
Nefarious users can create false alarms that must be investigated. They
can "drop" your host entries and therefore wipe out incredible amounts
of RRD graph history. If you have tests with delayed notification, it
would be possible to prevent notifications on real alarm conditions.
There are probably other nasty things I haven't thought of.
Thanks, Shawn
iptables on the xymon server could allow a list or range of IP addresses and/or block any address outside the segments that contain servers you want to allow. That can be implemented right now, outside xymon, to limit the risk.
Ralph Mitchell
On Fri, Dec 7, 2012 at 10:41 PM, Shawn Heisey <hobbit at elyograg.org> wrote:
On 12/5/2012 1:38 PM, Novosielski, Ryan wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
My understanding is that it's fairly easy to do, also. I don't know if having a proxy in between helps at all or any of that, but my understanding is that what's sent is fairly simple and plain text (I believe there's info about the protocol in the manual).
That said, I'm not 100% sure what nefarious thing someone could do with that information. I guess they could open the rlogin port or something and then send a status message to indicate it's still closed?
Nefarious users can create false alarms that must be investigated. They can "drop" your host entries and therefore wipe out incredible amounts of RRD graph history. If you have tests with delayed notification, it would be possible to prevent notifications on real alarm conditions. There are probably other nasty things I haven't thought of.
Thanks, Shawn
______________________________**_________________ Xymon mailing list Xymon at xymon.com http://lists.xymon.com/**mailman/listinfo/xymon<http://lists.xymon.com/mailman/listinfo/xymon>
Oddly enough, since writing BB in 1995, I've never seen this exploited.
I also don't think it could cause you to drop tests (or rrd data for that matter).
I think the worst thing that could be done is to just put a machine in 'maintenance mode' and then exploit it using a rootkit or something which might essentially "turn off the alarm".
To combat this I implemented a new BB message, bbcrypto - which used a system of shared secrets on clients and servers - for Henrik or anyone else that wants to code it, here's how it works:
If a "secret file" exists on the client for the server, then encrypt the file using the secret (in the file) via blowfish, then wrap it with the 'bbcrypto' keyword.
On the server side, if you see a 'bbcrypto' message, use the shared secret in the 'secret file' to decrypt the message, once decrypted, process it like a normal BB/Xymon message.
Just so people don't freak out :)
Shawn Heisey wrote:
On 12/5/2012 1:38 PM, Novosielski, Ryan wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
My understanding is that it's fairly easy to do, also. I don't know if having a proxy in between helps at all or any of that, but my understanding is that what's sent is fairly simple and plain text (I believe there's info about the protocol in the manual).
That said, I'm not 100% sure what nefarious thing someone could do with that information. I guess they could open the rlogin port or something and then send a status message to indicate it's still closed?
Nefarious users can create false alarms that must be investigated. They can "drop" your host entries and therefore wipe out incredible amounts of RRD graph history. If you have tests with delayed notification, it would be possible to prevent notifications on real alarm conditions.
There are probably other nasty things I haven't thought of.Thanks, Shawn
-- Sean MacGuire sean at maclawran.ca
Key West +1 305 390 0888 The best way to predict the future is to invent it. - Alan Kay
I have a customer who is concerned that anyone could send data messages to the xymon server with one of his host names and Xymon would accept it as real thus potentially masking an attack.
Note that this is in a university environment, so even if data can come only from campus addresses we might not necessarily trust the data.
Is there a way to get Xymon to check the IP address on incoming data packets to verify that it is coming from the host it claims to be?
--status-senders is the option you'd want to look into (though I've never actually used it myself); by default Xymon accepts reports from everything about everything (although it does record the source IP, for later investigation). This is key when you have -say- a network poller returning information about the http test for your www.example.com host.
Regards, -jc
=== man xymond snippet below ===
--status-senders=IP[/MASK][,IP/MASK] Controls which hosts may send "status", "combo", "config" and "query" commands to xymond.
By default, any host can send status-updates. If this option is used,
then status-updates are accepted only if they are sent by one of the IP-adresses listed here, or if they are sent from the IP-address of the host that the updates pertains to (this is to allow Xymon clients to send in their own status updates, without having to list all clients here). So typically you will need to list your servers running network tests here.
The format of this option is a list of IP-adresses, optionally with a
network mask in the form of the number of bits. E.g. if you want to accept status-updates from the host 172.16.10.2, you would use
--status-senders=172.16.10.2
whereas if you want to accept status updates from both 172.16.10.2 and
from all of the hosts on the 10.0.2.* network (a 24-bit IP network), you would use
--status-senders=172.16.10.2,10.0.2.0/24
Thanks.
I tried that and started getting a lot of refused messages referencing the monitored systems. I forgot to mention that this is release 4.2.3. If it is different in 4.3.x then I will have to wait a couple of months.
I see:
"... or if they are sent from the IP-address of the host that the updates pertains to (this is to allow Xymon clients to send in their own status updates, without having to list all clients here)
This seems to say that any value in --status-senders triggers this behavior (which is the way I interpreted it), but apparently that is not the case. At least not in 4.2.3.
Anything I'm missing? If there is some other value I need in there, like a network mask for all the networks all of my xymon clients are on (hundreds probably, I don't know), I don't think it will work for me.
Thanks, Steve
On Wed, Dec 5, 2012 at 12:34 PM, <cleaver at terabithia.org> wrote:
I have a customer who is concerned that anyone could send data messages to the xymon server with one of his host names and Xymon would accept it as real thus potentially masking an attack.
Note that this is in a university environment, so even if data can come only from campus addresses we might not necessarily trust the data.
Is there a way to get Xymon to check the IP address on incoming data packets to verify that it is coming from the host it claims to be?
--status-senders is the option you'd want to look into (though I've never actually used it myself); by default Xymon accepts reports from everything about everything (although it does record the source IP, for later investigation). This is key when you have -say- a network poller returning information about the http test for your www.example.com host.
Regards, -jc
=== man xymond snippet below ===
--status-senders=IP[/MASK][,IP/MASK] Controls which hosts may send "status", "combo", "config" and "query" commands to xymond.
By default, any host can send status-updates. If this option is used,then status-updates are accepted only if they are sent by one of the IP-adresses listed here, or if they are sent from the IP-address of the host that the updates pertains to (this is to allow Xymon clients to send in their own status updates, without having to list all clients here). So typically you will need to list your servers running network tests here.
The format of this option is a list of IP-adresses, optionally with anetwork mask in the form of the number of bits. E.g. if you want to accept status-updates from the host 172.16.10.2, you would use
--status-senders=172.16.10.2 whereas if you want to accept status updates from both 172.16.10.2 andfrom all of the hosts on the 10.0.2.* network (a 24-bit IP network), you would use
--status-senders=172.16.10.2,10.0.2.0/24
-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958)
I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
On 05-12-2012 21:04, Steve Holmes wrote:
I tried that and started getting a lot of refused messages referencing the monitored systems. I forgot to mention that this is release 4.2.3. If it is different in 4.3.x then I will have to wait a couple of months.
In --status-senders, you should list
- the Xymon server itself
- any hosts running network tests
The reason for 1) is somewhat obscure, but basically boils down to the Xymon client data triggering status-messages sent locally from the xymond_client daemon.
This behaviour is unchanged from 4.2.x to 4.3.x.
In 5.0, you can implement SSL client certificate checks for complete control of who is allowed to send status updates.
Regards, Henrik
On Wed, Dec 5, 2012 at 3:57 PM, Henrik Størner <henrik at hswn.dk> wrote:
On 05-12-2012 21:04, Steve Holmes wrote:
I tried that and started getting a lot of refused messages referencing the monitored systems. I forgot to mention that this is release 4.2.3. If it is different in 4.3.x then I will have to wait a couple of months.
In --status-senders, you should list
- the Xymon server itself
- any hosts running network tests
The reason for 1) is somewhat obscure, but basically boils down to the Xymon client data triggering status-messages sent locally from the xymond_client daemon.
This behaviour is unchanged from 4.2.x to 4.3.x.
In 5.0, you can implement SSL client certificate checks for complete control of who is allowed to send status updates.
Regards, Henrik
Thanks Henrik... But, but (he sputters) that causes the server to refuse messages from the clients. Did I do it wrong?
I used --status-senders=127.0.0.1,$BBSERVERIP,xxx.xx.xxx.xxx
where the x's is another Xymon server IP that does network tests.
Thanks, Steve
On 05-12-2012 22:14, Steve Holmes wrote:
In --status-senders, you should list 1) the Xymon server itself 2) any hosts running network testsThanks Henrik... But, but (he sputters) that causes the server to refuse messages from the clients. Did I do it wrong?
I used --status-senders=127.0.0.1,$BBSERVERIP,xxx.xx.xxx.xxx
where the x's is another Xymon server IP that does network tests.
Looks right. Must admit I haven't used it much myself ...
Could you post one of the log-messages rejecting the update (from xymond.log) and the hosts.cfg line for that host?
Regards, Henrik
On Wed, Dec 5, 2012 at 4:40 PM, Henrik Størner <henrik at hswn.dk> wrote:
On 05-12-2012 22:14, Steve Holmes wrote:
In --status-senders, you should list 1) the Xymon server itself 2) any hosts running network testsThanks Henrik... But, but (he sputters) that causes the server to refuse messages from the clients. Did I do it wrong?
I used --status-senders=127.0.0.1,$**BBSERVERIP,xxx.xx.xxx.xxx
where the x's is another Xymon server IP that does network tests.
Looks right. Must admit I haven't used it much myself ...
Could you post one of the log-messages rejecting the update (from xymond.log) and the hosts.cfg line for that host?
Regards, Henrik
Ok, I think I see now what is going on. All of the hosts showing up as being refused in the log are either not configured in or are configured with a testip tag and using an ip that is different from the ip that it is reporting from.
That makes sense, but would make it hard for me to use the feature.
Thanks for the stimulating discussion!
Steve
-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958)
I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
Hi,
On Wed, Dec 05, 2012 at 09:57:10PM +0100, Henrik Størner wrote:
On 05-12-2012 21:04, Steve Holmes wrote:
I tried that and started getting a lot of refused messages referencing the monitored systems. I forgot to mention that this is release 4.2.3. If it is different in 4.3.x then I will have to wait a couple of months.
I've configured some Xymon servers using all --*-senders options. It works great.
Additionally I also specified --no-download. Otherwise clients might fetch the (bb-)hosts(.cfg) file or other configuration files which might contain sensitive data.
Steve, are you sure that the IP address in the configuration is the same as the client is using for outgoing connections. I had a problem with a system having a couple of secondary IP addresses.
In 5.0, you can implement SSL client certificate checks for complete control of who is allowed to send status updates.
Great to hear that 5.0 will support SSL authentication and encryption :-)
Best regards Thomas Kähn
Thomas Kähn Technik, Network Engineering & Design; Content Delivery Platform & IP
NETCOLOGNE Gesellschaft für Telekommunikation mbH Am Coloneum 9 | 50829 Köln Tel: 0221 2222-8718 | Fax: 0221 2222-78718
www.netcologne.de
Geschäftsführer: Dr. Hans Konle (Sprecher) Dipl.-Ing. Karl-Heinz Zankel
Vorsitzender des Aufsichtsrates: Dr. Andreas Cerbe
HRB 25580, AG Köln
Diese Nachricht (inklusive aller Anhänge) ist vertraulich. Sollten Sie diese Nachricht versehentlich erhalten haben, bitten wir, den Absender (durch Antwort-E-Mail) hiervon unverzüglich zu informieren und die Nachricht zu löschen. Die E-Mail darf in diesem Fall weder vervielfältigt noch in anderer Weise verwendet werden.
participants (11)
-
baugust@stanford.edu
-
cleaver@terabithia.org
-
henrik@hswn.dk
-
hobbit@elyograg.org
-
novosirj@umdnj.edu
-
ralphmitchell@gmail.com
-
Rolands@logicaltech.com.au
-
sean@maclawran.ca
-
sholmes42@mac.com
-
tm@freedom.com
-
xymonliste@netcologne.de