Xymon security concern raised
list Steve Holmes
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
list Tim McCloskey
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 [user-ec1bf77b1b44@xymon.invalid]
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
list Japheth Cleaver
▸
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
list Steve Holmes
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, <user-87556346d4af@xymon.invalid> 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 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
--
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)
list Steve Holmes
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 <user-440820cc07d6@xymon.invalid> 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 [user-ec1bf77b1b44@xymon.invalid] 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)
list Ryan Novosielski
-----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 <user-440820cc07d6@xymon.invalid <mailto:user-440820cc07d6@xymon.invalid>> 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 [user-ec1bf77b1b44@xymon.invalid
<mailto:user-ec1bf77b1b44@xymon.invalid>] 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 |$&| |__| | | |__/ | \| _| |user-ae4522577e16@xymon.invalid - 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-----
list Roland Soderstrom
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 <user-440820cc07d6@xymon.invalid <mailto:user-440820cc07d6@xymon.invalid>> 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 [user-ec1bf77b1b44@xymon.invalid <mailto:user-ec1bf77b1b44@xymon.invalid>] 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 |$&| |__| | | |__/ | \| _| |user-ae4522577e16@xymon.invalid - 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-----
list Henrik Størner
▸
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 1) the Xymon server itself 2) 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
list Steve Holmes
▸
On Wed, Dec 5, 2012 at 3:57 PM, Henrik Størner <user-ce4a2c883f75@xymon.invalid> 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 1) the Xymon server itself 2) 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
list Henrik Størner
▸
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 tests
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.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
list Benjamin P. August
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" <user-0cec9512a49f@xymon.invalid>
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 <user-440820cc07d6@xymon.invalid <mailto:user-440820cc07d6@xymon.invalid>> 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 [user-ec1bf77b1b44@xymon.invalid <mailto:user-ec1bf77b1b44@xymon.invalid>] 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 |$&| |__| | | |__/ | \| _| |user-ae4522577e16@xymon.invalid - 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-----
list Roland Soderstrom
I have the cluster logicalhost names in hosts.cfg, don't care about the rest of the tests. I also have the real zones running the xymonclient in that zone with all its built in monitoring. Monitoring all cluster resources from the globalzone makes the script so much easier. group-only ftp-rs|app-rs|ora-server-rs|ora-lsnr-rs CLUSTER-Resources 10.0.1.40 ftp01-lh # noconn 10.0.1.30 app01-lh # noconn 10.0.1.20 ora01-lh # noconn - Roland
▸
-----Original Message-----
From: Benjamin P. August [mailto:user-e992dd5eb2a5@xymon.invalid] Sent: Thursday, 6 December 2012 11:49 AM
To: Roland Soderstrom
Cc: xymon at xymon.com
Subject: Re: [Xymon] Xymon security concern raised
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" <user-0cec9512a49f@xymon.invalid>
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 <user-440820cc07d6@xymon.invalid <mailto:user-440820cc07d6@xymon.invalid>> 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 [user-ec1bf77b1b44@xymon.invalid <mailto:user-ec1bf77b1b44@xymon.invalid>] 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 |$&| |__| | | |__/ | \| _| |user-ae4522577e16@xymon.invalid - 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-----
list Thomas Kähn
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: XXXX XXXX-XXXX | Fax: XXXX XXXX-XXXXX 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.
list Stef Coene
Hi,
I do the same for PowerHA (Clustering on AIX).
I have a aix-hobbitclient-hacmp.pl script that sends out a 'normal' client
message for each clustered resource. So I can monitor files, processes, ...
per clustered resource.
This script runs on each node. If a resource group is online, it will send
out the message for that resource group.
In bb-hosts I have something like:
page cluster1 Cluster 1
title Cluster 1
group-compress AIX
10.0.0.1 node 1 # ssh
10.0.0.2 node 2 # ssh
10.0.0.3 node 3 # ssh
group-compress Resource Group
10.0.0.10 resource 1 #
10.0.0.11 resource 2 #
Stef
list Steve Holmes
▸
On Wed, Dec 5, 2012 at 4:40 PM, Henrik Størner <user-ce4a2c883f75@xymon.invalid> 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 tests 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.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)
list Shawn Heisey
▸
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
list Ralph Mitchell
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 <user-5d0d01dba542@xymon.invalid> 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 at xymon.com<
list Sean MacGuire
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:
1. 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.
2. 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 user-4915795a2617@xymon.invalid
Key West +X XXX XXX XXXX
The best way to predict the future is to invent it. - Alan Kay