Selfhosted

51947 readers

1108 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:

Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
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.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.

Resources:

selfh.st Newsletter and index of selfhosted software and apps
awesome-selfhosted software
awesome-sysadmin resources
Self-Hosted Podcast from Jupiter Broadcasting

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago

MODERATORS

HybridSarcasm@lemmy.world

HybridSarcasm@lemmy.hybridsarcasm.xyz

What's the real danger of opening ports? (feddit.it)

submitted 19 hours ago by dontblink@feddit.it to c/selfhosted@lemmy.world

43 comments fedilink hide all child comments

Some services run really good behind a reverse proxy on 443, but some others can really become an hassle.. And sometimes just opening other ports would be easier than to try configuring everything to work through 443.

An example that comes to my mind is SSH, yeah you can use SSLH to forward requests coming from 443 to 22, but it's so much easier to just leave 22 open..

Now, for SSH, if you have certificate authentication or a strong password, I think you can feel quite safe, but what about other random ports? What risks I'm exposing my server to if I open some of them when needed for a service? Is the effort of trying to pass everything through 443/80 worth it?

you are viewing a single comment's thread
view the rest of the comments

[–] Onomatopoeia@lemmy.cafe 2 points 4 hours ago

Others have clarified, but I'd like to add that security isn't one thing - it's done in layers so each layer protects from potential failures in another layer.

This is called The Swiss Cheese Model. of risk mitigation.

If you take a bunch of random slices of Swiss cheese and stack them up, how likely is there to be a single hole that goes though every layer?

Using more layers reduces the risk of "hole alignment".

Here's an example model:

So a router that has no open ports, then a mesh VPN (wireguard/Tailscale) to access different services.

That VPN should have rules that only specific ports may be connected to specific hosts.

Hosts are on an isolated network (could be VLANS), with only specific ports permitted into the VLAN via the VPN (service dependent).

Each service and host should use unique names for admin/root, with complex passwords, and preferably 2FA (or in the case of SSH, certs).

Admin/root access should be limited to local devices, and if you want to get really restrictive, specific devices.

In the Enterprise it's not unusual to have an admin password management system that you have to request an admin password for a specific system, for a specific period of time (which is delivered via a secure mechanism, sometimes in person). This is logged, and when the requested time frame expires the password is changed.

Everyone's risk model and Swiss cheese layering will fall somewhere on this scale.