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

Selfhosted

40183 readers
748 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
[–] [email protected] 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.

[–] [email protected] 2 points 5 months ago

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