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
Gavin,
Use the FILE client check to determine and possibly alert when a file (/etc/passwd) has been changed.
---- Gavin Leonard <gleonard at progrexion.com> 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
rsmrcina at wi.rr.com a écrit :
Gavin,
Use the FILE client check to determine and possibly alert when a file (/etc/passwd) has been changed.
---- Gavin Leonard <gleonard at progrexion.com> 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
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
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
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 <doctor at makelofine.org>wrote:
rsmrcina at wi.rr.com a écrit :
Gavin,
Use the FILE client check to determine and possibly alert when a file (/etc/passwd) has been changed.
---- Gavin Leonard <gleonard at progrexion.com> 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
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
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
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
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 <doctor at makelofine.org <mailto:doctor at makelofine.org>> wrote:
rsmrcina at wi.rr.com <mailto:rsmrcina at wi.rr.com> a écrit : Gavin, Use the FILE client check to determine and possibly alert when a file (/etc/passwd) has been changed. ---- Gavin Leonard <gleonard at progrexion.com <mailto:gleonard at progrexion.com>> 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 To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk <mailto:hobbit-unsubscribe at hswn.dk> 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 To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk <mailto:hobbit-unsubscribe at hswn.dk>
Yes, of course every authorized changes in /etc/passwd MD5sum must be passed to hobbit-clients.cfg
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 < tainted.soul69 at googlemail.com> 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 <doctor at makelofine.org>wrote:
rsmrcina at wi.rr.com a écrit :
Gavin,
Use the FILE client check to determine and possibly alert when a file (/etc/passwd) has been changed.
---- Gavin Leonard <gleonard at progrexion.com> 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
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
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
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
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
From: Ralph Mitchell [mailto:ralphmitchell at gmail.com] Sent: Wednesday, July 08, 2009 10:21 AM To: hobbit at hswn.dk 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 <tainted.soul69 at googlemail.com<mailto:tainted.soul69 at googlemail.com>> 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 <doctor at makelofine.org<mailto:doctor at makelofine.org>> wrote: rsmrcina at wi.rr.com<mailto:rsmrcina at wi.rr.com> a écrit :
Gavin,
Use the FILE client check to determine and possibly alert when a file (/etc/passwd) has been changed.
---- Gavin Leonard <gleonard at progrexion.com<mailto:gleonard at progrexion.com>> 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
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk<mailto:hobbit-unsubscribe at hswn.dk>
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
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk<mailto:hobbit-unsubscribe at hswn.dk>
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 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. (888) 335-2620 | helpdesk (864) 224-3626 | office (864) 224-3093 | fax
Visit our website: www.heritage-healthcare.com
-----Original Message----- From: Buchan Milne [mailto:bgmilne at staff.telkomsa.net] Sent: Saturday, July 18, 2009 4:54 PM To: hobbit at hswn.dk 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
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
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. (888) 335-2620 | helpdesk (864) 224-3626 | office (864) 224-3093 | fax
Visit our website: www.heritage-healthcare.com
-----Original Message----- From: Buchan Milne [mailto:bgmilne at staff.telkomsa.net] Sent: Saturday, July 18, 2009 4:54 PM To: hobbit at hswn.dk 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
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
I think almost same, using md5 verification is strong (imho), and does not dispense of using other security audit tools.
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:doctor at makelofine.org] Sent: Monday, July 20, 2009 1:16 PM To: hobbit at hswn.dk 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. (888) 335-2620 | helpdesk (864) 224-3626 | office (864) 224-3093 | fax
Visit our website: www.heritage-healthcare.com
-----Original Message----- From: Buchan Milne [mailto:bgmilne at staff.telkomsa.net] Sent: Saturday, July 18, 2009 4:54 PM To: hobbit at hswn.dk 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
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
I think almost same, using md5 verification is strong (imho), and does not dispense of using other security audit tools.
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
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 < kenneth.langford at siemens.com> 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:doctor at makelofine.org] Sent: Monday, July 20, 2009 1:16 PM To: hobbit at hswn.dk 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. (888) 335-2620 | helpdesk (864) 224-3626 | office (864) 224-3093 | fax
Visit our website: www.heritage-healthcare.com
-----Original Message----- From: Buchan Milne [mailto:bgmilne at staff.telkomsa.net] Sent: Saturday, July 18, 2009 4:54 PM To: hobbit at hswn.dk 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
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
I think almost same, using md5 verification is strong (imho), and does not dispense of using other security audit tools.
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
participants (8)
-
bgmilne＠staff.telkomsa.net
-
doctor＠makelofine.org
-
gleonard＠progrexion.com
-
hballinger＠heritage-healthcare.com
-
kenneth.langford＠siemens.com
-
ralphmitchell＠gmail.com
-
rsmrcina＠wi.rr.com
-
tainted.soul69＠googlemail.com