Self-hosting overview page #1686
Comments
jonaharagon
added
c:guides
|
Would be amazing to have a section in knowledge base about self hosting. |
|
I only learned about self-hosting through the privacy community and something that wasn't immediately clear was that I'd be almost entirely responsible for the security of my self-hosted stuff. It's kinda obvious (viz. "self-hosting") but, as an amateur, beginner's guide-type searches mostly yielded either detailed technical walkthroughs (some of which are great, but I didn't know enough to even get started) or 'idk just use Docker and port forward'. For an overview, it might be helpful to point out what seem like really basic considerations: being responsible for security, and/or investing trust in providers or tools you use. I would certainly have found it helpful and it could be good to include regardless of any advice or recommendations. |
|
@KaiTebay exactly that was/is my concern with it not being there right now and why I opened https://github.com/privacyguides/privacyguides.org/discussions/1677 |
|
Something I'd like to cover wrt self-hosting is alternatives to Cloudflare. CF provides a lot of services all-in-one and I'm not sure if any other company really does what they do, but it would be cool to find a lot of individual services that together provide a comparable feature-set. Especially since it wouldn't require an MITM on your connection :) If anyone has any thoughts on authoritative DNS servers, CDNs, static site hosts, cloudflare tunnel alternatives, etc. please share! |
|
https://desec.io/ from https://pleroma.envs.net/notice/AMPxDYkBioJ2lLJ2sC Looking forward for more recommendations from any users! |
|
I know of an anti-DDOS alternative named Qbine by Serverius https://serverius.net/qbine/ @jonaharagon |
|
I haven't come to any conclusions of my own yet. I'm not sure about trying desec.io because I'm more interested in running my own nameserver (using PowerDNS) since I'm already using a VPS. But running my own nameserver with DNSSEC isn't exactly something I've done before, so I don't want to rush it.
|
|
This is the sort of thing that blurs the line between security and other areas.
Regarding non-managed hosting in general: I'm planning on eventually making a write-up on my server configs. Here's some of my brainstorming:
Areas I'm not certain about yet:
- Best ACME client. I'm looking into migrating to lego since it's a single binary (I want to keep everything I can to statically-linked binaries because it makes it easy to give them their own root directory in a hardened Systemd unit file). I think it supports TLS-APLN based renewals.
- I need a simple way to generate certs with a max lifetime *shorter* than 90 days. I think this is possible with acme.sh. IMO, the best lifetime for now is probably 60 days, with an auto-renewal every 30 days. If that works without issues for a year, you could shorten it to 30 days with a renewal every two weeks.
- The BoringSSL/OpenSSL tradeoff when building programs like Nginx. BoringSSL is smaller, simpler, and more secure; however, OpenSSL allows you to include OpenSSL commands in your Nginx configs. This enables useful features like TLS record padding to reduce the effectiveness of traffic analysis to determine pages visited.
Areas I'm more sure of:
- Use certbot-ocsp-fetcher, nginx-rotate-session-ticket-keys, Nginx, and an ACME client with auto-renewal for the best balance of perf + security
- Performance tuning is a security measure, since being able to handle several thousand req/sec should help you weather low- to mid-effort (D)DoS attacks (not high-effort DDoS attacks with hundreds of thousands---or millions---of req/sec). I listed some methods here: https://pleroma.envs.net/notice/AMVqR6uCUJ7zkLGOeW. I don't know as much about how to approach kernel parameter tuning (like what GrapheneOS infrastructure does)
- How to handle internal pages. Eliminating low-effort bot traffic will make it easier to notice an attack. I think that for pages only used by admins, compatibility is much less of an issue. They can be on a subdomain that uses a single TLS 1.3 cipher set and only supports ipv6, with no port-80 access. This isn't a robust security measure but it will have a nice side-effect of wiping out 95% of bot traffic without having to do anything at all on the client-side. Atop this, you could implement a simple measure of your choice (OAuth, mTLS, VPN, etc).
- If you're willing to put in the effort: keep distro packages to a minimal stable base and build statically-linked binaries yourself. Static binaries make sandboxing/confinement easier. That way, you can enable auto-updates for system packages without worrying too much about instability since it's just really "boring" packages like glibc, Systemd, etc. rather than the actual services you run.
- Set up notifications for error reports and performance issues.
- Have two sets of configs: one "regular" config that balances security and perf, and one "high-traffic" config that shifts the balance in favor of perf. If you get notified of perf problems, you can activate perf mode that makes some tradeoffs (kTLS, perf-oriented malloc, 0-RTT, etc)
Specifically regarding self-hosting, there's a lot of overlap between security and other concerns:
- Set up a Wireguard-based approach to access your network from afar
- Monitor your traffic. If your traffic isn't too high, your ISP will probably look the other way.
- Hardware considerations. For most users, power-consumption will be a concern. For heavier workloads and to bump up the req/sec (e.g. if you're running a Matrix server with 100s of users and you regularly get Reddit front-page traffic on large pages), a simple SBC might not cut it.
- Consider using a cheap webcam for video surveillance of the machine.
|
|
Thanks a lot for your time! |
|
I'd be keen to see the FreedomBox moved from Filesharing and Sync to this page. An extension of this page could be #1902 |
|
If you're going to self host you're going to need a domain: https://github.com/privacyguides/privacyguides.org/discussions/1506 so I think we should have a sub portion of this page perhaps about some domain registrars. I think we should talk about proxy registrars (like njalla), vs using something like Cloudflare with domain privacy enabled. I think for most people the latter is a better choice. |
|
UnifiedPush https://github.com/privacyguides/privacyguides.org/discussions/1437 I think this could be a part of this, as there's really only any privacy gained if you're running your own push service. There are some apps we recommend which do work with it https://unifiedpush.org/users/apps/ |
|
This issue has been mentioned on Privacy Guides. There might be relevant details there: https://discuss.privacyguides.net/t/rss-reader-recomendation/10989/11 |
|
Another semi related one is https://github.com/privacyguides/privacyguides.org/discussions/177 It's designed to be self hosted, as Google usually blocks public proxies. Has more Google specific functionality. |
|
Another one related to this would be Blobbackup/Blobbackup#95 if we decide to use it in #1740. |
|
This issue has been mentioned on Privacy Guides. There might be relevant details there: https://discuss.privacyguides.net/t/private-networking-category-software-defined-networks/11766/4 |
|
This issue has been mentioned on Privacy Guides. There might be relevant details there: https://discuss.privacyguides.net/t/projects-for-a-multiple-vpn-use/17225/4 |
|
This issue has been mentioned on Privacy Guides. There might be relevant details there: |
I think we have a consensus on adding this page to our knowledge base:
Originally posted by @jonaharagon in https://github.com/privacyguides/privacyguides.org/discussions/1677#discussioncomment-3451852
The text was updated successfully, but these errors were encountered: