Pi-hole diagnosis GUI with unbound: possible DNS-rebind attack detected

Help Community Help
1

Pi 4 running Pi-hole & unbound
Pi-hole** [v5.13] - FTL** [v5.18.2] - Web Interface [5.16]
i am getting a lot of messages: possible DNS-rebind attack detected: u.mokexapp.cloud
i am aware this has blocked any attack but 3 questions, where is this log stored?
can i stop/block this log from showing the notification in the gui if any attempt was blocked?
Last question how do i find the device that is requesting this u.mokexapp.cloud if any?

2

Entries in Tools | Pi-hole diagnosis should display a direct link to our documentation.
Doesn't that show for you, or does that link not work for you?

The link should take you to the documentation page, where the very top reads:

Warnings commonly seen in dnsmasq 's log file (/var/log/pihole/pihole.log ) and the Pi-hole diagnosis system.

No.

Yes, they would be using those IPs where queries for u.mokexapp.cloud originate from.
You can search the logs, e.g. by running

sudo grep u.mokexapp.cloud /var/log/pihole/pihole.log

Oct 14 14:21:30 dnsmasq[16356]: query[A] u.mokexapp.cloud from 192.168.1.36
Oct 14 14:21:30 dnsmasq[16356]: forwarded u.mokexapp.cloud to 127.0.1.1#5335
Oct 14 14:21:30 dnsmasq[16356]: possible DNS-rebind attack detected: u.mokexapp.cloud
3

Thank you for your informative reply,
my output only reads:
~ $ sudo grep u.mokexapp.cloud /var/log/pihole/pihole.log
Oct 14 03:43:05 dnsmasq[1579]: possible DNS-rebind attack detected: u.mokexapp.cloud
Oct 14 05:29:38 dnsmasq[1579]: possible DNS-rebind attack detected: u.mokexapp.cloud
Oct 14 06:19:19 dnsmasq[1579]: possible DNS-rebind attack detected: u.mokexapp.cloud

4

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

5

https://tricorder.pi-hole.net/d0FXzBKP/
Thanks

6

Your debug log contains no hints to explain why your grep returns only the dns rebind warnings, but not the actual client query.
Specifically, it shows PRIVACYLEVEL as 0, meaning that client details should be logged.
If you'd have changed your PRIVACYLEVEL recently (e.g. via Settings | Privacy, that may explain why those queries are absent.

To verify, could you run from a client

nslookup u.mokexapp.cloud

You should then be able to observe both the query as well as the warning in Pi-hole via Pi-hole's UI (Query Log and Pi-hole Diagnosis respectively).

7

from a windows client
nslookup u.mokexapp.cloud
Server: pi.hole
Address: 192.168.49.1

*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for u.mokexapp.cloud
and i then see the notification in pihole diagnosis
then from vnc
sudo grep u.mokexapp.cloud /var/log/pihole/pihole.log
Oct 17 02:43:35 dnsmasq[1579]: possible DNS-rebind attack detected: u.mokexapp.cloud
Oct 17 08:30:07 dnsmasq[1579]: possible DNS-rebind attack detected: u.mokexapp.cloud
Oct 17 09:18:16 dnsmasq[1579]: query[A] u.mokexapp.cloud.lan from 192.168.49.2
Oct 17 09:18:16 dnsmasq[1579]: forwarded u.mokexapp.cloud.lan to 127.0.0.1#5335
Oct 17 09:18:16 dnsmasq[1579]: reply u.mokexapp.cloud.lan is NXDOMAIN
Oct 17 09:18:16 dnsmasq[1579]: query[AAAA] u.mokexapp.cloud.lan from 192.168.49.2
Oct 17 09:18:16 dnsmasq[1579]: cached u.mokexapp.cloud.lan is NXDOMAIN
Oct 17 09:18:16 dnsmasq[1579]: query[A] u.mokexapp.cloud from 192.168.49.2
Oct 17 09:18:16 dnsmasq[1579]: forwarded u.mokexapp.cloud to 127.0.0.1#5335
Oct 17 09:18:16 dnsmasq[1579]: possible DNS-rebind attack detected: u.mokexapp.cloud
Oct 17 09:18:16 dnsmasq[1579]: query[AAAA] u.mokexapp.cloud from 192.168.49.2
Oct 17 09:18:16 dnsmasq[1579]: forwarded u.mokexapp.cloud to 127.0.0.1#5335
Oct 17 09:18:16 dnsmasq[1579]: reply u.mokexapp.cloud is NODATA-IPv6
Oct 17 09:19:39 dnsmasq[1579]: query[A] u.mokexapp.cloud.lan from 192.168.49.2
Oct 17 09:19:39 dnsmasq[1579]: cached u.mokexapp.cloud.lan is NXDOMAIN
Oct 17 09:19:39 dnsmasq[1579]: query[AAAA] u.mokexapp.cloud.lan from 192.168.49.2
Oct 17 09:19:39 dnsmasq[1579]: cached u.mokexapp.cloud.lan is NXDOMAIN
Oct 17 09:19:39 dnsmasq[1579]: query[A] u.mokexapp.cloud from 192.168.49.2
Oct 17 09:19:39 dnsmasq[1579]: forwarded u.mokexapp.cloud to 127.0.0.1#5335
Oct 17 09:19:39 dnsmasq[1579]: possible DNS-rebind attack detected: u.mokexapp.cloud
Oct 17 09:19:39 dnsmasq[1579]: query[AAAA] u.mokexapp.cloud from 192.168.49.2
Oct 17 09:19:39 dnsmasq[1579]: cached u.mokexapp.cloud is NODATA-IPv6

so if i lookup from my PC on 49.2 this shows in pihole log

8

i have just done a nslookup from my phone connected to my LAN and its showing u.mokexapp.club as 127.0.0.1 is that correct? i seem to be getting rather alot of these pihole diagnosis notifications daily for this domain yet i cant find what device is requesting it.
no privacy levels have been changed since the day i configured the pi-hole aproxx 2 yrs ago or a very long time ago now.

9

It's what public DNS servers seem to return for u.mokexapp.club as well, e.g.:

~$ dig +short u.mokexapp.club @9.9.9.9
127.0.0.1

As this is a localhost/loopback and not a public address, that's what would trigger the DNS rebind warning.

Your log excerpts show this to be the client IP requesting it:

10

Hi Bucking_Horn No, " Oct 17 09:18:16 dnsmasq[1579]: query[A] u.mokexapp.cloud.lan from 192.168.49.2" that was triggered when doing an nslookup on my pc, other that that it returns (3rd post in this thread), no device seems to request it, again another 27 log entries overnight last night. Why the developers don't give us a toggle button to stop this log is beyond me.
Every morning i delete these entries seems to have gotten more per evening and more oftener every night now.

11

What's the output of:

pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db "SELECT domain, client, count(domain) FROM queries WHERE domain LIKE 'u.mokexapp.cloud%' GROUP BY domain;"
12

pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db "SELECT domain, client, count(domain) FROM queries WHERE domain LIKE 'u.mokexapp.cloud%' GROUP BY domain;"
u.mokexapp.cloud|192.168.49.2|6
u.mokexapp.cloud.lan|192.168.49.2|4

13

currently the logged domain that seesm to being logged is u.mokexapp.co not cloud or club

14

The following statement should find those as well:

pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db "SELECT domain, client, count(domain) FROM queries WHERE domain LIKE 'u.mokexapp.%' GROUP BY domain;"
15

pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db "SELECT domain, client, count(domain) FROM queries WHERE domain LIKE 'u.mokexapp.%' GROUP BY domain;"
u.mokexapp.cloud|192.168.49.2|6
u.mokexapp.cloud.lan|192.168.49.2|4
u.mokexapp.co|192.168.49.2|2
u.mokexapp.co.lan|192.168.49.2|2
i assume the |6 or |4 is the amount of times that client has requested that domain? i have 984 deleted i think the last message said when i deleted the from the ui.

16

Just to mention i run unbound on the same Pi as Pi-Hole, which i am sure your aware of when looking at the logs but thought i would mention it as it may help shed further light on this.

17

Yes, the value in the last column represents a count of how often that domain was requested by a client.

It seems odd that a client would not be listed that correlates with the number of occurcences you observe.

Debug logs auto-expire from our servers 48 hours after you've uploaded them .
If you provide a fresh token, I'll have another look.

18

https://tricorder.pi-hole.net/r3L5b7YH/
i heave currently deleted the possible DNS-Rebind log entries for today would i be better waiting and sending you a log with the entries still showing?
I have enclosed the current debug.log

19

Perhaps.
On the one hand, it could possibly allow for catching details that have escaped me before.

On the other hand, we've already accessed your log files and your long-term database. Those are more detailed than a debug log, yet we haven't found additional clients than the ones you've used for explicit lookups. It remains a mystery to me why that happens.

How keen are you to keep that stop-dns-rebind setting of yours?

20

Could the Pi OS be causing the lookup? would this show in the logs?
stop-dns-rebind, i used because i am using unbound thought it was good practice to use this.

pi@raspberrypi:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.49.1  netmask 255.255.255.0  broadcast 192.168.49.255
        inet6 fe80::dea6:32ff:fec0:12da  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:c0:12:da  txqueuelen 1000  (Ethernet)
        RX packets 558454  bytes 72399589 (69.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 258385  bytes 33971277 (32.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 245772  bytes 20608377 (19.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 245772  bytes 20608377 (19.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether dc:a6:32:c0:12:db  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@raspberrypi:~ $ cat /etc/dhcpcd.conf
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# Most distributions have NTP support.
#option ntp_servers

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private

# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1

# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1

# fallback to static profile on eth0
#interface eth0
#fallback static_eth0

interface eth0
static ip_address=192.168.49.1
static routers=192.168.49.254
static domain_name_servers=127.0.0.1
static domain_search=
noipv6 
static ip_address=192.168.49.1/24
static routers=192.168.49.254
static domain_name_servers=1.1.1.1 1.0.0.1