- CheckMates
- :
- Products
- :
- Quantum
- :
- Threat Prevention
- :
- Re: Default DNS Trap and malware detection?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Default DNS Trap and malware detection?
Please advise if it is normal for Check Point default DNS trap to be identified as known to contain malware:
As per Anti-Virus Malware DNS Trap feature , The default value for DNS trap IP is 62.0.58.94.
Thank you,
Vladimir
- Tags:
- dns trap
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
DNS Trap means that the DNS request was intercepted and the gateway responded to the client with that bogus IP address. The malicious part is not the IP address 62.0.58.94, but the hostname etacontent. com.
You won't see the real IP address for that suspicious host because the query was intercepted before it reached the external DNS server and the response was replaced by the DNS trap address.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I guess that your log shows what happens after it receives the bogus IP.
Client -> DNS request for a malicious website
Client <- Gateway intercepts/acts as DNS server and tamper the respons with the false IP address 62.0.58.94
Client -> Tries to go to IP address 62.0.58.94 (Your log shows this step).
Here is a similar example where the destination is 62.0.58.94:
This examples shows that suppressed logs are 12 telling how many connections were made during a session.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Looks about right, but it would be helpful if CP would serve a page stating that the redirect took place for a reason, rather than terminating it on a blank.
My confusion was caused by trying to deliberately access 62.0.58.94 via HTTP and seeing the message shown in the first post, while in fact, the TRAP event was caused by a different machine on the same network.
Trying to access the http://62.0.58.94 directly does not, apparently, generate event logs.
Took me a few minutes to spot the difference of originator IP's.
Thanks guys!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The primary reason, if I'm not mistaken, for the DNS trap is to uncover the real host that made DNS request. Otherwise, we would be flagging the DNS server for forwarding the requests which doesn't do us any good. Of course the DNS server is resolving what is asked of it. By giving the host a bogus IP, and then waiting for the IP to come through we can flag the end host that is infected.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Makes sense, it would just be helpful to have these events better differentiated. I.e. without knowing the default DNS trap IP by heart, this prompts an investigation in misleading direction, (at least this is what happen in my case).
Speaking of this event being indicative of the hosts being infected: One of my clients called in today stating that they are seeing the growing rate of similar events from increasing number of PCs.
My first reaction, predictably, was that they have bought it, and that there is a laterally propagating malware loose in the network. Their endpoint protection, however, is staying mum.
No machines, as of yet, crashed and burned or have asked nicely for bitcoin deposits.
Now I am thinking that these events may be caused by one of the sites frequented by employees hosting malicious payload and, as the day progressed, more and more people accessing it.
For now, Check Point seem to be holding the fort, but am surprised not to see anything on endpoints.
The site in question is likely served via SSL and since there is no HTTPS inspection in place in that environment, we are seeing actions by the clients, but not flagging the real source.
Does this scenario sounds plausible?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From my experience a massive "DNS Reputation" events could have been because a blacklist was created thru object type "Domain" and put in Access Rule policy.
Then, firewall will try to research IP address for every each all time.
In this case, best practice could be use "indicators" feature. So event reports will be cleaner and better behavior.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Also, a blank page is given because when a bot makes the connection it won't know it is being redirected to a different destination.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nice!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Should I allow traffic to the bogus trap IP in security policy rule?
