Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add recursive watches to file integrity module #5421

Closed
andrewkroh opened this issue Oct 23, 2017 · 8 comments
Closed

Add recursive watches to file integrity module #5421

andrewkroh opened this issue Oct 23, 2017 · 8 comments

Comments

@andrewkroh
Copy link
Member

The file integrity module currently supports watching individual directories and does not recursively watch sub-directories. To add support for recursive watches while still maintaining the ability to detect changes in near real-time we need notifications from the OS that work recursively (see how it works for background info).

So for the various operating systems this means

  • Windows - ReadDirectoryChangesW already natively supports recursive monitoring. The feature is not exposed through fsnotify (watchSubtree is hard-coded to false). Hopefully a small change can be made to fsnotify to expose this feature.
  • macOS (Darwin) - We use kqueue now which doesn't have support for recursive watches. But we can switch to using FSEvents which does support recursive watches. Plus it doesn't use as many file descriptors. One important thing to note is that multiple changes can be coalesced into a single notification (more details in this blog) and changes will be needed to account for this.
  • Linux - inotify doesn't support recursive watches so we will need to implement this ourselves by adding and removing watches manually for sub-dirs.

Configuration

We can add a new configuration option like file.recursive to enable recursive watches.

- module: audit
  metricsets: [file]
  file.paths:
  - /etc
  file.recursive: true

Implementation

I would prefer to have these changes made incrementally for each operating system (e.g. one or more PR's per OS) in order to keep the changes managible from a review and testing perspective.

@andrewkroh andrewkroh mentioned this issue Oct 24, 2017
9 tasks
@adriansr adriansr self-assigned this Nov 7, 2017
adriansr added a commit to adriansr/beats that referenced this issue Nov 23, 2017
This patch adds a new file monitoring to the integrity module that
uses the FSEvents facility from macOS. Uses fsnotify's implementation
of fsevents library. Non-recursive behavior is emulated by filtering events.
adriansr added a commit to adriansr/beats that referenced this issue Nov 25, 2017
This patch adds a new file monitoring to the integrity module that
uses the FSEvents facility from macOS. Uses fsnotify's implementation
of fsevents library. Non-recursive behavior is emulated by filtering events.
andrewkroh pushed a commit that referenced this issue Nov 28, 2017
* auditbeat: macOS recursive file monitoring (#5421)

This patch adds a new file monitoring to the integrity module that
uses the FSEvents facility from macOS. Uses fsnotify's implementation
of fsevents library. Non-recursive behavior is emulated by filtering events.

* Use os.SameFile instead of comparing inodes

* Persist Action as a bit mask
@andrewkroh
Copy link
Member Author

andrewkroh commented Dec 18, 2017

This is implemented for Linux, macOS, and Windows now.

We can possibly optimize Windows more if we use ReadDirectoryChangesW with the watchSubtree flag. But we would need to do some measurements to see how the current version compares the the proposed version.

@jakommo
Copy link
Contributor

jakommo commented Dec 18, 2017

Awesome, which version will this be in. 6.2?

@andrewkroh
Copy link
Member Author

Yes, expect a 6.2 release for this feature.

@hmnguyen1201
Copy link

Thank you for adding this feature. It is great. I am also curious to know if there is an option to allow recursive on selected directories instead of everything?

@andrewkroh
Copy link
Member Author

There are include_files and exclude_files options. See https://www.elastic.co/guide/en/beats/auditbeat/7.x/auditbeat-module-file_integrity.html.

@hmnguyen1201
Copy link

Yep, I love those settings too but sometimes it would be just much easier to be able to tell auditbeat to be recursive on certain filepaths

@andrewkroh
Copy link
Member Author

andrewkroh commented Mar 4, 2020

I think you could split the config up into two separate modules one with recursion enabled and one with it disabled and set the paths between the two accordingly.

auditbeat.modules:
- module: file_integrity
  paths: [/c, /d]
  recursive: true
- module: file_integrity
  paths: [/a/b]
  recursive: false

@hmnguyen1201
Copy link

Thank you. This is great. It gives me a pretty good idea of what I can do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants