Schwachstellenscanner für Server
Findet, was der Webserver preisgibt: geleakte Konfigurationen und Backups, offene Verzeichnisse, Softwareversionen in Headern, veraltetes TLS, riskante Endpunkte und DNS-Fehler.
Die meisten Einbrüche beginnen nicht mit einer raffinierten Zero-Day-Lücke. Sie beginnen mit etwas, das der Server jedem gibt, der fragt: eine vergessene .env-Datei, ein Backup-Archiv im Web-Root, eine Softwareversion im Header, die direkt auf eine bekannte Schwachstelle zeigt. Der Schwachstellenscanner sucht genau solche Schwachpunkte — dieselben, nach denen automatisierte Angriffsbots jeden Tag auf jeder öffentlichen Adresse suchen.
Was der Scanner prüft
Geleakte Dateien und Geheimnisse. Der Scanner fragt die Adressen ab, an denen Deployments am häufigsten etwas zurücklassen: .env und andere Konfigurationsdateien, den Ordner .git, Datenbank-Dumps, .zip- und .tar.gz-Archive der Website, eine Sicherung von wp-config.php, .DS_Store, phpinfo- und server-status-Seiten. Ein Befund wird nur gemeldet, wenn der Inhalt der Antwort ihn bestätigt — ein echtes .git/HEAD, eine echte Variablenliste —, sodass eine Website, die auf jede Adresse mit „200 OK“ antwortet, keine Fehlalarme erzeugt.
Offene Verzeichnisse und Quellcode. Ein Verzeichnis-Listing macht einen Ordner zum öffentlichen Katalog von allem, was je dorthin hochgeladen wurde. Öffentliche JavaScript-Source-Maps liefern den unminifizierten Code samt Kommentaren und internen Pfaden. Beides lässt sich leicht abschalten, und beides wird mit der genauen Adresse gemeldet.
Softwareversionen in den Headern. Header wie Server: Apache/2.4.29 oder X-Powered-By: PHP/7.2.5 verraten einem Angreifer, welche bekannten Schwachstellen er zuerst probieren sollte. Der Scanner listet jeden Header und jedes Seitenfragment mit exakter Version auf und zeigt, wie man sie in der Serverkonfiguration verbirgt.
Protokolle und Verschlüsselung. Wir prüfen, welche TLS-Versionen und Zertifikate der Server akzeptiert, ob die Zertifikatskette vollständig ist, ob HTTP auf HTTPS umleitet und ob HTTP/2 und HTTP/3 unterstützt werden. Alte Protokolle sind an sich eine Schwachstelle und ein häufiger Grund, an PCI-DSS- und ähnlichen Audits zu scheitern.
Gefährliche Methoden und Cross-Origin-Zugriff. Ein Server, der auf TRACE antwortet oder jeden Ursprung zusammen mit Anmeldedaten in Access-Control-Allow-Origin spiegelt, kann gegen Ihre eigenen Besucher eingesetzt werden. Der Scanner sendet harmlose Testanfragen und meldet, was zurückkam.
CMS-Endpunkte. Bei WordPress-Websites prüfen wir die Routen, die jedem antworten: die REST-Route mit den Login-Namen aller Autoren und xmlrpc.php — den Endpunkt, den Passwort-Rate-Tools nutzen, weil er Hunderte Versuche in einer Anfrage erlaubt. Bei anderen Plattformen suchen wir nach offenen Admin- und Installationsseiten.
DNS und Perimeter. Wildcard-DNS-Einträge, verwaiste CNAME-Einträge, die auf nicht mehr existierende Dienste zeigen (ein klassisches Subdomain-Takeover-Szenario), fehlende CAA-Einträge, der Zustand von DNSSEC und IPv6 — alles, was beschreibt, wie die Domain selbst eingerichtet ist.
Ein sicherer Scan
Der Scanner nutzt nichts aus. Er errät keine Passwörter, sendet keine Angriffs-Payloads, versucht keine Authentifizierung zu umgehen und überlastet den Server nicht: Es sind wenige, zeitlich verteilte Anfragen, die sich nicht von denen eines normalen Browsers unterscheiden. Deshalb kann er gefahrlos während der Arbeitszeit gegen eine Produktivseite laufen. Es bedeutet aber auch, dass der Scanner Konfigurationsschwächen und Lecks findet, keine Fehler tief in der Anwendungslogik — dafür braucht es einen Penetrationstest mit Ihrer Erlaubnis und Zugängen.
Wie der Bericht aussieht
Jeder Befund hat eine Schwere — kritisch, hoch, mittel oder niedrig — und eine verständliche Erklärung: was genau gefunden wurde, unter welcher Adresse, was ein Angreifer damit tun könnte und wie man es schließt. Wo möglich, wird die Korrektur als fertige Konfiguration für nginx, Apache oder die Plattform angegeben. Kritische Befunde wie eine herunterladbare .env oder .git stehen ganz oben, denn sie müssen heute geschlossen werden, nicht im nächsten Sprint.
Regelmäßige Prüfungen
Ein Server wird nicht ein für alle Mal eingerichtet: Ein neues Release, ein Plugin-Update oder ein Hostingwechsel kann ein altes Problem zurückbringen. Nehmen Sie die Website ins Monitoring auf, und der Scan wird automatisch wiederholt; ein neuer kritischer Befund kommt per E-Mail oder Telegram. Über die API lässt sich derselbe Scan nach jedem Deployment aus der CI starten, damit eine geleakte Datei gefunden wird, bevor ein Bot sie findet.
Audit beauftragen
Nennen Sie uns die Adresse der Website und was Sie beunruhigt. Ein Spezialist führt das Audit durch, prüft jeden Befund von Hand und schickt Ihnen den Bericht mit einer priorisierten Liste von Korrekturen.