CCNA — Security Fundamentals: 60 Übungsfragen

Step 1: Analyse der Anforderung — Zuerst bestimmt man genau, welche Aktionen der Ingenieur für die Wartung durchführen muss (z. B. VLAN ändern, Port-Konfigurationen ausrollen). Auf dieser Basis wird ein begrenztes Rechteprofil definiert.

Step 2: Implementierung der kontrollierten Zugriffsrechte — Ein temporäres Konto über Role-Based Access Control (RBAC) oder ein Just-In-Time (JIT) Privilege-Management-System bietet nur die notwendigen Befugnisse für den definierten Zeitraum; Protokollierung und zeitliche Begrenzung erhöhen die Nachvollziehbarkeit.

Step 3: Überwachen und Widerrufen — Während und nach der Wartung werden Aktionen überwacht (Audit-Logs) und das Konto nach Abschluss automatisch deaktiviert oder gelöscht. Trap: Häufige Fehleinschätzung ist, dass Komfort (dauerhafter Adminzugang) gleichbedeutend mit Effizienz ist; tatsächlich erhöht dies das Risiko von Fehlkonfigurationen und lateralem Zugriff. Warum jede falsche Antwort fehlschlägt: Antwort 2 (dauerhafter voller Adminzugriff) verletzt Least Privilege, weil unnötige Rechte vergeben werden und ein kompromittiertes Konto gesamtes Netz gefährden kann; außerdem erschwert es Auditing. Antwort 3 (ACLs deaktivieren) gefährdet das Netzwerk während der Wartung, weil Sicherheitskontrollen außer Kraft gesetzt und damit Angriffsflächen temporär vergrößert werden — Wartung darf nicht auf Kosten von Network Segmentation und Filterung gehen. Antwort 4 (Passwortweitergabe) verletzt Accountability und Non-Repudiation: Geteilte Zugangsdaten verhindern eine eindeutige Zuordnung von Aktionen und erhöhen Missbrauchsrisiko; außerdem widerspricht dies Compliance-Anforderungen. Im Kontext eines Unternehmensnetzwerks mit Subnetting, Core/Distribution-Switching und VLANs ist die Kombination aus RBAC, zeitlich begrenzten Sudo-/Privileged-Access-Mechanismen und zentraler Authentifizierung (z. B. TACACS+/RADIUS) die sichere und praxisnahe Lösung.

Step 1: CIA-Triade kurz definieren: Die CIA-Triade besteht aus Confidentiality (Vertraulichkeit), Integrity (Integrität) und Availability (Verfügbarkeit). Jede Sicherheitsverletzung lässt sich primär einer dieser Kategorien zuordnen, auch wenn Seiteneffekte auftreten können.

Step 2: Analyse der Optionen im Kontext Availability: Verfügbarkeit betrifft die Zugänglichkeit und Funktionsfähigkeit von Systemen und Diensten für autorisierte Benutzer. Ein Distributed Denial of Service (DDoS)-Angriff überflutet Ressourcen (Bandbreite, Serverkapazität) und führt genau dazu: Dienste sind nicht mehr erreichbar oder arbeiten stark eingeschränkt. Daher ist Option 2 eindeutig ein Availability-Vorfall.

Step 3: Abgrenzung zu anderen Kategorien und Gründen: Die anderen Optionen betreffen primär Vertraulichkeit (Exfiltration der Kundenliste durch Phishing) oder Integrität (Manipulation von Transaktionsdaten) bzw. Access-Control-Probleme/Least-Privilege-Verstöße (Administrator mit zu vielen Rechten sieht HR-Daten). Diese haben andere primäre Auswirkungen als die Nicht-Verfügbarkeit des Dienstes. Trap: Ein häufiger Denkfehler ist zu glauben, dass jede Sicherheitsverletzung mehrere Triaden-Aspekte gleich stark betrifft. Zwar kann ein DDoS auch Vertraulichkeits- oder Integritätsprobleme nach sich ziehen (z. B. Ablenkungsangriffe), doch primär ist es ein Availability-Problem. Why each wrong answer fails: - Option 1 (kundenliste exfiltriert durch Phishing): Das ist klassisch ein Confidentiality-Problem — Daten wurden gestohlen/ungesichert weitergegeben. Es ist nicht primär Availability, weil die Systeme weiterhin erreichbar sein können. - Option 3 (Veränderung von Transaktionsdaten): Das greift die Integrität der Daten an. Die Verfügbarkeit könnte tangiert sein, aber die Kernwirkung ist die Unzuverlässigkeit der Daten (Fälschungen), somit Intgrity. - Option 4 (Administrator mit zu vielen Privilegien blickt in HR-Daten): Das ist ein Verstoß gegen das Prinzip der geringsten Rechte und verursacht in erster Linie ein Confidentiality-Problem (unerlaubter Datenzugriff). Es zeigt zudem, warum 'Least Privilege' wichtig ist, betrifft aber nicht primär Availability. Fazit: Für Availability ist der DDoS-Angriff das prägnanteste Beispiel: er verhindert legitimen Zugriff auf einen Service und beeinträchtigt damit die Verfügbarkeit von Ressourcen für Benutzer.

Step 1: Matching-Logik verstehen — First-match wins: Erweiterte ACLs auf Cisco-Geräten werden sequentiell von oben nach unten ausgewertet; das erste passende Eintrag bestimmt das Schicksal des Pakets (permit oder deny). Wenn keine Regel passt, ist das implizite 'deny ip any any' am Ende wirksam.

Step 2: Regeln analysieren: Die erste Regel erlaubt ausschließlich TCP-Verkehr von beliebiger Quelle an Host 192.168.10.10 mit Zielport 80 (HTTP). Das ist sehr spezifisch: nur TCP/80 ist erlaubt. Die zweite Regel ist explizit 'deny ip any any', also ein universelles Verbot aller IP-Pakete, die nicht vorher erlaubt wurden.

Step 3: Ergebnis für SSH (TCP/22): Ein SSH-Paket zu 192.168.10.10 auf Port 22 stimmt nicht mit Regel 1 überein, da der Zielport 22 ≠ 80. Daher geht die Auswertung zur nächsten Regel, Regel 2, die explizit alles ablehnt. Somit wird SSH verworfen. Trap: Ein häufiger Denkfehler ist zu glauben, dass eine spezifische erlaubende Regel an der Spitze nebenbei andere Dienste nicht beeinflusst; oder dass nur spezifizierte Dienste blockiert werden und "alles andere" automatisch erlaubt wäre. Ohne explizite 'permit' für SSH wird es geblockt, da die ACL restriktiv endet. Why each wrong answer fails: - Option 1 (SSH wird erlaubt): Falsch, weil die erste Regel nur TCP/80 erlaubt. SSH (TCP/22) passt nicht zu dieser Regel. Die ACL enthält danach eine 'deny ip any any', die SSH blockiert. - Option 3 (Router erlaubt standardmäßig alle ausgehenden Verbindungen): Falsch. Die ACL steuert die Pakete, und auf dem Interface mit angewandter ACL ist die Steuerung strikt. Es gibt keine generelle "Erlaubnis" seitens des Routers, wenn eine ACL vorhanden ist — die ACL regelt Verkehr unabhängig von der "Richtung" des Verbindungsaufbaus. - Option 4 (SSH wird verworfen nur wenn lokal): Falsch, weil die ACL keinen Unterschied zwischen lokalen und entfernten Quellen macht; 'deny ip any any' gilt für alle Quellen. Die Regel ist nicht auf ein Subnetz beschränkt und trifft global zu. Fazit: Die richtige Interpretation ist, dass SSH (TCP/22) abgewiesen wird, weil nur HTTP explizit erlaubt wurde und die nachfolgende Regel alles andere verbietet. In ACL-Design gilt: Reihenfolge und Spezifität sind entscheidend; explizit erlaubte Verkehre müssen vollständig definiert werden, wenn später ein generelles 'deny' folgt.

Step 1: Anforderung: Rogue DHCP-Server sollen blockiert werden, legitime DHCP-Server und Relay-Agenten müssen weiterhin DHCP-OFFERs/ACKs über Uplinks erhalten. DHCP Snooping entscheidet, ob DHCP-Server-Antworten basierend auf Port-Trust zugelassen werden.

Step 2: Aktivierung: DHCP Snooping muss global und für betroffene VLANs aktiviert werden. Ports, die legitime DHCP-Server oder DHCP-Relay-Agenten (z. B. Router-Interfaces) verbinden, müssen explizit als trusted markiert werden; alle anderen Access-Ports bleiben untrusted, so dass DHCP-Offers von dort verworfen werden. DAI (Dynamic ARP Inspection) ist eine sinnvolle Ergänzung, die ARP-Traffic validiert unter Verwendung derselben DHCP-Snooping-Bindings; DAI hilft, ARP-Spoofing zu verhindern, das häufig zusammen mit rogue DHCP-Aktivitäten auftritt.

Step 3: Umsetzung und Prüfung: (a) Aktivieren Sie DHCP Snooping global; (b) aktivieren Sie es für nötige VLANs; (c) markieren Sie Router-/Server-Ports als trusted; (d) aktivieren Sie DAI für kritische VLANs; (e) überprüfen Sie Binding-Tabellen und Testfälle (Client erhält IP vom legitimen DHCP-Server; rogue-DHCP-Server-Angebote werden geblockt). Trap: Ein häufiger Fehler ist, Access-Ports als trusted zu setzen, um "Bequemlichkeit" zu gewährleisten — dadurch wird DHCP Snooping wirkungslos. Ein anderer Fehler ist, Relay/Helper zu entfernen, was Client-DHCP-Anfragen in verteilten Netzen nicht funktionieren lässt. Warum jede falsche Antwort fehlschlägt: - DHCP Snooping global + Uplink trusted (richtig): Dies ist die korrekte Basis, damit legitime DHCP-Server über Uplinks Antworten senden können. - DHCP Snooping + alle Access-Ports als trusted (falsch): Wenn Access-Ports trusted sind, können rogue DHCP-Server an Access-Ports DHCP-Offers senden und die Schutzwirkung entfällt. - DHCP Snooping + DHCP-Relay/Helper entfernen (falsch): Entfernen des Relay unterbindet oftmals korrekte DHCP-Zustellung in Netzwerken mit zentralen DHCP-Servern; Relay-Agents sind notwendig, wenn DHCP-Server nicht im selben Broadcast-Domain/VLAN sind. - DHCP Snooping + DAI (richtig): DAI nutzt DHCP-Snooping-Bindings für ARP-Validierung und ergänzt Schutz gegen ARP-basiertes Umleiten des Traffics. Zusammen bilden sie eine robuste Verteidigung gegen rogue DHCP-Server und ARP-Spoofing.

Step 1: Funktionsprinzip von IP Source Guard — IP Source Guard filtert IP‑Verkehr auf Port‑Ebene, indem es prüft, ob die im Datenpaket genutzte IP‑Adresse mit der erwarteten IP für die Port‑MAC‑Adresse übereinstimmt. Wird eine Diskrepanz entdeckt, werden Pakete verworfen, um IP‑Spoofing zu verhindern.

Step 2: Voraussetzungen für die Validierung — Für diese Prüfung benötigt der Switch eine Datenquelle, die gültige IP↔MAC‑Zuordnungen liefert: entweder die dynamisch erstellte DHCP‑Snooping‑Binding‑Tabelle (wenn Geräte ihre IP per DHCP erhalten) oder manuelle statische IP‑MAC‑Bindings (bei statisch konfigurierten Geräten). Ohne diese Bindings weiß der Switch nicht, welche IP für welche MAC erwartet wird.

Step 3: Portkonfiguration und Interaktion mit anderen Features — IP Source Guard wird auf Access‑Ports angewendet; diese Ports sind typischerweise untrusted, weil sie Endgeräte verbinden. Uplink‑Ports bleiben trusted, damit legitimer Verkehr nicht fälschlich blockiert wird. Port Security kann parallel betrieben werden; es besteht keine zwingende Inkompatibilität, jedoch müssen Regeln abgestimmt werden (z. B. sticky MACs vs. dynamische Bindings). Trap: Ein häufiger Irrglaube ist, dass DAI zwingend erforderlich sei. DAI schützt ARP‑Verkehr und nutzt oft dieselben DHCP‑Snooping‑Bindings, ist aber keine Voraussetzung für IP Source Guard. Ebenso glauben manche, Port Security müsse entfernt werden — tatsächlich sind beide Funktionen oft komplementär. Warum jede falsche Antwort scheitert: - Dynamic ARP Inspection (DAI) muss auf allen VLANs aktiviert sein: Nicht korrekt — DAI ist nützlich gegen ARP‑Spoofing, aber IP Source Guard funktioniert unabhängig von DAI, solange IP‑MAC‑Bindings vorhanden sind. - Port Security muss entfernt werden, da es mit IP Source Guard inkompatibel ist: Falsch — Port Security beschränkt MAC‑Adressen; es kann parallel zu IP Source Guard betrieben werden. Allerdings muss man Konfigurationen aufeinander abstimmen, um unerwünschte Nebeneffekte zu vermeiden. Praxisempfehlung: Aktivieren Sie DHCP Snooping für VLANs, in denen IP Source Guard eingesetzt werden soll; prüfen Sie die Binding‑Einträge; konfigurieren Sie IP Source Guard auf den Access‑Ports und markieren Sie Uplinks als trusted. Verwenden Sie Port Security ergänzend, vor allem an Ports mit bekannten Endgeräten.

Step 1: Protokoll-Eigenschaften verstehen — TACACS+ wurde für Netzwerkgeräte-Management entwickelt und bietet eine klare Trennung der AAA-Funktionen: Authentication (wer du bist), Authorization (was du darfst) und Accounting (was du getan hast). Wichtig ist außerdem, dass TACACS+ die komplette Paket-Nutzlast verschlüsselt, was es geeigneter für granular kontrollierte Geräte-Administration macht (z. B. Kommando-Autorisierung auf Cisco IOS: erlauben/verbieten einzelner EXEC-Kommandos).

Step 2: RADIUS konzeptionell betrachten — RADIUS wurde primär für Netzwerkzugang (z. B. PPP, 802.1X, Netzwerk-Access-Server) entworfen. Es kombiniert in vielen Implementierungen Authentication und Authorization (d.h. AuthN und AuthZ werden typischerweise im selben Austausch behandelt) und überträgt Attribute. RADIUS läuft klassischerweise über UDP (Port 1812/1813 bzw. ältere Implementierungen 1645/1646), und es verschlüsselt typischerweise nur das Passwort im Access-Request, während viele Attribute im Klartext belassen werden können. Aufgrund seines Designs ist RADIUS sehr gut für Zugangskontrolle (z. B. WLAN- oder VPN-Authentifizierung) geeignet.

Step 3: Auswahl nach Anforderung — Wenn Sie feingranulare, kommandobasierte Autorisierungsentscheidungen auf Netzwerkgeräten brauchen, ist TACACS+ oft die bessere Wahl. Für viele Benutzerzugangs- und Netzwerk-Access-Szenarien ist RADIUS die verbreitete und interoperable Lösung. Beide haben Vor- und Nachteile; zentralisiertes Logging und Redundanz sind unabhängig vom Protokoll wichtige Aspekte. Trap: Ein häufiger Fehler ist zu glauben, RADIUS und TACACS+ seien austauschbar ohne Berücksichtigung der Unterschiede bei Verschlüsselung, Protokoll (UDP vs. TCP) und der Trennung von AAA-Funktionen. Das führt zu suboptimalen Architekturentscheidungen (z. B. Nutzung von RADIUS für Kommandoautorisierung auf Routern ohne die entsprechenden Features). Why each wrong answer fails: - Option 1 (RADIUS verwendet TCP und verschlüsselt die gesamte Nutzlast): Diese Aussage ist falsch. RADIUS verwendet typischerweise UDP (nicht TCP) und verschlüsselt normalerweise nur das Passwortfeld, nicht die komplette Nutzlast. Daher ist die Aussage über vollständige Paketverschlüsselung und TCP falsch. - Option 4 (TACACS+ verschlüsselt nur Passwortfelder und erlaubt keine Detailautorisierung): Ebenfalls falsch. TACACS+ verschlüsselt die gesamte Paket-Nutzlast und ist bekannt dafür, Authentication und Authorization zu trennen, was feingranulare Kommandoberechtigungen ermöglicht. Somit ist diese Beschreibung inhaltlich verkehrt. - Option 2 und 3 sind korrekt: TACACS+ bietet Verschlüsselung des Payloads und AAA-Trennung; RADIUS arbeitet typischerweise über UDP und kombiniert AuthN/AuthZ in vielen Szenarien, wobei nur das Passwort stark geschützt wird. Fazit: Wählen Sie das Protokoll nach Use-Case: TACACS+ für gerätebasierte, kommandogene Autorisierung und höhere Payload-Sicherheit; RADIUS für Access-Authentifizierung (WLAN, VPN) mit breiter Interoperabilität.

Step 1: Unterschiedliche Mechanismen für Managementzugang nutzen — Wenn das Ziel ist, SSH-Zugriff auf das Gerätemanagement zu beschränken, ist die Verwendung von access-class auf den VTY-Lines eine gezieltere und häufig sicherere Methode als eine allgemeine Interface-ACL auf dem Management-SVI. access-class appliziert direkt auf die vty-Lines und kontrolliert SSH/Telnet-Anmeldungen, ohne andere Pakete auf dem Interface zu beeinflussen. Dadurch verringert sich die Gefahr, administrativen Remote-Zugriff versehentlich zu blockieren.

Step 2: Explizite Ausnahmen und Tests einbauen — Vor Aktivierung einer ACL sollte man immer sicherstellen, dass administrative Workstation-IP(s) (z. B. die IP des NOC oder eines Jump-Hosts) explizit erlaubt sind. Zusätzlich sind explizite Regeln für bereits bestehende Sessions (oder die Nutzung von 'permit established' bei unterstützten Protokollen) sinnvoll. Wichtig: Testing über die Konsole oder Out-of-Band-Zugänge vor und nach dem Rollout verhindert Aussperrung. Außerdem ist eine temporäre ACL mit Logging sinnvoll, um Auswirkungen sichtbar zu machen.

Step 3: Change-Management und Fallback planen — Setzen Sie ACL-Änderungen über ein Change-Fenster, dokumentieren Sie die neuen Regeln und halten Sie einen Recovery-Plan (z. B. physischer Konsole, serieller Zugriff, Remote KVM) bereit. Rolling back via Console ist essenziell, falls die Remote-Änderung den Zugang kappt. Trap: Viele Admins wenden ACLs direkt am Interface an, weil sie denken "das ist global und schnell", aber das kann leicht den eigenen SSH/Management-Zugang kappen. Eine weitere Falle ist der Glaube, dass SSH-Aktivierung Sicherheitsregeln außer Kraft setzt — das tut sie nicht. Why each wrong answer fails: - Option 2 (ACL sofort in Produktion einsetzen): Dies ist riskant. Direkter Live-Deploy ohne Test, ohne explizite Ausnahmen und ohne Fallback-Plan erhöht die Wahrscheinlichkeit, den eigenen Zugang zu verlieren. Best Practice ist Testumgebung/zeitlich begrenztes Rollout und sofortiger Zugriff per Konsole. - Option 4 (SSH ersetzt ACL-Beschränkungen): Falsch — SSH ist nur das Managementprotokoll; ACLs regeln Paket-Level-Flows und können SSH-Verbindungen durchaus blockieren. SSH zu aktivieren schützt nicht automatisch gegen Fehler in ACLs. Man muss sowohl Protokolle (SSH) korrekt konfigurieren als auch ACLs/Access-class sauber implementieren. - Option 1 und 3 sind korrekt: access-class ist gezielter für vty-Restriktionen; explizite Permit-Statements für Admin-IP(s) und geplante Tests verhindern Selbstsperrung. Zusammenfassung: Wenige, gut dokumentierte Regeln, gezielte Zugriffskontrolle (access-class), Test über Out-of-Band und Notfallkonsole sind die Schlüssel, um Managementzugänge zu härten ohne sich selbst auszusperren.

Step 1: Problemverständnis und Ziel: Rogue DHCP-Server geben falsche IP-Informationen aus und IP-Spoofing erlaubt Clients, Adressen anzunehmen, die ihnen nicht zugewiesen sind; Ziel ist, DHCP-Replys von nicht vertrauenswürdigen Ports zu blocken und sicherzustellen, dass ein Host nur die für ihn bestimmte IP nutzt.

Step 2: Mechanismen anwenden – DHCP Snooping ist die Grundlage: DHCP Snooping markiert Ports als trusted (z. B. Uplink zu DHCP-Servern) oder untrusted (Access-Ports). Auf untrusted Ports verwirft der Switch DHCP-Server-Antwortpakete (DHCPOFFER/DHCPACK), was rogue DHCP-Server effektiv verhindert. Zusätzlich baut Snooping eine Binding‑Datenbank (MAC, IP, VLAN, Lease Time, Port), die eine verlässliche Quelle zur Validierung bietet. IP Source Guard (IPSG) ist die ergänzende Maßnahme: IPSG verwendet die Snooping-Bindings, um ausgehende Pakete auf einem Access-Port zu validieren — es lässt nur Verkehr zu, wenn die Quell-IP/MAC/VLAN-Kombination mit einer Snooping-Binding übereinstimmt. Damit wird IP‑Spoofing durch legitime, vom DHCP-Server vergebene Adressen verhindert.

Step 3: Betrieb & Best Practices: Aktivieren Sie DHCP Snooping pro VLAN, konfigurieren Sie die Ports korrekt (trusted/untrusted), sichern Sie die Binding-Datenbank persistent (z. B. DB-Files / external DB), aktivieren Sie IPSG auf Access-Ports für Endgeräte, und testen mit einem Staging-Bereich. Trap: Ein häufiger Irrtum ist, zu glauben, IP Source Guard allein reicht — IPSG benötigt die DHCP-Snooping-Bindings oder statische Bindings. Andernfalls fehlen die Validierungsdaten. Ebenso denken manche, DAI alleine stoppt DHCP‑Angriffe; DAI schützt ARP, nicht DHCP. Warum jede falsche Antwort scheitert: - Option 3 (DAI ohne DHCP Snooping): DAI validiert ARP basierend auf einer Bindungsquelle; ohne DHCP Snooping fehlen dynamische Bindungen und DAI kann nicht korrekt arbeiten (es kann zwar mit statischen ARP-ACLs betrieben werden, ist aber in großen Umgebungen unpraktisch). - Option 4 (nur Port Security mit statischer MAC-Zuordnung): Port Security begrenzt MAC-Anzahl oder setzt Sticky-MAC, es verhindert nicht, dass ein rogue DHCP-Server IP‑Adressen verteilt. Außerdem ist die Verwaltung statischer MACs in großen Netzwerken unflexibel. Fazit: Kombination DHCP Snooping + IP Source Guard bietet eine robuste Defense-in-Depth-Lösung gegen rogue DHCP und IP‑Spoofing auf Access‑Layer in Enterprise-Umgebungen.

Step 1: Ziel definieren. Least Privilege bedeutet, dass Benutzer nur die minimal nötigen Rechte für ihre aktuelle Aufgabe erhalten und temporäre erhöhte Rechte zeitlich begrenzt und nachvollziehbar sein sollten. Wichtige Anforderungen sind Auditierbarkeit, zentrale Kontrolle, Rückverfolgbarkeit und minimaler Zeitrahmen für erhöhte Rechte.

Step 2: Lösung bewerten. Die Nutzung eines zentralen AAA-Systems wie TACACS+ oder RADIUS mit rollenbasierten Zugriffskontrollen und Just-in-Time (JIT) Provisioning erfüllt diese Anforderungen. TACACS+ erlaubt granularen Command Authorization, Logging aller ausgeführten Befehle und Integration mit Identity-Management-Systemen, so dass temporäre Rollen automatisch zugewiesen und nach Ablauf entfernt werden können.

Step 3: Umsetzung und Betrieb. Aufbau einer Authentifizierungs- und Autorisationsarchitektur, Automation über API/Identity-Provider für JIT-Zuweisung (z. B. über ein Ticketing-System), regelmäßige Reviews von Rollen und Rechtevergaben sowie Audit-Logs zur Nachvollziehbarkeit. Zusätzlich MFA für die Identifizierung verwenden. Trap: Eine verbreitete Fehleinschätzung ist, dass das Verteilen permanenter Rechte oder die Nutzung gemeinsamer Konten einfacher und damit sicherer ist. In Wahrheit erhöhen diese Ansätze Risiko und reduzieren Auditierbarkeit. Why each wrong answer fails: - Gemeinsames Admin-Konto mit Passwort-Repository: Gemeinsame Konten verhindern individuelle Nachvollziehbarkeit, erschweren forensische Analysen und entsprechen nicht dem Least Privilege. Wenn das Passwort kompromittiert wird, hat ein Angreifer weitreichenden Zugriff ohne Attribution. - Dauerhafte lokale Admin-Rechte für alle Ingenieure: Das verletzt das Prinzip der geringsten Privilegien direkt, erhöht Angriffsfläche und das Risiko von Fehlkonfigurationen. Es gibt keine zeitliche Begrenzung und keine granulare Autorisation. - SSH-Schlüssel verteilen und manuelle Rechtevergabe: SSH-Schlüssel sind für Authentifizierung nützlich, aber manuelle Konfiguration auf jedem Gerät skaliert schlecht, ist fehleranfällig und erschwert zentrale Auditierung und JIT-Zugriffsverwaltung. Zudem fehlen meist Features wie command authorization, zentralisierte Sperrung oder automatische Entzug-Verfahren. Fazit: Eine zentrale AAA-Lösung mit rollenbasierter Rechtevergabe und Just-in-Time-Provisioning bietet granulare Kontrolle, Auditierbarkeit und minimiert die Zeitspanne, in der erhöhte Rechte bestehen, womit es das Prinzip der geringsten Privilegien am besten umsetzt.

Step 1: Sichere Remote-Management-Grundlagen Sichere Verwaltung erfordert verschlüsselte Management-Protokolle (SSH) statt unverschlüsselter (Telnet). SSH benötigt RSA-Schlüssel und einen Domain-Namen für die Schlüsselerzeugung auf Cisco-Geräten; danach muss der Zugriff auf vty-Leitungen auf SSH beschränkt werden.

Step 2: Konkrete Konfigurationsschritte Zwei zentrale Schritte sind: (a) ip domain-name konfigurieren und RSA-Schlüssel erzeugen (crypto key generate rsa) – dies erzeugt die Host-Keys, die SSH benötigt; (b) auf den vty-Leitungen 'transport input ssh' setzen, damit nur SSH-Verbindungen akzeptiert werden und Telnet blockiert wird. Zusätzlich sollte 'username ... secret ...' und 'enable secret' verwendet werden, da 'enable secret' PBKDF/MD5-basiert (besser verschlüsselt) ist im Vergleich zum Klartext 'enable password'.

Step 3: Warum einige häufig genutzte Maßnahmen nicht ausreichen Die CLI-Anweisung 'service password-encryption' verschlüsselt Passwörter nur schwach und reversible (Typ-7), sie ist kein Ersatz für starke Hashes/Secrets oder für SSH; sie verhindert lediglich Klartextdarstellung in der Konfiguration vor weniger erfahrenen Augen. Trap: verbreiteter Fehler Administratoren denken manchmal, dass 'service password-encryption' ausreichend ist oder dass das einfache 'enable password' sichere Zugriffe bietet. Beide Annahmen sind falsch — 'enable secret' und SSH sind Mindestanforderungen für sichere Verwaltung. Why each wrong answer fails: Option 1 (korrekt): 'transport input ssh' auf vty schaltet Telnet ab und erzwingt SSH; eine Kernmaßnahme zur Härtung. Option 2 (falsch): 'enable password' steht im Klartext oder weniger geschützt in der Konfiguration und ist unsicher. 'enable secret' sollte verwendet werden, weil es gehashte/geschützte Speicherung bietet. Option 3 (korrekt): SSH benötigt RSA-Schlüssel; ip domain-name + crypto key generate rsa sind notwendige Schritte, damit SSH-Verbindungen möglich und sicher sind. Option 4 (falsch): 'service password-encryption' verwendet eine reversible, schwache Verschlüsselung (Typ-7). Es ist besser als nichts, aber nicht ausreichend als alleinige Schutzmaßnahme und nicht gleichwertig mit 'enable secret' oder SSH.

Step 1: Unterschied Zwischen Modi verstehen. IPsec bietet grundsätzlich Transport- und Tunnelmodus. Im Transportmodus wird nur der Payload des IP-Pakets (z. B. TCP/UDP-Daten) verschlüsselt, während der Original-IP-Header unverschlüsselt bleibt. Im Tunnelmodus wird das gesamte Original-IP-Paket inklusive Header verschlüsselt und in ein neues IP-Paket gekapselt.

Step 2: Anforderungen des Szenarios anwenden. Für Site-to-Site VPNs zwischen Gateways ist häufig gewünscht, dass das gesamte private Netzsegment hinter einem Gateway für das andere Netz verborgen und geschützt ist. Tunnelmodus verschlüsselt das komplette Originalpaket und ersetzt den originalen Header durch einen neuen Header zwischen Gateways, sodass interne Adressierung und Inhalte nicht offengelegt werden.

Step 3: Auswahl und Implementation. Tunnelmodus verwenden, dabei ESP (Encapsulating Security Payload) für Verschlüsselung und optionale Integrität einsetzen. Sourcen und Ziele sind die Gateways; Routing auf beiden Seiten sorgt für Weiterleitung der internen Netze durch die verschlüsselte Tunnel-Schnittstelle. Weiterhin Sicherheitspolicies, IKEv2 für Schlüsselaushandlung und PFS (Perfect Forward Secrecy) implementieren. Trap: Ein häufiger Fehler ist die Annahme, AH würde Verschlüsselung bieten. AH liefert Integrität und Authentizität, ersetzt aber nicht ESP, da AH keinen Payload verschlüsselt und in der Praxis oft nicht geeignet ist, weil es auch Teile des IP-Headers schützt, die von NAT geändert werden können. Why each wrong answer fails: - Transportmodus: Obwohl effizienter für End-zu-End Szenarien zwischen Hosts ist Transportmodus ungeeignet, wenn Gateways komplette interne Netzwerke kapseln und auch Headerinformationen verborgen werden sollen. Transportmodus lässt Teile des IP-Headers unverschlüsselt, was in Site-to-Site Umgebungen problematisch sein kann. - AH (Authentication Header) Modus: AH bietet Authentizität und Integrität, verschlüsselt aber nicht die Nutzlast. Zudem ist AH inkompatibel mit NAT, da AH Teile des IP-Headers authentifiziert. Für vertrauliche Verschlüsselung des gesamten Pakets ist ESP/Tunnelmodus die richtige Wahl. - DTLS: DTLS ist TLS über UDP und wird typischerweise für VPNs genutzt, die TLS-basiert sind (z. B. OpenVPN) oder für Media-Anwendungen, jedoch adressiert es nicht das klassische IPsec-Tunnelproblem zwischen Gateways und ist nicht die Standardantwort für IPsec-basierte Site-to-Site-Gateways. Fazit: Für Site-to-Site-Verbindungen zwischen Gateways, die das gesamte interne IP-Paket schützen sollen, ist IPsec im Tunnelmodus mit ESP die richtige Wahl.

Step 1: Grundprinzip der ACL-Verarbeitung Access-Lists werden sequenziell Zeile für Zeile abgearbeitet. Ein Paket trifft auf die erste Regel, die auf seine Parameter (Quelle, Ziel, Protokoll, Ports) passt. Sobald eine Übereinstimmung gefunden ist, wird das Ergebnis dieser Regel (permit oder deny) angewendet und die Verarbeitung der ACL für dieses Paket endet.

Step 2: Konsequenzen der First-Match-Logik Weil die ACL-Verarbeitung bei der ersten passenden Regel stoppt, ist die Reihenfolge der Einträge kritisch. Häufige Fehler entstehen, wenn allgemeine Permits vor spezifischen Denys stehen — das Permit trifft zuerst und verhindert, dass das spezifische deny jemals wirkt. Deshalb sollten spezifische Regeln vor allgemeineren stehen.

Step 3: Implizite Regel am Ende und ihre Bedeutung Unabhängig davon, ob Sie am Ende einer ACL ein 'deny' explizit hinzufügen, existiert automatisch eine implizite 'deny ip any any'. Das bedeutet: Wenn kein Permit greift, wird das Paket verworfen. Praktisch heißt das: ACLs sind restriktiv, wenn keine Erlaubnis definiert ist. Trap: verbreiteter Fehler Ein häufiger Irrtum ist anzunehmen, dass bei fehlendem explicit deny automatisch alles erlaubt wird. Tatsächlich ist es genau umgekehrt: ohne explizite Permit-Regel blockiert die implizite deny-Regel den Verkehr. Ebenso fälschlich ist die Annahme, dass nach einem ersten Match noch weitere Regeln "überschreiben" können; sie tun es nicht. Why each wrong answer fails: Option 1 (korrekt): ACLs werden tatsächlich sequenziell von oben nach unten geprüft; das ist Basisverhalten. Option 2 (falsch): Dies beschreibt ein inkorrektes Modell; in Wirklichkeit stoppt die Verarbeitung bei der ersten passenden Regel — nachfolgende Einträge haben keine Wirkung auf dieses Paket. Option 3 (falsch): Diese Aussage ist genau umgekehrt; ohne explizite denies existiert eine implizite deny, sodass fehlende Permits zu Blockaden führen. Option 4 (korrekt): Die implizite 'deny ip any any' am Ende jeder ACL ist Bestandteil des Cisco-ACL-Verhaltens und erklärt, warum Pakete ohne ausdrückliche Erlaubnis fallen.