# To initialize a test run and verify correct files set value to 1 # To see full before and after results per file set value to 1 Grep permission $SUF/splunkd.log | awk -F “‘” ‘’ > /tmp/splperm SUF=”/opt/splunkforwarder/var/log/splunk” # If path exist then log will be read from that location. # set set value to the path for this installation. # To run on splunkforwarder (UF) or a custom path # that need to allow the user to have read and execute access. # the /opt/splunk/var/log/splunk/splunkd.log # This script will modify the acl rights of files retrieved from If you’d like to copy and use this script, download the text version here. If the permissions already exist a message is logged with that information. Logic has been added into the script where each file is tested for existing permissions. The ideal location to run the script is from the /tmp directory and as the root user account. Test Run (additional verification step if needed).SUF=”/opt/splunkforwarder/var/log/splunk”.Splunk location (Enterprise or Universal Forwarder).Bundled into the script are a couple of options that allow setting: The script will then process the command above with the spunk user as the intended recipient of the new file permissions. The script works by reading the splunkd.log and picking out the files that have been reported with insufficient permissions. The script below is a great example that will help to alleviate the permissions concerns. To fix the file access permissions after the fact can be done with a search of the splunk.log using Splunk for the host in question or a script can be run like the one below. The setfacl command however only solves the issue if you are aware of which files needed to have their permissions modified before deploying your configuration. setfacl -m u:splunk:rx File permissions fix Individual users and/or groups can be given read, write and/or execute permissions. The command runs as root or as an authorized pseudo-user. Thankfully, the getfacl and setfacl commands are available and allow directory/file access control for file access. While that solution works, there is a large risk of causing other issues on the system. It is not uncommon to manipulate the group ownership of a file so that the non-root Splunk user can view and subsequently index its contents. The traditional fix that does not involve running the Splunk software as root is to chmod the files or directories with permissions that can be set for the owner, group, and everyone. Surprisingly, a large number of Splunk consulting engagements that I have been on have ignored this security risk. This article suggests ways to reduce the Splunk security risks associated with root access, stay in bounds on Splunk best practices, while simultaneously providing Splunk Administrators the access to the data they need access to. Due to this, best practices from Splunk Professional Services suggest not running Splunk as the root user. The drawback in doing this is that running Splunk as the root user creates a security vulnerability for these systems. Naturally, running the program as the root user will allow access to the files that are being read. This configuration alleviates the complaints that the Splunk non-root user does not have the proper permissions to access and view the data. To work around this, a common configuration in the field for Linux-based systems is where the root is configured as the user to run the Splunk system. Oftentimes, a Splunk Administrator needs correct permissions to read system logs however, by default in Linux, these permissions are not available, or only available to the one Linux superuser account. File system permissions in Linux, the suggested operating system for Splunk, can be worrisome for Splunk administrators.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |