Sinkhole Feature Trouble

Reply
Highlighted
L4 Transporter

Sinkhole Feature Trouble

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.

L3 Networker

Re: Sinkhole Feature Trouble

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

L4 Transporter

Re: Sinkhole Feature Trouble

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

L4 Transporter

Re: Sinkhole Feature Trouble

I'll have to look into that some more. How do I send just the DNS traffic through the tap interface?

L4 Transporter

Re: Sinkhole Feature Trouble

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?

L4 Transporter

Re: Sinkhole Feature Trouble

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.

L1 Bithead

Re: Sinkhole Feature Trouble

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.

L4 Transporter

Re: Sinkhole Feature Trouble

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.

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 Live Community as a whole!

The Live Community thanks you for your participation!