Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 2 subscribers
  • Views 6653 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ATP notification on DC/DNS server

M.Rottler
Hey guys,

I already stated this question in the german forum, but no answer yet...

My ATP notified me yesterday in the morning with following message:

2015:05:19-07:57:04 UTM named[4492]: rpz: client 1**.1**.1.**#59998 (motiware.com): view default: rpz IP NXDOMAIN rewrite motiware.com via 32.37.26.70.109.rpz-ip.rpz 


I'm not quite sure where this error came from... The "client" is our 2nd DC and DNS server!

I couldn't find the IP 109.70.26.37 in the WebFiltering log...

Can anybody tell me what exactly could have happened here?

thanks a lot!

Max


This thread was automatically locked due to age.
  • 0
    Hey Max,

    What does the line on the 'Advanced Threat Protection' tab of 'Logging & Reporting >> Network Protection' say?  How is your DNS configured compared to DNS Best Practice?

    Cheers - Bob
  • 0
    Hey Bob,

    thanks for your help again!

    DNS is configured according to best practice! The only thing was that  'Use forwarders assigned by ISP'  was checked. I unchecked it, and put in the OpenDNS servers!

    ATP:

  • 0
    109.70.26.37 doesn't appear to be the public name server for srv1.qxtbnkr.nl (the rDNS for that IP), so I would be suspicious.  If Web Filtering is enabled, you might be able to find which internal IP caused the Proxy to do a DNS query at 2015-05-19 07:57:04.  Was there any malware detected on that computer?

    Cheers - Bob
  • 0
    Hey Bob,

    I can't find this IP in my webfiltering logs... DNS proxy log says around this time:

    2015:05:19-07:56:21 UTM named[4492]: rpz.zone:9: using RFC1035 TTL semantics
    2015:05:19-07:56:25 UTM named[4492]: zone rpz/IN/default: zone serial (1345588987) unchanged. zone may fail to transfer to slaves.
    2015:05:19-07:56:25 UTM named[4492]: rpz: (re)loading policy zone 'rpz' changed from 186823 to 186825 qname, 0 to 0 nsdname, 1553 to 1553 IP, 0 to 0 NSIP entries
    2015:05:19-07:56:25 UTM named[4492]: zone rpz/IN/default: loaded serial 1345588987
    2015:05:19-07:56:25 UTM named[4492]: zone 0.0.127.in-addr.arpa/IN/default: loaded serial 1432014979
    2015:05:19-07:56:39 UTM named[4492]: error (connection refused) resolving '65.5.140.140.in-addr.arpa/PTR/IN': 140.***.***.***#53
    2015:05:19-07:57:04 UTM named[4492]: rpz: client 140.***.***.***#59998 (motiware.com): view default: rpz IP NXDOMAIN rewrite motiware.com via 32.37.26.70.109.rpz-ip.rpz
    2015:05:19-07:57:08 UTM named[4492]: error (connection refused) resolving 'wpad.domain.local/A/IN': 140.***.***.***#53


    Sophos Endpoint Security didn't find any malware on the machine...
  • 0
    I wouldn't expect to find 109.70.26.37 in the Web Filtering log, but I would expect to find some clue at 2015:05:19-07:57:04.

    Cheers - Bob
  • 0
    Hey Bob,

    yeah sure... I wasn't only looking for this specific IP... But I couldn't find anything else "suspicious" around this time....

    Don't know what to do...
  • 0
    What do you see in the Web Filtering log at 2015:05:19-07:57:04 (or maybe a second earlier)?

    Cheers - Bob
  • 0
    Hi,

    This is pretty common if you have users in your network that have visited websites and some pop-up showed up. This is pretty standard for some people that like to visit shady sites (of course sometimes it pops out on normal ones as well).

    In essence, your DNS server will get marked because the client requested the URL from the DNS and the DNS server queried for that web site which at the end would have triggered the ATP engine to block the traffic.

    So there are two ways of figuring out the client of that request, either by redirecting the DNS from the clients to the UTM directly (and avoid NAT as well to the DNS service) or reconfigure the DNS server for logging of the requests. Wait for the same issue to occur and you will have the trace of the error. Right now it would be like looking for a needle in a haystack... [:)]

    Cheers,

    P.