OpenSSH sicher mitloggen

[gelöschter Benutzer]

Hallo Leute,

gibt ja die Möglichkeit nach der Anmeldung über den OpenSSHd ein Script zu starten (eingetragen in der .ssh/authorized_keys) und bspw. mit log-user-session die Eingaben zu protokollieren.

Jetzt muss ich den zu protokollierenden Benutzern allerdings root zur Verfügung stellen, Sudo mit bestimmten Kommandos reicht leider nicht aus. Gibt es eine Möglichkeit, eine Manipulation durch den User zu verhindern? Er könnte ja theoretisch immer weitere Keys zu .ssh/authorized_keys hinzufügen oder den Logger rauslöschen. Auch die Lögs selbst könnte er manipulieren. Wäre es möglich, einen User mit der UID 0 (also root) anzulegen und ihm dann zu verbieten, seine eigene .ssh/authorized_keys zu manipulieren?

Alternativ wäre ein "Über die Schulter schauen" mit Passworteingabe auch nett. Also dass der Benutzer einen Key bekommt und ich dann bei jedem sudo das Passwort eingeben oder Enter drücken muss. Oder dass ich ihm ein Keyfile schicke und dann per SSH auf seinen Rechner gehe, seine Session anschaue und das Passwort für den Key für meinen Server eingebe.

Findet ihr das überhaupt praktikabel oder sollte ich lieber mal über mein Rechtemanagement nachdenken?

 

[keksautomat]

Ein bisschen Background wäre vielleicht gut. Wen willst du überwachen. Sind das Neulinge? Oder Erfahrene die dir nicht ins System basteln sollen?

 

[gelöschter Benutzer]

Beides. Einerseits möchte ich, dass der Geschäftsführer (der unbedingt Zugriff "braucht") nichts aus Versehen kaputt macht, andererseits möchte ich, dass die IT-Mitarbeiter (variierender Skilllevel, kann ich schlecht einschätzen ob die schlauer sind als ich) mich nicht aussperren oder komische Dinge mit dem Mailserver anstellen. Sind halt auch einige sensible Daten auf dem Server.

 

[Kugelfisch]

Grundsätzlich kannst du nicht zuverlässig verhindern, dass jemand, der über volle root-Rechte verfügt, dein Logging deaktiviert oder die Ergebnisse manipuliert. Eine Möglichkeit wäre, das Log auf einem unabhängigen Server zu speichern - dass Log-Einträge gefälscht werden oder das Logging deaktiviert wird kannst du damit zwar nicht verhindern, wohl aber, dass gespeicherte Logs im Nachhinein manipuliert werden.

Weshalb benötigen benötigen überhaupt Dritte root-Zugriff auf deinen(?) Server? Wäre möglicherweise eine VM eine Option?

 

[gelöschter Benutzer]

Für ne VM haben die User zu wenig Ressourcen.

Vielleicht löse ich das doch lieber über die /etc/sudoers. Wenn ich aber einem User sudo-Rechte für irgendeinen Editor gebe, kann ichs ja auch gleich wieder vergessen, oder?

 

[keksautomat]

Eventuell hilft eine "Blacklist" von Commands die nicht ausgeführt werden dürfen?
Das könnte aufjedenfall häßlich werden..

Alternativ: Interne Bildung. Gebe eine Präsentation (auch für deinen Chef) von Sachen, die er nicht darf / sollte / wo gefahren sind und bla bla. Als allerwichtigste Regel: hast du keinen Plan was der Befehl da ausführt: nachfragen!
Und wenn es sein muss, rennst du halt X-Mal am Tag zu deinem Chef, um dir den Befehl anzusehen..

Alternativ habe ich keine Idee, wie man da ran gehen könnte..
Vielleicht hilft das aber: https://superuser.com/questions/735172/how-to-prevent-sudo-users-from-running-specific-commands

 

[Toady]

Vielleicht löse ich das doch lieber über die /etc/sudoers. Wenn ich aber einem User sudo-Rechte für irgendeinen Editor gebe, kann ichs ja auch gleich wieder vergessen, oder?

Nein. Du kannst dann zwar vim aufrufen, aber du bekommst deshalb noch lange nicht Schreibrechte auf die Dateien - das Rechtesystem funktioniert anders, da du Rechte auf Dateien gibst (da in einem unix ausnahmslos alles eine Datei ist, triffts das sogar ganz gut, auch wenn sudoers nicht ganz so funktioniert). vim in die sudoers aufzunehmen würde also nur Sinn ergeben, wenn /usr/bin/vim 0700 wäre (oder die gruppe das x bit gesetzt hast und du nicht in dieser gruppe wärst).

Dein Anwendungsfall klingt so, als könne man mit sudo und ggf. dem setuid-bit arbeiten - ist aber nicht mal eben so nebenbei erklärt (Beispiel zu setuid ist das Programm passwd; das kann jeder user aufrufen, und die /etc/shadow wird danach mit rootrechten geändert, weil passwd mit rootrechten "läuft"; grade wenn man mit Webservices arbeitet ist das ne verbreitete Technik, dass man kleine, übersichtliche wrapper baut, um sehr eingegrenzt erweiterte Rechte zur Verfügung zu stellen - die Möglichkeiten von sudo sind ja irgendwann doch eher begrenzt und man muss viel mehr erlauben als man eigentlich will).

 

[Kugelfisch]

Nein. Du kannst dann zwar vim aufrufen, aber du bekommst deshalb noch lange nicht Schreibrechte auf die Dateien

Das gilt doch aber nur, wenn man die Rechte zum Editieren von Dateien in der sudoers-Konfiguration über sudoedit-Direktiven vergibt? Wenn man tatsächlich `sudo-Rechte für irgendeinen Editor` vergibt, d.h. eine Zeile wie

foo     ALL = /usr/bin/vim

in /etc/sudoers einträgt, kann der Benutzer mit einer per `sudo vim` gestarteten vim-Instanz beliebige Dateien verändern (und über `:!bash` auch eine root-Shell erhalten, sofern die NOEXEC-Direktive nicht gesetzt ist). Wenn nur bestimmte, im Voraus bekannte Dateien verändert werden müssen, wäre sudo/sudoedit natürlich eine gute Lösung.

 

[gelöschter Benutzer]

Das, was Kugelfisch beschreibt, meinte ich auch eigentlich.

Ich habe auch Ewigkeiten das Web durchkämmt und immer noch keine andere Lösung gefunden außer die aus dem Startpost.
Gab sogar schon den (scherzhaften?) Vorschlag, doch diese Appliance hier zu kaufen: http://www.balabit.com/network-security/scb
Mein Kommentar dazu: "who watches the watchmen?"


Das Praktikabelste ist imho schon fast das Mitloggen und eine Überprüfung von Datei-Hashes durch einen externen Server. Also der externe Server guckt per cron alle paar Minuten auf den "Hauptserver", berechnet den Hash (CRC32 oder SHA1) des Logging-Scripts und wenn der nicht übereinstimmt, gibts nen Alert an einen der Superadmins. Ansonsten werden die Logs rüberkopiert und auf dem Hauptserver gelöscht.

Gibt natürlich die Schwachstelle, dass man ein Backup des Log-Scripts nutzen kann, den eigenen User rausnehmen kann und dann die Logs wieder zurückspielen kann. Dann hätte man in der Zeit zwischen zwei Checks die Möglichkeit, das System zu verändern. Wenn ich die Zeit zwischen den Checks allerdings randomisiere (zwischen 1min und 10min), wird das kein User jemals schaffen. Oder?


Gibt's doch nicht, dass noch niemand auf die Idee gekommen ist. Wird wohl daran liegen, dass sich kein Admin selbst Beschränkungen installieren will

 

[Toady]

Das gilt doch aber nur, wenn man die Rechte zum Editieren von Dateien in der sudoers-Konfiguration über sudoedit-Direktiven vergibt?

Ja, klar - Betriebsblindheit und der Umstand, dass ich solche Dateien grundsätzlich über puppet-templates verwalte, wo dererlei Grundkonfig schon vorhanden ist (weil man in der Regel das Bearbeiten von Dateien explizit erlauben möchte und hier keinerlei vererbten Rechte haben möchte), haben mich zu der falschen Aussage hinreißen lassen - Schande über mich :-)
Das ist übrigens einer der Gründe, weshalb ich lieber kleine wrapper in c habe, die sehr überschaubar sind, das setuid-bit gesetzt haben, wo entsprechende guards durchlaufen werden und dann eine function do() mit einem setuid=0 entsprechendes im System macht; sudo ist halt nicht so flexibel, wie man es gerne hätte.

 

[accC]

gibt ja die Möglichkeit nach der Anmeldung über den OpenSSHd ein Script zu starten (eingetragen in der .ssh/authorized_keys) und bspw. mit log-user-session die Eingaben zu protokollieren.

Wenn du es irgendwie schaffst die Logs (online) auf einem Dritten System zu speichern, dann wäre es möglich, dass er die Logs eben nicht manipulieren kann, sonst ist root eben root und du kannst root nicht einschränken, zumindest meines Wissens nach und solange wir über Linux/ Unix reden. Bei Windows wäre das noch mal anders.

Findet ihr das überhaupt praktikabel oder sollte ich lieber mal über mein Rechtemanagement nachdenken?

Nein, natürlich vollkommen unbedenklich, wenn du Nutzern, denen du nicht trauen kannst, root Zugriff gibst. Ungefähr so sinnvoll wie seine Kreditkarte mit in jedes Hinterzimmer zu geben, weil dort der Kartenleser steht. Das solltest du unbedingt beibehalten, Rechtemanagement ist nur so ein Modewort, damit sich ein paar eingebildete Schnösel etwas auf ihr Wissen einbilden können. << Achtung: Ironie!

 

[gelöschter Benutzer]

Okay, dann sag mir mal wie man Server ohne Root administriert. Web-Admin? o_O

 

[accC]

Dann erkläre mir erst mal, wieso ein Nutzer, der potentiell eine Bedrohung für deinen Server ist und dem du nicht vertrauen kannst, deinen Server administrieren sollte?
Das ist so, als wollte ich unbedingt einem vollkommen Unbekannten eine Vollmacht für mein Konto ausstellen wollen und dann fragen, wie ich das nun sicher hinbekomme, dass er nicht morgen mit sämtlichem Guthaben + Überziehungskredit über alle Berge gelaufen ist..

 

[gelöschter Benutzer]

Wenn du den Thread aufmerksam gelesen hättest, wüsstest du, dass es mir nicht um das Verhindern von Manipulationen an der Konfiguration an sich geht, sondern um das Mitloggen. Es geht nur um die Nachverfolgung im Falle eines Sicherheitslecks o.ä. in bezug auf ISO 27001. Wir sind zwar noch nicht zertifiziert, möchten uns aber gerne an dieser Norm orientieren und unsere Prozesse auf lange Sicht darauf ausrichten.

Meine konkrete Anforderung: Die Leute können von mir aus mit dem Server anstellen was sie wollen, solange ich die Kommandos nachvollziehen/mitloggen kann. Klar soll nach Möglichkeit nichts an der Config geändert werden, aber die von mir gewünschte Methode soll nicht präventiv, sondern retrospektiv funktionieren.

Ideal wäre eben eine Software auf einem Drittserver, der die Rolle der oben verlinkten Appliance übernimmt. Letztere ist für unsere Zwecke (weniger als 10 Server und User) definitiv zu teuer bzw. überdimensioniert.

 

[accC]

Nun wenn du dem Administrator vertrauen kannst, kannst du normal loggen.
Wenn du davon ausgehst, dass der Administrator den Log - aus welchen Gründen auch immer - manipuliert, dann ist es eben nicht mehr so einfach, das was Kugelfisch gesagt hat.

 

[gelöschter Benutzer]

Ich würde denen gerne vertrauen, aber ich sage auch "Vorsicht ist besser als Nachsicht".

 

[musv]

Vor einigen Jahren hatte ein Studienkollege von mir ein ähnliches Problem. Die Nutzer wollten unbedingt Root-Rechte auf dem Server. Allerdings war das bei ihm ein BSD und kein Linux.

Also hat er beim Booten eine Jail-Umgebung gestartet und dazu noch das Dateisystem des Jails als UnionFS gemountet. Die Änderungen hat er dann beim Runterfahren einfach gelöscht.

Die Nutzer bekamen dadurch eine Root-Umgebung, in der sie alles umstellen, ändern und zerschießen konnten. Nach jedem Neustart war die Umgebung wieder genauso jungfräulich wie bei der Installation. Google hat mich bei Linux auf LXC gebracht. Hab damit aber selbst noch nie gearbeitet.

Eventuell wäre das zumindest eine Lösung bei Dir, wie du die User per Fake-Root vom tatsächlichen Root-System abkoppeln kannst.

 

[gelöschter Benutzer]

die LXCs sehen ganz gut aus. Wäre ja cool, wenn ich deren Änderungen wie bei einem Versionskontrollsystem (git, hg, svn) absegnen und übernehmen könnte.

Was ja sogar möglich wäre, oder?

 

[Toady]

Wenn du Richtung ISO27001 gehen möchtest, dann solltest du überlegen, inwieweit direkter Zugriff auf Scope-Systeme dann überhaupt noch in Frage kommt.
Bei meinem letzten Arbeitgeber ging das de facto gar nicht mehr - da wurde die Config über puppet verteilt, und du hast den puppet-"code" via git eingechecked.
Also, du hast die puppet-Module auf deinem Arbeitsplatz bearbeitet und committet, dann von dort aus gepushed, und je nach Branch wurden dann serverseitig diverse pre-commit checks und sonstige getriggert, die dann weitere Programme aufgerufen haben.
Auf dem puppet master gibt es dann eine Art auto-checkout.

Ist in der Praxis um einiges komplexer als es sich jetzt liest (und wer sich mal etwas intensiver mit Continous Delivery/Integration becshäftigt hat, der weiß das auch - puppet-confg so zu verteilen ist noch einmal ne ganze Ecke komplexer) - wenns aber ein Mal steht ist es eine enorme Hilfe.


Anyway - bevor du dich an ISO27001 machst, versucht doch vielleicht ersteinmal die weit weniger strengen Vorgaben des BDSG zu erfüllen, denn ich gehe davon aus, dass hier personenbezogene Daten verarbeitet werden:
http://www.gesetze-im-internet.de/bdsg_1990/anlage_79.html
Du würdest bei deinem Vorhaben spätestens bei Punkt4 (Weitergabekontrolle) und Punkt5 (Eingabekontrolle) scheitern, da, wenn alle als root unterwegs sind, nicht sicher nachvollzogen werden könnte, wer was wann und wie geändert hat.
Wenn ihr einem Auditor aber wahrheitsgemäß berichtet, dass dort so viele unterschiedliche Leute als root auf dem System unterwegs sind, wird er euch eh nahelegen, das Rechtesystem grundlegend zu überdenken.

ISO27001 ist außerdem nicht wegen der Zertifizierung an sich ein Indiz (du musst ja nur bestätigen, dass dir Risiken bewusst sind - auch wenn es grobe Fehler im System gibt bekommst du das Zertifikat, solange du bestätigst, das dir das Risiko bewusst ist, und du es ggf. auf nicht-technischem Wege löst). Das Interessante an ISO27001 ist eher der Zertifizierungsweg und der Umstand, dass ein Auditor das System begutachtet (dem man btw. auch alles mögliche Erzählen kann - der Überprüft wenn überhaupt nur stichprobenartig).
Das ist nicht mit PCI-DSS o.ä. zu vergleichen - da haften die Auditoren ja auch für die inhaltliche Richtigkeit; bei ISO27001 wird einem ersteinmal das vorgetragen so geglaubt und es muss nicht nachgewiesen werden.

 

[musv]

die LXCs sehen ganz gut aus. Wäre ja cool, wenn ich deren Änderungen wie bei einem Versionskontrollsystem (git, hg, svn) absegnen und übernehmen könnte.

Was ja sogar möglich wäre, oder?

Ja, sollte möglich sein. Hat aber nichts mit LXCs sondern dann mit UnionFS zu tun.

Bei UnionFS kannst du ein oder mehrere Readonly-Verzeichnisse auf ein Zielverzeichnis mounten. Die Änderungen werden dann in ein 3. Verzeichnis übernommen. Das kannst du logischerweise mit dem Originalverzeichnis vergleichen und synchronisieren oder die Änderungen eben verwerfen. Ich nutz das für den Paketmanager unter Gentoo. Beispiel:

mount -t unionfs -o nodev,noexec,
 dirs=/pfad/schreibverzeichnis=rw:
  /pfad/leseverzeichnis1=ro:
  /pfad/leseverzeichnisn=ro:
  /pfad/merge_verzeichnis=ro
 unionfs /pfad/merge_verzeichnis

• rw = Verzeichnis, in dem die Änderungen landen
• ro = Verzeichnis(se), die der Nutzer sehen soll
• merge_verzeichnis = Sind praktisch die Readonly-Verzeichnisse und das Schreibverzeichnis. Das präsentiert sich dem Nutzer als normales Verzeichnis, bei dem er nicht erkennen kann, was dahinter steckt.

Alternativ gibt's noch OverlayFS. Das ist eine Art UnionFS light, sollte eigentlich schon seit 2 Jahren in den Kernel kommen.