Windows-VPN härten: Authentifizierung vor dem Tunnel reparieren

Ihr Windows-VPN-Server fragt nach Benutzername und Kennwort, und dieser eine Dialog verbirgt drei unabhängige Aufgaben. Eine beweist, wer die Person ist, eine verhindert, dass jemand, der die Leitung beobachtet, diesen Beweis wiederverwendet, und eine entscheidet, welche Adressen danach erreichbar sind. Die meisten kleinen Installationen härten zuerst den Tunnel und lassen die ersten beiden Aufgaben auf ihren Standardwerten, was die falsche Reihenfolge ist.

Arbeiten Sie in der Reihenfolge, in der der Angreifer arbeitet. Zuerst kommt, was sich von der Leitung abgreifen lässt. Dann, was sich mit diesem Mitschnitt später wiedergeben lässt. Schließlich, was ein authentifizierter Angreifer erreicht, sobald er drin ist.

Drei Aufgaben, ein Dialogfeld

Identität ist der Teil, an den Menschen denken, und sie ist nur ein Drittel des Problems. Der Identitätsnachweis muss einen Beobachter überstehen, der den Austausch aufzeichnet und es später erneut versucht. Autorisierung ist eine separate Entscheidung, die der Server trifft, nachdem die Identität geklärt ist, und Windows hält sie in einem anderen Dienst als dem, der Anmeldeinformationen prüft.

Wenn alle drei in einem gedanklichen Eimer liegen, ist das übliche Ergebnis ein Server, der stark authentifiziert und dem Benutzer dann alles erlaubt. Das später zu korrigieren ist schwieriger, als die Richtlinie jetzt festzulegen, weil dann Firewallprofil, Adresspool und Routen alle die alte Annahme kodieren.

Trennen Sie die drei in Ihren Notizen, bevor Sie eine Einstellung anfassen, und reparieren Sie sie dann vom schwächsten Glied aufwärts.

Warum MS-CHAPv2 einen Wiedergabetest nicht übersteht

Wenn der Server noch PPTP mit MS-CHAPv2 akzeptiert, schützt der Tunnel das Kennwort in keinem sinnvollen Sinne. Challenge und Response lassen sich aufzeichnen und offline angreifen, und 2012 zeigte ein öffentlicher Knackdienst die Wiederherstellung aus einem solchen Handshake in etwa einem Tag für ein typisches Kennwort. Ein längeres, komplexeres Kennwort erhöht die Kosten; es entfernt nicht das Material, das ein Angreifer aus dem Netzwerk braucht.

Die Eigenschaft, die Sie wollen, ist eine Anmeldeinformation, die nicht wiedergegeben werden kann. EAP-TLS mit Clientzertifikaten gibt jedem Gerät seine eigene Identität und erlaubt es, genau ein Gerät zu widerrufen.

Die Zertifikatsverteilung ist echte Arbeit: eine private CA, ein Widerrufspfad, den die Clients prüfen, und ein Erneuerungsplan, der Personalwechsel übersteht. Behandeln Sie diese Arbeit als das Projekt und nicht als Hindernis zwischen Ihnen und einem funktionierenden Tunnel. Planen Sie dafür Budget ein, wie Sie es für einen Firewall-Austausch einplanen würden. Ein gemeinsames Kennwort ist nur bis zum ersten Widerruf billiger.

Ein vorab geteilter Schlüssel authentifiziert das Paar, nicht die Person

L2TP/IPsec mit einem vorab geteilten Schlüssel beweist, dass zwei Gateways dasselbe Geheimnis kennen. Es sagt nichts darüber, welcher Mensch sich verbindet, und kann auf dieser Ebene einen Mitarbeiter nicht von einem anderen unterscheiden. Verwenden Sie einen langen Zufallswert, weit über die zehn Zeichen hinaus, die manche Anleitungen vorschlagen, denn wer den Handshake mitschneidet, kann den Schlüssel offline angreifen.

Jeder Client in diesem Profil teilt das Geheimnis, sodass das Entfernen einer Person bedeutet, es an alle übrigen zu verteilen. Behalten Sie einen separaten Benutzerauthentifizierungsschritt über dem Geheimnis auf Maschinenebene und wechseln Sie zu Zertifikaten, wenn die Clientbasis wächst. Ein vorab geteilter Schlüssel zusammen mit MS-CHAPv2 sind zwei schwache Schichten, und die zweite hebt die erste auf.

Autorisierung gehört in den Network Policy Server

NPS unter Windows entscheidet, wer sich verbinden darf, und zwar nachdem die Authentifizierung bereits erfolgreich war. Diese Trennung ist die nützlichste Härtungskontrolle im Produkt, und viele Installationen lassen sie unberührt.

Verwenden Sie Richtlinienbedingungen, die reale Einschränkungen abbilden: Gruppenmitgliedschaft, das Zeitfenster, in dem der Support besetzt ist, und Gerätezustand aus einer Zustandsprüfung. Fügen Sie einen zweiten Faktor hinzu, wo die Daten die Reibung rechtfertigen, und bedenken Sie, dass die Richtlinie pro Verbindungsversuch ausgewertet wird, was sie zu einer lebenden Kontrolle und nicht zu einem Dokument macht.

Die RADIUS-Abrechnung liefert Ihnen außerdem einen Datensatz darüber, wer sich wann verbunden hat. Dieses Protokoll ist der Unterschied zwischen einer Vorfallprüfung und einer Vermutung, und es existiert unabhängig davon, ob es jemals jemand liest.

Begrenzen Sie, was eine erfolgreiche Anmeldung erreicht

Der VPN-Adapter sollte in einem Firewallprofil landen, das die für seine Rolle nötigen Dienste erlaubt und nicht das gesamte Subnetz. Die Routingfrage ist von der Filterung getrennt. Ein voller Tunnel schützt das Clientgerät und leitet jedes Byte über Ihren Uplink, während ein geteilter Tunnel lokalen Verkehr lokal hält und das Gerät dem Netzwerk aussetzt, in dem es sich gerade befindet.

Keine der beiden Optionen ist eine Sicherheitsvorgabe. Beide müssen neben dem Firewallprofil festgehalten werden, das sie voraussetzen.

Prüfen Sie die Fehlerpfade

Testen Sie, was brechen soll: ein falsches Kennwort, ein abgelaufenes Zertifikat, ein widerrufenes Gerät, einen Benutzer außerhalb der Gruppe. Jedes sollte an einer anderen Stelle scheitern, und das Protokoll sollte sagen, welches es war. Führen Sie den Satz zuerst gegen ein Testkonto aus und wiederholen Sie ihn dann für einen echten Benutzer. Eine Ablehnung, die ohne Begründung im Ereignisprotokoll landet, sollte behoben werden, lange bevor Sie den Eintrag brauchen.

Bestätigen Sie dann, welche Ports veröffentlicht sind und warum. PPTP braucht TCP 1723 und GRE als IP-Protokoll statt als Port, IKEv2 braucht UDP 500 und 4500, und L2TP braucht UDP 1701 plus IPsec. Eine Verwaltungsschnittstelle freizugeben, damit sich ein Client verbindet, ist keine Reparatur, sondern ein zweiter Vorfall, der darauf wartet, entdeckt zu werden.

Entscheiden Sie schließlich, was der Server aufzeichnet und für wie lange. Ein Endpunkt ohne Authentifizierungshistorie kann die erste Frage nach einem Vorfall nicht beantworten, nämlich ob der Versuch jemals autorisiert war.