94
submitted 3 weeks ago* (last edited 2 weeks ago) by stratself@lemdro.id to c/selfhosting@slrpnk.net

There is a recently discovered critical vulnerability that affects all Matrix homeservers of the Conduit lineage. If you're using a Rust-based Matrix server (which are basically Conduit and forks), please urgently upgrade to the following versions:

If you're not able to upgrade right now, you should urgently implement this workaround in your reverse proxy.

Attackers exploiting this flaw can arbitrarily kick any user out of a room, join rooms unauthorized on the same server, and can also ban same-server users. They effectively constitute a severe denial of service from an unauthenticated party, and it has been exploited in the wild.

[-] stratself@lemdro.id 3 points 3 weeks ago* (last edited 3 weeks ago)

That doesn't seem to be too old of a laptop at all. One thing I'd say is to use an SSD as the main partition you run your apps on, as HDDs might be quite slow.

If you wanna keep the VPS, you can use it as a public inbound gateway + outbound proxy for your homeserver, so traffic looks like it comes in and out of your VPS. I wrote some notes on setting up Tailscale in such a manner, but there's plenty of other options.

If you don't wanna keep the VPS, you can front your inbound traffic with Cloudflare Tunnels, and use a commercial VPN to act as a proxy for outbounds. If you don't have any apps that make frequent network requests (e.g. a Matrix server), then a VPN may not be necessary

You should leave SSH on, especially if if you wanna run it without a monitor, but use key auth and limit it to your LAN only

[-] stratself@lemdro.id 7 points 1 month ago

How did you exactly install Express on the router? Did you use an app or something of that kind?

If the VPN provider has WireGuard support, you may wanna use a wireguard client software to connect to it. Flash OpenWRT on the router, install and configure a wireguard interface that connects to Express, then forward packets from behind LAN to that interface so they go through the VPN tunnel. A bit tricky for beginners, but I hope you can make it.

Since OpenVPN protocol seems to become unsupported in the future, Wireguard should be the way to go. Mullvad/IVPN should also support it, and once you know how to set it up it should be usable across many services and devices.

Do you recommend installing VPN apps on separate devices instead of the router?

For flexibility I'd do this. In case I'd wanna switch upstream servers for a single device without affecting others.

[-] stratself@lemdro.id 2 points 1 month ago

If you can run WireGuard on all your devices, you may wanna set up a multihop node that forward outbound traffic to the VPN tunnel via that hub

[-] stratself@lemdro.id 4 points 1 month ago* (last edited 1 month ago)

Desec.io is a solid option - it allows for various types of records like TLSA and SRV. It can also generate scoped API tokens e.g. for "only TXT records of the _acme-challenge subdomain of example.com" to use in automated cert renewals, so pretty good for granularity. It's also a nonprofit.

I think selfhosting DNS is beneficial when you wanna control your own DNSSEC keys, but you'd need to account for high availability and safety. With that, you could do what's called a "hidden primary + public secondary" setup to protect your master DNS data from the public prying. You can even use 3rd-party services like ns-global.zone as your secondaries for redundancy and to reduce load on your infra, too. I recommend Technitium and their guidance if you wanna get started

[-] stratself@lemdro.id 3 points 1 month ago

Those are not authoritative DNS providers where you can publish records...

[-] stratself@lemdro.id 6 points 2 months ago

Panasonic Let's Note, SV7 or SZ7 I think. Japanese domestic notebook for enterprises

[-] stratself@lemdro.id 4 points 2 months ago

Try Syncthing with IgnoreDelete but note that it's unrecommended. Maybe use Syncthing as an append-only store

[-] stratself@lemdro.id 3 points 2 months ago

It's entirely possible. If the 2 domains are different, you should look into SNI routing using the TCP router instead of HTTP. With the tls.passthrough flag, encryption is kept intact until it reaches the second proxy.

6
submitted 2 months ago by stratself@lemdro.id to c/selfhosted@lemmy.world

Technitium DNS Server (TDNS) has gotten a new release with many awesome features: TOTP authentication, an upgraded .NET library, and many security and performance fixes.

But most important of all, it now supports clustering. A long-awaited feature, this allows Technitium to sync DNS zones and configurations across multiple nodes, without needing an external orchestrator like Kubernetes, or an out-of-band method to replicate underlying data. For selfhosters, this would enable resilience for many use cases, such as internal homelab adblocks or even selfhosting your public domains.

From a discussion with the developer and his sneak peek on Reddit, it is now known that the cluster is set up as a single-primary/multiple-secondary topology. They communicate via good-old REST API calls, and transported via HTTPS for on-the-wire encryption.

To sync DNS zones (i.e. domains), the primary server provisions the "catalog" of domains, for secondary ones to dynamically update records in a method known as Zone Transfers. This feature, standardized as Catalog Zones (RFC9432), were actually supported since the previous v13 release as groundwork for the current implementation.

As an interesting result, nodes can sync to a cluster's catalog zone, as well as define their own zones and even employs other catalog zones from outside the cluster. This would allow setups where, for example, some domains are shared between all nodes, and some others only between a subset of servers.

To sync the rest of the data such as blocklists, allowlists, and installed apps, the software simply sends over incremental backups to secondaries. The admin UI panel is also revamped to improve multi-node management: it now allows logging in to other cluster nodes, as well as collating some aggregated statistics for the central Dashboard. Lastly, a secondary node can be promoted to primary in case of failures, with signing keys also managed within for a seamless transition of DNSSEC signed zones.

More details about configuring clusters is to be provided in a blogpost in the upcoming days. It is important to note that this feature only supports DNS stuff, and not DHCP just yet (Technitium is also a DHCP server). This, along with DHCPv6 and auto-promotion rules for secondaries, is planned for the upcoming major release(s) later on.

As a single-person copyleft project, the growth of this absolute gem of a software has been tremendous, and can only get better from here. I personally can't wait to try it out soon

Disclaimer: I'm just a user, not the maintainer of the project. Information here may be updated for correctness and you can repost this to whatever

3
submitted 2 months ago* (last edited 2 months ago) by stratself@lemdro.id to c/selfhosted@lemmy.world

Hi all, I made a simple container to forward tailscale traffic towards a WireGuard interface, so that you can use your commercial VPN as an exit node. It's called tswg

https://github.com/stratself/tswg

Previously I also tried Gluetun + Tailscale like some guides suggested, but found it to be slow and the firewall too strict for direct connections. Tswg doesn't do much firewalling aside from wg-quick rules, and uses kernelspace networking which should improve performance. This enables direct connections to other Tailscale nodes too, so you can hook up with DNS apps like Pi-hole/AdguardHome.

I've shilled for this previously, but now I wanna promote with an actual post. Having tested on podman, I'd like to know if it also works on machines behind NATs and/or within Docker. Do be warned though that I'm a noob w.r.t. networking, and can't guarantee against IP leaks or other VPN-related problems. But I'd like to improve.

Let me know your thoughts and any issues encountered, and thank you all for reading

[-] stratself@lemdro.id 4 points 2 months ago

If it ain't broke, don't fix it. I think it's better hooking up Element Call to your current setup, and remove Element Web if you can BYO client.

For a more lightweight alternative, I personally find continuwuity to be reasonably stable for the specs you mentioned. It does admin tasks in an #admins room, use an embedded database, and has no client UI so less containers needed. So continuwuity + EC should be able to run under the constraints you mentioned

The lightest would still be any XMPP server, though its functionality does differ from Matrix overall

[-] stratself@lemdro.id 3 points 3 months ago

You should add your DNS forwarder as its own node in Tailscale, and configure the tailnet to resolve DNS through it. That way you'll be able to resolve both MagicDNS node names and your local domains, as well as being blocklist-enabled. Besides, I think you can also define custom A/AAAA records on your Tailscale console, skipping local records on Pi-hole altogether.

I'd also recommend Technitium for a new DNS solution, mainly because they're going to add support for clustering soon. This could be highly useful if you want to configure blocklists once and sync them between different Technitium nodes. Should it works out, I'm thinking of installing it alongside every Tailscale exit node, for the benefit of synced blocklists, local domains, and exit-node geolocated IPs for external domains.

[-] stratself@lemdro.id 2 points 4 months ago* (last edited 4 months ago)

Let's Encrypt are rolling out IP-based certs, you may wanna follow its development. I'm not sure if it could be used for your forwarded VPN port, but it'd be nice anyhow

Edit: I believe encryption helps prevent tampering the data between the server and user too. It should prevent for example, someone MITM the connection and injecting malicious content that tells the user to download malware

[-] stratself@lemdro.id 3 points 5 months ago

Owncloud had a rewrite called oCIS (Owncloud Infinite Scale). Then it was bought by Kiteworks. Then many of the core devs switched to a new product/company called Opencloud. There's been quite some history over the past few years

15
submitted 5 months ago by stratself@lemdro.id to c/selfhosted@lemmy.world

Hi all. Per the title, I'm looking for something that:

  • Can run as an unprivileged user inside a container

  • Allows OpenID Connect authentication for a multiuser setup

  • Doesn't take hostage of my CPU

Homarr and Dashy are featureful solutions, but they can't run unprivileged in docker. Dashy closed this issue, but in fact it's not resolved. Meanwhile Homarr does work with UID/GID env vars, but starting as root and dropping capabilities is not the same as defining user: 1234:1234 from the get-go. Furthermore, they are really heavy node apps, which kinda deter me from deploying.

I neither wanna use my reverse proxy with forward auth or having an extra oauth2-proxy container, so Organizr (using forwarded auth headers) or Homer/Homepage/bunch of static pages behind a reverse proxy is out of scope.

Feature-wise I'm just looking for a beautified link keeper, preferably with multiple dashboard mapped to different user groups (ideally it could be done via custom OAuth metadata/claims). Fancy plugins like RSS and weather are not needed, but appreciated.

With all that said (and sorry if I'm too choosy), is there a current solution that fits the bills above? My IDP's UI is quite rudimentary, but I can resort to using it as a "homepage". I wanna thank in advance for any guidance

P/S: Seems like most dashboards fall into two categories - bloated fancy apps, or dead simple frontpages. It'd be nice to have something inbetween.

view more: next ›

stratself

joined 5 months ago