Weil Wireguard NICHT sicher ist und Sie es NICHT verwenden sollten.
Wenn Menschen zum ersten Mal ein VPN verwenden, sehen sie als Erstes, „wie schnell wir sind“. Und wenn „wir sehr schnell sind“, neigen wir dazu zu glauben, „dass wir es mit einem guten Produkt zu tun haben, das wenig Overhead produziert.
Dies hat einige Nachteile. Sie könnten beispielsweise ein VPN erstellen, das den Datenverkehr nur mit einem Rot (13) verschleiert, und das wäre in der Tat sehr schnell. Das Problem ist, dass Systemadministratoren auf der ganzen Welt und alle Sicherheitsmitarbeiter erkennen würden, dass das VPN schnell ist, weil es wenig tut.
Aber eine andere Möglichkeit, den Leistungsverlust zu verbergen, wäre, ihn als Teil des Kernels im Supervisor-Modus auszuführen. Auch hier scheint VPN wenig Latenz zu erzeugen. Aber das wäre ein Trick, auf den erfahrene Systemadministratoren mit einem Achselzucken reagieren würden.
Das heißt, es ist mir egal, wie schnell es ist oder wie wenig Latenz es hat. Es funktioniert im Kernel-Modus, andere VPNs nicht, daher kann ich nicht vergleichen. Das Einbinden des VPN in den Kernel war ein cleverer Trick, der aber so lange hält.
Jetzt brauche ich also einen KPI, um zu entscheiden, wie sicher dieses VPN ist, einen KPI, der nicht der übliche „Wie robust ist Ihr Algorithmus“ ist. Die Welt ist voll von sehr robusten Verschlüsselungsalgorithmen, aber Unfälle passieren immer noch. Wieso den?
Denn Computer sind mehr oder weniger indirekt Systeme, die von Menschen verwaltet werden. Und während ein Großteil der Verwaltungsaufgaben automatisiert ist, ist das IT-Personal der Eckpfeiler der Infrastruktur, wenn es um die Konfiguration und Einrichtung von Geräten geht, die Sicherheit bieten.
Aber was bedeutet es, dass „der Mensch der Grundstein der Infrastruktur ist“?
Dies bedeutet, dass IT-Sicherheitsexperten Zeit damit verbringen, die Protokolle zu lesen und sie in spezielle Datenbanken einzugeben, in denen automatisierte Systeme Warnungen erstellen, wenn sie falsche Dinge sehen, und möglicherweise die Aufmerksamkeit menschlicher Bediener auf sich ziehen, wenn etwas nicht stimmt.
Menschliche Bediener wiederum müssen verstehen, was schief läuft, warum es schief geht, und von dort aus eine Lösung finden.
Wenn wir von Sicherheit sprechen, sprechen wir immer von OBSERVABILITY.
Systemmanager brauchen Beobachtbarkeit, um zu verstehen, was schief läuft, um zu wissen, WARUM es schief läuft, um zu wissen, ob es sich um einen Angriff oder eine Fehlfunktion handelt, um zu wissen, ob es einem Bedrohungsmodell entspricht und so weiter.
Natürlich müssen wir uns jetzt fragen, was genau die Observability von Wireguard ist. Und die Antwort ist, dass, selbst wenn wir es in den „Debug“-Modus versetzen, die Beobachtbarkeit fehlt, inkompetent und völlig nutzlos ist.
Schau dir das an:
Wie habe ich das bekommen? Ich habe keine Ahnung. Ich habe keine Ahnung, weil dies zwei identische virtuelle Maschinen sind, die ich nach demselben Verfahren konfiguriert habe, das eine korrekte wg0.conf-Datei erzeugt.
Und ich sage richtig, weil das einzige Tool, das ich verwenden kann, „wg“, es liest und für mich richtig konfiguriert. (Offensichtlich sind die IPs und Schlüssel für jede Maschine unterschiedlich usw. usw.).
Von meiner Seite, also von Seiten des Kunden, gibt es nichts zu verbessern. Die beiden Dateien sind identisch, nur die öffentlichen Schlüssel und IPs des Clients ändern sich. (offensichtlich). Eine virtuelle Maschine funktioniert, eine nicht.
Dito auf der Serverseite. Wo ich nur weiß, dass WG den Peer versteht, dann aber "Invalid handshake initiation".
Aber vor allem beim Lesen dieser Register, WAS genau ist beim "Starten des Handshakes" ungültig? Was ist falsch?
Wenn ich einen Spezialisten alarmieren müsste, was würde ich auslösen? Sind nicht die richtigen Schlüssel dabei? Ist die Prüfsumme des UDP-Pakets ungültig? Wir wissen? Nein. Die Protokollmeldung sagt nichts. Schließlich wird die IT-Abteilung gebeten, jemanden anzurufen und zu sagen, „etwas Unbestimmtes läuft schief“. Das Schlimmste, was man einem Nachtdienst sagen kann. Das Schlimmste aller Zeiten.
Sie fragen sich also, was an einem UDP-Paket falsch sein könnte, und entscheiden sich, zunächst die Prüfsumme zu überprüfen.
Sie werden also einen netten tcpdump machen und sehen, dass (weil es andere gibt, die das VPN verwenden) einige Pakete die richtige Prüfsumme haben und andere die falsche – Sie sollten herausfinden, welches Paket sich über das Protokoll beschwert. Aber das Protokoll sagt es nicht. Sie müssen sich von der gesamten Benutzerbasis abmelden und es mit nur einem Benutzer erneut versuchen. Aber natürlich kannst du das nicht.
Die erste Versuchung, der Sie NICHT nachgeben sollten, besteht darin, die Prüfsummenprüfung von UDP-Paketen zu deaktivieren. Sie wissen nicht, ob das das Problem ist, und es ist sowieso keine gute Praxis. Wie verhindert man also etwas, das man nicht versteht?
Hier sind wir. Jeder, der viele Jahre in der IT gearbeitet hat, weiß, dass Sicherheitsprobleme größtenteils keine Probleme der Ebenen 1 bis 7 sind, die von Menschen nicht verstanden oder falsch konfiguriert wurden.
Entweder ist es eine Reaktion auf ein Problem, das sich als schlimmer herausstellt als erwartet, oder es ist eine falsche Annahme.
Die Systeme, die sich mit der Perimetersicherheit befassen, müssen daher das Risiko, dass Administratoren das Falsche tun, so weit wie möglich mindern. Sie müssen klären, was los ist. Sie müssen klären, warum etwas passiert. Sie müssen die Kontrolle abgeben. Sie müssen beobachtbar sein.
Aber Wireguard kann das nicht. Da sie auf Kernel-Ebene arbeiten, können sie sich offensichtlich keine sehr umfangreiche Protokollierung leisten, die ausreicht, um eine aufdringliche Beobachtbarkeit zu ermöglichen. Dies führt dazu, dass Administratoren zu unwissenden Entscheidungen getrieben werden: Welche Einstellung verbessert die Gültigkeit der "Handshake-Initiierung"? Wer weiß?
Kein System, das nicht beobachtbar ist, ist sicher, weil es den Personen, die es überwachen, nicht erlaubt, genau zu wissen, was vor sich geht.
Es ist mir egal, wie robust der Algorithmus ist. Stör mich nicht damit. Es ist mir egal, wie stark der Händedruck ist. Das ist mir egal.
Es ist mir egal, da Wireguard nicht nachweisbar ist und nur sehr wenig aufzeichnet:
- schwächt Systemadministratoren
- schwächt das Alarmsystem
- untergräbt die Reaktion des Sicherheitsteams.
Selbst wenn die kryptografischen Algorithmen die tödlichsten der Welt wären, hätten sie einen inakzeptablen Preis: das Sicherheitsteam des Unternehmens oder zumindest den Systemadministrator zu blenden.
Und dies ist in einem VPN-System oder einer Perimetersicherheit einfach INAKZEPTABEL.
Wiregard ist unsicher, weil alles, was es an Einfachheit der Implementierung und Leistung gewinnt, an Beobachtbarkeit verliert.
Es ist, als würde man eine Sicherheitstür einbauen, die superstark ist, aber erfordert, dass Sie den Rest des Hauses in ein Campingzelt verwandeln. Sie haben eine superstarke Tür und der Rest ist jetzt schwach. Ebenso haben Sie mit Wireguard einen robusten Verschlüsselungsalgorithmus, aber der Rest Ihrer Unternehmens- oder persönlichen Sicherheit wird weg sein, weil Sie keine Ahnung haben, was vor sich geht und warum.
Ich verstehe immer noch nicht, warum Torvalds zugestimmt hat, diesen Betrug in den Kernel einzufügen