|
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
|
|
|
|
| # ? May 28, 2024 21:59 |
|
|
Quixzlizx posted: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. What about "curl -k https://ip" ?
|
|
#
?
Sep 22, 2023 03:49
|
|
|
It sounds like your httpd config doesn't have the right declarations, can you share your config? Do remember to elide identifiable information.
|
|
#
?
Sep 22, 2023 14:28
|
|
|
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
|
|
|
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". If you don't write a domain but only tell the client "please connect to 1.2.3.4 with HTTPS", it's going to want the server to have a valid certificate for that IP, which I don't think is possible and in any case Let's Encrypt doesn't issue those. You would need to tell Caddy to generate a self-signed certificate, and then configure the client to accept it, which on modern browsers is made intentionally difficult for obvious security reasons. If you just want a catch-all, I think you can tell Caddy to force unencrypted HTTP in that :443 no-domain block? It's still weird and unexpected though, the connection error is the " normal " behaviour. NihilCredo fucked around with this message at 17:59 on Sep 23, 2023 |
|
#
?
Sep 23, 2023 17:56
|
|
|
Speaking of, the pattern “https to the reverse proxy and the http to the service” is largely fine, correct?
|
|
#
?
Sep 23, 2023 17:59
|
|
|
Warbird posted:Speaking of, the pattern “https to the reverse proxy and the http to the service” is largely fine, correct? Not only fine, very typical. In datacenter scale installs we used to use reverse proxies that function as SSL offload and load balancing to the servers behind it (The good old days of the F5 BigIP LTM). Now a lot of cloud based load balancers are SSL to nginx with a cert and straight http to the cluster behind it. This is fine if you control the network behind your load balancer/proxy, obviously. There are (strange) scenarios where that may not be the case.
|
|
#
?
Sep 23, 2023 18:04
|
|
|
That’s what I figured but you know what they say about assumptions.
|
|
#
?
Sep 23, 2023 18:08
|
|
|
Warbird posted:Speaking of, the pattern “https to the reverse proxy and the http to the service” is largely fine, correct? Assuming the connection between the reverse proxy and the service is secure, yes. Even if it isn't, a reverse proxy is gonna be more reliable at managing HTTPS than whatever service you're running, so you'd want to keep the HTTPS termination there and just protect the backend connection with a VPN. The only time I would not want the reverse proxy to terminate HTTPS is if it's running on someone else's infra, eg Cloudflare.
|
|
#
?
Sep 23, 2023 18:12
|
|
|
Warbird posted:Speaking of, the pattern “https to the reverse proxy and the http to the service” is largely fine, correct? Depends entirely where the service is. And probably what it is. On the same server, sure. Same private network, maybe. Different server/network but same "datacenter"? Probably not.
|
|
#
?
Sep 23, 2023 18:36
|
|
|
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
|
|
|
Quixzlizx posted: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. To clear a potential misconception: the standard purpose of HTTPS and certificates is a security measure against potential men-in-the-middle interfering in the communication between your server and a (legitimate) client. They are irrelevant against an attacker who acts as a client, because their purpose is to prove to the client that the server is really yours. If you want to use HTTPS to block unauthorized clients, you need to look into "client certificates", where you install specific certs on authorised client devices and the server validates that, and nobody else can use your services. Caddy supports them if you want. But a VPN like Tailscale is generally an easier way to get the same result.
|
|
#
?
Sep 23, 2023 19:19
|
|
|
Quixzlizx posted: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. Anything exposed to the internet is going to get hammered in a variety of unexpected ways, security isn't a single big wall and iron gate, caddy and any other internet facing service shouldn't be your one security measure. The phrase "defense in depth" exists for a reason. Caddy is vulnerable to exploitation, either via misconfiguration or CVE, as is whatever its talking to. Unless there is some auth mechanism its likely at some point some bot or bored attacker (or upset user who previously had access) is going to bypass Caddy. What happens then? Make sure your backend server / service is also hardened, ideally you would also have all of this on a separate DMZ and internal network, to limit the rest of your network. The goal is to limit the blast radius of a potential exposure, not make an impenetrable gate, because there is no such thing.
|
|
#
?
Sep 23, 2023 19:47
|
|
|
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
|
|
|
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.
|
|
#
?
Sep 23, 2023 20:42
|
|
|
Quixzlizx posted: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. If you're using docker (or podman) you can add all your services to the same docker network and only permit the reverse proxy's ports out. That will create a little DMZ for your services in the docker network separated from your local network. You would need to host a local dns server to direct traffic to your reverse proxy though. edit: you can also use iptables to restrict direct ip access to your services to just your reverse proxy too. https://docs.docker.com/network/packet-filtering-firewalls/ Nitrousoxide fucked around with this message at 20:45 on Sep 23, 2023 |
|
#
?
Sep 23, 2023 20:43
|
|
|
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
|
|
|
Quixzlizx posted:I do have fail2ban set up so someone can't get into Foundry directly by brute-forcing credentials. 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
|
|
|
Quixzlizx posted:I do have fail2ban set up so someone can't get into Foundry directly by brute-forcing credentials. I dont know about caddy specifically but you could do some sort of IP based whitelist using DNS lookups for foundary.com if thats what you're trying to say? To only allow communication between Caddy and foundary.com? You'd be better off using your firewall but with nginx, https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-access-proxied-tcp/ Even so the points I made above are still valid, maybe its worth the risk to you, but foundary.com can be compromised, see it communicates a lot with caddy, then have an open door into whatever is behind caddy. Unless you are unlucky or very popular its probably not going to happen having these basic security measures in place its just wise to be aware of the risks and have some additional protections in place for it. You do find blogs all the time of people getting owned like this.
|
|
#
?
Sep 23, 2023 21:10
|
|
|
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
|
|
|
Your network topology should be such that nothing outside of your network can access Foundry except by going through the reverse proxy. Port 443 should not be forwarded to your foundry server, it should be forwarded to your reverse proxy, which should be configured such that it only forwards HTTP requests that include HOST: foundry.example.com or whatever and 403s the rest.
|
|
#
?
Sep 23, 2023 21:44
|
|
|
Personally I would just drop the connection without responding if its not asking for foundry.mysite.com, in nginx you can code:http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return
|
|
#
?
Sep 23, 2023 22:03
|
|
|
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
|
|
|
Quixzlizx posted: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. Ahh, right. To be clear what other people are saying is you can subvert that with code:
|
|
#
?
Sep 23, 2023 22:23
|
|
|
Mr. Crow posted:Personally I would just drop the connection without responding On the scale of self hosting, making a response that says "we're not gonna layer 7 together" after you've already done all the rest you need to make that decision doesn't sound like it really matters.
|
|
#
?
Sep 23, 2023 22:57
|
|
|
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. 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
|
|
|
If you're only hosting one or two things and are using cloudflare already to proxy the domain via cloudflare DNS you may be better off just setting up a cloudflare tunnel right to whatever you're selfhosting and foregoing a reverse proxy and exposing a port on your network at all.
|
|
#
?
Sep 24, 2023 04:12
|
|
|
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
|
|
|
THF13 posted:If you're only hosting one or two things and are using cloudflare already to proxy the domain via cloudflare DNS you may be better off just setting up a cloudflare tunnel right to whatever you're selfhosting and foregoing a reverse proxy and exposing a port on your network at all. Yeah just do what THF13 says above (quoted). If you don't want to do that (it's a slight pain in the rear end to setup, but then you can leverage more of their zero trust stuff) - you can use CF's list of IPs https://www.cloudflare.com/en-gb/ips/ to put a filter and drop anything else, but that's more to maintain.
|
|
#
?
Sep 24, 2023 17:30
|
|
|
Some of the cloudflare tunnel stuff can be confusing because it's very similar to their DNS proxy feature, and there's lots of guides and tutorials that will come up when searching either for that or just with outdated information on setting up cloudflare tunnels. This one goes through the tech, does some basic setup from start to finish, and shows off some of the cooler things you can do with it, like a basic 2 step feature that allows access based on email domain. https://www.youtube.com/watch?v=eojWaJQvqiw
|
|
#
?
Sep 24, 2023 17:40
|
|
|
From this conversation I've learned that Authelia exists and I think that would be super useful to me, if I can figure out how to get to talk to jellyfin/gonic/calibre-server/codex/etc.
|
|
#
?
Sep 24, 2023 17:45
|
|
|
ToxicFrog posted:From this conversation I've learned that Authelia exists and I think that would be super useful to me, if I can figure out how to get to talk to jellyfin/gonic/calibre-server/codex/etc. It doesn't support SAML or anything so you don't need it to talk to the services. Generally you set it from your reverse proxy.
|
|
#
?
Sep 24, 2023 17:51
|
|
|
Matt Zerella posted:It doesn't support SAML or anything so you don't need it to talk to the services. Generally you set it from your reverse proxy. My understanding (based on a quick read of the Authelia docs) is that for the "single" part of "single sign-on" to work, the reverse proxy needs to have something to pass to the backend service, based on its interaction with the IAM, that the service will recognize as carrying authentication information. This might be openID stuff, or a special header containing the name of the authenticated user, or http basic-auth headers, or the like, but it needs something unless the backend service doesn't support authentication at all. Otherwise you don't have SSO, you have a setup where you sign into Authelia and then you sign in again to whatever service you're trying to access. And Authelia has loads of service-specific documentation pages for various services that use different mechanisms for this, but almost none of the services I actually run are listed.
|
|
#
?
Sep 24, 2023 18:21
|
|
|
Not recommending one over the other, but Authentik is another service that exists and fulfills a very similar role to Authelia. Really just mentioning it so you can look at both before setting up one and realizing you want to use the other. The main thing I'd want to put behind one of those myself would be Emby, but while you can get this working with the web it will break any mobile/tv/set top apps that use an app to connect. I'd guess Jellyfin would have a similar limitation, but it being open source, who knows?
|
|
#
?
Sep 24, 2023 18:35
|
|
|
ToxicFrog posted:My understanding (based on a quick read of the Authelia docs) is that for the "single" part of "single sign-on" to work, the reverse proxy needs to have something to pass to the backend service, based on its interaction with the IAM, that the service will recognize as carrying authentication information. This might be openID stuff, or a special header containing the name of the authenticated user, or http basic-auth headers, or the like, but it needs something unless the backend service doesn't support authentication at all. Otherwise you don't have SSO, you have a setup where you sign into Authelia and then you sign in again to whatever service you're trying to access. And Authelia has loads of service-specific documentation pages for various services that use different mechanisms for this, but almost none of the services I actually run are listed. I've got my home network stack fully protected by Aithelia and for most of the endpoints protected by it I disable the built in auth. I don't want to do the double login part. Hopefully one day the Arrs will support SAML or OID. This is all internal I don't expose anything at home except the plex port and I have Overseerr going out over a cloud flare tunnel which is protected by plex SSO.
|
|
#
?
Sep 24, 2023 18:37
|
|
|
I use Authelia with Ngnix Proxy Manager and I pretty much just stole the configuration text from a YouTuber and pasted in my docker containers’ info where it said to. It’s a lot of complex configuration text but if you’re just looking to secure some lowish risk stuff I’ve liked it
|
|
#
?
Sep 24, 2023 20:06
|
|
|
This talk got me to sit down and update my docker stacks to use networks or localhost for the http traffic behind the reverse proxy wherever possible. I was able to make about half of my services completely inaccessible without going through the reverse proxy locally. There's a few that require different network modes, so I don't think I can really use docker networks for them and I don't feel like messing with the ip tables so I'll leave those be. Took some traffic off the lan and hopefully sped things up a bit on those services I could change at least.
|
|
#
?
Sep 24, 2023 22:07
|
|
|
Matt Zerella posted:I've got my home network stack fully protected by Aithelia and for most of the endpoints protected by it I disable the built in auth. I don't want to do the double login part. Hopefully one day the Arrs will support SAML or OID. So, the issue (or, well, an issue) is that I basically have four categories of browser-accessed services: (1) doesn't have built in auth but is meant to be public anyways, like share-by-link web hosting; (2) doesn't have built in auth but needs to have restricted access, like Munin's web dashboard; (3) has built in auth but I'm the only person who ever uses it, like the bittorrent status dashboard; (4) has built in auth and multiple family members use it, like jellyfin. (1) is irrelevant here, and (2) can be handled just by putting it behind some login screen with no further complication. (3) can be handled the same as (2) if there's some way to disable authentication on it, or hardcode some headers in the reverse proxy to tell it who is logged in, which there usually is. (4) is the problem here -- it matters whether (e.g.) it's me, my wife, or my daughter logged into jellyfin, both because different users have different libraries accessible and because because it tracks things like watched/unwatched flags per-user. I could kind of halfass it by using an IAM for (2) and (3) and leaving everything in category (4) to handle its own auth, but it would be nice if, say, logging into Jellyfin also meant you were logged into Airsonic and Codex automatically.
|
|
#
?
Sep 25, 2023 00:32
|
|
|
I'm trying to better segregate my 2 internet facing services in the event of one being compromised and escaping the Docker container (see the issue with a single Emby setting causing no-password logins by spoofing headers. Not a Docker escape but still sketchy). Right now all my local-only services are running on the same VM with my internet facing ones, but the internet facing ones are on a different VLAN. I'm going to move to running the two internet facing services (Joplin and Emby) to a separate Debian VM entirely along with staying on the separate VLAN (VLAN tag is applied at the hypervisor level so the VM can't change it). Emby would have an NFS port opened through the firewall to my NAS VM (the NFS share is read only), otherwise it would have no access back to my normal VLAN. Joplin data is encrypted and only decrypted on the clients. I know I should be using Podman, but some of the differences (rootless networking/slirp4netns slower than normal, quadlets more annoying than Docker compose/Portainer, permissions issues/uid mapping, etc) combined with the lack of documentation/examples compared to Docker turned me off. It seems like a Docker escape is relatively rare unless you do something really dumb like mount the Docker socket in the container, and VM escapes are even more rare. I'd run a VPN 24/7, but the Emby clients for family have no way of navigating that. Is there anything else I should be doing or considering?
|
|
#
?
Sep 28, 2023 04:59
|
|
|
|
| # ? May 28, 2024 21:59 |
|
|
I too occasionally think “I should switch my docker stuff over to podman” but then I look at my 40+ containers already running perfectly fine and decide to touch grass instead. I did move my two Ubuntu pihole/docker vms to CoreOS Podman vms so I could set them to auto update everything automatically so I never have to touch them again or worry about poo poo blowing up on a LTS version change though.
|
|
#
?
Sep 28, 2023 05:07
|
|