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.

1. auf einem sicheren Rechner den RSA-Schlüssel erstellen - passwortgeschützt!:

   ssh-keygen -t rsa -b 4096 

2. den öffentlichen Schlüssel (üblicherweise ~/.ssh/id_rsa.pub) zum Host-System kopieren

3. 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