Self Hosting: It's like being a prepper for the cloudpocalypse

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > Self Hosting: It's like being a prepper for the cloudpocalypse

Dyscrasia: Jun 23, 2003; Give Me Hamms Premium Draft or Give Me DEATH!!!!

Does anyone deal with https on their internal networks? I know I could buy a domain name and use let's encrypt with a reverse proxy. While at work I would do this, it just seems like a lot of work for internal only service at home..

# ¿ Feb 18, 2023 01:35

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 08:28

Dyscrasia: Jun 23, 2003; Give Me Hamms Premium Draft or Give Me DEATH!!!!

Thanks, I figured the best path was buying a real domain, everything falls into place after that.

# ¿ Feb 18, 2023 01:45

Dyscrasia: Jun 23, 2003; Give Me Hamms Premium Draft or Give Me DEATH!!!!

Generic Monk posted:

Do I need to have a user/group on the host machine (the one hosting the containers) with a UID/GID of 1001 for it to 'pass through' properly? My only real experience janitoring this kind of stuff before has been freeBSD jails which needed something like that (the GID inside the jail had to match the GID outside the jail).

I had similar problems a few months ago, it was this for me. Need permissions to match the uid/gid.

# ¿ May 25, 2023 22:08

Dyscrasia: Jun 23, 2003; Give Me Hamms Premium Draft or Give Me DEATH!!!!

Quixzlizx posted:

I do have fail2ban set up so someone can't get into Foundry directly by brute-forcing credentials.

But I think I'm either explaining myself very badly, or I can't do what I'm attempting to do. I was hoping I could configure Caddy to flat-out refuse all connections to my server that aren't explicitly from foundry.mywebsite.com, regardless of http or https or legitimacy of certificates. With the understanding that it wouldn't be a foolproof measure, since that wouldn't help if Caddy itself is exploitable.

What your describing does not really offer any sort of protection. It's trivial to find a dns record from an IP address. You need to make sure your network is properly configured and your auth mechanism is solid.

# ¿ Sep 23, 2023 21:06

Dyscrasia: Jun 23, 2003; Give Me Hamms Premium Draft or Give Me DEATH!!!!

Quixzlizx posted:

Thanks for the replies. foundry.mysite.com is just my registered domain address that goes through a CF proxy DNS server before being pointed to my server. I also have a CF cert installed that Caddy requires for authentication per my settings. But that's all only relevant for traffic that is reaching my server through my domain address, rather than randomly port scanning my IP. Which was really what my original question was about, what happens when someone randomly port scans my IP on port 443 (the one forwarded port in my router) that doesn't even know the domain exists.

It sounds like, other than the fail2ban I already have set up to stop brute-force login attempts to my Foundry service, I would need to implement something like a VPN at this point to harden things further on the front-end.

Although f2b has so far only picked up on the one intentional failed login attempt to test that the f2b config was working correctly, so it doesn't seem like I'm attracting any undue attention as of now.

Is cloudflare your proxy or just dns host, they offer both. If it's your proxy, there should be a way for caddy to only accept traffic from that proxy, such as a client certificate config or IP whitelist as suggested by others resulting in anything else being dropped.

Dyscrasia fucked around with this message at 01:06 on Sep 24, 2023

# ¿ Sep 24, 2023 01:04

Dyscrasia: Jun 23, 2003; Give Me Hamms Premium Draft or Give Me DEATH!!!!

I think clarification is needed here too because I read a comment about an emby exploit.... I'd never expose a service directly to the Internet. Put a reverse proxy with authentication in front of it(or your choice of VPN etc)

Dyscrasia fucked around with this message at 04:19 on Sep 29, 2023

# ¿ Sep 29, 2023 04:16

Dyscrasia: Jun 23, 2003; Give Me Hamms Premium Draft or Give Me DEATH!!!!

dweepus posted:

So when you say authentication in front of the reverse proxy, do you mean Login Prompt > Nginx proxy > Jellyfin login prompt? So having an authentication layer on both sides of the reverse proxy?

Also having done more research I do feel a bit more comfortable with putting the server in a DMZ. It seems to me that the stipulation with doing that is being very thorough with a firewall on the host itself.

More or less. I'd probably turn off the emby authentication and force all traffic through the reverse proxy. I don't trust services like emby or the *arrs to properly implement authentication. I use emby myself, but only on the local network. I'd be doing tailscale if I needed remote access.

# ¿ Sep 30, 2023 15:10

Dyscrasia: Jun 23, 2003; Give Me Hamms Premium Draft or Give Me DEATH!!!!

Ah shoot, in that case it's VPN all the way from my opinion.

# ¿ Sep 30, 2023 23:41

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 08:28

Dyscrasia: Jun 23, 2003; Give Me Hamms Premium Draft or Give Me DEATH!!!!

mawarannahr posted:

NetData is very easy to get running, FWIW. I'd even call it "batteries included."

Netdata works great for home servers. The docker compose file works out of box to get all system stats. I've not tried to get it running on my fedora system with podman as a child to my Ubuntu servers parent yet.

# ¿ Feb 22, 2024 01:20

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > Self Hosting: It's like being a prepper for the cloudpocalypse