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
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.
What about creating a new VSYS on your PA device and attach 2 interfaces to it which you configure as VWIRE and then plug that between your DNS and the rest of the network?
Oh and in this VSYS configure it only for alterting to not disturb the flows (that is unless you wish to block the queries with the help of the PA).
Mikand: I know that VWIRE is better (easier) than SPAN port on switch.
At the moment I have a lot of things to do and I haven't time for it.
I have PA200 and I'm not sure that I can create second VSYS, and I'm sure that I ran out of free Security zones (I have used 10 at the moment).
But if you can help me on priv (I 'm alsomst newbe in PAN) we can do it.
At the moment I isolated problem. This suspicius reguest comes from my WiFi networks, so its mean that from private users computers. Thats good for me
You'll have to enable dns debug file on your dns server to get the level of detail you need to find the sources of the dns requests.
Here's how; (Warning: Microsoft recommends only keeping dns debug captures enabled temporarily)
1. Login to server
2. Open dnsmgmt - (Administrative tools -> DNS)
3. Right Click on your server object and select properties
4. Select Debug Logging
5. Put check mark on;
Packet Direction [Outgoing and Incoming]
Packet Contents [ Queries/Transfer]
Transfer Protocol [UDP/TCP]
Packet type [Request/Response]
6. Choose where you want the debug file created and make sure you have enough space to hold the files.
7. Select OK
Now just go into the threat log of Palo Alto, find the dns name ie. google then search [Ctrl+F] for that URL in the dns debug file . Make sure to only search for the URL without the suffix at the end. (example: google.com - only look for google as the dns debug format substitutes dots for a format like "(6)" .)
That is the quick and dirty way to find it. If you have hundreds of entries from multiple sources, you will need to create a script. I wrote a VB script for this very purpose to find Conficker infected hosts on my network. It's 100% accurate. If anyone wants a copy, reply back to me and I can post the code.
Just to say I found this thread really beneficial. We only allow our AD servers to do outbound DNS queries and it never occurred to me that spyware signatures would check DNS traffic - enabled it and cleared the DNS server caches and sure enough had a ping for a nice piece of webwebgo crapware
use the dns sinkhole feature in 6.0 this is what its meant for.
user makes dns request , dns server performs look up, palo alto picks this up via dns signature then returns sink hole ip . User then tries to connect to the sinkhole ip and its will get recorded in the traffic logs as such.
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!