Sichere Remote-Administration von Cisco-Routern: Bastion, Jump Host und MFA-Überlegungen

Sichere Remote-Administration von Cisco-Routern bedeutet: Managementzugriff ist nicht „aus dem Internet per SSH“, sondern ein kontrollierter, auditierbarer Pfad über eine Bastion (Jump Host), starke Authentifizierung (MFA) und strikte Netzwerk-Policies. In Enterprise-Umgebungen ist das Ziel, Angriffsfläche zu minimieren und gleichzeitig den Betrieb zu ermöglichen: Admins arbeiten über einen zentralen Zugriffspunkt, Sessions sind nachvollziehbar (AAA/Accounting), und direkte Zugriffe aus Benutzer-Netzen oder aus dem Internet sind ausgeschlossen. Dieser Leitfaden beschreibt ein praxistaugliches Bastion-/Jump-Host-Design, MFA-Überlegungen und die wichtigsten Cisco-Konfigurationsbausteine für die Management Plane.

Zielbild: Was eine sichere Remote-Admin-Architektur leisten muss

Eine gute Architektur trennt klar zwischen Nutzerzugriff und Adminzugriff. Sie erzwingt Identität, reduziert offene Ports und liefert Evidence für Audits und Incident-Analysen.

• Kein direkter SSH-Zugriff aus dem Internet auf Router
• Ein definierter Zugriffspfad (Bastion/Jump Host) mit MFA
• MGMT-Netz separat, Router-Management nur aus MGMT
• AAA/Accounting für Nachvollziehbarkeit (wer hat was wann getan?)
• Notfallzugang (OOB/Console) dokumentiert und getestet

Architekturmuster: Bastion vs. Jump Host (Begriffe sauber trennen)

„Jump Host“ ist oft der Server, über den Admins springen. „Bastion“ bezeichnet das gehärtete, besonders geschützte System, das als einziger Eintrittspunkt dient. In der Praxis sind Jump Host und Bastion häufig identisch.

• Jump Host: technische Sprungstation (SSH/RDP) ins Managementnetz
• Bastion: gehärteter Eintrittspunkt mit Logging, MFA und restriktiven Policies
• Empfehlung: 1–2 Bastions (HA) + zentraler AAA-Backend

Netzwerk-Blueprint: Der sichere Zugriffspfad (Referenz)

Das Grundmuster ist: Admin → VPN/ZTNA → Bastion → Managementnetz → Router. Die Router akzeptieren Managementzugriff nur aus dem Managementnetz (oder sogar nur aus Bastion-IPs).

• Admin-Client: kein direkter Zugriff auf Router
• Zugangsschicht: VPN oder ZTNA (mit MFA)
• Bastion: zentrale Session-Quelle, optional Session-Recording
• MGMT-Netz: isoliertes Segment, keine Route in User/Guest/IoT
• Router: SSH-only, VTY Access-Class nur MGMT/Bastion

MGMT-Segmentierung: Warum ein separates Managementnetz Pflicht ist

Ein Managementnetz verhindert, dass kompromittierte Clients direkt Router erreichen. Es ist die wichtigste Netzmaßnahme, noch vor MFA. In Multi-Site-Umgebungen wird MGMT oft als eigenes VLAN pro Standort plus zentrale Erreichbarkeit umgesetzt.

• MGMT-VLAN pro Standort, IP-Plan standardisiert
• Router-Management-IPs nur im MGMT-VLAN (keine „Users-IP als Admin-IP“)
• ACLs: Users/Guest/IoT dürfen MGMT nie erreichen
• Option: Zugriff ausschließlich aus Bastion-IP(s)

SSH-Baseline auf dem Router: sichere Defaults

Auf dem Router muss SSH sauber konfiguriert sein: SSHv2, starke Keys, keine unsicheren Managementservices und klare Session-Timeouts.

• SSHv2 aktiv, Schlüssel ausreichend stark
• Telnet aus, HTTP/HTTPS aus (wenn nicht zwingend nötig)
• Exec-Timeout gegen offene Sessions
• Login über AAA (wenn verfügbar)

CLI: SSH-Mindestkonfiguration

ip domain-name example.local
crypto key generate rsa modulus 2048
ip ssh version 2
no ip http server

no ip http secure-server

VTY-Restriktion: Zugriff nur aus Bastion/MGMT (Mindeststandard)

Setzen Sie eine Access-Class auf den VTY-Lines. Dadurch wird SSH auf Routerebene nur von definierten Quellnetzen akzeptiert. Das ist unabhängig von VPN/MFA eine harte Sicherheitsbarriere.

CLI: MGMT_ONLY ACL + VTY (Beispiel)

ip access-list standard MGMT_ONLY
 permit 10.10.10.0 0.0.0.255
 deny any
line vty 0 4

transport input ssh

access-class MGMT_ONLY in

exec-timeout 10 0

login authentication default

Verifikation VTY-Zugriff

show running-config | include line vty|access-class|transport input
show access-lists MGMT_ONLY

AAA-Integration: zentrale Identität und Audit

MFA sitzt in der Praxis häufig vor der Bastion (VPN/ZTNA) oder auf der Bastion selbst. Auf Routerseite sorgt AAA dafür, dass Benutzeridentitäten und Befehle auditierbar sind.

• Authentication: TACACS+/RADIUS, fallback local (Break-Glass)
• Authorization: Rollen/Command-Controls (RBAC über AAA)
• Accounting: Exec und Commands für Audit und Forensik

CLI: AAA/TACACS+ (Muster)

aaa new-model
tacacs server TACACS1

address ipv4 10.10.10.10

key 
aaa authentication login default group tacacs+ local

aaa authorization exec default group tacacs+ local

aaa accounting exec default start-stop group tacacs+

aaa accounting commands 15 default start-stop group tacacs+

MFA-Überlegungen: Wo MFA sinnvoll umgesetzt wird

Router unterstützen MFA nicht „nativ“ wie moderne IdP-Apps. In Enterprise-Designs wird MFA daher an einer vorgelagerten Stelle erzwungen: VPN/ZTNA, Bastion-Login oder AAA-Proxy. Das Ziel ist ein MFA-Gate vor dem Managementnetz.

• Option A: MFA am VPN/ZTNA (empfohlen, zentraler Zugriffspunkt)
• Option B: MFA am Bastion-Login (RDP/SSH mit MFA)
• Option C: MFA via AAA-Proxy/IdP-Integration (abhängig von Tooling)
• Regel: Kein direkter Routerzugang ohne vorherige MFA-Schicht

Session-Handling: Least Privilege, Recording und Zeitbegrenzung

Eine Bastion ermöglicht zusätzliche Kontrollen, die Router allein nicht leisten: Session-Recording, Ticketbindung und zeitlich begrenzte Freischaltungen. Das ist besonders wichtig für Audits.

• RBAC: ReadOnly/Ops/NetEng Rollen, keine Shared Accounts
• Session Recording: optional für kritische Umgebungen
• Just-in-Time Access: zeitlich begrenzter Zugriff statt Dauerfreigabe
• Ticketbindung: Zugriff nur mit Change/Incident-ID

Schutz der Management Plane: zusätzliche Router-Bausteine

Neben VTY-Restriktion erhöhen weitere Maßnahmen die Robustheit der Management Plane: NTP/Syslog (Audit), Discovery aus und optional Control Plane Protection (CoPP) gegen Control-Plane-Last.

• NTP synchronized + Syslog zentral (Pflicht)
• Discovery auf WAN deaktivieren (z. B. CDP)
• Optional: CoPP für SSH/SNMP/ICMP (plattformabhängig)

CLI: Audit-Readiness (NTP/Syslog)

service timestamps log datetime msec
ntp server 192.0.2.10 prefer
logging host 192.0.2.20
logging trap informational

Notfallzugang: OOB/Console als Teil der Security

Ein sicherer Betrieb braucht einen Notfallpfad, der unabhängig vom Produktionsnetz ist. Das verhindert riskante „temporäre Öffnungen“ im Incident und ist ein Pflichtpunkt in Enterprise-Runbooks.

• OOB/Console oder Remote Hands für den Worst Case
• Break-Glass Account lokal, streng verwaltet und rotiert
• Dokumentation: Ablauf, Kontaktkette, Zeiten, Evidence

Abnahme (UAT): Tests, die sichere Remote-Administration belegen

Die Architektur gilt erst als abgenommen, wenn Zugriffspfade getestet sind: Admin erreicht Router nur über Bastion, MFA ist erzwungen, Logs sind nachvollziehbar, und unautorisierte Quellen werden geblockt.

• Test 1: Direkter SSH aus Users/Internet scheitert (blocked)
• Test 2: Zugriff über VPN/ZTNA mit MFA funktioniert
• Test 3: Bastion → Router SSH funktioniert, RBAC greift
• Test 4: AAA/Accounting erzeugt nachvollziehbare Logs

CLI: Evidence-Set (Copy/Paste)

show ip ssh
show access-lists MGMT_ONLY
show running-config | include line vty|access-class|transport input
show ntp status
show logging | last 50

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.