YADS hinter Gittern: Der Kampf gegen den Corporate Proxy
Tja... wer in einer modernen Enterprise-Umgebung Security-Tools bauen will, merkt schnell: Das Internet ist kein Ponyhof. Es ist ein Hochsicherheitstrakt mit Stacheldraht, Wachtürmen und dem ultimativen Endgegner... dem HTTP-Proxy.
Kennt ihr das? Ihr habt ein tolles neues Tool gebaut, lokal flutscht alles wie geschmiert, und dann rollt ihr es aus und... Crickets. Nichts geht mehr. Connection refused. SNAFU.
Warum? Weil Tools wie Nmap oder Playwright den Corporate Proxy ignorieren wie ich die Werbung vor YouTube-Videos. ;-)
🧱 Die Ausgangslage: ZScaler & Co.
Wenn ein Proxy (egal ob explizit oder transparent) zwischen dem YADS-Worker und dem Ziel sitzt, wird es haarig. Wir reden hier meistens von HTTP/HTTPS-Connect-Tunneling. Die üblichen Verdächtigen wie HTTP_PROXY und HTTPS_PROXY sind gesetzt, aber nicht jeder Scanner-Modul spielt mit.
Ich habe mal eine Bestandsaufnahme gemacht... und die war... ernüchternd.
✅ Was funktioniert (ca. 60%):
Alles, was requests oder httpx nutzt. Die Jungs sind brav und lesen die Env-Vars. ssl_scanner, security_txt, cookie_scanner — die laufen einfach.
❌ Was sang- und klanglos untergeht (40%):
- Playwright / Chromium: Ein Subprozess, dem die System-Env-Vars völlig egal sind. Screenshots? Tech-Stack-Detection? Fehlanzeige.
- Nmap / Infrastructure Scanning: Nutzt Raw-Sockets. In einer Proxy-Umgebung? Vergiss es. Da hilft kein Tunnel der Welt.
- DNS (UDP 53): Hinter einem Enterprise-Proxy ist UDP 53 oft dicht wie ein U-Boot. Bye bye, dns_scanner.
🗺️ Der Schlachtplan: In 5 Phasen zur Freiheit
Wir können nicht alles fixen, aber wir können verdammt nah dran kommen. Hier ist die Roadmap, die ich mir für die nächsten Wochen vorgenommen habe:
Phase P-0: Die "Low Hanging Fruits"
Einfach die Proxy-Env-Vars im docker-compose.yml beim Worker-Service reinwerfen. Bringt sofort 60% Funktionalität zurück. Kostet 10 Minuten Zeit. Done.
Phase P-1: Playwright an die Leine nehmen
Playwright braucht explizit das --proxy-server= Flag. Ich werde ein neues Setting BROWSER_PROXY_URL einführen, damit die Browser-Module (visual_osint, web_analyzer, etc.) endlich wieder sehen können, was sie scannen.
Aufwand: ~2-3 Stunden.
Phase P-2: Nuclei Proxy-Support
Nuclei v3 unterstützt das --proxy Flag nativ. Muss nur noch in nuclei_scanner.py eingebaut werden. Quick Win! :)
Phase P-3: DNS-over-HTTPS (DoH)
Das ist der spannende Teil. Da UDP 53 meistens tot ist, weichen wir auf DoH aus. dns_scanner.py lernt demnächst, wie man DNS-Queries über HTTPS an Cloudflare oder Google schickt – getunnelt durch den Proxy. Genial, oder?
Phase P-4 & P-5: UI & Das Unausweichliche
Am Ende kommt noch eine schicke UI-Sektion für die Netzwerk-Settings. Was Nmap angeht: Das wird hinter einem Proxy nie funktionieren. Da brauchen wir ein Feature-Flag, das den Modus deaktiviert und stattdessen auf Shodan/Censys-Daten verweist. Graceful degradation nennt man das, glaube ich.
Fazit
Realistisch gesehen kommen wir auf 90% Proxy-Kompatibilität. Die restlichen 10% (Nmap Raw Scanning) sind technisch halt einfach "by design" nicht proxy-fähig. Aber hey... 90% ist deutlich besser als der aktuelle Totalausfall in manchen Umgebungen.
Wir biegen das hin. Schritt für Schritt.
Man liest sich... ;-)
Transparency Note: Einige Inhalte, Code-Snippets und Beschreibungen in diesem Post wurden mittels KI (LLMs / Vibecoding) erstellt oder unterstützt, jedoch von mir persönlich kuratiert, überarbeitet und geprüft. Wie immer... sonst wär's ja nicht ehrlich. ;-)