Basic firewall functionality is a must-have feature

[oficsu]

Motivation

Let's enumerate some key points:

• Yggdrasil is very helpful for a bunch of users, especially for users behind NAT;
• Yggdrasil is easy-to-use solution for non-experts;
• Yggdrasil exposes local services unconditionally to the network;
• exposing ports is dangerous;
• it's easy to forget about the firewall;
• configuring a system-level firewall is hard;
• configuring a system-level firewall correctly is nearly impossible;
• the firewall can easily be misconfigured later while the Yggdrasil instance is still running

Together, these points make Yggdrasil an easy-to-use tool that also shoots unprepared users in the foot by default. And I think easy-to-use tools mustn't shoot users by default despite their declared experimental status, so addressing these security concerns is critical for any networking tool and for Yggdrasil in particular. Basically, the principle of least privilege is currently violated

What I propose

To address these concerns, I propose adding new options to the configuration file that will control the behavior of Yggdrasil over incoming connections. Below are their detailed descriptions

UnrestrictedClients
A list of IPv6 netmasks. Incoming connections from their addresses will be allowed to any local port

If left undefined, then anyone can connect to any local port. The same as now. Should emit a warning, which can be suppressed with 200::/7 mask. If left empty, only connections from AllowedClients to ExposedPorts are accepted. The only reason to have a different behavior for undefined and empty option is backward compatibility with old configs. Should be empty in newly generated configs

AllowedClients
A list of IPv6 netmasks. Incoming connections from their addresses will be allowed to ports specified in ExposedPorts option

If left empty/undefined, then all incoming connections are denied (except connections from UnrestrictedClients). Should be empty in newly generated configs

ExposedPorts
A list of ports exposed to AllowedClients. Maybe it could support port ranges, but I think it's beyond basic functionality and can be implemented later

If left empty/undefined, then all ports are exposed. Should be empty in newly generated configs

Conclusion?

There are two type of users: users struggling to start using Yggdrasil since it requires very broad technical knowledge to ensure their safety and users who don't even bother about the security and readily put themself in danger

Without having to rack their brains about security concerns, the first type is more likely to engage within the project. And, with significantly improved security of newly generated configs, the second type will be secured. Old configurations won't be affected, but the project and both user types will benefit from the changes

P.S. I might consider digging into the code and creating pull request, but firstly I'd like to confirm the feature has a chance

[zod076]

There is a firewall, ip6tables assuming it's Linux. You could:

1. use ip6tables + ipset
2. Don't peer with a public peer
3. Set a password on the Listen option if you want people to peer with you.

[oficsu]

@zod076,

1. use ip6tables + ipset

As I said above, system-wide firewalls have a number of disadvantages:

configuring a system-level firewall is hard;
configuring a system-level firewall correctly is nearly impossible;
the firewall can easily be misconfigured later while the Yggdrasil instance is still running

And the recommendation of ip6tables instead of modern and simpler nftables highlights this very well

2. Don't peer with a public peer
3. Set a password on the Listen option if you want people to peer with you

If I understand correctly, it will require you to have your own peer host with public IP. Then it contradicts the mentioned use case:

Yggdrasil is very helpful for a bunch of users, especially for users behind NAT;

And it doesn't matter if Yggdrasil wasn't designed as a NAT-traversal tool. The fact is that it's the popular use case because Yggdrasil is easy-to-use tool. And in my opinion, defaults should prioritize user safety, even if use cases deviate from original design. In other words, the tool mustn't harm users by default even if someone thinks their use case is wrong

[neilalexander]

This question pops up every now and again, the main problem is that to do any of this, we basically need to embed a userspace IP stack into Yggdrasil (or we'll end up having to basically implement one ourselves). That's a pretty significant maintenance burden for us.

There's a community distribution called Yggstack (https://github.com/yggdrasil-network/yggstack) which uses the gvisor netstack in order to provide connectivity via SOCKS instead of TUN, but netstack is a lot of code, not particularly elegant and the last I checked had problems with ordered prefix matching correctly in its internal routing table.

[EugeneMartein]

That's not Yggdrasil's goal. Close this issue.

[oficsu]

@neilalexander, wouldn’t filtering packets within readPC be enough? Sorry if I'm missing something important here — I've only skimmed through the Yggdrasil code and I'm not deeply familiar with Go or Yggdrasil internals

@EugeneMartein, while security is never a goal of any tool by itself, it's always an important requirement. And most of the issue’s text is devoted to explaining why it's especially important for Yggdrasil, so "not Yggdrasil's goal" can't be the answer to my points

[neilalexander]

It's not just filtering packets, it's also tracking connection state such that return traffic is allowed properly etc, which requires us to be aware of UDP/TCP flows and IP destinations in general. It might also cause us to unintentionally break other protocols (i.e. SCTP) which today work just fine as long as the kernel is happy with them. Firewalls actually track quite a lot of state in order to not break applications and aren't easy at all to get right from an implementation perspective.

[oficsu]

@neilalexander,

it's also tracking connection state such that return traffic is allowed properly

As for basic firewall functionality (and the most important), I think it's sufficient to filter only incoming traffic (since that poses the highest risk) by its source. So in that case, wouldn't return traffic still be handled correctly?

It might also cause us to unintentionally break other protocols (i.e. SCTP)

But don't we already check whether the source address matches its public key? I don't think an extra check on a user-defined mask would break things any more than it does now. Furthermore, if needed, users would be able to... simply not use the firewall; or, if they need more granular filtering, they would have to use system-level firewall just as they do now

[oficsu]

Oh, I've caught the idea about the return traffic. Yes, incoming return traffic would be broken in this case... But at least, it could work as a whitelist of peers with whom we can communicate(?)...