INDICATOR-COMPROMISE Suspicious .tk dns query

Hi, Gino, and welcome to the UTM Community!

Thanks for the vote of confidence!

Just follow the link in my post above to which you replied.  That effectively blocks the entire domain.  The IP in the Network definition is a dummy one, so no lookups can be made for the top level domain.  Just replace "ru" with "tk" in the definition.  If you also want to block ru, then just add tk to 'Additional Hostnames'.

Cheers - Bob

Got about 300 of these Intrusion Prevention Alerts today.

Lots, but not all, seem to be contacting destinations like G.ROOT-SERVERS.NET

Eg:

*********
Intrusion Prevention Alert

An intrusion has been detected. The packet has been dropped automatically.
You can toggle this rule between "drop" and "alert only" in WebAdmin.

Details about the intrusion alert:

Message........: INDICATOR-COMPROMISE Suspicious .tk dns query
Details........: https://www.snort.org/search?query=39867
Time...........: 2017-04-06 10:08:58
Packet dropped.: yes
Priority.......: low
Classification.: Misc activity
IP protocol....: 17 (UDP)

Source IP address: 192.168.2.229
Source port: 61828
Destination IP address: 192.112.36.4 (G.ROOT-SERVERS.NET)
Destination port: 53 (domain)

--
HA Status          : HA MASTER (node id: 2)
System Uptime      : 55 days 11 hours 0 minutes
System Load        : 2.28
System Version     : Sophos UTM 9.411-3

**********

Destination IP address: 192.5.5.241 (f.root-servers.net)

Destination IP address: 192.58.128.30 (j.root-servers.net)

Destination IP address: 192.33.4.12 (c.root-servers.net)

Destination IP address: 198.32.64.12

Destination IP address: 128.8.10.90

Destination IP address: 128.9.0.107

So I don't think it actually has anything to do with .tk domains.

What you are seeing are Root hints from your domain controller. (zones that do not exist on the local DNS server) You will find it under the properties of your domain controller in DNS. I had the same problem with the .tk domain alert on a daily basis but then realized that it had to do with spam email. I recently upgraded to version 4.11 and the alerts stopped so I do not know if the new fix corrected any false positives.

Gino

This is an indication that there could be a problem with name resolution in your network or with the configuration in the UTM.  How does your config differ from DNS best practice?

Cheers - Bob

DNS Best Practice:

1. Allowed networks. Left blank as we have internal DNS.

2. Forwarders. OpenDNS 1 and OpenDNS 2. Use ISP forwarders is not checked.

3. I have nothing in Request Routing. Not sure of your instructions - do I actually put '20.16.172.in-addr.arpa -> {Internal DNS}' in the Domain field, and put the internal DNS in Target servers? Or do you mean put '20.16.172.in-addr.arpa' in Domain, and drag the Internal DNS host into Target Servers? 

5. Doesn't this happen automatically?

James.

3. Yes, "put '20.16.172.in-addr.arpa' in Domain, and drag the Internal DNS host into Target Servers."  Thanks! - I've corrected/clarified that in the DNS post.

5. In Windows Server, at least when I last set up a Windows server, only the IP of the server is included.  Even then, only if DNS is already configured on the server when you configure DHCP.

I would try conforming to DNS Best Practice to see if your DC stops trying to go to the root name servers.  This should also speed up browsing.

Cheers - Bob