limit Client Server trust

[Darin755]

Is your feature request related to a problem? Please describe. I'm a little concerned with the level of trust that netbird puts onto the server and the network operator. I know its convenient to allow some control of the clients though the dashboard but I think this could be easily misused to harm the clients that aren't servers

Describe the solution you'd like I would be nice to have a "don't trust the server" option when installing netbird that would block connections to the local client at the client level. This would protect labtops and desktops that usually don't have as good as security compared to servers.

Other considerations I am also a little worried about the power entrusted to the server. Creating a single server that connects everything could allow a corrprate network to be compromised though one single machine. I know that netbird can't protect against third party services running on clients but I think its a good idea to make the clients assume the server has already been compromised.

[mlsmaycon]

Thanks for your request @Darin755, can you share a bit more of how you see the "don't trust the server" working?

We are working on better ACLs at the moment which will control inbound access to clients and we will add flags to disable SSH and DNS at the client level.

[Darin755]

• Its great that you're adding ACL's but they wouldn't fix the issue. My fear is that the netbird server will become a high value target for an attacker who want to harm an individual or organization. Currently netbird puts all of the trust into one server and when that server gets compromised it could be used to compomise every device in the network. What I would like to see is a more distributed approach to security that spreads out the potencial attack vectors so that there isn't a centralized attack point

• I recently been using i2p for remote access. Its design is overly complicated for what netbird is trying to do but I think netbird could learn something from i2p. One of the biggest benifits of i2p is its zero trust architecture. I would like to see netbird add the ability to have multiple servers that talk to each other over a a secure channel. Each server should be setup in a way that doesn't give it power over the other servers. If one server is compromised it shouldn't beable to cause to much damage.

[mlsmaycon]

Thanks, @Darin755 for sharing more about your concerns, which are definitely helpful for us to build a better system.

We are always considering and researching options to improve security in the system while keeping usability simple and more updates towards that will come in the following months.

Regarding the trust with the management server, I forgot to mention in the previous message that we have the option to use Wireguard's pre-shared keys with the flag --preshared-key to control tunnel establishment.

[CrimsonFez]

I was considering using netbird, but the inability to disable the integrated ssh server in the client is a deal breaker.

[FHRNet]

I unfortunately consider this a failure point for any business-type environment deployment as well, the ability for a compromised server or a malicious employee to directly affect the security of connected client-only devices like laptops is a show stopper.

I think that blocking all incoming connections at the client level, in addition to being able to completely disable the SSH functionality would indeed help to mitigate the consequences of compromises.

I fully understand the push for simplicity, but I don't think it should come at the cost of deviating from established best security practices; i.e. the ability to centrally enable SSH on unsuspecting devices seems to go directly against zero-trust / trust-nothing principles into the territory of placing all the trust into a single potential point of entry for a malicious actor.

I would maybe also like to propose some simple client-side ACLs that can be hardcoded in the clients as well. So for example, being able to specify that only incoming connections towards local port 1234/tcp should be permitted from the rest of the network regardless of any global configuration (with the inability to change this anywhere but directly on the client) might be helpful in environments with a higher focus on security.

As a use case, let's say I want to be able to expose a single local HTTP development port on my laptop from time to time to showcase a demo application to coworkers. It's fine to trust NetBird's central ACL system to determine who should be able to access the single port. However, under no circumstances should things like SMB or other services that might be listening on the device itself, be exposed towards the rest of the network.

Thank you everyone for the great work so far! I'm looking forward towards any future developments in this regard.

[Darin755]

I think the easiest way to lockdown netbird is to use the host os firewall.

[jonathanspw]

+1

[1doce8]

+1 The inability to set up a client for outgoing connections only in Netbird client and the ability to enable ssh server on the client is a deal breaker for me