Die Management Plane ist das „Steuerpult“ deines Switches: Wer Zugriff auf SSH, VTY und Privileged Exec hat, kann Konfigurationen ändern, VLANs umbiegen, Trunks öffnen oder Logs löschen. Deshalb ist die Absicherung der Management Plane eine der wichtigsten Basismaßnahmen im Netzwerkbetrieb. In der Praxis bestehen robuste Standards aus drei Bausteinen: ausschließlich SSH (keine Klartext-Protokolle), Zugriffsbeschränkung per ACLs (nur Admin-Netze) und AAA (zentrale Authentifizierung/Autorisierung/Accounting) mit sauberem Fallback.
Bedrohungsbild: Was passiert bei unsicherer Management Plane?
Ohne Härtung sind Switches oft über „irgendwelche“ Netze erreichbar, nutzen schwache Passwörter oder erlauben Telnet. Angreifer oder interne Fehlbedienung können so schnell zu großflächigen Ausfällen führen.
- Passwort-Spraying/Brute Force auf VTY
- Abhören von Klartext (Telnet/HTTP)
- Missbrauch lokaler Accounts ohne Audit-Trail
- Fehlende Rollen/Autorisierung (jeder ist „admin“)
Grundsatz 1: Management im eigenen VLAN/VRF und nur aus Admin-Netzen
Der wichtigste Design-Schritt ist Trennung: Management-Zugriff sollte nicht aus Client-VLANs möglich sein. Nutze ein dediziertes Management-VLAN und beschränke Zugriffe auf definierte Admin-Quellnetze.
Management-SVI und Default Gateway (Beispiel Layer-2 Switch)
enable
configure terminal
vlan 99
name MGMT
exit
interface vlan 99
ip address 10.1.99.10 255.255.255.0
no shutdown
exit
ip default-gateway 10.1.99.1
end
Verifikation
show ip interface brief
show running-config | include default-gateway
ping 10.1.99.1
Grundsatz 2: SSH hart konfigurieren (nur v2, starke Schlüssel, keine Klartextdienste)
SSH ist der Standard für Remote-CLI. Deaktiviere Telnet konsequent, erzwinge SSH v2 und nutze lokale oder AAA-basierte Logins. Zusätzlich sollten Timeouts und Login-Blockierung gesetzt werden.
SSH v2 aktivieren (Beispiel)
configure terminal
hostname SW-ACCESS-01
ip domain-name corp.local
crypto key generate rsa modulus 2048
ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 3
end
Telnet deaktivieren und SSH erzwingen
configure terminal
line vty 0 15
transport input ssh
exec-timeout 10 0
login local
end
Optional: Login-Blockierung gegen Brute Force
configure terminal
login block-for 120 attempts 3 within 60
login on-failure log
login on-success log
end
Grundsatz 3: Lokale Accounts sauber setzen (Fallback, nicht „shared enable password“)
Auch wenn du AAA nutzt, brauchst du in der Praxis einen lokalen Fallback-Account für Notfälle (z. B. RADIUS-Ausfall). Nutze secret (gehasht) und klare Rollen.
Lokale User (Beispiel)
configure terminal
username netadmin privilege 15 secret <STARKES_PASSWORT>
enable secret <STARKES_ENABLE_SECRET>
service password-encryption
end
Hinweis zur Praxis
Lokale Accounts sollten selten genutzt werden, aber zuverlässig funktionieren. Dokumentiere den Break-Glass-Prozess und schütze Credentials organisatorisch.
VTY-ACL: Zugriff auf Management-IP strikt begrenzen
Die VTY-ACL ist der zentrale „Türsteher“: Sie entscheidet, aus welchen Quellnetzen überhaupt eine SSH-Verbindung auf die VTY-Lines erlaubt ist. Setze hier konsequent nur Admin-Netze oder Jump-Hosts frei.
Standard ACL für SSH-Zugriff (Beispiel)
configure terminal
ip access-list standard ACL-MGMT-SSH
permit 10.1.99.0 0.0.0.255
deny any
exit
line vty 0 15
access-class ACL-MGMT-SSH in
transport input ssh
end
Verifikation
show access-lists ACL-MGMT-SSH
show running-config | section line vty
AAA einführen: Zentral authentifizieren, autorisieren, protokollieren
AAA (Authentication, Authorization, Accounting) bringt zentrale Kontrolle: Benutzer werden im RADIUS/TACACS+ verwaltet, Privilegien können rollenbasiert vergeben werden, und Logins/Commands können geloggt werden. In Enterprise-Umgebungen wird häufig TACACS+ für Admin-CLI genutzt, RADIUS eher für 802.1X.
AAA-Grundkonzept im Betrieb
- Authentication: Wer bist du? (Login)
- Authorization: Was darfst du? (Privileg/Command-Policy)
- Accounting: Was hast du getan? (Audit-Trail)
AAA mit RADIUS (praxisnahes Beispiel für Login + Fallback)
configure terminal
aaa new-model
radius server AAA-1
address ipv4 10.1.99.20 auth-port 1812 acct-port 1813
key
exit
radius server AAA-2
address ipv4 10.1.99.21 auth-port 1812 acct-port 1813
key
exit
aaa group server radius RAD-ADMIN
server name AAA-1
server name AAA-2
exit
aaa authentication login VTY-AUTH group RAD-ADMIN local
aaa authorization exec VTY-AUTHZ group RAD-ADMIN local
aaa accounting exec VTY-ACCT start-stop group RAD-ADMIN
line vty 0 15
login authentication VTY-AUTH
authorization exec VTY-AUTHZ
accounting exec VTY-ACCT
transport input ssh
exec-timeout 10 0
end
AAA-Serverstatus prüfen
show aaa servers
show running-config | section aaa
show logging | include AAA|RADIUS|AUTH
Optional, aber sinnvoll: Management Plane weiter härten
Neben SSH/ACL/AAA gibt es zusätzliche „Low Effort, High Impact“ Maßnahmen: unnötige Dienste aus, nur sichere Protokolle, saubere Banner/Logging und stabile Zeitbasis.
- HTTP/HTTPS deaktivieren, wenn nicht benötigt
- SNMP nur als v3, sonst nicht (oder strikt per ACL)
- NTP konfigurieren (korrekte Logs/Audit)
- Syslog zentral, Source-Interface auf MGMT
NTP und Syslog (Beispiel)
configure terminal
ntp source vlan 99
ntp server 10.1.99.30
ntp server 10.1.99.31
logging source-interface vlan 99
logging host 10.1.99.70
logging trap notifications
end
Troubleshooting: Wenn SSH/AAA plötzlich nicht mehr funktioniert
Bei Management-Problemen ist die häufigste Ursache eine zu strenge ACL oder fehlende Erreichbarkeit des AAA-Servers. Prüfe immer zuerst L3-Reachability, dann VTY-Config, dann AAA.
- SSH von Admin-Netz nicht erreichbar: VTY-ACL oder Routing/Default-Gateway
- AAA-Login hängt: RADIUS/TACACS nicht erreichbar, Timeout zu hoch
- Nur lokale Logins gehen: AAA-Server down oder Shared Secret falsch
Diagnose-Spickzettel
show ip interface brief
show running-config | section line vty
show access-lists
show aaa servers
show logging | include SSH|AAA|RADIUS|AUTH
Best Practices: Minimaler Management-Plane-Standard (Template)
Dieses Template bildet einen praxistauglichen Mindeststandard: dediziertes Management, nur SSH, VTY-ACL, AAA mit lokalem Fallback, Timeouts und Logging. Passe IPs/Namen/Server an deine Umgebung an.
configure terminal
hostname SW-ACCESS-01
ip domain-name corp.local
aaa new-model
username netadmin privilege 15 secret <BREAKGLASS_SECRET>
enable secret <ENABLE_SECRET>
ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 3
crypto key generate rsa modulus 2048
ip access-list standard ACL-MGMT-SSH
permit 10.1.99.0 0.0.0.255
deny any
exit
line vty 0 15
transport input ssh
exec-timeout 10 0
access-class ACL-MGMT-SSH in
login local
end
login block-for 120 attempts 3 within 60
login on-failure log
login on-success log
end
copy running-config startup-config
Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)
Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.
Was ich (je nach Paket) umsetze
-
Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)
-
Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)
-
Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation
-
Optional Security: Basic ACLs und SSH-Hardening
-
Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)
Sie erhalten
-
✅ Packet Tracer .pkt Datei
-
✅ Saubere Konfigurations-Notizen pro Gerät
-
✅ Verifikations-Checkliste + erwartete Outputs
-
✅ Kurze Dokumentation (wie die Topologie funktioniert)
Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.
Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.
