59
Just how secure are the various reverse proxy options? (feddit.uk)
submitted 6 months ago* (last edited 5 months ago) by TedZanzibar@feddit.uk to c/selfhosted@lemmy.world
24 comments fedilink hide all child comments

Specifically from the standpoint of protecting against common and not-so-common exploits.

I understand the concept of a reverse proxy and how works on the surface level, but do any of the common recommendations (npm, caddy, traefik) actually do anything worthwhile to protect against exploit probes and/or active attacks?

Npm has a "block common exploits" option but I can't find anything about what that actually does, caddy has a module to add crowdsec support which looks like it could be promising but I haven't wrapped my head around it yet, and traefik looks like a massive pain to get going in the first place!

Meanwhile Bunkerweb actually looks like it's been built with robust protections out of the box, but seems like it's just as complicated as traefik to setup, and DNS based Let's Encrypt requires a pro subscription so that's a no-go for me anyway.

Would love to hear people's thoughts on the matter and what you're doing to adequately secure your setup.

Edit: Thanks for all of your informative replies, everyone. I read them all and replied to as many as I could! In the end I've managed to get npm working with crowdsec, and once I get cloudflare to include the source IP with the requests I think I'll be happy enough with that solution.

you are viewing a single comment's thread
view the rest of the comments
[-] TedZanzibar@feddit.uk 1 points 6 months ago

Yeah I'm running a Cloudflare tunnel for external access (which is why I need DNS based LE certs), but that's another thing that I don't really know what it's doing beyond basic reverse proxying.

I have a country-based whitelist for where my Immich instance can be accessed from but I find the Zero Trust admin backend to be massive overkill for my needs, and it doesn't help that they've recently moved everything around so none of the guides out there point to the right places anymore!

[-] vzq@lemmy.blahaj.zone 1 points 6 months ago

Btw, you can do http based LE certificates through cloudflare. They just proxy the ACME URLs.

[-] TedZanzibar@feddit.uk 1 points 6 months ago

Hmm I must be doing something wrong then because it doesn't work for me.

[-] towerful@programming.dev 0 points 6 months ago

So, is public accessibility actually required?
Does it need to be exposed to the public internet?

Why not use wireguard (or another VPN)? Even easier is tailscale.
If you are hand selecting users (IE, doesn't actually need to be publicly accessible), then VPN is the most secure and just run a reverse proxy for ease & certs.
Or set up client certificate authentication, so only users that install a certificate issued by you can connect to the service (dunno how that works for 3rd party apps to immich)

Like I asked, what is your actual threat model?
What are your requirements?
Is public accessibility actually required?

[-] TedZanzibar@feddit.uk 2 points 6 months ago

If it was just me, or if Tailscale wasn't such an insatiable battery leech then I'd absolutely do that but the wife (and kids) acceptance factor plays a big role, and they're never going to accept having to toggle a separate service on and off to get to their photos.

Maybe I'm being overly paranoid but I work in IT and see the daily, near constant barrage of port scans and login attempts to our VPN service and it has an effect!

[-] butitsnotme@lemmy.world 1 points 6 months ago

I use WireGaurd, it’s set to on demand for any network or cellular data (so effectively always on), no DNS records (I just use public DNS providing private range IP addresses). It doesn’t make any sort of dent in my battery life. Also, only the wiregaurd network traffic is routed through it, so if my server is down the phone/laptop’s internet continues to work. I borrowed my wife’s phone and laptop for 15 minutes to set it up, and now no one has to think about it.

[-] TedZanzibar@feddit.uk 1 points 5 months ago

Thanks for the suggestion. I spent a good hour or two trying to make Wireguard work for me last night but failed. If I set it to only apply to Immich, nothing else would have Internet access at all. Likewise if I set the peer IP range to just my LAN subnet.

After pulling my hair out for a while I gave up and uninstalled.

[-] butitsnotme@lemmy.world 2 points 5 months ago

The peer range shouldn’t be your LAN, it should be a new network range, just for WireGaurd. Make sure that the server running Immich is part of the WireGaurd network.

My phone and laptop see three networks: the internet, the lan (192.168.1.0/24, typically) and WireGaurd (10.30.0.0/16). I can anonymize and share my WireGaurd config if that would help.

[-] TedZanzibar@feddit.uk 1 points 5 months ago

Yes please, I might revisit it with a fresh pair of eyes.

[-] butitsnotme@lemmy.world 1 points 5 months ago

Here are a few more details of my setup:

Components:

  • server
  • clients (phone/laptop)
  • domain name (we'll call it custom.domain)
  • home router
  • dynamic DNS provider

The home router has WireGuard port forwarded to server, with no re-mapping (I'm using the default 51820). It's also providing DHCP services to my home network, using the 192.168.1.0/24 network.

The server is running the dynamic DNS client (keeping the dynamic domain name updated to my public IP), and I have a CNAME record on the vpn.custom.domain pointing to the dynamic DNS name (which is an awful random string of characters). I also have server.custom.domain with an A record pointing to 10.30.0.1. All my DNS records are in public DNS (so no need to change the DNS settings on the computer or phone or use DNS overrides with WireGuard.)

Immich config:

version: "3.8"

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:release
    entrypoint: ["/bin/sh", "./start-server.sh"]
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
    env_file:
      - .env
    ports:
      - target: 3001
        published: 2283
        host_ip: 10.30.0.1
    depends_on:
      - redis
      - database
    restart: always
    networks:
      - immich

WireGuard is configured using wg-quick (/etc/wireguard/wg0.conf):

[Interface]
Address = 10.30.0.1/16
PrivateKey = <server-private-key>
ListenPort = 51820

[Peer]
PublicKey = <phone-public-key>
AllowedIPs = 10.30.0.12/32

[Peer]
PublicKey = <laptop-public-key>
AllowedIPs = 10.30.0.11/32

Start WireGuard with systemctl enable --now wg-quick@wg0.

Phone WireGuard configuration (iOS):

[Interface]
Name = vpn.custom.domain

Private Key = <phone private key>
Public Key = <phone public key>

Addresses = 10.30.0.12/32
Listen port = <blank>
MTU = <blank>
DNS servers = <blank>

[Peer]
Public Key = <server public key>
Pre-shared key = <blank>
Endpoint = vpn.custom.domain:51820
Allowed IPs = 10.30.0.0/16
Persistent Keepalive = 25

[On Demand Activation]
Cellular = On
Wi-Fi = On
SSIDs = Any SSID

This connection is then left always enabled, and comes on whenever my phone has any kind of network connection.

My laptop (running Linux), is also using wg-quick (/etc/wireguard/wg0.conf):

[Interface]
Address = 10.30.0.14
PrivateKey = <laptop private key>

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.custom.domain:51820
AllowedIPs = 10.30.0.0/16

My wife's window's laptop is configured using the official WireGuard windows app, with similar settings.

No matter where we are (at home, on a WiFi hotspot, or using cellular data) we access Immich over the VPN: http://server.custom.comain:2283/.

Let me know if you have any further questions.

[-] TedZanzibar@feddit.uk 1 points 5 months ago

Thanks, I'll muse over this when I next get the chance!

this post was submitted on 20 May 2024
59 points (100.0% liked)

Selfhosted

40198 readers
403 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz