Comment on Uncomplicated firewall rule set for a *arr stack.

• farcaller@fstab.sh ⁨11⁩ ⁨months⁩ ago

  I disabled DHCP and IPv6

  Why, though?

  source

  • Fedegenerate@lemmynsfw.com ⁨11⁩ ⁨months⁩ ago

    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.

    source

    • TCB13@lemmy.world ⁨11⁩ ⁨months⁩ ago

      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 your computers and phones connected to the network would get their IP addresses from it and also the ISP DNS servers (or router IP) completely bypassing your pi-hole.

      source

      • Fedegenerate@lemmynsfw.com ⁨11⁩ ⁨months⁩ ago

        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.

        source

        • -> View More Comments
• atzanteol@sh.itjust.works ⁨11⁩ ⁨months⁩ ago

  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)) -> 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.

  The router has a “public” facing internet connection which gets an IP from your ISP. 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 route you’ll see something like this:

  $ ip route
  default via 192.168.0.1 dev wlp0s20f3 proto dhcp metric 600 
  

  This tells your computer to send all traffic that is not on the local private network 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. 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.

  source

  • Fedegenerate@lemmynsfw.com ⁨11⁩ ⁨months⁩ ago

    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.

    source
• TCB13@lemmy.world ⁨11⁩ ⁨months⁩ ago

  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?

  source

  • Fedegenerate@lemmynsfw.com ⁨11⁩ ⁨months⁩ ago

    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/bellow it as I learn how.

    source

    • towerful@programming.dev ⁨11⁩ ⁨months⁩ ago

      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).
      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.

      source

      • TCB13@lemmy.world ⁨11⁩ ⁨months⁩ ago

        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.

        source
    • towerful@programming.dev ⁨11⁩ ⁨months⁩ ago

      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

      source