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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

L3 Networker

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

4 REPLIES 4

Cyber Elite
Cyber Elite

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,

L3 Networker

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

Cyber Elite
Cyber Elite

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

Help the community: Like helpful comments and mark solutions.

L3 Networker

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.

  • 1599 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!