|
I have a server that, for now, really only hosts Plex and FoundryVTT, and only Foundry is exposed to the internet. After reading this thread for a bit, I figured I should at least protect myself a little more, and I ended up with a domain ---> Cloudflare DNS/proxy --> Caddy reverse proxy --> Foundry chain, with end-to-end https. I have a couple of questions about this. Maybe someone could explain to me like I'm an idiot how the reverse proxy is blocking traffic rather than just redirecting it. I had port 30000 forwarded to my server originally, but now I have ports 80 and 443 forwarded, which Caddy is still redirecting to Foundry. Is it that, since I only have a "foundry.mywebsite.com" rule in my Caddy config, that all traffic that doesn't originate from there is blocked, so I don't have to worry about random port sniffers directly scanning my IP address getting anywhere? I also want to implement fail2ban so that randoms can't brute force their way into Foundry. Unfortunately, Caddy doesn't support CLF, so I can't just use one of f2b's default profiles. I managed to find this link, which is essentially a standard f2b jail, but with a custom regex (which I can't wrap my head around) in order to filter Caddy's logs into a format that f2b can parse. I understand how f2b works, and I'll probably slightly modify his jail configs to drop max retries down to 5, but with a 300 second findtime so that I don't end up with players with 10 failed login attempts over 3 years getting banned, but I just want to make sure that the regex code makes sense, since I don't want to just copy/paste code I don't understand.
|
#
¿
Sep 11, 2023 22:11
|
|
|
|
| # ¿ May 14, 2024 16:30 |
|
|
Zapf Dingbat posted:So when you say you have the ports forwarded, you mean at your router, right? Sorry if that's a dumb question. Maybe I worded my post badly. In my router, I have port 443 forwarded to my server. If someone visits "foundry.mywebsite.com," Caddy correctly sends that traffic to port 30000, which is the port Foundry is listening on. My question was more a general question about how reverse proxies are supposed to work. I have a specific rule for "foundry.mywebsite.com" in my Caddy config file, and it's working as expected. My question was what happens if someone scans port 443 while not coming from "foundry.mywebsite.com," as in directly using my IP address. Do reverse proxies just not resolve those connections at all, since there's no rule defined for that? Or do I have to explicitly block all attempted connections that don't fit one of my defined rules?
|
|
#
¿
Sep 21, 2023 20:41
|
|
|
Thanks for the replies. I asked a friend to test them out, and my external ip on http times out, https gives a secure connection failed error, external ip on http and port 443 is "Client sent an http request to an https server," and https with port 443 is SSL_ERROR_INTERNAL_ERROR_ALERT. So it seems like the connections are still happening, but they're not being authenticated because there's no cert to engage with in my config file outside of the defined rules for my domain.
|
|
#
¿
Sep 22, 2023 00:40
|
|
|
fletcher posted:What about "curl -k https://ip" ? curl: (35) error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error Sorry, it took until this morning until I had access to someone outside my network with access to a Linux terminal, since I didn't know whether being on the same local network as the server would alter the results. I'm actually getting my intended behavior with Caddy, in that people using the domain I have defined are successfully connecting, and connections directly to my IP are erroring out in various ways, which is basically the behavior I want. I was just curious about whether or not my config is actually secure so that it's impossible for anyone to access anything through port 443 (the only port I have forwarded to the server) if it's not through a domain address I define in my Caddy rules. I tried googling/looking through the documentation to see if there was a way to implement a catch-all rule for when someone isn't engaging with one of my defined rules, and I tried adding this rule under the rule for my domain based on what I could figure out by Googling, but that didn't seem to change the error message people were getting: :443 { respond 404 }
|
|
#
¿
Sep 22, 2023 14:42
|
|
|
NihilCredo posted:You get an error message because HTTPS doesn't work unless both sides agree to establish an encrypted connection, and with a normal client that means "the server must have a valid certificate for the domain my used asked for". So I don't need to change anything to increase my security then, because I want all connections not through the domain to fail. I just didn't know if there were any edge cases where a theoretical attacker could get around the lack of a certificate, which is why I was contemplating a catch-all rule to block everything else.
|
|
#
¿
Sep 23, 2023 18:59
|
|
|
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.
|
|
#
¿
Sep 23, 2023 20:40
|
|
|
Well Played Mauer posted:Which log are you using for Foundry’s login? I threw it behind Authelia on my server because I didn’t trust Foundry’s auth process as much as I did Authelia, but I wanna get better at fail2ban than I am. It depends on what software you're using as access control. SSH and NGINX both have default filter settings in fail2ban that you can just enable, but Caddy doesn't use the same logging format. So, I followed this person's regex/filter settings, then had someone intentionally enter incorrect credentials into Foundry to make sure that it was working correctly. https://muetsch.io/how-to-integrate-caddy-with-fail2ban.html
|
|
#
¿
Sep 23, 2023 20:56
|
|
|
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.
|
|
#
¿
Sep 23, 2023 21:32
|
|
|
Mr. Crow posted:Personally I would just drop the connection without responding if its not asking for foundry.mysite.com, in nginx you can Yes, this is what I wanted to accomplish, but I wasn't able to figure it out by searching Google results or the Caddy documentation. I'll keep reading and hopefully I'll eventually figure it out.
|
|
#
¿
Sep 23, 2023 22:14
|
|
|
Dyscrasia posted: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. Cloudflare is both my DNS nameserver and proxy. I also have a CF certificate installed on the server and "Full (strict)" TLS/SSL encryption mode enabled. I'll try to figure out how to create a global IP whitelist in the config file.
|
|
#
¿
Sep 24, 2023 16:53
|
|
|
This may be a weird question, but I originally installed Kubuntu on my server since I still wasn't completely comfortable with an only-terminal environment at the time. I'm now doing 100% of my interaction with the server through an SSH terminal, and I don't see myself ever having to log into KDE again. I tried googling ways to remove KDE, but many of the results were contradictory, and ranged from 2-10 years old. This seems to be the cleanest solution I could find, with the caveat that I may have to start removing individual KDE apps afterward that aren't covered by this set of packages: sudo apt remove plasma-desktop kubuntu-desktop sudo apt autoremove Is this probably the best balance of ripping out as much of KDE's guts as possible without causing some sort of catastrophe by uninstalling a package that's required for something non-KDE? The reason why I want to do this is that my server has a relatively lightweight CPU (Alder Lake N100), so I figure I should try to claw back as much performance as possible, as well as remove any possible vulnerabilities from packages I'm not using anyway.
|
|
#
¿
Oct 7, 2023 17:53
|
|
|
apt autoremove removed 355 packages and cleared up 729 MB, so seems like it did a decent job, at least. I noticed my grub and initramfs were updated as part of the process, and everything seems to be working on a reboot. I'll say this is a job well done by Ubuntu/apt.
|
|
#
¿
Oct 8, 2023 02:54
|
|
|
mawarannahr posted:I like it, please keep posting. When the "real apocalypse hits," you'll probably have more important things to do than fiddle with your nextcloud. Especially since many/most of the services discussed in this thread still require a generally functioning Internet to have any purpose.
|
|
#
¿
Jan 14, 2024 20:53
|
|
|
Ubuntu also has a Plex snap. You don't have to worry about snap permissions screwing things up, since Plex isn't going to be moving files around or writing to directories outside of itself.
|
|
#
¿
Jan 17, 2024 02:15
|
|
|
|
| # ¿ May 14, 2024 16:30 |
|
|
FAT32 SHAMER posted:Great advice, I appreciate it. Yeah I reckon the sane approach here is to not gently caress around with fancy distros. I'm not sure exactly what you mean by this, but you can SSH both into and from SteamOS, not that I would recommend using it as a server OS.
|
|
#
¿
Apr 19, 2024 14:42
|
|