Die Veröffentlichung der Nebula 1.9-Projekts bietet Werkzeuge zum Aufbau sicherer Overlay-Netzwerke, die geografisch getrennte Hosts in ein separates, isoliertes Netz integrieren, das über das globale Netzwerk arbeitet. Das Projekt zielt darauf ab, individuelle Overlay-Netzwerke für verschiedene Bedürfnisse zu schaffen, beispielsweise zur Verknüpfung von Unternehmenscomputern in verschiedenen Büros, Servern in verschiedenen Rechenzentren oder virtuellen Umgebungen bei unterschiedlichen Cloud-Anbietern. Der Code ist in Go geschrieben und wird unter der MIT-Lizenz vertrieben. Das Projekt wird von der Firma Slack unterstützt, die auch den gleichnamigen Unternehmensmessenger entwickelt. Die Nutzung erfolgt auf Linux, FreeBSD, macOS, Windows, iOS und Android.
Die Knoten im Nebula-Netzwerk interagieren direkt im P2P-Modus – sobald der Bedarf an einem Datenaustausch zwischen den Knoten besteht, werden dynamisch direkte VPN-Verbindungen. Die Identität jedes Hosts im Netzwerk wird durch ein digitales Zertifikat bestätigt, und der Zugang zum Netzwerk erfordert eine Authentifizierung – jeder Benutzer erhält ein Zertifikat, das die IP-Adresse im Nebula-Netzwerk, den Namen und die Mitgliedschaft in den Hostgruppen bestätigt. Die Zertifikate werden von einer internen Zertifizierungsstelle signiert, die vom Ersteller des jeweiligen Netzwerks auf seinen eigenen Servern eingesetzt wird und für die Validierung der Berechtigungen der Hosts verwendet wird, die berechtigt sind, sich mit einem bestimmten Overlay-Netzwerk zu verbinden, das an die Zertifizierungsstelle gebunden ist.
Für die Erstellung eines authentifizierten sicheren Kommunikationskanals in Nebula wird ein eigener Tunnelprotokoll verwendet, das auf dem Schlüsselaustauschprotokoll von Diffie–Hellman und dem AES-256-GCM-Verschlüsselungsalgorithmus basiert. Die Implementierung des Protokolls stützt sich auf bewährte und getestete Bausteine, die vom Noise-Framework bereitgestellt werden, das auch in Projekten wie WireGuard, Lightning und I2P verwendet wird. Es wird behauptet, dass das Projekt eine unabhängige Sicherheitsprüfung bestanden hat.
Zur Entdeckung anderer Knoten und zur Koordination der Verbindungen zum Netzwerk werden spezielle Knoten mit der Bezeichnung „Lighthouse“ eingerichtet, deren globale IP-Adressen festgelegt und den Teilnehmern des Netzwerks bekannt sind. Teilnehmerknoten haben keine Bindung an externe IP-Adresse, sie werden durch Zertifikate identifiziert. Die Eigentümer der Hosts können keine Änderungen an den signierten Zertifikaten vornehmen und im Gegensatz zu traditionellen IP-Netzen können sie sich nicht einfach durch Ändern der IP-Adresse als ein anderer Host ausgeben. Bei der Erstellung eines Tunnels wird die Identität des Hosts durch einen individuellen privaten Schlüssel bestätigt.
Der erstellten Netzwerk wird ein bestimmter Bereich von Intranet-Adressen zugewiesen (zum Beispiel 192.168.10.0/24) und es wird eine Verknüpfung der internen Adressen mit den Host-Zertifikaten hergestellt. Es stehen verschiedene Mechanismen zur Verfügung, um Adressübersetzer (NAT) und Firewalls zu umgehen. Es ist möglich, die Routing über das Overlay-Netzwerk für den Datenverkehr von Drittanbietern zu organisieren, die nicht Teil des Nebula-Netzwerks sind (unsichere Routen). Aus den Teilnehmern des Overlay-Netzwerks können Gruppen gebildet werden, zum Beispiel zur Trennung von Servern und Arbeitsstationen, für die separate Regeln zur Datenverkehrsfilterung gelten.
Die Erstellung von Firewalls wird unterstützt, um den Zugriff zu trennen und den Datenverkehr zwischen Knoten im Nebula-Overlay-Netzwerk zu filtern. Für die Filterung werden ACLs mit Tag-Verknüpfungen verwendet. Jeder Host im Netzwerk kann eigene Filterregeln basierend auf Hosts, Gruppen, Protokollen und Netzwerkports definieren. Dabei werden Hosts nicht nach IP-Adressen, sondern nach von einer Zertifizierungsstelle signierten Host-IDs gefiltert, die nicht gefälscht werden können, ohne die Funktionsweise der Netzwerkzertifizierungsstelle zu kompromittieren.
In der neuen Version:
- Eine neue Einstellung default_local_cidr_any wurde hinzugefügt, die das Verhalten bei der Verarbeitung der Subnetze „local_ip“ in den Firewall-Regeln ändert, um eine ungerechtfertigte Erlaubnis des Datenverkehrs zu Hosts, die im Block unsafe_routes aufgeführt sind, zu verhindern. In Version 1.9 ist die Einstellung auf „true“ gesetzt, wird jedoch in der nächsten Version 1.10 auf „false“ geändert, was dazu führt, dass lokale Subnetze bei der Anwendung der Firewall-Regeln auf Hosts, die über unsichere Routen erreichbar sind, berücksichtigt werden (um den Zugriff auf solche Hosts zu ermöglichen, ist die Angabe von local_cidr erforderlich).
- Ein offizielles Image für das Docker-System wurde bereitgestellt, das eine schnelle Bereitstellung eines Nebula-basierten Overlay-Netzwerks oder eines Knotens dafür ermöglicht.
- Experimentelle Builds für die Architektur Loong64 wurden hinzugefügt.
- Ein Dienstskript für das OpenRC-Init-System wurde implementiert.
- Der Hintergrundprozess SSH hat die Unterstützung für die Zertifikatsauthentifizierung durch ein von einer Zertifizierungsstelle signiertes Zertifikat (sshd.trusted_cas) hinzugefügt. Es wurde die Möglichkeit implementiert, Host-Schlüssel in den Konfigurationsblock sshd.host_key einzufügen.
- Die Unterstützung für das Neuladen der Einstellungen „tun.unsafe_routes“ wurde sichergestellt.
- Die Unterstützung für die veraltete Einstellung local_range wurde entfernt, stattdessen sollte preferred_ranges verwendet werden.
- Für die Erstellung wird jetzt das Toolkit Go 1.22 benötigt. Die minimalen Anforderungen an die Windows-Versionen wurden auf Windows 10 und Windows Server 2016 erhöht.
Quelle: opennet.ru
