this post was submitted on 19 May 2024
24 points (96.2% liked)

Selfhosted

40183 readers
1008 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
 

Hey everyone,

My personal server of choice is a DiskStation right now, and I'm using the default reverse proxy for all my subdomains. I went through a few stages to secure them, and now that I'm finally finished (famous last words heh?!) I thought I'd document my approach and provide some configs and code. I've seen a few unanswered questions here and there about how to do this on Synology, so hopefully this helps a few people.

The guide covers limiting access to local IPs, as well as adding Basic or SSO authentication. The main goal is to integrate well with the GUI and access control profiles, and to leave all existing and autogenerated files untouched, so updates and changes via the GUI still work as expected.

Here is the basic idea:

The nginx server config is located in /etc/nginx/, and the reverse proxies are defined in the sites-available/server.ReverseProxy.conf file inside that folder. There's one server directive for every proxied site, and the DSM config adds a include .acl.<random string>.conf* directive if you set up an access control profile for a site. That * at the end there is crucial, because it means we can manually add more configuration files with the same prefix, and they will automatically be included and applied to all sites using this access control profile.

There are also include directives for the main and http scopes, as well as for the default DSM server directives. This means we can inject configurations in these places, just by adding correctly named files to the conf.d folder.

For Single Sign-On (SSO) authentication we run a Vouch-Proxy instance to handle the communication between nginx and the OIDC server. We also need to spin up another nginx reverse proxy and forward requests to it, because the built-in one doesn't support the required auth_request directive. Its container script just copies the default reverse proxy configuration with some modifications, and it is set up to reload whenenver the original file changes.

Link

no comments (yet)
sorted by: hot top controversial new old
there doesn't seem to be anything here