Inhaltsverzeichnis
Die Zugangskontrolle für systemausfall.org bezieht sich ausschließlich auf den ssh-Zugang. Dies genügt zur Administration.
Hinweis: im Folgenden bezeichnet NAME den Namen eines Gast-Systems.
Allgemein
Das Ziel unserer Konfiguration ist die weitgehende Minimierung der Zugangsmöglichkeiten. Dabei muss jedoch ein gewisser Komfort für die Administratoren erhalten bleiben.
Ein direkter ssh-Zugriff (von außerhalb des Host-Systems) auf die einzelnen Gast-Systeme ist nicht möglich. Nur das Host-System bietet einen ssh-Zugang an.
Host-System
Der ssh-Server ist direkt von außen zugänglich.
Das Einloggen als root ist per ssh jedoch nicht möglich:
- jeder Administrator hat einen eigenen Account
per su wechseln die Administratoren zum root-Account
Das Einloggen ohne gültigen ssh-key ist von außen nicht möglich:
- als user mittels ssh-key und dem dazu gehörigen Passwort anmelden
- achte auf den richtigen Port (22WC)
Vorteile:
ein Angreifer braucht sowohl ein Nutzer-, als auch das root-Passwort
Privatsphäre für die Admins
- häufigere Passwort-Wechsel der Nutzer leicht umsetzbar
Nachteile:
- mehr login-Accounts
- zwei Passwörter sind notwendig (Komfort!)
Gast-Systeme
Zugang vom Host
- per ssh oder screen
Umsetzung
Das Login in ein Gast-System erfolgt indirekt:
zu jedem Gast-System existiert ein Nutzer im Host-System (Nutzername: uml-NAME)
diese Nutzer erlauben den Zugang nur mittels RSA-Schlüssel
- jeder dieser Nutzer des Host-Systems besitzt einen weiteren RSA-Schlüssel, der ihm den passwort-freien Zugang zu dem dazugehörigen Gast-System gestattet
jedem rsa-Schlüssel, der den Zugang zu einem UML-Nutzer erlaubt, wird in der ~/.ssh/authorized_keys das folgende force-command zugeordnet:
command="sh -c 'ssh -l root ${USER#uml-} $SSH_ORIGINAL_COMMAND'" [hier folgt der dazugehörige rsa-Schlüssel]
damit wird die transparente Weiterleitung von scp-Anforderungen möglich
Diese Methode erlaubt einem böswilligen Angreifer, der sich in einen dieser Gast-System-Accounts einloggen kann, lediglich den Zugriff auf die Daten dieses Gast-Systems auf dem Host, da die Gast-System-Verzeichnisse verschiedenen Nutzern gehören und keinen fremden Zugriff gestatten (Dateirechte).
Zugang von außen
Schlüssel-Import
Um von außen per ssh in ein uml zu gelangen, bedarf es kurzer Vorarbeit.
auf einem sicheren Rechner den RSA-Schlüssel erstellen - passwortgeschützt!:
ssh-keygen -t rsa -b 4096
den öffentlichen Schlüssel (üblicherweise ~/.ssh/id_rsa.pub) zum Host-System kopieren
dann auf dem Host-System einloggen und (als root):
/uml/scripts/admin-uml.sh import-key UML KEYFILE
Fertig!
Nutzung
Ein Administrator, dessen RSA-Schlüssel für den jeweiligen Gast-System-Nutzer gültig ist, kann sich per ssh uml-NAME@systemausfall.org einloggen.
Beim Login in das Host-System wird automatisch die ssh-Verbindung zum passenden Gast-System weitergeleitet.
In kurzen Worten: mensch ist sofort drin, falls sein RSA-Schlüssel akzeptiert wurde. Auch scp ist problemlos möglich.
Nutzung bei mehreren RSA-Schlüsseln
Wenn der Rechner von dem aus du dich einloggen willst mehrere ssh-sec/pub-keys besitzt, hilft folgendes (wie auch im nächsten Punkt beschrieben):
- in .ssh die keys reinkopieren (z.B. ~/.ssh/server1_rsakey)
in .ssh eine config für einen bestimmten server erstellen (z.B. server1_conf)
echo "Host server1" >> ~/.ssh/config echo "IdentityFile ~/.ssh/server1_rsakey" >> ~/.ssh/config
jetzt folgendermaßen einloggen
ssh nutzer@server1
Zugang vom Host-System aus
Die Datei /root/.ssh/config enthält für jedes UML-System einen Eintrag nach dem folgenden Muster:
Host NAME IdentityFile /uml/chrootjail/guests/NAME/.ssh/id_rsa
Der root-Nutzer im Host-System kann durch ein einfaches su NAME seine Identität wechseln. Als jeweiliger Nutzer kann dann per ssh root@uml-hostname (z.B.: ssh root@bastelecke) in das uml gewechselt werden. Dabei wird der ssh-key benutzt, also kein weiteres Passwort abgefragt.
?stimmt das noch?: Somit genügt dem root-Nutzer im Host-System ein einfaches ssh NAME, um passwortfreien Zugang zu dem Gast-System zu erlangen (der passende RSA-Schlüssel wurde durch die ssh-config-Datei automatisch ausgewählt). Diese Zugriffsmethode bleibt den anderen Nutzern verschlossen, da die Dateirechte für die Schlüssel der Gast-System-Nutzer äußerst restriktiv sind.
Diskussion des Sicherheit
Vorteile:
nur ein ssh-Server muss sicher konfiguriert werden
- das Ganze ist ziemlich leicht wartbar (alles wird von Skripten erledigt)
nur ein ssh-Port für alles
mehrere Maintainer eines Gast-Systems müssen kein gemeinsames Passwort verwenden
- die Maintainer müssen sich nicht verschiedene Passworte für die verschiedenen betreuten Gast-System merken
Zugriffe von einem Gast-System zu einem anderen sind nicht möglich, da der notwendige RSA-Schlüssel nur im Host-System liegt - dies beseitigt die übliche Gefahrenquelle des Eintippens von Passworten auf entfernten Systemen (die eventuell von einem Angreifer übernommen wurden - Keylogger!)
- der ausschließliche Zugang mit einem (passwortgeschützten) RSA-Schlüssel ist vergleichsweise sicherer als die Verwendung eines Login-Passworts, da der Angreifer sowohl Zugriff auf deinen Schlüssel, also auch auf dein Passwort benötigt
Nachteile:
das Host-System stellt einen Dienst nach außen hin zur Verfügung -> verwundbar
root auf dem Host-System darf alles (jedoch auch unabhängig von dem ssh-Zugang)
- dank LIDS nicht wirklich relevant (in ferner Zukunft)
- mehrere Login-Accounts auf dem Host-System