Ermitteln, mit welchem ​​Befehl / Skript Ihre Dateien mit inotifywait gelöscht werden

650
Shin Dapaty

Einer unserer Anwendungsserver löscht regelmäßig Dateien in:

/home/test/data 

Das Problem ist, dass wir immer noch nicht wissen, welches Skript oder welcher Befehl die Dateien löscht, sodass wir versuchen, inotifywait zu verwenden. Wir können Datum und Uhrzeit protokollieren, aber die erforderlichen Informationen nicht abrufen. Kann ich dieses inotify konfigurieren / anpassen, um zu zeigen, wem Schuldner meine Dateien löscht?

Protokollbeispiel:

/opt/asd CREATE 2017/04/03-17:49:05 /opt/asd DELETE 2017/04/03-17:49:11 /opt/wira/.bash_history MODIFY 2017/04/03-17:51:29 /opt/wira/.bash_history MODIFY 2017/04/03-17:51:29 /opt/wira/.bash_history MODIFY 2017/04/03-17:51:29 /home/test/data/test DELETE 2017/04/03-17:52:16 /home/test/data/c/test DELETE 2017/04/03-17:58:00 /home/test/data/c DELETE,ISDIR 2017/04/03-17:58:00 

Dies ist unsere Konfiguration

# specify log file LOGFILE=/var/log/inotify.log # specify target directory for monitoring MONITOR=/home/test/data # specify target events for monitoring ( comma separated ) # refer ro "man inotifywait" for kinds of events EVENT=delete,modify,move 
0

2 Antworten auf die Frage

1
MariusMatutiae

Das Werkzeug, dies zu tun ist auditd was

die Userspace-Komponente an das Linux-Auditing-System. Es ist für das Schreiben von Audit-Datensätzen auf die Festplatte verantwortlich. Das Anzeigen der Protokolle erfolgt mit den Dienstprogrammen ausearch oder aureport. Das Konfigurieren der Überwachungsregeln erfolgt mit dem Dienstprogramm auditctl. Während des Startvorgangs werden die Regeln in /etc/audit/audit.rules von auditctl gelesen. Der Audit-Daemon selbst verfügt über einige Konfigurationsoptionen, die der Administrator möglicherweise anpassen möchte. Sie befinden sich in der Datei auditd.conf.

(aus dem Handbuch ). Um zu erkennen, dass eine Datei gelöscht wird, nachdem Sie das auditd- Paket installiert und gestartet haben, prüfen Sie den enthaltenden Ordner der betreffenden Datei wie folgt:

  $ berühren Sie zz $ sudo auditctl -w / home / me -p wa $ rm / home / me / zz $ sudo cat /var/log/audit/audit.log type = DAEMON_START msg = audit (1491310210.803: 235): auditd start, ver = 2.4.5 Format = roher Kernel = 4.8.0-45-generic auid = 4294967295 pid = 29913 subj = unbestimmt res = success type = USER_AUTH msg = audit (1491310280.366: 26): pid = 30060 uid = 1000 auid = 1000 ses = 2 msg = 'op = PAM: Authentifizierung acct = "e" exe = "/ usr / bin / sudo" hostname =? addr =? terminal = / dev / pts / 6 res = Erfolg type = USER_ACCT msg = audit (1491310280.366: 27): pid = 30060 uid = 1000 auid = 1000 ses = 2 msg = 'op = PAM: buchhaltung acct = "me" exe = "/ usr / bin / sudo" hostname =? addr =? terminal = / dev / pts / 6 res = Erfolg type = USER_CMD msg = audit (1491310280.366: 28): pid = 30060 uid = 1000 auid = 1000 ses = 2 msg = 'cwd = "/ home / me" type = CRED_REFR msg = audit (1491310280.366: 29): pid = 30060 uid = 0 auid = 1000 ses = 2 msg = 'op = PAM: setcred acct = "root" exe = "/ usr / bin / sudo" hostname =? addr =? terminal = / dev / pts / 6 res = Erfolg type = USER_START msg = audit (1491310280.366: 30): pid = 30060 uid = 0 auid = 1000 ses = 2 msg = 'op = PAM: session_open acct = "root" exe = "/ usr / bin / sudo" hostname =? addr =? terminal = / dev / pts / 6 res = Erfolg type = CONFIG_CHANGE msg = audit (1491310280.390: 31): auid = 1000 ses = 2 op = "add_rule" -Schlüssel = (null) list = 4 res = 1 type = USER_END msg = audit (1491310280.390: 32): pid = 30060 uid = 0 auid = 1000 ses = 2 msg = 'op = PAM: session_close acct = "root" exe = "/ usr / bin / sudo" hostname =? addr =? terminal = / dev / pts / 6 res = Erfolg type = CRED_DISP msg = audit (1491310280.390: 33): pid = 30060 uid = 0 auid = 1000 ses = 2 msg = 'op = PAM: setcred acct = "root" exe = "/ usr / bin / sudo" hostname =? addr =? terminal = / dev / pts / 6 res = Erfolg type = SYSCALL msg = audit (1491310299.535: 34): arch = c000003e syscall = 263 erfolg = ja exit = 0 a0 = ffffff9c a1 = 21b0000 a2 = 0 a3 = 15e artikel = 2 ppid = 2441 pid = 30087 auid = 1000 gid = 1000 euid = 1000 suid = 1000 fsuid = 1000 egid = 1000 sgid = 1000 fsgid = 1000 tty = pts6 ses = 2 comm = "rm" exe = "/ bin / rm" schlüssel = (null) type = CWD msg = audit (1491310299.535: 34): cwd = "/ home / me" type = PATH msg = audit (1491310299.535: 34): item = 0 name = "/ home / me" inode = 23199747 dev = fd: 00 mode = 040755 ouid = 1000 ogid = 1000 rdev = 00: 00 nametype = PARENT type = PATH msg = audit (1491310299.535: 34): item = 1 name = "zz" inode = 23205547 dev = fd: 00 mode = 0100664 ouid = 1000 ogid = 1000 rdev = 00: 00 nametype = DELETE type = PROCTITLE msg = audit (1491310299.535: 34): proctitle = 726D007A7A type = USER_CMD msg = audit (1491310321.131: 35): pid = 30120 uid = 1000 auid = 1000 ses = 2 msg = 'cwd = "/ home / me" type = CRED_REFR msg = audit (1491310321.131: 36): pid = 30120 uid = 0 auid = 1000 ses = 2 msg = 'op = PAM: setcred acct = "root" exe = "/ usr / bin / sudo" hostname =? addr =? terminal = / dev / pts / 6 res = Erfolg type = USER_START msg = audit (1491310321.131: 37): pid = 30120 uid = 0 auid = 1000 ses = 2 msg = 'op = PAM: session_open acct = "root" exe = "/ usr / bin / sudo" hostname =? addr =? terminal = / dev / pts / 6 res = Erfolg 

Ich habe den Fettdruck für das relevante Löschereignis verwendet, wobei Sie leicht die PPID, PID und den Benutzer sehen können, der den Löschvorgang durchgeführt hat.

0
George Erhard

Die Verwendung von inotifywait als Ereignisfalle ist ein guter Anfang. Wie Sie jedoch festgestellt haben, sagt es Ihnen nicht, wer / was nur wann. Zu wissen, wann ist eine großartige Möglichkeit, die Täter einzuschränken. Aber Sie brauchen mehr Informationen.

Ändern Sie als schnelle und (sehr) schmutzige Lösung vorübergehend die Dateiberechtigungen für Ihr Datenverzeichnis, sodass nur ein bestimmter Benutzer oder eine bestimmte Gruppe Dateien ändern / löschen kann. Dies führt zu einem Abbild von Fehlermeldungen, da Apps (und möglicherweise auch andere Benutzer) versuchen, die Dateien zu berühren und geschlagen zu werden. (Vorsichtsmaßnahme: Alles, was als root ausgeführt wird, umgeht dies. Daher ist hier mein Rat, Apps / Jobs über Dienstkonten auszuführen, NICHT root).

In diesen Fehlermeldungen werden die Prozesse identifiziert, die versuchen, die Dateien zu löschen. Von dort aus können Sie genauer untersuchen, welches Skript welchen Prozess startet, da alle untergeordneten Prozesse ihren übergeordneten Prozess bis hin zu init / 0 enthalten. Skripte werden wahrscheinlich eine Instanz von bash sein, aber ihr Elternteil wird entweder crond (zeitgesteuerter Job) oder eine App sein.

Eine andere Möglichkeit besteht darin, Ihre cron-Tabellen zu überprüfen, um zu sehen, welche cron-Jobs ausgeführt werden, bevor die Dateien gelöscht werden. (Wenn in Ihren Apps Jobs ausgeführt werden, ohne sie weiterzugeben, suchen Sie nach den Jobzeitplänen und Protokollen in den Apps.)

Eigentlich ist es komplexer als das. In unserem Fall muss die Datei selbst nach der Verarbeitung von "X" gelöscht werden. Das Problem ist, dass die Datei gelöscht wurde, bevor die Verarbeitung "X" erfolgt. Diese Datei wird von unserem System automatisch generiert. Deshalb können wir nicht so manipulieren, wie Sie gesagt haben, aber wir wissen das zu schätzen, danke! Shin Dapaty vor 7 Jahren 0
OK. Ich verstehe, warum Sie den Job finden müssen, weil er Ihre Workflows durcheinander bringt. Empfehlung: Nach X-Verarbeitung (evtl. dadurch ausgelöst), MOVE die Datendateien in einen Archivordner. Führen Sie dies unter einem Dienstkonto aus, das über Berechtigungen zum Ändern / Entfernen / Löschen in Ihrem ursprünglichen Ordner verfügt. Sperren Sie dann diesen Ordner, damit * nichts anderes * an diesem Ort mod / move / del geändert werden kann. Sie können das Archiv anschließend über einen Hausmeisterjob nach Belieben löschen. George Erhard vor 7 Jahren 0