Warum sich ein Portscan mit sudo anders verhält

Nmap sendet nicht immer das Paket, von dem Sie glauben, es angefordert zu haben. Wenn Raw-Sockets nicht verfügbar sind, ersetzt es den standardmäßigen SYN-Scan durch einen TCP-Connect-Scan, sodass ein Lauf als normaler Benutzer und ein Lauf unter sudo unterschiedliche Fragen zum selben Port beantworten können. Die Ergebnisse sehen wie ein Rechteproblem aus, und meist sind sie eine Methodenänderung. Die Methode explizit zu machen, ist der einzige Weg, die beiden Läufe überhaupt zu vergleichen.

Zwei Sonden, ein Port, verschiedene Codepfade

Ein SYN-Scan baut den TCP-Header selbst, sendet ihn aus einem Raw-Socket und liest die Antwort vom Draht, bevor der TCP-Stack des Kernels jemals eine abgeschlossene Verbindung verzeichnet. Ein Connect-Scan bittet das Betriebssystem, einen gewöhnlichen Socket zu öffnen, und meldet, was connect() zurückgibt. Beide können einen Port als offen bezeichnen, doch nur eine hinterlässt einen halboffenen Versuch, und nur eine unterliegt Socket-Richtlinien, die an den sendenden Prozess gebunden sind.

Der Raw-Pfad benötigt CAP_NET_RAW, weshalb der Standard-Scan still zurückfällt, wenn diese Fähigkeit fehlt. Nmaps eigener Überblick über Scan-Techniken dokumentiert die Ersetzung: Der Connect-Scan ist der Rückfall, weil er überhaupt keine besonderen Rechte braucht. Der Austausch geschieht in den meisten Läufen ohne Warnung, und genau das macht ihn so leicht falsch zu lesen. Sobald man weiß, dass der Rückfall existiert, klingt „offen als root, geschlossen als Benutzer“ nicht mehr nach einem Rechtefehler, sondern nach zwei verschiedenen Messungen.

Was sudo im Scan tatsächlich ändert

Erhöhte Rechte stellen den Raw-Socket-Pfad wieder her, und das ändert mehr als das Urteil. Quellportwahl, Paket-Timing, Neuübertragungsverhalten und die Art, wie eine gefilterte Antwort klassifiziert wird, stammen alle aus anderem Code. Eine Middlebox, die SYNs drosselt, behandelt die beiden Läufe ungleich, selbst wenn der Zielhost identisch ist.

Auch die Protokollierung auf der Zielseite weicht ab. Ein abgeschlossener Handshake ist für den Dienst und jede Socket-Abrechnung sichtbar, eine zurückgesetzte halboffene Sonde häufig nicht. Wenn Sie Läufe gegen einen Host vergleichen, dessen Protokolle Sie ebenfalls lesen, ist ein Teil des beobachteten Unterschieds die Beobachtung selbst.

Halten Sie die Methode in beiden Läufen konstant

Erzwingen Sie in beiden Aufrufen dieselbe Technik, und der Vergleich beginnt etwas zu bedeuten. Das Flag -sT fordert ausdrücklich einen Connect-Scan an, -Pn entfernt die Hosterkennung, -n entfernt die Namensauflösung, und ein einzelnes -p entfernt Unterschiede der Portliste.

nmap -sT -Pn -n -p 8443 198.51.100.77
sudo nmap -sT -Pn -n -p 8443 198.51.100.77

Ersetzen Sie Adresse und Port durch einen Host, den Sie testen dürfen; der Dokumentationsbereich oben ist ein Platzhalter, kein Ziel. Stimmen die beiden Läufe nun überein, kam der ursprüngliche Unterschied von der Scanmethode. Weichen sie weiterhin voneinander ab, klassifiziert etwas anderes den Verkehr, und der nächste Abschnitt zeigt, wo Sie nachsehen.

Kontokontext ist nicht nur ein Rechteflag

Ein VPN-Deployment kann Pakete nach UID, nach cgroup oder nach einer Regel klassifizieren, die an den Prozess gebunden ist, der den Socket geöffnet hat. Dann verlassen Root-Verkehr und Benutzerverkehr unterschiedliche Routingtabellen oder treffen auf unterschiedliche Regelsätze, und keine Scanmethoden-Disziplin gleicht das aus.

Prüfen Sie die Richtlinie statt das Recht. Unter Linux drückt nftables das mit meta skuid aus und iptables mit dem Owner-Match, und jede der beiden kann eine einzelne UID durch einen Tunnel schicken, während die andere weiterhin die physische Standardroute nutzt.

sudo nft list ruleset | grep -n skuid
sudo iptables-save | grep -n uid-owner
ip rule show
ip route get 198.51.100.77

Bestätigen Sie die Sonde, bevor Sie Ergebnisse vergleichen

Bevor Sie Schlüsse ziehen, weisen Sie nach, welche Sonde lief. Nmap benennt die Technik in seiner eigenen Ausgabe, und --reason ergänzt den Beleg hinter jedem Zustand, und dieser Teil sagt Ihnen, ob ein Handshake tatsächlich abgeschlossen wurde.

nmap --reason -sT -Pn -n -p 8443 198.51.100.77
sudo nmap --reason -sS -Pn -n -p 8443 198.51.100.77
getcap "$(command -v nmap)"
capsh --print | grep -i net_raw

Zwei Läufe, die denselben Zustand aus verschiedenen Gründen melden, sind kein Widerspruch, und zwei Läufe, die verschiedene Zustände aus demselben Grund melden, deuten auf Routing oder Richtlinie statt auf den Scan hin. Halten Sie Ziel, Port, Namensraum und Timing identisch und ändern Sie dann jeweils eine Variable. Den Dienst als root laufen zu lassen ist nicht die Reparatur für eine Richtlinien-Abweichung; die beabsichtigte Richtlinie über den Eigentümer des Dienstes auszudrücken, ist es.