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.
You must log in or register to comment.
What’s your actual end goal? What are you trying to protect against? Do you only want certain systems on your network to be able to access your apps? There’s not really much of a point of a firewall if you’re just going to open up the ports to the whole network.
If you want it to be more secure then I’d close all the ports except for 22 (SSH) and 443 (HTTPS), stick a reverse proxy in front of everything (like Nginx Caddy, Traefik, etc), and use Authentik for authentication, with two-factor authentication enabled. Get a TLS certificate using Let’s Encrypt and a DNS challenge. You have to use a real domain name for your server, but the server does not have to be publicly accessible - Let’s Encrypt works for local servers too.
The LinuxServer project has a Docker image called “SWAG” that has Nginx with a bunch of reverse proxy configs for a bunch of common apps. Might be a decent way to go. The reverse proxy should be on the same Docker network as the other containers, so that it can access them directly even though you won’t be exposing their ports any more.
Authentik will give you access controls (eg to only allow particular users to access particular apps), access logs for whenever someone logs in to an app, and two-factor auth for everything. It uses OIDC/OAuth2 or SAML, or its own reverse proxy for apps that don’t support proper auth.
Just trying to keep outside/malicious actors from entering my stuff while also bring able to use my stuff. More safer is more better, but I’m trying to balance that against my poor technical ability.
My priority list is free>easy>usable>safe. Using UFW seemed to fit, but you’re right, punching holes in it defeats the purpose Which is why I wanted to only allow local network and have only the necessary ports open. You have given me lots of terms to Google as a jumping off point so thank you.
VPN back into your network. Only open the VPN port on your router. Use certificates based VPN.
The guy above you gives great advice. Set up SWAG, then the only ports you’re exposing are 443.
Once you have that set up, look at adding something like authelia. This will give you 2FA on top of those apps meaning even if someone guesses the password and the URL to access them, they still won’t be able to.
adding something like authelia.
I used to use Authelia, but Authentik is nicer since it’s mostly configured through a web UI. It also supports SAML for services that don’t support OpenID Connect. It also has a proxy mode like Authelia, but that’s not recommended if the service has proper SSO support. There’s just a bit of an initial learning curve.
Yeah honestly either solution is a solid one
Is your system running behind a ISP router / selfhosted at home or a VPS at some provider?
ISP modem. I have a pi3 running pihole-dhcp-unbound, ufw and log2ram.
My system is a pi4 running *arrs, qBit, fail2ban, portainer in docker and ufw for now. Use case is: via mobile phone access *arrs, let them do their things and manually play files via hdmi or move files via thumbdrive. I was thinking giving up the phone access to put them on their own network, but subnets are beyond my ken for now.
Hoping to increment my security, and then the system as my skills develop.
Edit, qBit and prowlarr are behind gluetun set up for mullvard. I’m in the UK so had to put the indexer behind a VPN. UFW
Im bit confused tbh. Have you even forwarded any ports on your ISP router?
You are safe if you havent. You can use all arrs at home safely and stick with gluetun to hide your trafic from ISP. Its good to have firewall, but only people on your home network can access your server. You have opened only ports that you need in UFW and thats perfect.
In case you want to access your services when not at home, you have to deal with security and feels like most comments are about this. If this is what you are looking for then I would suggest setting up wireguard VPN or look into tailscale (or alternatives). Both options are safe enough IMO, much safer than exposing ports 80 and 443
That’s a relief. Thank you.
ISP modem.
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…
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:
Could I instead have told Sonarr qBit is at 172.18…:port(dockers network address)
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
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.
I disabled DHCP and IPv6
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.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters DNS Domain Name Service/System HTTP Hypertext Transfer Protocol, the Web HTTPS HTTP over SSL IP Internet Protocol NAT Network Address Translation SSH Secure Shell for remote terminal access SSL Secure Sockets Layer, for transparent encryption SSO Single Sign-On TLS Transport Layer Security, supersedes SSL VPN Virtual Private Network VPS Virtual Private Server (opposed to shared hosting)
[Thread #501 for this sub, first seen 10th Feb 2024, 13:55] [FAQ] [Full list] [Contact] [Source code]
