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

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

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

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