Re: [ossec-list] Identifying user that made change to file as part of File Integrity/Syscheck monitoring?
I see this topic come up a lot and I have dealt with the question from auditors too. Unless you have full auditing enabled, the simple answer is no. Think about this -- a file is writable by the owner and a group - the group contains 1000 users. Auditd is NOT enabled. One of those 1000 users that has the ability to modify the file and indeed they do. Unix checks the perms and verifies that the uid or gid has permission to modify the file. It does, it is allowed. No place in the inode or the directory entry is any information kept on who modified the file. Why? Because it has to be someone that is authorized to do it. Therefore the only way to track this data is to have another process monitor everything users are doing - i.e. "auditd" running, in order to track this. At one point I had an auditor tell me "But tripwire does this." Um, no it does not. Tripwire shows that the file was changed and who the owner of the file is. Based on this, auditors sometimes assume that it was the owner changing the folder, which is not the case. Additionally, if a user has sudo privs to one of the UIDs or GIDs - well, that pretty much throws it all out the window. Take a look at "auditd" and if you are willing to accept the load it may present on your system, then this will solve the question you are asking. Otherwise, you are not going to be able to do it. It is all about understanding what information is stored in an inode and the directory entry. (And the directory entry is minimal -- filename, inode #) cheers Kat
Re: [ossec-list] Identifying user that made change to file as part of File Integrity/Syscheck monitoring?
On Mon, Nov 12, 2012 at 10:51 AM, Kat wrote: > I see this topic come up a lot and I have dealt with the question from > auditors too. Unless you have full auditing enabled, the simple answer is > no. > > Think about this -- a file is writable by the owner and a group - the group > contains 1000 users. Auditd is NOT enabled. One of those 1000 users that has > the ability to modify the file and indeed they do. Unix checks the perms and > verifies that the uid or gid has permission to modify the file. It does, it > is allowed. > > No place in the inode or the directory entry is any information kept on who > modified the file. Why? Because it has to be someone that is authorized to > do it. Therefore the only way to track this data is to have another process > monitor everything users are doing - i.e. "auditd" running, in order to > track this. > > At one point I had an auditor tell me "But tripwire does this." Um, no it > does not. Tripwire shows that the file was changed and who the owner of the > file is. Based on this, auditors sometimes assume that it was the owner > changing the folder, which is not the case. > > Additionally, if a user has sudo privs to one of the UIDs or GIDs - well, > that pretty much throws it all out the window. > > Take a look at "auditd" and if you are willing to accept the load it may > present on your system, then this will solve the question you are asking. > Otherwise, you are not going to be able to do it. It is all about > understanding what information is stored in an inode and the directory > entry. (And the directory entry is minimal -- filename, inode #) > > cheers > Kat I'm guessing the big commercial UNIXes have something similar, but auditd is a Linux daemon, right?
Re: [ossec-list] Identifying user that made change to file as part of File Integrity/Syscheck monitoring?
auditd is a Unix-centric process. Kind of like ACLs though. They all have it, but they all have slightly different ways of enabling and managing. >
Re: [ossec-list] Identifying user that made change to file as part of File Integrity/Syscheck monitoring?
All, My 2 cents, though it appears auditd (for Linux) may not be the OS the originator was asking about... Two comments: 1) auditd (for Linux) support is provided within the kernel. I have not found it to be CPU intensive provided you do not try to audit every syscall under the sun. 2) auditd (for Linux) is flexible, allowing you to create rules for syscalls as well as reads/writes/executes/attribute change to files/directories. It also records UID/GID metadata associated with an event, including the effective UID and the audited UID, meaning you can record actions taken after a user sudo's to another account. OSSEC 2.7 does come with auditd rules out-of-the-box (and have been available from this distribution list for quite some time). The issue is that auditd (for Linux) writes out these very annoying logs that are multi-line joined by common event ID. The metadata is spread across these multiple lines so you will not get the full picture of what it is happening without code changes to OSSEC--for example, usually the 'subject' (e.g. file modified) is in a separate line that the user who modified the file. I am hoping the "Accumulator" progress being made will extend over to atomic alerts. On Nov 12, 2012, at 10:51 AM, Kat wrote: > I see this topic come up a lot and I have dealt with the question from > auditors too. Unless you have full auditing enabled, the simple answer is no. > > Think about this -- a file is writable by the owner and a group - the group > contains 1000 users. Auditd is NOT enabled. One of those 1000 users that has > the ability to modify the file and indeed they do. Unix checks the perms and > verifies that the uid or gid has permission to modify the file. It does, it > is allowed. > > No place in the inode or the directory entry is any information kept on who > modified the file. Why? Because it has to be someone that is authorized to do > it. Therefore the only way to track this data is to have another process > monitor everything users are doing - i.e. "auditd" running, in order to track > this. > > At one point I had an auditor tell me "But tripwire does this." Um, no it > does not. Tripwire shows that the file was changed and who the owner of the > file is. Based on this, auditors sometimes assume that it was the owner > changing the folder, which is not the case. > > Additionally, if a user has sudo privs to one of the UIDs or GIDs - well, > that pretty much throws it all out the window. > > Take a look at "auditd" and if you are willing to accept the load it may > present on your system, then this will solve the question you are asking. > Otherwise, you are not going to be able to do it. It is all about > understanding what information is stored in an inode and the directory entry. > (And the directory entry is minimal -- filename, inode #) > > cheers > Kat
