This was my issue. Thanks for this! ... View more

Chrome 83.0.4103.97 appears to fix this. ... View more

I can confirm Chrome 83.0.4103.97 fixes this issue for me. ... View more

Yes I can confirm this occurs only when my search head is using SSL. We also have reports of some users having issues with Firefox as well, but they're more intermittent. ... View more

Tried upgrading to Chrome 84 (beta). Issue still present. ... View more

Thank you for your investigation! ... View more

The entire file will be indexed each time the input runs. ... View more

The input reads in the complete file each time. ... View more

Ah, good catch. A minor change changed the domaintools command to output as a statistics table as opposed to events, and this dashboard is expecting events. This too will be fixed in the next version of the app. If you'd like to quickly fix it yourself, click "edit" on the top right of the dashboard, then change the visualization type of that panel from "Events" to "Statistics Table". Here is a screenshot for reference: ... View more

Thanks. This helped a lot. ... View more

Thank you. That helped me nail down the bug specifically. It appears that while all of the API code respects proxy settings, the tldextract module does not when it makes an initial request to cache a list of TLDs. This bug will be resolved and fixed as soon as possible. In the meantime, you should be able to fix the problem by doing the following: Download this file: https://raw.githubusercontent.com/john-kurkowski/tldextract/master/tldextract/.tld_set_snapshot Place .tld_set_snapshot in /opt/splunk/etc/apps/TA-domaintools/bin/tldextract/ Let me know if that fixes it. Thanks for your patience on this. ... View more

Could you specify which pages/panels are giving JSON errors, as well as include the JSON errors themselves? I just set up a local proxy server and can confirm that each dashboard is working and going through the proxy to do it. As far as the documentation for Splunk, this is directly related to the behavior of Python Requests module (python-requests.org) and how it handles proxies. From my tests, if the URL schema is 'http' it will look at the HTTP_PROXY variable, and for 'https' it looks for HTTPS_PROXY. I don't think this is how the environment variables were intended to work, but that's how Requests handles them. ... View more

From my testing, HTTPS_PROXY is used while HTTP_PROXY is ignored. Since the requests made are all using HTTPS, it looks like the HTTPS_PROXY variable needs to be set. Could you try setting that as well and see if it fixes your issue? Thanks. ... View more

Just to clarify, you mean that you have HTTP_PROXY/HTTPS_PROXY set in splunk-launch.conf? The app should respect those environment variables. I will look into if there is something preventing that from happening. ... View more

Hi, I know this is late but I just wanted to share how I solved this myself. I used requests as jkat54 suggested, but used a session key rather than a hardcoded username and password. Because this is a modular input, the session key is passed in as part of the config XML - this can be seen here: http://docs.splunk.com/Documentation/Splunk/latest/AdvancedDev/ModInputsScripts So I modified the part of my input which parsed the config out of that XML and added a section that pulls the session key out. From there you can just add it as a header to your request: r = requests.post(uri, headers={'Authorization': 'Splunk %s' % sessionKey}, data={'name':'mySearch','value':'Hey ALL!','severity':'warn'}, verify=False) ... View more

Apologies, but I am still looking into this. I've found some unrelated bugs with the Nessus app but have been unable to recreate this one so far. ... View more

Hi Matt. Are you using our addon for Nessus, or another app for pulling data out of your Nessus scanner? Additionally, what version of Nessus is your scanner running? ... View more

Is the severity field "informational" in all of your Nessus scan results? The Hurricane Labs App for Vulnerability Management doesn't display informational scan results in its dashboards. ... View more

Apologies, I meant sourcetype=nessus_vuln, not index=nessus. Are the events in that sourcetype scan results? ... View more

Try running an all-time search over sourcetype=nessus_vuln. Do you see any events? If the dashboards are empty, that probably means you have no indexed scan data. Note: The user account that Splunk is using to log in to your Nessus scanner must be the same user that ran the scans. EDIT: Sorry, I wrote index=nessus instead of sourcetype=nessus_vuln ... View more

Would you mind if we continued this over e-mail? It appears this comment chain has gotten so long that replies are no longer displaying. cschmidt@hurricanelabs.com ... View more