I set up an *arr stack and made it work, and now I’m trying to make it safe - the objectivly correct order.
I installed uncomplicated firewall on the system to pretend to protect myself, and opened ports as and when I needed them.
So I’m in mind to fix my firewall rules and my question is this: Given there’s a more sensible ufw rule set what is it, I have looked online I couldn’t find any answers? Either “limit 8080”, “limit 9696”, “limit …” etc. or “open”. Or " allow 192.168.0.0/16" would I have to allow my docker’s subnet as well?
To head off any “why didn’t you <brilliant idea>?” it’s because I’m dumb. Cheers in advance.
Is it running as bridge? Do you get a public IP on your Pi or is it a NAT?
I don’t know, what’s more I don’t know how to check.Which ever most likely?
ISP plastic box didn’t allow custom DNS, I disabled DHCP and IPv6. On pihole I enabled DHCP with IPv6 disabled.
I know, I know enough to be dangerous now, and I’m trying to get the system through my dangerous phase. I don’t think I know enough to ask intelligent questions yet…
That’s fine - we all start somewhere.
I went looking to see if there were any “intro to networking for homegamers” sites but didn’t come up with much… Maybe I’ll put something together some day as this is a frequently misunderstood topic.
You “typically” have something like this: Internet -> Your “ISP plastic box” (which acts as a router, firewall and gateway (actual terms you’ll want to understand and can search on)) -> Things on your network.
In this scenario you have two separate networks - the Internet (things on the left of the firewall) and your internal network (things on the right).
Your internal things get to the internet by asking the gateway to fetch them for it. This is called “Network Address Translation” (NAT). Your internal network uses “non-globaly-routable IP addresses”. They look like “192.168.0.0”, “10.0.0.0”, and 172.16.0.0. These are sometimes called RFC1918 addresses. These addresses can’t be used on the internet. They’re reserved for internal private use only. There are thousands of networks using those ranges internally so they’re not unique globally.
The router has a “public” facing internet connection which gets an IP from your ISP that is globally unique. And it has a “private” facing connection that gets a private IP address (something like 192.168.0.1 is common). If you run
ip routeyou’ll see something like this:$ ip route default via 192.168.0.1 dev wlp0s20f3 proto dhcp metric 600This tells your computer to send all traffic that is not on the local private network (or it doesn’t have a route for specifically) to the gateway (at 192.168.0.1) to fetch for you.
Things on the internet side of your router can’t access things on the private network directly by default. So if you haven’t gone out of your way to make that happen then I have good news - you’re probably fine. What you’re installing with UFW is a “host-based firewall”. It only blocks and restricts access to ports running on that server. But the router also has a firewall which blocks everything from your network.
If you do want to access services in your private network from the internet side then you do something called “port forwarding”. This means that when systems on the internet connect to your router on, for example, port 80 the router will “forward” the request to an internal system on that port (or a different one depending on how you configure it). But only that port gets forwarded and to a specific internal host/port. The router then acts as a go-between to make the communication happen.
Once you start exposing services to the internet you open up a larger can of risk that you’ll want to understand.
In short - if you’re not doing anything fancy then you probably don’t really need host-based firewalling on systems in your private network. It wouldn’t hurt - and I do it as well - but it’s not a big deal if you don’t.
You have cleared up a lot of misconceptions for me, I have not been port forwarding, I have not learned how yet. I think I’m good. I don’t mind breaking functional stuff, and have a lot already, but I really don’t want to explain to my fiancée that the reason someone is in her bank is because I wanted to watch Samurai Jack.
I have been keeping it as insular as possible for this reason, and the next thing I intent to learn is to make it more insular by putting the pi on a subnet of its own. Actually, thank you for writing that up. I have been actively resisting using people for IT support, as I know it takes time. I have been trying to find everything I can, there isn’t much or what there is assumes knowledge I don’t have.
There’s a comment with a list of stuff to do that I’ve saved. So I’ll probably start knocking that out one by one.
So you’ve set a static IP in your Pi? Something like 192.168.1.x? Second question, whenever you want to expose some service to the internet you’ve to go into your ISP and setup a port forward am I right?
Both pi’s have static IPs.
I asked the *arrs to talk to each other, and when they didn’t work (and only when they didnt work) I "ufw allow"ed the relevant port.
I just want to patch up my firewall layer as best I can, and then start building security layers on top/below it as I learn how.
So I told Sonarr that qBit it at 192.168…:port. The test failed, “ufw allow port”, then the test passed. Could I instead have told Sonarr qBit is at 172.18…:port(dockers network address) and then close up the firewall. Or can I set them all to “ufw limit”. Or set the firewall to only allow local local traffic… You get the idea, I know enough to be dangerous but not enough to ask the right questions.
Basically, what they are getting at is:
Have you allowed internet access TO arr?
A default config ISP router will take the public IP address and drop all incomming connections. It will then NAT internal IP addresses to the public IP addresses.
So when you go to Google, Google responds to the established connection coming from the routers public IP address. Your router then knows to forward that response to the local client that started the connection.
If Google just randomly decided to connect to your public IP address, your router is configured to drop that traffic.
If you set up port forwarding on your router, you are telling it “if you get a new connection on port 443, forward it to this local client”. This is exposing that client to the internet and allowing strangers to connect to it. If Google then tried to connect to your public ip:443, it would get the response from that local client.
If you set up a “dmz” client, the router will forward ALL unknown incoming connections to that client. There is no need to do this. The only exception is for research or as a hunnypot/tarpit.
All other traffic will be on the local network, and wont even touch the routers firewall. A connection from 192.168.0.12 to 192.168.0.200 will go through layer 2 (ie, switches) instead of layer 3 (ie, routing) of the network OSI layers.
So, if you trust your internal home network and you have not exposed anything to the internet (port forwarding on the router, or set up a DMZ client) then you dont really need internal firewalls: the chance of a malicious device being able to even connect to an arr service is vanishingly small - like, your arr service will be the least of your concerns.
When you expose arr to the internet (i wouldnt do it directly, use a VPN or similar as a secure hole through your home firewall) THEN you need to address internal firewalls.
If you feel you do need them, then go about it for learning purposes and take your time. Do things, break things, learn things, fix things.
In an ideal scenario, security would be in many layers, connections would all be TLS with client certificate trust, etc etc.
But for a server on your home network serving only local clients… Why bother worrying about it until you want to learn it properly!
I was starting to get annoyed by so much “*arrs” and dancing around the subject that I lost the motivation to type. Thank you for taking the time to type an answer similar to mine. :).
@Fedegenerate@lemmynsfw.com go read this.
Oh, just saw this:
TL:dr;
No, the host has no idea what happens inside a docker network.
The exception is if the containers are on the same host and joined to the SAME docker network (docker compose does this automatically)
It seems like your home network is on 192.168.something. Youve omitted any details to describe what subnet it is within an entire 182.168.0.0/16 block that is dedicated to local network addresses (rfc1918) but that doesnt matter. And docker uses a different dedicated block of 172.16.0.0/12.
Regardless!
Your host has an ip of 192.168.1.4. A client on 192.168.1.5 knows exactly how to communicate to 192.168.1.4 (provided they are in the same subnet… Which is likely on a standard home DHCP served network. Im glossing over this).
Googles DNS server is 8.8.8.8. Which is outside of your home networks subnet (192.168.1.0/24 in CIDR notation). So client 192.168.1.5 has no idea how to contact 8.8.8.8. So it sends the connection to its default gateway (likely 192.168.1.1) as it is an unknown route. Your router then sends it to the internet appropriately (doing NAT as described elsewhere).
What Im saying is that clients within the 192.168.1.0/24 network know how to talk to eachother. If they dont know how to talk to an IP, they send to the gateway.
Now, docker uses its own internal network: 172.16.0.0/12. To a client on 192.168.1.5/24, an ip inside 172.16.0.0/12 is as strange as 8.8.8.8/32. It has no idea where to send it, so it goes to the default gateway. Which isnt helpful if that network is actually INSIDE the host at 192.168.1.4/24.
What am i getting at? Docker runs its own NAT.
It takes the host’s ip address. When you expose a containers port, you are telling docker to bind a host port and forward it to the specific port of the specific container.
So outside of the host, the network has no idea what 172.16.0.0/12 means, but it does know what 192.168.1.4/24 means.
Inside the docker network, a container has no idea what 192.168.0.0/16 means, but does know 172.16.0.0/12 means. Equally, a docker container will send packets to its default gateway inside that 172.16.0.0/12… Which will then respond aporopriately to the 192.168.1.0/24 client.
Which means a dcoker containers host firewall is going to have no idea whats happening inside a docker network. All it knows is that docker wants to recieve information on port 443, and that the local network is 192.168.1.0/24. … Ish, there are other configurations
Why, though?
When it was active I was getting ads. I disabled the pi-hole registered an increase in traffic and there were no more ads. I don’t know why. It’s working as it is and I’ll tinker when I know more.
Did you care to understand why at least? @farcaller@fstab.sh @Fedegenerate@lemmynsfw.com the reason you were getting more ads was simple. If the ISP router was running DHCP and IPv6 then te the devices connected to the network got their IP addresses from the ISP router and it would also provide ISP DNS servers (or router IP) completely bypassing your pi-hole.
Ah, I knew it was bypassing the pi-hole, I thought it was IPv6. I think I made the mistake of changing more than one thing at once, what I did worked and I moved on to the next functionality I was chasing. I’ll try enabling IPv6 on the pihole, I know at least if I get Ads with it on its not IPv6.
It’s both the IPv4 and IPv6 DHCP… You IPS router has to run DHCP (or similar) for both IP versions.
Both of them will provide your machines with ISP DNS servers / gateway and the machines will bypass your pi-hole. Since most operating systems will prefer to use IPv6 over IPv4 if you enable IPv6 you’ll most likely get ANY ad from any company that runs on IPv6 (most likely everyone).
When it comes to IPv6 it’s game over to the pi-hole if your ISP router doesn’t allow you to set custom IPv6 DNS servers (and set it to your pi-hole IPv6 address).
Anyways, as long as you don’t go into the router ISP and tell it to “forward port X to port Y on pi-hole” you don’t even need a firewall running on pi-hole, as nothing from the public internet will be able to reach it.
If you’re using a VPN on the Pi then you may run a firewall but restrict only to the VPN interface and set it do drop all incoming traffic on that interface unless related to some outgoing connection.