Kompromittierte Pakete in npm, PyPI und anderen Open-Source-Ökosystemen richten reale Schäden an – von Backdoors bis Ransomware. CVE-Monitoring kommt zu spät, und ob man selbst betroffen war, lässt sich oft gar nicht sagen. Ein Blick auf das Problem und wie sich der Blast Radius wenigstens nachvollziehen lässt.
TXT Verify Records sind der Standardmechanismus, um Domain-Besitz gegenüber Drittdiensten nachzuweisen. Dieser Artikel erklärt, wie die Verifikation technisch abläuft, wo sie eingesetzt wird und welche Risiken entstehen, wenn Tokens unkontrolliert im DNS landen.
Die meisten Teams wissen nicht genau, welche Domains sie besitzen, wo sie registriert sind und was darauf zeigt. Das ist kein Security-Problem – das ist ein Ordnungsproblem. Bis es keins mehr ist.
Du startest ein neues Projekt, registrierst eine Domain und willst es von Anfang an richtig machen. Hier ist eine pragmatische Checkliste für eine saubere DNS-Konfiguration – ohne Paranoia, mit Verstand.
SPF, DKIM und DMARC schützen deine Domain vor Mail-Spoofing. Aber sie sind nur so stark wie die DNS-Records, in denen sie definiert sind. Ändert sich ein Record, bricht die Vertrauenskette.
TLS-Zertifikate laufen aus. Automatische Erneuerung kann fehlschlagen. Und ein unbemerkt ausgestelltes Zertifikat kann bedeuten, dass jemand anderes deine Domain kontrolliert.
Der CAA Record legt fest, welche Zertifizierungsstellen TLS-Zertifikate für deine Domain ausstellen dürfen. Fehlt er, darf es jeder. Wird er manipuliert, verlierst du die Kontrolle über deine Verschlüsselung.
Der MX Record bestimmt, welcher Server deine E-Mails empfängt. Wird er manipuliert, landen Password-Resets, Verträge und 2FA-Codes beim Angreifer.
Der NS Record bestimmt, welche Nameserver für deine Domain zuständig sind. Wird er manipuliert, kann ein Angreifer jeden anderen Record frei definieren – ohne dass du es merkst.
Wir investieren in Firewalls, MFA und Verschlüsselung. Aber DNS und TLS – das Fundament, auf dem alles steht – überwachen wir oft nur per Zufall.