imported>TechCorner-Redaktion: Neuer Artikel: NetBird (Zero Trust, WireGuard, Self-Hosting), Stand 10/2026

2026-10-05T00:00:00Z

Neuer Artikel: NetBird (Zero Trust, WireGuard, Self-Hosting), Stand 10/2026

Neue Seite

{{Steckbrief
| gilt_fuer = NetBird ab Version 0.53 (Cloud oder selbst gehostet), Clients für Linux, Windows, macOS, Android, iOS, OPNsense/pfSense
| bereich = IT-Security
| dauer = ca. 30 Minuten (Self-Hosting-Quickstart inkl. erstem Peer)
| rechte = root/sudo auf dem Server, Administrator auf den Clients
| stand = Oktober 2026
}}
'''NetBird''' ist eine Open-Source-Plattform für '''Zero-Trust-Netzwerke auf Basis von [[WireGuard]]''': Statt eines zentralen VPN-Gateways, über das der gesamte Datenverkehr läuft, baut NetBird ein verschlüsseltes '''Mesh-Netzwerk''' auf, in dem sich Server, Arbeitsplätze, Smartphones und ganze Standorte direkt miteinander verbinden. Benutzer melden sich per [[Single Sign-On]] und [[MFA]] an, Zugriffe werden über Gruppen und Richtlinien feingranular freigegeben. Damit ist NetBird eine ernstzunehmende, selbst hostbare Alternative zu Tailscale und zu klassischen Remote-Access-[[VPN]]s.

Dieser Artikel erklärt, wie NetBird funktioniert, wofür es sich eignet und wie Sie einen eigenen NetBird-Server in wenigen Minuten aufsetzen.

== Was ist NetBird? Zero Trust statt Perimeter-VPN ==
Ein klassisches Firmen-VPN folgt dem Burggraben-Prinzip: Wer einmal über das VPN-Gateway im Netz ist, erreicht in der Regel große Teile des internen Netzwerks. Das widerspricht dem Gedanken von [[Zero Trust]] („never trust, always verify“), bei dem jede Verbindung einzeln anhand von Identität, Gerät und Richtlinie geprüft wird.

NetBird setzt genau hier an:
* '''Identitätsbasiert:''' Geräte werden einem Benutzer zugeordnet, der sich über einen Identity Provider (z. B. Microsoft Entra ID, Google Workspace, Keycloak, Authentik, Okta oder das eingebaute Dex) per [[OpenID Connect]] anmeldet.
* '''Least Privilege:''' Standardmäßig darf niemand etwas – erst Zugriffsrichtlinien (''Access Control Policies'') erlauben z. B. der Gruppe „Admins“ SSH auf die Gruppe „Linux-Server“.
* '''Peer-to-Peer:''' Der Datenverkehr fließt direkt zwischen den Geräten, nicht über einen zentralen Engpass. Das senkt Latenz und entlastet die Internetanbindung der Zentrale.
* '''Ende-zu-Ende verschlüsselt:''' Die privaten WireGuard-Schlüssel verlassen das jeweilige Gerät nie.

== So funktioniert NetBird: Architektur im Überblick ==
NetBird besteht aus vier Bausteinen:

{| class="wikitable"
! Komponente !! Aufgabe
|-
| '''Management-Service''' || Zentrale Steuerung: authentifiziert Peers, verwaltet Gruppen, Richtlinien, Routen und DNS und verteilt die „Netzwerkkarte“ an alle Clients. Vergibt die internen Adressen aus dem Bereich <code>100.64.0.0/10</code> ([[Carrier-Grade NAT]]-Adressraum).
|-
| '''Signal-Service''' || Vermittelt beim Verbindungsaufbau die Verbindungskandidaten zwischen zwei Peers. Die Nachrichten sind Ende-zu-Ende verschlüsselt – der Signal-Server kann sie nicht lesen.
|-
| '''Relay-Service''' || Leitet Verkehr weiter, wenn keine Direktverbindung möglich ist (z. B. hinter restriktiven Firewalls oder doppeltem [[NAT]]). Früher Coturn (TURN), seit Version 0.29 ein eigener WebSocket-basierter Relay. Auch der Relay sieht nur WireGuard-verschlüsselte Pakete.
|-
| '''Client (Agent)''' || Läuft auf jedem Gerät, erzeugt die WireGuard-Schlüssel, baut die Tunnel auf und setzt die Firewall-Regeln lokal (z. B. per nftables) um.
|}

Der Verbindungsaufbau nutzt '''ICE''' (bekannt aus WebRTC): Beide Peers ermitteln per STUN ihre öffentlichen Adressen, tauschen die Kandidaten über den Signal-Service aus und versuchen per NAT-Traversal („Hole Punching“) eine direkte WireGuard-Verbindung. Nur wenn das scheitert, springt der Relay ein.

[[Datei:NetBird-Architektur.png|thumb|center|700px|NetBird-Architektur: Management und Signal steuern nur den Verbindungsaufbau – der eigentliche Datenverkehr läuft per WireGuard direkt von Peer zu Peer, nur im Ausnahmefall über den Relay.]]

== Wichtige Funktionen von NetBird ==
* '''Zugriffsrichtlinien''' auf Basis von Gruppen, Protokollen und Ports – zentral im Dashboard gepflegt.
* '''Posture Checks:''' Verbindungen nur, wenn das Gerät Bedingungen erfüllt (z. B. Mindestversion von Betriebssystem oder NetBird-Client, Standort per GeoIP, laufender Prozess wie ein EDR-Agent).
* '''Network Routes:''' Ganze Subnetze (z. B. ein Büro-LAN mit Druckern oder Altgeräten ohne eigenen Client) über einen Routing-Peer erreichbar machen – inkl. Hochverfügbarkeit mit mehreren Routing-Peers.
* '''Exit Nodes:''' Den gesamten Internetverkehr eines Clients über einen bestimmten Peer leiten.
* '''DNS-Verwaltung:''' Peers über Namen erreichen, eigene Nameserver für interne Domains hinterlegen.
* '''Setup-Keys:''' Server, Container und IoT-Geräte ohne interaktive Anmeldung automatisiert einbinden.
* '''Activity- und Traffic-Events:''' Protokollierung von Anmeldungen, Änderungen und Verbindungen – die Logs lassen sich an ein SIEM weiterleiten.
* '''Breite Plattformunterstützung:''' Linux, Windows, macOS, Android, iOS, FreeBSD, Docker, Kubernetes (Operator) sowie Firewalls und NAS wie OPNsense (siehe [[OPNsense - NetBird-Plugin]]), pfSense, MikroTik, OpenWRT, Synology und TrueNAS.

== NetBird selbst hosten: Quickstart ==
NetBird gibt es als gehosteten Cloud-Dienst und zum Selbstbetrieb. Für Unternehmen mit Datenschutz- und Souveränitätsanforderungen ist das Self-Hosting oft die bessere Wahl – alle Steuerdaten bleiben im eigenen Rechenzentrum.

=== Voraussetzungen ===
* Linux-VM mit mindestens '''1 CPU und 2 GB RAM''' (z. B. Debian oder Ubuntu)
* Docker inkl. Compose-Plugin (v2), <code>jq</code> und <code>curl</code>
* Öffentlicher DNS-Name, der auf die VM zeigt (z. B. <code>netbird.example.com</code>)
* Aus dem Internet erreichbar: '''TCP 80, TCP 443 und UDP 3478''' (STUN)

=== Schritt 1: Server installieren ===
Das offizielle Skript erzeugt eine komplette Installation mit Management, Signal, Relay und STUN in einem kombinierten Server, Traefik als Reverse Proxy mit automatischen Let’s-Encrypt-Zertifikaten sowie Dex als eingebautem Identity Provider:
<syntaxhighlight lang="bash">
export NETBIRD_DOMAIN=netbird.example.com
curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/getting-started.sh | bash
</syntaxhighlight>

{{Hinweis|Skripte aus dem Internet sollten Sie vor dem Ausführen herunterladen und lesen, statt sie blind per Pipe an die Shell zu übergeben. Legen Sie außerdem vor jedem Update ein Backup des Installationsverzeichnisses (inkl. Datenbank) an.}}

=== Schritt 2: Admin-Konto anlegen ===
Nach der Installation <code><nowiki>https://netbird.example.com</nowiki></code> aufrufen. Solange noch kein Benutzer existiert, leitet das Dashboard auf die Seite <code>/setup</code> weiter. Dort E-Mail-Adresse, Name und Passwort für den ersten Administrator vergeben und anmelden. Anschließend kann im Dashboard ein externer Identity Provider (z. B. Entra ID) angebunden werden.

=== Schritt 3: Ersten Peer verbinden ===
Auf einem Linux-Client:
<syntaxhighlight lang="bash">
curl -fsSL https://pkgs.netbird.io/install.sh | sh
netbird up --management-url https://netbird.example.com
</syntaxhighlight>
Der Befehl öffnet einen Anmeldelink im Browser; nach dem Login erscheint das Gerät im Dashboard unter '''Peers'''. Für Server ohne Browser wird im Dashboard ein '''Setup-Key''' erzeugt und mitgegeben:
<syntaxhighlight lang="bash">
netbird up --management-url https://netbird.example.com --setup-key <SETUP-KEY>
netbird status -d
</syntaxhighlight>
<code>netbird status -d</code> zeigt für jeden Peer, ob die Verbindung '''P2P''' (direkt) oder '''Relayed''' läuft.

=== Schritt 4: Zugriffsrichtlinie anlegen ===
Nach der Installation existiert eine Standardregel „Default“, die allen Peers gegenseitigen Zugriff erlaubt. Für ein echtes Zero-Trust-Modell:
# Unter '''Access Control → Groups''' Gruppen anlegen, z. B. ''Admins'', ''Mitarbeiter'', ''Linux-Server''.
# Unter '''Access Control → Policies''' gezielte Regeln erstellen, z. B. ''Admins → Linux-Server, TCP 22''.
# Die '''Default-Regel deaktivieren''' – erst dann gilt „deny by default“.

== NetBird im Vergleich: Tailscale, Headscale und klassisches VPN ==
{| class="wikitable"
! Kriterium !! NetBird !! Tailscale !! Headscale !! Klassisches VPN (IPsec/OpenVPN)
|-
| Protokoll || WireGuard (Kernel oder Userspace) || WireGuard || WireGuard (Tailscale-Clients) || IPsec, OpenVPN, ggf. WireGuard
|-
| Topologie || Mesh, Peer-to-Peer || Mesh, Peer-to-Peer || Mesh, Peer-to-Peer || Hub-and-Spoke über Gateway
|-
| Steuerserver selbst hostbar || Ja, offizieller Bestandteil || Nein (nur SaaS) || Ja (Community-Projekt) || Ja
|-
| Eigenes Web-Dashboard || Ja || Ja (SaaS) || Nein (nur Drittanbieter) || Je nach Produkt
|-
| SSO/MFA, Posture Checks || Ja || Ja || Teilweise || Je nach Produkt
|-
| Lizenz || Clients BSD-3, Server AGPLv3 || Clients BSD-3, Steuerserver proprietär || BSD-3 || Je nach Produkt
|}

Die Stärke von NetBird liegt in der Kombination aus vollständig selbst hostbarer Steuerebene, komfortabler Oberfläche und Zero-Trust-Funktionen wie Posture Checks. Klassische Site-to-Site-VPNs zwischen Firewalls haben dennoch weiterhin ihre Berechtigung – häufig ergänzen sich beide Ansätze.

== Sicherheit und Betrieb: Worauf Sie achten sollten ==
* '''Lizenz:''' Seit Version 0.53.0 (August 2025) stehen die Server-Komponenten (Management, Signal, Relay, Dashboard) unter '''AGPLv3''', die Clients weiterhin unter BSD-3. Der Selbstbetrieb für die eigene Organisation ist ausdrücklich erlaubt; für Zusatzfunktionen und Support bietet NetBird kommerzielle Self-Hosting-Lizenzen an.
* '''Updates zeitnah einspielen:''' NetBird wird sehr aktiv entwickelt. Im Juli 2026 schloss Version 0.76.0 eine Schwachstelle im Client-Daemon (GHSA-qcpp-8vwj-hhwr, CVSS 8.8). Clients und Server sollten daher regelmäßig aktualisiert werden.
* '''Management-Server härten:''' Er ist das Herzstück – nur die nötigen Ports öffnen, das Dashboard per SSO mit MFA schützen, Backups der Datenbank einplanen.
* '''Default-Regel entfernen''' und Richtlinien eng fassen (siehe oben).
* '''Monitoring:''' Activity-Events und Server-Logs zentral auswerten, z. B. in einem [https://www.max-it.de/it-services/siem-open-source/ Open-Source-SIEM auf Wazuh-Basis], um ungewöhnliche Anmeldungen oder neue Peers zu erkennen.
* '''NIS2:''' Identitätsbasierter Zugriff mit MFA, Protokollierung und Gerätezustandsprüfung unterstützt die Anforderungen an Zugriffskontrolle und Kryptografie aus NIS2 – ersetzt aber kein Gesamtkonzept.

== Fazit ==
NetBird bringt das Zero-Trust-Prinzip mit überschaubarem Aufwand in mittelständische Netzwerke: WireGuard-Performance, direkte Peer-to-Peer-Verbindungen, Anmeldung über den vorhandenen Identity Provider und fein steuerbare Zugriffsrechte – auf Wunsch komplett im eigenen Rechenzentrum. Wer heute noch Mitarbeiter und Dienstleister per klassischem VPN „ins ganze Netz“ lässt, sollte NetBird als modernen Nachfolger evaluieren.

== Unterstützung von m.a.x. it ==
Sie möchten Remote-Zugriffe nach dem Zero-Trust-Prinzip absichern oder NetBird in Ihre bestehende Firewall- und SIEM-Landschaft integrieren? m.a.x. it unterstützt Sie bei Konzeption, Betrieb und Härtung – mit [https://www.max-it.de/it-services/cybersecurity/ Cybersecurity-Leistungen von m.a.x. it] und einer [https://www.max-it.de/it-services/managed-firewall/ Managed Firewall von m.a.x. it].

== Siehe auch ==
* [[OPNsense - NetBird-Plugin]]
* [[WireGuard]]
* [[Zero Trust]]
* [[VPN]]
* [[VPN Techniken für das Homeoffice]]
* [[Single Sign-On]]
* [[OpenID Connect]]
* [[MFA]]
* [[NAT]]
* [[Carrier-Grade NAT]]

== Links und Quellen ==
* [https://docs.netbird.io/ Offizielle NetBird-Dokumentation]
* [https://github.com/netbirdio/netbird NetBird-Quellcode auf GitHub]
* [https://www.max-it.de/it-services/cybersecurity/ m.a.x. it – Cybersecurity und Zero Trust]
* [https://www.max-it.de/it-services/managed-firewall/ m.a.x. it – Managed Firewall]

{{Uebermax}}
[[Kategorie:IT-Security]]

NetBird – Zero-Trust-Netzwerk mit WireGuard - Versionsgeschichte

imported>TechCorner-Redaktion: Neuer Artikel: NetBird (Zero Trust, WireGuard, Self-Hosting), Stand 10/2026