FSChange Hashing Question

[kholleran]

Hello,

I am setting up FSChange to monitor system32 and critical application .exe & .dll files. Do I need to utilize the hash in FSChange to monitor these properly to guard against dll insertion and stuff like that? If so, what is an appropriate hashMaxSize value?

Thanks for your advice.

Kevin

[Lowell]

Also, the hash values seem to be very broken on the windows implementation so I always disable hashing on windows. (I find this quite annoying, because every thread I've ever read suggests using windows auditing instead, as Felix has pointed out in his answer.)

And while I agree that the windows file auditing may be a better approach, it would still be nice if this feature actually worked within splunk on all platforms that it supports. For example, there may be times when I want to limit the frequency of change reporting on a windows system. I can tell fschange to poll every 15 minutes and get nice and small audit events, vs the massive events that the windows auditing creates for every change. And splunk also has the option of indexing the file, if you want what. Which isn't something you can get with the windows auditing feature, I don't believe. (Obviously, you don't want to do this for .dlls or .exes.) There are pros/cons to each, but it would be nice if both choices worked well.

[ftk]

I agree. I currently work around the lack of the fschange fullEvent=true option when using Windows OS auditing by having a separate monitor stanza that indexes the contents of the config files I am doing FIM on: http://answers.splunk.com/questions/2882/using-fschange-to-monitor-windows-filesystem/3620#3620

[ftk]

Kevin, keep in mind that fschange on Windows will not record the login making the change, so IMHO it is useless for FIM on Windows.

You would be better served using Windows native SACLs to monitor these files and just monitor the Windows Security log for object audit events.

To go a bit more in depth, SACLs are the audit entries you can define on NTFS for files and/or folders. They are easy to implement adhoc (Right click file > Properties > Security tab > Advanced > Auditing tab), and can be deployed via group policy to effectively farm out the same configs to your entire domain.

Naturally you will have to enable Object Access auditing (Success, Failure) in your server's security policies before the SACL entries take effect.

Once this has been done, you can check the security log for events 560 thru 564 and 567. These will tell you the file/folder accesses, success/failure, login, etc.

There are some pitfalls to monitoring system32 on Windows due to some very chatty processes in some of the system32 subfolders, WBEM or similar comes to mind.

Let me know if you need me to expand on any of this.