Unsichere Protokolle ersetzen: Telnet vs. SSH, FTP vs. SFTP
Verstehen Sie, warum Klartextprotokolle wie Telnet, FTP und HTTP Anmeldedaten offenlegen und wie ihre verschlüsselten Alternativen (SSH, SFTP, HTTPS) diese Probleme lösen.
Unsichere Protokolle ersetzen: Telnet vs. SSH, FTP vs. SFTP ist eine kostenlose Security+ Academy-Lektion auf CoddyKit. Dies ist Lektion 1 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Security+ Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Security+ Academy-Kurs umfasst insgesamt 4 Lektionen.
Das Problem mit Klartextprotokollen
Viele grundlegende Internetprotokolle wurden in den 1970er- und 1980er-Jahren entwickelt, als Sicherheit noch keine hohe Priorität hatte. Klartextprotokolle übertragen sämtliche Daten – einschließlich Benutzernamen, Passwörtern und vertraulichen Informationen – im Klartext über das Netzwerk. Jedes Gerät im selben Netzwerksegment sowie jedes System, das die Pakete durchlaufen, kann diesen Datenverkehr mit frei verfügbaren Tools wie Wireshark mitschneiden und lesen. In Umgebungen mit Netzwerk-Switches, die den Datenverkehr zwischen Ports normalerweise isolieren, kann ARP-Spoofing den Datenverkehr auf das System einer angreifenden Person umleiten. Dadurch sind Klartextprotokolle selbst in „internen“ Netzwerken gefährlich.
# What an attacker sees on the wire with Telnet
# (captured via Wireshark or tcpdump)
tcpdump -i eth0 -A port 23
# Sample Telnet capture output:
..login: admin..
..password: S3cr3tPa$$...
..$ ls -la /etc/passwd..
# Every keystroke is visible in plaintext
# Credentials, commands, and file contents - all exposedTelnet im Vergleich zu SSH
Telnet (TCP-Port 23) ermöglicht den Fernzugriff auf die Kommandozeile von Systemen, überträgt jedoch alles im Klartext. Es verfügt über keine integrierte Authentifizierung außer der Anmeldung mit Benutzername und Passwort, die unverschlüsselt übertragen werden. SSH (Secure Shell) (TCP-Port 22) ersetzt Telnet durch einen verschlüsselten und authentifizierten Kanal. SSH verwendet einen asymmetrischen Schlüsselaustausch, um einen Sitzungsschlüssel einzurichten, und verschlüsselt anschließend die gesamte Kommunikation mit symmetrischer Verschlüsselung. SSH authentifiziert außerdem den Server (und verhindert so eine Server-Impersonation) und unterstützt zusätzlich zur Passwortauthentifizierung die Authentifizierung mit öffentlichen Schlüsseln (ohne Passwort, aber sicherer als Passwörter).
# SSH connection (encrypted, server authenticated)
ssh admin@192.168.1.10
# SSH key-based authentication (no password)
ssh -i ~/.ssh/id_rsa admin@192.168.1.10
# Generate SSH key pair
ssh-keygen -t ed25519 -C 'admin@company.com'
# Copy public key to server
ssh-copy-id -i ~/.ssh/id_rsa.pub admin@192.168.1.10
# Disable Telnet on network devices (Cisco IOS)
no service telnet
line vty 0 4
transport input ssh
login localSSH-Schlüsselaustausch und Authentifizierung
Die Sicherheit von SSH beruht auf einem robusten Schlüsselaustauschverfahren. Beim Verbindungsaufbau verifiziert der Client den Hostschlüssel anhand einer lokal gespeicherten Kopie – dadurch wird eine Server-Impersonation verhindert. Wenn sich der Hostschlüssel unerwartet ändert, warnt SSH die Benutzerin oder den Benutzer (ein häufiges Anzeichen für einen Man-in-the-Middle-Angriff). Nach der Verifizierung des Servers kann die Client-Authentifizierung folgendermaßen erfolgen: mit Passwort (bei der Übertragung verschlüsselt, aber anfällig für Brute-Force-Angriffe), mit einem öffentlichen Schlüssel (der Client weist nach, dass er über den privaten Schlüssel verfügt; deutlich sicherer) oder interaktiv über die Tastatur (unterstützt MFA). Organisationen sollten die schlüsselbasierte Authentifizierung erzwingen und die Passwortauthentifizierung bei internetseitig erreichbaren SSH-Diensten deaktivieren.
# Harden SSH server configuration
# /etc/ssh/sshd_config
Port 22
PermitRootLogin no
PasswordAuthentication no # Require key auth only
ChallengeResponseAuthentication no
MaxAuthTries 3
AllowUsers admin deploy
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
ClientAliveInterval 300 # Disconnect idle sessions
ClientAliveCountMax 0
# Restart SSH after changes
systemctl restart sshdFTP im Vergleich zu SFTP und FTPS
FTP (File Transfer Protocol) (TCP-Ports 20/21) überträgt Dateien im Klartext – Zugangsdaten, Befehle und Dateidaten sind vollständig offengelegt. FTP verwendet außerdem einen separaten Datenkanal (im passiven oder aktiven Modus), was Firewallregeln erschwert. SFTP (SSH File Transfer Protocol) tunnelt die Dateiübertragung über SSH auf Port 22 – es unterscheidet sich vollständig von FTP und hat lediglich einen ähnlichen Namen. FTPS (FTP Secure) ergänzt das ursprüngliche FTP-Protokoll um TLS-Verschlüsselung. SFTP wird im Allgemeinen bevorzugt, da es einen einzigen Port verwendet und die Authentifizierung sowie Verschlüsselung von SSH übernimmt. FTP sollte auf allen Produktionssystemen deaktiviert werden.
# SFTP usage (over SSH, single connection)
sftp admin@fileserver.company.com
sftp> put localfile.zip /uploads/
sftp> get /reports/monthly.pdf .
sftp> ls /uploads/
sftp> exit
# Automated SFTP transfer with key auth
sftp -i ~/.ssh/id_rsa admin@fileserver.company.com <<EOF
put /tmp/report.csv /incoming/
EOF
# Disable FTP on Linux (remove vsftpd)
apt purge vsftpd
# Verify no FTP listener:
ss -tlnp | grep ':21'HTTP im Vergleich zu HTTPS
HTTP (TCP-Port 80) überträgt Webinhalte einschließlich Formulardaten, Sitzungscookies und Authentifizierungstokens im Klartext. HTTPS (TCP-Port 443) kapselt HTTP in TLS und bietet Verschlüsselung, Serverauthentifizierung und Datenintegrität. Organisationen sollten HTTPS überall erzwingen: Leiten Sie sämtlichen HTTP-Datenverkehr auf HTTPS um (301-Weiterleitung), implementieren Sie HSTS, um zu verhindern, dass Browser eine Verbindung über HTTP herstellen, und konfigurieren Sie die Cookie-Flags Secure und HttpOnly, um zu verhindern, dass Sitzungstokens über HTTP oder JavaScript gestohlen werden. Moderne Browser kennzeichnen HTTP-Websites als „Nicht sicher“ – HTTPS ist inzwischen die grundlegende Erwartung für alle Webdienste.
# nginx: force HTTPS redirect
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
ssl_certificate /etc/ssl/example.crt;
ssl_certificate_key /etc/ssl/example.key;
add_header Strict-Transport-Security
'max-age=31536000; includeSubDomains; preload';
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options SAMEORIGIN;
}SNMP v1/v2 im Vergleich zu SNMPv3
SNMP (Simple Network Management Protocol) verwaltet Netzwerkgeräte und Server. SNMPv1 und v2c verwenden Community-Strings (im Wesentlichen gemeinsam genutzte Passwörter), die im Klartext übertragen werden – Community-Strings wie „public“ (Lesen) und „private“ (Schreiben) sind Standardwerte, die Angreifende kennen. Wer SNMP-Datenverkehr mitschneidet, erfährt den Community-String und kann Gerätekonfigurationen lesen oder Geräteeinstellungen ändern. SNMPv3 ergänzt eine Authentifizierung (HMAC-MD5 oder HMAC-SHA) und Verschlüsselung (AES) mit benutzerbezogenen Zugangsdaten und ist damit die einzige für Produktionsumgebungen geeignete Version. SNMPv1/v2c sollte deaktiviert werden.
# SNMPv3 configuration (Cisco IOS)
snmp-server group MYGROUP v3 priv
snmp-server user MONITORUSER MYGROUP v3 \
auth sha MyAuthP@ss priv aes 128 MyPrivP@ss
# SNMPv3 query from monitoring server
snmpwalk -v3 -l authPriv \
-u MONITORUSER \
-a SHA -A MyAuthP@ss \
-x AES -X MyPrivP@ss \
192.168.1.1 sysDescr
# Disable SNMPv1/v2c:
no snmp-server community public ro
no snmp-server community private rwLDAP im Vergleich zu LDAPS
LDAP (Lightweight Directory Access Protocol) (TCP-Port 389) authentifiziert und durchsucht Verzeichnisdienste (Active Directory, OpenLDAP) standardmäßig im Klartext, wodurch Zugangsdaten und Verzeichnisdaten offengelegt werden. LDAPS (LDAP über SSL/TLS, TCP-Port 636) verschlüsselt die Verbindung mithilfe eines Zertifikats. StartTLS ist eine Alternative, die eine bestehende LDAP-Verbindung über denselben Port 389 auf TLS hochstuft. Sowohl LDAPS als auch StartTLS bieten Verschlüsselung, LDAPS ist jedoch im Allgemeinen einfacher und zuverlässiger. Organisationen sollten alle LDAP-verwendenden Anwendungen für die Nutzung von LDAPS konfigurieren und unverschlüsseltes LDAP auf Port 389 an der Firewall blockieren.
POP3/IMAP im Vergleich zum verschlüsselten E-Mail-Abruf
Ältere E-Mail-Clients rufen E-Mails über POP3 (Port 110) und IMAP (Port 143) im Klartext ab. Verschlüsselte Alternativen sind: POP3S (Port 995, TLS) und IMAPS (Port 993, TLS). Moderne E-Mail-Plattformen (Exchange Online, Google Workspace) erzwingen TLS für alle Clientverbindungen und unterstützen die tokenbasierte Authentifizierung mit OAuth 2.0 anstelle von Passwörtern. Organisationen sollten die Standardauthentifizierung für E-Mail-Protokolle deaktivieren – die erforderliche moderne Authentifizierung (OAuth 2.0 + MFA) verhindert Credential-Stuffing-Angriffe, die die Klartext-Authentifizierungsmechanismen älterer E-Mail-Protokolle ausnutzen.
# Protocol port reference card
Protocol Insecure Port Secure Port Replacement
--------- ------------ ---------- -----------
Telnet 23 22 SSH
FTP 20/21 22 SFTP
HTTP 80 443 HTTPS
SMTP 25 587/465 SMTPS
POP3 110 995 POP3S
IMAP 143 993 IMAPS
LDAP 389 636 LDAPS
SNMP 161/162 161/162 SNMPv3
RDP 3389 3389 RDP+NLA+TLSErsetzen von Protokollen in der Praxis
Das Ersetzen unsicherer Protokolle erfordert mehr, als lediglich die sichere Version zu aktivieren – die unsichere Version muss aktiv deaktiviert werden. Vorgehensweise: Überprüfen Sie die bestehende Protokollnutzung (Nmap-Scans, Firewallprotokolle), migrieren Sie Anwendungen und Konfigurationen auf das sichere Protokoll, testen Sie gründlich (Geschäftsanwendungen können ausfallen), und blockieren Sie anschließend das unsichere Protokoll an der Firewall und auf dem Host. Häufige Stolpersteine: Ältere Drucker und eingebettete Geräte unterstützen oft nur FTP oder SNMPv2; ältere industrielle Systeme sind möglicherweise auf Telnet angewiesen. Diese Systeme benötigen eine Netzwerkisolierung oder den Austausch durch den Hersteller und nicht lediglich ein Protokoll-Upgrade.
# Audit for insecure protocol usage
# Nmap: find all Telnet listeners on network
nmap -p 23 10.0.0.0/24 --open -sV
# Find FTP listeners
nmap -p 21 10.0.0.0/24 --open
# Find HTTP (not HTTPS) web services
nmap -p 80 --open 10.0.0.0/24
# Check for SNMPv1/v2c community strings
nmap -sU -p 161 --script snmp-info 10.0.0.0/24
# Block Telnet at firewall after migration
iptables -A FORWARD -p tcp --dport 23 -j DROP
iptables -A INPUT -p tcp --dport 23 -j DROPSicherheit des Remote Desktop Protocol
RDP (Remote Desktop Protocol) (Port 3389) wird häufig für die Remoteverwaltung von Windows verwendet und ist ein wichtiges Angriffsziel. Zu unsicheren RDP-Konfigurationen gehören: die Freigabe von Port 3389 im Internet, die ausschließliche Verwendung von passwortbasierter Authentifizierung und die Deaktivierung von NLA. RDP-Härtung: Aktivieren Sie Network Level Authentication (NLA), die vor dem Öffnen der vollständigen Sitzung authentifiziert und nicht authentifizierte Verbindungen blockiert; verlangen Sie TLS 1.2+ für alle RDP-Sitzungen; stellen Sie RDP hinter ein VPN oder RDP-Gateway, anstatt es dem Internet auszusetzen; und erzwingen Sie eine Kontosperrung, um Brute-Force-Angriffe zu verhindern. Viele Ransomware-Kampagnen erlangen ihren ersten Zugriff über exponierte und unzureichend gesicherte RDP-Dienste.
Schrittweise Ablösung unsicherer Protokolle
Die Migration weg von unsicheren Protokollen in Produktionsumgebungen erfordert eine sorgfältige Planung, um Betriebsunterbrechungen zu vermeiden. Ein schrittweises Vorgehen: Phase 1 – Ermitteln: Führen Sie Nmap-Scans durch und prüfen Sie Firewallprotokolle, um alle Verwendungen von Klartextprotokollen zu identifizieren. Phase 2 – Sichere Alternativen aktivieren: Konfigurieren Sie SSH, SFTP und HTTPS parallel zu den bestehenden unsicheren Diensten. Phase 3 – Clients migrieren: Aktualisieren Sie Skripte, Anwendungen, Überwachungstools und Arbeitsabläufe der Benutzerinnen und Benutzer, damit sie das sichere Protokoll verwenden. Phase 4 – Deaktivieren und blockieren: Deaktivieren Sie den unsicheren Dienst auf jedem Host und blockieren Sie den Port an der Firewall. Tests in jeder Phase verhindern Ausfälle in der Produktionsumgebung.
# Phase 4: Disable and block Telnet permanently
# Disable Telnet service on Linux
systemctl stop telnet.socket
systemctl disable telnet.socket
# Block Telnet at iptables
iptables -A INPUT -p tcp --dport 23 -j DROP
iptables -A OUTPUT -p tcp --dport 23 -j DROP
# Save rules
iptables-save > /etc/iptables/rules.v4
# Block at network firewall (Cisco ASA)
access-list OUTSIDE_IN deny tcp any any eq 23
# Verify: should timeout / connection refused
nc -zv 192.168.1.10 23Schnelltest
Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.
Zusammenfassung der Lektion
In dieser Lektion haben Sie Folgendes gelernt: Cleartext-Protokolle (Telnet, FTP, HTTP, SNMPv1/v2c, LDAP) legen Anmeldedaten und Daten für das Abhören des Netzwerkverkehrs offen und müssen ersetzt werden; sichere Ersatzprotokolle (SSH, SFTP, HTTPS, SNMPv3, LDAPS) verwenden TLS- oder SSH-Verschlüsselung, um dieselbe Funktionalität zu schützen; und beim Ersetzen von Protokollen muss die unsichere Version nach einer Prüfung auf Abhängigkeiten älterer Systeme sowohl auf Firewall- als auch auf Host-Ebene deaktiviert werden. Als Nächstes befassen wir uns mit TLS-Versionen, Cipher-Suites und Perfect Forward Secrecy.
Häufig gestellte Fragen
Ist die Lektion „Unsichere Protokolle ersetzen: Telnet vs. SSH, FTP vs. SFTP“ kostenlos?
Ja — der vollständige Text von „Unsichere Protokolle ersetzen: Telnet vs. SSH, FTP vs. SFTP“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Security+ Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Security+ Academy-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Unsichere Protokolle ersetzen: Telnet vs. SSH, FTP vs. SFTP“?
Verstehen Sie, warum Klartextprotokolle wie Telnet, FTP und HTTP Anmeldedaten offenlegen und wie ihre verschlüsselten Alternativen (SSH, SFTP, HTTPS) diese Probleme lösen. Du übst Security+ Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Security+ Academy zu starten?
Keine Vorkenntnisse erforderlich. Security+ Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 1 von 4.
Wie lange dauert die Lektion „Unsichere Protokolle ersetzen: Telnet vs. SSH, FTP vs. SFTP“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Security+ Academy-Lektion Code schreiben und ausführen?
Ja. Jede Security+ Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Unsichere Protokolle ersetzen: Telnet vs. SSH, FTP vs. SFTP
- TLS-Versionen, Cipher Suites und Perfect Forward Secrecy
- Sicheres DNS: DNSSEC und DNS over HTTPS (DoH)
- IPsec, VPN-Protokolle und Sicherheit beim Remotezugriff