Hello,
I'm wondering if we can send the PaloAlto firewall logs to splunk *cloud* via HEC? We've done that once when evaluating other SIEM solution (crowd-strike NG-SIEM).
As to splunk, the documents I can find in Internet all recommend using this flow: PaloAlto -> syslog-ng+universal forwarder -> splunk cloud.
Does anyone know why HEC is not a preferred option in this case? any potential issue here?
Regards,
Iris
Theoretically, you could set up forwarding logs to HEC endpoint by defining proper destination and message template.
But.
As Palo themselves write on their docs page - "Log forwarding to an HTTP server is designed for log forwarding at low frequencies and is not recommend for deployments with a high volume of log forwarding. You may experience log loss when forwarding to an HTTP server if your deployment generate a high volume of logs that need to be forwarded."
Which actually makes sense since it seems Palo will emit a separate HTTP request for each event which might flood your receiver in case of - for example - traffic logs. (and I'm not sure how well it does with keepalives and reusing connections). It doesn't seem to be able to aggregate multiple events into a single request.
So it is indeed a typical approach to send events via syslog to any reasonable modern syslog daemon (either rsyslog or syslog-ng) and handle it there. They can either write them to file which will be picked up by UF or can aggregate them (at least rsyslog can, I'm not that good with syslog-ng but I suppose it does as well) into bigger batches and send much lower number of requests to destination HEC endpoint (like a single HTTP request for every 100 events to send). Of course you have much more flexibility in processing data in-transit if you use an intermediate syslog daemon.
Thanks @PickleRick for the detailed explanation! it's very helpful 🙂
Theoretically, you could set up forwarding logs to HEC endpoint by defining proper destination and message template.
But.
As Palo themselves write on their docs page - "Log forwarding to an HTTP server is designed for log forwarding at low frequencies and is not recommend for deployments with a high volume of log forwarding. You may experience log loss when forwarding to an HTTP server if your deployment generate a high volume of logs that need to be forwarded."
Which actually makes sense since it seems Palo will emit a separate HTTP request for each event which might flood your receiver in case of - for example - traffic logs. (and I'm not sure how well it does with keepalives and reusing connections). It doesn't seem to be able to aggregate multiple events into a single request.
So it is indeed a typical approach to send events via syslog to any reasonable modern syslog daemon (either rsyslog or syslog-ng) and handle it there. They can either write them to file which will be picked up by UF or can aggregate them (at least rsyslog can, I'm not that good with syslog-ng but I suppose it does as well) into bigger batches and send much lower number of requests to destination HEC endpoint (like a single HTTP request for every 100 events to send). Of course you have much more flexibility in processing data in-transit if you use an intermediate syslog daemon.