Xymon Mailing List Archive search

monitoring etc passwd

12 messages in this thread

list Gavin Leonard · Tue, 7 Jul 2009 16:19:58 -0600 ·
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..

-Gavin
list Rich Smrcina · Tue, 7 Jul 2009 17:24:48 -0500 ·
Gavin,

Use the FILE client check to determine and possibly alert when a file (/etc/passwd) has been changed.
quoted from Gavin Leonard

---- Gavin Leonard <user-d65663809eb4@xymon.invalid> 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..

-Gavin

list dOCtoR MADneSs · Wed, 08 Jul 2009 10:02:24 +0200 ·
quoted from Rich Smrcina
user-cf452ff334e0@xymon.invalid a écrit :
Gavin,

Use the FILE client check to determine and possibly alert when a file (/etc/passwd) has been changed.

---- Gavin Leonard <user-d65663809eb4@xymon.invalid> 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..

-Gavin

Hi,

In client-local.cfg :
[your_host]
file:/etc/passwd
in hobbit-clients.cfg :
HOST=your_host
FILE /etc/passwd red MD5=9780JNLKNoiulknaée2

Those settings should do exactly what you need
list Shaun Phillips · Wed, 8 Jul 2009 11:34:10 +0100 ·
If you do monthly root password changes this is going to send your entire
estate red surely as the MD5 will change?
quoted from dOCtoR MADneSs

On Wed, Jul 8, 2009 at 9:02 AM, dOCtoR MADneSs <user-d54077869176@xymon.invalid>wrote:
user-cf452ff334e0@xymon.invalid a écrit :

Gavin,
Use the FILE client check to determine and possibly alert when a file
(/etc/passwd) has been changed.

---- Gavin Leonard <user-d65663809eb4@xymon.invalid> 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..

-Gavin

Hi,
In client-local.cfg :
[your_host]
file:/etc/passwd
in hobbit-clients.cfg :
HOST=your_host
FILE /etc/passwd red MD5=9780JNLKNoiulknaée2

Those settings should do exactly what you need

list dOCtoR MADneSs · Wed, 08 Jul 2009 13:48:02 +0200 ·
quoted from Shaun Phillips
Shaun Phillips a écrit :
If you do monthly root password changes this is going to send your entire estate red surely as the MD5 will change?

On Wed, Jul 8, 2009 at 9:02 AM, dOCtoR MADneSs <user-d54077869176@xymon.invalid <mailto:user-d54077869176@xymon.invalid>> wrote:

    user-cf452ff334e0@xymon.invalid <mailto:user-cf452ff334e0@xymon.invalid> a écrit :

        Gavin,

        Use the FILE client check to determine and possibly alert when a
        file (/etc/passwd) has been changed.

        ---- Gavin Leonard <user-d65663809eb4@xymon.invalid
        <mailto:user-d65663809eb4@xymon.invalid>> 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..

            -Gavin


    Hi,

    In client-local.cfg :
    [your_host]
    file:/etc/passwd
    in hobbit-clients.cfg :
    HOST=your_host
    FILE /etc/passwd red MD5=9780JNLKNoiulknaée2

    Those settings should do exactly what you need

Yes, of course every authorized changes in /etc/passwd MD5sum must be passed to hobbit-clients.cfg
list Ralph Mitchell · Wed, 8 Jul 2009 11:20:31 -0500 ·
Only if passwords are actually stored in /etc/passwd.  Linux systems have
been using /etc/shadow to store passwords, along with last change time and
some other things, leaving just the uid, gid, home directory and shell in
/etc/passwd.
Ralph Mitchell


On Wed, Jul 8, 2009 at 5:34 AM, Shaun Phillips <
quoted from dOCtoR MADneSs
user-176e7038266c@xymon.invalid> wrote:
If you do monthly root password changes this is going to send your entire
estate red surely as the MD5 will change?


On Wed, Jul 8, 2009 at 9:02 AM, dOCtoR MADneSs <user-d54077869176@xymon.invalid>wrote:
user-cf452ff334e0@xymon.invalid a écrit :

Gavin,
Use the FILE client check to determine and possibly alert when a file
(/etc/passwd) has been changed.

---- Gavin Leonard <user-d65663809eb4@xymon.invalid> 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..

-Gavin

Hi,
In client-local.cfg :
[your_host]
file:/etc/passwd
in hobbit-clients.cfg :
HOST=your_host
FILE /etc/passwd red MD5=9780JNLKNoiulknaée2

Those settings should do exactly what you need

list Gavin Leonard · Wed, 8 Jul 2009 10:24:51 -0600 ·
Correct.. I just need to know when a new user or group has been added, I am not planning to monitor the shadow file.

-Gavin
quoted from Ralph Mitchell


From: Ralph Mitchell [mailto:user-00a5e44c48c0@xymon.invalid]
Sent: Wednesday, July 08, 2009 10:21 AM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] monitoring etc passwd

Only if passwords are actually stored in /etc/passwd.  Linux systems have been using /etc/shadow to store passwords, along with last change time and some other things, leaving just the uid, gid, home directory and shell in /etc/passwd.

Ralph Mitchell

On Wed, Jul 8, 2009 at 5:34 AM, Shaun Phillips <user-176e7038266c@xymon.invalid<mailto:user-176e7038266c@xymon.invalid>> wrote:
If you do monthly root password changes this is going to send your entire estate red surely as the MD5 will change?

On Wed, Jul 8, 2009 at 9:02 AM, dOCtoR MADneSs <user-d54077869176@xymon.invalid<mailto:user-d54077869176@xymon.invalid>> wrote:
user-cf452ff334e0@xymon.invalid<mailto:user-cf452ff334e0@xymon.invalid> a écrit :

Gavin,

Use the FILE client check to determine and possibly alert when a file (/etc/passwd) has been changed.

---- Gavin Leonard <user-d65663809eb4@xymon.invalid<mailto:user-d65663809eb4@xymon.invalid>> 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..

-Gavin


Hi,

In client-local.cfg :
[your_host]
file:/etc/passwd
in hobbit-clients.cfg :
HOST=your_host
FILE /etc/passwd red MD5=9780JNLKNoiulknaée2

Those settings should do exactly what you need
list Buchan Milne · Sat, 18 Jul 2009 22:53:45 +0200 ·
quoted from Gavin Leonard
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
list Harold J. Ballinger · Mon, 20 Jul 2009 11:49:00 -0400 ·
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 
quoted from Buchan Milne


-----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
list dOCtoR MADneSs · Mon, 20 Jul 2009 19:16:21 +0200 ·
quoted from Harold J. Ballinger
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.
list Kenneth Langford · Mon, 20 Jul 2009 14:55:49 -0400 ·
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
quoted from dOCtoR MADneSs


-----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.
list Ralph Mitchell · Mon, 20 Jul 2009 14:56:08 -0500 ·
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 <
quoted from Kenneth Langford
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.