XyMon client binaries default security is bad 🔗 link

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

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

The 300 seconds is the frequency that xymonnet executes. You set it in
tasks.cfg.

Thanks,
Larry Barber

On Thu, Feb 28, 2013 at 7:44 PM, Maik Heinelt <user-4ab5eb34adb2@xymon.invalid> wrote:

Xymon at xymon.com<

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

On 1 March 2013 08:59, Andrey Chervonets <user-e7fb5c02322c@xymon.invalid> 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

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 <user-71895fb2e44c@xymon.invalid>wrote:

It does partially depend on umask, however it's also a larger issue of how
the client package is deployed in the first place.

If a binary shouldn't be run, and it exists in someone's (or something's)
home directory, directory privs should be modified as well. The annoyance
of users not being able to query (without switching users) might be a
non-issue, depending on your local policies.

For RPM-based installs, it's a little bit different.


Keep in mind that bogus reports can be sent from a specific host about
itself by a local user anyway, though. See
http://www.xymon.com/xymon/help/xymon-tips.html#noinstall, which
definitely puts us into the "bug or feature?" realm.

--status-senders doesn't help here either:

"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-addresses 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."


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

Perhaps Henrik can chime in?


Without SSL, setting more restrictive perms seems more helpful in keeping
people from messing around with your install than anything else.


Regards,
-jc

On Fri, Mar 1, 2013 at 3:40 PM, <user-87556346d4af@xymon.invalid> wrote:

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

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

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

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.

- -- 
- ---- _  _ _  _ ___  _  _  _
|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/

iEYEARECAAYFAlExI20ACgkQmb+gadEcsb4BgwCgyifmXeCCHou/X5qVYRp05hMN
2yUAmgKjxYEhHfSH8f2P6jZ48ZwhROk1
=YI8p
-----END PGP SIGNATURE-----

On Fri, Mar 1, 2013 at 4:53 PM, Novosielski, Ryan <user-ae4522577e16@xymon.invalid>wrote:

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

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

All other cases when someone will try to send report "on behalf of" real client - are more complicated and require some networking skills and special reasons.

My concern regarding  read and execute permission to everyone on client host - was just prevent other then xymon users  to try and play with xymon tools.
If anyone see it can execute anything - it can try to do something just for interest, for example to send "drop .."  request",
just to test System security and sysadmin ability to track exceptions.

I think this can be easy fixed, for example with 1 find execution after installation done:
find client/ -exec chmod o-rwx {} \;
or just:
find client/bin -exec chmod o-rwx {} \;    # if someone see others should see some output generated.


Best regards,

Andrey Chervonets
CoMinder SIA.
http://www.cominder.eu/
Mobile: +XXX XXXXXXXX
Fax: +XXX XXXXXXXX

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

Maik

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

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 <user-4ab5eb34adb2@xymon.invalid> wrote:

Xymon at xymon.com<

On Sat, 02 Mar 2013 10:51:06 +0200, Andrey Chervonets

<user-e7fb5c02322c@xymon.invalid> wrote:

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

On 2 March 2013 06:44, Larry Barber <user-6ef9c2864140@xymon.invalid> wrote:

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.

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 Thu, Mar 7, 2013 at 12:49 AM, Jeremy Laidman

<user-71895fb2e44c@xymon.invalid> wrote:

it's a common notion, although I don't think it really helps in true
security very often.   I've usually seen it in places where a
draconian security policy is compiled by people who don't really
understand what they're doing from a wide range of internet sources
that are then too widely applied.     e.g. one place I worked for
established a security policy that insisted that root's home dir be
mode 700, owned by root.   which is a pretty decent suggestion for
linux machines where root's home is (typically) /root.   on a solaris
machine where root's home dir is typically (or at least was then) /,
it'll render a machine unusable.   but since it'd been found at what
some security auditor considered to be a reputable site and s/he
didn't understand the underlying reasoning, it became the standard
policy to be applied across all OSes and all machines (and yes if you
added the extra clause that root's home dir can not be /, it goes back
to possibly a reasonable security policy).

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.

-- 
Even the Magic 8 ball has an opinion on email clients: Outlook not so good.

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

On 7 March 2013 17:37, zGreenfelder <user-7203df77e300@xymon.invalid> 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.

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

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

<user-5e10259081b2@xymon.invalid>wrote:

Xymon at xymon.com<

Brilliant!
Thanks very much for that.

On 08/03/2013 02:21, Jeremy Laidman wrote: