Simple File Integrity Monitoring Management Dashboard

This is the code for my original reddit post at https://www.reddit.com/r/Splunk/comments/am3tgr/simple_file_integrity_monitoring/

This dashboard allows users to manage simple File Integrity Monitoring (FIM) within Splunk. Please note that this isn’t a full FIM suite as it only validates if a checksum has been changed on a file, but I have included a simple TA for Linux. However, if you or your organization just need a simple “Has something been changed” then this should suffice. This dashboard provides the ability to modify verification hashtables and includes audit logging as well. Here are the highlights:

  • Has an audit log of any action performed within the interface
  • Auto refreshes tables when actions are completed.

  • Batch level rebasing of the verification hashtable with asynchronous modal window to prevent accidental clicks

  • Only allows updates for items that have been modified via a table usually defined mismatches

  • Filters to prevent alert fatigue

There is quite a bit of backend code for this dashboard, so I will attempt to provide all the code with explanations as well. Staring with getting data into the system.

../default/inputs.conf

../bin/fim-nix.sh

This script uses a file called watchlist.conf that is placed in the default folder of the TA. Then you just need to add the fullpath of the file you want to monitor one file per line, like this:

../default/watchlist.conf

/home/username/file1.txt
/home/username/file2.txt

That covers the TA. The output should be something similar to the following:

checksum 12345678900987654321  /home/username/file1.txt

Now for the dashboard. This dashboard uses custom JS and KVstores to assist in the integration. Remember to change <app_name> with your apps actual name.

$SPLUNK_HOME/etc/apps/<app_name>/default/data/views/fim_interface.xml

I chose to use a rex function in this design instead of using a props.conf file. Notice that in the code above I’m using an index=logs-*. I was too lazy to edit all the code, so remember to replace the index name with the actual index name you created in the TA. This is all pretty self-explanatory, the only part that may be confusing is the first few searches at the top. They are the ones that have the depends=<token_name>. They are going to be used in the JS code further down the screen. They are a part of the dashboard instead of integrated into the JS to provide better support for later changes. It’s much easier to modify a search on a dashboard then modify the search in JS. Next we will create the KVStores:

$SPLUNK_HOME/etc/apps/<app_name>/default/collections.conf

$SPLUNK_HOME/etc/apps/<app_name>/default/transforms.conf

After the KVStores have been created we can start on the actual backend code. The first part will be controlling the KVStore within the dashboard. By default, Splunk doesn’t provide a way to update or delete the items in a KVstore, so we are using JS to integrate and refresh our dashboard panels. Here is the code. Please note that the file names and locations for the rest of these files are very important.

$SPLUNK_HOME/etc/apps/<app_name>/appserver/static/fim_interface.js

This is where we start referencing the searches at the top of the dashboard view. The JS will instantiate a token that allows the update searches to run, since they depend on the token to start. Without this dependency, Splunk would run the searches everytime the dashboard loaded. Then the JS waits for the search to complete, then reloads the panels. These are all referenced by the search id field on the dashboard.

Now we need to do a little bit of decoration before we handle the much larger issue of the asynchronous modal window. I will put the JS here, but it’s just a modified version of the one that comes with the Dashboard Visualization app from Splunk. I’ll put the CSS at the end of the page so I can get all the JS out of the way first.

$SPLUNK_HOME/etc/apps/<app_name>/appserver/static/fim_decorations.js

This is the big one next. It uses a callback function that waits on the user to confirm an action before running the code. It may look like just a simple modal window, but the callback feature is really important. Since Splunk without the callback feature will just run the search without waiting. So if a user accidentally clicks the Bulk Rebase button on the dashboard it removes all the old hashes from the KVStore and redefines new ones. This could be an expensive operation depending on your environment. Here is the first JS file

$SPLUNK_HOME/etc/apps/<app_name>/appserver/static/fim_modal.js

Like the other JS script we are setting a token and then updating the searches. However, this file includes a reference to another components file. This is because we want to create a template for how the modal window will look using backbone.js. This HTML in the template of the next file will get automatically inserted into the Splunk dashboard when the button is clicked. You will need to modify the <app_name> tag in this script to match your apps name as well.

$SPLUNK_HOME/etc/apps/<app_name>/appserver/static/components/modalview.js

Almost done. Now we just need a little bit of styling to make everything look nice.

$SPLUNK_HOME/etc/apps/<app_name>/appserver/static/fim_decorations.css

Nothing fancy here. Just pulled it from the Dashboard Visualization app from Splunk. Can’t remember if I even modified it at all. And that’s it. You should now be able to view and modify a verification table of hashes and get provide audit resources.

Sorry. I know this was a long one. So if you need additional info let me know.

Share This:

Leave A Comment?