Verfolgen von Superuser-Aktivitäten

Ich möchte wissen, welche Ansätze am besten geeignet sind, um Superuser-Aktivitäten in einer Linux-Umgebung zu verfolgen.

Im Einzelnen suche ich nach folgenden Funktionen:

• A) Protokollieren von Tastatureingaben auf einem gesicherten Syslog-Server
• B) Fähigkeit, Shell-Sessions wiederzugeben (so etwas wie Drehbuchwiedergabe)
• C) Idealerweise sollte dies etwas sein, das ohne physischen Zugriff auf den Server unmöglich (oder ziemlich schwierig) zu umgehen ist.

Stellen Sie sich dies aus Sicherheits- / Überwachungssicht vor, und zwar in einer Umgebung, in der verschiedene Systemadministratoren (oder sogar Dritte) privilegierte Vorgänge auf einem Server ausführen dürfen müssen.

Jeder Administrator verfügt über ein eigenes nominales Konto, und jede interaktive Sitzung sollte vollständig protokolliert werden. Bei Bedarf kann sie erneut abgespielt werden. Wenn beispielsweise jemand mc zum Löschen oder Ändern kritischer Dateien verwendet hat, reicht dies nicht aus wissen, dass diese Person den Befehl mc ausgegeben hat, es muss eine Möglichkeit geben, genau zu sehen, was nach dem Start von mc) getan wurde.

Zusätzliche Hinweise :

1. Wie Womble bereits betont hat, ist es möglicherweise die beste Option, wenn sich Benutzer nicht mit Root-Rechten anmelden, um Änderungen auf Servern vorzunehmen, sondern dies über ein Konfigurationsverwaltungssystem. Nehmen wir also eine Situation an, in der wir kein solches System haben und verschiedenen Personen über denselben Server Root-Zugriff gewähren müssen .
2. Ich bin überhaupt nicht daran interessiert, dies heimlich zu tun: Jede Person, die sich bei einem Server mit Root-Rechten anmeldet, weiß genau, dass die Sitzung aufgezeichnet wird (so, wie zum Beispiel Call-Center-Betreiber wissen, dass ihre Gespräche stattfinden) aufgenommen werden)
3. Niemand würde ein generisches Superuser-Konto ("root") verwenden
4. Ich kenne ttyrpld und es scheint zu tun, wonach ich suche. Bevor ich diesen Weg gehe, möchte ich wissen, ob dies mit einem nicht modifizierten Kernel gelöst werden kann. Ich möchte wissen, ob es Tools für Debian im Besonderen (oder für Linux im Allgemeinen) gibt, die eine vollständige Prüfung von Superuser-Konten ermöglichen, ohne die Shell oder den Kernel zu patchen.

Verwenden Sie in Umgebungen mit mehreren Administratoren nach Möglichkeit niemals root.

Verwenden Sie sudo für alles - sudo ist extrem konfigurierbar und einfach zu protokollieren.

Logge alle Logins oder su's, um sie zu rooten und zu untersuchen, während jemand deine festgelegten Regeln umgeht.

Welche Art von Root-Benutzerzugriff möchten Sie überwachen? Dumme Admin-Fehler oder böswillige Insider? Ersteres - Sie möchten eine gute Konfigurationsverwaltungslösung, wie bereits vorgeschlagen. Letzteres - wenn sie wissen, was sie tun, können Sie nur hoffen, genug zu fangen, um anzuzeigen, dass etwas passiert ist, das es wert ist, untersucht zu werden. Sie möchten nur wissen, dass irgendeine Form von nicht autorisierter Aktivität gestartet wurde, und auf diese Tatsache aufmerksam gemacht werden. Wenn sie schlau sind, deaktivieren sie den größten Teil der von Ihnen eingebauten Protokollierung (indem sie den Serverstatus ändern oder ihre eigenen Tools einbringen), aber hoffentlich können Sie die Anfänge des Vorfalls nachvollziehen.

Davon abgesehen schlage ich ein paar Tools vor, die Sie verwenden können. Beginnen Sie zunächst mit einer guten Sudo-Richtlinie (die bereits vorgeschlagen wurde). Zweitens sollten Sie sudoshell ausprobieren, wenn Sie diesen Administratoren Root-Shell-Zugriff gewähren müssen. Drittens, wahrscheinlich die beste Wahl (wenn auch die intensivste) ist die Prüfung des Linux-Kernels.

Sie könnten diese Bibliothek für sudo verwenden, jedem sein eigenes Benutzerkonto zuweisen und sudo -i in das Profil von everyones einfügen. Auf diese Weise haben sie sofortigen Root-Zugriff und jeder von ihnen verwendete Befehl wird protokolliert.

Sie haben Wurzel. Das Beste, auf das Sie hoffen können, ist, zumindest zu sehen, wann sie sich entschieden haben, aus Ihrer kleinen Überwachungsutopie auszubrechen, aber darüber hinaus ist es unklar, was sie getan haben.

Die "beste" Option, die ich mir vorstellen kann, besteht darin, die Verwendung von allgegenwärtiger Konfigurationsautomatisierung und -verwaltung vorzuschreiben und Ihre Manifeste mit einem Revisionskontrollsystem zu verwalten und Aktualisierungen auf diese Weise bereitzustellen. Verhindern Sie dann die tatsächlichen Root-Anmeldungen an den Servern. (Der Notfallzugriff "Oh nein, ich habe etwas kaputt gemacht" kann durch ein nicht verteiltes und nach jeder Verwendung geändertes Kennwort oder einen SSH-Schlüssel erfolgen, und jeder kann den Systemadministrator beobachten, der es vermasselt hat, um sicherzustellen, dass er es nicht tut etwas ändern).

Ja, das wird unbequem und ärgerlich, aber wenn Sie paranoid genug sind, um die Handlungen aller in diesem Maße zu überwachen, befinden Sie sich wahrscheinlich in einer Umgebung, die unbequem und auf andere Weise ärgerlich genug ist, als dass dies gewonnen hätte scheint kein großes Problem zu sein.

Wie andere gesagt haben, gibt es so gut wie keine Möglichkeit, Benutzer mit vollem Root-Zugriff so zu protokollieren, wie sie es nicht deaktivieren können. Wenn Sie jedoch debian / ubuntu ausführen , schauen Sie sich snoopy an , das Ihren Vorstellungen ziemlich nahe kommt

snoopy ist lediglich eine gemeinsam genutzte Bibliothek, die als Wrapper für die von libc bereitgestellte Funktion execve () verwendet wird, um jeden Aufruf von syslog (authpriv) zu protokollieren. Systemadministratoren finden snoopy möglicherweise nützlich bei Aufgaben wie der Überwachung von leichten und schweren Systemen, dem Verfolgen der Aktionen anderer Administratoren sowie dem Erhalten eines guten Gefühls dafür, was im System vor sich geht (z. B. Apache, der CGI-Skripte ausführt).

Ich bin mit den Kommentaren von disabledleopard über die Verwendung von sudo für alles einverstanden. Es macht es sicherlich ein bisschen einfacher, Dinge zu protokollieren.

Ich füge außerdem hinzu, dass die Bash-Verlaufsdatei regelmäßig gesichert wird. Scheinbar oft übersehen, aber manchmal eine großartige Informationsquelle ... fragen Sie einfach Goldman Sachs. ;-)

http://www.guardian.co.uk/business/2009/jul/12/goldman-sachs-sergey-aleynikov

Das wäre schwierig ...

root kann sorgfältig getestete Skripte ausführen, die alle Sicherheitsmaßnahmen verletzen (Überwachungsprozesse beenden), Protokolldateien löschen / zuschneiden usw. Aber trotzdem ...

Angenommen, mehrere Administratoren mit Root-Rechten arbeiten als Team. Und root kann auch jeden Überwachungsprozess beenden. Und leider wird dieses Login / Passwort öffentlich. Oder sie bekommen unerwünschte Gesellschaft.

Das Erstellen mehrerer Stammkonten mit der UID 0 wird zwar nicht empfohlen, kann hier jedoch hilfreich sein.

In / etc / ssh / sshd_config Ändern der Zeile in: PermitRootLogin-Nr

ist empfohlen. Damit sich ein Benutzer hier mit seinem normalen Konto anmeldet (Datum / Uhrzeit-Stempel wird mit protokolliert (möglicherweise gefälschte IP-Adresse)), wechselt er dann zu root. mit su Befehl

Und so wird das direkte Einloggen als root verhindert.

Wir müssen uns überlegen, was Root Cant hier machen kann.

sudo sollte gut sein. Sichern des Verzeichnisses / etc Die Konfigurationsdateien sollten fehlerfrei sein. / var / directory Protokolldateien sollten regelmäßig per E-Mail gesendet oder auf einem separaten NFS gespeichert werden.

Wie wäre es mit dem Schreiben von Skripten, die APIs von Mobile Gateway-Unternehmen integrieren, die SMS-Nachrichten für alle Stammbenutzer-Handys zusammenfassen, wenn einer von ihnen nicht zu Hause ist. Ich weiß, das wäre ärgerlich, aber trotzdem.

Das Brechen von SSH kommt meist nicht in Frage.

Wir haben die folgenden Einstellungen bei einem Kunden vor Ort:

• Ebenfalls offen für die Authentifizierung mit Kerberos in AD (persönliche Konten)
• Autorisierung nur für bestimmte AD-Gruppen von Unix-Administratoren
• sudoers group == AD group
• OSSEC HIDS- Agenten auf jedem Server und ein Manager auf einem gehärteten Server
• OSSEC Web UI
• Splunk 3 mit Splunk-for-OSSEC

Es protokolliert jede sudo-Nutzung auf den Servern und verfolgt auch alle Änderungen an Dateien, die Installation von Paketen, verdächtige Prozesse usw.

Wir haben mehrere Terminalserver, um auf alle unsere Geräte zuzugreifen. Das heißt, man kann sich entweder vom Terminalserver aus oder wenn man physischen Zugriff hat, bei allem anmelden.

Sshd auf Terminalservern ist mit http://www.kdvelectronics.eu/ssh-logging/ssh-logging.html gepatcht , funktioniert einwandfrei, wurde aber lange nicht aktualisiert. Ich habe es ein wenig modifiziert, um mit openssh 4.7 zu arbeiten, aber es ist mir mit 5.1 nicht gelungen. Gepatchte sshd segfaults, und solange ich nicht genug Zeit habe, um das zu beheben, bin ich fast auf ttyrpld umgestiegen.

Bisher habe ich Folgendes:

• sudosh : scheint A und B zu unterstützen (bei A allerdings nicht ganz sicher)
• Sudoscript : scheint B zu unterstützen (Sudoscript hat eine Komponente namens sudoshell, und wenn Romandas dies vorgeschlagen haben, danke für den Tipp)
• Snoopy Logger oder sudo_exetrace : nicht genau das, wonach ich suche, aber eine gute Ergänzung sein könnte (dank theotherreceive und blauwblaatje für diese Links)

Kennen Sie ähnliche Tools, bei denen der Kernel oder andere Systemkomponenten nicht gepatcht werden?