February 2016 - Xymon - Xymon mailman web

terabithia vs self compiled
by Galen.Johnson＠sas.com 10 Feb '16

10 Feb '16

Hey, I'm considering switching over to using the RPMs that JC provides through Terabithia rather than compiling from scratch. I'm assuming it should as simple as just copying over the RPMs and yum installing them. Any gotcha's to look out for? Just want to be sure that my tweaks to the various configs will work and the best way to handle the client tests. I use include and directory a fair bit. I've never exactly been clear on 'local' mode but the majority of my monitored systems use msgcache/pulldata so I'm not sure which client rpm makes the most sense. Also, is there a repository definition I can add that will let me just run 'yum update' and it can bring in the updated rpms? I didn't see anything obvious on the terabithia site (or I could just be blind). thx =G=

3 4

Xymon 4.3.x (including 4.3.25) on Solaris 10 SPARC w/libwrap installed
by novosirj＠rutgers.edu 10 Feb '16

10 Feb '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, I brought his problem up ages ago (http://lists.xymon.com/archive/2012-November/036102.html) Basically, this happens when you do a make: gcc -o xymond_rrd xymond_rrd.o xymond_worker.o do_rrd.o client_config.o ../lib/libxymontime.a -lrt ../lib/libxymoncomm.a - -L/usr/sfw/lib -lssl -lcrypto -lresolv -lsocket -lnsl -lrt - -L/opt/csw/lib -lrrd -L/opt/csw/lib -lpcre Undefined first referenced symbol in file deny_severity /usr/sfw/lib/libwrap.so.1 allow_severity /usr/sfw/lib/libwrap.so.1 ld: fatal: symbol referencing errors. No output written to xymond_rrd collect2: ld returned 1 exit status gmake[1]: *** [xymond_rrd] Error 1 gmake[1]: Leaving directory `/root/src/xymon-4.3.25/xymond' gmake: *** [xymond-build] Error 2 A discussion of possible solutions for building is included in the above link. Is there a better/more permanent solution that can be implemented in the source code? - -- ____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences* || \\UTGERS |---------------------*O*--------------------- ||_// Biomedical | Ryan Novosielski - Senior Technologist || \\ and Health | novosirj at rutgers.edu - 973/972.0922 (2x0922) || \\ Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark `' -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAla6SLQACgkQmb+gadEcsb4TgwCdEIkAQGBA0yXPIr+aLCZckD9T mAUAoMvFzGDhNN4nUgMGZJii82fEj0Nh =CNrj -----END PGP SIGNATURE-----

3 3

Xymon 4.3.25 - Important Security Update
by cleaver＠terabithia.org 09 Feb '16

09 Feb '16

Hello all, Xymon 4.3.25 has been released and is now available for download at https://sourceforge.net/projects/xymon/ Version 4.3.25 includes fixes for several security issues in the server component of the Xymon monitoring system, which are further detailed below. In addition, there are several other feature additions, and several bug fixes and reliability improvements. Full release notes and a Changelog are available at https://sourceforge.net/projects/xymon/files/Xymon/4.3.25/ These issues affect all versions of Xymon 4.3.x prior to 4.3.25, as well as the obsolete 4.1.x and 4.2.x versions. All Xymon users are strongly encouraged to upgrade their server component. We would like to greatly thank Markus Krell for his responsible reporting of these issues and for his assistance in testing their resolution. And as always, thank you to everyone who has contributed code or submitted feature suggestions or bug reports to the Xymon project. Regards, Japheth "J.C." Cleaver Xymon 4.x Maintainer * CVE-2016-2054: Buffer overflow in xymond handling of "config" command: The xymond daemon performs an unchecked copying of a user-supplied filename to a fixed-size buffer when handling a "config" command. This may be used to trigger a buffer overflow in xymond, possibly resulting in remote code execution and/or denial of service of the Xymon monitoring system. This code will run with the privileges of the xymon userid. This bug may be triggered by anyone with network access to the xymond service on port 1984, unless access has been restricted with the "--status-senders" option (a non-default configuration). This bug has been patched in Xymon 4.3.25. * CVE-2016-2055: Access to possibly confidential files in the Xymon configuration directory: The xymond daemon will allow anyone with network access to the xymond network port (1984) to download configuration files in the Xymon "etc" directory. In a default installation, the Apache htaccess file "xymonpasswd" controlling access to the administrator webpages is installed in this directory and is therefore available for download. The passwords in the file are hashed, but may then be brute-forced off-line. This bug may be triggered by anyone with network access to the xymond service on port 1984, unless access has been restricted with the "--status-senders" option (a non-default configuration). Administrators of existing installations should ensure that the xymonpasswd file is not readable by the userid running the xymond daemon. Permissions should be: Owner=webserver UID, group=webserver GID, mode rw-rw--- (600). This will be the default configuration starting with Xymon 4.3.25. In addition, the "config" command will only allow access to regular files. By default, only files ending in ".cfg" may be directly retrieved, although this can be overridden by the administrator, and config files may include other files and directories using existing directives. Alternatively, the file may be moved to a location outside the Xymon configuration directory. The Xymon cgioptions.cfg file must then be edited so CGI_USERADM_OPTS and CGI_CHPASSWD_OPTS include "--passwdfile=FILENAME". * CVE-2016-2056: Shell command injection in the "useradm" and "chpasswd" web applications: The useradm and chpasswd web applications may be used to administer passwords for user authentication in Xymon, acting as a web frontend to the Apache "htpasswd" application. The htpasswd command is invoked via a shell command, and it is therefore possible to inject arbitrary commands and have them executed with the privileges of the webserver (CGI) user. This bug can only be triggered by web users with access to the Xymon webpages, who are already authenticated as Xymon users. However, when combined with CVE-2016-xxxx which allows for off-line cracking of password hashes, this bug may be exploitable by others. This bug has been patched in Xymon 4.3.25. * CVE-2016-2057: Incorrect permissions on IPC queues used by the xymond daemon can bypass IP access filtering: An IPC message queue used by the xymon daemon is created with world-write permissions, allowing a local user on the Xymon master server to inject all types of messages into Xymon, bypassing any IP-based access controls. Exploitation of this bug requires local access to the Xymon master server. This bug has been patched in Xymon 4.3.25. * CVE-2016-2058: Javascript injection in "detailed status webpage" of monitoring items: A status-message sent from a Xymon client may contain any data, including HTML, which will be included on the "detailed status" page available via the Xymon status webinterface. A malicious user may send a status message containing custom Javascript code, which will then be rendered in the browser of the user viewing the status page. Exploitation of this bug requires that you can control the contents of a status message sent to Xymon, which is possible if you control one of the servers monitored by Xymon, or the Xymon master server. Also, the bug requires a user to actually view the "detailed status" webpage. This bug has been patched in Xymon 4.3.25 by including a "Content-Security-Policy" HTTP header in the response sent to the browser. This means that older browsers may still be vulnerable to this issue. * CVE-2016-2058: XSS vulnerability via malformed acknowledgment messages: (Note that this uses the same CVE id as the Javascript injection issue) The message sent by a user to indicate acknowledgment of an alert is not HTML-escaped before being displayed on the status webpage, which may be used to trigger a cross-site scripting vulnerability. Exploitation of this bug requires that the attacker is able to acknowledge an alert status. This requires user-authenticated access to the Xymon webpages, or that the user receives a message (usually via e-mail) containing the authentication token for the acknowledgment. This bug has been patched in Xymon 4.3.25.

3 4

hphwraid
by aristide＠free-it.ch 05 Feb '16

05 Feb '16

Hi, I need to check the raid volumes on a HP ProLiant ML110 server so I set up the 'hphwraid'. The 'hphwraid.sh' script was updated in 2012 and since then, the tool from HP to monitor an configure their RAID-Adapters has changed (from 'hpacucli' to 'hpssacli'), as has the name of the Xymon-project. The script should be adapted (reference to the HP-tool in the script and naming of variables in the config part). The changes I made to have the 'hphwraid'-check working are in the attached file. May be someone could update the script and the README file accordingly (I don't know how). Or is there a newer/better way to monitor RAID-volumes on HP ProLiant servers ? Regards Yann

1 0

Problem with FILE monitoring
by neilsimmonds1808＠gmail.com 04 Feb '16

04 Feb '16

Hi, I have an issue with FILE monitoring. I can't seem to get it to alert correctly if the file exists. This is the relevant line from my client-local.cfg, file:`ls -l /applogs/mdmpim/dump/*.txt 2>/dev/null` and this is the relevant line from my analysis.cfg, FILE "%/applogs/mdmpim/dump/*.txt" NOEXIST yellow I've also tried, FILE "%/applogs/mdmpim/dump/*.txt" yellow NOEXIST, FILE "%/applogs/mdmpim/dump/*.txt" yellow noexist and FILE "%/applogs/mdmpim/dump/*.txt" yellow None of them actually flag yellow! All I get is Files status at Wed Feb 3 11:57:36 GMT 2016 green -rw-rw-r-- 1 pimwas pimwas 254632 Jan 22 10:01 /applogs/mdmpim/dump/javacore.20160122.100109.30318.0006.txt So it looks like it's recognising that the file is there but the colour change isn't happening.

2 1

Question on Xymon installation on Ubuntu with apache2
by jborissr＠gmail.com 04 Feb '16

04 Feb '16

I am new to Xymon but have used Big Brother. My big issue is the web setup. I am doing this on a Ubuntu server with apache2. Apache2 has a new type of configuration file and it is very confusing where to put the xymon-apache.conf file info. I tried adding it to the default configuration file in the /etc/apach2/sites-available directory but it doesn't like the RewriteEngine lines which I am assuming I have this in the wrong place. Is there a document that shows the steps to getting Xymon to work on a Ubuntu server running apache2? Also is there a search utility for this mailing list? TIA -- John J. Boris, Sr.

3 3

Xymon 4.3.25-RC2 available
by cleaver＠terabithia.org 04 Feb '16

04 Feb '16

Hello all, Xymon 4.3.25-RC2 has been posted to SourceForge and should be available now at a mirror near you: Download link and release notes: https://sourceforge.net/projects/xymon/files/Xymon/4.3.25/ Current changelog: https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.3.25/Changes Note: RC1 was not publicly announced. The majority of the visible changes in RC2 are on the client side, including additional variables in xymonclient.cfg to make things more convenient for users running in "local config mode", and globbing functionality in logfetch for gathering a dynamic set of files without the need to run any additional commands. There are also server server-side and CGI bug fixes, including a fix for where xymond_alert may fail to alert after attempting to page about a host that had been added into hosts.cfg after its initial startup. There are several additional issues in the final stages of testing which will likely be included in 4.3.25 final. Please test things out, replying back to the list if you notice any issues, or any additional (or new, hopefully not! ) bugs. If all goes well, 4.3.25 will be getting released early next week. Regards, -jc

2 1

HTTP test accessible local only
by lk＠man-da.de 03 Feb '16

03 Feb '16

Am Freitag, 29. Januar 2016, 13:34:47 schrieb Novosielski, Ryan: > Hi there, > > Figured I could use a little bit of collective wisdom here: > > I have an HTTP service that is only accessible from the local machine > (either connected to by a local app or a web browser that is launched from > the server). I’d like to test that it is available. I don’t need any more > specialized functionality than I would have from the HTTP test (maybe I’d > set up an HTTP POST to actually log in). > > Is there a way to somehow cause the client to do this, without writing an > external script, or some other way to do what I’m talking about that I > might not have considered? > > Thanks! > Hi, another way would be to use the real Xymonnet HTTP Check like you would use it on a monitoring satelite (Xymonnet Server). This might be a bit overkill, but I would expect it to give back better results than a self writen script. At least selfwriten within the time you need to configure. The monitoring of the port state as mentioned by J.C. might be easier and more straight forward way. And I would prefer it, if it fit's the needs. The xymonnet is part of the server package. On the "client" running the server package you'll need to deactivate all sections but | # "xymonnet" runs the xymonnet tool to perform the network based tests | # - i.e. http, smtp, ssh, dns and | # all of the various network protocols we need to test. | [xymonnet] | ENVFILE /usr/lib/xymon/server/etc/xymonserver.cfg | # NEEDS xymond | # CMD xymonnet --report --ping --checkresponse | CMD xymonnet --noping --checkresponse=red | LOGFILE $XYMONSERVERLOGS/xymonnet.log | INTERVAL 5m And remove/comment out the NEEDS line, since this works only if Xymonnet and Xymondisplay are on the same host. See man xymonnet(1) for usefull options. I think --noping would be what you'll want. The --checkresponse has only an effect if you are checking also Ports configured in protocols.cfg. The --report is for the xymonnet-Column, this selfmonitoring might work, since it will report it xymonnet-Column for the "client", but choose yourself if you need this. I'm running this with =red since it was a common wish from our server admins to alert if the Ports don't return the expected helo. You'll also need to disable | #directory /usr/lib/xymon/server/etc/tasks.d | #include /var/run/xymon/xymonlaunch-include.cfg too, since some additional stuff might come in this way. After this is done you can set XYMONSERVERIP in the xymonservers.cfg on the client to the IP of the real server. Now you'll be able to configure your HTTP check in the hosts.cfg on the "client" as you are used to do on the "server". But be aware you should *only* configure the "client" *itself* in *it's* hosts.cfg. For real Xymonnet Servers there is a "NET:<XymonNetIdentifier>" tag available, but this would be real overkill in this case. Might be I've forgotten something. But this should be it. ;-) Kind regards, Lars -- man-da.de GmbH, AS8365 Phone: +49 6151 16-71027 Mornewegstraße 30 Fax: +49 6151 16-71198 D-64293 Darmstadt e-mail: lk at man-da.de Geschäftsführer Marcus Stögbauer AG Darmstadt, HRB 94 84

1 0

Bug in holidays calculation
by tschmidt＠micron.com 03 Feb '16

03 Feb '16

I have noticed a bug in the holidays feature of Xymon. I am using Xymon 4.3.24 and have seen it on previous releases as well. The issue is that the US Holiday of Thanksgiving is not showing the correct date during leap years. Thanksgiving is the fourth Thursday in November, so is using this entry in holidays.cfg: Thanksgiving:type=thu month=11 offset=4 This works correctly during non-leap years, but it is a day off during leap years like 2016. I added these simple entries to holidays.cfg to better show the issue: November Week 1 Thu:type=thu month=11 offset=1 November Week 2 Thu:type=thu month=11 offset=2 November Week 3 Thu:type=thu month=11 offset=3 When I look at the holidays that it calculates, I get this in the info column: Holidays 2015/2016 (USA) November Week 1 Thu Nov 05 November Week 2 Thu Nov 12 November Week 3 Thu Nov 19 Thanksgiving Nov 26 Christmas Day Dec 25 New Year's Day Jan 01 Easter Sunday Mar 27 Memorial Day May 30 Independence Day Jul 04 Labor Day Sep 05 November Week 1 Thu Nov 03 November Week 2 Thu Nov 09 November Week 3 Thu Nov 16 Thanksgiving Nov 23 Note that the November 2015 dates are correct, but the November 2016 dates for Week 2 and later are a day early. Thus it thinks Thanksgiving 2016 is on November 23 instead of the correct November 24 date. I looked at the source code some, but I could not follow the logic of how it is calculating this date incorrectly. It is a minor bug only affecting those that use the holidays feature for alerts or look at the holidays table in the info tab. Can someone figure out why it is not calculating the date offsets correctly? It only seems to be doing this during leap years. Thanks...Tom -- Micron Technology, Inc., Confidential and Proprietary Tom L. Schmidt Central Engineering System Administrator Lead Micron Technology, Inc. http://www.micron.com/ 8000 S. Federal Way P.O. Box 6 Mail Stop 01-351 Boise, Idaho USA 83707-0006 mailto:tschmidt at micron.com

3 2

RSS option with critical view
by cleaver＠terabithia.org 03 Feb '16

03 Feb '16

On Fri, January 29, 2016 1:38 pm, FARRIOR, Andy wrote: > > Thought I'd experiment with the XYMONGENOPTS "-rss" option today. > > It's creating the RSS files for each page and the main, nongreen, and red > status pages just fine; however, the critical.rss file doesn't match the > critical view display. > > > The critical.rss file does match the critical.html file that's created. > > So, in my case, critical.rss and critical.html both display "No Critical > Alerts" > > However, my /xymon-cgi/criticalview.sh lists the systems with issues. > > What did I miss in the configuration? > > > Thx, > Andy Hi Andy, The criticalview.sh script was intended as a replacement for xymongen hard-coded "critical" version, if I recall correctly. They're two different functions, so rss will match the static .html file, alas. I believe the "critical" from xymongen's perspective refers to alerting only, with criticalview.sh as its own thing. An .rss response to the criticalview.sh or a merging of the logic together would probably be a good idea for the future, though. HTH, -jc

1 0