Management General Management Topics Logging and Reporting Multi-Domain Management Policy Management
- Local User Groups
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.
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?
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.
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.
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.
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.
@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 , 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?
>>>> 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.
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.
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!
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.
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.