AP5 FinalProtocol AP2-Ausbau: 10 Themen / 200 Fragen (FISI + FIAE)
Je Fachrichtung 5 neue Themen a 20 Fragen, nach dem bestehenden Skelett
(Lernfokus + Inhaltssektionen + Pruefungsmodus, data-questions-src) und JSON-
Schema {title, questions:[{category,hint,text,answers[3],correct,explanation}]}:
- FISI: netzwerkplanung, it-sicherheit, virtualisierung, monitoring-backup,
skripting.
- FIAE: sql, uml, oop, algorithmen, testverfahren.
Jede Datei: 20 Fragen, 5 Kategorien a 4, correct ausgewogen rotierend (7/7/6),
Erklaerungen benennen die Distraktoren-Fallen, "du"-Ansprache, echte Umlaute
(UTF-8). Navigation in finalflux.html um je 5 Links erweitert (Bestand bleibt).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WFxcjtc9HNP4VECT6Ur1tE
This commit is contained in:
AliceDarkest
@@ -0,0 +1,245 @@
|
||||
{
|
||||
"title": "IT-Sicherheit",
|
||||
"questions": [
|
||||
{
|
||||
"category": "Firewall & DMZ",
|
||||
"hint": "Verbindungszustand merken oder nicht.",
|
||||
"text": "Worin unterscheidet sich eine Stateful-Inspection-Firewall von einem einfachen Paketfilter?",
|
||||
"answers": [
|
||||
"Sie verfolgt den Verbindungszustand und lässt Antwortpakete zu bereits aufgebauten Verbindungen automatisch zu.",
|
||||
"Sie prüft ausschließlich einzelne Pakete ohne Bezug zueinander anhand starrer Regeln.",
|
||||
"Sie arbeitet nur auf der Anwendungsschicht und ersetzt jede Verbindung durch eine eigene Sitzung."
|
||||
],
|
||||
"correct": 0,
|
||||
"explanation": "Stateful Inspection führt eine Zustandstabelle und erkennt, welche Pakete zu einer bestehenden Verbindung gehören – Rückantworten müssen nicht einzeln freigegeben werden. Die reine Einzelpaketprüfung ohne Kontext beschreibt gerade den zustandslosen Paketfilter, und das vollständige Ersetzen jeder Verbindung ist Aufgabe eines Proxys bzw. Application-Gateways."
|
||||
},
|
||||
{
|
||||
"category": "Firewall & DMZ",
|
||||
"hint": "Wo steht ein öffentlich erreichbarer Server sicher?",
|
||||
"text": "Ein aus dem Internet erreichbarer Webserver soll ins Firmennetz integriert werden. Wie platzierst du ihn sicher?",
|
||||
"answers": [
|
||||
"Direkt im internen LAN, damit er bequem auf die interne Datenbank zugreifen kann.",
|
||||
"In einer DMZ, die per Firewall sowohl vom Internet als auch vom internen LAN getrennt ist.",
|
||||
"Ohne Firewall direkt am Internet-Router, damit die Erreichbarkeit garantiert bleibt."
|
||||
],
|
||||
"correct": 1,
|
||||
"explanation": "Eine DMZ isoliert öffentlich erreichbare Dienste, sodass ein kompromittierter Server nicht unmittelbar das interne Netz öffnet. Im internen LAN säße ein gekaperter Server sofort im vertrauenswürdigen Bereich, und ohne Firewall wäre er völlig ungeschützt exponiert."
|
||||
},
|
||||
{
|
||||
"category": "Firewall & DMZ",
|
||||
"hint": "Zwei Firewalls bilden einen Zwischenbereich.",
|
||||
"text": "Was beschreibt das Konzept eines Screened Subnet (DMZ mit zwei Firewalls)?",
|
||||
"answers": [
|
||||
"Eine einzelne Firewall mit drei Schnittstellen für LAN, WAN und DMZ.",
|
||||
"Zwei baugleiche Firewalls hintereinander, die nur der Lastverteilung dienen.",
|
||||
"Eine äußere und eine innere Firewall, zwischen denen die DMZ liegt, sodass ein Angreifer beide überwinden muss."
|
||||
],
|
||||
"correct": 2,
|
||||
"explanation": "Beim Screened Subnet spannen eine äußere und eine innere Firewall (idealerweise verschiedener Hersteller) die DMZ dazwischen auf – der Weg ins LAN führt nur durch beide. Die einzelne Firewall mit drei Schnittstellen ist die kollabierte Ein-Firewall-Variante, und Lastverteilung ist nicht der Zweck dieses Sicherheitskonzepts."
|
||||
},
|
||||
{
|
||||
"category": "Firewall & DMZ",
|
||||
"hint": "Was ist nicht erlaubt, ist verboten.",
|
||||
"text": "Nach welchem Grundprinzip sollte ein Firewall-Regelwerk aufgebaut sein?",
|
||||
"answers": [
|
||||
"Default-Allow: grundsätzlich alles erlauben und nur bekannte Angriffe gezielt blockieren.",
|
||||
"Default-Deny: grundsätzlich alles verbieten und nur den explizit benötigten Verkehr freigeben.",
|
||||
"Die Reihenfolge der Regeln ist egal, weil die Firewall stets die am wenigsten restriktive Regel anwendet."
|
||||
],
|
||||
"correct": 1,
|
||||
"explanation": "Default-Deny (Whitelist) lässt nur ausdrücklich freigegebenen Verkehr durch und hält die Angriffsfläche minimal. Default-Allow lässt unbekannten Verkehr offen, und die Reihenfolge ist keineswegs egal – die meisten Firewalls wenden die erste passende Regel an."
|
||||
},
|
||||
{
|
||||
"category": "VPN",
|
||||
"hint": "Welcher IPsec-Teil verschlüsselt die Nutzdaten?",
|
||||
"text": "Welcher Bestandteil von IPsec sorgt durch Verschlüsselung der Nutzdaten für Vertraulichkeit?",
|
||||
"answers": [
|
||||
"ESP (Encapsulating Security Payload).",
|
||||
"AH (Authentication Header).",
|
||||
"IKE (Internet Key Exchange)."
|
||||
],
|
||||
"correct": 0,
|
||||
"explanation": "ESP verschlüsselt die Nutzdaten und liefert damit Vertraulichkeit, optional zusätzlich Integrität und Authentizität. AH schützt nur Integrität und Herkunft, verschlüsselt aber nichts, und IKE handelt lediglich die Schlüssel aus, ohne den eigentlichen Datenverkehr zu verschlüsseln."
|
||||
},
|
||||
{
|
||||
"category": "VPN",
|
||||
"hint": "Ganzes Paket kapseln oder nur Nutzlast schützen?",
|
||||
"text": "Ein Site-to-Site-VPN zwischen zwei Standorten soll die kompletten Original-IP-Pakete schützen und verbergen. Welcher IPsec-Modus ist dafür vorgesehen?",
|
||||
"answers": [
|
||||
"Der Transportmodus, weil er den ursprünglichen IP-Header unverändert lässt.",
|
||||
"Der Transportmodus in Verbindung mit zusätzlichem NAT.",
|
||||
"Der Tunnelmodus, der das gesamte Original-Paket verschlüsselt und in ein neues IP-Paket kapselt."
|
||||
],
|
||||
"correct": 2,
|
||||
"explanation": "Der Tunnelmodus kapselt das vollständige Originalpaket samt Header in ein neues IP-Paket – Standard für die Kopplung ganzer Standorte über Gateways. Der Transportmodus lässt den ursprünglichen IP-Header sichtbar und schützt nur die Nutzlast, was eher für direkte Host-zu-Host-Verbindungen gedacht ist; NAT ändert daran nichts."
|
||||
},
|
||||
{
|
||||
"category": "VPN",
|
||||
"hint": "Zugriff nur über den Browser.",
|
||||
"text": "Ein Außendienstmitarbeiter soll ohne installierten VPN-Client nur per Browser auf einzelne Webanwendungen zugreifen. Welche VPN-Variante passt am besten?",
|
||||
"answers": [
|
||||
"IPsec im Tunnelmodus mit vollständigem Zugriff auf das gesamte Firmennetz.",
|
||||
"Ein clientloses SSL/TLS-VPN, das den Zugriff über HTTPS direkt im Browser ermöglicht.",
|
||||
"Ein PPTP-VPN, weil es besonders starke Verschlüsselung bietet."
|
||||
],
|
||||
"correct": 1,
|
||||
"explanation": "Clientlose SSL/TLS-VPNs laufen über HTTPS im Browser und eignen sich ideal für den gezielten Zugriff auf einzelne Webanwendungen ohne Softwareinstallation. IPsec benötigt einen Client und öffnet gleich das ganze Netz, und PPTP gilt als veraltet und kryptografisch gebrochen – keineswegs besonders stark."
|
||||
},
|
||||
{
|
||||
"category": "VPN",
|
||||
"hint": "Alte Aufzeichnungen bleiben geschützt.",
|
||||
"text": "Was bewirkt Perfect Forward Secrecy (PFS) bei einem VPN?",
|
||||
"answers": [
|
||||
"Ein später kompromittierter Langzeitschlüssel erlaubt es nicht, zuvor aufgezeichnete Sitzungen nachträglich zu entschlüsseln.",
|
||||
"Der Sitzungsschlüssel wird dauerhaft gespeichert, damit sich Verbindungen schneller wieder aufbauen lassen.",
|
||||
"Alle Teilnehmer verwenden denselben statischen Schlüssel, um maximale Kompatibilität zu erreichen."
|
||||
],
|
||||
"correct": 0,
|
||||
"explanation": "PFS erzeugt pro Sitzung flüchtige Schlüssel über einen frischen Diffie-Hellman-Austausch, sodass ein geknackter Langzeitschlüssel den mitgeschnittenen Altverkehr nicht offenlegt. Das dauerhafte Speichern von Sitzungsschlüsseln oder ein einziger statischer Schlüssel würden genau diesen Schutz aushebeln."
|
||||
},
|
||||
{
|
||||
"category": "Verschlüsselung",
|
||||
"hint": "Ein Schlüssel für beide Seiten.",
|
||||
"text": "Welche Aussage über AES trifft zu?",
|
||||
"answers": [
|
||||
"AES ist ein asymmetrisches Verfahren mit öffentlichem und privatem Schlüssel.",
|
||||
"AES ist ein Hashverfahren zur reinen Integritätsprüfung.",
|
||||
"AES ist eine symmetrische Blockchiffre, bei der beide Seiten denselben geheimen Schlüssel nutzen."
|
||||
],
|
||||
"correct": 2,
|
||||
"explanation": "AES ist eine symmetrische Blockchiffre: derselbe geheime Schlüssel ver- und entschlüsselt die Daten. Öffentlicher und privater Schlüssel gehören zu asymmetrischen Verfahren wie RSA, und eine Integritätsprüfung ohne Rückgewinnung der Daten leistet eine Hashfunktion wie SHA – beides andere Verfahrensklassen."
|
||||
},
|
||||
{
|
||||
"category": "Verschlüsselung",
|
||||
"hint": "Schnell und sicher zugleich kombinieren.",
|
||||
"text": "Warum kombiniert man in der Praxis (etwa bei TLS) asymmetrische und symmetrische Verschlüsselung zu einem Hybridverfahren?",
|
||||
"answers": [
|
||||
"Weil asymmetrische Verfahren als unsicher gelten und nur zur Tarnung mitlaufen.",
|
||||
"Weil der schnelle symmetrische Sitzungsschlüssel sicher über das langsame asymmetrische Verfahren ausgetauscht wird.",
|
||||
"Weil symmetrische Verfahren überhaupt keinen gemeinsamen Schlüssel benötigen."
|
||||
],
|
||||
"correct": 1,
|
||||
"explanation": "Beim Hybridverfahren transportiert das asymmetrische Verfahren sicher den symmetrischen Sitzungsschlüssel, mit dem anschließend die Massendaten schnell verschlüsselt werden. Asymmetrische Verfahren sind nicht unsicher, sondern nur rechenintensiv, und symmetrische Verschlüsselung braucht sehr wohl einen gemeinsamen Schlüssel – dessen Austausch ist ja gerade das Problem."
|
||||
},
|
||||
{
|
||||
"category": "Verschlüsselung",
|
||||
"hint": "Nur der Empfänger soll lesen können.",
|
||||
"text": "Alice möchte Bob eine vertrauliche Nachricht asymmetrisch verschlüsselt senden. Welchen Schlüssel verwendet sie dafür?",
|
||||
"answers": [
|
||||
"Bobs öffentlichen Schlüssel.",
|
||||
"Bobs privaten Schlüssel.",
|
||||
"Ihren eigenen privaten Schlüssel."
|
||||
],
|
||||
"correct": 0,
|
||||
"explanation": "Für Vertraulichkeit verschlüsselt Alice mit Bobs öffentlichem Schlüssel, denn nur Bobs privater Schlüssel kann das wieder entschlüsseln. Bobs privaten Schlüssel besitzt Alice gar nicht, und mit ihrem eigenen privaten Schlüssel würde sie signieren – lesbar für jeden mit ihrem öffentlichen Schlüssel."
|
||||
},
|
||||
{
|
||||
"category": "Verschlüsselung",
|
||||
"hint": "Fester Prüfwert, nicht umkehrbar.",
|
||||
"text": "Wozu dient eine kryptografische Hashfunktion wie SHA-256?",
|
||||
"answers": [
|
||||
"Zum umkehrbaren Verschlüsseln, das sich mit dem passenden Schlüssel wieder entschlüsseln lässt.",
|
||||
"Zum verlustfreien Komprimieren großer Dateien.",
|
||||
"Zum Erzeugen eines festen, praktisch kollisionsfreien Prüfwerts zur Integritätssicherung."
|
||||
],
|
||||
"correct": 2,
|
||||
"explanation": "Eine kryptografische Hashfunktion bildet Daten auf einen festen, praktisch kollisionsfreien Prüfwert ab und sichert so die Integrität. Sie ist eine Einwegfunktion – es gibt keinen Schlüssel zum Zurückrechnen – und dient auch nicht der verlustfreien Kompression, da sich die Originaldaten nicht rekonstruieren lassen."
|
||||
},
|
||||
{
|
||||
"category": "Zertifikate & PKI",
|
||||
"hint": "Wer bürgt für den öffentlichen Schlüssel?",
|
||||
"text": "Welche Aufgabe hat eine Zertifizierungsstelle (CA) in einer PKI?",
|
||||
"answers": [
|
||||
"Sie verschlüsselt den gesamten Datenverkehr zwischen den Teilnehmern.",
|
||||
"Sie bestätigt mit ihrer digitalen Signatur die Zuordnung eines öffentlichen Schlüssels zu einer Identität.",
|
||||
"Sie speichert die privaten Schlüssel aller Teilnehmer zentral ab."
|
||||
],
|
||||
"correct": 1,
|
||||
"explanation": "Die CA signiert Zertifikate und beglaubigt damit, dass ein öffentlicher Schlüssel wirklich zu einer bestimmten Identität gehört. Den eigentlichen Datenverkehr verschlüsselt nicht die CA, und private Schlüssel müssen beim jeweiligen Besitzer bleiben – eine zentrale Ablage würde das gesamte Vertrauensmodell zerstören."
|
||||
},
|
||||
{
|
||||
"category": "Zertifikate & PKI",
|
||||
"hint": "Signieren geschieht mit dem eigenen geheimen Schlüssel.",
|
||||
"text": "Mit welchem Schlüssel erzeugt der Absender eine digitale Signatur für ein Dokument?",
|
||||
"answers": [
|
||||
"Mit seinem eigenen privaten Schlüssel.",
|
||||
"Mit dem öffentlichen Schlüssel des Empfängers.",
|
||||
"Mit einem zuvor ausgehandelten gemeinsamen symmetrischen Schlüssel."
|
||||
],
|
||||
"correct": 0,
|
||||
"explanation": "Der Absender signiert mit seinem privaten Schlüssel; jeder kann die Signatur mit dessen öffentlichem Schlüssel prüfen und so Echtheit und Urheberschaft bestätigen. Mit dem öffentlichen Schlüssel des Empfängers würde man zur Vertraulichkeit verschlüsseln, und ein gemeinsamer symmetrischer Schlüssel kann keinen eindeutigen Urheber belegen (keine Nichtabstreitbarkeit)."
|
||||
},
|
||||
{
|
||||
"category": "Zertifikate & PKI",
|
||||
"hint": "Zurückgezogen trotz gültigem Datum.",
|
||||
"text": "Wie prüft ein Client, ob ein vorgelegtes Zertifikat zwischenzeitlich vorzeitig zurückgezogen wurde?",
|
||||
"answers": [
|
||||
"Anhand des Ablaufdatums, das im Zertifikat eingetragen ist.",
|
||||
"Durch erneutes Berechnen des Fingerprints des Zertifikats.",
|
||||
"Über eine Sperrliste (CRL) oder eine OCSP-Abfrage bei der ausstellenden CA."
|
||||
],
|
||||
"correct": 2,
|
||||
"explanation": "Den Sperrstatus liefern eine Zertifikatssperrliste (CRL) oder eine OCSP-Anfrage bei der CA. Das Ablaufdatum zeigt nur den regulären Gültigkeitszeitraum, nicht einen vorzeitigen Rückruf, und das Neuberechnen des Fingerprints prüft lediglich die Unverfälschtheit, nicht den Widerruf."
|
||||
},
|
||||
{
|
||||
"category": "Zertifikate & PKI",
|
||||
"hint": "Kette bis zu einer vertrauten Wurzel.",
|
||||
"text": "Worauf beruht das Vertrauen in ein Serverzertifikat beim Aufruf einer HTTPS-Seite?",
|
||||
"answers": [
|
||||
"Darauf, dass das Zertifikat selbstsigniert und damit automatisch fälschungssicher ist.",
|
||||
"Auf einer lückenlosen Vertrauenskette bis hinauf zu einer im System hinterlegten Root-CA.",
|
||||
"Darauf, dass die Domain im Zertifikat mit irgendeiner beliebigen anderen CA übereinstimmt."
|
||||
],
|
||||
"correct": 1,
|
||||
"explanation": "Das Vertrauen folgt der Kette vom Serverzertifikat über Zwischenzertifikate bis zu einer Root-CA, der Betriebssystem oder Browser bereits vertrauen. Ein selbstsigniertes Zertifikat hat keinen externen Vertrauensanker, und die ausstellende Stelle muss eine vertrauenswürdige CA sein, nicht eine beliebige."
|
||||
},
|
||||
{
|
||||
"category": "Schutzziele & Authentisierung",
|
||||
"hint": "Daten wurden unbemerkt verändert.",
|
||||
"text": "Ein Angreifer verändert unbemerkt die Beträge in einer übertragenen Überweisungsdatei. Welches Schutzziel der CIA-Triade ist dadurch primär verletzt?",
|
||||
"answers": [
|
||||
"Integrität.",
|
||||
"Vertraulichkeit.",
|
||||
"Verfügbarkeit."
|
||||
],
|
||||
"correct": 0,
|
||||
"explanation": "Die unbefugte, unbemerkte Veränderung von Daten verletzt die Integrität. Vertraulichkeit wäre erst bei unbefugtem Mitlesen betroffen und Verfügbarkeit erst, wenn die Daten oder das System nicht mehr erreichbar wären – beides ist hier nicht der Fall."
|
||||
},
|
||||
{
|
||||
"category": "Schutzziele & Authentisierung",
|
||||
"hint": "Der Dienst ist nicht mehr erreichbar.",
|
||||
"text": "Ein DDoS-Angriff überlastet einen Webshop so stark, dass Kunden ihn nicht mehr erreichen. Welches Schutzziel ist primär betroffen?",
|
||||
"answers": [
|
||||
"Integrität.",
|
||||
"Vertraulichkeit.",
|
||||
"Verfügbarkeit."
|
||||
],
|
||||
"correct": 2,
|
||||
"explanation": "Ein DDoS-Angriff verhindert den legitimen Zugriff und trifft damit die Verfügbarkeit. Die Daten werden dabei weder verändert (Integrität) noch ausgelesen (Vertraulichkeit) – der Dienst ist schlicht nicht erreichbar."
|
||||
},
|
||||
{
|
||||
"category": "Schutzziele & Authentisierung",
|
||||
"hint": "Zwei verschiedene Faktorarten.",
|
||||
"text": "Eine Anmeldung verlangt ein Passwort und zusätzlich einen Einmalcode aus einer Authenticator-App. Warum gilt das als echte Zwei-Faktor-Authentisierung?",
|
||||
"answers": [
|
||||
"Weil zwei verschiedene Passwörter nacheinander abgefragt werden.",
|
||||
"Weil zwei unterschiedliche Faktorarten kombiniert werden: Wissen (Passwort) und Besitz (Gerät mit App).",
|
||||
"Weil dasselbe Passwort zur Sicherheit zweimal eingegeben werden muss."
|
||||
],
|
||||
"correct": 1,
|
||||
"explanation": "Echte 2FA verbindet Faktoren aus verschiedenen Kategorien – hier Wissen (Passwort) und Besitz (das Gerät, das den Code erzeugt). Zwei Passwörter oder eine doppelte Eingabe bleiben im selben Faktor Wissen und fügen keinen zweiten, unabhängigen Faktor hinzu."
|
||||
},
|
||||
{
|
||||
"category": "Schutzziele & Authentisierung",
|
||||
"hint": "Erst wer bist du, dann was darfst du.",
|
||||
"text": "Worin unterscheiden sich Authentisierung und Autorisierung?",
|
||||
"answers": [
|
||||
"Die Authentisierung weist die Identität nach, die Autorisierung legt danach fest, worauf der Nutzer zugreifen darf.",
|
||||
"Die Authentisierung vergibt die Zugriffsrechte, die Autorisierung prüft das Passwort.",
|
||||
"Beide Begriffe bezeichnen denselben Vorgang der reinen Passwortprüfung."
|
||||
],
|
||||
"correct": 0,
|
||||
"explanation": "Die Authentisierung beantwortet, wer jemand ist, und erst die Autorisierung entscheidet, welche Ressourcen dieser Nutzer verwenden darf. Die vertauschte Definition dreht beide Schritte um, und sie als denselben Vorgang zu sehen ignoriert, dass Identitätsnachweis und Rechtevergabe getrennte Stufen sind."
|
||||
}
|
||||
]
|
||||
}
|
||||
Reference in New Issue
Block a user