Telnet abschalten: Router-Härtung nach Best Practice

Telnet ist aus Security-Sicht nicht mehr vertretbar, weil Benutzername, Passwort und Befehle unverschlüsselt übertragen werden. Auf Cisco Routern gehört das Abschalten von Telnet zu den schnellsten und wirkungsvollsten Hardening-Maßnahmen. Best Practice ist: SSHv2 aktivieren, Telnet auf allen VTY-Lines verbieten, Management-Zugriff per ACL einschränken und optional AAA (TACACS+/RADIUS) nutzen. Diese Anleitung zeigt ein sauberes Vorgehen ohne Lockout-Risiko.

Warum Telnet ein Sicherheitsrisiko ist

Telnet überträgt alles im Klartext. Jeder, der den Traffic mitschneiden kann (z. B. im gleichen LAN/VLAN oder über kompromittierte Geräte), kann Credentials lesen und Sessions übernehmen.

• Keine Verschlüsselung (Credentials im Klartext)
• Kein Schutz gegen Session-Hijacking
• Verstößt gegen gängige Compliance-Standards

Safe Change Ablauf: Erst SSH sicherstellen, dann Telnet deaktivieren

Der häufigste Fehler ist, Telnet zu blocken, bevor SSH funktioniert – das führt zum Lockout. Die sichere Reihenfolge ist: Management-IP erreichbar, SSHv2 aktiv, Login getestet, dann Telnet abschalten.

• 1) SSHv2 einrichten und testen
• 2) VTY nur SSH erlauben
• 3) Zugriff per ACL begrenzen
• 4) Änderungen speichern

Schritt 1: SSHv2 aktivieren (Voraussetzungen)

Für SSH brauchst du Hostname, Domain-Name, einen lokalen User und RSA-Keys. Danach erzwingst du SSH Version 2.

Hostname, Domain, User, RSA-Key

Router# configure terminal
Router(config)# hostname R1
R1(config)# ip domain-name lab.local
R1(config)# username netadmin privilege 15 secret Str0ngP@ssw0rd!
R1(config)# crypto key generate rsa modulus 2048
R1(config)# ip ssh version 2
R1(config)# end

SSH-Parameter optional härten

R1# configure terminal
R1(config)# ip ssh time-out 60
R1(config)# ip ssh authentication-retries 2
R1(config)# end

Schritt 2: VTY-Lines auf SSH-only setzen (Telnet abschalten)

Telnet wird auf Cisco Routern über transport input gesteuert. Setze auf allen VTY-Lines transport input ssh und nutze login local oder AAA.

VTY 0–4 (oder 0–15) auf SSH-only

R1# configure terminal
R1(config)# line vty 0 4
R1(config-line)# login local
R1(config-line)# transport input ssh
R1(config-line)# exec-timeout 10 0
R1(config-line)# end

Wenn dein Router 0–15 hat

R1# configure terminal
R1(config)# line vty 0 15
R1(config-line)# login local
R1(config-line)# transport input ssh
R1(config-line)# exec-timeout 10 0
R1(config-line)# end

Schritt 3: Management-Zugriff per ACL einschränken

SSH-only ist gut, aber „SSH aus dem ganzen Netz“ ist oft unnötig. Begrenze VTY-Zugriff auf definierte Admin-Netze oder einen Jump Host. Das reduziert Brute-Force-Risiko und Fehlbedienung.

Standard-ACL für Admin-Netz

R1# configure terminal
R1(config)# ip access-list standard VTY_MGMT
R1(config-std-nacl)# permit 192.168.10.0 0.0.0.255
R1(config-std-nacl)# deny any
R1(config-std-nacl)# end

ACL an VTY binden

R1# configure terminal
R1(config)# line vty 0 4
R1(config-line)# access-class VTY_MGMT in
R1(config-line)# end

Schritt 4: Verifikation (bevor du speicherst)

Teste SSH von einem Client und prüfe, ob Telnet wirklich nicht mehr möglich ist. Danach prüfst du die VTY-Konfiguration und SSH-Status am Router.

Router-seitige Checks

R1# show ip ssh
R1# show running-config | section line vty
R1# show access-lists VTY_MGMT
R1# show users

Client-Tests

Client$ ssh netadmin@192.168.10.1
Client$ telnet 192.168.10.1

Zusätzliche Hardening-Bausteine (Best Practice)

Wenn du das Management wirklich „sauber“ härten willst, ergänzen sich diese Maßnahmen gut mit Telnet-Abschaltung.

• Nur SSHv2: ip ssh version 2
• Kein unnötiger Zugriff: VTY per access-class begrenzen
• AAA mit TACACS+/RADIUS statt lokale User (Produktion)
• Login-Block bei Brute-Force (je nach IOS): login block-for
• Banner/Legal Notice und Logging

Beispiel: Brute-Force-Schutz (wenn unterstützt)

R1# configure terminal
R1(config)# login block-for 120 attempts 3 within 60
R1(config)# end

Typische Fehler und Lockout-Vermeidung

Lockouts entstehen meist durch eine ACL, die das eigene Admin-Netz nicht matcht, oder durch das Abschalten von Telnet, bevor SSH wirklich funktioniert. Plane deshalb immer einen Fallback (Console/OOB) oder teste in einem parallelen SSH-Session.

• ACL falsch (Wildcard/Netz) → SSH auch blockiert
• VTY-Ranges unvollständig (0–4 geändert, aber 5–15 bleibt offen)
• RSA-Key fehlt → SSH startet nicht
• transport input ssh nicht gesetzt → Telnet bleibt aktiv

Quick-Checks

show ip ssh
show running-config | section line vty
show access-lists
show users
show logging

Konfiguration speichern

Wenn SSH funktioniert und Telnet-Verbindungen abgewiesen werden, speichere die Konfiguration.

R1# 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.