FAQ » History » Version 5
Version 4 (Luke Murphey, 05/24/2018 05:50 PM) → Version 5/7 (Luke Murphey, 05/24/2018 05:58 PM)
h1. FAQ
h2. How do I audit changes to the lookup files?
The lookup editor keeps a log that is indexed into the _internal index. You can view that logs like this:
<pre>
index=_internal "Lookup edited successfully" | table _time user namespace lookup_file
</pre>
h2. My lookup file cannot be opened, why not?
Look into the logs to see if there is a reason given why the files are not loading:
<pre>
index=_internal source=*lookup_editor_controller.log
</pre>
h2. How do I enable replicating of the lookup file backups to other search heads when using a Search Head Cluster?
You can enable replication of the lookup backups by using the REST replay feature. To enable this, add the following in restmap.conf (in $SPLUNK_HOME/etc/shcluster/lookup_editor/default/restmap.conf):
<pre>
[global]
allowRestReplay = true
</pre>
This will work on Splunk 6 from (6.3+) and on Splunk 7.1+. +*However, do not enable*+ this on Splunk 7.0 (7.0 to 7.0.3) because there is a bug in Splunk 7.0 that causes REST replay to crash splunkd.
h2. What does the lookup editor app do to prevent security issues (such as directory traversal attacks)?
Directory traversal attacks are prevented by stripping path information from the lookup names. The app also relies on asking Splunk for the canonical path of the lookup file and thus doesn't assume that the user's input is valid. See https://lukemurphey.net/projects/splunk-lookup-editor/repository/entry/trunk/src/bin/lookup_editor/__init__.py#L185
XSS attacks are specifically tested for too. See the test-case here: https://github.com/LukeMurphey/splunk-lookup-test/tree/master/test/Katalon%20Test%20Cases/Lookup%20Editor/Test%20Cases/Lookup%20Edit
The app uses Splunk's APIs to edit the lookup files. Splunk sets the file permissions to read & write to the owning user and allows no other access (equivalent to "chmod 600"). The app keeps copies of lookup files (for CSV lookups) which it writes out directly. These are also written with the same permissions (equivalent to "chmod 600").
h2. How do I audit changes to the lookup files?
The lookup editor keeps a log that is indexed into the _internal index. You can view that logs like this:
<pre>
index=_internal "Lookup edited successfully" | table _time user namespace lookup_file
</pre>
h2. My lookup file cannot be opened, why not?
Look into the logs to see if there is a reason given why the files are not loading:
<pre>
index=_internal source=*lookup_editor_controller.log
</pre>
h2. How do I enable replicating of the lookup file backups to other search heads when using a Search Head Cluster?
You can enable replication of the lookup backups by using the REST replay feature. To enable this, add the following in restmap.conf (in $SPLUNK_HOME/etc/shcluster/lookup_editor/default/restmap.conf):
<pre>
[global]
allowRestReplay = true
</pre>
This will work on Splunk 6 from (6.3+) and on Splunk 7.1+. +*However, do not enable*+ this on Splunk 7.0 (7.0 to 7.0.3) because there is a bug in Splunk 7.0 that causes REST replay to crash splunkd.
h2. What does the lookup editor app do to prevent security issues (such as directory traversal attacks)?
Directory traversal attacks are prevented by stripping path information from the lookup names. The app also relies on asking Splunk for the canonical path of the lookup file and thus doesn't assume that the user's input is valid. See https://lukemurphey.net/projects/splunk-lookup-editor/repository/entry/trunk/src/bin/lookup_editor/__init__.py#L185
XSS attacks are specifically tested for too. See the test-case here: https://github.com/LukeMurphey/splunk-lookup-test/tree/master/test/Katalon%20Test%20Cases/Lookup%20Editor/Test%20Cases/Lookup%20Edit
The app uses Splunk's APIs to edit the lookup files. Splunk sets the file permissions to read & write to the owning user and allows no other access (equivalent to "chmod 600"). The app keeps copies of lookup files (for CSV lookups) which it writes out directly. These are also written with the same permissions (equivalent to "chmod 600").