Drei Fälle, bei denen eine begründete Entscheidung zählt.

Eine unerwartete Anmeldung, ein zu offenes Gastnetz und verdächtige Dateiveränderungen verlangen unterschiedliche Antworten. In diesem Lernlab prüfst du konkrete defensive Maßnahmen. Es gibt keine Punkteliste und keinen Countdown. Entscheidend ist, weshalb eine Maßnahme unter den genannten Voraussetzungen geeignet, unvollständig oder riskant ist.

Jeder Fall enthält drei Entscheidungen. Wähle eine Option und lasse sie besprechen. Auch eine unvollständige oder riskante Auswahl erlaubt anschließend den nächsten Schritt: Sie dient als Erklärung, nicht als ausgeführte Änderung an einem echten System. Bei Rücknavigation bleibt deine Auswahl erhalten; änderst du sie, werden spätere Antworten verworfen. Neustart und Szenariowechsel beginnen ohne alte Antworten. Es werden weder Zugangsdaten abgefragt noch Antworten gespeichert.

Die Fälle sind fiktive, vereinfachte Lernsituationen. Eine Unternehmensrichtlinie, ein abgestimmter Notfallplan und die zuständigen Personen bleiben im wirklichen Betrieb maßgeblich. Das Lab ersetzt keine konkrete Einsatzentscheidung und nimmt selbst keine Anmeldung, Firewalländerung oder Wiederherstellung vor.

Deine Entscheidung im IT-Alltag.

Defensives Lernlab ohne echte Konten, Scans oder Konfigurationsänderungen. Antworten werden nur im Arbeitsspeicher gehalten. Jede Aufgabe beurteilt die angegebene Ausgangslage; gewählte Vorschläge werden nicht als echte Änderungen in spätere Aufgaben übernommen.

Ohne JavaScript kannst du alle Fälle, Entscheidungen und Erklärungen lesen. Die Lösungstexte sind zur Selbstkontrolle aufklappbar.

Verdächtige Anmeldung

Fiktiver Arbeitsalltag: Der echte Dienst liegt unter konto.example.org. Eine unerwartete Nachricht führt zu https://konto.example.org.hilfe.example/. Alle Domains sind Beispiele; es findet keine Anmeldung statt.

  1. Herkunft vor Anmeldung prüfen

    Eine Nachricht droht mit Kontosperrung. Die verlinkte Seite hat HTTPS und sieht vertraut aus. Welche erste Maßnahme ist geeignet?

    Nachricht nicht zur Anmeldung nutzen; den bekannten Dienst unabhängig öffnen und die Aufforderung verifizieren.

    Geeignet. Der Host endet auf hilfe.example, nicht auf example.org. Die bekannte Adresse oder ein bereits gespeicherter Einstieg verhindert, dass die Nachricht selbst den Vertrauensanker vorgibt. Bei Unsicherheit den bekannten Supportkanal verwenden.

    Mögliche Folge: Es werden weder Passwort noch Code an das unbekannte Ziel übergeben; ein Verdacht kann über den vorgesehenen Meldeweg geklärt werden.

    Nur nach dem HTTPS-Symbol schauen und ohne weitere Prüfung entscheiden.

    Unvollständig. Eine gültige TLS-Verbindung kann auch zu einer betrügerischen Domain bestehen. Das Symbol prüft nicht, ob du diesen Dienst überhaupt kontaktieren wolltest.

    Mögliche Folge: Die Herkunft bleibt ungeklärt. Die vollständige Adresse und der Anlass müssen unabhängig geprüft werden.

    Passwort und aktuellen TOTP-Code auf der verlinkten Seite eingeben.

    Riskant. Beide Eingaben können von einer täuschenden Gegenstelle abgefangen und zeitnah weitergereicht werden. Die kurze Gültigkeit des Codes bindet ihn nicht an die legitime Website.

    Mögliche Folge: Ein fremder Anmeldevorgang könnte erfolgreich abgeschlossen werden; keine echten Geheimnisse in solche Aufforderungen eingeben.

    HTTPS allein bestätigt weder die Seriosität einer Nachricht noch die Zugehörigkeit zum erwarteten Dienst.

  2. MFA-Verfahren unterscheiden

    Vergleiche manuell eingegebenes TOTP mit einer korrekt implementierten WebAuthn-Anmeldung am erwarteten Dienst. Was schützt gegen das Weiterreichen von Anmeldedaten?

    WebAuthn am unabhängig geöffneten richtigen Dienst nutzen und dessen Domainbindung erklären.

    Geeignet. Der Authenticator erzeugt einen passenden Nachweis für die Relying Party. Browser und Dienst prüfen unter anderem Origin, RP-ID und Challenge. Für die fremde Domain entsteht kein gültiger Nachweis des echten Dienstes.

    Mögliche Folge: Der typische Relay-Angriff einer gefälschten Loginseite wird erschwert. Kompromittierte Geräte, gestohlene Sitzungen oder schwache Recovery bleiben eigene Risiken.

    Passwort plus TOTP als Verbesserung nutzen, aber es mit Phishingresistenz gleichsetzen.

    Unvollständig. TOTP ergänzt einen Besitznachweis und ist gegenüber nur einem Passwort oft hilfreich. Der manuell übertragene Code kann jedoch weitergeleitet werden.

    Mögliche Folge: Ein Teil des Risikos sinkt; die hier betrachtete falsche Anmeldeseite wird dadurch nicht zuverlässig ausgeschlossen.

    Eine unaufgeforderte Push-Anmeldung bestätigen, damit die Hinweise aufhören.

    Riskant. Eine unerwartete Bestätigung kann einen fremd ausgelösten Zugriff autorisieren. Druck oder Wiederholung sind kein verlässlicher Nachweis einer eigenen Anfrage.

    Mögliche Folge: Ein unerwünschter Zugang könnte freigegeben werden. Aufforderung ablehnen und unabhängig melden.

    Phishingresistenz verlangt eine kryptografische Bindung an den richtigen Dienst; zwei Faktoren allein garantieren sie nicht.

  3. Nach Verdacht und für später vorsorgen

    Es ist unklar, ob bereits Zugangsdaten offengelegt wurden. Welche Kombination ist angemessen?

    Verdacht melden; über vertrauenswürdigen Weg betroffene Zugänge und Sitzungen prüfen sowie abgesicherte Recovery vorbereiten.

    Geeignet. Mit dem zuständigen Team klären, welche Konten, Authentifikatoren oder Sitzungen betroffen sein können. Einzigartige Passwörter, passende Widerrufe und Ersatzauthentifikatoren gehören in einen abgestimmten Ablauf.

    Mögliche Folge: Die Reaktion beschränkt sich nicht auf ein neues Passwort. Wiederzugang und Schutz eines synchronisierenden Kontos werden mitbetrachtet.

    Nur das Passwort ändern und alle bestehenden Sitzungen und Recoverywege ungeprüft lassen.

    Unvollständig. Ein neues Passwort beendet je nach Dienst nicht jede aktive Sitzung. Andere betroffene Geheimnisse und Wiederherstellungswege können weiterhin relevant sein.

    Mögliche Folge: Die Maßnahme kann helfen, lässt aber mögliche Zugänge offen; deren Prüfung muss ergänzt werden.

    Recoverycodes zusammen mit Passwort und TOTP im Supportchat der Nachricht schicken.

    Riskant. Ein Chat aus derselben verdächtigen Nachricht ist kein unabhängig verifizierter Kontakt. Recoverycodes sind ebenfalls schützenswerte Zugangsmittel.

    Mögliche Folge: Weitere Zugangsmöglichkeiten könnten offengelegt werden. Keine echten Codes in unbekannte Kommunikationswege geben.

    Kontoschutz umfasst auch Recovery, Sitzungen und einen bekannten Ansprechpartner.

Gastnetz und Firewall

Lehrmodell mit getrennten Zonen Gast, Büro und Server sowie IPv4 und IPv6. Verkehr zwischen den Zonen wird geroutet und gefiltert. DNS und Webzugang sind die ausdrücklich vorgesehenen Dienste, kein beliebiger Vollzugriff.

  1. Ein begrenztes Regelwerk wählen

    Ein Gast soll Websites erreichen, aber nicht den internen Dateiserver. Welche Grundregel passt?

    Nur benötigte DNS-/Webwege freigeben, Gastzugriffe auf interne Dienste sperren und Default Deny für übrige neue Verbindungen setzen.

    Geeignet. Im festgelegten First-Match-Modell werden Ausnahmen bewusst vor allgemeineren Sperren eingeordnet. Ein freigegebener Resolver darf als eng begrenzte Ausnahme erreichbar sein; Dateidienste bleiben gesperrt. IPv6 wird entsprechend berücksichtigt.

    Mögliche Folge: Der gewünschte Dienst wird ermöglicht, ohne eine pauschale Gast-zu-intern-Freigabe einzuführen. Lokale Infrastruktur- und Kontrollnachrichten brauchen ebenfalls passende Regeln.

    Nur eine IPv4-Regel gegen den internen Dateiserver anlegen und IPv6 offenlassen.

    Unvollständig. Eine zweite Adressfamilie kann einen anderen Weg zum gleichen Dienst eröffnen. Eine einzelne Hostsperre ersetzt außerdem keine vollständige Zonenrichtlinie.

    Mögliche Folge: Die beabsichtigte Trennung ist nicht für beide Familien nachgewiesen; IPv6 und weitere interne Ziele müssen einbezogen werden.

    Gast zu allen internen Netzen erlauben, damit keine Supportfälle entstehen.

    Riskant. Eine breite Freigabe macht interne Dienste unnötig aus dem Gastnetz erreichbar. Ein VLAN allein hebt diese Erlaubnis nicht wieder auf.

    Mögliche Folge: Der Dateiserver und weitere Dienste könnten erreichbar werden; die vorgegebene Sicherheitsgrenze wäre aufgehoben.

    Richtung, Quelle, Ziel, Dienst und beide IP-Familien gehören zur Freigabe; eine letzte Standardrichtlinie schließt Lücken.

  2. Antwortverkehr einordnen

    Ein erlaubter Client hat eine TCP-Webverbindung aufgebaut. Wie werden Antworten im zustandsbehafteten Lehrmodell behandelt?

    Nur zum erlaubten Zustand passende Antworten nach vorgesehener Zustandsprüfung zulassen.

    Geeignet. Die Firewall ordnet das Rückpaket einer bestehenden erlaubten Kommunikation zu. Für UDP sind zeitbegrenzte Zuordnungen möglich, obwohl UDP selbst keinen Verbindungsaufbau besitzt.

    Mögliche Folge: Es braucht keine pauschale spiegelbildliche Freigabe für neue Zugriffe aus dem Internet. Zeitüberschreitungen und asymmetrische Wege können dennoch Probleme verursachen.

    Alle Pakete mit Quellport 443 als sichere Antworten behandeln.

    Unvollständig. Eine Portnummer allein belegt keine Zugehörigkeit zu einer erlaubten Verbindung. Die Zuordnung benötigt mehr Informationen als einen einzelnen Port.

    Mögliche Folge: Die Prüfung bleibt unzureichend; Zustand, Richtung und Endpunkte müssen passend bewertet werden.

    Alle neuen Internetverbindungen in das Gast- und Servernetz freigeben.

    Riskant. Damit würde die Regel weit über den Rückverkehr der erlaubten Webverbindung hinausgehen. Die Firewall könnte neue unerwünschte Initiierungen zulassen.

    Mögliche Folge: Die Einschränkung auf Antworten ginge verloren. Stateful-Zuordnung rechtfertigt keine solche breite Freigabe.

    Eine passende Zustandszuordnung ist von der Erlaubnis für beliebige neue Verbindungen zu unterscheiden.

  3. Kontrollnachrichten sinnvoll begrenzen

    Nach einer Änderung funktionieren manche IPv6-Verbindungen nicht mehr. Jemand schlägt vor, jedes ICMPv6-Paket zu verwerfen. Wie gehst du vor?

    Erforderliche ICMPv6-Funktionen nach Typ, Richtung und Linkbereich zulassen und anhand des Regelwerks prüfen.

    Geeignet. Neighbor Discovery wirkt auf dem lokalen Link; Packet Too Big unterstützt die Pfad-MTU-Ermittlung. Routeranzeigen müssen aus dem vorgesehenen vertrauenswürdigen Kontext kommen. Das ist keine Erlaubnis für beliebige Nachrichten überall.

    Mögliche Folge: Reguläre IPv6-Funktionen bleiben möglich, während unnötiger Verkehr begrenzt wird. Logs und konkrete Tests gehören in eine isolierte Freigabeprüfung.

    Nur Echo Request und Echo Reply zulassen und damit IPv6 als vollständig geprüft ansehen.

    Unvollständig. Ein Ping kann funktionieren, während andere notwendige Kontrollmeldungen fehlen. Große Datenübertragungen oder die Nachbarauflösung hängen nicht allein von Echo ab.

    Mögliche Folge: Ein Teiltest reicht nicht aus; notwendige Typen und ihre Reichweite müssen gezielt betrachtet werden.

    ICMPv6 vollständig blockieren, weil es keine Anwendungsdaten enthält.

    Riskant. Kontrollnachrichten sind Teil des regulären IPv6-Betriebs. Ihre pauschale Sperre kann Nachbarauflösung und Fehlerbehandlung beeinträchtigen.

    Mögliche Folge: Scheinbar zufällige Verbindungsfehler können entstehen; das vorgegebene Netzwerk wäre nicht zuverlässig funktionsfähig.

    IPv6 benötigt bestimmte Kontrollfunktionen; differenzierte Freigaben ersetzen pauschales Blockieren oder Öffnen.

Daten verschlüsselt, Betrieb gestört

Fiktiver Betrieb mit Dateiserver und gesonderten Backupzugängen. Um 10:30 werden verdächtige Dateiveränderungen entdeckt, Hinweise reichen bis 10:00 zurück. Keine echten Dateien, Malware oder Systeme werden verwendet.

  1. Zuerst Ausbreitung begrenzen

    Mehrere Dateien sind unerwartet verschlüsselt. Welche erste Reaktion ist geeignet?

    Betroffene Systeme koordiniert vom Netz isolieren, den Vorfall melden und Beobachtungen sichern lassen.

    Geeignet. Den vorgesehenen Notfallweg und einen unabhängigen Kommunikationskanal nutzen. Das verantwortliche Team bewertet Umfang, betroffene Zugänge und Sicherung flüchtiger Belege. Nicht vorschnell neu installieren.

    Mögliche Folge: Weiterverbreitung wird begrenzt und die Untersuchung vorbereitet. Abschalten ist eine situationsabhängige Notmaßnahme, etwa wenn Netzwerkisolation nicht möglich ist, keine pauschale Standardaktion.

    Nur die Fehlermeldung notieren und auf einen späteren Wartungstermin warten.

    Unvollständig. Dokumentieren ist hilfreich, aber eine laufende Ausbreitung oder ein aktiver fremder Zugang kann dadurch ungebremst bleiben.

    Mögliche Folge: Die Reaktion ist zu langsam; koordinierte Eindämmung und Meldung müssen zeitnah ergänzt werden.

    Die Offline-Backupplatte sofort an den verdächtigen Server anschließen und direkt zurückkopieren.

    Riskant. Damit würde eine bisher unabhängige Kopie dem möglicherweise kompromittierten System ausgesetzt. Eine bloße Rückkopie beseitigt die Ursache oder fremde Zugänge nicht.

    Mögliche Folge: Auch die Sicherung könnte gefährdet und ein sauberer Wiederanlauf verhindert werden. Wiederherstellung separat vorbereiten.

    Eindämmung, koordinierte Kommunikation und Beweiserhalt gehören zusammen; keine ungeprüfte Wiederinbetriebnahme.

  2. Eine geeignete Sicherung auswählen

    Kandidaten: getrennte Offlinekopie von 08:00 mit Restore-Nachweis; ständig erreichbare Kopie von 10:15; Snapshot von 10:20 im selben Administrationskonto. Das vereinbarte RPO beträgt eine Stunde.

    Die getrennte 08:00-Kopie als Kandidat unabhängig validieren und die mögliche RPO-Überschreitung offen benennen.

    Geeignet. Die Kopie ist durch ihre Trennung plausibler geschützt, muss aber noch auf Eignung und Konsistenz geprüft werden. Bis zur Erkennung um 10:30 liegen 150 Minuten; das Beispiel erfüllt das Ein-Stunden-Ziel damit nicht automatisch.

    Mögliche Folge: Die Auswahl wird fachlich begründet und der mögliche Datenverlust transparent. Gegebenenfalls sind weitere geeignete Transaktionsstände oder Kopien zu prüfen.

    Die 10:15-Kopie allein wegen des jüngsten Zeitstempels bevorzugen.

    Unvollständig. Die Kopie entstand nach den ersten bekannten Hinweisen und war erreichbar. Ihre Unversehrtheit und ihr Inhalt sind unklar; sie ist nicht ohne weitere Prüfung ausgeschlossen, aber auch nicht nachgewiesen geeignet.

    Mögliche Folge: Eine zusätzliche unabhängige Validierung ist nötig. Ein grüner Backupjob ersetzt diese Prüfung nicht.

    Den Snapshot im selben kompromittierbaren Konto als garantiert unabhängige und saubere Sicherung behandeln.

    Riskant. Ein Snapshot kann nützlich sein, teilt hier aber wichtige Zugangs- und Ausfallrisiken. Sein Zeitpunkt liegt zudem nach den bekannten Hinweisen.

    Mögliche Folge: Die behauptete Garantie wäre unbegründet. Zugangstrennung, Aufbewahrung und validierte saubere Datenstände müssen nachgewiesen werden.

    Neuester Zeitstempel und erfolgreicher Job allein belegen keine unveränderte, saubere Wiederherstellungsbasis.

  3. Den Betrieb kontrolliert wieder aufnehmen

    Die gewählte Kopie wurde als geeignet bewertet. Ein frischer Restore benötigt im Beispiel 40 Minuten. Dürfen Nutzer danach sofort wieder arbeiten?

    In bereinigter Umgebung wiederherstellen, Abhängigkeiten und Zugänge prüfen und den Dienst nach fachlichen Tests freigeben lassen.

    Geeignet. Beispielplanung: 20 Minuten Vorbereitung, 40 Restore, 35 technische/fachliche Prüfung und 25 kontrollierte Freigabe ergeben 120 Minuten. Datenkonsistenz, Rechte, Schlüssel, Patchstand und Beobachtung nach Wiederanlauf werden berücksichtigt.

    Mögliche Folge: Unter diesen ausdrücklich vereinfachten Annahmen liegt der Plan unter einem RTO von 180 Minuten. Das ist keine Laufzeitgarantie und beendet die Ursachenanalyse nicht.

    Nur den Dateihash vergleichen und daraus einen betriebsbereiten Dienst ableiten.

    Unvollständig. Ein Hashvergleich kann Bytegleichheit mit einer Referenz zeigen. Er beweist weder eine malwarefreie Referenz noch funktionierende Anwendung, Konten und Abhängigkeiten.

    Mögliche Folge: Integritätsprüfung ist nur ein Baustein. Der fachliche Restore-Test und die Freigabe fehlen weiterhin.

    Den alten verdächtigen Server unverändert verbinden, weil die Dateien nun wieder lesbar sind.

    Riskant. Lesbare Dateien belegen nicht, dass der initiale Zugang, eine Hintertür oder kompromittierte Berechtigungen entfernt wurden.

    Mögliche Folge: Saubere Systeme und Daten könnten erneut gefährdet werden. Bereinigung und kontrollierte Prüfung gehen vor Wiederanschluss.

    RTO umfasst den nutzbaren Dienst und seine Abhängigkeiten; Restorezeit allein genügt nicht.

Die technische Grundlage hinter der Auswahl.

Quellen und fachlicher Stand.

Geprüft am . Eigene Lehrfälle, keine Ergebnisse echter Vorfälle. Die Bewertungen gelten für die jeweils ausdrücklich beschriebene Ausgangslage.

  • NIST SP 800-63B-4, finale Fassung: Authentifikatoren, Phishingresistenz, Ereignis- und Sitzungsverwaltung sowie synchronisierbare Authentifikatoren.
  • W3C WebAuthn Level 3: RP-ID, Origin und Prüfung kryptografischer Anmeldenachweise.
  • BSI IT-Grundschutz-Kompendium: NET.3.2 Firewall und CON.3 Datensicherungskonzept, Editions-/Abrufgrenzen in den Quellenmaps der verlinkten Fachartikel.
  • CISA #StopRansomware Guide: Eindämmung, unabhängige Backups und kontrollierte Wiederherstellung. Organisations- und Rechtsvorgaben müssen im konkreten Einsatz gesondert geprüft werden.