Securing Client side logging using HTTP Event Collector

[aliyusuf]

I am sending client side logs (browser logs) to Splunk. I have setup an HTTP Event Collector (HEC) where I am sending the log events using splunk-bunyan-logger. Everything works fine with this setup. I am able to send the logs from my web page to this HEC which eventually ends up on our Splunk index.

One major concern we have is putting the HEC token in the client code. splunk-bunyan-logger requires an HEC token and URL to send log events to HEC. Anyone knowing this token and URL can send random requests on our HEC or DDoS it since its endpoint will be open on the internet. Is there any solution built around it? Or is it considered safe in the Splunk community to use HEC token in the client code? I need suggestions on this if anyone has already implemented client side logging using Splunk.

[akshatj2]

Hi @aliyusuf,

were you able to get the issue resolved. We have a similar requirement.

[johntron]

Disclaimer: I know very little about Splunk, but I do know a little about general security practices.

In general, any kind of client-side authentication is considered a very weak form of security to deter only the most basic attackers. I'm not sure what other privileges the HEC token provides, but it shouldn't grant access to anything other than client-side logging.

You should assume attackers already have client-side tokens (they do) and treat them simply as a way to associate your log messages with your account. With that assumption, the next concern is preventing attacks against your logging endpoint.

Since messages are not stored on your webserver, your app can't be taken down by a DoS aimed at filling up disk space. That means you just need to ensure your app doesn't hang if the logging endpoint is in an unhealthy state. Another thing to consider is that log messages should all be considered untrusted - attackers can send false information if they really just want to wait your time.

I hope somebody else has a better answer...