Any way to audit file permission changes?

[fullspeed]

So first off this isn't a problem with Freenas per say I'm just asking in a general sense if there is a way to watch files to see if someone changes permissions.

We have some sensitive files/folders and I want to monitor them for access changes. There is an audit program for freebsd however I have NTFS permission layered on top of them so that won't work.

I was thinking maybe I could externally monitor the NTFS folders from a windows server or perhaps write a bash script that has a baseline and checks for changes via get-facl?

Just throwing it out there.

 

[dlavigne]

Were you able to find a way to do this?

 

[fullspeed]

Were you able to find a way to do this?

Yes but not through Freebsd as it seemed to be the more difficult way to go about it, I wrote a couple Powershell scripts.

The first script creates baseline file containing original permissions (I run that whenever I want to set a new baseline as well)

Then I wrote another script which runs every hour and basically compares the current permissions to the baseline, if they change it sends me an email.

I only have a few sensitive folders (account, legal, research) so the upkeep isn't too difficult.

 

[fullspeed]

Hey guys,

I wanted to revisit this as I hate updating these scripts manually. I was thinking of potentially easier ways to do this and figured why couldn't I map my freenas box as a network share on one of my windows servers with auditing enabled then just monitor it via splunk (which alerts me on permissions changes)

Thing is when I add someone under the auditing tab it just disappears as soon as I hit apply, any idea why this would happen?

 

[anodos]

Hey guys,

I wanted to revisit this as I hate updating these scripts manually. I was thinking of potentially easier ways to do this and figured why couldn't I map my freenas box as a network share on one of my windows servers with auditing enabled then just monitor it via splunk (which alerts me on permissions changes)

Thing is when I add someone under the auditing tab it just disappears as soon as I hit apply, any idea why this would happen?

If this is a samba share you can always configure vfs_full_audit.

https://www.samba.org/samba/docs/man/manpages-3/vfs_full_audit.8.html

 

[fullspeed]

If this is a samba share you can always configure vfs_full_audit.

https://www.samba.org/samba/docs/man/manpages-3/vfs_full_audit.8.html

The most important thing is logging of permissions changes, will it do that? I'm assuming it writes to the samba logs? if so I can get Splunk to monitor it and that's my answer.

 

[tvsjr]

As a security guy, your script makes me cringe because it's only checking once per hour. People can play all sorts of hijinx in 59 minutes. vfs_full_audit will produce a (potentially very chatty) log of everything done via Samba... so if you're only exposing your files via Samba/CIFS, you're golden. If you have NFS, AFP, whatever else where permissions could also be altered, that's a different challenge.

I've never tried it, but it might be better to install a Universal Forwarder on the FreeNAS and let it forward the data, rather than having Splunk digest the data via a share. Make sure you're careful on what audit events you enable... turning everything on on a busy server could burn through quite a few GBs of data ingest per day.

 

[fullspeed]

As a security guy, your script makes me cringe because it's only checking once per hour. People can play all sorts of hijinx in 59 minutes. vfs_full_audit will produce a (potentially very chatty) log of everything done via Samba... so if you're only exposing your files via Samba/CIFS, you're golden. If you have NFS, AFP, whatever else where permissions could also be altered, that's a different challenge.

I've never tried it, but it might be better to install a Universal Forwarder on the FreeNAS and let it forward the data, rather than having Splunk digest the data via a share. Make sure you're careful on what audit events you enable... turning everything on on a busy server could burn through quite a few GBs of data ingest per day.

Yeah that's a fair point, unless I run the script all the time it won't catch any access changes fast enough. See with windows I can turn on auditing, have Splunk watch the security log and i'm notified immediately. I'm trying to find a similar solution but in Freenas.

Would Netwrix or Varonis meet this goal? I just cringe at how expensive they would be. I really only need to monitor 3-4 small shares with low turnover.

I have Splunk setup on all my Freenas servers but I need data for them to look over, currently nothing can make windows permissions changes show up in any Freenas/Zfs log so there is nothing for Splunk to see.

 

[tvsjr]

@anodos already gave you the solution... just click on the link he provided and read through the man page, then set it up.

 

[fullspeed]

@anodos already gave you the solution... just click on the link he provided and read through the man page, then set it up.

I read through it and was able to setup the auditing very easily however it's only showing open/close/chdir etc,. even with full_audit:success/failure both at "all"

I'm tailing the messages file and can see everything just fine but nothing gets logged when permissions for a file get added/removed:

Jan 18 14:01:16 fs07 smbd_audit: domain\testuser |10.100.68.31|10.100.68.31|ftp|close|ok|.
Jan 18 14:01:21 fs07 smbd_audit: domain\testuser|10.100.68.31|10.100.68.31|ftp|chdir|ok|chdir|/mnt/storage01/ftp
Jan 18 14:01:21 fs07 smbd_audit: domain\testuser|10.100.68.31|10.100.68.31|ftp|realpath|ok|test.txt
Jan 18 14:01:21 fs07 smbd_audit: domain\testuser|10.100.68.31|10.100.68.31|ftp|realpath|ok|.

 

[anodos]

I read through it and was able to setup the auditing very easily however it's only showing open/close/chdir etc,. even with full_audit:success/failure both at "all"

I'm tailing the messages file and can see everything just fine but nothing gets logged when permissions for a file get added/removed:

Jan 18 14:01:16 fs07 smbd_audit: domain\testuser |10.100.68.31|10.100.68.31|ftp|close|ok|.
Jan 18 14:01:21 fs07 smbd_audit: domain\testuser|10.100.68.31|10.100.68.31|ftp|chdir|ok|chdir|/mnt/storage01/ftp
Jan 18 14:01:21 fs07 smbd_audit: domain\testuser|10.100.68.31|10.100.68.31|ftp|realpath|ok|test.txt
Jan 18 14:01:21 fs07 smbd_audit: domain\testuser|10.100.68.31|10.100.68.31|ftp|realpath|ok|.

Okay. I looked at some debug output when changing permissions on a share. NFSv4 permission changes only appear if you have samba logging set to 10 (full). Relevant message is "/source3/modules/nfs4_acls.c:1036 (smb_set_nt_acl_nfs4)". I believe vfs_full_audit only audits samba VFS operations. It doesn't monitor operations performed by samba modules (like nfs4_acls, vfs_zfsacl, etc).

source3\modules\vfs_full_audit.c covers the following:

Code:

/* NT ACL operations. */

    SMB_VFS_OP_FGET_NT_ACL,
    SMB_VFS_OP_GET_NT_ACL,
    SMB_VFS_OP_FSET_NT_ACL,

    /* POSIX ACL operations. */

    SMB_VFS_OP_CHMOD_ACL,
    SMB_VFS_OP_FCHMOD_ACL,

    SMB_VFS_OP_SYS_ACL_GET_FILE,
    SMB_VFS_OP_SYS_ACL_GET_FD,
    SMB_VFS_OP_SYS_ACL_BLOB_GET_FILE,
    SMB_VFS_OP_SYS_ACL_BLOB_GET_FD,
    SMB_VFS_OP_SYS_ACL_SET_FILE,
    SMB_VFS_OP_SYS_ACL_SET_FD,
    SMB_VFS_OP_SYS_ACL_DELETE_DEF_FILE,

Meaning that it only covers operations that modify NT ACLS (those set in share_info.tdb), and POSIX ACL (i.e. not NFSv4 ACL) operations.

It's probably best to clarify on samba mailing lists.

 

[fullspeed]

Okay. I looked at some debug output when changing permissions on a share. NFSv4 permission changes only appear if you have samba logging set to 10 (full). Relevant message is "/source3/modules/nfs4_acls.c:1036 (smb_set_nt_acl_nfs4)". I believe vfs_full_audit only audits samba VFS operations. It doesn't monitor operations performed by samba modules (like nfs4_acls, vfs_zfsacl, etc).

source3\modules\vfs_full_audit.c covers the following:

Code:

/* NT ACL operations. */

    SMB_VFS_OP_FGET_NT_ACL,
    SMB_VFS_OP_GET_NT_ACL,
    SMB_VFS_OP_FSET_NT_ACL,

    /* POSIX ACL operations. */

    SMB_VFS_OP_CHMOD_ACL,
    SMB_VFS_OP_FCHMOD_ACL,

    SMB_VFS_OP_SYS_ACL_GET_FILE,
    SMB_VFS_OP_SYS_ACL_GET_FD,
    SMB_VFS_OP_SYS_ACL_BLOB_GET_FILE,
    SMB_VFS_OP_SYS_ACL_BLOB_GET_FD,
    SMB_VFS_OP_SYS_ACL_SET_FILE,
    SMB_VFS_OP_SYS_ACL_SET_FD,
    SMB_VFS_OP_SYS_ACL_DELETE_DEF_FILE,

Meaning that it only covers operations that modify NT ACLS (those set in share_info.tdb), and POSIX ACL (i.e. not NFSv4 ACL) operations.

It's probably best to clarify on samba mailing lists.

Damn this is becoming a tough task, everything is fighting me.. lots of caveats for all the potential solutions I've found.

Thanks for the info I appreciate it.

 

[anodos]

One option might be to use dtrace to monitor acl_set_file, acl_set_fd, etc syscalls by smbd processes. Correlating it to match up with user accounts might be difficult. If you can output the pid of the particular smbd process you might be able to use tools like smbstatus to do this correlation.