this post was submitted on 27 May 2024
48 points (94.4% liked)

Selfhosted

40201 readers
764 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
 

Hi!

I often read suggestions to use something like Tailscale to create a tunnel between a home server and a VPS because it is allegedly safer than opening a port for WireGuard (WG) or Nginx on my router and connecting to my home network that way.

However, if my VPS is compromised, wouldn't the attacker still be able to access my local network? How does using an extra layer (the VPS) make it safer?

you are viewing a single comment's thread
view the rest of the comments
[–] cheddar@programming.dev 5 points 5 months ago (1 children)

Quite often I see replies like "don't open ports, use tailscale". Maybe they mix different reasons and solutions, confusing people like me :D

[–] Trainguyrom@reddthat.com 3 points 5 months ago (1 children)

The really nice thing about tailscale for accessing your hosted services is absolutely nothing can connect without authentication via a professionally hosted standard authentication, and there's no public ports for script kiddies to scan for, spot and start hammering on. There's thousands of bots that do nothing but scan the internet for hosted services and then try to compromise them, so not even showing up on those scans is a good thing.

For example, I have tailscale on my Minecraft server and connect to it via tailscale when away from home. If a buddy wants to join I just send a link sharing the machine to them and they can install tailscale and connect to it normally. If for some reason buddy needs to be cut off, I can just stop sharing to that account on Tailscale and they can no longer access the machine.

The biggest challenge of tailscale is also it's biggest benefit. Nothing can connect without connecting through the tailscale client, so if my buddy can't/won't install tailscale they can't join my Minecraft server

[–] melmi@lemmy.blahaj.zone 2 points 5 months ago* (last edited 5 months ago) (1 children)

WG uses UDP, so as long as your firewall is configured correctly it should be impossible to scan the open port. Any packet hitting the open port that isn't valid or doesn't have a valid key is just dropped, same as any ports that are closed.

Most modern firewalls default to dropping packets, so you won't be showing up in scans even with an open WG port.

[–] Trainguyrom@reddthat.com 0 points 5 months ago (1 children)
[–] melmi@lemmy.blahaj.zone 1 points 5 months ago* (last edited 5 months ago) (1 children)

Yes, but only if your firewall is set to reject instead of drop. The documentation you linked mentions this; that's why open ports are listed as open|filtered because any port that's "open" might actually be being filtered (dropped).

On a modern firewall, an nmap scan will show every port as open|filtered, regardless of whether it's open or not.

Edit: Here's the relevant bit from the documentation:

The most curious element of this table may be the open|filtered state. It is a symptom of the biggest challenges with UDP scanning: open ports rarely respond to empty probes. Those ports for which Nmap has a protocol-specific payload are more likely to get a response and be marked open, but for the rest, the target TCP/IP stack simply passes the empty packet up to a listening application, which usually discards it immediately as invalid. If ports in all other states would respond, then open ports could all be deduced by elimination. Unfortunately, firewalls and filtering devices are also known to drop packets without responding. So when Nmap receives no response after several attempts, it cannot determine whether the port is open or filtered. When Nmap was released, filtering devices were rare enough that Nmap could (and did) simply assume that the port was open. The Internet is better guarded now, so Nmap changed in 2004 (version 3.70) to report non-responsive UDP ports as open|filtered instead.

[–] Trainguyrom@reddthat.com 2 points 5 months ago

Huh! Thank you very much for the detailed answer that's extremely interesting!