Great learning material! Thank you for the tutorial. Does DNS Sinkhole leave any Malware trace on the source endpoint as in any files? Where it uses Palo Alto Network's Cortex XDR Agent On it and while scanning the endpoint, no items detected.
don't you need the dns security license along with threat prevention? Has this requirement recently changed? I updated to 10.x.x.x and now i get a warning every commit saying "Warning: No Valid DNS Security License"
Thanks for posting this video. Jeff, is there a chance to get the report for what malicious domain or url the host trying to connect?? or is it only host IP displayed in sinkhole concept
You could create a report in custom reports for any threat traffic with an address of the sinkhole IP. That report will show the IP, but also shows what threat signature was hit. The signature hit SHOULD tell you the domain. In the video I have a snippet of a log that shows the threat signature and it includes the domain name.
what if i am limiting my enterprise to access my internal dns only for upstream and downstream resolutions. in that case, my traffic log does show that hosts are being sinkholed. But in the Threat log, only the DNS server show up as the ones requesting dns queries to be sinkholed. Given that my DNS Server and my Users are within a zone.
Is the external DNS the suspicious one that makes the firewall alert or is it the domain you are requesting? Also why don't you just block that domain using URL filtering when the infected machine tries to connect to it after the DNS resolution or just deny traffic to that IP ? I don't understand the advantage of using DNS sinkhole instead of that
Hi Juan- It's going to be the domain I'm requesting that will alert, and will show that the connection was trying to be made to the DNS sinkhole address sourced from the compromised endpoint IP. URL filtering is definitely an option for blocking access and we will have a URL category for Malware, Phising, and Command-and-Control that will block the traffic at that point- DNS sinkholing prevents not only malicious web traffic, but other apps as well- (DNS, FTP, etc).
Why there is need of DNS sinkhole? If it is just to see the malicious source IP address , we can also see source address in traffic logs post DNS resolution.
DJ B- this is a common question. The sinkhole IP solves the issue of an endpoint resolving a malicious domain. In an enterprise network, the endpoint will query the internal DNS server. Since the internal DNS server is not likely to have the domain, the internal DNS server will query an external DNS server. This is normally the place where the firewall will see and block this malicious DNS request. If you search the traffic logs, it will appear that the source IP is the internal DNS server, not the endpoint. By responding to the DNS request with a sinkhole IP, we can then see the endpoint try to connect to the sinkhole address, and know that it's likely compromised.
Great question! I don't use DNS because the deny policy comes AFTER the victim tries to resolve a malicious domain. So, the connection to the sinkhole IP will not typically be DNS. It will likely be something like http or bittorrent for a download of malware or FTP for uploading stolen data to a command-and-control server. Since I can't predict what the traffic will be and know that ANY traffic to the sinkhole IP should be from a victim machine connecting to a malicious resource, I want to catch all of it.
Why there is need of DNS sinkhole? If it is just to see the malicious source IP address , we can also see source address in traffic logs post DNS resolution.
Great tutorial Jeff. I have implemented successfully in 20 locations and works like charm.
Excellent video Jeff. Thanks!
Great learning material! Thank you for the tutorial.
Does DNS Sinkhole leave any Malware trace on the source endpoint as in any files?
Where it uses Palo Alto Network's Cortex XDR Agent On it and while scanning the endpoint, no items detected.
Great video..very well explained..thanks
don't you need the dns security license along with threat prevention? Has this requirement recently changed? I updated to 10.x.x.x and now i get a warning every commit saying "Warning: No Valid DNS Security License"
Thanks for posting this video. Jeff, is there a chance to get the report for what malicious domain or url the host trying to connect?? or is it only host IP displayed in sinkhole concept
You could create a report in custom reports for any threat traffic with an address of the sinkhole IP. That report will show the IP, but also shows what threat signature was hit. The signature hit SHOULD tell you the domain. In the video I have a snippet of a log that shows the threat signature and it includes the domain name.
but is there a way to log the actual destination of the request?
what if i am limiting my enterprise to access my internal dns only for upstream and downstream resolutions. in that case, my traffic log does show that hosts are being sinkholed. But in the Threat log, only the DNS server show up as the ones requesting dns queries to be sinkholed. Given that my DNS Server and my Users are within a zone.
Is the external DNS the suspicious one that makes the firewall alert or is it the domain you are requesting? Also why don't you just block that domain using URL filtering when the infected machine tries to connect to it after the DNS resolution or just deny traffic to that IP ? I don't understand the advantage of using DNS sinkhole instead of that
Hi Juan- It's going to be the domain I'm requesting that will alert, and will show that the connection was trying to be made to the DNS sinkhole address sourced from the compromised endpoint IP. URL filtering is definitely an option for blocking access and we will have a URL category for Malware, Phising, and Command-and-Control that will block the traffic at that point- DNS sinkholing prevents not only malicious web traffic, but other apps as well- (DNS, FTP, etc).
Why there is need of DNS sinkhole?
If it is just to see the malicious source IP address , we can also see source address in traffic logs post DNS resolution.
DJ B- this is a common question. The sinkhole IP solves the issue of an endpoint resolving a malicious domain. In an enterprise network, the endpoint will query the internal DNS server. Since the internal DNS server is not likely to have the domain, the internal DNS server will query an external DNS server. This is normally the place where the firewall will see and block this malicious DNS request. If you search the traffic logs, it will appear that the source IP is the internal DNS server, not the endpoint. By responding to the DNS request with a sinkhole IP, we can then see the endpoint try to connect to the sinkhole address, and know that it's likely compromised.
In URL Filtering would the returned address be that of Sinkhole's.
It wouldn't be under URL filtering since they are DNS queries
Thanks Jeff
Any particular reason for not using the app, dns in the sink hole deny policy
Great question! I don't use DNS because the deny policy comes AFTER the victim tries to resolve a malicious domain. So, the connection to the sinkhole IP will not typically be DNS. It will likely be something like http or bittorrent for a download of malware or FTP for uploading stolen data to a command-and-control server. Since I can't predict what the traffic will be and know that ANY traffic to the sinkhole IP should be from a victim machine connecting to a malicious resource, I want to catch all of it.
@@jefftalkington8404 thanks, well done,👍
Why there is need of DNS sinkhole?
If it is just to see the malicious source IP address , we can also see source address in traffic logs post DNS resolution.
Best One -=EVEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEER=-