Argumente gegen arbeiten als root

[Zephyrus]

Moin.

Ich suche gerade Argumente, die gegen das arbeiten als "root" sprechen.
Und zwar im Bereich der Serveradministration.

Folgendes Argument habe ich mir selber zusammen gereimt:

Wenn SSH auf Port 22 lauscht und ein potentieller Angreifer sich denkt "probier ich mal mit user root alle passwörter durch", würde er keinen Erfolg haben, wenn root sich per SSH nicht direkt einloggen kann, sondern nur über einen normalen User Account mit su oder sudo zu root wird.

Klar ist das arbeiten als root-User riskant, jedoch sollte ein Serveradmin ja wissen was er tut. Selbst wenn nicht, würde ihn der Sicherheitsmechanismus nicht abhalten, da die meisten sich 3 Sekunden später eh mit su zu root machen.

Von daher finde ich mein Argument bisher am sinnvollsten.
Kennt ihr noch weitere?

 

[marzl]

Na irgendeiner muss ja Zugriff auf verschiedene Systemfunktionen oder andere kritische Bereiche haben. Da kommt ja eigentlich nur Root in Frage. Bei Dateiberechtigungn helfen Dir Gruppen weiter, denen Du Schreibzugriff erlaubst.

 

[Zoi]

Von daher finde ich mein Argument bisher am sinnvollsten.

Welches Argument? So ganz habe ich es noch nicht verstanden. Willst Du sagen, dass man sich doch ruhig auch als root per ssh einloggen kann, oder ...?

 

[Zephyrus]

Willst Du sagen, dass man sich doch ruhig auch als root per ssh einloggen kann, oder ...?

Technisch gesehen wäre das möglich allerdings halte ich das für zu unsicher. Besser wäre es da doch sich als System-Maintenance-Account einzuloggen, sprich sich einen normalen Account anzulegen für Wartungen am System und darüber per su zu root zu werden.

 

[marzl]

Es gilt sowieso und unter *BSD ist es auch voreingestellt, das root keinen direkten SSH-Zugriff hat. Das ist ein alter Muck und die nächste Stufe sind dann Zertifikate, und nicht nur mit Passwort.

 

[zuglufttier]

Generell kann man auch einfach den root-Account deaktivieren und einem anderen User, den man natürlich nicht so leicht rausbekommt, diese Rechte übertragen.

 

[lars]

$ cat /etc/group| grep wheel

Oder, wie verstecke ich einen User, der ähnliche Rechte wie 'root' hat?

Das geht in Richtung 'Security by Obscurity', das funktioniert nicht.

Accounts müssen mit starken Passphrasen und/oder Tokens und Zertifikaten
geschützt werden (ob es sich in jedem Szenario lohnt, ist eine andere Frage).



Dass jeder einfach mit 'su' 'root' wird impliziert, dass mehrere Leute sich den root-Account teilen.
Das ist schlecht [TM].

Und als Normalzustand immer die höchsten Benutzerprivilegien zu haben erhöht
die Wahrscheinlichkeit zu einem Clusterfuck beträchtlich.



Generell sollten Accounts nicht geteilt werden, sondern alle Administratoren
einen User-Account haben um normal zu arbeiten und einen zweiten Account, der in den
jeweiligen funktionalen administrativen Gruppen ist.

Das geht in Richtung Role-Based Access Control (RBAC), siehe Trusted Solaris etc.

 

[oenone]

Ich suche gerade Argumente, die gegen das arbeiten als "root" sprechen.
Und zwar im Bereich der Serveradministration.

Serveradministration... Mit nur einem einzigen Verantwortlichen? oder mit einer Sysadmin-Gruppe, die alle das System administrieren sollen/wollen? Ist immer die Frage, wie ernsthaft du "Serveradministration" siehst.

das Beispiel mit dem ssh lass ich mal weg, das ist lächerlich...

Klar ist das arbeiten als root-User riskant, jedoch sollte ein Serveradmin ja wissen was er tut. Selbst wenn nicht, würde ihn der Sicherheitsmechanismus nicht abhalten, da die meisten sich 3 Sekunden später eh mit su zu root machen.

bei su musst du das root-Passwort eingeben... wenn du hingegen sudo verwendest, kannst du 1. das root-Passwort in Sicherheit ruhen lassen (z.B. im Tresor, nur bei Notfällen öffnen) und 2. die Rechte der einzelnen User gezielt regeln (mit su hast du alle Rechte, mit sudo kannst du einzelne Befehle konfigurieren).

Sofern du einziger User des Systems bist, dann ists relativ gleichgültig ob du als root arbeitest oder nicht.. du kennst ja als einziger das root-Passwort und weißt immer ganz genau, was du tust. (achtung, ironie). Tippfehler passieren ja so selten... (z.B. "rm -rf foo/ *" statt "rm -rf foo/*")

Durch die häufige Eingabepflicht des root-Passworts hast du entweder ein sehr einfaches gewählt, oder du hast es dir irgendwo aufgeschrieben oder gemerkt... letzteres ist schlecht, weil es dann zu einfach ist und die davor sind aus verständlichen Gründen auch schlecht.

auf bald
oenone

*nie als root einlog*

 

[CMW]

Moin.

Ich suche gerade Argumente, die gegen das arbeiten als "root" sprechen.
Und zwar im Bereich der Serveradministration.

Folgendes Argument habe ich mir selber zusammen gereimt:

Wenn SSH auf Port 22 lauscht und ein potentieller Angreifer sich denkt "probier ich mal mit user root alle passwörter durch", würde er keinen Erfolg haben, wenn root sich per SSH nicht direkt einloggen kann, sondern nur über einen normalen User Account mit su oder sudo zu root wird.

Klar ist das arbeiten als root-User riskant, jedoch sollte ein Serveradmin ja wissen was er tut. Selbst wenn nicht, würde ihn der Sicherheitsmechanismus nicht abhalten, da die meisten sich 3 Sekunden später eh mit su zu root machen.

Von daher finde ich mein Argument bisher am sinnvollsten.
Kennt ihr noch weitere?

Wenn ein Programm mit dem Du "nur mal schnell" etwas im Netz nachsiehst, und dieses dir Befehle unter jubelt laufen diese mit vollen Recheten. Des weitern ist es besser möglichst wenig unter Root zu arbeiten dass man nicht unter Root in den Alltagstrott fällt. (Ups, sollte garnicht rm -rf /bin sondern rm -rf bin/ sein... )

 

[nevixpain]

Wenn ein Programm mit dem Du "nur mal schnell" etwas im Netz nachsiehst, und dieses dir Befehle unter jubelt laufen diese mit vollen Recheten.

Full Ack.

Das ist imho noch das wichtigste Argument,
und auch der Grund warum sich unter Windows Viren so schnell verbreiten können, weil eben (fast) jeder als Administrator rumsurft und daddelt.

 

[kong]

Wenn du auf Nummer sicher gehen willst, dann lässt du root überhaupt nur auf den phisikalischen Konsolen zu, also seriell oder direkt mit Bildschirm und Tastatur (freilich dann nicht den Rechner zugleich mit seriellem Modem ans Internet anschließen, sondern dafür halt die NICs benutzen.) Bei OpenBSD geht das indem du deinen normalen User nicht in die wheel-group tust. Dann kann nur noch jemand mit physikalischem Zugang zum Rechner auch root-Zugang erlangen. Nachteil: Manche Aufgabe geht nicht mehr übers Internet zu machen. Wenn man genau weiß, welche Aufgaben so anfallen, dann ist dieser Nachteil allerdings minimierbar indem man mit chmod, chown etc. die Rechte nach Bedürfnis konfiguriert; sprich dem User genau die Sachen erlaubt, die halt so anfallen - möglichst nichts Anderes, was allerdings ein durchdachtes Konzept erfordert. Dabei ist es auch extrem wichtig welche Prozesse als wer laufen etc.
Das mit dem Einloggen und dann su gestaltet sich übrigens wesentlich schwieriger für einen Angreifer wenn sudo nicht installiert ist, oder entsprechend konfiguriert, dass der Angreifer nicht nur ein einziges Passwort knacken muß.
Wenn du dich einfach per ssh als root einloggst, dann ist das so sicher wie ssh das Passwort absichert. Wenn aber root gar nicht als Login per ssh geht, dann ist der Remote-Login gleich (Pi mal Daumen) doppelt sicher: Der Angreifer kann zwar sinnlos Passwörter für root durchprobieren, verschwendet damit aber nur Zeit, der Username der geht ist nochmal so sicher wie zuvor nur das Passwort war. Aber das war ja eh dein Argument, fällt mir grade auf. Der Witz ist: Wenn du es noch sicherer haben willst, mußt du also deinem Remote-User verweigern root zu werden. Ob das ein gehbarer Weg ist entscheidet sich an deinen Sicherheits- und Fersteuerungsbedürfnissen. Wie gesagt, dazu vielleicht mal Rechte und setuids auf deinem System studieren. Und auch mal in Betracht ziehen, was es noch für Angriffe gibt, außer sich als root einzuloggen und dann zu machen was man will. Z.B. ist es wichtig wer was in den PATH von root schreiben kann; so jemand könnte z.B. ein Programm namens cp an eine frühere Stelle im root-PATH schreiben, als das cp, das root meint wenn er was kopieren will - und schon läuft ein Teufelscp mit root-Rechten. Wenn du dich z.B. als Hans einloggst, dann in "~/" sust und root "./" in seinem PATH hat, kann jeder der in Hans sein Home-Verzeichnis schreiben kann dort ein Killergrep oder Würgecat platzieren. Etc.
Um all solche Gefahren zu minimieren ist es prinzipiell ein guter Rat so wenig wie möglich als root zu machen.

 

[mawei]

Um all solche Gefahren zu minimieren ist es prinzipiell ein guter Rat so wenig wie möglich als root zu machen.

Zu dem Thema fällt mir gerade was aus Elad Efrats Artikel ein ("Recent Security Enhancements in NetBSD"):

"Introducing capabilities, implemented as a set of kernel authorization listeners, will replace the role of the set-id bit in today's systems. Providing a fine-grained privilege model, each program will run with the minimal set of capabilities required for its operation. Furthermore, associating capabilities with users will allow us to define user roles, dividing the work-load of the super-user - possibly eliminating it entirely!"

http://www.securityfocus.com/infocus/1878/7

So ganz ohne root auskommen zu können - das wär' schon cool!

Wenn ich mir aber den Artikel insgesamt ansehe, beschleicht mich das Gefühl, dass die Systemverwaltung immer aufwendiger und komplizierter wird. Mensch, waren das noch Zeiten als man ganz ohne Paketfilter auskam, ohne Skrupel telnet und ftp nutzen konnte.

Erzähl' ich heute jemandem, dass ich immer noch keinen Paketfilter nutze, bekomme ich ein Kopfschütteln und vielleicht ein mitleidsvolles Lächeln ("Oh mann, der arme Kerl hat ja sowas von keine Ahnung" ;-) )

Immerhin hab' ich mir inzwischen (Open)ssh angewöhnt...