The last days, our Hobbit 4.2.3 shows up the following alarm:

WARNING: Runtime 471 longer than time limit (300)

Any idea, where I can set, or reset this limit? I have restarted the server a couple times, but no change.

Thanks

Maik

It means your xymon server is taking more than 5 minutes to complete the cycle of network tests. Unless you just added a ton of new clients, it is probably timing out trying to test something, or there's a DNS issue in your network. The xymonnet column for your xymon server shows how long each test takes. That might narrow it down.

Ralph Mitchell

On Sun, Mar 3, 2013 at 6:11 PM, Maik Heinelt <maik at vegasystems.com> wrote:

Am I the only one with this error message? Any help would be appreciated.

Maik

On 2013/03/01 15:31, Maik Heinelt wrote:

...

The last days, our Hobbit 4.2.3 shows up the following alarm:

WARNING: Runtime 471 longer than time limit (300)

Any idea, where I can set, or reset this limit? I have restarted the server a couple times, but no change.

Thanks

Maik ______________________________**_________________ Xymon mailing list Xymon at xymon.com http://lists.xymon.com/**mailman/listinfo/xymon<http://lists.xymon.com/mailman/listinfo/xymon>

______________________________**_________________ Xymon mailing list Xymon at xymon.com http://lists.xymon.com/**mailman/listinfo/xymon<http://lists.xymon.com/mailman/listinfo/xymon>

It could allow bogus reports to be sent to the Xymon server, maybe hiding something malicious.

Also, a lot of security scans will pick up on things that are world executable and not in one of the standard directories (like /usr/bin, /bin, etc.).

Thanks, Larry Barber

On Thu, Feb 28, 2013 at 9:37 PM, Jeremy Laidman <jlaidman at rebel-it.com.au>wrote:

What's wrong with non-xymon users executing these commands? What harm could it do?

On 1 March 2013 08:59, Andrey Chervonets <a.chervonets at cominder.eu> wrote:

...

upgraded XyMon (clinet) to 4.3.10 (the same was at least in 4.3.5) and notices all files in bin can read and execute privileges to everyone:

ls -l client/bin/ total 1840 -rwxr-xr-x 1 xymon monitor 161079 Feb 28 21:08 clientupdate -rwxr-xr-x 1 xymon monitor 200250 Feb 28 21:08 logfetch -rwxr-xr-x 1 xymon monitor 151256 Feb 28 21:08 msgcache -rwxr-xr-x 1 xymon monitor 153905 Feb 28 21:08 orcaxymon -rwxr-xr-x 1 xymon monitor 156173 Feb 28 21:08 xymon -rwxr-xr-x 1 xymon monitor 133445 Feb 28 21:08 xymoncfg ....

I suppose it depends on umask setting during installation, but I would be more happy if installation process setup more secured configuration regardless of default settings. At least: -rwxr-x---

---

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 Fri, Mar 1, 2013 at 3:40 PM, <cleaver at terabithia.org> wrote:

[snip]

Perhaps user/pass authentication could be added, but "real" security at the report-submission level would be SSL-handshaking at the port with any local keys controlled by standard unix/host access controls, (or HTTPS and xymonmsgcgi.msg and appropriate user/pass auth info after the SSL tunnel is set up). The bits and pieces are in trunk, but I'm not sure what their current working state is...

I'm currently using xymoncgimsg.cgi to catch status messages sent over HTTPS via curl. For what I'm doing, the client-side xymon binary can be replaced by a script.

I'm not using client-side certificates, though that ought to be fairly easy to add. The problem with any client-side userid/password/certificate is that you have to have a plain text password or key somewhere, so the whole security chain could unravel if not done right.

Ralph Mitchell

On Fri, Mar 1, 2013 at 4:53 PM, Novosielski, Ryan <novosirj at umdnj.edu>wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 03/01/2013 04:45 PM, Ralph Mitchell wrote:

...

On Fri, Mar 1, 2013 at 3:40 PM, <cleaver at terabithia.org <mailto:cleaver at terabithia.org>> wrote:

[snip]

Perhaps user/pass authentication could be added, but "real" security at the report-submission level would be SSL-handshaking at the port with any local keys controlled by standard unix/host access controls, (or HTTPS and xymonmsgcgi.msg and appropriate user/pass auth info after the SSL tunnel is set up). The bits and pieces are in trunk, but I'm not sure what their current working state is...

I'm currently using xymoncgimsg.cgi to catch status messages sent over HTTPS via curl. For what I'm doing, the client-side xymon binary can be replaced by a script.

I'm not using client-side certificates, though that ought to be fairly easy to add. The problem with any client-side userid/password/certificate is that you have to have a plain text password or key somewhere, so the whole security chain could unravel if not done right.

Another piece of software I use, Bacula, can use SSL and does validation against the CN field. I would think that would be a reasonable solution. It also needs to pass a signature test. I would think it would be pretty hard to fake a CN and then get it signed by your in-house certificate authority, let alone VeriSign.

I'm working on setting up something similar to that - wifi network with client certificates.

For the SSL handshake to work with certificates at both ends, they each need to have a private key that matches their certificate. What I was saying is that the client-side key has to be protected from any users on the system. You can encrypt it, but then you'd need someone to type the decrypting passphrase whenever the client starts up. Or you can put the passphrase for the key in a file, but then it has to be clear text so you might as well not bother. Or you can store the key in a hardware token or smart card, which makes it extremely hard to copy.

And all of that's overkill for most of us - I'm just pointing out that it's not just a certificate, there's a private key as well. Both need protecting, because if I get your key, I *am* you...

Ralph Mitchell

On Sat, 02 Mar 2013 10:51:06 +0200, Andrey Chervonets <a.chervonets at cominder.eu> wrote:

Thanks everyone participated for interesting discussion!

Yes, securing client-server communication may be a problem. I see just 2 quite simple things, that will eliminate most of issues a) limit list of acceptable connections by IP at OS level (or may be XyMon may do this too?!) b) use ssh tunnels between client and Server - it was already described in XyMon manuals or Wiki

What all of this really boils down to is that Xymon is not designed for use in a "hostile" network. There are very few security features built into Xymon, e.g. access to the webpages is really wide-open. The only access controls are whatever you build on top of Xymon, e.g. with the Apache webserver security features.

xymond has some options to do some basic IP-level checking of who is allowed to send various commands. With this, you can restrict administrative commands (drop, disable etc.) to come from certain hosts - the Xymon webserver, probably. Same with status-updates, which are then only allowed from the monitored server itself and from network-test servers.

But IP-layer checks are fast becoming irrelevant due to proxies, NAT and IPv6.

The only way I can see to implement security in the communications to xymond, is to use SSL and then two-way certification of the connection. So SSL client- and server-certificate validation. I'm implementing this (have done so, actually) in the same style as OpenVPN - client certificates must be issued by a specifig trusted certificate authority (and not be revoked). So you setup your own CA to issue a certificate for each client installation, and then the Xymon server just checks who issued the certificate.

xymond should then use the identity given in the certificate as the name of the server sending status-updates (instead of trusting the client to use the correct hostname), but that hasn't been implemented yet.

File-level read/execute permission on the binaries is meaningless. Anyone with half a bit of Perl-knowledge can cook up a script that sends commands to xymond (you'll find it if you search the archives).

Regards, Henrik

You can define RRDGRAPHOPTS to have, for example, "--height 60 --width 180". You'd normally do this in xymonserver.cfg, but it applies to all graphs. If you wanted it to only apply to Metrics Report graphs, you could either adjust showgraph.sh or (preferably) cgioptions.cfg by adding the following:

echo "$HTTP_REFERER" | grep "/hostgraphs.sh\?" >/dev/null && RRDGRAPHOPTS="--height 60 --width 180" export RRDGRAPHOPTS

J

On 7 March 2013 21:39, Gonzalo Fernandez Ordas <g.fer.ordas at unicyber.co.uk>wrote:

Hi

I have been looking into the possibility of resizing the graphs generated by the "Metrics Report" but I cannot see a way of doing it?

The generated graphs got a fix size and the scripts do not seem to show a way of customizing that

Any idea?

Many thanks

______________________________**_________________ Xymon mailing list Xymon at xymon.com http://lists.xymon.com/**mailman/listinfo/xymon<http://lists.xymon.com/mailman/listinfo/xymon>

On 2 March 2013 06:44, Larry Barber <lebarber at gmail.com> wrote:

It could allow bogus reports to be sent to the Xymon server, maybe hiding something malicious.

I can do that using telnet, or in the absence of telnet, I can use bash. The binaries make it slightly more convenient, that's all.

Also, a lot of security scans will pick up on things that are world executable and not in one of the standard directories (like /usr/bin, /bin, etc.).

Really! Why? I've never seen this, except when the script is also world-writeable. What security scanner(s) are you referring to?

Lots of users write their own scripts and keep them in their home directories. Sysadmins write scripts like this all the time. I'm not sure this is a useful security stance.

J

On 7 March 2013 17:37, zGreenfelder <zgreenfelder at gmail.com> wrote:

it's a common notion,

Really? I've been in Win/UNIX/Internet security for 20 years, used various scanners, applied many security policies, worked with lots of security experts, been on several security courses, yada yada. I don't recall ever having seen this (a non-suid, world-executable binary) being checked by a scanner, or forbidden by policy. I'm only a single data point, but I'd be really surprised if this was "common" in the general UNIX security community. Perhaps I've been isolated from sites governed by dumb-ass managers. If that's the case, I don't like solutions purely to satisfy dumb-ass managers.

you can also argue that it's part of a 'least possible permissions' sort of thing where only the users/groups that _Need_ to run the programs/scripts have perms to do it, reducing the potential exposure if a security flaw is uncovered at some point in the future.

In most realistic scenarios, restricting access to a binary doesn't prevent its execution. Someone simply copies it from elsewhere. If you can get a login shell on a box, you can generally create any binary you want, and use chmod to make it executable. In this specific case, I don't even need the Xymon binaries to be installed to send bogus reports to the server, if I have a login on the client. So what's the point?

The 'least possible permissions' policy is to be applauded in general, but if it generates policy or procedures that don't actually restrict the bad actors while making things difficult for the good actors, then it's being implemented without using a threat model. Being able to manually run xymoncfg, for example, to diagnose a problem or misconfiguration is helpful to a sysadmin. Preventing this makes things harder for a sysadmin, but doesn't actually stop him, or the bad guys.

I really can't see any practical benefit in altering the permissions of these files, yet I can see it being a hindrance in some situations.

J