Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Sanjay_Gounder
Explorer
Jump to solution

DNS Query going through implied rules

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 ??

 

0 Kudos
1 Solution

Accepted Solutions
SteveM
Participant

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.

View solution in original post

12 Replies
PhoneBoy
Admin
Admin
The DNS Server being queried here is a function of what you've configured in GAIA OS.
Change it to a different server.
0 Kudos
SteveM
Participant

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?

0 Kudos
Vladimir
Champion
Champion

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.

0 Kudos
SteveM
Participant

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!

0 Kudos
Ruan_Kotze
Advisor

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?

0 Kudos
SteveM
Participant

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"

0 Kudos
SteveM
Participant

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.

0 Kudos
SteveM
Participant

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.

PhoneBoy
Admin
Admin

Traffic originating from the gateway itself is typically allowed (and not logged) through implied rules...unless you've turned that off.

0 Kudos
Wei_Jie__Ho
Employee
Employee

Hi Steve,

 

is there anyway to prove that its because of the FQDN object but nothing else?

0 Kudos
SteveM
Participant

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.

0 Kudos
Ruan_Kotze
Advisor

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

cpwd_admin stop -name WSDNSD -path "$FWDIR/bin/wsdnsd" -command "kill -SIGTERM $(pidof $FWDIR/bin/wsdnsd)"
cpwd_admin start -name WSDNSD -path "$FWDIR/bin/wsdnsd" -command "wsdnsd"
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events