File system change monitor

File system change monitor

Splunk's file system change monitor is useful for tracking changes in your file system. The file system change monitor watches any directory you specify and generates an event (in Splunk) when that directory undergoes any change. It is completely configurable and can detect when any file on the system is edited, deleted or added (not just Splunk-specific files). For example, you can tell the file system change monitor to watch /etc/sysconfig/ and alert you any time the system's configurations are changed.

Configure file system change monitor in inputs.conf.

Note: If you're interested in auditing file reads on Windows, check out this topic on the Splunk Community best practices Wiki. Some users might find it more straightforward to use Windows native auditing tools.

How the file system change monitor works

The file system change monitor detects changes using:

• modification date/time
• group ID
• user ID
• file mode (read/write attributes, etc.)
• optional SHA256 hash of file contents

You can configure the following features of the file system change monitor:

• white listing using regular expressions
  • specify files that will be checked no matter what
• black listing using regular expressions
  • specify files to skip
• directory recursion
  • including symbolic link traversal
  • scanning multiple directories, each with their own polling frequency
• cryptographic signing
  • creates a distributed audit-trail of file system changes
• indexing entire file as an event on add/change
  • size cutoffs for sending entire file and/or hashing
• all change events indexed by and searchable through Splunk

Configure the file system change monitor

By default, the file system change monitor will generate events whenever the contents of $SPLUNK_HOME/etc/ are changed, deleted, or added to. When you start Splunk for the first time, an add audit event will be generated for each file in the $SPLUNK_HOME/etc/ directory and all sub-directories. Any time after that, any change in configuration (regardless of origin) will generate an audit event for the affected file(s). If you have signedaudit=true , the file system change audit event will be indexed into the audit index (index=_audit). If signedaudit is not tuend on, by default, the events are written to the main index unless you specify another index.

Note: The file system change monitor does not track the user name of the account executing the change, only that a change has occurred. For user-level monitoring consider using native operating system audit tools, which have access to this information.

You can use the file system change monitor to watch any directory by adding a stanza to inputs.conf.

Create your own inputs.conf in $SPLUNK_HOME/etc/system/local/. Edit this files in $SPLUNK_HOME/etc/system/local/, or your own custom application directory in $SPLUNK_HOME/etc/apps/. For more information on configuration files in general, see how configuration files work.

Edit the [fschange] stanza to configure the file system change monitor. Every setting is optional except the stanza name fschange:<directory or file to monitor>.

Note: You must restart Splunk any time you make changes to the [fschange] stanza.

[fschange:<directory or file to monitor>]
index=<indexname>
recurse=<true | false>
followLinks=<true | false>
pollPeriod=N
hashMaxSize=N
fullEvent=<true | false>
sendEventMaxSize=N
signedaudit=<true | false>
filters=<filter1>,<filter2>,...<filterN> 

Possible attribute/value pairs

[fschange:<directory or file to monitor>]

• The system will monitor all adds/updates/deletes to this directory and sub-directories.
• Any changes will generate an event that is indexed by Splunk.
• Defaults to $SPLUNK_HOME/etc/.

index=<indexname>

• The index to store all events generated.
• Defaults to main (unless you have turned on audit event signing).

recurse=<true | false>

• If true, recurse directories within the directory specified in [fschange].
• Defaults to true.

followLinks=<true | false>

• If true, the file system change monitor will follow symbolic links.
• Defaults to false.

Caution: If you are not careful with setting followLinks, file system loops may occur.

pollPeriod=N

• Check this directory for changes every N seconds.
• Defaults to 3600.
  • If you make a change, the file system audit events could take anywhere between 1 and 3600 seconds to be generated and become available in audit search.

hashMaxSize=N

• Calculate a SHA1 hash for every file that is less than or equal to N size in bytes.
• This hash can be used as an additional method for detecting change in the file/directory.
• Defaults to -1 (no hashing used for change detection).

signedaudit=<true | false>

• Send cryptographically signed add/update/delete events.
• Defaults to false.
• Setting to true will generate events in the _audit index.
• This should be deliberately set to false if you wish to set the index.

Note: When setting signedaudit to true, make sure auditing is enabled in audit.conf.

fullEvent=<true | false>

• Send the full event if an add or update change is detected.
• Further qualified by the sendEventMaxSize attribute.
• Defaults to false.

sendEventMaxSize=N

• Only send the full event if the size of the event is less than or equal to N bytes.
• This limits the size of indexed file data.
• Defaults to -1, which is unlimited.

sourcetype = <string>

• Set the sourcetype for events from this input.
• "sourcetype=" is automatically prepended to <string>.
• sourcetype = fs_notification by default.

filesPerDelay = <integer>

• Injects a delay specified by 'delayInMills' after processing <integer> files.
• This is used to throttle file system monitoring so it doesn't consume as much CPU.

delayInMills = <integer>

• The delay in milliseconds to use after processing every <integer> files as specified in 'filesPerDelay'.
• This is used to throttle file system monitoring so it doesn't consume as much CPU.

filters=<filter1>,<filter2>,...<filterN>

Each of these filters will apply from left to right for each file or directory that is found during the monitors poll cycle.

To define a filter, add a [filter...] stanza as follows:

[filter:blacklist:backups] 
regex1 = .*bak
regex2 = .*bk
[filter:blacklist:code] 
regex1 = .*\.c 
regex2 = .*\.h 
 
[fschange:/etc] 
filters = backups,code 

Fschange white/blacklist logic is handed quite similarly to typical firewalls. The events pass down the list of filters until they reach their first match. If the first filter to match an event is a whitelist, the event will be indexed. If the first filter to match an event is a blacklist, the event will not be indexed. If an event reaches the end of the chain with no matches, it will be indexed. To create a no-index default, end the chain with a blacklist for all events. eg,

...
filters = <filter1>, <filter2>, ... terminal-blacklist

[filter:blacklist:terminal-blacklist]
regex1 = .

• Was this topic useful?
• Post a comment