17.2 SSH, RDP und sichere Fernadministration im Detail
Fernadministration bedeutet, dass Systeme aus der Ferne verwaltet werden.
Dafür werden Protokolle, Zugriffswege, Benutzerkonten, Berechtigungen und Sicherheitsmaßnahmen kombiniert.
Typische Fernadministration:
- Linux-Server per SSH verwalten
- Windows-Server per RDP verwalten
- Firewall über Weboberfläche konfigurieren
- Switch per SSH administrieren
- NAS oder Router über Managementoberfläche verwalten
- Cloud-Systeme über Portal oder API steuern
- Zugriff über VPN oder Bastion Host absichern
Merksatz:
Fernadministration ist praktisch,
aber sicherheitskritisch.
Warum Fernadministration abgesichert werden muss
Remotezugänge sind besonders interessant für Angreifer, weil sie direkten Zugriff auf Systeme ermöglichen können.
Risiken:
Passwortangriffe
Brute Force
Credential Stuffing
Phishing
gestohlene SSH-Schlüssel
offene RDP-Ports
veraltete Remote-Dienste
fehlende MFA
schwache Firewall-Regeln
kompromittierte Admin-Konten
Merksatz:
Ein unsicherer Fernzugriff kann zum Einstiegspunkt für einen kompletten Angriff werden.
Grundregel für Fernadministration
Adminzugänge sollten nicht unnötig direkt aus dem Internet erreichbar sein.
Besser:
Zugriff über VPN
oder
Zugriff über Bastion Host
oder
Zugriff nur von festen Quell-IP-Adressen
oder
Zugriff über ein getrenntes Managementnetz
Merksatz:
Adminzugänge nicht breit öffentlich bereitstellen.
SSH
SSH steht für:
Secure Shell
SSH ist ein verschlüsseltes Protokoll für entfernten Zugriff auf eine Kommandozeile.
SSH wird häufig genutzt für:
Linux-Server
Unix-Systeme
Netzwerkgeräte
Firewalls
Switches
Router
NAS-Systeme
Git-Zugriffe
Dateiübertragung mit SFTP oder SCP
Standardport:
TCP 22
Merksatz:
SSH ist sicherer Fernzugriff auf die Kommandozeile.
Was SSH schützt
SSH schützt die Verbindung durch Verschlüsselung.
Dadurch werden geschützt:
Zugangsdaten bei der Übertragung
Befehle
Ausgaben
Dateiübertragungen
Sitzungsdaten
Wichtig:
SSH verschlüsselt die Verbindung,
aber schützt nicht automatisch vor schwachen Passwörtern,
gestohlenen Schlüsseln
oder falsch vergebenen Rechten.
Merksatz:
SSH schützt den Transport,
aber nicht jede Fehlkonfiguration.
SSH-Authentifizierung
SSH kann verschiedene Anmeldearten nutzen.
Typisch sind:
Passwortauthentifizierung
oder
Schlüsselbasierte Authentifizierung
Zusätzlich möglich:
MFA
Zertifikatsbasierte SSH-Anmeldung
zentrale Benutzerverwaltung
Zugriff über Bastion Host
Merksatz:
SSH braucht starke Authentifizierung,
nicht nur Verschlüsselung.
SSH mit Passwort
Bei SSH mit Passwort meldet sich ein Benutzer mit Benutzername und Passwort an.
Vorteil:
einfach einzurichten
Nachteile:
anfällig gegen Brute Force
anfällig gegen gestohlene Passwörter
Risiko durch Passwortwiederverwendung
schwierig bei vielen Servern sicher zu verwalten
Merksatz:
SSH-Passwortlogin ist einfach,
aber sicherheitlich schwächer als Schlüsselanmeldung.
SSH mit Schlüsselpaar
Bei SSH mit Schlüsselpaar gibt es zwei Schlüssel:
privater Schlüssel
und
öffentlicher Schlüssel
Der öffentliche Schlüssel liegt auf dem Server.
Der private Schlüssel bleibt beim Administrator.
Nur wer den passenden privaten Schlüssel besitzt, kann sich authentifizieren.
Merksatz:
Öffentlicher Schlüssel auf den Server,
privater Schlüssel bleibt geheim beim Benutzer.
Privater Schlüssel
Der private SSH-Schlüssel ist geheim.
Er darf nicht:
weitergegeben werden
in Git-Repositories liegen
in Tickets kopiert werden
in Chatnachrichten stehen
unverschlüsselt auf fremden Systemen liegen
auf gemeinsam genutzten Netzlaufwerken liegen
Merksatz:
Der private SSH-Schlüssel ist wie ein besonders kritisches Passwort.
Öffentlicher Schlüssel
Der öffentliche SSH-Schlüssel ist nicht geheim.
Er wird auf Systemen hinterlegt, auf die der Benutzer zugreifen darf.
Trotzdem muss er verwaltet werden.
Wichtig:
alte Schlüssel entfernen
Schlüssel Personen zuordnen
Schlüssel bei Austritt löschen
keine unbekannten Schlüssel erlauben
Berechtigungen regelmäßig prüfen
Merksatz:
Öffentliche Schlüssel sind nicht geheim,
aber ihre Zuordnung ist sicherheitsrelevant.
Passphrase für SSH-Schlüssel
Ein privater SSH-Schlüssel sollte mit einer Passphrase geschützt werden.
Vorteil:
Wenn der Schlüssel gestohlen wird,
kann er nicht sofort genutzt werden.
Nachteil:
Benutzer muss Passphrase eingeben
oder sicher mit einem Agent arbeiten.
Merksatz:
Passphrase schützt den privaten Schlüssel zusätzlich.
SSH-Agent
Ein SSH-Agent kann private Schlüssel nach Eingabe der Passphrase temporär bereithalten.
Vorteil:
Benutzer muss Passphrase nicht bei jeder Verbindung neu eingeben.
Risiko:
ein kompromittiertes System kann unter Umständen den Agent missbrauchen.
Merksatz:
SSH-Agent ist praktisch,
muss aber bewusst genutzt werden.
SSH-Agent-Forwarding
SSH-Agent-Forwarding leitet die Authentifizierung über ein Zwischensystem weiter.
Beispiel:
Administrator
→
Bastion Host
→
Zielserver
Risiko:
Wenn der Bastion Host kompromittiert ist,
kann Agent-Forwarding missbraucht werden.
Besser je nach Umgebung:
ProxyJump
kurzlebige Zertifikate
Bastion-Lösung mit Protokollierung
gezielte Schlüsselverwaltung
Merksatz:
Agent-Forwarding nur nutzen,
wenn Risiko und Bedarf klar sind.
SSH über Bastion Host
Ein Bastion Host ist ein geschützter Sprungserver.
Vorteile:
Zielserver müssen nicht öffentlich erreichbar sein.
Zugriff kann zentral protokolliert werden.
Firewall-Regeln werden einfacher.
Adminzugriffe laufen kontrollierter.
Beispielprinzip:
Administrator verbindet sich zuerst zum Bastion Host.
Danach erfolgt der Zugriff auf interne Server.
Merksatz:
Bastion Host schützt interne Systeme vor direktem Adminzugriff aus dem Internet.
SSH ProxyJump
ProxyJump ist eine SSH-Funktion, um über einen Zwischensystem zu einem Zielserver zu gelangen.
Prinzip:
lokaler Rechner
→
Bastion Host
→
Zielserver
Vorteil:
Zielserver muss nur vom Bastion Host erreichbar sein.
Merksatz:
ProxyJump ermöglicht SSH-Zugriff über einen Sprungserver.
Root-Login per SSH
Direkter Root-Login über SSH ist riskant.
Nachteile:
Angreifer kennt den Benutzernamen root.
Aktionen sind schwerer einzelnen Personen zuzuordnen.
Root hat sofort volle Rechte.
Brute-Force-Ziel ist eindeutig.
Besser:
Anmeldung mit persönlichem Benutzerkonto
danach
Rechteerhöhung mit sudo
Merksatz:
Direkten Root-Login vermeiden,
persönliche Konten und sudo nutzen.
sudo bei Fernadministration
sudo erlaubt, einzelne Befehle mit erhöhten Rechten auszuführen.
Vorteile:
Adminrechte nur bei Bedarf
bessere Nachvollziehbarkeit
weniger Risiko durch Alltagssitzungen
gezieltere Rechtevergabe
Protokollierung möglich
Merksatz:
sudo trennt normale Anmeldung und administrative Rechte.
SSH sicher konfigurieren
Wichtige Maßnahmen:
Passwortlogin deaktivieren,
wenn Schlüsselbetrieb sauber eingerichtet ist
direkte Root-Anmeldung deaktivieren
nur benötigte Benutzer erlauben
SSH-Zugriff per Firewall begrenzen
MFA prüfen
starke Schlüssel verwenden
alte Schlüssel entfernen
Loginversuche überwachen
Systeme aktuell halten
Logs auswerten
Merksatz:
SSH-Sicherheit entsteht durch Schlüssel,
Rechte,
Regeln
und Überwachung.
SSH-Logs
SSH-Logs zeigen Anmeldeversuche und Fehler.
Typische Hinweise:
erfolgreiche Anmeldung
fehlgeschlagene Anmeldung
ungültiger Benutzer
falscher Schlüssel
falsches Passwort
viele Versuche von einer IP
Verbindungsabbrüche
Merksatz:
SSH-Logs helfen,
Angriffe und Fehlkonfigurationen zu erkennen.
Typische SSH-Fehlerbilder
Häufige Ursachen:
falscher Benutzername
falscher Hostname
falsche IP-Adresse
Firewall blockiert TCP 22
SSH-Dienst läuft nicht
Schlüssel nicht hinterlegt
falsche Dateirechte beim Schlüssel
privater Schlüssel passt nicht
Root-Login deaktiviert
Passwortlogin deaktiviert
Server-Key hat sich geändert
Merksatz:
SSH-Fehler können an Netzwerk,
Dienst,
Benutzer,
Schlüssel
oder Berechtigung liegen.
Host Key bei SSH
Ein SSH-Server besitzt einen Host Key.
Dieser dient dazu, den Server wiederzuerkennen.
Beim ersten Verbinden wird der Host Key gespeichert.
Wenn sich der Host Key später unerwartet ändert, erscheint eine Warnung.
Mögliche Ursachen:
Server wurde neu installiert
Host Key wurde erneuert
falscher Server wird erreicht
Man-in-the-Middle-Angriff möglich
Merksatz:
SSH-Host-Key-Warnungen nicht blind ignorieren.
RDP
RDP steht für:
Remote Desktop Protocol
RDP ermöglicht grafischen Fernzugriff auf Windows-Systeme.
Standardport:
TCP 3389
Typische Nutzung:
Windows-Server administrieren
Remote-Desktop-Sitzung
Zugriff auf grafische Anwendungen
Fernwartung interner Systeme
Merksatz:
RDP ist grafischer Fernzugriff auf Windows-Systeme.
RDP-Risiken
RDP ist ein häufiges Angriffsziel.
Risiken:
Brute Force
Credential Stuffing
Exploits gegen ungepatchte Systeme
Ransomware-Einstieg
Passwortdiebstahl
fehlende MFA
unsichere Freigabe ins Internet
schwache Kontosperrregeln
Merksatz:
RDP offen im Internet ist ein hohes Risiko.
RDP sicher betreiben
Schutzmaßnahmen:
RDP nur über VPN
RDP Gateway nutzen
MFA nutzen
Network Level Authentication aktivieren
Quell-IP einschränken
starke Passwörter
Account Lockout
Updates einspielen
Adminrechte begrenzen
Logs überwachen
Merksatz:
RDP gehört hinter VPN,
Gateway
oder andere Zugriffsschutzmaßnahmen.
Network Level Authentication
Network Level Authentication wird abgekürzt:
NLA
NLA verlangt Authentifizierung, bevor eine vollständige RDP-Sitzung aufgebaut wird.
Vorteile:
reduziert Angriffsfläche
spart Serverressourcen
erschwert bestimmte Angriffe
Anmeldung erfolgt früher im Verbindungsaufbau
Merksatz:
NLA schützt RDP,
bevor die vollständige Sitzung entsteht.
RDP Gateway
Ein RDP Gateway bündelt RDP-Zugriffe.
Statt viele Systeme direkt per RDP erreichbar zu machen, verbinden sich Benutzer zum Gateway.
Vorteile:
zentraler Zugriffspunkt
bessere Protokollierung
MFA möglich
interne Systeme bleiben privater
Regeln zentral steuerbar
Merksatz:
RDP Gateway reduziert direkte RDP-Erreichbarkeit interner Systeme.
RDP und VPN
RDP sollte häufig nur nach VPN-Verbindung erreichbar sein.
Vorteile:
RDP-Port nicht öffentlich
Benutzer vorher authentifiziert
Zugriff kann auf interne Netze begrenzt werden
MFA kann am VPN greifen
Firewall-Regeln einfacher
Wichtig:
VPN ersetzt keine RDP-Sicherheit.
Benutzerrechte und Logs bleiben wichtig.
Merksatz:
VPN schützt den Zugang,
aber nicht automatisch das Zielsystem.
RDP-Logs
RDP-Zugriffe sollten protokolliert werden.
Zu prüfen:
erfolgreiche Anmeldungen
fehlgeschlagene Anmeldungen
ungewöhnliche Uhrzeiten
unbekannte Quelladressen
viele Fehlversuche
neue Benutzer
Admin-Anmeldungen
Sitzungsabbrüche
Merksatz:
RDP-Logs sind wichtig für Angriffserkennung und Nachvollziehbarkeit.
Webbasierte Administrationsoberflächen
Viele Systeme haben Weboberflächen.
Beispiele:
Firewall
Router
Switch
NAS
Drucker
Hypervisor
Backup-System
Monitoring-System
Cloud-Dienst
Container-Plattform
Merksatz:
Weboberflächen sind bequem,
aber oft sehr mächtig.
Risiken von Admin-Weboberflächen
Typische Risiken:
öffentlich erreichbar
Standardpasswort aktiv
fehlende MFA
veraltete Firmware
unsicheres TLS
schwache Rollenverwaltung
XSS oder CSRF
unsichere Sessionverwaltung
fehlende Logs
Merksatz:
Admin-Weboberflächen nicht ungeschützt bereitstellen.
Admin-Weboberflächen absichern
Maßnahmen:
nur intern erreichbar machen
Zugriff über VPN
Quell-IP beschränken
MFA aktivieren
HTTPS nutzen
gültige Zertifikate einsetzen
Standardkonten deaktivieren
starke Passwörter
Updates einspielen
Rollen begrenzen
Logs aktivieren
Merksatz:
Admin-Weboberflächen brauchen Zugriffsschutz,
Verschlüsselung,
Updates
und Logging.
VPN als Zugriffsschutz
VPN kann Fernzugriff absichern, indem interne Dienste nicht direkt öffentlich erreichbar sind.
Vorteile:
zentrale Authentifizierung
MFA möglich
verschlüsselter Tunnel
interne Adressen bleiben privat
Zugriff über Gruppen steuerbar
Logs zentral auswertbar
Merksatz:
VPN ist ein sicherer Zugangspfad,
aber kein Ersatz für Berechtigungen.
Bastion Host und Jump Server
Bastion Host oder Jump Server dienen als kontrollierter Sprungpunkt.
Typische Eigenschaften:
besonders gehärtet
stark überwacht
nur für Administration gedacht
MFA geschützt
protokolliert Zugriffe
hat eingeschränkten Zugriff auf Zielsysteme
Merksatz:
Bastion Host und Jump Server bündeln administrative Zugriffe.
Managementnetz
Ein Managementnetz trennt administrative Zugriffe vom normalen Benutzernetz.
Darin liegen:
Switch-Management
Firewall-Management
Server-Management
Hypervisor-Management
Storage-Management
Backup-Management
Out-of-Band-Management
Merksatz:
Managementschnittstellen gehören nicht ins normale Clientnetz.
Out-of-Band-Management
Out-of-Band-Management nutzt einen getrennten Verwaltungsweg.
Beispiele:
iLO
iDRAC
IPMI
serielle Konsole
separates Managementinterface
Vorteil:
Zugriff auch bei Störungen des normalen Systems möglich
Risiko:
extrem mächtiger Zugriff
Merksatz:
Out-of-Band-Management besonders stark schützen.
API-Zugriff für Administration
Viele moderne Systeme werden über APIs verwaltet.
Beispiele:
Cloud-APIs
Firewall-APIs
Monitoring-APIs
Backup-APIs
Container-APIs
Automatisierungsschnittstellen
Risiken:
API-Schlüssel gestohlen
Token zu viele Rechte
fehlendes Rate Limiting
unsichere Speicherung
keine Protokollierung
Schlüssel nicht rotiert
Merksatz:
API-Zugänge sind Adminzugänge und müssen genauso geschützt werden.
API-Schlüssel und Tokens
API-Schlüssel und Tokens erlauben Zugriff auf Systeme.
Sie dürfen nicht:
im Quellcode stehen
in öffentlichen Repositories liegen
in Tickets kopiert werden
in Chatverläufen stehen
unverschlüsselt gespeichert werden
dauerhaft ohne Prüfung aktiv bleiben
Merksatz:
API-Schlüssel wie Passwörter behandeln.
Sichere Speicherung von Zugangsdaten
Zugangsdaten sollten sicher verwaltet werden.
Geeignete Mittel:
Passwortmanager
Secret Manager
PAM-System
verschlüsselte Tresore
zentrale Identitätsverwaltung
Zugriff nach Rollen
regelmäßige Prüfung
Ungeeignet:
Textdateien
Excel-Listen ohne Schutz
Screenshots
Chatnachrichten
Notizzettel
Quellcode
gemeinsam genutzte Klartextdokumente
Merksatz:
Zugangsdaten gehören in sichere Verwaltung,
nicht in Klartextablagen.
Least Privilege bei Fernadministration
Fernzugriffe sollten nur die Rechte erhalten, die für die Aufgabe nötig sind.
Beispiele:
Support darf Dienste neu starten,
aber keine Firewall löschen.
Backup-Operator darf Sicherungen prüfen,
aber keine Benutzer anlegen.
Netzwerkadmin darf Switches verwalten,
aber keine Personaldaten lesen.
Merksatz:
Remotezugriff immer nach Aufgabe und Rolle begrenzen.
Zeitlich begrenzte Zugriffe
Administrative Zugriffe sollten möglichst nicht dauerhaft bestehen.
Möglichkeiten:
Just-in-Time-Rechte
temporäre VPN-Gruppen
befristete Dienstleisterzugänge
zeitlich begrenzte Adminrollen
Ablaufdatum für Konten
automatische Deaktivierung
Merksatz:
Dauerhafte Adminrechte erhöhen das Risiko.
Dienstleisterzugänge
Externe Dienstleisterzugänge sind besonders kritisch.
Zu beachten:
klare Freigabe
begrenzte Rechte
zeitliche Befristung
MFA
Protokollierung
keine Sammelkonten
Zugriff nur auf benötigte Systeme
Abschaltung nach Auftrag
vertragliche Regelungen
Merksatz:
Dienstleisterzugänge müssen begrenzt,
überwacht
und wieder entfernt werden.
MFA für Fernadministration
MFA sollte besonders für Remotezugriffe genutzt werden.
Wichtig für:
VPN
Cloud-Portal
RDP Gateway
Admin-Weboberflächen
PAM
Bastion Host
Identitätsdienst
kritische APIs
Merksatz:
Fernadministration ohne MFA ist ein erhöhtes Risiko.
Logging bei Fernadministration
Protokolliert werden sollten:
wer sich angemeldet hat
wann Zugriff erfolgte
von welcher Quelle
auf welches Ziel
welche Aktion ausgeführt wurde
ob Zugriff erfolgreich war
ob Fehler auftraten
welche Rechte genutzt wurden
Merksatz:
Fernadministration muss nachvollziehbar sein.
Session Recording
Session Recording bedeutet:
administrative Sitzungen werden aufgezeichnet.
Möglich bei:
Bastion Hosts
PAM-Systemen
RDP Gateways
SSH-Proxies
Remote-Support-Systemen
Nutzen:
Nachvollziehbarkeit
forensische Analyse
Schulung
Missbrauchserkennung
Merksatz:
Session Recording erhöht Nachvollziehbarkeit bei kritischen Zugriffen.
Timeouts und automatische Trennung
Remote-Sitzungen sollten bei Inaktivität getrennt werden.
Vorteile:
weniger Risiko bei vergessenen Sitzungen
geringere Angriffsfläche
weniger Missbrauch offener Sessions
Beispiele:
SSH-Timeout
RDP-Session-Timeout
VPN-Timeout
Websession-Timeout
Adminportal-Timeout
Merksatz:
Offene Admin-Sitzungen nicht unbegrenzt laufen lassen.
Sperren nach Fehlversuchen
Viele fehlgeschlagene Loginversuche können auf Angriffe hinweisen.
Schutz:
Account Lockout
Rate Limiting
IP-Blockierung
Fail2ban oder vergleichbare Mechanismen
MFA
Alarmierung
Wichtig:
Sperrregeln sinnvoll einstellen,
damit kein einfacher Denial-of-Service gegen Benutzerkonten entsteht.
Merksatz:
Fehlversuche begrenzen,
aber Sperrlogik kontrolliert planen.
Fail2ban als Prinzip
Fail2ban ist ein Beispiel für einen Schutzmechanismus, der Logs auswertet und bei vielen Fehlversuchen Quellen blockieren kann.
Prinzip:
Log prüfen
Muster erkennen
IP-Adresse temporär sperren
Merksatz:
Logbasierte Sperren können Brute-Force-Angriffe bremsen.
Fernadministration und Change Management
Fernadministration sollte nicht bedeuten, dass Änderungen unkontrolliert erfolgen.
Auch remote gilt:
Änderung planen
Risiko bewerten
Wartungsfenster prüfen
Backup oder Snapshot prüfen
Rollback vorbereiten
Änderung dokumentieren
Funktion testen
Logs kontrollieren
Merksatz:
Remoteänderungen brauchen denselben Prozess wie lokale Änderungen.
Fernadministration und Notfallzugriff
Für Notfälle braucht es definierte Zugriffswege.
Beispiele:
Break-Glass-Konto
Out-of-Band-Zugang
Ersatz-VPN
lokale Konsole
Notfallpasswort im Tresor
dokumentierte Wiederherstellung
Wichtig:
Notfallzugang stark schützen
Nutzung protokollieren
regelmäßig testen
nicht im Alltag verwenden
Merksatz:
Notfallzugriff vorbereiten,
aber streng kontrollieren.
Typische Fehler bei Fernadministration
Häufige Fehler:
RDP direkt im Internet offen
SSH mit schwachem Passwort
Root-Login erlaubt
private Schlüssel ungeschützt
alte SSH-Schlüssel nicht entfernt
Admin-Weboberfläche öffentlich
keine MFA
keine Logs
Sammelkonten
Adminrechte dauerhaft vergeben
Dienstleisterzugang nicht deaktiviert
Managementnetz fehlt
API-Schlüssel im Code
Merksatz:
Viele Remoteprobleme entstehen durch Bequemlichkeit und fehlende Kontrolle.
Checkliste: sichere Fernadministration
Remotezugänge erfassen.
Öffentliche Erreichbarkeit prüfen.
Nur notwendige Ports freigeben.
VPN oder Bastion Host nutzen.
MFA aktivieren.
Persönliche Konten verwenden.
Sammelkonten vermeiden.
Admin- und Benutzerkonto trennen.
Least Privilege umsetzen.
SSH-Schlüssel verwalten.
Root-Login vermeiden.
RDP nicht direkt öffentlich machen.
Weboberflächen absichern.
Logs aktivieren.
Fehlversuche überwachen.
Notfallzugänge schützen.
Dienstleisterzugänge befristen.
Änderungen dokumentieren.
Zugriffe regelmäßig prüfen.
Merksatz:
Sichere Fernadministration braucht Technik,
Rechtekonzept,
Protokollierung
und klare Prozesse.
Typische IHK-Fragen
In AP1 und AP2 kann zum Beispiel gefragt werden:
- Was ist SSH?
- Wofür wird SSH verwendet?
- Welchen Standardport nutzt SSH?
- Warum sind SSH-Schlüssel sicherer als reine Passwortanmeldung?
- Was ist der Unterschied zwischen privatem und öffentlichem SSH-Schlüssel?
- Warum sollte der private SSH-Schlüssel geschützt werden?
- Was ist ein SSH Host Key?
- Warum sollte Root-Login per SSH vermieden werden?
- Was ist sudo?
- Was ist RDP?
- Welchen Standardport nutzt RDP?
- Warum sollte RDP nicht direkt aus dem Internet erreichbar sein?
- Was ist Network Level Authentication?
- Was ist ein RDP Gateway?
- Was ist ein Bastion Host?
- Was ist ein Jump Server?
- Was ist ein Managementnetz?
- Was ist Out-of-Band-Management?
- Warum sind API-Schlüssel wie Passwörter zu behandeln?
- Warum ist MFA bei Fernadministration wichtig?
- Warum ist Logging bei Remotezugriffen wichtig?
Typische Prüfungsfallen
SSH ist verschlüsselt,
aber nicht automatisch sicher konfiguriert.
SSH nutzt standardmäßig TCP 22.
RDP nutzt standardmäßig TCP 3389.
RDP offen im Internet ist riskant.
VPN ersetzt keine Benutzerrechte.
MFA ersetzt kein Rechtekonzept.
SSH-Schlüssel brauchen Schutz.
Privater Schlüssel bleibt geheim.
Öffentlicher Schlüssel gehört auf Zielsysteme.
Host-Key-Warnungen nicht blind ignorieren.
Root-Login vermeiden.
sudo kontrolliert Rechteerhöhung.
Bastion Host ist ein geschützter Sprungserver.
Managementnetz vom Clientnetz trennen.
Out-of-Band-Zugriff ist besonders kritisch.
Admin-Weboberflächen nicht öffentlich bereitstellen.
API-Tokens wie Zugangsdaten behandeln.
Dienstleisterzugänge befristen.
Logs müssen aktiv sein,
bevor ein Vorfall passiert.
Session Recording kann Nachvollziehbarkeit erhöhen.
Notfallzugang ist kein Alltagszugang.
Wichtige Begriffe kurz erklärt
| Begriff | Kurze Erklärung |
|---|---|
| Fernadministration | Verwaltung von Systemen aus der Ferne |
| SSH | verschlüsselter Kommandozeilenzugriff |
| SSH-Port | TCP 22 |
| Passwortauthentifizierung | Anmeldung mit Passwort |
| Schlüsselbasierte Authentifizierung | Anmeldung mit Schlüsselpaar |
| privater Schlüssel | geheimer Schlüsselteil beim Benutzer |
| öffentlicher Schlüssel | Schlüsselteil auf dem Server |
| Passphrase | Schutzwort für privaten Schlüssel |
| SSH-Agent | hält Schlüssel temporär bereit |
| Agent-Forwarding | Weiterleitung der SSH-Authentifizierung |
| Bastion Host | geschützter Sprungserver |
| ProxyJump | SSH-Verbindung über Zwischensystem |
| Root-Login | direkte Anmeldung als Root |
| sudo | kontrollierte Rechteerhöhung |
| Host Key | Identität des SSH-Servers |
| RDP | grafischer Windows-Fernzugriff |
| RDP-Port | TCP 3389 |
| NLA | Network Level Authentication |
| RDP Gateway | zentraler RDP-Zugriffspunkt |
| Admin-Weboberfläche | Verwaltungssystem im Browser |
| VPN | verschlüsselter Zugang ins interne Netz |
| Jump Server | Zwischensystem für Administration |
| Managementnetz | getrenntes Verwaltungsnetz |
| Out-of-Band-Management | Verwaltung über separaten Weg |
| API-Zugriff | Administration über Programmierschnittstelle |
| API-Schlüssel | Zugangsschlüssel für API |
| Token | Zugriffsnachweis für Dienste |
| Secret Manager | sichere Verwaltung geheimer Werte |
| PAM | Verwaltung privilegierter Zugriffe |
| Just-in-Time | zeitlich begrenzte Rechte |
| Dienstleisterzugang | externer Administrationszugang |
| Session Recording | Aufzeichnung administrativer Sitzungen |
| Timeout | automatische Trennung bei Inaktivität |
| Account Lockout | Kontosperre nach Fehlversuchen |
| Rate Limiting | Begrenzung von Anfragen |
| Fail2ban | logbasierte Sperre bei Fehlversuchen |
| Break-Glass-Konto | Notfallzugang |
IHK-sichere Kurzformulierung
Fernadministration ermöglicht die Verwaltung von Systemen aus der Ferne, ist aber sicherheitskritisch. SSH dient dem verschlüsselten Kommandozeilenzugriff und nutzt standardmäßig TCP-Port 22. Eine schlüsselbasierte SSH-Anmeldung ist sicherer als reine Passwortanmeldung, wenn der private Schlüssel geschützt und alte Schlüssel entfernt werden. RDP dient dem grafischen Fernzugriff auf Windows-Systeme und nutzt standardmäßig TCP-Port 3389. RDP sollte nicht direkt aus dem Internet erreichbar sein, sondern über VPN, RDP Gateway oder andere Zugriffsschutzmaßnahmen abgesichert werden. Für sichere Fernadministration sind MFA, Least Privilege, persönliche Konten, Logging, Bastion Hosts, Managementnetze, abgesicherte Weboberflächen, geschützte API-Schlüssel und dokumentierte Notfallzugänge wichtig.
Merksätze
Fernadministration ist praktisch,
aber sicherheitskritisch.
Adminzugänge nicht breit öffentlich bereitstellen.
SSH = Secure Shell.
SSH nutzt TCP 22.
SSH verschlüsselt den Transport.
SSH braucht trotzdem sichere Authentifizierung.
Passwortlogin ist einfacher,
aber schwächer.
SSH-Schlüssel bestehen aus privatem und öffentlichem Schlüssel.
Privater Schlüssel bleibt geheim.
Öffentlicher Schlüssel liegt auf dem Server.
Passphrase schützt privaten Schlüssel.
Agent-Forwarding bewusst nutzen.
Bastion Host schützt interne Systeme.
ProxyJump verbindet über Sprungserver.
Root-Login vermeiden.
sudo für kontrollierte Rechteerhöhung nutzen.
SSH-Logs prüfen.
Host-Key-Warnungen ernst nehmen.
RDP = Remote Desktop Protocol.
RDP nutzt TCP 3389.
RDP nicht direkt ins Internet öffnen.
RDP über VPN oder Gateway absichern.
NLA schützt RDP vor vollständigem Sitzungsaufbau.
Admin-Weboberflächen nicht öffentlich bereitstellen.
VPN schützt Zugang,
aber ersetzt keine Rechte.
Managementnetz trennt Verwaltungszugriffe.
Out-of-Band-Management besonders schützen.
API-Schlüssel wie Passwörter behandeln.
Secrets sicher speichern.
Least Privilege auch remote anwenden.
Dienstleisterzugänge befristen.
MFA für Fernadministration nutzen.
Remotezugriffe protokollieren.
Session Recording kann Nachvollziehbarkeit erhöhen.
Timeouts für Admin-Sitzungen setzen.
Fehlversuche begrenzen.
Notfallzugänge streng kontrollieren.
Sichere Fernadministration braucht Technik,
Prozesse
und Kontrolle.