- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
Introducing Check Point Quantum Spark 2500:
Smarter Security, Faster Connectivity, and Simpler MSP Management!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Currently, In checkpoint firewall (R80.20 take 47) i see lot of DNS query request is going from firewalls IPs to Internal DNS servers. I want to stop this because DNS
query is coming from firewalls IPs and its pointing to malicious dominas via interanl DNS servers.
Secondly, I changed the DNS settings to Public DNS servers and also , i have uncheck Implied rules i.e "Accept Domain Name UDP QUERIES" and "Accept incoming traffic to DHCP and DNS services of gateways" but
till i see DNS request is coming through security gateways to AD servers.
Can anyone guide or help us why such behaviour is observed ??
Mystery solved - the queries were the FWs looking up IPs for Domain objects. We have rules blocking access to many known C&C servers and our DNS provider was flagging that we had infected hosts. Interesting to know that "self DNS" traffic isn't logged though.
We are seeing exactly the same issue, but need to identify the infected client that is presumably using the FW as DNS proxy. I have triend packet capture and cannot see the initial query, only the query from the FW to DNS server. I've created a spoofed zone on our DNS server and A records for the suspect queries to try and trap the client, but it's not connecting to the spoofed IP. CP logs do not show the original client query. Any ideas how I might find the culprit? Can you turn on logging for the DNS proxy service?
When your clients attempt to access resources on the internet by name, these must be resolved to IPs for traffic to be forwarded.
Gateway will query DNS servers configured in its properties to do so.
If your clients and DNS servers are in different networks connected to different interfaces of the gateway, you can identify those that are querying malicious destinations.
If you have a flat network, the origins of the query will be your internal DNS servers.
When you are stating that "DNS query is coming from firewalls IPs", I'd like to know where you re seeing it.
Post the firewall logs replacing your actual public IPs with bogus entries.
Thank you for your replies and let me try and elaborate. Logs on our internal DNS server show DNS A record queries for known C&C FQDNs. The logs on the server (and packet capture taken on server) both show the source IP of the query being the Checkpoint interbal Cluster IP. We need to identify the client(s) trying to resolve these C&C FQDNs.
Now clearly since the source IP of the query is the Checkpoint VIP, a device (not on our internal LAN) is either querying the internal DNS server directly and the traffic is being NATd to the Cluster internal VIP (this can't be the case as not shown in FW logs, or tcpdump taken on Checkpoint). Or perhaps the client(s) are performing DNS query against one of the FW interface IPs and the Checkpoint DNS proxy daemon is then querying the internal DNS server - but if this is the case, once again neither the client -> FW DNS query is logged, nor is the FW -> internal DNS query. Neither are showing in a tcpdump.
So I can't post any logs here as nothing is logged for these suspicious DNS queries yet they are either originating from, or being proxied by, the Checkpoint. Logging of Implied Rules is also enabled.
Mystery!
Might be worth double-checking that DNS Trap is enabled? With it enabled, doing a log query for traffic where the destination is your trap IP (default is 62.0.58.94) should show the offending client IP?
Thank you - this isn't enabled, but I've enabled the same functionality by creating zones and bogus A records for many of the C&C FQDNs on our internal DNS server. Unfortunately even when a bogus IP is returned, the infected client(s) are not connecting to the IP. I really need a way to either log the original DNS query or capture the traffic - it just seems this is not possible for traffic to the Checkpoint "self"
Update - I originally thought the queries were from clients using one of the FW IPs as DNS server and although DNS Proxy is enabled by default, our Security Policy doesn't permit DNS queries against the FW interfaces.
I really need a way to locate the source of the DNS queries. The query is originating from the internal Cluster VIP and yet there is absolutely no log for these connections. Any help would be most appreciated.
Mystery solved - the queries were the FWs looking up IPs for Domain objects. We have rules blocking access to many known C&C servers and our DNS provider was flagging that we had infected hosts. Interesting to know that "self DNS" traffic isn't logged though.
Traffic originating from the gateway itself is typically allowed (and not logged) through implied rules...unless you've turned that off.
Hi Steve,
is there anyway to prove that its because of the FQDN object but nothing else?
Hi in our case it was obvious because thre was one rule blocking access the the FQDNs that were being resolved by the internal DNS server. Perhaps you could remove the domain object(s) from the policy and see if the DNS server is still being queried for it/them.
In my experience, if you change DNS (either via clish or Web GUI) the appliance needs to be rebooted for the change to take effect. If the impact is too high restarting the WSDNSD process might also do the trick
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
17 | |
9 | |
6 | |
5 | |
4 | |
4 | |
3 | |
3 | |
2 | |
2 |
Wed 03 Sep 2025 @ 11:00 AM (SGT)
Deep Dive APAC: Troubleshooting 101 for Quantum Security GatewaysThu 04 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: External Risk Management for DummiesWed 10 Sep 2025 @ 11:00 AM (CEST)
Effortless Web Application & API Security with AI-Powered WAF, an intro to CloudGuard WAFWed 10 Sep 2025 @ 11:00 AM (EDT)
Quantum Spark Management Unleashed: Hands-On TechTalk for MSPs Managing SMB NetworksWed 03 Sep 2025 @ 11:00 AM (SGT)
Deep Dive APAC: Troubleshooting 101 for Quantum Security GatewaysThu 04 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: External Risk Management for DummiesWed 10 Sep 2025 @ 11:00 AM (EDT)
Quantum Spark Management Unleashed: Hands-On TechTalk for MSPs Managing SMB NetworksAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY