Cisco 200-301: Netzwerksicherheit und Zugriffskontrolle — Lernleitfaden

By Laurynas Brazys · 14 August 2026 · #cisco #200-301 #certification #exam-prep #study-guide

Teil des Cisco CCNA 200-301 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Cisco-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Netzwerksicherheit und Zugriffskontrolle stellen sicher, dass nur autorisierte Entitäten Netzwerkressourcen auf die beabsichtigte Weise nutzen, während Daten und Dienste vor Kompromittierung oder Unterbrechung geschützt werden. Effektive Designs richten technische Kontrollen an den Kernprinzipien Vertraulichkeit, Integrität, Verfügbarkeit und dem Prinzip der geringsten Rechte (Least Privilege) aus. Die Kontrollen müssen die Management-Ebene (wie Geräte verwaltet werden), die Control-Plane (wie Geräte Adjacencies bilden und Routing-Informationen austauschen) und die Data-Plane (wie der Benutzerverkehr weitergeleitet wird) umfassen, mit gestaffelten Verteidigungsmaßnahmen auf Layer 2, Layer 3 und darüber. Dieser Abschnitt fasst praktische Mechanismen zusammen – AAA, ACLs, Layer-2-Schutzmaßnahmen, VPNs, Firewalls/IPS, Härtung und Betriebsüberwachung – zusammen mit Designüberlegungen, häufigen Fehlermodi und prägnanten Konfigurationsbeispielen.

Sicherheitsprinzipien und Grundlagen der Zugriffskontrolle

• Vertraulichkeit: Verhindert unbefugte Offenlegung. Umgesetzt durch Verschlüsselung während der Übertragung (SSH, IPsec), Verschlüsselung im Ruhezustand (at rest) und bereichsbezogene Zugriffsrichtlinien.
• Integrität: Verhindert unbefugte Veränderung. Erreicht durch kryptografische Prüfungen (HMACs, digitale Signaturen), Konfigurationskontrollen und die Unveränderlichkeit von Audit-Aufzeichnungen.
• Verfügbarkeit: Hält Dienste trotz Fehlern oder Angriffen erreichbar. Realisiert durch Redundanz, Ratenbegrenzung (Rate-Limiting), Policing und resiliente Architekturen, die eine kontinuierliche Konnektivität bei Ausfällen aufrechterhalten.
• Prinzip der geringsten Rechte (Least Privilege): Gewährt die minimal notwendigen Rechte, beschränkt auf Rolle, Gerät, Protokoll, Zeit und Ort. Implementiert durch rollenbasierte Zugriffskontrolle (RBAC), Segmentierung und Autorisierung pro Befehl.

Designüberlegungen:

• Leiten Sie Zugriffsrichtlinien von Geschäftsrollen ab. RBAC auf der Infrastruktur (z. B. network-operator vs. network-admin) reduziert den Schadensradius bei Missbrauch von Anmeldeinformationen und Betriebsfehlern.
• Trennen Sie die Aufgaben (z. B. Security Operations vs. Network Operations). Erzwingen Sie dies durch separate AAA-Gruppen und Befehlsautorisierung.
• Bevorzugen Sie eine „Deny-by-Default“-Haltung. Erlauben Sie explizit beabsichtigte Datenflüsse und Management-Quellen, mit Protokollierung bei Ausnahmen.

Häufige Fallstricke:

• Übermäßige Berechtigungen aus Bequemlichkeit (z. B. pauschal privilege 15). Dies lädt zu lateralen Bewegungen und irreversiblen Fehlern ein.
• Flache Netzwerke ohne Segmentierung. Broadcast-Domänen und undifferenzierte Richtliniengrenzen verstärken Angriffe (z. B. ARP-Spoofing).
• Übermäßig strenge Kontrollen ohne Telemetrie. Fehlende Zähler/Protokollierung erschweren die Fehlerbehebung und können Ausfälle verlängern.

AAA und sicheres Gerätemanagement

AAA-Überblick:

• Authentifizierung überprüft die Identität. Autorisierung bestimmt, was eine Identität tun darf. Accounting zeichnet auf, was wann getan wurde.
• Lokale Authentifizierung: Das Gerät speichert Benutzer und Passwörter. Nützlich für den Notfallzugriff (Break-Glass); skaliert nicht und zentralisiert keine Richtlinien.
• TACACS+: TCP/49, verschlüsselt die gesamte Payload, unterstützt granulare Autorisierung pro Befehl; wird für die Geräteadministration bevorzugt.
• RADIUS: UDP/1812 (Authn/Author), UDP/1813 (Acct), verschlüsselt nur das Passwortfeld; lässt sich gut in 802.1X und den Netzwerkzugriff integrieren, bietet jedoch eine weniger granulare Autorisierung für die CLI.

Typische AAA-Konfiguration mit TACACS+ und lokalem Fallback:

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

Rollenbasierter Zugriff:

• Weisen Sie TACACS+/RADIUS-Attribute den Berechtigungsstufen oder Befehlssätzen des Geräts zu. Verwenden Sie die Autorisierung pro Befehl, um riskante Aktionen einzuschränken (z. B. reload, write, policy-map-Änderungen).
• Validieren Sie RBAC mit Testkonten; stellen Sie sicher, dass das lokale Notfallkonto (Break-Glass) dokumentiert, gesichert und überwacht wird.

Sichere Management-Ebene:

• Bevorzugen Sie SSHv2 für die CLI. Deaktivieren Sie Telnet und ungenutzte Server.

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

• Beschränken Sie das Management auf Out-of-Band- oder dedizierte Management-VLANs/VRFs. Wenden Sie ACLs auf dem SVI oder der physischen Management-Schnittstelle an, um nur autorisierte Quellen zuzulassen.
• Control-Plane Policing (CoPP) zum Schutz von Routing-, Management- und Kontrollprotokollen vor Floods:

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

Überlegungen und Warnhinweise: Verwenden Sie Policing, aber verwerfen Sie nicht pauschal die class-default; eine Fehlklassifizierung kann Routing-Adjacencies oder BFD unterbrechen und Ausfälle verursachen. Beginnen Sie mit großzügigen Raten, beobachten Sie die Zähler und verschärfen Sie sie dann.

Passworthärtung und Geräteintegrität:

• Verwenden Sie enable secret (gehasht) anstelle von enable password.
• Erzwingen Sie eine Mindestlänge und drosseln Sie Anmeldeangriffe:

undefined

undefined

• Bevorzugen Sie lokale Benutzer-Secrets (PBKDF2/scrypt auf unterstützten Plattformen). Beachten Sie, dass service password-encryption ältere Typ-7-Passwörter nur verschleiert.
• Sicherer Start und Konfiguration:

undefined

undefined

• Schützen und versionieren Sie Konfigurationen; erwägen Sie eine regelmäßige Archivierung auf lokalem Speicher und in einem sicheren Remote-Repository. Verwenden Sie SCP oder SFTP für Dateiübertragungen; vermeiden Sie unverschlüsseltes TFTP für sensible Dateien.

Datenverkehrsfilterung mit IPv4/IPv6-ACLs

Grundlagen von IPv4-ACLs:

• Standard-ACLs (1–99, 1300–1999) filtern nur nach der Quell-IPv4-Adresse. Erweiterte ACLs (100–199, 2000–2699) filtern nach Quelle/Ziel, Protokoll und L4-Ports.
• Wildcard-Masken: Ein 0-Bit muss übereinstimmen; ein 1-Bit ist ein „Don’t-Care“-Bit. Berechnet als Inverse der Subnetzmaske (z. B. /24 => 0.0.0.255). Abkürzungen: host 192.0.2.5 entspricht 192.0.2.5 0.0.0.0; any entspricht 0.0.0.0 255.255.255.255.
• Richtung: inbound wird vor dem Routing bei eingehendem Verkehr (Ingress) verarbeitet; outbound wird nach dem Routing bei ausgehendem Verkehr (Egress) verarbeitet. Pakete werden von oben nach unten bis zur ersten Übereinstimmung geprüft; ein implizites deny any beendet die ACL.
• Platzierungsrichtlinien: Platzieren Sie erweiterte ACLs nahe an der Quelle, um unerwünschten Verkehr frühzeitig zu verwerfen; platzieren Sie Standard-ACLs nahe am Ziel, um übermäßiges Blockieren zu vermeiden. Moderne Plattformen verwenden TCAM; dennoch wird Präzision nahe der Quelle bevorzugt.

Beispiele:

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

Nützliche Verfeinerungen: Verwenden Sie remark zur Dokumentation; verwenden Sie established für eine rudimentäre Rückkanal-Erlaubnis bei TCP (begrenzter Sicherheitswert); aktivieren Sie Logging bei deny-Anweisungen nur sparsam, um CPU-Spitzen zu vermeiden.

Prinzipien von IPv6-ACLs:

• Ähnliche Logik, aber IPv6-ACLs sind ausschließlich benannt und werden mit ipv6 traffic-filter angewendet. Ein deny am Ende ist ebenfalls implizit.
• Berücksichtigen Sie immer wesentliche ICMPv6-Typen (Neighbor Solicitation/Advertisement, Router Solicitation/Advertisement, PMTU). Zu restriktive ACLs, die ICMPv6 verwerfen, unterbrechen die Neighbor Discovery (ND) und verursachen Black Holes.

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

Überprüfung und Betrieb:

• show access-lists APP-POLICY und show ipv6 access-lists V6-EDGE-IN, um Trefferzähler (Hit Counter) und Sequenznummern anzuzeigen.
• show ip interface oder show ipv6 interface, um die Zuweisung und Richtung zu bestätigen.
• Testen Sie in kleinem Rahmen vor einer breiten Bereitstellung; ein falsch platziertes deny ip any any kann weitreichende Ausfälle verursachen.

Häufige Fehlerursachen:

• Fehlkalkulationen bei Wildcard-Masken, die unbeabsichtigt zu weit gefasste Übereinstimmungsregeln erstellen.
• Anwendung von ACLs in der falschen Richtung oder auf dem falschen Interface/SVI.
• Weglassen kritischer ICMPv6-Freigaben, was zu Fehlern bei der Neighbor Discovery führt.

Layer-2-Schutzmechanismen, VPNs und Perimeterschutz

Layer-2-Schutzmaßnahmen gegen Bedrohungen:

• DHCP Snooping: Erstellt eine Binding-Tabelle mit IP-MAC-VLAN-Port für per DHCP zugewiesene Adressen; verwirft Antworten nicht autorisierter Server auf nicht vertrauenswürdigen (untrusted) Ports; begrenzt die Rate von Offers/Requests.

undefined

undefined

undefined

undefined

undefined

undefined

Fehlerursachen: Wenn Uplinks zu echten DHCP-Relays/Servern nicht als vertrauenswürdig (trust) konfiguriert werden, schlägt die Adressvergabe fehl; wenn die Binding-Tabelle bei Neustarts nicht gespeichert wird, kann dies DAI/IPSG beeinträchtigen, bis die Leases erneuert werden.

• Dynamic ARP Inspection (DAI): Validiert ARP-Pakete anhand der DHCP-Snooping-Binding-Tabelle (oder statischer Bindings). Verwirft gefälschtes ARP.

undefined

undefined

undefined

Achtung: Statisch adressierte Hosts erfordern statische Bindings; andernfalls kann legitimes ARP verworfen werden.

• IP Source Guard (IPSG): Verwendet Bindings, um pro Port nur gültige Quell-IPs (und optional MAC-Adressen) zuzulassen.

undefined

undefined

undefined

undefined

• Beispiel für ein statisches Binding für ein Gerät mit fester IP:

undefined

VPN-Grundlagen und IPsec-Konzepte:

• Site-to-Site-VPNs verwenden typischerweise IPsec im Tunnel-Modus, um private Subnetze über nicht vertrauenswürdige Netzwerke zu verschlüsseln und zu authentifizieren. Kernelemente: IKE Phase 1 (z. B. IKEv2) zum Aufbau einer ISAKMP SA; Phase 2 zum Aufbau von IPsec SAs mit Transforms (z. B. AES-GCM für den kombinierten Modus oder AES-CBC mit HMAC-SHA2); PFS zur Gewährleistung von Forward Secrecy; Lifetimes zur Erneuerung der Schlüssel; NAT-T über UDP/4500, falls NAT vorhanden ist.
• Remote-Access-VPNs können SSL/TLS-basiert (Client oder clientless) oder IPsec-basiert sein. Split-Tunneling reduziert die Bandbreitennutzung am Headend und verbessert die Benutzererfahrung, erhöht aber die Angriffsfläche; Full-Tunneling zentralisiert die Sicherheitskontrollen auf Kosten von Bandbreite und Latenz.
• Validieren Sie die Path MTU und aktivieren Sie die PMTU Discovery; der durch die Verschlüsselung entstehende Overhead reduziert die effektive MTU und kann ohne korrekte Konfiguration zu Fragmentierung führen.

Firewalls und Intrusion Prevention:

• Firewalls setzen Erlauben/Verweigern mit zustandsbasierter Paketüberprüfung (Stateful Inspection) und Anwendungserkennung (NGFW) durch. Auf Routern ermöglicht eine zonenbasierte Firewall zustandsbasierte Richtlinien zwischen Zonen; ACLs allein sind zustandslos (stateless).
• Ein IPS analysiert den Datenverkehr auf Signaturen, Anomalien oder Verhaltensmuster; ein Inline-IPS kann blockieren, während ein passives IDS nur alarmiert. Feinabstimmung (Tuning) ist unerlässlich, um Fehlalarme (False Positives) zu reduzieren.
• Achten Sie auf symmetrische Verkehrsflüsse über zustandsbasierte Geräte; asymmetrisches Routing zerstört die Zustandstabellen. Positionieren Sie Sensoren dort, wo sie den relevanten Verkehr sehen (z. B. zwischen nicht vertrauenswürdigen und vertrauenswürdigen Zonen).

Sicherheitsbetrieb (Security Operations): Überwachung, Protokollierung und Incident Triage

Audit-Protokollierung und Zeit:

• Uhren für forensische Genauigkeit synchronisieren: ntp server 10.20.20.20 service timestamps log datetime msec localtime show-timezone
• Lokale und Remote-Protokollierung mit angemessenem Schweregrad aktivieren: logging buffered 16384 informational logging host 10.30.30.5 logging trap informational
• Sichtbarkeit von Authentifizierungsereignissen und Befehlsnutzung mit AAA-Accounting erhöhen: aaa accounting commands 15 default start-stop group TAC-GRP
• ACL-Protokollierung bei denies mit Bedacht einsetzen; hochvolumige Protokolle können die CPU-Auslastung in die Höhe treiben. Ziehen Sie Sampling mit NetFlow/IPFIX für das Traffic-Baselining in Betracht.

Workflow für die Incident Triage:

• Erkennen und eingrenzen: Syslog, SNMP-Traps und Flow-Daten verwenden, um anomale Quellen, Ports und Volumina zu identifizieren. Zähler in ACLs, CoPP und auf Schnittstellen korrelieren.
• Eindämmen: Vorübergehend gezielte ACL-denies anwenden, kompromittierte Switch-Ports abschalten oder VLANs unter Quarantäne stellen. Bei DDoS auf der Control Plane das CoPP-Policing anpassen und Upstream-Ratenbegrenzungen oder Blackholing in Betracht ziehen.
• Beseitigen und wiederherstellen: Bösartige Artefakte entfernen, Anmeldeinformationen (einschließlich Schlüssel und Shared Secrets) rotieren, Dienste schrittweise unter Überwachung wieder aktivieren.
• Nach dem Vorfall (Post-Incident): Protokolle/Konfigurations-Snapshots aufbewahren, eine Ursachenanalyse (Root-Cause Analysis) durchführen und präventive Kontrollen kodifizieren (z. B. Layer-2-Schutzmaßnahmen erweitern, RBAC verfeinern).

Häufige betriebliche Lücken:

• Fehlendes NTP führt zu unbrauchbaren Zeitachsen.
• Alles überall zu protokollieren erzeugt Störrauschen; Schweregrad und Filter je nach Geräterolle anpassen.
• Kein getesteter Break-Glass-Prozess verlängert Ausfälle, wenn AAA-Server nicht erreichbar sind.

Praktisches Problemszenario

Die Orion Retail Group muss die Geräteadministration absichern, den Benutzer-zu-Anwendung-Verkehr für IPv4/IPv6 segmentieren, illegale DHCP/ARP-Aktivitäten in den Filialen unterbinden, einen sicheren Fernzugriff für Mitarbeiter ermöglichen und die Sichtbarkeit für die Incident Response verbessern – ohne den Betrieb zu stören.

1. Zentrales AAA mit TACACS+ und lokalem Fallback implementieren

• Konfiguration: TACACS+-Server einrichten; aaa new-model mit der Gruppe TAC-GRP, Authentifizierung/Autorisierung/Accounting definieren; einen lokalen Break-Glass-Benutzer mit privilege-15 erstellen.
• Begründung: Zentralisierte Identitäten und Autorisierung pro Befehl setzen das Prinzip der geringsten Rechte (Least Privilege) durch, liefern Audit-Trails für administrative Aktionen und ermöglichen einen schnellen Widerruf von Anmeldeinformationen. Der lokale Fallback erhält den Zugriff bei Ausfällen des AAA-Servers aufrecht.

2. Management-Zugriff auf SSH migrieren und nach Quelle einschränken

• Konfiguration: RSA-Schlüssel generieren, ip ssh version 2 erzwingen, Telnet deaktivieren, line vty auf transport input ssh mit login authentication default setzen; access-class MGMT_VTY in anwenden, um nur die NOC-Jump-Hosts zuzulassen.
• Begründung: Die Verschlüsselung des Management-Verkehrs verhindert das Abfangen von Anmeldeinformationen; Management-ACLs reduzieren die Angriffsfläche auf eine kleine, bekannte Gruppe von Quellen.

3. Die Control Plane mit konservativem CoPP schützen

• Konfiguration: Eine class-map für SSH, SNMP, NTP erstellen; eine policy-map COPP-POLICY anwenden, die bekannten Management-/Kontrollverkehr überwacht (polices) und class-default ratenbegrenzt; an den control-plane input anhängen.
• Begründung: Die Ratenbegrenzung des Control-Plane-Verkehrs erhält die Verfügbarkeit bei Überlastungsangriffen (Floods) aufrecht, ohne wesentliche Protokolle zu blockieren. Der Beginn mit lockeren Raten vermeidet eine versehentliche Selbstsperrung.

4. Layer-2-Integrität in den Filialen durchsetzen

• Konfiguration: DHCP-Snooping auf Access-VLANs aktivieren, nur Uplinks zum WAN/Relay als vertrauenswürdig (trust) einstufen; Ratenbegrenzungen für request/offer anwenden. DAI auf denselben VLANs aktivieren; statische Bindungen für Geräte mit festen IP-Adressen hinzufügen. IP Source Guard auf Access-Ports aktivieren.
• Begründung: Diese Funktionen blockieren illegale DHCP-Server, ARP-Spoofing und IP-Impersonation am ersten Hop und verhindern so laterale Bewegungen und Man-in-the-Middle-Angriffe.

5. Anwendungen mit präzisen ACLs (IPv4 und IPv6) segmentieren

• Konfiguration: Erweiterte IPv4-ACLs auf zum Zugriff gerichteten Schnittstellen bereitstellen, um nur erforderliche Protokolle zu erlauben (z. B. HTTPS zu den App-Servern) und alles andere zu verweigern/protokollieren. IPv6-ACLs mit expliziten ICMPv6-Erlaubnissen für ND/RA/RS und anwendungsspezifischen permits bereitstellen; mit ipv6 traffic-filter anwenden.
• Begründung: Quellennahe, protokollspezifische Filter minimieren unerwünschten Verkehr und reduzieren die Bandbreitenverschwendung; die Beibehaltung von ICMPv6 stellt sicher, dass Neighbor Discovery und PMTU zuverlässig funktionieren.

6. Sicheren Fernzugriff und Site-to-Site-Verschlüsselung aktivieren

• Konfiguration: IPsec-Site-to-Site-Tunnel im Tunnel-Modus zwischen Filialen und Rechenzentren mit IKEv2, AES-GCM, PFS und Lebensdauern (Lifetimes), die auf die Betriebsfenster abgestimmt sind, aufbauen. Ein SSL/TLS-basiertes Remote-Access-VPN für Mitarbeiter mit Split-Tunneling bereitstellen, um die Last am Headend zu reduzieren, gekoppelt mit Endpoint-Posture-Checks.
• Begründung: Die Verschlüsselung nicht vertrauenswürdiger Pfade schützt die Vertraulichkeit/Integrität; Split-Tunneling schafft eine Balance zwischen Sicherheit und Leistung, wenn es mit Endpoint-Kontrollen kombiniert wird.

7. Firewall und IPS am Perimeter und an der DC-Aggregation bereitstellen

• Konfiguration: Eine zustandsbehaftete (stateful) Firewall-Richtlinie zwischen nicht vertrauenswürdigen, Benutzer- und Server-Zonen implementieren; IPS inline auf kritischen Pfaden mit abgestimmten Signaturen für Einzelhandelsanwendungen positionieren. Pfadsymmetrie sicherstellen oder State-Sharing aktivieren.
• Begründung: Firewalls setzen Zonenrichtlinien auf hoher Ebene durch; IPS erkennt/blockiert Exploits, die Anwendungs- und Protokollschwachstellen ausnutzen. Die korrekte Platzierung und Abstimmung verhindern False Positives und Probleme mit asymmetrischem Zustand.

8. Härtung, Protokollierung und Reaktion verstärken

• Konfiguration: enable secret setzen, Mindestpasswortlänge und Anmelde-Throttling erzwingen; sicheres Boot-Image/Konfiguration aktivieren. NTP, gepufferte und Remote-Syslog-Protokollierung mit dem Schweregrad informational und AAA-Command-Accounting konfigurieren. deny log-Anweisungen sparsam bei wichtigen ACLs hinzufügen. Das Break-Glass-Verfahren testen.
• Begründung: Starke Anmeldeinformationen und Geräteintegrität reduzieren das Kompromittierungsrisiko; synchronisierte, dauerhafte Protokolle und Accounting beschleunigen die Triage. Geübte Wiederherstellungsverfahren minimieren die Ausfallzeit bei Vorfällen.

Durch die Ausführung dieser Schritte in der richtigen Reihenfolge – von der Identitäts- und Management-Ebene über die Layer-2-Härtung, die Segmentierung und den verschlüsselten Transport bis hin zur Perimeter-Inspektion und betrieblichen Sichtbarkeit – erreicht Orion eine mehrschichtige Sicherheit nach dem Prinzip der geringsten Rechte (Least Privilege) mit messbaren Kontrollen und minimaler Unterbrechung.

← Wireless-LAN-Design und Betrieb · Alle Domänen · WAN →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →