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)

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 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:baugust at stanford.edu] 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" <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

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 sean at maclawran.ca

Key West +1 305 390 0888 The best way to predict the future is to invent it. - Alan Kay

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 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)

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

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

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 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)