Got root?

Ein Kunde von uns sorgte neulich für Verwirrung, weil wir uns auf seinen Servern mit einem Mal nicht mehr einloggen konnten. Auf Nachfrage stellte sich dann heraus: Der Kunde hatte gerade eine neue Policy eingeführt und den Root-Account deaktiviert — und war noch nicht dazu gekommen uns zu informieren. Alles halb so wild, war ja glücklicherweise aufgefallen bevor irgendwas ausgefallen war und wir schnell auf die Server hätten zugreifen müssen/sollen. Aber es ergab sich dann doch eine Diskussion über den Sinn und Unsinn dieser Policy und da ich hier etwas länger an meiner Position dazu gefeilt habe, wollte ich sie hier nochmal wiedergeben.

Um unsere Sicht auf diese Dinge zu verstehen, sollte ich zunächst einmal erläutern, wie die Frage des administrativen Zugriffs bei uns gehandhabt wird:

  • Jeder von uns hat einen SSH-Key, den er für die Arbeit verwendet. Unsere SSH-PublicKeys sind auf all unseren Servern beim Root-Account hinterlegt. Sollte einer von uns gehen oder einer der SSH-PrivateKeys kompromitiert werden, müssen wir den PublicKey auf allen von uns administrierten Servern austauschen bzw. entfernen. (Was wir dann wohl mit parallel-ssh tun würden.) Macht eine Menge Arbeit, aber Dinge die selten vorkommen dürfen auch mehr Arbeit machen als Dinge die oft vorkommen. Wenn es irgendwann häufiger vorkommen sollte, werden wir es besser automatisieren.
  • SSH ist so konfiguriert, dass Logins als Root nur mit SSH-Keys möglich sind, keinesfalls mit dem Root-Passwort.
  • Keiner von uns hat individualisierte Accounts und dementsprechend auch keine Passwörter dazu. Solange der Login per SSH mit Key funktioniert, vermeiden wir Passwörter wo immer es geht. Passwörter häufig eintippen macht irgendwann bekloppt und deswegen führt das nur zu einfachen Passwörtern oder der Verwendung der Zwischenablage — letzteres führt wiederum zu sehr häufiger Verwendung desselben Passworts.
  • Wir pflegen eine GPG-verschlüsselte Liste mit den Root-Passwörtern für alle von uns betreuten Server. Diese Passwörter brauchen wir beinahe ausschließlich für den Login auf Konsolen oder wenn der SingleUserMode ein Passwort verlangt. Es gibt kein einheitliches Root-Passwort, außer bei Kunden die das entgegen unserem Rat bei all ihren Servern so wollen. Allerdings vermeiden wir aufgrund der leider allzu häufigen Problematik Sonderzeichen auf Konsolen einzugeben wo es geht diese Zeichen und wählen dafür eher lange alphanumerische Passwörter. (Ich vergebe z.B. nie Passwörter mit weniger als 23 Zeichen und bevorzuge eher 42 Zeichen. Diese Passwörter werden nur ganz selten gebraucht und können meist über die Zwischenablage kopiert werden, sie dürfen ruhig lang sein.)
  • Wir arbeiten auf Servern meist als root, weil wir keinen Vorteil darin sehen es nicht zu tun.

Soweit erstmal zum Admin-Zugriff und wie wir das handhaben und absichern. Bleibt die Frage, ob als Root gearbeitet werden sollte und wenn nicht warum. Das wiederum geht zurück auf die weit verbreitete Proklamation, dass der Root-Account in irgendeiner Weise eine generelle konzeptionelle Schwäche bei Unix sei und abgeschafft werden sollte. Das sehe ich explizit nicht so. Insbesondere finde ich, dass administratives Arbeiten auf einem Unix-System ohne Root-Account sehr schnell zu einer Plage wird, denn in der Regel läuft das dann immer auf sudo-Orgien und endloses Passwort-Eintippen hinaus (oder auf „sudo -i“).

(Ich will hier übrigens nicht über sudo herziehen oder davon abraten. Für unerfahrene User ist sudo meiner Ansicht nach genau das richtige, besonders wenn sie nicht „sudo -i“ verwenden. Es hilft Schusseligkeitsfehler zu vermeiden und vermittelt ein Gefühl dafür, welche Eingriffe größeres Gewicht haben. Aber es geht hier auch um die Handhabung von Servern. Unerfahrene User sollten keine Server administrieren, auch nicht mit sudo. Ich bin davon überzeugt, weil ich selbst mal ein unerfahrener User war und mich an die Lektionen auf dem Weg zum erfahrenen User erinnere.)

Das Problem mit dem root-Account aus meiner Sicht ist weniger, dass Admins damit arbeiten, als vielmehr dass das System damit arbeitet. Mittlerweile ist es glücklicherweise üblich geworden, dass nahezu alle Dienste entweder ohne Root-Rechte starten können oder einen Mechanismus enthalten, um nach dem Starten ihre Root-Rechte aufzugeben. Aber warum brauchen bestimmte Dienste beim Starten Root-Rechte? In den meisten Fällen entweder weil sie a) Kernel-Module laden müssen (oder ähnlich gewichtige Dinge tun müssen) oder b) sich an einen privilegierten Port binden müssen. Das mit den Kernel-Modulen lässt sich oft anders lösen und wird inzwischen meist auch umgangen. Das mit den Ports ist nach wie vor ein Problem. Warum braucht ein Webserver-Dienst beim Starten root-Rechte um sich an Port 80 binden zu dürfen? Eigentlich will man doch nur sicherstellen, dass ausschließlich der Dienst dem man das erlaubt hat sich an diesen Port bindet. Das ist mit den Root-Rechten streng genommen nichtmal erfüllt. Es wäre durchaus denkbar, dass sich ein anderer mit Root-Rechten startender Dienst an diesen Port bindet, obwohl er es gar nicht soll. Hier fehlt es Linux (genauso wie allen anderen mir bekannten unixoiden Betriebssystemen) an einer vernünftigen Lösung.

Dann gibt es noch ein paar andere Problembereiche, z.B. dass nur der Root-User Netzwerkinterfaces wie z.B. tun/tap-Devices aktivieren kann. Statt hier einem VPN-Dienst (der ein Primärziel für Attacken ist) beim Starten Root-Rechte zu geben die er erst abgeben muss, wäre es gewiss sinnvoller dem von diesem Dienst genutzten Account ein Sonderprivileg einzuräumen, um eben genau diese Art Interfaces (und keine anderen) aktivieren zu können. (Nebenbei: es fehlt auch an einem Mechanismus um zu überprüfen, ob ein Dienst tatsächlich wie verlangt nach dem Starten seine Rechte gedroppt hat.)

Warum aber sollten Admins nicht als root arbeiten?

Das vielleicht offensichtlichste Argument dagegen wäre wohl: Wer als Root arbeitet, kann als Root auch viel kaputt machen. — Ja, aber mit sudo geht das auch. Wer ständig Dinge tut die sudo erfordern, wird sich irgendwann angewöhnen nahezu jeden Befehl mit sudo zu beginnen oder eben „sudo -i“ zu verwenden. Diese „Schutzwirkung“ von sudo ist dann auch dahin. Admins sind hier letztlich nichts anderes als Spezialisten die eben wissen, wie sie mit ihren zum Teil gefährlichen Werkzeugen umzugehen haben ohne sich oder anderen Schaden zuzufügen.

Eines der häufigeren Argumente dagegen ist, dass das Root-Passwort über unsichere Kanäle eingegeben werden könnte. — Das trifft auf uns aber nicht zu. Wir verwenden kein telnet, wir verwenden kein FTP, wir schließen den Root-User bei solchen Diensten sogar explizit aus, wenn die Dienste das zulassen. Und wir erlauben bei SSH keinen Root-Login per Passwort. Wo wir gezwungen sind auf schwache Dienste zurückzugreifen (etwa: telnet-Zugriff auf Switche), umgehen wir die Schwäche indem wir den Zugriff nur über ein internes Netz hinter einem VPN erlauben.

Dann besteht noch die Gefahr, dass das Passwort kompromitiert wird. — Die können wir nicht eliminieren, wir können sie nur die Konsequenzen minimieren, indem wir für jeden Host ein anderes Passwort verwenden. Hin und wieder ändern wir die Passwörter auch. Letztlich kann aber eben auch ein SSH-Key verloren gehen und muss dann eben auch ausgetauscht werden. Eine weitere Maßnahme, über die wir bereits nachdenken, wäre das Aufteilen der GPG-Passwortliste in mehrere Listen, auf die auch nicht jeder von uns Zugriff hat. Das war bisher nicht nötig und sinnvoll, da bei uns bisher immer alle gleichermaßen für alle Server und Kunden zuständig waren, aber je mehr MitarbeiterInnen wir dazu bekommen, desto attraktiver wird dieser Schritt.

Hingegen vermehren sich die Probleme ohne Root-Account. Ich versuche das mal an einem typischen Beispiel gegenüber zu stellen:

Server geht in die Knie, SSH reagiert nicht, wir versuchen Zugriff über einen anderen Weg zu bekommen. Das ist in der Regel die virtuelle Konsole bei virtualisierten Hosts, oder es ist eine Art emulierte Konsole via KVM oder Serial-Over-LAN, beides in der Regel als Payload in einer verschlüsselten IPMI-Verbindung, oder eben eine richtige KVM-Verbindung über ein entsprechendes Gerät, auf das wiederum verschlüsselt zugegriffen wird.

Mit Root-Login: Root-Passwort aus der PW-Liste suchen, Konsole aufrufen, „root“ und Passwort auf der Konsole eingeben (oder besser: aus der Zwischenablage, wenn sie denn funktioniert), hoffen dass der Host noch in der Lage ist einen hereinzulassen, damit man was unternehmen kann.

Ohne Root-Login: User- und ggf. Root-Passwort aus der PW-Liste suchen, Konsole aufrufen, Username und Passwort eingeben, hoffen, dass der Host einen noch rein lässt. Dann „sudo -i“ und User-Passwort oder „su -l“ und Root-Passwort eingeben, hoffen dass der Host in seiner Not noch genügend Ressourcen frei hat, um einen auch hier noch reinzulassen, damit man endlich was unternehmen kann.

(Faierweise sei erwähnt, dass sich hinter „Konsole aufrufen“ noch eine Menge mehr Schritte verbergen können. Das tut hier aber nichts zur Sache.)

Oder nehmen wir meinen persönlichen Evergreen:

Die tolle, neue Linux-Distribution die ach so benutzerfreundlich und bunt und (zumindest für jemanden der nie wirklich an einem Mac gesessen hat) fast wie ein Mac daher kommt und selbstverständlich ohne bösen Root-Account auskommt wirft das Handtuch, das System bootet mit einem fetten Dateisystemfehler, ruft freundlicherweise die Recovery-Konsole auf mit der man das Dateisystem eventuell reparieren könnte und fragt in freundlichen, großen weißen Lettern:

Please enter Root-Password for Recovery: _

Und ich bekomme grüne Haut.

Alles in allem ist meine professionelle und persönliche Meinung (die bei uns im Team geteilt wird) dazu: Ja, am Root-Account offenbaren sich eine ganze Reihe konzeptioneller Schwächen der Rechtetrennung in unixoiden Betriebssystemen. Nein, das Arbeiten von Admins als root-User ist (bei hinreichend verantwortungsbewußten Admins) nicht eine davon.

Das heißt aber nicht, dass wir uns quer stellen würden, wenn ein Kunde Wert darauf legt, eben keinen Root-Account zu haben. Jemand von uns erläutert dann (wie ich in diesen Tagen) warum wir das selber nicht für sinnvoll halten und wir weisen ausdrücklich darauf hin, dass a) wir dann mit „sudo -i“ arbeiten werden und b) unbedingt, auf jeden Fall, ganz sicher vorher getestet werden sollte, ob die Linux-Distribution der Kundenwahl nicht auf der Recovery-Konsole doch nach einem Root-Passwort fragt, sonst kann es ein böses Erwachen geben — oder wie Murphy’s Law uns lehrt: sonst gibt es früher oder später ein böses Erwachen.

Ob der Kunde uns dann einen Admin-Account einrichtet oder individualisierte Accounts ist uns dabei relativ egal, wir würden selbst individuallisierte Accounts in unserer Passwort-Liste verzeichnen (damit hätte dann jeder von uns theoretisch die Zugangsdaten zu den Accounts der anderen), einfach weil wir grundsätzlich alle Passwörter dort sammeln. Denn uns ist eine verschlüsselte Passwortliste auf die nur wir fünf Zugriff haben lieber, als individuelle Passwörter die jeder einzelne von uns sich anders (und potentiell unsicherer) notiert und im Notfall vielleicht auch nicht findet.

10 Antworten zu “Got root?”

  1. Nizagam sagt:

    Geschmack ist ja bekanntlich unterschiedlich. Ein Punkt fehlt mir in den Überlegungen jedoch, wie ist es um die Nachvollziehbarkeit gestellt? Woher weiß man wer wann welche Befehle abgesetzt hat? Oder wird das nie benötigt in eurem Umfeld?

  2. Finkregh sagt:

    Danke für den Post :-)

    > Hier fehlt es Linux (genauso wie allen anderen mir bekannten unixoiden Betriebssystemen) an einer vernünftigen Lösung.

    Was spricht da gegen Mechanismen wir SELinux?

  3. Christopher Hirschmann sagt:

    Nachvollziehbarkeit dessen was überhaupt getan wurde erreichen wir mit einer endlosen Bash-History: http://blog.jonaspasche.com/2012/10/02/die-annalen-der-bash-geschichte/
    Wer das gewesen sein könnte, wäre unter Umständen an Logs abzulesen, die aber jemand mit Root-Zugriff natürlich manipulieren könnte, genauso wie jemand mit unbeschränkten sudo-Rechten. Remote Syslog könnte das ein bißchen lindern. So oder so: So genau müssen wir bisher nicht protokollieren.

  4. Christopher Hirschmann sagt:

    Also gegen SELinux spricht m.E., dass es SELinux ist, also ein nur bei Red Hat überhaupt eingesetzter, komplexer Exot.
    Darüber hinaus kann SELinux das Port-Problem nicht zufriedenstellend lösen, das haben wir schon versucht.

  5. Chris sagt:

    Ich muss euch grundsätzlich zustimmen. Ich komme selbst aus dem Bereich IT-Consulting, speziell Sicherheit und Netzwerk, und habe ähnliche Erfahrungen gemacht. Auch haben wir das in den Firmen wo ich bisher als Consultant tätig war weitgehend so gemacht. Es ist alles eine Frage des Vertrauens und der Machbarkeit. Bei den Kunden, wo es nur namentliche Zugänge gab, wurden auch diese in einer gemeinschaftlichen Liste festgehalten. Teilweise gab es dann einfach nur noch ein Passwort für su, ansonsten halt sudo. Allerdings habe ich nie (!) erlebt, dass die Logfiles sicher gewesen wären bzw. das diese nicht hätten manipuliert werden können. Das gilt zwar nur für Systeme, die wir / ich nicht gebaut hatten, ist aber bei einer derartigen Policy schon „verrückt“. Allerdings gab es in einer Firma schon die Abstufung, dass nicht jeder auf alles Zugriff hatte. Ob das mehr Vor- als Nachteile hat, ist in meinen Augen aber fraglich für den speziellen Einzelfall.

    Also grundsätzlich sollte in jeder SSHD Konfiguration der Punkt
    > PermitRootLogin without-password
    so enthalten sein. Wobei ich so oder so dazu tendiere, dass ich jegliche Passwortauthentifizierung abschalte und nur Keys zulasse. Ansonsten versuche ich bei Menschen, die das nicht verstehen, zumindest ein 2 Faktor System einzusetzen. Erstaunlicherweise kapieren das einige besser als die Keys.. Muss man nicht verstehen ;)

  6. marcel sagt:

    Was das binden auf Privileged Ports auf nicht-Kinderunixen (scnr) angeht:

    FreeBSD: sysctl net.inet.ip.portrange.reservedhigh=0

    Solaris: hier kann man es granularer an einer Benutzerrolle erlauben: /usr/sbin/usermod -K defaultpriv=basic,net_privaddr

    auf Linux geht das nur mit SELinux und „cap_net_bind_service=+ep“ für den Prozess…

  7. peter sagt:

    Zitat: „Sollte einer von uns gehen oder einer der SSH-PrivateKeys kompromitiert werden, müssen wir den PublicKey auf allen von uns administrierten Servern austauschen bzw. entfernen.“

    Schon mal mit http://www.sshark.org/ beschäftigt?
    https://www.youtube.com/watch?v=aXLz9YQm0-k&t=1h27m23s

    So ganz verstehe ich das System auch noch nicht, jedoch sollen mit sshark auf die schnelle Puplic Keys global widerrufen werden können.

  8. Sebastian sagt:

    Eventuell kannst ja die Überlegungen als Konzept an OVH verkaufen. Die sind augenscheinlich auf der Suche nach neuen Ideen ;)

  9. nonchip sagt:

    gegen das Problem mit privileged ports hilft übrigens ab 2.6.x der Befehl „setcap ‚cap_net_bind_service=+ep‘ /pfad/zum/dienst“

  10. mifritscher sagt:

    jep, das mit den capabilities ist mir auch in den Sinn bekommen.
    Zur 2 Faktor Authentifizierung: naja, ist beim Onlinebanking mittlerweile gängig, vermutlich verstehen es deswegen mehr ;)
    Zum sudo: Ich verwende es gerade auf Servern, wo mehrere Leute parallel dran arbeiten, recht gerne. Das hat neben dem Loggen, wer wann dran war, u.a. den Vorteil, dass jeder „seine“ Umgebung entsprechend einrichten kann (Shell, Editor, aliase etc.)
    Ja, dass dann manche Distros trotzdem nach einem root-Passwort fragen, wenn beim starten an einer bestimmten Stelle was schief ging (meist wenn / zumindest noch ro mountbar war, aber andere Partitionen nicht mehr, oder Fehler in der fstab) ist blöde, aber sehr einfach zu umgehen: Beim Grub ein init=/bin/(ba)sh reinhauen ;-) Hat sogar den Vorteil, dass dann noch weniger läuft, und in solchen Situationen will man keine Prozesse, die „irgendwas“ machen.


Impressum