NXLog User Guide
- OS Support
- Enterprise Edition Reference Manual
- 146. Man Pages
- 147. Configuration
- 148. Language
- 149. Extension Modules
- 150. Input Modules
- 150.1. Process accounting (im_acct)
- 150.2. AIX auditing (im_aixaudit)
- 150.3. Azure (im_azure)
- 150.4. Batched compression (im_batchcompress)
- 150.5. Basic Security Module Auditing (im_bsm)
- 150.6. Check Point OPSEC LEA (im_checkpoint)
- 150.7. DBI (im_dbi)
- 150.8. Event Tracing for Windows (im_etw)
- 150.9. External programs (im_exec)
- 150.10. File (im_file)
- 150.11. File integrity monitoring (im_fim)
- 150.12. Go (im_go)
- 150.13. HTTP(s) (im_http)
- 150.14. Internal (im_internal)
- 150.15. Java (im_java)
- 150.16. Kafka (im_kafka)
- 150.17. Kernel (im_kernel)
- 150.18. Linux Audit System (im_linuxaudit)
- 150.19. macOS Endpoint Security (im_maces)
- 150.20. macOS ULS (im_maculs)
- 150.21. Mark (im_mark)
- 150.22. Event Logging for Windows XP/2000/2003 (im_mseventlog)
- 150.23. Event log for Windows 2008/Vista and later (im_msvistalog)
- 150.24. Null (im_null)
- 150.25. ODBC (im_odbc)
- 150.26. Packet capture (im_pcap)
- 150.27. Perl (im_perl)
- 150.28. Named pipes (im_pipe)
- 150.29. Python (im_python)
- 150.30. Redis (im_redis)
- 150.31. Windows Registry Monitoring (im_regmon)
- 150.32. Ruby (im_ruby)
- 150.33. TLS/SSL (im_ssl)
- 150.34. Systemd (im_systemd)
- 150.35. TCP (im_tcp)
- 150.36. Test Generator (im_testgen)
- 150.37. UDP (im_udp)
- 150.38. Unix domain sockets (im_uds)
- 150.39. Windows Performance Counters (im_winperfcount)
- 150.40. Windows Event Collector (im_wseventing)
- 150.41. ZeroMQ (im_zmq)
- 151. Processor Modules
- 152. Output Modules
- NXLog Manager
- NXLog Add-Ons
This module is capable of scanning files and directories and reporting detected changes and deletions. On the first scan, the checksum of each file is recorded. This checksum is then compared to the checksum value calculated during successive scans. The im_fim module works on the filesystem level, so it only has access to file information such as ownership and last modification date, and no information about which user made a change.
|To examine the supported platforms, see the list of installer packages in the Available Modules chapter.|
Files are checked periodically, not in real-time. If there are multiple changes between two scans, only the cumulative effect is logged. For example, if one user modifies a file and another user reverts the changes before the next scan occurs, only the change in modification time is detected.
For real-time monitoring, auditing must be enabled on the host operating system. See the File Integrity Monitoring chapter in the User Guide for more information.
This specifies the digest method (hash function) to be used to calculate the checksum. The default is
sha1. The following message digest methods can be used:
This directive can specify a file or a set of files (using wildcards) to be excluded from the scan. More than one occurrence of the Exclude directive can be specified.
This directive can be used to specify an upper file size limit, in bytes. The checksum calculation will be skipped for files that exceed this limit, and changes will only be reported based on the file name and attributes.
This boolean directive specifies whether the backslash (
\) in file paths should be disabled as an escape sequence. By default, NoEscape is FALSE (the path separator on Windows needs to be escaped).
If set to TRUE, this boolean directive specifies that files set with the File directive should be searched recursively under sub-directories. For example,
/var/log/apache2/error.log. Wildcards can be used in combination with Recursive:
/var/log/apache2/access.log. This directive only causes scanning under the given path and does not affect the processing of wildcarded directories:
/var/*/qemu/debian.logwill not match
/var/log/libvirt/qemu/debian.log. The default is FALSE.
This directive specifies how long the module will wait between scans for modifications, in seconds. The default is 86400 seconds (1 day). The value of ScanInterval can be set to
0to disable periodic scanning and instead invoke scans via the start_scan() procedure.
The following functions are exported by im_fim.
Returns TRUE if scanning is in progress.
The following procedures are exported by im_fim.
Start the file integrity scan. This could be invoked from the Schedule block, for example.
The following fields are used by im_fim.
A list of event fields in key-value pairs.
The calculated digest (checksum) value.
The name of the digest used to calculate the checksum value (for example,
The time when the modification was detected.
One of the following values:
The name of the file that the changes were detected on.
The size of the file in bytes after the modification.
The name of the originating computer.
The modification time (mtime) of the file when the change is detected.
One of the following values:
The calculated digest (checksum) value from the previous scan.
The name of the file from the previous scan.
The size of the file in bytes from the previous scan.
The modification time (mtime) of the file from the previous scan.
The severity name:
The WARNING severity level value:
With this configuration, NXLog will monitor the specified directories recursively. Scans will occur hourly.
The im_fim module provides a start_scan() procedure that can be called to invoke the scan. The following configuration sets ScanInterval to zero to disable periodic scanning and uses a Schedule block instead to trigger the scan every day at midnight.