Ein kostenloser Sicherheitsscanner, der genau offenlegt, was er geprüft hat
Secure Your Server führt zwei unabhängige Prüfungen gegen Infrastruktur durch, die dir gehört: einen Domain-Sicherheitsscan und einen Mail-Zustellungstest. Beide sind dauerhaft kostenlos, ohne Konto, ohne Bezahlschranke und ohne Tracking. Diese Seite erklärt, was das Projekt ist, warum es existiert, und listet jeden einzelnen Check auf, den es durchführt. Nichts davon bleibt geheim.
Für immer kostenlos, kein KontoKein Tracking, keine Cookies von DrittenVollständige Checkliste weiter unten
Die meisten Werkzeuge, die TLS-Konfiguration, Mail-Authentifizierung, HTTP-Header oder offene Ports prüfen, sind auf ein Dutzend einzelne Dienste verteilt. Viele davon sind kommerziell, rate-limitiert oder verlangen ein Konto, bevor sie ein vollständiges Ergebnis zeigen. Secure Your Server bündelt genau die Checks, die vor einem Audit, einer Kundenübergabe oder der Frage „warum landet diese Mail eigentlich im Spam" tatsächlich gebraucht werden, an einem Ort. Mit einer Note je Kategorie, und sobald der Besitz der Zieldomain nachgewiesen ist, jedem Einzelbefund samt konkreter Behebungsanleitung statt eines vagen Bestanden-oder-nicht.
So läuft ein Scan ab
1
Domain eingeben
Trage eine Domain ein, die dir gehört. Bloße IP-Adressen und E-Mail-Adressen lassen sich nicht scannen; der Besitznachweis funktioniert ausschließlich für Domains.
2
Besitz nachweisen, bevor überhaupt etwas läuft
Ein Scan startet nur mit vorherigem Besitznachweis (DNS-TXT-Record oder well-known-Datei). Ohne den läuft kein Scan, und es wird nichts gespeichert, nicht mal eine Note.
3
Acht Checks laufen, der volle Bericht gehört dir
DNS, E-Mail-Authentifizierung, TLS/SSL, SSH, Ports, HTTP-Security-Header, WHOIS und PGP/WKD laufen, und du bekommst sofort jeden Einzelbefund samt Behebungsanleitung, 365 Tage lang gültig. Wer diese Domain später auf der öffentlichen Bestenliste findet, ohne sie selbst verifiziert zu haben, sieht ausschließlich die Kategorienoten.
Domain-Sicherheitsscan: jeder Check im Detail
Acht Kategorien, jede einzeln bewertet und zu einer Gesamtnote zusammengeführt. Nichts davon ist geraten: Jeder Befund verlinkt im Bericht selbst auf das RFC, die Herstellerempfehlung oder die CVE, auf der er beruht.
◈
DNS
Auflösung, Redundanz und Zonen-Hygiene, inklusive eines echten Zonentransfer-Versuchs.
A/AAAA-Auflösung und IPv6-Erreichbarkeit (AAAA)
Anzahl und Redundanz der Nameserver (RFC 2182 empfiehlt mindestens zwei)
DNSSEC-Vorhandensein
CAA-Records: welche Zertifizierungsstellen für die Domain ausstellen dürfen, und ob eine iodef-Meldeadresse gesetzt ist
Plausibilität der SOA-Zeitwerte (Refresh/Retry/Expire)
Ein tatsächlicher AXFR-Zonentransfer-Versuch gegen jeden autoritativen Nameserver, mit Warnung, sobald einer davon die komplette Zone unauthentifiziert herausgibt
Wildcard-DNS-Erkennung, die auch andere Checks (etwa die DKIM-Selector-Suche) vor Fehlalarmen schützt
Ob sich ausgehende Mail deiner Domain fälschen lässt, und ob sie im Spam landet.
SPF-Record: Vorhandensein, Syntax, das 10-Lookup-DNS-Limit, und ob er mit einem harten Fail (-all) oder einem schwächeren Soft-Fail (~all) endet
DKIM-Schlüsselsuche über gängige Selektoren
DMARC-Record: Vorhandensein, Richtlinienstärke (none/quarantine/reject), Alignment-Modus und aggregiertes Reporting (rua)
Erreichbarkeit der MTA-STS-Policy (rein informativ, ohne Punktabzug)
Die Mailserver-IPs, geprüft gegen vier öffentliche DNSBLs (Spam-Blacklists), die im echten Mailfiltering genutzt werden
◐
TLS/SSL
Vollständige Protokoll-, Cipher- und Zertifikatsanalyse via testssl.sh, nicht nur ein Ja/Nein zu HTTPS.
Jede Protokollversion von SSLv2 bis TLS 1.3: welche angeboten werden, welche abgeschaltet gehören
Die vollständige Cipher-Suiten-Liste je Protokoll, schwächste zuerst, mit testssls eigener OK/LOW/MEDIUM/HIGH-Bewertung je Suite
Schlüsselaustausch und Forward Secrecy
Zertifikatsdetails: Common Name, alternative Namen (SAN), Gültigkeitszeitraum, Schlüsselgröße, Signaturalgorithmus, Aussteller, Vertrauenskette, und eine realistische Ablaufwarnung (erst ab ≤7 Tagen dringend, denn ein 90-Tage-Let’s-Encrypt-Zertifikat, das an Tag 40 erneuert wird, ist völlig normal)
Simulierte Client-Kompatibilität (welche Browser/Clients sich überhaupt verbinden können)
Ein Certificate-Transparency-Log-Abgleich (crt.sh) mit kürzlich ausgestellten Zertifikaten für die Domain, rein informativ
▣
SSH
Vollständiges ssh-audit des Server-Banners und jedes angebotenen Algorithmus.
Server-Banner und Softwareversion
Jeder angebotene Schlüsselaustausch-, Host-Key-, Verschlüsselungs- und MAC-Algorithmus, einzeln bewertet
Bekannte CVEs, abgeglichen mit der erkannten SSH-Softwareversion, verlinkt auf den jeweiligen NVD-Eintrag
Abgleich gegen Mozillas aktuelle OpenSSH-Härtungsrichtlinien
▤
Ports & Firewall
Was aus dem offenen Internet erreichbar ist, mit dienstspezifischen Härtungstipps.
Die 20 gängigsten Ports werden für alle geprüft; ein vollständiger Top-1000-Scan mit Dienst- und Versionserkennung schaltet sich nach Verifizierung frei
Über zwei Dutzend Ports gelten bei Offenheit als Risikosignal (Datenbanken, Cache-Server, Management-Interfaces, Legacy-Protokolle wie Telnet und FTP), jeweils mit eigenem konkretem ersten Handgriff statt eines pauschalen „Firewall zu"
Warnung, wenn ungewöhnlich viele Ports gleichzeitig offen sind
◫
HTTP-Security-Header
Jeder Header, den ein moderner Browser versteht, plus die etablierten Discovery-Dateien.
HTTPS-Erzwingung und automatische Weiterleitung von HTTP auf HTTPS (folgt bis zu 10 Redirect-Hops, meldet die tatsächlich geprüfte Zieladresse)
Content-Security-Policy, inklusive Erkennung von unsafe-inline/unsafe-eval und Wildcard-script-src
HSTS: Vorhandensein, Länge der max-age, includeSubDomains- und preload-Direktive
Wertprüfung (nicht nur Vorhandensein) bei X-Content-Type-Options, X-Frame-Options, Referrer-Policy
CORS-Wildcard in Kombination mit Cookies, die Zugangsdaten übertragen
security.txt nach RFC 9116, mit echter Feld- und Ablaufdatum-Validierung statt reinem Vorhanden-Sein
llms.txt, robots.txt und humans.txt als reine Info-Checks ohne Punktabzug in beide Richtungen, da keine davon ein etablierter Standard ist
Alle Header-Checks werden mit einer neutralen „nicht anwendbar"-Note übersprungen, nie als Fehlschlag gewertet, wenn ein Ziel gar keinen Webserver auf Port 80/443 hat
◔
WHOIS
Registrierungsstatus und das betriebliche Risiko einer ablaufenden Domain.
Ablaufdatum der Domain, mit eskalierenden Warnungen bei Annäherung
Registry-Statuscodes: Sperrzustände der Registrierung und fehlende Transfer-/Update-Sperren
Anzahl der Nameserver laut Registry-Eintrag
✦
PGP / WKD
Ob verschlüsselte Mail an diese Domain realistisch möglich ist.
Öffentlicher-Schlüssel-Suche über Web Key Directory (WKD) und Keyserver
Schlüssellänge und Alter
Ablauf- und Widerrufsstatus
Wie die Noten zustande kommen
Jede Kategorie bekommt einen eigenen Score von 0 bis 100, abgebildet auf eine Buchstabennote (A+ ab 97, absteigend bis F unter 50), im selben Notenschema wie bei bekannten SSL-Testwerkzeugen. Die Gesamtnote ist ein einfacher Durchschnitt aller tatsächlich abgeschlossenen Kategorien. Kategorien, die für ein Ziel nicht zutreffen (etwa Header-Checks bei einer Domain ohne Webserver), fließen gar nicht erst ein, statt als Fehlschlag gewertet zu werden, damit sie eine ansonsten solide Domain nicht künstlich nach unten ziehen.
Mail-Zustellungstest: was geprüft wird
Ein eigenständiges Werkzeug neben dem Domain-Scan, denn die DNS-Records einer Domain erzählen nur die halbe Geschichte. Dieser Test schaut sich eine echte Nachricht so an, wie sie tatsächlich ankommt.
Eine temporäre, einmalige Empfangsadresse, 15 Minuten gültig und genau einmal nutzbar
SPF-, DKIM- und DMARC-Authentifizierungsergebnisse, ausgewertet an der tatsächlich empfangenen Nachricht, nicht nur isoliert an den DNS-Records
Die TLS-Verbindung, über die der versendende Server zugestellt hat
Reverse-DNS (rDNS/PTR) des versendenden Mailservers
Spam-relevante Signale aus der Nachricht selbst
Die vollständigen rohen E-Mail-Header, ausschließlich dir zugänglich über einen privaten Einmal-Link
Datenschutz von Grund auf
Kein Konto, kein Login und keine Tracking-Skripte irgendwo auf der Seite
Genau ein einziges Cookie existiert im gesamten Dienst, gesetzt nur nach einer Domain-Verifizierung, vollständig beschrieben im Cookie-Hinweis
Einzelbefunde zu einer Domain sieht ausschließlich, wer deren Besitz nachgewiesen hat; alle anderen sehen immer nur die Noten
Das Testpostfach des Mail-Zustellungstests wird direkt nach Verarbeitung jeder Nachricht geleert, plus einem zusätzlichen 24-Stunden-Sicherheits-Sweep
Jede eigene Domain lässt sich komplett von der öffentlichen Bestenliste ausschließen
Gebaut von chrislo.de
Entstanden bei chrislo.de, Studio für freie Technik
Secure Your Server wird von chrislo.de betrieben, Christin Löhners Studio für freie Technik, digitale Souveränität und IT-Sicherheit. Dieselbe Haltung, die dieses Studio trägt, steckt auch in diesem Werkzeug: Sicherheits-Tooling, das etwas taugt, gehört nicht hinter eine Bezahlschranke, eine Kontopflicht oder eine Herstellerbindung. Jede*r sollte die eigene Infrastruktur kostenlos prüfen können, genau nachvollziehen, was dabei getestet wurde, und echte, umsetzbare Hinweise bekommen statt einer Marketing-Ampel.
Diese Seite nutzt genau ein Cookie, und das nur, wenn du eine Domain verifizierst. Details unten.
Cookie-Hinweis
Dieser Dienst nutzt genau ein Cookie, unten beschrieben. Keine Cookies von Dritten, kein Tracking, keine Werbung. Niemals.
Domain-Verifizierungs-CookieEssenziell
Wird nur gesetzt, nachdem du erfolgreich den Besitz einer Domain nachweist (DNS-TXT-Record oder well-known-Datei), um deren vollständigen Bericht freizuschalten. Cookie-Name: sys_owner_<domain>. HttpOnly (per Skript nicht auslesbar), Secure, SameSite=Lax, wird ausschließlich an diese Seite gesendet. Zweck: belegt bei späteren Besuchen, dass du diejenige Person bist, die genau diese Domain verifiziert hat, damit nur du (und nicht irgendjemand, der die Domain über die öffentliche Bestenliste findet) den vollständigen Bericht mit Einzelbefunden und Behebungsanleitungen siehst. Keine Nutzung für Tracking oder Analyse, keine Weitergabe an Dritte. Läuft nach 365 Tagen ab, passend zur Gültigkeit der Verifizierung selbst. Dieses Cookie ist für die Verifizierungsfunktion essenziell und wird ausschließlich gesetzt, wenn du sie aktiv nutzt. Es wird nie bei einem normalen Besuch gesetzt.
