DNS Sinkhole - working or not?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

DNS Sinkhole - working or not?

L1 Bithead

I have followed the configuration guide for setting up dns sinkhole but i am not seeing the expected output in the logs.

 

My configuration is as follows:-

Client sits on a zone 'mplstrust' (internal LAN)

Internal DNS Server sits on zone 'dnstrust' (internal LAN but different subnet to mplstrust zone)

We have subscribed to Dynamic Updates for Spyware (not AntiVirus).

New AV Spyware profile created (PA sinkhole external IP configured with action set to sinkhole)) and applied on rule 'mplstrust to untrust' (inbound to outbound)

 

To test sinkhole, I am performing an nslookup from a client on the 'mplstrust' subnet to a 'suspicious dns query' contained in the release notes of the latest spyware updates (spyware release 2533-3029). 

 

When I search in the threat logs I can see the source IP address of the client with an action of sinkhole, however I cannot see the sinkhole IP address anywhere in either the traffic logs or the threat logs. Is this to be expected?

 

As a 2nd test I configured the client with an external 8.8.8.8 dns server entry and created a new zone on the FW with outbound access. Using the same spyware release (dated today), I performed an nslookup to around 10 suspicious dns queries. Only 1 of the 10 queries returned the sinkhole IP address in nslookup. I would have expected all 10 nslookup queries to return the same output - the sinkhole IP.

 

Can anyone please suggest where I am going wrong!

1 accepted solution

Accepted Solutions

The policy action is your choice: drop will silently discard, deny will send a RST and allow will let the traffic pass (it will be discarded by the sinkhole IP), byt allowing it allows further forensics if that is of itnerest to you (the traffic can be scanned for more threats, packetcapturs etc.)

 

No if your client tries to start a web session to a malicious host, your client will first perform a dns lookup to determine the ip to connect to, and will receive a false (sinkhole) IP. the browser will then continue setting up it's connection to the sinklhole IP instead of the infected remote host, there's no icmp in that scenario

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

View solution in original post

6 REPLIES 6

L4 Transporter

Do you have a security rule that denies access to the sinkhole IP address, with logging enabled? If so, you should be seing it in the traffic log.

We have the sinkhole definition in our AS profile that's connected to outgoing security policies. There is a separate security policy that denies traffic to the sinkhole destination. I can search on the destination address of the sinkhole and it shows data in the traffic log.

Cyber Elite
Cyber Elite

your nslookup will not show any connections to the sinkhole IP because you don't make a connection to it, you did a DNS lookup and got a 'poisoned' reply

 

if you were to ping a malware host, your system would first perform a dns lookup to get the ip, this would trip the sinkhole and your client would get a false IP for the lookup and would then go and send out ICMP packets to the false IP addres

 

the sinkhole profile should be enabled on policies that process your DNS lookups: mplstrust to dnstrust and/or dnstrust to untrust

the sinkhole IP block (or allow for logging,..) policy should be set how the traffic woiuld logically flow to the internet: mplstrust to untrust

 

sinkhole example.png

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Thanks Reaper

 

The spyware profile is only applied to the outbound traffic policy mplstrust (client) to untrust.

I havent applied the spyware on the trust to untrust (the dns server sits in the trust zone) - i will try that.

 

Above the outbound traffic policy is a policy to 'deny' the sinkhole ip with 'log at session end' checked. Is the action 'deny' correct, or should it be configured to block? I dont understand your comment suggesting 'allow (for logging)' ?

 

If a client tries to open a web session to a malicious url in the 'suspicious dns signatures' list, i would expect the sinkhole ip to be returned to the client forcing the client to then generate icmp packets towards the sinkhole ip and this be captured in the logs?

 

 

Hi

 

Yes I have a deny rule set to logging.

The policy action is your choice: drop will silently discard, deny will send a RST and allow will let the traffic pass (it will be discarded by the sinkhole IP), byt allowing it allows further forensics if that is of itnerest to you (the traffic can be scanned for more threats, packetcapturs etc.)

 

No if your client tries to start a web session to a malicious host, your client will first perform a dns lookup to determine the ip to connect to, and will receive a false (sinkhole) IP. the browser will then continue setting up it's connection to the sinklhole IP instead of the infected remote host, there's no icmp in that scenario

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

That makes sense - thank you

  • 1 accepted solution
  • 4281 Views
  • 6 replies
  • 0 Likes
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 LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!