Was gemessen wird, wird verbessert. Diesen Monat haben wir neun neue Sicherheits-Checks ausgerollt — manche sind Standard, fehlten aber in unserem eigenen Scanner; andere führt kein öffentlicher Wettbewerber aus. Dieser Post geht jeden Check durch, erklärt warum er wichtig ist, und wo die EU-Benchmark-Zahlen bisher stehen.
Warum die Check-Erweiterung?
Anfang April haben wir eine Vergleichsseite für fünf Wettbewerber geschrieben — SSL Labs, Mozilla Observatory, securityheaders.com, Hardenize, Internet.nl — und eine faktenbasierte Matrix versprochen, was jedes Tool prüft. Diese Matrix ehrlich zu schreiben bedeutete, uns selbst in Checks als partial oder no markieren, die unser Scanner noch nicht ausführte. Diese Liste wurde die Roadmap.
Drei Wochen später ist jede dieser Partial-Markierungen jetzt grün. Hier ist was gelandet ist.
Die neun Checks
1. Nameserver-Redundanz (RFC 2182)
Jede Domain braucht ≥2 Nameserver auf topologisch unterschiedlichen Netzwerken. Nicht "zwei Availability Zones beim selben Cloud-Provider" — wirklich unterschiedliche Netze, damit ein Ausfall oder BGP-Fehlkonfiguration nur einen von beiden erwischt.
Unser Check gruppiert die IPs jedes Nameservers nach /24 (IPv4) oder /48 (IPv6) und schlägt Alarm, wenn alle NS dasselbe Netz teilen. 1,2 % der überwachten Domains scheitern hier — meist kleine Setups mit zwei NS auf einem VPS.
2. SOA-Serial-Konsistenz
Jeder autoritative Nameserver serviert seine eigene Zonen-Kopie. Wenn einer hinterherhinkt — veraltetes Secondary, defektes AXFR, NOTIFY-Firewalled — werden DNS-Antworten inkonsistent, je nachdem welchen NS der Resolver trifft. Die SOA-Seriennummer ist der kanonische Versionsmarker; wir fragen sie bei jedem NS ab und flaggen Drift. Selten, aber wenn es passiert, katastrophal.
3. IPv6-Bereitschaft
Drei AAAA-Record-Checks zu einem Composite-Signal gebündelt: - Web (apex / www) über IPv6 erreichbar? - MX-Hosts über IPv6 erreichbar? - Nameserver über IPv6 erreichbar?
ok ist True nur wenn alle anwendbaren Signale True sind. Domains ohne MX-Records erhalten "Mail N/A" statt Failed — wir bestrafen keine reinen Service-Domains.
NIS2 Art. 21(2)(c) listet Business Continuity / Modernisierung als verpflichtende Maßnahmen. IPv6-Erreichbarkeit gehört dazu.
4. Subresource Integrity (SRI) auf Cross-Origin <script> und <link>
Jedes externe Script, das Ihre Seite lädt, ist eine Supply-Chain-Komponente. Der British-Airways-Breach 2018 passierte, weil ein Angreifer ein Modernizr-CDN kompromittierte und einen Skimmer in das minifizierte File einschleuste — das jeder Check-in-Browser brav ausführte.
SRI behebt das: <script src="…" integrity="sha384-…"> sagt dem Browser, ein Script nicht auszuführen, wenn der Hash nicht matched. Unser Check zählt Cross-Origin-<script>- und Stylesheet-<link>-Tags auf der gerenderten Seite und meldet, wie viele ein integrity=-Attribut haben. Fehlendes SRI ist ein Supply-Chain-Risiko, das weder SSL Labs noch Hardenize prüfen.
5. Mixed-Content-Erkennung
Eine HTTPS-Seite, die ein http://-Bild, Script oder iframe lädt, ist Mixed Content. Moderne Browser upgraden entweder still (manchmal) oder blockieren (meistens). So oder so: ein Zeichen für eine schlampige Template-Migration von einem legacy HTTP-Build. Wir parsen das gerenderte HTML nach src=, href=, action=, data=, oder poster= mit http:// auf einer https://-Seite. Gekappt bei 20 URLs pro Scan.
6. TLS 1.3 0-RTT (early_data)
0-RTT ist TLS 1.3's Optimierung fürs Session-Resume. Statt den Handshake abzuwarten, sendet der Client Anwendungsdaten im ersten Paket. Schnell — und replay-bar.
RFC 8446 §E.5 macht es klar: 0-RTT-Daten sind nicht forward-secret wie ein voller Handshake, und ein aktiver Angreifer kann sie replayen. Für idempotente GETs mag das OK sein. Für POST /transfer-money definitiv nicht.
Wir probeen den Server, parsen Max Early Data aus dem OpenSSL-Handshake-Banner, und flaggen wenn 0-RTT aktiv ist. SSL Labs prüft das. Hardenize prüft das. Observatory nicht. Wir jetzt schon.
7. HTTP/3-Advertisement (Alt-Svc)
HTTP/3 läuft über QUIC, und moderne Browser upgraden nur dann, wenn der Server es via Alt-Svc: h3=":443"-Header bewirbt. Kein Advertisement = der QUIC-fähige Server bleibt für jeden Besucher auf HTTP/2. Ein Performance- und Energieeffizienz-Gap, den zu schließen nichts kostet.
Keiner der Standard-Scanner prüft das — wir haben's nur bemerkt, weil wir die Vergleichsseite geschrieben haben.
8. robots.txt / ads.txt-Integrität
Zwei Info-Disclosure-Checks in einem Pass:
- robots.txt mit langen
Disallow:-Listen, die/admin,/backup,/.git,/stagingnennen — Angreifer nutzen das als Landkarte. Wir matchen gegen 17 häufige sensible Pfade und melden die Anzahl. - ads.txt (IAB-Spec) mit null gültigen Einträgen — vorhanden-aber-leer ist schlimmer als fehlend, weil programmatische Käufer das als "keine autorisierten Verkäufer" interpretieren und Ad-Fraud-Bots die Lücke ausnutzen.
9. security.txt-Qualität (RFC 9116 §2.5.4)
Bisher fragte unser Scanner nur: existiert /.well-known/security.txt? Jetzt parsen wir es richtig:
- Mehrfach-
Contact:(RFC 9116 erlaubt mehrere). Expires:in der Vergangenheit macht die Datei per §2.5.4 ungültig. Eine abgelaufene security.txt ist schlimmer als keine — sie signalisiert einen toten Offenlegungsprozess.Canonical:-URL muss zum abgerufenen Host passen.Encryption:,Policy:,Acknowledgments:,Preferred-Languages:vollständig erfasst.
~14 % der security.txt-Dateien, die wir im März als "valid" markiert hatten, waren tatsächlich abgelaufen. Das sind 14 % Offenlegungs-Kontakte, die still ins Leere laufen würden. Jetzt gefixt.
Bonus: JARM-Drift-Erkennung (wöchentlich)
Ab dieser Woche bekommt jede überwachte Domain einen wöchentlichen TLS-Fingerprint via einer leichten Implementierung von Salesforces JARM-Algorithmus. Der Hash ändert sich, wenn:
- Sie die Server-Implementierung wechseln (nginx → Caddy, AWS ALB → CloudFront)
- Ihre TLS-Policy sich verschiebt (Cipher-Prioritäten, ALPN-Liste)
- Jemand einen komplett anderen Server hinter dieselbe DNS stellt
Fall drei ist der interessante — genau so treten Shadow-IT, Account-Kompromittierung und Fehlkonfigurationen zutage. Wir speichern den Hash und alerten bei Änderung.
Und weil wir gegen 75 bekannte C2-Framework-JARM-Hashes cross-referencen (Cobalt Strike, Sliver, Metasploit, Brute Ratel, Mythic, AsyncRAT, Trickbot, …), ist ein Match jetzt ein lautes Alarm-Signal — nicht nur "dein TLS hat sich geändert", sondern "dein TLS sieht aus wie ein C2-Server."
Das ist ein offensiver Check, den kein Wettbewerber durchführt.
Was das für Ihre Note bedeutet
Die Scoring-Engine behandelt die neuen Signale behutsam:
- Modernisierungs-Bonus (NS-Redundanz, SOA-Konsistenz, IPv6, HTTP/3) gibt bis zu +6 Punkte, gecappt bei 100, damit bestehende A-Noten nicht überlaufen. Niemand bekommt dadurch eine schlechtere Note.
- Discovery-Scan-Abzüge (Takeover, JARM C2) greifen nur bei bestätigten Findings. Wenn Ihr wöchentlicher Discovery-Scan sauber ist, sehen Sie keinen Abzug.
Re-scanneen Sie Ihre Site — die neuen Zeilen erscheinen automatisch.
Was als nächstes kommt
Roughly nach Priorität:
- Certificate-Transparency-Log-Monitoring (Alarm bei neuem Zertifikat für Ihre Domain — erkennt rogue issuance).
- BGP-Hijack-Indikatoren (AS-Path-Anomalien für Ihre Hosting-IP).
- DMARC-Rollout-Reifegrad (Gradient p=none → quarantine → reject mit Policy-Maturity-Scoring).
Falls es einen Check gibt, den unser Scanner Ihrer Meinung nach laufen sollte — antworten Sie auf diesen Post oder schreiben Sie uns. Genau so ist die Liste dieses Monats entstanden.
— Das SiteGuardian-Team