4558
Kommentar: Darstellung unseres Zugangssystems
|
← Revision 13 vom 2012-06-13 21:26:27 ⇥
6112
converted to 1.6 markup
|
Gelöschter Text ist auf diese Art markiert. | Hinzugefügter Text ist auf diese Art markiert. |
Zeile 1: | Zeile 1: |
[[TableOfContents]] | <<TableOfContents>> |
Zeile 5: | Zeile 5: |
Die Zugangskontrolle für ''systemausfall.org'' bezieht sich ausschließlich auf den [wiki:WikiPediaDe/Ssh ssh]-Zugang. Dies genügt zur Administration. | Die Zugangskontrolle für ''systemausfall.org'' bezieht sich ausschließlich auf den [[WikiPediaDe:Ssh|ssh]]-Zugang. Dies genügt zur Administration. Hinweis: im Folgenden bezeichnet ''NAME'' den Namen eines [[UML-Gastsysteme| Gast-Systems]]. |
Zeile 10: | Zeile 12: |
Ein direkter Zugriff auf die einzelnen Gast-Systeme ist nicht möglich. Nur das Host-System bietet einen ''ssh''-Zugang an. |
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. |
Zeile 16: | Zeile 16: |
Der ''ssh''-Server ist direkt nach außen offen. | Der ''ssh''-Server ist direkt von außen zugänglich. |
Zeile 18: | Zeile 18: |
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!) |
|
Zeile 20: | Zeile 36: |
== Zugang vom Host == * per ssh oder screen |
|
Zeile 25: | Zeile 44: |
* diese Nutzer erlauben den Zugang nur mittels [wiki:WikiPediaDe/RSA-Kryptosystem 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 erlauben * die Login-Shell jedes dieser Nutzer ist dieses [SubVersion:/sao/scripts/uml-admin/ssh-login.sh Skript] - jeder Nutzer stellt damit automatisch eine Verbindung zu seinem Gast-System her Diese Methode erlaubt einem böswilligen Angreifer, der sich in eins der Gast-Systeme 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). |
* diese Nutzer erlauben den Zugang nur mittels [[WikiPediaDe:RSA-Kryptosystem|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). |
Zeile 34: | Zeile 55: |
== Schlüssel-Import == | === Schlüssel-Import === Um von außen per ssh in ein uml zu gelangen, bedarf es kurzer Vorarbeit. |
Zeile 39: | Zeile 61: |
1. auf dem Host-System einloggen und dann: {{{ cat PUBLIC_KEY >>/uml/chrootjail/guests/NAME/.ssh/authorized_keys }}} |
1. dann auf dem Host-System einloggen und (als root): {{{ /uml/scripts/admin-uml.sh import-key UML KEYFILE }}} |
Zeile 48: | Zeile 71: |
Beim Login in das Host-System wird automatisch die login-Shell ausgeführt - diese ist wiederum eine ''ssh''-Verbindung zum passenden Gast-System. | Beim Login in das Host-System wird automatisch die ''ssh''-Verbindung zum passenden Gast-System weitergeleitet. |
Zeile 50: | Zeile 73: |
In kurzen Worten: mensch ist sofort drin, falls sein RSA-Schlüssel akzeptiert wurde. | In kurzen Worten: mensch ist sofort drin, falls sein RSA-Schlüssel akzeptiert wurde. Auch ''scp'' ist problemlos möglich. |
Zeile 52: | Zeile 75: |
== Zugang vom Host-System aus === | === Nutzung bei mehreren RSA-Schlüsseln === |
Zeile 54: | Zeile 77: |
Die Datei ''/root/.ssh/config'' für jedes UML-System enthält einen Eintrag nach dem folgenden Muster: {{{ | 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: {{{ |
Zeile 58: | Zeile 91: |
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). | 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. |
Zeile 60: | Zeile 93: |
Diese Zugriffsmethode bleibt den anderen Nutzern verschlossen, da die Dateirechte für die Schlüssel der Gast-System-Nutzer äußerst restriktiv sind. | * ?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. |
Zeile 65: | Zeile 98: |
Unser Zugangsmethode hat natürlich den Nachteil, dass wir einen Dienst des Host-Systems nach außen öffnen und somit das Gesamtsystem verwundbar machen. Die alternative Weiterleitung von ''ssh''-Zugängen der Gast-Systeme auf verschiedenen Ports nach außen ist jedoch schlecht wartbar. Zudem müssen wir uns nicht um die Absicherung der Konfiguration der einzelnen ''ssh''-Server der Gast-Systeme kümmern. Folgende Vorteile bewogen uns außerdem, dieses System umzusetzen: * mehrere [wiki:WikiPediaDe/Maintainer Maintainer] eines Gast-Systems müssen kein gemeinsames Passwort verwenden |
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 [[WikiPediaDe:Maintainer|Maintainer]] eines Gast-Systems müssen kein gemeinsames Passwort verwenden |
Zeile 70: | Zeile 104: |
* 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 - [wiki:WikiPediaDe/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 aufd ein Passwort benötigt |
* 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 - [[WikiPediaDe:Keylogger|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 |
Zeile 74: | Zeile 108: |
* das Host-System stellt einen Dienst nach außen hin zur Verfügung | * das Host-System stellt einen Dienst nach außen hin zur Verfügung -> verwundbar |
Zeile 76: | Zeile 110: |
* dank LIDS nicht wirklich relevant (in ferner Zukunft) | |
Zeile 77: | Zeile 112: |
Insgesamt ist diese Entscheidung aber sicherlich diskussionswürdig :) [[BR]] [dies war eine Einladung!] |
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