DNS Trap

[Mikel_Aanstoot]

Hello, I have configured DNS trap, first in R77.30 and we have now R80.10, according to sk74060. Also added an internal DNS server for better identification. We see some internal DNS trap alerts coming from internal DNS server. We cannot identify the real client who is actually making the DNS request. I think we have to correlate ourselves from DNS log from the internal DNS server ?

But we also see that the external IP address we are using for DNS trap is attracting a lot, a very lot, of external IP addresses trying to access this IP address on almost every port. Far more than the other external IP addresses in use. Can someone explain ? I hope not that the DNS Trap IP address is in some way now also an external attraction ? Can someone explain this a bit more indepth ?

Thanks and kind regards,

Mikel

[PhoneBoy]

The DNS Trap will only be effective if the Security Gateway is between the client and DNS server.

Otherwise, you'll just see the DNS server making the requests, which won't be terribly useful.

It's meant for internal hosts (not external ones) and the Trap IP should be a private IP address not in use in your network anywhere. 

This means even if external hosts get the Trap IP somehow, the traffic would never route to your Security Gateway from the outside.

[D_W]

I have the same issue that our internal DNS are shown. Is there a description how to configure this so that only the clients are falling into the trap?

[PhoneBoy]

It's basically two things:

1. A security gateway must be between the DNS Client and the DNS Server (otherwise, you'll just see the DNS server making requests)

2. You should configure the internal DNS servers in the Threat Prevention profile.

[SantiagoPlatero]

Hi Dameon, quick question, what do you mean exactly on the first point?

The gateway must be physically/logically between the client and server?

In my topology I have the DNS server in one VLAN (same VLAN for the gateway) and the clients in another VLANs. I have a lot of logs of DNS request (and responses to the trap) but if I have to know which client made the malicious request I have to go to the DNS server logs.

Maybe the topology is incorrect and should be like you pointed out in the post above?

Thanks!

[Mikel_Aanstoot]

Hi Santiago, as long as the VLAN is routed through the gateway you should be fine I think. We have now 3 DNS servers configured, 2 internally that are not behind the gateway and one DNS server VPN tunneled to another network segment. We see both internally DNS server make the request but also the request to and from the VPN tunneled DNS server. With Identity Awareness we see username and we see the client. However the experience so far that we still see a lot of DNS traps captured but aren't necessary due to infected systems. It also happens with normal browsing from an end user. It still takes some effort to identify whether the DNS traps are from normal browsing or possible infected systems

[SantiagoPlatero]

Hi Mikel, thanks for your answer.

And yes, the VLANs are routed through the gateway (at least for internet browsing).

As you say some traps aren't malicious browsing per se, but (malicious or not) almost never I could see from which client and/or user (we also have IA enabled) the request was made.

Some insight I forgot to mention is we have a Barracuda Web Filter between the gateway and the core switch, maybe it can create some issues regarding to this.

[Tim_McColgan]

Why is this only meant for internal hosts and not external? 

[PhoneBoy]

Not sure I see any benefit to providing this function for external hosts in general.

I could see it being useful for specific ones, but in general? No.

[Tim_McColgan]

So thinking about it more, I guess you want to know if internal hosts are going to bad domains....

[PhoneBoy]

Exactly, you can potentially remediate those hosts.

Ones outside your network, not so much.

[Viktor_Karlsson]

Hi,

I read this and also the discussion and did not understand how this would work so I sent a question to PhoneBoy and got some clarity but I’m still unsure how it’s working.

My question was:

If you have the option turned on for DNS trap and the GW is changing the IP in the response even if there is not a GW with Anti-bot activated that is handling the traffic between the client computer and the DNS server you should see the client computer trying to communicate with the spoofed IP? Or have I misunderstood this?

Will the customer need to have AV activated on the GW that handles the traffic between Computer and DNS server to have full protection?

I also created a scenario to clarify this:

So in this scenario the Checkpoint with AV and AB installed that know that is has changed the DNS reply to a spoofed IP can identify and block the computer?

The answer:

That's the basic idea, yes.
The gateway will see the DNS lookup to badsite.com and replace the real DNS lookup result with the "sinkhole" IP you've configured.
It should be an IP that no legitimate communication should go to.
The end user PC will reach a harmless site instead of the real one.

Note if the end user gets the DNS lookup a different way, the client may attempt a connection to that IP still.
In which case, if the IP itself is blacklisted by AV/AB, the connection should be blocked.

But if you know the IP that the client is trying to connect to that is located on the internet and needs to bypass the perimeter firewall with AV and AB you should see this and can identify the client as infected. (If you have specified the DNS servers)

Right? Or do you really need to have AV-AB activated everywhere to identify the infected clients?

Regards

Viktor