Über den Scanner

Was dieser Scanner tut

• Er läuft nur, wenn eine Person ihn anstößt. Es gibt kein Crawling, keine geplanten Scans und keine Zielliste – ein Scan startet entweder, weil jemand auf dieser Website eine Domain in das Formular eingegeben hat, oder weil jemand einen Link geöffnet hat, der bereits eine enthält (/?domain=beispiel.de). Erneute Aufrufe innerhalb derselben Stunde werden aus dem Cache beantwortet und öffnen keine neuen Verbindungen zu Ihren Servern; Crawler, die sich an robots.txt halten, lösen überhaupt keinen Scan aus.
• Er ist rein lesend. Er sendet eine Handvoll einfacher GET-Anfragen über HTTP und HTTPS – die Startseite, /.well-known/security.txt und, nur falls diese nichts ergibt, das ältere /security.txt; eine MTA-STS-Policy von mta-sts.<domain>; ein BIMI-Logo und Mark-Zertifikat von den URLs, die Ihr eigener Record nennt; sowie – nur wenn Ihre security.txt einen Schlüssel nennt oder signiert ist – diese Schlüssel-URL und die Web-Key-Directory-Abfrage zu ihrer Kontaktadresse, unter /.well-known/openpgpkey/ auf Ihrer Domain und auf dem Host openpgpkey.<domain>. Er führt TLS-Handshakes auf Port 443 und eine kurze QUIC-Probe auf UDP 443 je Adressfamilie durch (das ist die HTTP/3-Prüfung) und verbindet sich mit den MX-Servern der Domain auf Port 25, um STARTTLS zu prüfen – es wird keine Mail versendet, die Session endet mit QUIT.
• Er testet nicht auf Schwachstellen. Er bewertet veröffentlichte Konfiguration (Zertifikate, TLS-Versionen, DNS-Records, HTTP-Response-Header) anhand öffentlicher Standards – dieselben Checks, die Tools wie SSL Labs, internet.nl oder securityheaders.com durchführen.
• Er ist rate-limitiert, gedrosselt und gecacht. Ein vollständiger Scan öffnet grob 50 bis 120 kurzlebige Verbindungen zu Ihrem Webserver – überwiegend TLS-Handshakes, weil jede Cipher Suite einzeln geprüft und je Adressfamilie ein Backend vollständig profiliert wird; ein Server mit langer Suite-Liste liegt am oberen Ende, ein reiner TLS-1.3-Server am unteren. Dazu kommen bis zu rund 40 SMTP-Verbindungen, verteilt auf Ihre fünf bestpriorisierten MX-Hosts, und je eine Abfrage pro autoritativem Nameserver auf Port 53. Die TLS- und Mail-Proben sind so gedrosselt, dass immer nur eine Handvoll gleichzeitig läuft. Ergebnisse werden eine Stunde lang gecacht, eine erneute Prüfung derselben Domain innerhalb dieses Fensters löst also keine neuen Verbindungen aus. Ein manueller Refresh kann eine Neuprüfung erzwingen, aber nur einmal pro Minute und Abschnitt.
• Die meisten DNS-Abfragen berühren Ihre Infrastruktur nicht. Sie laufen über öffentliche DNS-over-HTTPS-Resolver (Google, Cloudflare). Zwei Prüfungen sind die Ausnahme und fragen Ihre autoritativen Nameserver direkt auf Port 53: eine, ob sie autoritativ antworten, untereinander übereinstimmen und zur Delegation der Elternzone passen, und eine, die einen Zonentransfer (AXFR) gegen jeden von ihnen versucht, um eine Offenlegung zu erkennen.

So erkennen Sie ihn

HTTP-Anfragen tragen diesen User-Agent:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36 (compatible; domainsecuritycheck.de/1.0; +https://domainsecuritycheck.de/scanner.html)

Das Chrome-Präfix sorgt dafür, dass Server so antworten wie gegenüber einem normalen Browser (die Ergebnisse spiegeln also wider, was echte Besucher bekommen); das (compatible; …)-Token identifiziert den Scanner ehrlich – nach derselben Konvention wie bei Googlebot oder Bingbot.

Alle Verbindungen (HTTP, TLS-Probes, SMTP) stammen von diesen Adressen:

Hinweis: TLS-Handshakes (Protokoll-/Cipher-Checks) und SMTP-STARTTLS-Probes tragen keinen User-Agent – dort sind Quell-IP und Reverse DNS die verlässlichen Erkennungsmerkmale.

Mail-Absender-Identität (Empfangs-Test)

Der Empfangs-Test stellt zusätzlich an die Mailserver einer Domain zu – nachdem diese Domain die Kontrolle nachgewiesen hat (durch eine authentifizierte Mail von ihr). Diese ausgehenden Nachrichten stammen von einem eigenen Adresspaar der Subdomain mail-test.domainsecuritycheck.de – bewusst getrennt von den obigen Scanner-IPs, damit die Mail-Reputation nie die Website-IP berührt:

Wir stellen nur an eine Domain zu, die gerade die Kontrolle bewiesen hat, und nur an genau die Adresse, die uns kontaktiert hat – nie an eine eingetippte Adresse. Um nie wieder eine Probe zu erhalten, das Opt-out in der Nachricht nutzen oder an abuse@mail-test.domainsecuritycheck.de mailen.

So blockieren Sie ihn

Wenn Ihre Domain hier nicht scannbar sein soll, blockieren Sie entweder das User-Agent-Token (HTTP-Checks) oder die Quell-IPs (alle Checks). Das Token domainsecuritycheck.de ist stabil und wird sich nicht ändern.

Per User-Agent

nginx:

if ($http_user_agent ~* "domainsecuritycheck\.de") {
    return 403;
}

Apache (.htaccess):

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} domainsecuritycheck\.de [NC]
RewriteRule ^ - [F]

Caddy:

@dsc header_regexp User-Agent (?i)domainsecuritycheck\.de
respond @dsc 403

Cloudflare / WAF: eine Custom Rule anlegen – User Agent contains domainsecuritycheck.de → Block.

Per IP-Adresse

# Linux (nftables)
nft add rule inet filter input ip saddr 159.195.68.98 drop
nft add rule inet filter input ip6 saddr 2a0a:4cc0:c2:23fb::1 drop

Was eine Blockierung ändert

• Eine User-Agent-Blockierung stoppt jede Prüfung, die über HTTP läuft: Security-Header, Redirect und Mixed Content – sowie die security.txt-Prüfung samt der dadurch ausgelösten PGP-Schlüssel-URL und Web-Key-Directory-Abfragen. Sie erreicht auch zwei Prüfungen auf der Mail-Seite, weil auch das HTTPS-Abrufe sind: Soweit Ihre Sperre den Policy-Host mta-sts.<domain> oder den Host Ihres BIMI-Logos erfasst, meldet der Bericht die Policy als nicht abrufbar, und das MTA-STS-Finding fällt von pass auf warn. Die TLS-Handshake-Proben, DNS und DNSSEC bleiben unberührt, ebenso der SMTP-Teil der Mail-Checks: Die verwenden weder HTTP noch einen User-Agent.
• Eine IP-Blockierung stoppt zusätzlich die TLS- und SMTP-Probes – und, auf Ihren autoritativen Nameservern angewandt, die beiden oben beschriebenen direkten Port-53-Prüfungen; diese melden dann, dass uns kein Nameserver geantwortet hat. Die übrigen DNS-/DNSSEC-/E-Mail-Authentifizierungsdaten werden über Drittanbieter-DoH-Resolver gelesen und lassen sich an Ihren Servern nicht blockieren.
• So oder so: Ein blockierter Scan verschlechtert typischerweise die angezeigte Note für alle, die Ihre Domain hier testen – Blockieren verbirgt Ihre Konfiguration, es verbessert sie nicht.