Looking at the REST API logs in splunkd_access.log or the audittrail isn't going to tell you that as far as I can see, for that Splunkweb is just another REST client.
However, you may be able to detect Splunkweb logins by correlating webaccess.log with splunkdaccess.log, and use the inverse of this for detecting non-Splunkweb REST clients. Here's what a login through Splunkweb looks like (localhost, 5.0.1):
web_access.log: 127.0.0.1 - admin [25/Dec/2013:23:27:35.276 Mitteleurop\xe4ische Zeit] "POST /en-US/account/login HTTP/1.1" 303 95 "http://localhost:8000/en-US/account/login?return_to=%2Fen-US%2F" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0" - snipped 77ms splunkd_access.log: 127.0.0.1 - - [25/Dec/2013:23:27:35.322 +0100] "POST /services/auth/login HTTP/1.1" 200 238 - - - 2ms splunkd_access.log: 127.0.0.1 - admin [25/Dec/2013:23:27:35.328 +0100] "GET /services/authentication/users/admin HTTP/1.1" 200 4577 - - - 4ms
These three events should be
transaction-able on the IP and the time. If there's just the splnukd_access.log login then you're likely looking at a non-Splunkweb REST client.
The rest endpoint access is logged via the splunkd_access.log
Look for IP addresses that are NOT 127.0.0.1 and those will be the ones where the users hit the REST endpoints from an external server.
You can search API based access to the search heads using the following search:
index=_internal sourcetype=splunkd_access host= NOT ( user="splunk-system-user" OR user="-") NOT clientip="127.0.0.1" NOT clientip IN()
GUI traffic all comes from localhost on the search heads, and any other splunk related traffic (deployer, cluster-master, dmc) will use the splunk-system-user username. Anything with a username of “-“ is unauthenticated and will be blocked or part of the login flow. The only edge case is when search heads are clustered and they proxy requests for jobs that have already been run. The job requests themselves have an “isProxyRequest” query string field that we can filter on, but you may also need to filter out anything coming from IPs of the other search heads in the cluster. Everything else will be authenticated API traffic. You can then analyze the URLs to see if they are running searches or taking other administrative actions. Requests with a POST method are taking action against the API, like running a search or editing a config If you want to see the actual searches that are being run, you can pull out the search ids from the URLs and search for them in the audit logs.
index=_internal sourcetype=splunkd_access host=<search_head_hosts> NOT ( user="splunk-system-user" OR user="-") NOT clientip="127.0.0.1" NOT clientip IN(<shc_ips>) | rex field=uri_path "search/jobs/(?<search_id>[^/\?]+)" | eval search_id="'"+coalesce(search_id,id)+"'" | stats count by search_id | eval isAPIsearch="True" | outputlookup api_searches.csv
index=_audit action=search (info=granted search=*) OR info=completed | lookup api_searches.csv search_id | search isAPIsearch="True" | stats earliest(_time) AS _time, values(user) AS user, values(host) AS search_head, values(search) AS search, values(event_count) AS event_count, values(result_count) AS result_count, values(total_run_time) AS total_run_time by search_id
Hope that helps.