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: You cannot currently use both monitor and file system change monitor to follow the same directory or file. If you want to see changes in a directory, use file system change monitor. If you want to index new events in a directory, use monitor.

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). The audit event will be indexed into the audit index (index=_audit).

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: Additions or changes to the [fschange] stanza require a restart of the Splunk Server.

[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 _audit.

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 greater 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>.

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 
regex1 = .*\.h 
 
[fschange:/etc] 
filters = backups,code 

• Was this topic useful?
• Post a comment