Eine autorisierte Prüfung eines auf dem Smartphone gehosteten VPN scheitert still, wenn der Scanner auf der falschen Seite des Tunnels sitzt. Man bekommt Ergebnisse, sie sehen plausibel aus, und sie beantworten eine Frage, die niemand gestellt hat. Arbeiten Sie die fünf Prüfungen unten der Reihe nach durch. Jede hat eine Abbruchbedingung, und früh aufzuhören ist billiger, als nach dem Schreiben des Berichts von vorn zu testen.

Schritt 1: Benennen Sie die Oberfläche, die Sie erreichen wollen

Drei Oberflächen werden regelmäßig verwechselt, weil ein Gerät sie verbindet. Sie führen unterschiedlichen Code und unterschiedliche Richtlinien aus, deshalb schreiben Sie vor jedem Start auf, welche im Umfang liegt.

Assessment targetWhat the path exercises
Public VPN listener on the handsetReachability before login, plus the exposed VPN daemon
A service on the handset, by its tunnel addressAccess after admission to something hosted locally
A LAN host behind the handset gatewayForwarding, the return path and downstream access policy

Sagt der genehmigte Umfang nicht, welche der drei, halten Sie an und fragen Sie. Ein Root des Telefons beantwortet diese Frage nicht und verändert die getestete Sache statt des Beobachtungspunkts.

Halten Sie Ziele, erlaubte Quelladressen, Zeitfenster und Intensitätsgrenze gleichzeitig fest. Der Tunnel bringt Sie in diesen Umfang; er erlaubt nicht, alles zu prüfen, was er routen kann.

Schritt 2: Wählen Sie die Quelle, die diese Oberfläche sehen kann

Ein Scanner innerhalb des VPN kann einen nicht authentifizierten Internetbeobachter nicht nachbilden. Er hat bereits Routen, Anmeldedaten und Berechtigungen, die dem äußeren Beobachter fehlen, seine Ergebnisse beschreiben also die Sicht nach der Zulassung, selbst wenn die Zieloberfläche dieselbe ist. Der umgekehrte Fehler ist genauso häufig. Ein öffentlicher Scan des VPN-Ports sagt fast nichts über einen privaten Dienst hinter dem Login aus, und ihn so zu berichten, als täte er es, überschätzt die Exposition in die eine Richtung und unterschätzt sie in die andere.

Halten Sie an, wenn die erhältliche Quelle nicht zur Oberfläche passt. Eine Prüfung von einem Peer innerhalb des Tunnels sollte nicht als Ergebnis vor der Authentifizierung dargestellt werden, und ein Test, der eine genehmigte externe Quelle verlangt, sollte nicht still nach innen verlegt werden, um den Papierkram zu vermeiden.

Schritt 3: Bestätigen Sie die Route und den Rückweg über das Telefon

Wenn das Gerät in ein anderes Subnetz weiterleitet, braucht der Scanner eine erlaubte Route und das Ziel einen funktionierenden Rückweg. Bestätigen Sie beides, statt anzunehmen, eine Ping-Antwort bedeute, der Weg sei vollständig.

ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8

Source NAT verändert, was der nachgelagerte Dienst sieht. Übersetzt das Telefon die Adresse des Scanners, gelten die Zugriffsregeln und Protokolle am Ziel für die übersetzte Adresse, ein Dienst, der Sie anzunehmen scheint, nimmt also vielleicht das Telefon statt den Scanner an.

Achten Sie auch auf eine Überschneidung mit dem eigenen Netz des Scanners. Routet das Telefon 192.168.1.0/24 und sitzt der Scanner in einem gleich nummerierten LAN, treffen die Sonden lokale Geräte, und der Bericht beschreibt sie als das Ziel. Prüfen Sie die Route, die der Scanner selbst nutzen würde, bevor Sie ein einziges Paket senden.

Scannen Sie die tatsächliche Zieladresse und behalten Sie den Hostnamen, den die Anwendung für TLS-Identität und virtuelles Hosting braucht. Ein Gateway zu erreichen beweist, dass das Gateway antwortet; es prüft nicht den Dienst dahinter.

Schritt 4: Behandeln Sie die Erkennung als Sonde mit Annahmen

Die Hosterkennung ist der Punkt, an dem Prüfergebnisse am häufigsten schiefgehen. Lokale Ethernet-Erkennung überquert ein geroutetes VPN nicht, die Sonden, die in einem flachen LAN funktionieren, kommen also schlicht nicht an. Blockierte Erkennungssonden lassen dann einen erreichbaren, autorisierten Dienst als abwesend erscheinen.

Entscheiden Sie bewusst, ob Sie die Erkennung überspringen und die bekannten Adressen direkt scannen, und sagen Sie das im Bericht. Ein Port, der antwortet, ist kein Beweis, dass die VPN-Authentifizierung gelungen ist, und eine gefilterte Antwort ist kein Beweis, dass nichts lauscht. Auch die Rate gehört zum selben Problem. Ein Telefon, das bei einem schnellen Scan drosselt oder verwirft, erzeugt gefilterte Zustände, die zum Telefon und nicht zum Dienst gehören, reduzieren Sie also die Parallelität und scannen Sie erneut, bevor Sie einen Port als geschlossen festhalten.

Die Abbruchbedingung ist hier Auslegung, nicht Technik: Können Sie nicht sagen, was ein Zustand für diesen Weg bedeutet, gehört das Ergebnis in einen Anhang und nicht in die Befunde.

Schritt 5: Halten Sie das Fenster und schließen Sie es dann

Ein Telefon ist ein schlechter Server, weil es zum Schlafen gebaut ist. Akku-Optimierung, Doze und Wi-Fi-Energieverwaltung können die App mitten in der Prüfung aussetzen, und ein erneutes Verbinden des Tunnels kann die Adresse ändern, die das Ziel nutzt. Ein Lauf, der eines dieser Ereignisse überspannt, hat ein ungültiges Ergebnisfenster.

Halten Sie die Gateway-Rolle im kleinsten Umfang, den die genehmigte Aufgabe zulässt, beobachten Sie den Tunnel, solange der Lauf aktiv ist, und protokollieren Sie Beginn und Ende jedes gemeldeten Fensters. Wenn die Prüfung endet, entfernen Sie den temporären Zugang über dessen Eigentümer, behalten Sie den Quell- und Routennachweis und schützen Sie die Ausgabe wie jedes andere Testartefakt.

Brauchen Sie einen wiederholbaren Beobachtungspunkt statt eines einmaligen Erfolgs, ist das das Ergebnis, für das Sie argumentieren sollten. Referenz zur Hosterkennung erklärt, welche Sonden ein lokales Segment voraussetzen, und genau dieses Detail macht aus einem leeren Ergebnis eine belastbare Aussage.

Ähnliche Artikel