Kann root sehen was user macht?
- Ersteller Lock
- Erstellt am
Ja, kann man. Guck dir einfach die .bash-history im Userverzeichnis an. Und wenn der User Dinge tut, die im System Auswirkungen haben, d. h. sudo nutzen, sieht man das (bei Debian) im auth.log.
AN00BIS
/dev/comfy
Sobald der User erfolgreich "sudo su" ausgeführt hat ist er als root User aktiv, sprich die weiteren Schritte landen in der History des root Users unter /root/.bash_history. Wie Metal_Warrior erwähnt hat wird je nach Distro ein auth.log geschrieben. Unter Debian/Ubuntu/Mint findest du dieses unter /var/log/auth.log. Der Command "last" gibt dir ausserdem eine Übersicht über die Usersessions.
BurnerR
Bot #0384479
- Registriert
- 20 Juli 2013
- Beiträge
- 5.311
Vor allem kann der user, der sich dann als root eingeloggt hat alle diese Dateien bearbeiten und generell alles auf und mit dem Computer machen. Es klingt so ein bisschen danach, dass ein User sich root-Rechte 'verschafft' hat. Damit ist der Drops gelutscht und du wirst nicht nachvollziehen können was passiert oder nicht passiert ist.
Damit ist, wie BurneR schon richtig sagt, der Drops gelutscht. Dein System ist kompromittiert, die Logdateien wertlos und du kannst es gleich neu aufsetzen, wenn das Kommando erfolgreich war und der besagte User nicht voll vertrauenswürdig.
DukeMan999
Duke Nukem Master
- Registriert
- 14 Juli 2013
- Beiträge
- 317
Un wenn die besagte /root/.bash_history noch da ist, paste den inhalt dochmal in einem Code block hier hinein, da kann man mal kucken was so gemacht wurde.
Mfg
Mfg
@DukeMan999: Selbst wenn sie noch da ist, kann root sie beliebig manipulieren - daher: Neu installieren.
Also nur weil sudo su - in der history steht, heisst das noch lange nicht, dass das System kompromitiert wurde. Da muss man ja auch noch das Passwort dazu haben. Aber man kann ja mal die Ueblichen checks machen, ob das System wirklich kompromtiert wurde und ja, root kann alles sehen was ein user macht.
BurnerR
Bot #0384479
- Registriert
- 20 Juli 2013
- Beiträge
- 5.311
Um das nochmal zu ordnen:
Fall A: User hat eventuell Zugriff auf den root Account gehabt -> System muss platt gemacht werden und neu aufgesetzt. Mit anderem Passwort/Credentials
.
Fall B: User hatte keinen Zugriff auf den root Account gehabt -> die fehlgeschlagenen Einwahlversuche per sudo kannst wie hier erwähnt nachvollziehen
Was nicht geht: In den logfiles nachvollziehen, ob ein User sich root Rechte verschafft hat oder nicht.
Fall A: User hat eventuell Zugriff auf den root Account gehabt -> System muss platt gemacht werden und neu aufgesetzt. Mit anderem Passwort/Credentials
.Fall B: User hatte keinen Zugriff auf den root Account gehabt -> die fehlgeschlagenen Einwahlversuche per sudo kannst wie hier erwähnt nachvollziehen
Was nicht geht: In den logfiles nachvollziehen, ob ein User sich root Rechte verschafft hat oder nicht.
Ja, und zwar das eigene. Das jeder User hat, sonst wäre er nicht am System angemeldet.
Sudo fragt in der Grundkonfig immer das Passwort des Users ab. su würde das Passwort des Root-Users abfragen, aber da su nur die Variable/Parameter für sudo ist, gilt was sudo tut, und wenn das erfolgreich war (was der Fall ist, wenn der ausführende User in der Gruppe sudo ist oder in der sudoers-File {Wildcard-,für diesen expliziten Aufruf} Rechte hat), ist su per root ausgeführt und damit stellt su nur noch die interaktive Shell für den root-User bereit, ohne Rückfrage.
Es steht nach wie vor, was BurnerR und ich gesagt haben: War der Zugriff erfolgreich, ist das System Schrott. Kann man das hinterher rausfinden, wenn er erfolgreich gewesen sein konnte? Nein.
Ergo: Besteht auch nur der geringste Zweifel an der Erfolglosigkeit des Versuchs, kann die Maschine als kompromittiert eingestuft werden.
darksider3
NGBler
Ja. "Kann man"? Ja. Definitiv, 100%. Will man?
Vollkommener Ausschluss ist im übrigen auch absolut unwissenschaftlich, wie ich von deinen unermüdlichen Erklärungsdrang in anderen Threads bisher lernen durfte. Ganz besonders, wenn der User offenbar zu Dumm war, sich trotz dieser Fähigkeiten als Root zu etablieren, und dennoch die bash_history nicht weiter fingiert hat. Toplol.
Davon abgesehen gehe ich nun auf den Server meines Shared-Hosters und führe sudo su aus, damit er endlich den Server neu aufsetzt. Schließlich wird er und sein Default-Debian jetzt voller Angst erzittern, alsbald er es Rotleuchend in seiner Holobrille aufblitzen sieht und Siri laut
You do not have permission to view link please Anmelden or Registrieren
summt.
- Registriert
- 14 Juli 2013
- Beiträge
- 3.542
Wie findest Du denn raus ob jemand Deine Logfiles gefälscht hat?
darksider3
NGBler
You do not have permission to view link please Anmelden or Registrieren
Ganz einfach. Wie findest Du raus, ob jemand nicht deine Logfiles gefälscht hat?Genau. Er hat es nicht einmal geschafft, den einzigen eindeutigen Beweis zu vernichten, den er produzieren konnte. Beweis durch Unfähigkeit oder Unwissenheit eindeutig erbracht.
- Registriert
- 14 Juli 2013
- Beiträge
- 3.542
Sehr guter Punkt.
Allerdings, wenn ich Dir Deinen Rechner kompromittiere, alle Logs fälsche und Dir zum Futter sudo su da lasse ...
Selbst wenn ich ausgerechnet das aus Blödheit oder was auch immer vergessen sollte zu löschen/faken änderts ja nix dran, dass Du nicht weisst, was ich auf Deinem Rechner gemacht hab.
Bleibt imho aus "sehr guter Punkt" nur noch semigutes Indiz über, dass nix passiert ist.
@darksider3: Wozu würde ich als Einbrecher einen Hinweis vernichten, der in deinen Augen meine Unfähigkeit beweist?
Das ist etwa so, wie direkt zur nächsten Staatsgrenze zu fliehen, wenn man ausm Gefängnis ausgebrochen ist. Wesentlich dümmer als sich direkt im Nachbarskeller zu verstecken.
Das ist etwa so, wie direkt zur nächsten Staatsgrenze zu fliehen, wenn man ausm Gefängnis ausgebrochen ist. Wesentlich dümmer als sich direkt im Nachbarskeller zu verstecken.
darksider3
NGBler
Weil ich nicht sehe, wieso man ausgerechnet das Faken sollte. Wenn es denn füttern soll, warum ausgerechnet dort? Wieso einen User anzeigen, statt einfach einen Log woanders produzieren, z.B. /var/log/auth? Weniger Hinweise, mysteriöser, bei jedem ordentlichen Monitoring direkte 300 Alarmmeldungen, anders als bei der bash_history.
Außerdem: Wieso überhaupt?
Wie bisher scheint, ist es ja überhaupt erst deshalb aufgefallen, d.h. es war zumindest keine systemschädigende Aktion. Damit wird ja effektiv alles ausgeschlossen, was irgendwie mitlaufen soll, weil es ja ansonsten schon kein sudo su gäbe, dass eurer Meinung nach derartig gefährlich sei.
You do not have permission to view link please Anmelden or Registrieren
Ich würde es eher damit Vergleichen, die Festplatten zu zerstören, weil irgendjemand mit einem Script versucht hat root@ an deinem SSH zu erreichen und Standardpasswörter verwendet hat.Weil alleine dieser Hinweis es ist, der dein Gegenüber dazu gebracht hat zu wissen, dass Du ausgebrochen bist.
Stellst Du dich also vor die Gefängnistore und schreist die Wachen an, dass Du gerade ausgebrochen bist, beim Schichtwechsel?
Wenn Du das damit vergleichen willst, warum schießt er nicht gleich den gesamten User weg? Wäre das nicht noch auffälliger?
Es macht keinen Sinn eine Fackel zu werfen, um jemanden zu verwirren, wenn man irgendwo unbemerkt eingebrochen ist.
Zuletzt bearbeitet:
- Registriert
- 14 Juli 2013
- Beiträge
- 3.542
Du hast da wahrscheinlich Recht, aber was ist in dem Falle, wenn ich alles "richtig" gemacht hab, aber nur diese eine "Idiotie" vergessen hab?
Das kannst Du nicht ausschliessen, also weisst Du nicht, was auf Deinem Rechner ist. (s.O.: Indiz)
Das kannst Du nicht ausschliessen, also weisst Du nicht, was auf Deinem Rechner ist. (s.O.: Indiz)
Jetzt mal anders herum: Hat denn der eigentliche Admin eine Mail bekommen? Sowas richtet man ein, üblicherweise. Wenn dann ein Sudo, das an sich ja nicht gefährlich ist, fehlschlägt, sendet zumindest ein Debian eine Security-Meldung.
Gab es die denn?
Gab es die denn?