Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
05-05-2014 02:21 PM
We implemented the DNS Sinkhole feature about the time 6.0 came out. I've actually had a hard time using the threat and traffic logs for incident response. We can't pinpoint which hosts are hitting what URLs or malicious domains. The threat logs show all the suspicious DNS queries that come from our DNS servers but not the hosts themselves (because the request came from the DNS server). The host details show up in the traffic logs, but of course you don't see the URL or the malicious domain in the traffic logs (just the configured Sinkhole IP address). How do I figure out where the hosts are trying to go? It seems with the way this is designed that this is not possible. We can only get the Sinkhole IP. It's become such a pain for our security team to try to track down information regrading threats to hosts they are implementing FireEye for better tracking.
This has recently become a much bigger issue for us since over the weekend our inboxes were flooded with alerts of DNS Sinkhole Alerts (traffic matching our security policy that was setup for the Sinkhole IP). Over the weekend we received hundreds of emails with these alerts. It seems as if the application and threats database was updated, possibly incorrectly, kicking off all of these alerts. That is just a guess though of course. The other fear we have is something is spreading through our network.
How do I use the sinkhole logs to track down where hosts are going to kick off these alerts? Also, any more help in understanding how to use this feature would be appreciated too. Maybe this all due to my lack of understanding it.
05-06-2014 08:43 AM
Hi,
maybe this DOC can help you to understand the new feature: New Features Guide 6.0 (English)
You can find more information about the reporting of the sinkhole feature on page 20
05-06-2014 09:00 AM
mario11584 - would you be able to build a tap interface on your PA, and tap the client traffic going to your DNS server and feed that to your PA? This is one way we have solved this problem where I work
05-06-2014 10:25 AM
I'll have to look into that some more. How do I send just the DNS traffic through the tap interface?
05-06-2014 01:50 PM
Well, that depends on what you're using to tap honestly. Are you using anything intelligent to tap, like Gigamon? We use filters in Gigamon to filter out traffic.
Would it be a bad thing if you send all the traffic to the PA tap interface, and then only configure policies on the PA side concerning DNS? I suppose if/when backups run you might peg your tap interface, but that should be at night anyway, right?
05-06-2014 02:21 PM
We don't have anything like Gigamon...yet. We're still fairly small.
We were thinking of connecting the DNS server to one of the tap interfaces on the firewall and the second tap interface to the original switch port. Essentially all DNS traffic would traverse the tap interface, but the 3020 should be able to handle that. The only problem with that would be redundancy right? We have bonded links between the switches and the DNS servers. We also have two DNS servers. Requests could be resolved by either one. I'd have to create two tap interfaces per server? That would be a little excessive I think.
The other option is to put the DNS server in a different zone and route that traffic through the firewall, forcing DNS traffic to traverse the firewall. I'm not completely fond of this idea either. But may be a better option than using 8 tap interfaces on the firewall...if that is even allowed.
It's two ports per tap right? Two bonded links per server. Two servers makes 8 tap interfaces. Is there another way to do this?
Hmmm.....my brain hurts.
08-19-2015 04:43 PM
I am testing using an internal IP that runs netsink. Netsink basically emulates DNS,HTTP, HTTPS,SMTP,SMTPS,FTP and has functionality to redirect any tcp connection to a listener which then determines which of the above protocols the request is for and emulates it.
The reason we do this is to allow for more detailed analysis of the client and the malware. Having the headers from an HTTP/S request (yes netsink will strip the SSL as it servers its own cert) or the SMTP headers improves your situational awareness around these incidents.
So far so good.
08-20-2015 12:16 AM
I think you are confusing a v-wire setup with a tap setup.
In v-wire you have: client -- vwire --- PA --- vwire --- server
Tap mode is just a mirror port. so its: client --- server and the PA is just listening to all traffic. No action can be taken. You just configure a mirror port on your switch and feed that to your PA.
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!
