topic Re: Best practice for reducing Log ingestion for DNS traffic logs to 3rd party log servers in General Topics

Best practice for reducing Log ingestion for DNS traffic logs to 3rd party log servers

PA_nts — Tue, 23 Jan 2024 07:30:26 GMT

Hi All,

Need some opinions please..

I have a client who wants to ingest their PAN logs (panorama managed) into Sentinel.
However looking at the log data we will be ingesting around 40-50GB of log traffic per day which from a costing perspective is going to be super expensive.

Dissecting the log data I can see majority of log data are Traffic logs, and that DNS logs within traffic logs, (app = dns-base) are making up around 55% of all traffic log data. We do not have a DNS security license. so essentially 55% of all logs to sentinel will be dns logs.

What is your view on me suggesting the following:

To exclude the DNS logs from being sent to Sentinel Log Collector (still logged on Panorama though)
This will be done by doing a filter for Traffic Type logs and using the following filter expression ' no (app eq dns-base) '
This means that the DNS logs will still be visible in Panorama but will not be forwarded towards the Sentinel Log Collector and greatly reduce the amount of log ingestion into Sentinel.

My other question, if i do this, to what extent am i limiting my security layer on sentinel? On my FWs, the app/threat and url filtering (licensed) will still alert on dodgy DNS requests and this will be sent to the Sentinel Collection via the Threat type logs - correct?

Just need clarification so that we can say any 'alerts' triggered by PAN that are DNS related will still be ingested into Sentinel.

Alternatively, Is there a best practice guide for configuring dns logging (no dns security license) in this instance? (i cannot seem to find anything that matches my end goal)
How are your setups doing this with reducing dns log volume.

Any thoughts?

thanks in adv

Re: Best practice for reducing Log ingestion for DNS traffic logs to 3rd party log servers

OtakarKlier — Tue, 23 Jan 2024 22:18:32 GMT

Hello,

DNS logs are pretty handy when it comes to incident response. Each packet is usually less than 1kb, so not sure if that is 55% of your traffic? If it is, it could be data exfiltration via DNS? Definitely something to look into.

Regards,

Re: Best practice for reducing Log ingestion for DNS traffic logs to 3rd party log servers

PA_nts — Wed, 24 Jan 2024 07:17:44 GMT

Hi, I don't think it is data exfiltration via DNS.. we have around 20M DNS log events per day (big environment). and log size according to PAN per event on average is about 1500bytes. so it amounts to alot of DNS log traffic. I will try and see who the top talkers are on DNS (src/dest) and try and limit that way instead.. but the crux of the matter is, client will have to exempt some logs in order to minimize log storage issues. its a work in progress. thanks

Re: Best practice for reducing Log ingestion for DNS traffic logs to 3rd party log servers

PavelK — Wed, 31 Jan 2024 12:55:06 GMT

Hello @PA_nts

possibly your client could consider to store DNS logs in Azure ADX. ADX can store a large volume of logs and is cheaper than Sentinel. With necessary permissions it is possible to query ADX logs directly from Sentinel.

In this scenario all logs would be sent from Panorama to Sentinel except of DNS logs that would be sent to ADX. In the case of incident investigation ADX logs could be accessed from single Sentinel console.

Kind Regards

Pavel

Re: Best practice for reducing Log ingestion for DNS traffic logs to 3rd party log servers

PA_nts — Wed, 31 Jan 2024 14:23:19 GMT

thanks.. in the end we will be filtering out internal dns logs towards sentinel using filters on the syslog traffic. The dns logs will still be visible on panorama (30 day retention) and ngfw should still alert on dodgy dns traffic and this will be sent to sentinel via the threat type logs.