ike-scan erhält keine Antwort von einem funktionierenden IPsec-Gateway

Das Gateway bedient täglich Telefone und Laptops, und dennoch meldet ike-scan, dass kein Host geantwortet hat. Diese Ausgabe liest sich wie der Beweis, dass IPsec auf dem Gerät fehlt. Meist heißt es, dass das Gerät jeden Vorschlag in der Probe verworfen und beschlossen hat, nichts zu antworten. Schweigen ist eine Antwort, und sie ist die am wenigsten aussagekräftige, die das Werkzeug geben kann.

Arbeiten Sie drei getrennte Fragen ab: Kam das Paket an, passte irgendein Vorschlag, und hat etwas anderes den Peer abgewiesen?

Schritt 1: Lesen Sie den Vorschlag, den das Werkzeug sendet

Der Hauptmodus beginnt mit einer SA-Nutzlast, die die Transformationen auflistet, die der Initiator akzeptieren wird, und ike-scan füllt diese Liste aus einem kompilierten Standard. Der Standardsatz ist bewusst alt: DES und 3DES zur Verschlüsselung, MD5 und SHA1 zum Hashen, Gruppen 1 und 2 für den Schlüsselaustausch, vorab geteilte Schlüssel zur Authentifizierung. Kein AES, kein SHA-2, keine Gruppe 14. Ein Gateway, das für AES-256 mit SHA-256 und modp2048 konfiguriert ist, teilt nichts damit.

Manche Implementierungen beantworten eine unpassende Probe mit einer NO-PROPOSAL-CHOSEN-Meldung. Andere verwerfen sie einfach, was bei Geräten üblich ist, die unbekannte Peers als Rauschen behandeln. So oder so gibt der Scan nichts aus, und dieses Nichts ist identisch mit dem, wie ein gefiltertes UDP 500 von außen aussieht, wie die Dokumentation des ike-scan-Projekts es zum Standardsatz deutlich macht.

Schritt 2: Bieten Sie einen modernen Vorschlag an

Ersetzen Sie den Standardsatz durch --trans. Die Attributform nimmt IKE-Attributnummern direkt: 1 für die Verschlüsselung, 2 für den Hash, 3 für die Authentifizierung, 4 für die Gruppe und 14 für die Schlüssellänge, wenn der Algorithmus eine annimmt. Was herauskommt, ist eine Zeile, die Sie in einer Änderungsprüfung laut vorlesen können.

Die Positionsform trägt dieselben Werte in der Reihenfolge und vermeidet Klammern, was zählt, sobald der Befehl durch eine Shell läuft.

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

Ein Vorschlag pro Paket ist beim Aufzählen langsam, also laufen Sie die plausiblen Werte durch: Verschlüsselung 5, 7/128, 7/192, 7/256; Hash 1, 2, 5, 6, 7; Gruppen 1, 2, 5, 14, 15, 19, 20, 21; Authentifizierung 1 für einen vorab geteilten Schlüssel und 3 für RSA-Signaturen. Geben Sie jeden Befehl aus, bevor Sie ihn ausführen, damit das Protokoll zeigt, was und in welcher Reihenfolge angeboten wurde.

Schritt 3: Deuten Sie eine Antwort

Eine Antwort beweist genau zwei Dinge: Ein IKE-Responder ist unter dieser Adresse erreichbar, und ein angebotener Vorschlag war akzeptabel. Sie sagt nichts über den vorab geteilten Schlüssel, die L2TP-Schicht oder darüber, ob ein Benutzerkonto existiert. Ein erfolgreicher Scan ist vollständig damit vereinbar, dass jede spätere Stufe scheitert.

Auf einem Gateway, das Sie betreiben, ist dies der wirklich nützliche Teil. Der Scan sagt Ihnen, welche Vorschläge das Gerät noch akzeptiert, und ein auf Alt-Transformationen beschränktes Ergebnis ist ein Befund zur Gerätepolitik, kein Grund, den Client zu schwächen.

Schritt 4: Deuten Sie Schweigen

Schweigen ist schwächere Evidenz, als es aussieht. Jeder Vorschlag kann abgelehnt worden sein, UDP 500 und 4500 können gefiltert sein, die Quelle kann nach einem Burst ratenbegrenzt sein, oder der Dienst kann auf einer anderen Adresse lauschen als der, die Sie gescannt haben. Vergleichen Sie das IKE-Log des Gateways mit einem Client, der sich bereits mit gültigen Anmeldedaten verbindet, bevor Sie irgendetwas über die Box schließen.

Burst-Verhalten gehört auf diese Liste, weil das Aufzählen viele Pakete in einem kurzen Fenster erzeugt. Ein Gateway, das die ersten Versuche beantwortet und dann verstummt, beschreibt seine Anti-DoS-Politik statt seines Vorschlagssatzes.

Schritt 5: Notieren Sie, was Sie bewiesen haben

Schreiben Sie die akzeptierte Kombination neben die Firmware-Version und vergleichen Sie sie dann mit den Transformationen, die Ihre wichtigen Clients standardmäßig anbieten. Die Lücke zwischen diesen beiden Listen ist das Konfigurationsproblem, und der Scan hat es nur sichtbar gemacht. Sind die einzigen akzeptierten Vorschläge solche, die Sie nicht wählen würden, gehört die Korrektur in die Gateway-Politik oder in ein Client-Profil, nie in die Probe.

Eine Probe, die nie geantwortet hat, hat dennoch etwas beantwortet: Sie zeigt, welche Vorschläge dieses Gerät bereit ist zu erörtern und welche es lieber fallen lässt.