[Xymon] Xymon Log Retrieval

[Adam Goryachev]

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