pihole-FTL: block IP's from lists

Blocking on IP is like catching a eel with bare hands, it can change IP swiftly and the domain name is the most efficient till now.

If you want catch on only the IP number if the progrem is using thst nativly then I use a firewall addresslist that resolves domainnames or put the hard in the addresslist.

1 Like

Ummm, yeah, Pi-hole is a DNS server.

I wouldn’t say this and I know you’re also not saying this as you already said

I thought about your idea and I can see some value in it is you understand Pi-hole as a security product. However, my personal understanding is that it should not be misunderstood as such a thing as it is too easy to simply circumvent the Pi-hole without us being able to even notice.

You may lock port 53 to the outer world, then they may simply use a different port. You may do deep packet inspection, then they simply encrypt their content by using DoH to a hard-coded IP range. You may xyz, …
This is just to highlight that there are always ways to circumvent the local DNS server and - even when I think such a feature could be implemented in FTL - we shouldn’t do it as it can easily lead to a deceptive feeling of safety and leak to a risky handling of network security.

But I’m open for more discussions, maybe you can convince us regardless of what I wrote above.

Commenting on this: This is not the first period of prolonged silence on the dnsmasq mailing list. I’m aware of the limitations a single man project has, however, dnsmasq has proven to be worth it and the reasoning before we start diverging need to be really good.

Validating input to be a valid IP address is not a trivial task.

Adding a feature like this to FTL would diverge it from the upstream dnsmasq code and truly create a new fork of dnsmasq that would be incompatible with future updates from Simon. This will add a very large burden on the Pi-hole team for something that can easily be handled by a firewall.

If your goal is to prevent users from being able to access 172.217.17.72 then just use something like IPTables and create an IP set of addresses you do not want clients to access. There doesn’t need to be any wait for the client to time out if you reject the traffic with the proper flags, similar to the IPTables rules that we found worked for blocking HTTPS requests while preventing the client from pausing for timeouts.

Without having the illusion this is ever going to happen, clear to me as of the first response, I would like to argue your quoted statement.

The default adlists.list, suggested during the pihole installation contains https://mirror1.malwaredomains.com/files/justdomains and https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist

Do you really assume people see the word malware and abuse, and don’t assume they have at least some protection against these, making it a security product in their minds?

The reason I would like pihole to take some action (implement something more than it currently is - innovate) is the fact that you can read almost anywhere the advertisers are fighting back, making it a losing battle with the current functionality of pihole.

Another feature request, made recently, is to, somehow, find a way to block recently created domains. May be not easy to implement, but could be a way to make pihole a more effective and attractive product, changes to the web interface may generate a WOW effect for some users, but since the introduction of regex, nothing has really changed.

To give my thoughts on how to implement my proposal (ain’t gonna happen, I would fork if I could, but not smart enough)

  • sooner or later, pihole-FTL has an answer ready to send to the client, the original host that made the request.
  • code: If result in IPgravitylist then send 0.0.0.0 else send result.

Of course, I don’t know the first thing about the source code, it’s probably a lot more complicated than this, but this is how a project manager would approach the issue.

In conclusion: if you want pihole to remain relevant, you’re gonna have to do something to get new users to install it. Changes to the web interface may convince some manager types, but this isn’t going to have a long term effect.

Well, yes, they will have a certain protection. I just wanted to highlight that this should not be stretched too much. If they happen to request a blocked domain from Pi-hole, then they will get the blocked reply. Instead of blocking based on an IP, I’d argue that the corresponding host name should instead be on a blocking list. I can see that this might be less effective, because

however, regex is a certain hindrance for them.

When you filter on the replied IPs in addition, we can easily run into numerous additions problems as

Look at server politics run by most major hosting providers. Ad content can easily live on the same server as the legit content, a web server can host dozens or even hundreds of pages from the same IP as you very well know. They just decide what to respond with based on the host name you used to connect to it.

That is not and should not be our first goal (well, I should say it is not my goal). If you ask for personal opinion, here it comes: I want to make a software that is useful for our users and obviously also for myself.
If the software becomes less “relevant”, then that is fine as long as it still serves the purpose of those who use it.

  • We are not selling anything any licenses and we are not going to do this in the future.
  • We do not run the project as a business.
  • None of the developers is basing their daily food on the project.
  • We do not have to do anything possible to stay in the minds of managers.

in some way, this is already implemented in development as I added the support for massive whitelists. And with massive I really mean dozens or hundreds of million domains if you like. Combined with a all-blocking regex, this seems to come close to the idea in this feature request, although it is more based on the idea of allowing only legit domains instead of blocking young ones. This approach has its own drawbacks but I will go to this feature request you linked and comment there tonight.


Just to summarize this: You see, we are still evolving. It is just not happening like a manager would maybe do it - we focus more on sustainability than on “WOW effect”.

This is the only technical opposition I’ve heard so far, that does make sense. Maybe, I’ll run in to it some day. As explained in the first entry of this topic, I’ve added the IPs of the lists I’ve mentioned to pfBlockerNG, they are now all blocked on the firewall, so whatever is behind them, doesn’t get trough. The bad thing is the timeout. I’ll have to consider this in the future, whenever I cannot go where I want, but so far, that hasn’t occurred yet.

I’ve offered you a solution to combat the timeout. It’s up to you to implement it or not.

We’ve had no slowdown in adoption of Pi-hole, in fact things are picking up!

You will make a Quantum Leap when the database version is released.

Posibilities will become endless then…pihole-QL?

I can definitely see how being able to block hostnames based off their IP could be useful (Microsoft Telemetry IP blacklists, anyone?), but I do have to agree with others that it really does fall outside the purview of Pi-hole being a DNS server.

If it could be implemented in a way that would be very easy to add back when upstream dnsmasq gets updated, that’d be awesome, but I honestly doubt that’d be the case.

Ultimately, I’m of the opinion that IP blocking should be handled at the firewall because you can never be sure whether DNS resolution comes into play when it comes to this sort of thing.

3 Likes

I found a feature request, referring an alarming new type of malware, using DOH to attack. Since the pihole documentation offers a guide to implement it, I assume it is well within pihole’s scope.

The feature request (already rejected as usual) refers a github page, containing lists with DNS entries, and, more relevant here, IPv4 and IPv6 lists, that could be used in the suggested IPlists.list.

I was wondering if this would count as a good enough reason, making pihole users, using DOH, implemented per pihole’s guide, resistant to these attacks?

P.S. I’ve relayed this information to Simon, hoping he will consider the feature request.

That’s not the way to engender the developers to be likely to explore your requests.

This not a task that Pi-hole is up to.

Rules for firewall on a router:

  • only pihole tcp/udp 53+853 to outside
  • filtering on IP number to DNS servers + DOT/DOH to the outside excluding Pihole
  • Add DNS server names added to regex to have resolving…oops that could levels out the rule just above. Not a good idea if your firewall list is generated from domains.

Pi-hole can’t stop clients going rouge and visiting services.

DOH is activly promoted and I made some earlier sugestions to detect that hapening.

The list is welcome and add the missing ones to my fitewall.

Update my current (DNS/DOT) and new (DOH) blocked IP:

Current DNS/DOT:

1.1.1.1
8.8.4.4
8.8.8.8
4.2.2.2
4.2.2.1
14.215.150.17
14.215.155.156
14.215.155.170
14.215.155.203
42.120.214.1
58.247.212.48
58.247.212.36
58.247.212.119
61.129.8.159
61.151.180.44
61.215.150.17
101.226.220.16
111.161.57.77
111.161.57.81
121.161.220.16
121.51.128.164
149.112.112.112
151.51.1.151
180.76.76.76
180.163.19.5
182.140.167.188
182.140.167.166
216.239.35.0/24
223.5.5.5

Added block-doh:
9.9.9.9
9.9.9.10
45.32.105.4
45.32.253.116
45.77.124.64
47.96.179.163
104.16.248.249
104.16.249.249
104.236.178.232
104.28.0.106
104.28.1.106
108.61.201.119
116.203.35.255
116.203.70.156
118.89.110.78
136.144.215.158
139.59.48.222
146.185.167.43
149.112.112.10
149.112.112.9
185.228.168.10
185.228.168.168

Current DNS/DOT:
2001:4860:4860::8844
2001:4860:4860::8888
2620:fe::fe

Added from block-doh:
2001:19f0:4400:7bcc:5400:1ff:fed1:8599
2001:19f0:6001:146f:45:77:124:64
2001:19f0:7001:1ded:5400:1ff:fe90:945b
2001:19f0:7001:27a2:45:32:253:116
2001:470:f324::45:77:124:64
2001:470:ff0a::45:32:253:116
2604:a880:1:20::51:f001
2606:4700:30::681c:16a
2606:4700:30::681c:6a
2606:4700::6810:f8f9
2606:4700::6810:f9f9
2620:fe::10
2620:fe::9
2620:fe::fe:10
2620:fe::fe:9
2a01:4f8:1c1c:5e77::1
2a01:4f8:1c1c:75b4::1
2a01:7c8:d002:1ef:5054:ff:fe40:3703
2a03:b0c0:0:1010::e9a:3001

firefox: network.trr.uri, setting: https://mozilla.cloudflare-dns.com/dns-query

if the normal (pihole) DNS service isn’t going to resolve this, how will the client get the IP address?

browser: https://mozilla.cloudflare-dns.com/dns-query, results in empty page. https://mozilla.cloudflare-dns.com/ provides an explanation for using 1.1.1.1

nslookup mozilla.cloudflare-dns.com results in

Addresses:  2606:4700::6810:f9f9
          2606:4700::6810:f8f9
          104.16.248.249
          104.16.249.249

Both the IPv4 and IPv6 addresses are on the list, provided in the IP lists on the DOH GitHub page.

edit
You might argue, adding the hosts lists (doh-hosts.txt) to adlists.list would protect, using the current functionality of pihole. Unfortunately, the domain mozilla.cloudflare-dns.com isn’t on the list (already reported). It looks like the browsers are simply creating a domain in their zone, pointing to one of the IP addresses, capable of providing DOH services
/edit

You might want to do the research, before telling me I’m wrong.

That is ‘standard’ resolving now and as I wrote I suggestion earlier how to detect that, several times.

Malware is not likely going to use a default resolving or even a domain name. It will use an IP because that is more difficult to tag and grab.

Google and others are using UDP/53 to call home and those will also use TCP/443 and you have to packet inspection to see what is inside and that is almost impossible with SSL/TLS traffic.

To be honest and complete, this article (uk isp group names mozilla internet villain for supporting dns over https) on reddit, comments here, appeared today, a rather pro DOH opinion is expressed here.

I still believe unbound, as a recursive DNS server, is the better option (this may change in the future), provided your ISP doesn’t interfere with regular DNS requests, going to servers, other than their own. The idea is simple, divide and conquer. Visiting the website of iRobot will of course give iRobot the option to collect my data, but Samsung will never know, and vice versa, nobody gets a complete history of whatever DNS requests I’m making.

I have collected in my log of the router firewall the RougeDNS requests. They all came from my Android tablet from Huawei and none of my other devices.

Used are port 53 UDP (DNS), 853 TCP (DOT) and port 123 (NTP - Time sync)

The DNS/DOT request went to Ali (from Aliexpress) and Baidu. The NTP request went to Google. The firewall drop those request and don’t let them go out to the Internet. I rather drop those requests than redirect them to my local services.

This all is with the new RougeDNS list also containing the DOH servers.

The log:

Jul/04/2019 14:07:10 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:43639->216.239.35.4:123, len 76
Jul/04/2019 14:07:14 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:40134->223.5.5.5:853, len 64
Jul/04/2019 14:07:14 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:40022->180.76.76.76:853, len 64
Jul/04/2019 14:07:15 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:39755->180.76.76.76:53, len 70
Jul/04/2019 14:07:15 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:40022->180.76.76.76:853, len 60
Jul/04/2019 14:07:15 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:40134->223.5.5.5:853, len 60
Jul/04/2019 14:07:16 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:52164->180.76.76.76:53, len 65
Jul/04/2019 14:07:17 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:44134->216.239.35.4:123, len 76
Jul/04/2019 14:07:17 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:53611->223.5.5.5:53, len 70
Jul/04/2019 14:07:18 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:58692->223.5.5.5:53, len 65
Jul/04/2019 14:07:19 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:39755->180.76.76.76:53, len 70
Jul/04/2019 14:07:20 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:56162->180.76.76.76:53, len 61
Jul/04/2019 14:07:20 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:52164->180.76.76.76:53, len 65
Jul/04/2019 14:07:22 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:44671->223.5.5.5:53, len 61
Jul/04/2019 14:07:22 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:1774->180.76.76.76:53, len 62
Jul/04/2019 14:07:24 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:56162->180.76.76.76:53, len 61
Jul/04/2019 14:07:24 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:53611->223.5.5.5:53, len 70
Jul/04/2019 14:07:24 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:60666->223.5.5.5:53, len 62
Jul/04/2019 14:07:25 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:44795->180.76.76.76:53, len 60
Jul/04/2019 14:07:25 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:58692->223.5.5.5:53, len 65
Jul/04/2019 14:07:26 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:1774->180.76.76.76:53, len 62
Jul/04/2019 14:07:27 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:57469->223.5.5.5:53, len 60
Jul/04/2019 14:07:29 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:44671->223.5.5.5:53, len 61
Jul/04/2019 14:07:29 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:57949->180.76.76.76:53, len 70
Jul/04/2019 14:07:29 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:44795->180.76.76.76:53, len 60
Jul/04/2019 14:07:30 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:62770->180.76.76.76:53, len 65
Jul/04/2019 14:07:31 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:45647->223.5.5.5:53, len 70
Jul/04/2019 14:07:31 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:60666->223.5.5.5:53, len 62
Jul/04/2019 14:07:32 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:61711->223.5.5.5:53, len 65
Jul/04/2019 14:07:33 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:57949->180.76.76.76:53, len 70
Jul/04/2019 14:07:34 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:40117->180.76.76.76:53, len 61
Jul/04/2019 14:07:34 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:63140->180.76.76.76:53, len 61
Jul/04/2019 14:07:34 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:50000->180.76.76.76:53, len 64
Jul/04/2019 14:07:34 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:57469->223.5.5.5:53, len 60
Jul/04/2019 14:07:34 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:62770->180.76.76.76:53, len 65
Jul/04/2019 14:07:36 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:36359->223.5.5.5:53, len 61
Jul/04/2019 14:07:36 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:58658->223.5.5.5:53, len 61
Jul/04/2019 14:07:36 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:45936->223.5.5.5:53, len 64
Jul/04/2019 14:07:36 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:44155->223.5.5.5:53, len 62
Jul/04/2019 14:07:36 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:49806->223.5.5.5:53, len 75
Jul/04/2019 14:07:38 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:63140->180.76.76.76:53, len 61
Jul/04/2019 14:07:38 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:40117->180.76.76.76:53, len 61
Jul/04/2019 14:07:38 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:58938->180.76.76.76:53, len 73
Jul/04/2019 14:07:38 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:50000->180.76.76.76:53, len 64
Jul/04/2019 14:07:38 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:45647->223.5.5.5:53, len 70
Jul/04/2019 14:07:38 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:63884->180.76.76.76:53, len 62
Jul/04/2019 14:07:38 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:48544->180.76.76.76:53, len 75
Jul/04/2019 14:07:39 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:60206->180.76.76.76:53, len 60
Jul/04/2019 14:07:39 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:61711->223.5.5.5:53, len 65
Jul/04/2019 14:07:40 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:64187->223.5.5.5:53, len 73
Jul/04/2019 14:07:40 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:58580->180.76.76.76:53, len 83
Jul/04/2019 14:07:40 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:55121->180.76.76.76:53, len 62
Jul/04/2019 14:07:41 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:56262->223.5.5.5:53, len 60
Jul/04/2019 14:07:42 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:58938->180.76.76.76:53, len 73
Jul/04/2019 14:07:42 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:37014->223.5.5.5:53, len 83
Jul/04/2019 14:07:42 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:37447->223.5.5.5:53, len 62
Jul/04/2019 14:07:43 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:36359->223.5.5.5:53, len 61
Jul/04/2019 14:07:43 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:58658->223.5.5.5:53, len 61
Jul/04/2019 14:07:43 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:45936->223.5.5.5:53, len 64
Jul/04/2019 14:07:43 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:60206->180.76.76.76:53, len 60
Jul/04/2019 14:07:43 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:44155->223.5.5.5:53, len 62
Jul/04/2019 14:07:43 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:49806->223.5.5.5:53, len 75
Jul/04/2019 14:07:44 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:58580->180.76.76.76:53, len 83
Jul/04/2019 14:07:44 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:55121->180.76.76.76:53, len 62
Jul/04/2019 14:07:47 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:64187->223.5.5.5:53, len 73
Jul/04/2019 14:07:48 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:64447->180.76.76.76:53, len 61
Jul/04/2019 14:07:48 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:56722->180.76.76.76:53, len 62
Jul/04/2019 14:07:48 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:1466->180.76.76.76:53, len 64
Jul/04/2019 14:07:48 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:56262->223.5.5.5:53, len 60
Jul/04/2019 14:07:48 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:64191->180.76.76.76:53, len 67
Jul/04/2019 14:07:48 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:39293->180.76.76.76:53, len 75
Jul/04/2019 14:07:49 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:37014->223.5.5.5:53, len 83
Jul/04/2019 14:07:49 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:37447->223.5.5.5:53, len 62
Jul/04/2019 14:07:50 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:62743->223.5.5.5:53, len 61
Jul/04/2019 14:07:50 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:34298->223.5.5.5:53, len 62
Jul/04/2019 14:07:50 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:41349->223.5.5.5:53, len 64
Jul/04/2019 14:07:50 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:62414->223.5.5.5:53, len 67
Jul/04/2019 14:07:50 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:50722->223.5.5.5:53, len 75
Jul/04/2019 14:07:52 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:64447->180.76.76.76:53, len 61
Jul/04/2019 14:07:52 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:56722->180.76.76.76:53, len 62
Jul/04/2019 14:07:52 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:42080->180.76.76.76:53, len 73
Jul/04/2019 14:07:52 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:1466->180.76.76.76:53, len 64
Jul/04/2019 14:07:52 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:64191->180.76.76.76:53, len 67
Jul/04/2019 14:07:52 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:39293->180.76.76.76:53, len 75
Jul/04/2019 14:07:53 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:48187->180.76.76.76:53, len 69
Jul/04/2019 14:07:54 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:49396->223.5.5.5:53, len 73
Jul/04/2019 14:07:54 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:56940->180.76.76.76:53, len 83
Jul/04/2019 14:07:54 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:45039->180.76.76.76:53, len 62
Jul/04/2019 14:07:55 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:50091->223.5.5.5:53, len 69
Jul/04/2019 14:07:56 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:35956->180.76.76.76:53, len 60
Jul/04/2019 14:07:56 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:42080->180.76.76.76:53, len 73
Jul/04/2019 14:07:56 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:48801->223.5.5.5:53, len 83
Jul/04/2019 14:07:56 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:55646->223.5.5.5:53, len 62
Jul/04/2019 14:07:57 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:62743->223.5.5.5:53, len 61
Jul/04/2019 14:07:57 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:34298->223.5.5.5:53, len 62
Jul/04/2019 14:07:57 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:41349->223.5.5.5:53, len 64
Jul/04/2019 14:07:57 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:62414->223.5.5.5:53, len 67
Jul/04/2019 14:07:57 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:48187->180.76.76.76:53, len 69
Jul/04/2019 14:07:57 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:50722->223.5.5.5:53, len 75
Jul/04/2019 14:07:58 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:1629->223.5.5.5:53, len 60
Jul/04/2019 14:07:58 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:56940->180.76.76.76:53, len 83
Jul/04/2019 14:07:58 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:45039->180.76.76.76:53, len 62
Jul/04/2019 14:08:00 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:35956->180.76.76.76:53, len 60
Jul/04/2019 14:08:02 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:47734->180.76.76.76:53, len 62
Jul/04/2019 14:08:02 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:60524->180.76.76.76:53, len 67
Jul/04/2019 14:08:02 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:50091->223.5.5.5:53, len 69
Jul/04/2019 14:08:03 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:48801->223.5.5.5:53, len 83
Jul/04/2019 14:08:03 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:55646->223.5.5.5:53, len 62
Jul/04/2019 14:08:04 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:36997->223.5.5.5:53, len 62
Jul/04/2019 14:08:04 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:61734->223.5.5.5:53, len 67
Jul/04/2019 14:08:05 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:1629->223.5.5.5:53, len 60
Jul/04/2019 14:08:06 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:47734->180.76.76.76:53, len 62
Jul/04/2019 14:08:13 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto UDP, 192.AN.DR.OID:49711->216.239.35.0:123, len 76
Jul/05/2019 17:51:33 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:40502->180.76.76.76:853, len 64
Jul/05/2019 17:51:33 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:42014->223.5.5.5:853, len 64
Jul/05/2019 17:51:34 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:42014->223.5.5.5:853, len 60
Jul/05/2019 17:51:34 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:40502->180.76.76.76:853, len 60
Jul/05/2019 17:52:35 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:40718->180.76.76.76:853, len 64
Jul/05/2019 17:52:35 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:42230->223.5.5.5:853, len 64
Jul/05/2019 17:52:36 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:40718->180.76.76.76:853, len 60
Jul/05/2019 17:52:36 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:42230->223.5.5.5:853, len 60
Jul/05/2019 17:54:37 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:42414->223.5.5.5:853, len 64
Jul/05/2019 17:54:37 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:40906->180.76.76.76:853, len 64
Jul/05/2019 17:54:38 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:40906->180.76.76.76:853, len 60
Jul/05/2019 17:54:38 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:42414->223.5.5.5:853, len 60
Jul/05/2019 17:58:39 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:42682->223.5.5.5:853, len 64
Jul/05/2019 17:58:39 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:41174->180.76.76.76:853, len 64
Jul/05/2019 17:58:40 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:42682->223.5.5.5:853, len 60
Jul/05/2019 17:58:40 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:41174->180.76.76.76:853, len 60
Jul/06/2019 12:47:53 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:52006->223.5.5.5:853, len 64
Jul/06/2019 12:47:54 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:40336->180.76.76.76:853, len 64
Jul/06/2019 12:47:54 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:52006->223.5.5.5:853, len 60
Jul/06/2019 12:47:54 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:40336->180.76.76.76:853, len 60
Jul/06/2019 12:49:56 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:40424->180.76.76.76:853, len 64
Jul/06/2019 12:49:56 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:52098->223.5.5.5:853, len 64
Jul/06/2019 12:49:57 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:52098->223.5.5.5:853, len 60
Jul/06/2019 12:49:57 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:40424->180.76.76.76:853, len 60
Jul/06/2019 12:53:58 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:40614->180.76.76.76:853, len 64
Jul/06/2019 12:53:58 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:52286->223.5.5.5:853, len 64
Jul/06/2019 12:53:59 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:52286->223.5.5.5:853, len 60
Jul/06/2019 12:53:59 firewall,info RougeDNS , src-mac a0:an:dr:oi:dd:dd, proto TCP (SYN), 192.AN.DR.OID:40614->180.76.76.76:853, len 60