monitoring etc passwd

Not true.  The OP was not planning to monitor the /etc/shadow file, which is
where the password is actually stored.  The /etc/passwd file only contains
the username, userid, groupid, a comment field, the user's home directory
and the default shell.  Those are rarely changed.
Ralph Mitchell


On Mon, Jul 20, 2009 at 1:55 PM, Langford, Kenneth <
user-d20c9ef29808@xymon.invalid> wrote:

The bad news is that a simple user changing his password on the system
would cause an event notification if you are not using NIS/NIS+ or LDAP for
your users and the /etc/passwd file was for local accounts only.

Ken,

----
Kenneth W. Langford
Systems Engineer


-----Original Message-----
From: dOCtoR MADneSs [mailto:user-d54077869176@xymon.invalid]
Sent: Monday, July 20, 2009 1:16 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] monitoring etc passwd

Harold J. Ballinger a écrit :

I agree with you that he needs to have more in place to control this, but
having an alert when changes are made is a nice event notification to kick
off any necessary audit/control procedures. I can definitely see the
advantages of having such an event notification in place.

• Harold Ballinger
IT Coordinator
Heritage Healthcare, Inc.
 (XXX) XXX-XXXX  | helpdesk
 (XXX) XXX-XXXX  | office
 (XXX) XXX-XXXX  | fax

Visit our website: www.heritage-healthcare.com


-----Original Message-----
From: Buchan Milne [mailto:user-9b139aff4dec@xymon.invalid]
Sent: Saturday, July 18, 2009 4:54 PM
To: user-ae9b8668bcde@xymon.invalid
Cc: Gavin Leonard
Subject: Re: [hobbit] monitoring etc passwd

On Tuesday 07 July 2009 23:19:58 Gavin Leonard wrote:

Hi All,
                I am having a problem where users and groups are being
created without the knowledge of the admin team and its making it
difficult
to know who had access to what systems if they leave the company... is
there a way for hobbit to tell me when the /etc/passwd or /etc/group
files
change? Thanks in Advance..

IMHO, this is not a problem to solve by monitoring, it is a problem to be
solved by:
-authorization for actions/commands (e.g. sudo access to specific
commands,
instead of root shell access)
-accounting/auditing (e.g., in case root shell access is required, the
commands/screen output should be recorded against the user who started
the
root shell session)
-security auditing

Centralised authentication (which implies that the only local accounts
required are for "system" use, not for users) can also help reduce the
amount
of work in picking up and fixing incorrect user/group changes.

If monitoring when changes were made to local files forms one part of
your
process, fine, you can use the 'FILE' monitoring feature with the mtime
check.

However, I would really hope this is not the only thing you are putting
in
place to solve this problem.

Regards,
Buchan

I think almost same, using md5 verification is strong (imho), and does
not dispense of using other security audit tools.