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 [Nick at Pettefar.com] 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
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
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 <Galen.Johnson at sas.com> wrote:
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 [Nick at Pettefar.com] 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
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Wouldn't the history logs serve?
On 04/19/2013 09:54 AM, Nick Pettefar wrote:
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 <Galen.Johnson at sas.com> wrote:
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 [Nick at Pettefar.com] 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 _______________________________________________ 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
- ---- _ _ _ _ ___ _ _ _ |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/
iEYEARECAAYFAlFxrb8ACgkQmb+gadEcsb6X6wCeM7duQP6JB8b+nCJkIG1o0ht2 hlQAoN1rARNOvKttmj/AezG1jLM7dobZ =afbi -----END PGP SIGNATURE-----
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 <Galen.Johnson at sas.com> wrote:
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 [Nick at Pettefar.com] 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
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
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 <Galen.Johnson at sas.com> wrote:
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 [Nick at Pettefar.com] 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
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
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On 22/04/13 20:53, Ralph Mitchell wrote:
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:
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 <mailinglists at websitemanagers.com.au>wrote:
On 22/04/13 20:53, Ralph Mitchell wrote:
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:
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 Managerswww.websitemanagers.com.au
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
-- "Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton
On 22/04/13 23:20, Vernon Everett wrote:
Hi guys
There are a number of issue with what you propose. Firstly, /etc/shadow is readable by root only. Unless you are running 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...
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 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)
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.
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...
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.
I agree.... also /etc/passwd is the "low fruit". It adds some tangible security (possibly, see above), and it is easy to do.
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.
Not really, see chfn or even chsh, both allow a normal user write access to /etc/passwd.
Trust me, if you have more than a handful of users, doing a checksum on /etc/shadow will only bring you pain and suffering.
I'd limit that to shell users perhaps... really it will depend on your environment.
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.
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 19 April 2013 22:00, Nick <Nick at pettefar.com> 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.
I want to use Xymon to fetch /etc/passwd files so that I can check for unwanted/unnoticed changes.
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
On 22 April 2013 14:54, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:
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
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
On 22 April 2013 17:15, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:
On 22 April 2013 14:54, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:
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
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
participants (8)
-
everett.vernon@gmail.com
-
Galen.Johnson@sas.com
-
jlaidman@rebel-it.com.au
-
mailinglists@websitemanagers.com.au
-
Nick@Pettefar.com
-
novosirj@umdnj.edu
-
Phil.Crooker@orix.com.au
-
ralphmitchell@gmail.com