Xymon Log Retrieval 🔗 link

Is there a doco anywhere explaining the log file retrieval mechanism?

I want to use Xymon to fetch /etc/passwd files so that I can check for unwanted/unnoticed changes.

Nick
Dublin

Why not just use the Xymon client's built-in ability to test for file age and trigger an alert if it changes?

=G=

From: xymon-bounces at xymon.com [xymon-bounces at xymon.com] on behalf of Nick [user-2027539dd102@xymon.invalid]
Sent: Friday, April 19, 2013 8:00 AM
To: xymon at xymon.com
Subject: [Xymon] Xymon Log Retrieval

Is there a doco anywhere explaining the log file retrieval mechanism?

I want to use Xymon to fetch /etc/passwd files so that I can check for unwanted/unnoticed changes.

Nick
Dublin

Yes, that's what I've done but management want a copy of them for some
reason or other...

Regards,

Nick Pettefar

On 19 April 2013 14:18, Galen Johnson <user-87f955643e3d@xymon.invalid> wrote:

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

Wouldn't the history logs serve?

On 04/19/2013 09:54 AM, Nick Pettefar wrote:

Nick Dublin _______________________________________________ Xymon
mailing list Xymon at xymon.com

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

iEYEARECAAYFAlFxrb8ACgkQmb+gadEcsb6X6wCeM7duQP6JB8b+nCJkIG1o0ht2
hlQAoN1rARNOvKttmj/AezG1jLM7dobZ
=afbi
-----END PGP SIGNATURE-----

On 19 April 2013 22:00, Nick <user-2027539dd102@xymon.invalid> wrote:

Is there a doco anywhere explaining the log file retrieval mechanism?

Log file retrieval configuration is documented in client-config.cfg.
 Analysis and reporting of log files is documented in analysis.cfg.

The log file contents are processed by the logfetch binary, and the man
page for that gives some information on how it does its thing.

The problem with using the log retrieval mechanism is that it assumes that
the file is a logfile, and only reports on new entries past the last time
it checked.  If an entry is changed, but the file doesn't change size, it
won't report any change to the file.  If an entry is added in the middle,
rather than at the end, then logfetch will report the lines at the end and
so you'll see the wrong values.

You can trick logfetch into thinking that a file is a logfile that has been
rotated by reducing its size, and it starts from the beginning of the file.
 The next run, you append to the file, so that it reports only the new
stuff.  Then you get it to cycle between the two states (new entries,
rotated, new entries, rotated, etc).  But you wouldn't want to do that on
the actual passwd file!

What you could do is to create a virtual file using backticks and
manipulate its contents as you need, and to satisfy logfetch.  It's a bit
hackety but it only requires changes in a couple of config files on the
Xymon server.  For example, something like this in client-local.cfg:

log:`if [ -f /tmp/pw.rep ]; then if grep '^[0-9]' /tmp/pw.rep | tail -n +3
| grep ^ >/dev/null; then cp /dev/null /tmp/pw.rep; fi; diff /tmp/pw.old
/etc/passwd >> /tmp/pw.rep; else touch /tmp/pw.rep; fi; cp /etc/passwd
/tmp/pw.old; echo /tmp/pw.rep`:2048

All this does is to create a copy of the password file pw.old, and any
differences in the last time it was run are appended to a report file
pw.rep, which is what's actually monitored.  If the report file has 3 or
more diffs appended, it gets emptied before the next report is added, to
keep the file from growing too large.

My analysis.cfg file can contain something like this:

HOST=name.of.host
    LOG /tmp/pw.rep "%^>" COLOR="red" "TEXT=Account added to /etc/passwd"
    LOG /tmp/pw.rep "%^<" COLOR="yellow" "TEXT=Account removed from
/etc/passwd"

Note: untested.

J

If you want to monitor changes to the passwd/shadow file, one way would be to write an ext script. One can get around the OS recording changes to users by just editing the files directly, so this would be a bit more foolproof. 
You'd need be to keep a copy of the passwd file somewhere else (say the xymon server itself) and then do a diff against it.   Something like:
 
if scp $server:/etc/passwd $BBHOME/secret/$server.passwd.new
then
	    if diff $BBHOME/secret/$server.passwd.new $BBHOME/secret/$server.passwd.reference
	    then
				 COLOR=green
	    else
				 COLOR=red
	    fi
else
	    COLOR=red
fi
 
cheers, Phil

 

Yes, that's what I've done but management want a copy of them for some
reason or other...

Regards,

Nick Pettefar


On 19 April 2013 14:18, Galen Johnson <user-87f955643e3d@xymon.invalid> wrote:

On 22 April 2013 14:54, Jeremy Laidman <user-71895fb2e44c@xymon.invalid> wrote:

and

Note: untested.

This is now tested, and IMHO it works well.  The only problem is that the
"TEXT=" modifier in analysis.cfg doesn't seem to work at all, and I just
get the text "Warnings in /tmp/pw.rep" instead.  But it shows the accounts
added or removed, which is the important thing.

J

You might want to talk to your security people before copying the passed
file to another system, and you *definitely* should not copy the shadow
file. There are good reasons that file is readable only by root.

Ralph Mitchell

 If you want to monitor changes to the passwd/shadow file, one way would
be to write an ext script. One can get around the OS recording changes to
users by just editing the files directly, so this would be a bit more
foolproof.
You'd need be to keep a copy of the passwd file somewhere else (say the
xymon server itself) and then do a diff against it.   Something like:

if scp $server:/etc/passwd $BBHOME/secret/$server.passwd.new
then
        if
diff $BBHOME/secret/$server.passwd.new $BBHOME/secret/$server.passwd.reference
        then
                 COLOR=green
        else
                 COLOR=red
        fi
else
        COLOR=red
fi

cheers, Phil


  Yes, that's what I've done but management want a copy of them for some
reason or other...

Regards,

Nick Pettefar


On 19 April 2013 14:18, Galen Johnson <user-87f955643e3d@xymon.invalid> wrote:

[user-2027539dd102@xymon.invalid]

On 22/04/13 20:53, Ralph Mitchell wrote:

I've been watching this thread, but maybe I missed it...

Doesn't xymon allow to calculate the MD5 of a file and alert if it is
modified..... I'm pretty sure this is a standard feature. Here it is:
#             - "MD5=md5sum", "SHA1=sha1sum", "RMD160=rmd160sum" trigger
a warning
#               if the file checksum using the MD5, SHA1 or RMD160
message digest
#               algorithms do not match the one configured here. Note:
The "file"
#               entry in the client-local.cfg file must specify which
algorithm to use.

Surely this would generate an appropriate alert if the file is
modified... and continue to alert until the xymon config was updated
with the new checksum.

Regards,
Adam

-- 
Adam Goryachev
Website Managers
www.websitemanagers.com.au

Hi guys

There are a number of issue with what you propose.
Firstly, /etc/shadow is readable by root only. Unless you are running
Xymonas root, (which is very bad) or doing some interesting things
with
sudo or wrapper scripts, there is no way Xymon can checksum /etc/shadow.

But lets assume you have overcome the read issue in some way, and are now
doing a check-sum of /etc/shadow.....
Besides picking up new users, it will also alert whenever somebody changes
their password or whenever an account is locked and/or reactivated

I company I worked for (very briefly) used tripwire to monitor /etc/shadow,
"for security" and we had to log in and reset the tripwire every time some
sod changed their password.
Complete waste of time.

If you want to keep tabs on your list of users, you are better off just
checking /etc/passwd, and leave /etc/shadow alone. It's probably the most
protected file in the Unix file system, and probably the least likely to me
modified by a hacker, unless they have access to a userID.

Consider the paradox of /etc/passwd and /etc/shadow.
The most protected file is /etc/shadow, but any user can modify it.
The /etc/passwd file is a very "open" file, readable by all, but writable
by only a very select few.

Trust me, if you have more than a handful of users, doing a checksum on
/etc/shadow will only bring you pain and suffering.

If you don't want to use checksums, have a known list of users and/or
userIDs, then you can always write a quick script to check your list
against the usernames  ( cut -d: -f1 /etc/passwd) or the userIDs ( cut -d:
-f3 /etc/passwd) or both (cut -d: -f1,3 /etc/passwd)
I would suggest you sort both lists first though.

Cheers
Vernon


On 22 April 2013 19:45, Adam Goryachev

<user-92fd6827f6ae@xymon.invalid>wrote:

Website Managerswww.websitemanagers.com.au

-- 
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton

On 22/04/13 23:20, Vernon Everett wrote:

Xymon as root, (which is very bad) or doing some interesting things with
sudo or wrapper scripts, there is no way Xymon can checksum /etc/shadow.

Actually, I thought the original request was only in relation to
/etc/passwd... Though you are right about /etc/shadow needing special
permissions for read access...

I suppose it depends on the size of the company, and the type of system
you are using. For me, every server I manage, I'm the *only* admin,
therefore I know everything that *should* be happening (well, I should
know)... In addition, I'm the only one that actually changes passwords,
creates users, etc, since all the actual users only have access via FTP,
or POP3, or SMB, etc... ie, they don't get shell access, don't get any
method to change their own password (actually, I lie, the POP users can
use a web interface to change their POP password, but they aren't users
in /etc/passwd anyway).

So, in my case, it could be helpful to be made aware of any changes to
the /etc/passwd file (and even /etc/shadow assuming I could find a way
to resolve the read access for xymon without compromising security)

It is, until one of those times it was someone who had compromised the
system. However, the question is would you even know the difference
between an illegal user modifying a user password (or an admin password)
or even adding a new account? Especially if this is a common occurrence,
then you are unlikely to even check properly, assuming it is just
"normal" for the alarm to go off, and react by logging in, update the
tripwire DB and carry on...

I agree.... also /etc/passwd is the "low fruit". It adds some tangible
security (possibly, see above), and it is easy to do.

Not really, see chfn or even chsh, both allow a normal user write access
to /etc/passwd.

I'd limit that to shell users perhaps... really it will depend on your
environment.

Another good option.... Like I said, the built-in checksum against
/etc/passwd is really easy to implement without any real issues.

Regards,
Adam

-- 
Adam Goryachev
Website Managers
www.websitemanagers.com.au

On 22 April 2013 17:15, Jeremy Laidman <user-71895fb2e44c@xymon.invalid> wrote:

Updated to work with non-GNU tail (eg on Solaris):

log:`if [ -f /tmp/pw.rep ]; then if grep '^[0-9]' /tmp/pw.rep | tail +3 |
grep ^ >/dev/null; then cp /dev/null /tmp/pw.rep; fi; diff /tmp/pw.old
/etc/passwd >> /tmp/pw.rep; else touch /tmp/pw.rep; fi; cp /etc/passwd
/tmp/pw.old; echo /tmp/pw.rep`:2048

J