
Monitor changes to your file system
This feature has been deprecated. |
---|
This feature has been deprecated as of Splunk Enterprise version 5.0. This means that although it continues to function in version 6.x of Splunk software, it might be removed in a future version. As an alternative, you can:
For a list of all deprecated features, see the topic Deprecated features in the Release Notes. |
The Splunk Enterprise file system change monitor tracks changes in your file system. The monitor watches a directory you specify and generates an event when that directory undergoes a 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 configurations change.
To monitor file system changes on Windows, see Monitor file system changes in this manual to learn how with Microsoft 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:
- whitelist using regular expressions
- specify files that will be checked, no matter what
- blacklist 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 Enterprise
By default, the file system change monitor generates audit events whenever the contents of $SPLUNK_HOME/etc/
are changed, deleted, or added to. When you start Splunk Enterprise for the first time, it generates an audit event for each file in the $SPLUNK_HOME/etc/
directory and all subdirectories. Afterward, any change in configuration (regardless of origin) generates an audit event for the affected file. If you have configured signedaudit=true
, Splunk Enterprise indexes the file system change into the audit index (index=_audit
). If signedaudit
is not turned on, by default, Splunk Enterprise writes the events to the main index unless you specify another index.
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.
Caution: Do not configure the file system change monitor to monitor your root file system. This can be dangerous and time-consuming if directory recursion is enabled.
Configure the file system change monitor
Configure the file system change monitor in inputs.conf. There is no support for configuring the file system change monitor in Splunk Web. You must restart Splunk Enterprise any time you make changes to the [fschange]
stanza.
1. Open inputs.conf
.
2. Add [fschange:<directory>]
stanzas to specify files or directories that Splunk Enterprise should monitor for changes.
3. Save the inputs.conf file and close it.
4. Restart Splunk Enterprise. File system change monitoring begins immediately.
If you want to use this feature with forwarding, follow these guidelines:
- To send the events to a remote indexer, use a heavy forwarder.
- If you cannot use a heavy forwarder, then follow the configuration instructions at Use with a universal forwarder.
To use the file system change monitor to watch any directory, add or edit an [fschange]
stanza to inputs.conf
in $SPLUNK_HOME/etc/system/local/
or your own custom application directory in $SPLUNK_HOME/etc/apps/
. For information on configuration files in general, see About configuration files in the Admin manual.
Syntax
Here is the syntax for the [fschange]
stanza:
[fschange:<directory or file to monitor>] <attribute1> = <val1> <attribute2> = <val2> ...
Note the following:
- Splunk Enterprise monitors all adds/updates/deletes to the directory and its subdirectories.
- Any change generates an event that Splunk indexes.
<directory or file to monitor>
defaults to$SPLUNK_HOME/etc/
.
Attributes
All attributes are optional. Here is the list of available attributes:
Attribute | Description | Default |
---|---|---|
index=<indexname>
|
The index where all generated events should be stored. | main (unless you have turned on audit event signing).
|
recurse=<true | false>
|
Whether or not to recurse all directories within the directory specified in <code[fschange]. Set to true to recurse all subdirectories and false to specify only the current directory. | true |
followLinks=<true | false>
|
Whether or not the file system change monitor follows symbolic links. Set to true to follow symbolic links and false not to follow symbolic links. | false
Caution: If you are not careful when setting |
pollPeriod=N
|
Check this directory for changes every N seconds. | 3600 seconds
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. |
-1 (no hashing used for change detection). |
signedaudit=<true | false>
|
Send cryptographically signed add/update/delete events.
Set to true to generate events in the _audit index.
Set to false if you're setting the |
false |
fullEvent=<true | false>
|
* Send the full event if an add or update change is detected.
|
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. |
-1 (unlimited.) |
sourcetype = <string>
|
Set the source type for events from this input.
"sourcetype::" is prepended to |
audittrail (if signedaudit=true ) or fs_notification (if signedaudit=false )
|
filesPerDelay = <integer>
|
Injects a delay specified by delayInMills after processing <integer> files. This throttles file system monitoring so it does not consume as much CPU.
|
n/a |
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 does not 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. See the next section for information on defining filters. | n/a |
Define a filter
To define a filter to use with the filters
attribute, add a [filter...]
stanza as follows:
[filter:blacklist:backups] regex1 = .*bak regex2 = .*bk [filter:whitelist:code] regex1 = .*\.c regex2 = .*\.h [fschange:/etc] filters = backups,code
The following list describes how Splunk Enterprise handles fschange whitelist and blacklist logic:
- The events run down through the list of filters until they reach their first match.
- If the first filter to match an event is a whitelist, then Splunk Enterprise indexes the event.
- If the first filter to match an event is a blacklist, the filter prevents the event from getting indexed.
- If an event reaches the end of the chain with no matches, then Splunk Enterprise indexes the event. This means that there is an implicit "all pass" filter built in.
To default to a situation where Splunk Enterprise does not index events if they don't match a whitelist explicitly, end the chain with a blacklist that matches all remaining events.
For example:
... filters = <filter1>, <filter2>, ... terminal-blacklist [filter:blacklist:terminal-blacklist] regex1 = .?
If you blacklist a directory including a terminal blacklist at the end of a series of whitelists, then Splunk Enterprise blacklists all its subfolders and files, as they do not pass any whitelist. To accommodate this, whitelist all desired folders and subfolders explicitly ahead of the blacklist items in your filters.
Example of explicit whitelisting and terminal blacklisting
This configuration monitors files in the specified directory with the extensions .config
, .xml
, .properties
, and .log
and ignores all others.
In this example, a directory could be blacklisted. If this is the case, Splunk Enterprise blacklists all of its subfolders and files as well. Only files in the specified directory would be monitored.
[filter:whitelist:configs] regex1 = .*\.config regex2 = .*\.xml regex3 = .*\.properties regex4 = .*\.log [filter:blacklist:terminal-blacklist] regex1 = .? [fschange:/var/apache] index = sample recurse = true followLinks = false signedaudit = false fullEvent = true sendEventMaxSize = 1048576 delayInMills = 1000 filters = configs,terminal-blacklist
Use with a universal forwarder
To forward file system change monitor events from a universal forwarder, you must set signedaudit = false
and index=_audit
.
[fschange:<directory or file to monitor>] signedaudit = false index=_audit
With this workaround, Splunk Enterprise indexes file system change monitor events into the _audit
index with sourcetype
set to fs_notification
and source
set to fschangemonitor
, instead of the default value of audittrail
for both sourcetype
and source
.
PREVIOUS Monitor First In, First Out (FIFO) queues |
NEXT Get data from APIs and other remote data interfaces through scripted inputs |
This documentation applies to the following versions of Splunk® Enterprise: 6.3.0, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.3.14, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.4.11, 6.5.0, 6.5.1, 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12, 7.0.0, 7.0.1, 7.0.11, 6.3.1, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.1.0, 8.1.1, 7.0.13, 7.0.2
Feedback submitted, thanks!