Blocking access to public Pi-Hole in AWS EC2

I had recently decided to move my pi-hole to AWS but it seems that the server is being observed by others as well. I see a lot of clients from external IPs that are not familiar and some of those look sketchy.

Is there a way to limit the requests from a select range of IPs inside Pi-Hole because I tried limiting range to my IPv4 & v6 through the aws security groups but that essentially killed the internet.

What are the possible options to handle this?

You could try iptables and netfilter-persistent. Limit certain ip ranges to both udp port 53 and tcp port 53. You could also use a cdn like cloudflare to protect your public interface, but that would require using their nameservers for your domain if you have one.

Like this:

# Allow DNS (53) from <source IP>
iptables -A INPUT -p udp --dport 53 -s <source IP> -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s <source IP> -j ACCEPT

# Deny all other DNS requests
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

I still don't know how to save my firewall rules on reboot myself. Can someone maybe help @itsbhanusharma and I with that? I just got luck and it works on one of my Pi-holes in AWS.

1 Like

maybe instead of iptables, using ufw will help?

My public area is protected by AWS Security Groups by limiting access on HTTP & HTTPS to my static IP from ISP. that's not an issue.

turns out if I use the same rule to limit DNS (TCP & UDP) to my IPv4 Address, The system somehow stops resolving and I have to revert to some other DNS in my router then allow reqests from anywhere in security group to fix this.

Yes, assuming you're on Ubuntu

Yes, Ubuntu 18.04

What does this look like? Can you provide me with a screenshot?

Ok! That's good. Also, can you verify that Pi-hole works correctly?

Pi-hole is working fine. The only problem is some random computers on the internet being able to use it. I'm okay with legit users using my pihole but these are from IPs of berkley uni and some other censys group so seems like the situation is a bit more complicated than what I'd assume.

I see what you mean. I get unwanted DNS queries all the time. You do know there is a way to opt out of those unwanted queries for some of them. Looking at your configuration, you haven't specified port 53 udp/tcp for your IP address, therefore no DNS resolution.

Problem is that:

  1. when I open it for everyone i.e. 0.0.0.0 then it works fine (everywhere)
  2. when I open it to only my IP then it doesn't work at all.

I haven't really tinkered with Security Groups. Do you think the order has something to do with it?

I have crossed that possibility since there aren't any "block" rules that may cause it. The default is to block everything and we explicitly whitelist or "allow" by creating a security group.

Ok, I see. Let me look into this.

1 Like

Just for the nutcrackers, Let me pour in some information about my network as well so that if there is something wrong from my side, I may as well try fixing it.

  1. I'm directly connecting through my public IPv4 as that is a direct allocation static IP I have rented from my ISP so their NAT is not at any role play here.
  2. I'm using HE.net tunnelbroker for IPv6 connectivity and it is configured working fine.
  3. I have set up a lot of block rules for incoming on my home router to disallow people from trying to ssh into my router.

That all sounds good.
I just spun up a Pi-hole in EC2 and I can verify that it works this far:

I am using dynamic IPv4 only from Spectrum here in the U.S., Minnesota. My closest AWS region is us-east-2.

I'm suspecting this to be an IPv6 Tunnel issue then. Since all of my devices get an IP from the Public IPv6 Subnet allocated by HE and I'm assuming that I'd have to find a way to allow the whole subnet to somehow be able to resolve port 53.

1 Like

Yes, that is what I suspected at this point. Maybe you should look and see if anyone else is having this problem. If the IPv4 part works for me, and the IPv6 part of the Security Group not for you, then I would have to conclude that that is the issue. As of now, you should mark this reply as the solution. I will work with you to further investigate the issue, but I have to get some sleep. It's 4:10 A.M. here.

1 Like