Since I upgraded to 5.0.3 from 4.1.10 I started getting such entry in Treat log:
Suspicious DNS Query (Backdoor.rshot:app.pou.me) 4009473 spyware medium drop-all-packets 74
Suspicious DNS Query (Downloader.fik:encyklopedia.eduteka.pl) 4008620 spyware medium drop-all-packets 31
Suspicious DNS Query (generic:stor1173.uploaded.net) 4014899 spyware medium drop-all-packets 26
Bot: Torpig Phone Home DNS request 12657 spyware medium drop-all-packets 276
Suspicious DNS Query (generic:www.tns-counter.ru) 4000032 spyware medium drop-all-packets 40
It's pointing to my two DNS servers for my local networks. I'm almost sure that this isnt a problem with this servers because last week was Eastern Christmas and during this time I never got such traffic. When my users back to work its started again.
Some of user's computers are in the same Zone as this two DNS servers. How in this case catch sources of this traffic?
For other network I will enable strict Tread profile on allow DNS traffic rules, I hope that this will give me information about real sources of this dns requests.
Having your DNS server logs forwarded to a centralized location such as a log collector appliance or SIEM, or having full packet captures to an appliance (or both!) are two things that are essential in my mind for being able to effectively research events like these.
Here are two suggested ways of doing this "on the cheap" (the only cost is hardware and time essentially)
For the log collector/SIEM, an open source solution I can recommended is ELSA: enterprise-log-search-and-archive - Enterprise log search and archive (ELSA) is an industrial-stren...
"ELSA is a centralized syslog framework built on Syslog-NG, MySQL, and Sphinx full-text search. It provides a fully asynchronous web-based query interface that normalizes logs and makes searching billions of them for arbitrary strings as easy as searching the web. It also includes tools for assigning permissions for viewing the logs as well as email based alerts, scheduled queries, and graphing."
For an open source full packet capture solution, I've read about openfpc: openfpc - Open Full Packet Capture - Google Project Hosting
"OpenFPC is a set of scripts that combine to provide a lightweight full-packet network traffic recorder & buffering tool. It's design goal is to allow non-expert users to deploy a distributed network traffic recorder on COTS hardware while integrating into existing alert and log tools."
If the Palo Alto only saw the request from the DNS server out to the Internet and alerts on that traffic, wouldn't that still not provide enough info to track down the original client?
If you added a mirrored switch port of your LAN side network trwffic to a tap port on the PA, then the original client could be seen. Also if you segregated your DNS server from your clients into two separate VLANs and used the PA to route between them, you'd see the original traffic that way too.
Full packet capture / centralized logging is still the overall 'best practice' in my humble opinion :smileyhappy:
We are dealing with this issue now and we may not have access to DNS logs and we have a distributed DNS structure with an internal root DNS. The root dns server may only be forwarding a request drom one of our distributed dns servers. What we are looking is creating FQDN based objects for the DNS entries identified by PA and then putting those objects in a rule to block non DNS traffic. This will identify the probable comprimised hosts.
>If the Palo Alto only saw the request from the DNS server out to the Internet and alerts on that traffic, wouldn't that still not provide enough info to track down the original client?
not, because klient and dns server are in the same security zone. That is my problem. Rest of my networks are separated, that one no.
I came up with idea: put on every policy from separated network security profile that will block such traffic. After that if I will have in logs warnings about thats mean that problem is from this one zone with DNS servers on it.
I also preparing for Splunk instalation. That could help me now and in the future.
Thank you for your help
I ran into similar situation with conficker spyware. The option is to enable logging on the DNS server to find out the original client. That is usually not possible due to high volume of logs. The other option is to SPAN/mirror your DNS server port and configure TAP on PAN. I have this configuration running in my network and it provides you with the real client ip address.
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!