I was going through the query log and I found three entries of this (14.1.168.192.in-addr.arpa) it was in black text and in the client, I think it said "client host".
Should I worry about this?
Thanks.
It's not much to worry about, it's trying to find out what the name of 192.168.1.14 is.
1 Like
Why is it doing that? And what is it, is it pihole?
A client is trying to find out what the name of 192.168.1.14 is. You'd need to see who the client is and what software is running on that client in order to see why it's asking for that information.
This looks like normal network traffic. Please post some lines from /var/log/pihole.log showing this request and the reply and we can verify.
X
This is a representative part of the log. There are around 1500 of this kind of request every hour.
Firts three IP's I looked up dont look good:
https://www.abuseipdb.com/check/89.33.8.34
https://www.abuseipdb.com/check/213.55.176.168
https://www.abuseipdb.com/check/74.82.47.50
You might have something running on the Pi-hole host thats not kosher.
If lucky, below one might reveal some more (can take a while depending host speed):
sudo grep '89.33.8.34' -R / | grep -v log
1 Like
Thank you for your reply.
I'm currently running your command and will reply as soon as it is done.
My Pihole is running on a public IP address. Could it also be possible that these IPs just use my PiHole as DNS Server or want to connect via SSH on Port 53 and that PiHole tries to look up from which name these requests are coming from?
1 Like
sudo grep '89.33.8.34' -R / | grep -v log
has revealed this:
grep: /run/wpa_supplicant/p2p-dev-wlan0: No such device or address
grep: /run/wpa_supplicant/wlan0: No such device or address
grep: /run/pihole/FTL.sock: No such device or address
grep: /run/dhcpcd.unpriv.sock: No such device or address
grep: /run/dhcpcd.sock: No such device or address
grep: /run/dbus/system_bus_socket: No such device or address
grep: /run/avahi-daemon/socket: No such device or address
grep: /run/thd.socket: No such device or address
grep: /run/user/999/gnupg/S.dirmngr: No such device or address
grep: /run/user/999/gnupg/S.gpg-agent.ssh: No such device or address
grep: /run/user/999/gnupg/S.gpg-agent: No such device or address
grep: /run/user/999/gnupg/S.gpg-agent.extra: No such device or address
grep: /run/user/999/gnupg/S.gpg-agent.browser: No such device or address
grep: /run/user/999/systemd/private: No such device or address
grep: /run/user/999/systemd/notify: No such device or address
grep: /run/php/php7.0-fpm.sock: No such device or address
Good one.
Yes I believe sometimes the local sshd daemon is configured to do a reverse lookup when a client tries to connect.
Check the auth logs if they coincide with the Pi-hole logs:
sudo less /var/log/auth.log
Or grep an IP:
sudo grep 89.33.8.34 /var/log/auth.log
1 Like
There were no connection attempts logged with any of the three IPs mentioned above.
The only thing that shows up is me running this command.
Looking at which IPs are looked up, the vast majority is good IP adresses i.e. IP adresses from which I know I have connected to my pihole from.
Are we sure that it isn't pihole trying to find a hostname to display for these IP adresses?
What would trigger pihole-FTL to do a reverse lookup for public IP addresses by its own?
I cant think of any.
Only thing I can think of is another process/daemon running on the Pi-hole host doing these reverse lookups like sshd is known to do.
You can try stop a few processes/daemons temporally to see if the queries disappear.
The other two things that are not installed by default running on my raspberry pi are nginx and unbound. Might these be the culprit?
The reason I'm thinking of pihole as being the reason for this is that in my top list, there are entries like
X
Which are both networks from which known good actors are connecting to my pihole.
In my pihole.log I also find queries like
X
Which I guess is pihole looking up whether the IP-Adresses using pihole are connected to a domain. Because the responses are then shown in the pihole dashboard in the toplist.
The only way why FTL would do such lookups on its own is when clients are coming from external IP addresses. Albeit explicitly discouraged, users still open port 53 on their WAN IP actually making this a rather likely possibility.
This seems to support my above assumption as host names are periodically (once each hour) refreshed. There are two things you can do now:
-
Check the number of known clients on the dashboard (see screenshot)
-
Check your "Top Clients". The dashboard limits the display to 10 clients, but using this link you can query up to 100 clients (note: you need to be logged into the dashboard in the same browser for this link to show anything).
1 Like
If you open up services to the public, you got to be damn sure what your doing.
If you have nginx open to the public, web apps on nginx might do reverse lookups etc.
For example opening up sshd to the public is reasonably safe if proper precautions like brute force protection and/or login with key only(no password).
And opening up DNS 53 UDP/TCP is asking for troubles:
Yep, that's it. I completely missed it being discouraged to open pihole to the public.
Does FTL look up all IPs make some kind of request, regardless whether they are actually doing something DNS related. Because none of the IPs that show up in the top 100 list had any kind of request.
1 Like
I currently only have port 53 and 443 open to the public. nginx also drops all connections not originating from Switzerland. Opening up SSH seemed to risky at the time.
I basically bet on my internet connection being to slow to participate in any kind of meaningful way in an attack (it's awfully slow).
But thanks for your help. That clears it up. All clients that were not authorised to access my pihole had no requests. So no damage done.
1 Like
Doenst matter if slow or fast.
Whenever your setup gets involved in an attack, it takes up precious resources on the target host.
If the link is slow, these resources are not available for other processes during the (long slow) time it takes to complete the query.
Which in its own is another attack vector:
If its a fixed list of public IP's that need access to your setup remotely, you can configure the iptables firewall to allow only those IP's to connect.
Many tools exist to configure iptables.
I believe "UFW" is popular.
Or better, setup openVPN on the Pi-hole host and clients and run everything (or DNS only) through an encrypted VPN tunnel:
https://docs.pi-hole.net/guides/vpn/overview/
EDIT: added some 
1 Like
Yeah but Slowloris doesn't work over DNS.
A popular one to slow things down was "syn-flood" which attacks the transport layer and is independent of the application layer.
DNS replies (application layer) too large to fit in a UDP packet gets truncated to TCP (transport layer).
pi@noads:~ $ cat /proc/sys/net/ipv4/tcp_syncookies
1