[Bro] Intel::FILE_NAME and SMB_files behavior questions

[Seth Hall]

On 31 Mar 2018, at 18:14, James Gordon wrote:

> I have a few questions on behavioral issues with the intel framework 
> and SMB / SMB file logging:
>
> 1. I’m not sure if this is expected behavior or not, but it 
> doesn’t look like filenames parsed in smb_files.log are properly 
> being logged in files.log.

I checked in our autogenerated documentation and I'm now noticing a 
glaring lack of documentation about *what* that log represents. :(

That log is meant to represent that an action against a file was seen.  
Considering that since SMB is a file system protocol you will see a lot 
of actions that aren't necessarily file transfers.  Most of what I've 
typically seen in smb_files.log is files being opened.  This seems be a 
very common action in SMB, I don't know all of the reasons that an 
application might open a file but not read nor write to it but it's 
definitely seen a lot.  I think that it could be a way for the client to 
get a timestamp for a remote file or other metadata.  Other actions that 
fits into that log are file renames and deletes.  File renames are 
represented through the "name" and "prev_name" fields.  Deletes just 
give the name of the file before it was deleted.

The important field to look at is the "action" field since that's where 
the log tells you what the client was actually doing.  Here are all of 
the potential actions that you will typically see there...
		FILE_OPEN,
		FILE_RENAME,
		FILE_DELETE,

If you wanted, you could add FILE_CLOSE as action that you want logged 
if you add this to your local.bro (I chose to leave this out by default 
since it didn't seem to provide much extra context, but had a great 
increase in log size)...

redef SMB::logged_file_actions += { SMB::FILE_CLOSE };

You could also have it include FILE_WRITE and FILE_READ, but those are 
really not great to include and lead to a massive increase in log size 
but I felt like transfers were better represented through the files.log 
anyway.  Generally if data is seen as being transferred that will be 
represented in files.log since that's the aggregation point for all 
"files" seen by Bro.  smb_files.log can be really helpful if you need to 
know when someone is poking around at files even if they aren't 
transferring them and there is a lot of information there that can be 
useful forensically (MAC times being the big one in my mind).

If you have thoughts on other SMB logs that you'd like to see or if you 
have thoughts on extensions to the smb_files.log I'd love to hear them!  
There is definitely no right or wrong answer to what should be in those 
logs or even what logs should exist.

   .Seth

--
Seth Hall * Corelight, Inc * www.corelight.com