Verhindert 802.1X und RADIUS Rogue-APs?

1879
Jason

Ich habe heute mit einem Kollegen diskutiert, und er schien zu glauben, wenn man 802.1X verwendet, kann der Benutzer erkennen, ob er sich mit einem Rogue-Zugangspunkt verbindet.

Ich verstehe das zwar nicht, aber wenn Sie glauben, dass ein Rogue Access Point von Anfang an der echte war, würden Sie sich nur bei einem Rogue-Radius-Server authentifizieren, anstelle des Originals.

Ich sehe nicht, wie 802.1X Sie davon abhalten kann, sich mit dem falschen Netzwerk zu verbinden?

4

2 Antworten auf die Frage

2
lxgr

Die 802.1X-Authentifizierung (und die nachfolgende WPA-Schlüsselerzeugung) umfasst drei Entitäten: einen Supplicant (den Client), einen Authentifikator (den Zugriffspunkt) und einen Authentifizierungsserver.

Wie Zoredache sagte, ist die Kommunikation zwischen dem Client und dem Authentifizierungsserver durch Kryptografie mit öffentlichem Schlüssel geschützt (zumindest wenn Sie EAP-TTLS oder EAP-PEAP verwenden). Es ist nicht möglich, als ursprünglicher Authentifizierungsserver zu posieren.

Es gibt jedoch keine direkte Authentifizierung des AP (des Authenticators in 802.1X-Sprache) beim Client (dem Supplicant) oder umgekehrt. Der Authentifikator übermittelt nur Nachrichten zwischen dem Supplicant und dem Authentifizierungsserver. Die von einigen EAP-Methoden bereitgestellte fantastische Kryptografie mit öffentlichem Schlüssel und die gegenseitige Authentifizierung sind für den Authentifikator transparent und könnten daher theoretisch von einem Rogue Access Point (MITM) abgefangen und wiedergegeben werden.

Mit Basic 802.1X gibt es zwar keinen Schutz gegen Schurkenauthentifizierer - bei Verwendung von "WPA Enterprise Encryption" (EAP) bietet 802.1X jedoch zusätzliche Sicherheit:

Der WPA-Verschlüsselungsschlüssel (der unter anderem die gegenseitige Authentifizierung zwischen Client und AP ermöglicht - was Sie vor unberechtigten APs schützen möchten!) Für die Verbindung wird nicht vom Zugriffspunkt, sondern vom Authentifizierungsserver generiert über den gesicherten inneren EAP-Kanal an den Client weitergeleitet. Damit der Zugangspunkt (= Authentifikator) mit dem Client kommunizieren kann, muss er natürlich auch den Schlüssel kennen, er erhält jedoch den Schlüssel vom Authentifizierungsserver und nicht vom Client.

In einer normalen Konfiguration akzeptiert der Server keine Authentifizierungsanfragen von Dritten. Es kommuniziert normalerweise nur mit einer begrenzten Anzahl von Authentifizierern, und die Kommunikation wird normalerweise verschlüsselt (durch ein paarweises RADIUS-Geheimnis). Damit ein MITM erfolgreich einen richtigen Zugangspunkt nachahmen kann, müsste der Angreifer die Rolle eines gültigen Zugangspunkts gegenüber dem Authentifizierungsserver nachahmen.

Um es kurz zu machen, der Schutz vor Rogue-APs ist so gut wie die Authentifizierung und Verschlüsselung zwischen den Authentifizierern (z. B. den APs) und dem Authentifizierungsserver.

Wenn Sie einen Rogue-AP erstellen, können Sie tatsächlich die 802.1X-Authentifizierung weiterleiten. Sie können jedoch keinen Datenverkehr des Clients lesen, da dies mit einem Ihnen unbekannten WPA-Schlüssel verschlüsselt würde. Ebenso wird alles, was Ihr Rogue-AP an den Client sendet, vom Client abgelehnt, da der WPA-Schlüssel auch für die Nachrichtenauthentifizierung verwendet wird.

1
Zoredache

Das 802.1x ermöglicht in einigen Konfigurationen die gegenseitige Authentifizierung über PKI. Dies kann TLS verwenden, das Protokoll, das für das sichere Surfen im Internet verwendet wird.

Sowohl der Client als auch der AP verfügen über ein privates / öffentliches Schlüsselpaar. Die öffentlichen Schlüssel sind in einem Zertifikat enthalten, das von einem dritten System kryptografisch signiert ist, das auf dem Client und dem AP als vertrauenswürdig konfiguriert ist. Solange die privaten Schlüssel und die und die Zertifizierungsstelle nicht gefährdet sind, können beide Maschinen das Protokoll verwenden, um sich gegenseitig zu authentifizieren .

Der Nachteil ist, dass die Verwaltung aller PKI viel mehr Aufwand erfordert als ein einfacher gemeinsam genutzter Schlüssel.

Ok, aber gehen Sie davon aus, dass der Client den richtigen AP auswählt? Wenn sie den falschen Zugangspunkt / das falsche Netzwerk auswählen, fällt alles auseinander? Jason vor 12 Jahren 0
Ein Schurke AP hätte kein gültiges Zertifikat von der Zertifizierungsstelle haben. Zoredache vor 12 Jahren 0
Der AP ist nicht der Authentifizierungsserver, und nur der Authentifizierungsserver kennt das Zertifikat. lxgr vor 11 Jahren 0