Ein Autorisierungs-Gate für aktives Scanning: Sicher per Konstruktion

Jeder aktive Scanner — nmap, httpx, nuclei — ist ein geladenes Werkzeug. Auf ein System gerichtet, das man besitzt oder testen darf, ist es Aufklärung. Auf eines gerichtet, das man nicht darf, ist es in den meisten Rechtsordnungen eine Straftat. Das Einzige zwischen diesen beiden Ausgängen ist die Autorisierung — und in den meisten Security-Tools ist Autorisierung ein Häkchen, das ein Mensch einmal gesetzt hat, keine Kontrolle, die die Software bei jedem einzelnen Scan durchsetzt. Dieser Beitrag dokumentiert ein anderes Design: eine Architektur, in der „autorisiert und im Scope" ein Gate ist, das das System nur passieren lässt, wenn die Bedingungen im Moment des Scan-Starts tatsächlich erfüllt sind.

Das Muster entstand beim Bau einer Plattform, auf der ein Operator das Engagement scopt, die Recon durchführt und den Report unterschreibt. Diese Bequemlichkeit ist zugleich die Gefahr: nichts hindert einen müden Berater daran, den falschen Host zur falschen Zeit ins richtige Werkzeug einzufügen. Also musste Autorisierung aufhören, eine Frage der Disziplin zu sein, und eine Frage der Architektur werden — etwas, das das System verweigern kann, nicht nur etwas, das sich der Operator merken soll.

Autorisierung muss eine Kontrolle sein, kein Kommentar

Rules of Engagement leben üblicherweise in einem PDF: ein unterschriebener Scope, ein IP-Bereich, eine Ausschlussliste, ein Testfenster. Der Scanner liest dieses PDF nie. Die Lücke zwischen dem Dokument, das die Befugnis erteilt, und dem Werkzeug, das sie ausübt, ist der Ort, an dem Out-of-Scope-Scans passieren — nicht aus böser Absicht, sondern durch einen vertippten Hostnamen, eine veraltete Ziel-Liste oder einen Scan, der nach Schließen des Fensters gestartet wurde.

Diese Lücke zu schließen heißt, die Rules of Engagement als Daten zu kodieren, die die Software prüft, und den Scan zu verweigern, wenn die Prüfung scheitert. Der Scope, die Ausschlüsse und die Engagement-Phase hören auf, Prosa zu sein, und werden zur Vorbedingung. Der Operator muss sich die Grenze nicht mehr merken; das System überschreitet sie nicht.

Die erste Kontrolle: die App kann nicht scannen

Die Web-Anwendung, die das Ganze steuert, läuft mit einem read-only Root-Dateisystem und allen verworfenen Linux-Capabilities. Das ist gewöhnliche Container-Härtung — aber hier hat es einen zweiten Zweck. Ein Prozess, der nicht auf die Platte schreiben kann und keine Capabilities hält, kann keinen Portscanner sinnvoll starten und betreiben. Die App ist strukturell unfähig zu scannen, und das ist Absicht.

Aktives Scanning wird daher an einen separaten Worker-Container über eine Queue delegiert. Die App validiert und reiht ein; der Worker — der in einem eigenen Egress-only-Netz ohne eingehende Ports lebt — nimmt den Job auf und führt die Werkzeuge aus. Die Trennung ist selbst die Kontrolle: ein Bug in der Web-Schicht, oder sogar ein kompromittierter Request-Handler, erreicht trotzdem keinen Scanner direkt. Der einzige Weg zu nmap führt durch die Queue, und das Einzige, was auf die Queue darf, hat das Gate passiert.

Das Gate: vier Bedingungen, und Ausschlüsse gewinnen immer

Eine Scan-Anfrage wird verweigert, sofern nicht jede der folgenden Bedingungen gilt:

• Im Scope. Das Ziel entspricht einem Scope-Eintrag des Engagements — einer Domain (Subdomains eingeschlossen), einem CIDR-Bereich (CIDR-gematcht, nicht String-verglichen) oder einer benannten Anwendung.
• Nicht ausgeschlossen. Das Ziel entspricht keinem Ausschluss-Eintrag. Ausschlüsse gewinnen immer: liegt ein Host sowohl in einem In-Scope-Bereich als auch auf der Ausschlussliste, ist er draußen. Es gibt kein Override.
• Aktives Engagement. Das Engagement ist in einer ACTIVE- oder REPORTING-Phase — nie, während es noch gescopt wird, oder nachdem es ausgeliefert oder geschlossen wurde.
• Ausdrückliche Einwilligung. Die Anfrage trägt ein explizites Autorisierungs-Flag. Ein Scan ist nie das beiläufige Ergebnis von Herumklicken; er ist ein aktiver Schritt.

Kein definierter Scope bedeutet kein Scan — das Fehlen einer Autorisierung wird als Verweigerung behandelt, nicht als Blankoscheck. Und der getroffene Scope wird zusammen mit der Identität des startenden Nutzers auf den Job geschrieben. Die Autorisierung wird zum Startzeitpunkt eingefroren, sodass ein später bearbeitetes Engagement nicht rückwirkend ändern kann, was ein vergangener Scan berühren durfte.

Defense in Depth: der Worker nimmt an, das Gate liegt falsch

Der Worker ist keine Vertrauensgrenze. Er führt aus, welchen autorisierten Job die gegatete App ihm übergibt — also ist er gebaut, als könnte das Gate falsch liegen. Selbst mit einem gültigen Job führt er nmap als TCP-Connect-Scan aus (-sT, keine Raw-Sockets, keine NET_RAW-Capability) und schließt die nuclei-Template-Familien dos, intrusive und brute-force von vornherein aus. Harte Timeouts begrenzen jedes Werkzeug. Das Ergebnis sind zwei unabhängige Schichten: das Gate entscheidet, ob ein Scan überhaupt stattfinden darf, und der Worker begrenzt, wie viel Schaden ein Scan anrichten kann, selbst wenn das Gate je etwas durchließe.

Was der Audit-Trail bringt

Weil das Gate den autorisierenden Nutzer, den getroffenen Scope und den Zeitstempel auf jeden Job schreibt, kann das System die eine Frage beantworten, die im Nachhinein zählt: „Warum hast du diesen Host gescannt?" Die Antwort ist ein Datensatz, keine Erinnerung — das Engagement, zu dem er gehörte, der Scope-Eintrag, der ihn autorisierte, die Person, die ihn startete, und wann. Dieser Datensatz ist der Unterschied zwischen einem verteidigbaren Engagement und einer unangenehmen E-Mail.

Er macht die Grenze auch vorab auditierbar. Ein Prüfer kann den Scope und die Ausschlüsse lesen und wissen, was das System tun wird und was nicht — ohne darauf zu vertrauen, dass sich der Operator korrekt verhält. Die Kontrolle ist inspizierbar, nicht bloß angestrebt.

Dieselbe Form lässt sich verallgemeinern

Aktives Scanning ist das scharfe Beispiel, aber die Form ist überall wiederverwendbar, wo Software eine Handlung mit realen Konsequenzen ausführen kann: Trenne die entscheidende Komponente von der handelnden; lass die entscheidende Komponente standardmäßig verweigern; schreibe die Autorisierung revisionssicher auf die Handlung; und baue die handelnde Komponente, als könnte die Entscheidung falsch sein. Es ist dieselbe Least-Privilege-, Defense-in-Depth-Disziplin, die Firewall-Change-Management seit jeher verlangt — angewandt auf das Werkzeug selbst statt auf die Regeln, die es verwaltet.

Warum das wichtig ist

Der günstigste Ort, einen Out-of-Scope-Scan zu stoppen, ist in der Software, bevor das erste Paket den Host verlässt. Sich darauf zu verlassen, dass der Operator die Rules of Engagement im Kopf hat, funktioniert genau bis zu dem einen Mal, an dem es nicht klappt — und im Security-Testing ist dieses eine Mal das Mal, das im Postfach eines Anwalts landet. Autorisierung als durchgesetzte Kontrolle zu kodieren verwandelt „wir waren vorsichtig" in „das System hätte es uns nicht erlaubt" — ein deutlich besserer Satz gegenüber einem Kunden, einem Auditor oder einem Gericht.