DNS Malware trap - DNS servers

[NikBloemers]

Hello CheckMates,

Can anyone explain to me what adding the internal DNS servers to the DNS trap configuration actually does?

The only thing I can find in the documentation is 'to better help identify the origin of malicious requests', but it's not like we can see the client IP that the DNS request originates from.

I've built a test setup in VM's to compare the difference of the logs with and without the DNS server defined, and I see no difference in the log cards. This is with both the client to DNS server and DNS server to public DNS requests going through the gateway.

I hope someone knows more about this.

[PhoneBoy]

Any DNS queries that go through the gateway intended for a known Command and Control site will have the IP substituted for a different value.
It doesn't change what shows in the log cards but it does ultimately prevent the client from connecting to the C&C server.

[Nik_Bloemers]

I understand how the DNS trap works (and it works fine). What I'm trying to understand is how defining the internal DNS servers in the malware trap configuration changes anything / what it does.
It replaces the DNS result nicely with the default trap IP in both cases (with or without DNS servers defined), but I'm trying to find if there's any point in filling up this list or keeping it up to date, since it doesn't appear to do anything. Action is the same, log information is the same, so what does it do?

[Vladimir]

Is your DNS server seating on a different interface of the gateway?

If not, defining local DNS servers really does nothing, as the gateway is not aware of the query originator, just the DC/DNS server that executed it on behalf of the client.

[Nik_Bloemers]

In my test environment I have them on different interfaces, just to test this. But as in my posts above I see no difference in the results when I define the internal DNS server or don't.

[Chris_Atkinson]

Per sk74060 what do you see if you search logs for the trap IP?

(Default value 62.0.58.94)

[Nik_Bloemers]

No results, but that's because I'm performing these tests with nslookup, not actual browsing, to try and find out the point/benefit of defining the internal DNS servers.

[Wolfgang]

Nik,

I agree with you, this is a good to know question.

I configured this all the time but never checked the difference. If you add the DNS server to the DNS trap feature, then there are some IPS protections for DNS enabled. Because this sets the servertype to DNS on the host object.

But what else....... I can't see any difference in the logs and in the behaviour if configured the DNS servers or not.

Wolfgang

[Chris_Atkinson]

The idea is that connections to the trap IP after the DNS lookup are logged for correlation (or if you've specified your own trap IP directed their for further investigation of the request itself).

Replacing the DNS response with the trap IP also obviously prevents the connection to the intended destination.

[Wolfgang]

Chris,
as Nik already wrote, the functionality of DNS trap feature is understandable and really clear to us.

But why should I add my local DNS servers to the DNS trap configuration and which is the behaviour with or without these ?

Wolfgang

[Chris_Atkinson]

Apologies I understand your question now, my expectation would be the DNS server shouldn't be flagged as potential infected hosts.

[Wolfgang]

Thanks Chris,

that's it. I did a quick check for my better understanding....

If you define the DNS servers these servers are not shown as infected hosts, normally the should because they do the DNS query for an known malware site. But they do it only for the requesting client.

If these DNS servers are not defined they are counted and shown as infected neither they are.

Thanks Chris, good to know.

[Nik_Bloemers]

This clears things up! Thank you very much.
Perhaps the description should change to reflect that the listed hosts will not be marked as Infected Hosts. I assume this will only be for DNS malware trap logs and not in general, so that if somehow the DNS server or domain controller is actually infected with something bad, it does still shows up.

[Vladimir]

@Wolfgang , please confirm that in the environment you are experimenting, DNS servers are segregated from the clients by the gateway.

I expect this feature to work properly when:

1. client attempts to look up known bad resource

2. query originator is recognized by the gateway and response is substituted with the IP of the trap

If you have a flat network with DNS behind same interface as the client, I do not see how Check Point can recognize the originator.

Adding local DNS servers to the trap configuration in this case may simply prevent listing them as infected while still serving the trap IP, but it cannot know which client asked for the bad resource.

[PhoneBoy]

You are correct in that this doesn't work so well when the DNS server is on the same gateway interface as the client.
The DNS server will simply serve up the invalid trap IP to the appropriate clients in this case.

[Vladimir]

@PhoneBoy , can you verify if in case of the flat network, DNS servers are flagged as infected if they are not defined in "Local DNS" servers fields and if they are listed as infected if not defined?

@Wolfgang already shows, what I suspect is the case of the flat network DNS scenario, but I'd like to get a definitive answer on that.

In case of the segregated DNS servers, would Check Point even allow the query to reach the DNS, or will it proxy the query itself and reply to it without permitting it to hit on-premises DNS and thus avoid unnecessary secondary query to external forwarders? 

[Wolfgang]

@Vladimir 

>>>> can you verify if in case of the flat network, DNS servers are flagged as infected if they are not defined in "Local DNS" servers fields and if they are listed as infected if not defined?

This is the shown behaviour in my environment (Management R80.30, gateway R80.20)

>>>>>> segragated DNS servers

A DNS request from client or internal server with request for "pbjs.sskzlabs.com" is not forwarded to the DNS server. The request is answered from gateway and IP is set to the bogus IP.

You can test this with nslookup for "pbjs.sskzlabs.com" (this is a known malware dns name) and a packet trace or fw monitor on the gateway. I did it and can't see any request for  "pbjs.sskzlabs.com" reaching the DNS server.

Wolfgang

[Vladimir]

Thank you @Wolfgang . Your answer puts this issue to rest.

It would be nice for CP to expand the description of DNS traps functionality in its documentation a little bit by addressing flat and split networks.

This is not the first time this subject is being brought up in the forum and by my clients.

Regards,

Vladimir

[PhoneBoy]

My own experience says that DNS servers will get flagged if you don't define them in the "Local DNS Servers" fields.
Further, it should not pass along the malicious DNS requests to the remote server.

[Wolfgang]

Vladimir,

You‘re really correct.
If client and DNS are not seperate via firewall you can‘t analyze this request. But normally the clients ask his DNS server for www.malware.come, the DNS server does not know this domain and forward the request to the next DNS server (mostly one from the local ISP).
If this request is seen on the gateway, DNS trap feature replaces the request with the bogus IP and answer to the internal DNS server. Then the client get‘s the bogus IP from local DNS server and try to access this bogus IP. This last request is seen by the firewall, blocked and logged.

Wolfgang

[Kaloyan_Kirchev]

Hello Guys,

very interesting and most accurate issue for my problem right now.

I have AD DC servers which are also DNS(same client network).

Checkpoint R80.30 shows them as "infected" and source of MANY attacks.

Maybe they should not be suspected(~90%)?

Any idea or advice how can I see originating IPs?

Look through DNS server logs?

P.S.: As I go through the previous answers situation seem to be going to a dead end 😞

Have a nice day!

[Wolfgang]

Kaloyan,

if the DNS trap feature is enabled and if you have defined an IP address, then look for this IP address in the logs.

If you see your DNS server as infected you have to look at these logs. Are these all DNS request to known malicious sites ?

Is there a statement in these logs that the IP-address is replaced with the bogues IP from DNS trap feature?

If yes, the client which is asking for these DNS name Gets the „wrong“ IP for the requested name. The client then requests the packets from the „wrong“ IP and this should be seen in the firewall logs. And you can identify the source which requests the malicious sites via DNS.

Wolfgang

[Kaloyan_Kirchev]

Hi Wolfgang,

First I want to THANK YOU for reply!

DNS trap was not enabled due to.

CP 4800 R77.30 was used for Security Checkup monitoring(gathering logs from client networks).

On R77.30 I have problems with SmartEvent so I extracted logs and have done reports on R80.30 VM.

So, now most "infected" PC are Domain Controllers.

1. Many DNS request are to malicious sites

2.There is no info about Bogus IPs.

There is info about Protection type - DNS Trap/DNS Reputation.

3.However there is another interesting fact - client IP addresses are from DHCP not on DC. And pool is almost exhausted.

So there are constant changes of addresses between host.

So maybe there will be another deeper inspection of client network and further analysis.