After installing AdGuardHome, I noticed a few things that didn't seem right, here are my notes

[lopperman]

Disclaimer: I'm by no means a security expert, and I acknowledge that some of the issues I found after installing AdGuardHome could be caused by my own configuration mistakes, or might have nothing to do with AdGuardHome.

I installed AdGuardHome today (version 1.9.3, via amtm). I'd been monitoring the output, and making adjustments to dns block lists, and generally looking around in the AdGuardHome settings. Something caught my eye when I was reviewing the Settings --> Client Settings. Some non-local ip addresses where showing up. Specifically: 167.94.138.178, and 66.132.153.155. Both of those resolve to census-scanner.com. What was confusing isn't that they were trying to 'knock on my door', but in fact they were accessing the locally running dns server that is installed with AdGuard.

Apparently, when AdGuardHome was installed, it was available from the WAN and allowed incoming UDP/TCP traffic on port 53. I don't believe by default that should ever be allowed, and and at least for my home network, I never need my local dns service to be available from the WAN. I fixed this issue by blocking incoming UDP/TCP port 53 for WAN traffic. It appears that AdGuard home ships with 0.0.0.0 as the default bind address for setup. It's possible that there's an assumption that the default firewall would block unsolicited WAN traffic to port 53, but in my case (I have a public ip that gets assigned to my WAN port from my Spectrum cable/modem), it was wide open. There's not legitimate reason I could find to expose your local dns service to the wan. It should only be needed for your home devices, or devices connected via VPN (if configured).

In my case, adding explicit drop rules for port 53 from eth0 (WAN Interface), solved the problem. (also added to /jffs/scrips/firewall-start to persist across reboots).

After I did that, I decided to dig a bit deeper, and found that AdGuard Home Web UI (which I'm running on default port 3000), was also exposed to the WAN. I blocked that by adding a drop rule for TCP/UDP Port 3000 from the WAN.

Probably unrelated to AdGuard Home, I also found that Port 21 (FTP) and Port 9999 (infosvr - known ASUS vulnerability), and Port 202 (what I running for local ssh only) were also open to the WAN, so I added drop rules for those as well.

Wondering if anyone else has had similar experiences

 

[lopperman]

Disclaimer: I'm by no means a security expert, and I acknowledge that some of the issues I found after installing AdGuardHome could be cause by my own configuration mistakes, or might have nothing to do with AdGuardHome.

I installed AdGuardHome today (version 1.9.3, via amtm). I'd been monitoring the output, and making adjustments to dns block lists, and generally looking around in the AdGuardHome settings. Something caught my eye when I was reviewing the Settings --> Client Settings. Some non-local ip addresses where showing up. Specifically: 167.94.138.178, and 66.132.153.155. Both of those resolve to census-scanner.com. What was confusing isn't that they were trying to 'knock on my door', but in fact they were accessing the locally running dns server that is installed with AdGuard.

Apparently, when AdGuardHome was installed, it was available from the WAN and allowed incoming UDP/TCP traffic on port 53. I don't believe by default that should ever be allowed, and and at least for my home network, I never need my local dns service to be available from the WAN. I fixed this issue by blocking incoming UDP/TCP port 53 for WAN traffic. It appears that AdGuard home ships with 0.0.0.0 as the default bind address for setup. It's possible that there's an assumption that the default firewall would block unsolicited WAN traffic to port 53, but in my case (I have a public ip that gets assigned to my WAN port from my Spectrum cable/modem), it was wide open. There's not legitimate reason I could find to expose your local dns service to the wan. It should only be needed for your home devices, or devices connected via VPN (if configured).

In my case, adding explicit drop rules for port 53 from eth0 (WAN Interface), solved the problem. (also added to /jffs/scrips/firewall-start to persist across reboots).

After I did that, I decided to dig a bit deeper, and found that AdGuard Home Web UI (which I'm running on default port 3000), was also exposed to the WAN. I blocked that by adding a drop rule for TCP/UDP Port 3000 from the WAN.

Probably unrelated to AdGuard Home, I also found that Port 21 (FTP) and Port 9999 (infosvr - known ASUS vulnerability), and Port 202 (what I running for local ssh only) were also open to the WAN, so I added drop rules for those as well.

Wondering if anyone else has had similar experiences

FYI, here's the changes I made to the /jffs/scripts/firewall-start:

File: /jffs/scripts/firewall-start                   
     ---
     #!/bin/sh
     # Block external access to services from WAN (eth0)

     # DNS (AdGuard Home)
     iptables -I INPUT -i eth0 -p udp --dport 53 -j DROP
     iptables -I INPUT -i eth0 -p tcp --dport 53 -j DROP

     # AdGuard Home web UI
     iptables -I INPUT -i eth0 -p tcp --dport 3000 -j DROP

     # FTP
     iptables -I INPUT -i eth0 -p tcp --dport 21 -j DROP

     # infosvr (ASUS discovery - known vulnerability)
     iptables -I INPUT -i eth0 -p udp --dport 9999 -j DROP

     # SSH
     iptables -I INPUT -i eth0 -p tcp --dport 202 -j DROP

     # cfg_server (AiMesh)
     iptables -I INPUT -i eth0 -p tcp --dport 7788 -j DROP
     iptables -I INPUT -i eth0 -p udp --dport 7788 -j DROP

     # wsdd2 (Windows discovery)
     iptables -I INPUT -i eth0 -p tcp --dport 3702 -j DROP
     iptables -I INPUT -i eth0 -p udp --dport 3702 -j DROP

     # nmbd (NetBIOS)
     iptables -I INPUT -i eth0 -p udp --dport 137 -j DROP
     iptables -I INPUT -i eth0 -p udp --dport 138 -j DROP

     # avahi (mDNS/Bonjour)
     iptables -I INPUT -i eth0 -p udp --dport 5353 -j DROP

 

[dave14305]

There is a difference between listening on 0.0.0.0 or public IP, and actually being accessible on those IPs and ports. The default firewall would not allow such incoming connections from outside. Do you see any rules that are allowing this incoming traffic? Dropping should be the default.