staging.inyokaproject.org

Nun haben wir den 2. Fall in der Familie, dass ein Verzeichnis verschwunden ist.

https://forum.ubuntuusers.de/topic/bash-user-cronjob-waehrend-script-laeuft-deakt/#post-9463303 Plötzlich waren alle Scripts weg. Vorweg, alles von einem anderen PC gerettet Nachdem ich das Backup-Script organsiatorisch geändert habe, hatte ich alle Sicherungen gelöscht. Als ich fertig war und das Script nochmals testen wollte, konnte ich es nicht aufrufen. /usr/local/bin ist bei mir auf eine "Daten"-Partition verlinkt, damit habe ich es nach einer Neuinstallation einfacher. Der Link war noch da, aber auf der Daten-Partition war der komplette Ordner weg, auch nach einem Reboot. Ok, ich mache viel auf der Konsole und lösche viel mit rm, da denkt man primär daran, ein falsches Verzeichnis gelöscht zu haben, aber in der bash_history war nichts in dieser Richtung zu finden. Da ssh-Verbindung, kommt Löschen per Maus nicht in Frage.

Im 1. Fall waren alle Scripte weg, im 2. Fall alle Mails. Sicherung ist vorhanden, aber das ist schon mysteriös. Im 1. Fall Xubuntu 24.04, im 2. Fall Xubuntu 22.04 Beide PCs an unterschiedlichen Standorten und nicht miteinnderer über das Internet verbunden.

Kann man da irgendwelche Malware-Scans machen?

Da von Scripten geredet wird, da kann es schnell mal passieren, daß man ein Typo in einer Variable hat und aus rm $ordner/datei wird rm /datei o.ä., shellcheck kann da manchmal weiterhelfen. Natürlich kanns da auch Fehler geben die man nicht automatisch findet.

Falls irgendwas mit /dev/shm gemacht wird. Da löscht systemd auch fleissig. /dev/shm war früher meine Spielwiese für Experimente, aber am besten ist, man benutzt es gar nicht. Insbesondere nicht für Mounts... einmal blinzeln, alles weg.

Malware-Scans... kannst du ziemlich vergessen. Man könnte rm durch einen Wrapper ersetzen der alle Aufrufe protokolliert und ähnliches mit inotify/selinux/apparmor/... versuchen, aber es gibt unzählige Möglichkeiten, Dateien zu löschen.

Auf Linux-Dateisystemen kann man einzelne Dateien mit chattr +i unlöschbar machen. Mit etwas Glück gibts dann lustige Fehlermeldungen beim nächsten Löschversuch aber das halt auch nur, wenn die Programme die da so laufen, irgendwie mitgeloggt werden.

Früher gabs /proc/sys/vm/block_dump um alle möglichen Zugriffe im Kernellog mitprotokollieren zu lassen. Heute geht das nur noch mit Tracepoints. Aber wenn man das macht (Zugriffslogs auf Kernelebene) hat man so ewig viel Ausgabe. Die muss man ja auch wieder irgendwo speichern (was wenns blöd läuft zu neuen Ausgaben führt und das Ding dreht sich im Kreis). Und dann muss da noch jemand durchblicken.

Wenn jemand einen einfacheren Weg kennt, um "wer hat wann was gelöscht" auf die Schliche zu kommen, immer her damit. Fehlt mir noch im Repertoire.

Da von Scripten geredet wird, da kann es schnell mal passieren, daß man ein Typo in einer Variable hat und aus rm $ordner/datei wird rm /datei

Ja, früher schon passiert. Ich lösche in Scripten nur mehr ausnahmsweise und dann mehrfach abgesichert, vor allem nicht mit einer Variablen alleine, sondern irgendeinen Text dabei und keine Wildcards.

Gefährlich kann auch rsync und lftp sein, wenn man synchronisiert.

Bis jetzt kann ich aber aus dieser Richtung alles ausschließen. Habe in die Scripts geschaut, die ich in letzter Zeit intensiver verwende, weil ich ändere und teste. Da gibt es kein rm und rsync tut was es soll, dh richtige Richtung von Quelle und Ziel.

In diesem Fall ist das aber einem anderen User passiert, der (noch) nicht von meinen Scripts beglückt wurde, mein neues Mini-Backup muss bei mir noch intensiver getestet werden. Vor lauter Schrecken habe ich jetzt auf einen USB-Stick wichtige Dinge kopiert. Ich will die externen HDs vorsichtshalber nicht anrühren.

Es ist einfach verdammt komisch, was da passiert. Ok, dass ich einen Fehler mache, soll so sein und Daten werden gelöscht. Aber ähnliches bei einem 2. User, schon sehr komisch.

Falls irgendwas mit /dev/shm gemacht wird

Nein, nichts.

Mit etwas Glück gibts dann lustige Fehlermeldungen

Das Problem ist, dass man das Löschen nur zufällig merkt. Ich hatte das Script verloren und konnte es nicht starten, und das andere Familienmitglied brauchte dringend ein Mail mit Zugangscode für ein Online-Meeting.

Wenn da Malware unterwegs ist, wird es schwierig. Logwatch ist installiert, aber ich habe keine Ahnung wie ich das dafür nutzen soll. Mich interessiert da primär ham und spam.

Löschen vom System aus protokollieren wäre schon interessant. Es wäre schon hilfreich wann und womit komplette Verzeichnisse mit Unterverzeichnissen gelöscht werden.

Malware-Scans... kannst du ziemlich vergessen.

Ich überlege gerade in die andere Richtung. Vielleicht komme ich mit mit auditd weiter.

Nehmen wir mal an, das Verzeichnis wurde durch einen User-Fehler oder ein lokales Script gelöscht. Wie könnte ich da eine sinnvolle auditd-Regel erstellenn?

Mir würde es vorerst reichen, wenn nur das Löschen kompletter Verzeichnisse geloggt wird, aber dann alles unterhalb von /

Vielleicht findet sich hier ein Ansatz: https://www.ucartz.com/clients/knowledgebase/1186/How-to-use-auditd-to-monitor-a-file-deletion-in-Linux.html

Aber:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 auditd : Hängt ab von: libaudit1 (= 1:3.1.2-2.1build1) aber 1:3.1.2-2.1build1.1 soll installiert werden
          Hängt ab von: libauparse0t64 (= 1:3.1.2-2.1build1) soll aber nicht installiert werden
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.

Hier passen die Versionen:

apt show auditd
Package: auditd
Version: 1:3.1.2-2.1build1.1
[...]
Depends: libaudit1 (= 1:3.1.2-2.1build1.1), libauparse0t64 (= 1:3.1.2-2.1build1.1),

Mal mit apt policy nachgesehen?

~# apt policy auditd
auditd:
  Installiert:           (keine)
  Installationskandidat: 1:3.1.2-2.1build1
  Versionstabelle:
     1:3.1.2-2.1build1 500
        500 http://at.archive.ubuntu.com/ubuntu noble/main amd64 Packages

~# apt show auditd
Package: auditd
Version: 1:3.1.2-2.1build1
Priority: extra
Section: admin
Source: audit
Origin: Ubuntu
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Laurent Bigonville <bigon@debian.org>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 726 kB
Pre-Depends: init-system-helpers (>= 1.54~)
Depends: libaudit1 (= 1:3.1.2-2.1build1), libauparse0t64 (= 1:3.1.2-2.1build1), mawk | gawk, libc6 (>= 2.38), libcap-ng0 (>= 0.7.9)
Suggests: audispd-plugins
Breaks: audispd-plugins (<< 1:3.0~)
Homepage: https://people.redhat.com/sgrubb/audit/
Download-Size: 215 kB
APT-Sources: http://at.archive.ubuntu.com/ubuntu noble/main amd64 Packages
Description: Userspace-Werkzeuge für Sicherheitsprüfungen
 Das Paket Audit enthält die Userspace-Dienstprogramme für die Speicherung
 und Abfrage der vom Audit-Subsystem des 2.6er Kernels erzeugten Audit-
 Datensätze.
 .
 Es enthält auch den Audit Dispatcher »audispd«.

~# apt install libauparse0t64
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 libauparse0t64 : Hängt ab von: libaudit1 (= 1:3.1.2-2.1build1) aber 1:3.1.2-2.1build1.1 soll installiert werden
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.

noble-updates für main nicht aktiv?

apt policy auditd
auditd:
  Installiert:           (keine)
  Installationskandidat: 1:3.1.2-2.1build1.1
  Versionstabelle:
     1:3.1.2-2.1build1.1 500
        500 https://mirrors.tuxedocomputers.com/ubuntu/mirror/archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages
     1:3.1.2-2.1build1 500
        500 https://mirrors.tuxedocomputers.com/ubuntu/mirror/archive.ubuntu.com/ubuntu noble/main amd64 Packages

noble-updates für main nicht aktiv?

Sollte wohl unter /etc/apt/sources.list.d zu finden sein. Wonach muss ich genau suchen? "apt update / upgrade" wurde gerade noch einmal gemacht.

# grep -r -i main /etc/apt/ | grep noble
/etc/apt/sources.list.d/yubico-ubuntu-stable-noble.sources:Components: main
/etc/apt/sources.list.d/yubico-ubuntu-stable-noble.sources.save:Components: main

bzw.

# grep -r -i noble /etc/apt/
/etc/apt/sources.list.d/ubuntu.sources:Suites: noble
/etc/apt/sources.list.d/ubuntu.sources:Suites: noble-security
/etc/apt/sources.list.d/ubuntu.sources.curtin.orig:Suites: noble noble-updates noble-backports
/etc/apt/sources.list.d/ubuntu.sources.curtin.orig:Suites: noble-security
/etc/apt/sources.list.d/yubico-ubuntu-stable-noble.sources:Suites: noble
/etc/apt/sources.list.d/ubuntu.sources.save:Suites: noble
/etc/apt/sources.list.d/ubuntu.sources.save:Suites: noble-security
/etc/apt/sources.list.d/yubico-ubuntu-stable-noble.sources.save:Suites: noble

Ergänzung: Mit einem anderen PC kann ich auditd installieren:

~# apt install auditd
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  libauparse0t64
Vorgeschlagene Pakete:
  audispd-plugins
Die folgenden NEUEN Pakete werden installiert:
  auditd libauparse0t64
0 aktualisiert, 2 neu installiert, 0 zu entfernen und 39 nicht aktualisiert.
Es müssen 274 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 893 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] 
Holen:1 http://at.archive.ubuntu.com/ubuntu noble-updates/main amd64 libauparse0t64 amd64 1:3.1.2-2.1build1.1 [58,9 kB]
Holen:2 http://at.archive.ubuntu.com/ubuntu noble-updates/main amd64 auditd amd64 1:3.1.2-2.1build1.1 [215 kB]
Es wurden 274 kB in 0 s geholt (1.531 kB/s).
Vormals nicht ausgewähltes Paket libauparse0t64:amd64 wird gewählt.
(Lese Datenbank ... 396209 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../libauparse0t64_1%3a3.1.2-2.1build1.1_amd64.deb ...
»Umleitung von /lib/x86_64-linux-gnu/libauparse.so.0 zu /lib/x86_64-linux-gnu/libauparse.so.
0.usr-is-merged durch libauparse0t64« wird hinzugefügt
»Umleitung von /lib/x86_64-linux-gnu/libauparse.so.0.0.0 zu /lib/x86_64-linux-gnu/libauparse
.so.0.0.0.usr-is-merged durch libauparse0t64« wird hinzugefügt
Entpacken von libauparse0t64:amd64 (1:3.1.2-2.1build1.1) ...
Vormals nicht ausgewähltes Paket auditd wird gewählt.
Vorbereitung zum Entpacken von .../auditd_1%3a3.1.2-2.1build1.1_amd64.deb ...
Entpacken von auditd (1:3.1.2-2.1build1.1) ...
libauparse0t64:amd64 (1:3.1.2-2.1build1.1) wird eingerichtet ...
auditd (1:3.1.2-2.1build1.1) wird eingerichtet ...
Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → /usr/lib/system
d/system/auditd.service.
Trigger für man-db (2.12.0-4build2) werden verarbeitet ...
Trigger für libc-bin (2.39-0ubuntu8.3) werden verarbeitet ...

Ich weiß jetzt nicht, wie das bei einem original installierten Ubuntu ist, bei meinem Ubuntu 24.04 Server schauts so aus:

Suites: noble-updates noble-backports noble-security

Und bei Compnents halt auch das, was man braucht, bei mir:

Components: main restricted universe ...

In meinem Fall stehen die offiziellen Paketquellen, das bei dir sieht eher nach einer Fremquelle aus, hier:

/etc/apt/sources.list.d/ubuntu.sources

Ich habe jetzt oben ergänzt, während du gepostet hast.

Auf einem anderen PC läuft es durch. Beide PCs sind Original-Xubuntu Installationen, gleicher USB-Stick.

0 aktualisiert, 2 neu installiert, 0 zu entfernen und 39 nicht aktualisiert.

Sehe da aber keinen Zusammenhang zu der auditd-Installation

Folgende Aktualisierungen wurden aufgrund von gestaffelter Auslieferung vorerst zurückgehalten:
  grub-efi-amd64 grub-efi-amd64-bin libdrm-amdgpu1 libdrm-common libdrm-intel1
  libdrm-nouveau2 libdrm-radeon1 libdrm2 libmpc3 libnfsidmap1 libnghttp2-14 libnss-systemd
  libpam-systemd libpcre2-16-0 libpcre2-32-0 libpcre2-8-0 libpcre2-dev libpcre2-posix3
  libperl5.38t64 libsystemd-dev libsystemd-shared libsystemd0 libudev-dev libudev1
  nfs-common nfs-kernel-server perl perl-base perl-modules-5.38 python3-distupgrade
  systemd systemd-dev systemd-resolved systemd-sysv systemd-timesyncd
  ubuntu-release-upgrader-core ubuntu-release-upgrader-gtk udev
Die folgenden Pakete sind zurückgehalten worden:
  grub-efi-amd64-signed
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 39 nicht aktualisiert.

Jups, wenn man was geändert hat an den Quellen, nochmal sudo apt update. Du brauchst halt noble-updates für main.

Öffne einfach mal die Datei ubuntu.sources.

# cat /etc/apt/sources.list.d/ubuntu.sources
Types: deb
URIs: http://at.archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Damit konnte ich problemlos installieren und mit folgender Datei nicht:

# cat /etc/apt/sources.list.d/ubuntu.sources
Types: deb
URIs: http://at.archive.ubuntu.com/ubuntu/
Suites: noble
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: noble-security
Components: universe restricted main multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Interessant wie die unterschiedlichen Konfigurationen zustande kommen. Da habe ich garantiert nichts editiert.

Bei meinem Server wurde von 22.04 auf 24.04 geupgradet, ich meine, da habe ich auch anschließend was editiert. Auf dem Desktop habe ich kein originales Ubuntu, verwendet aber auch die Quellen.

Ich würde bei Suites einfach ergänzen: noble-updates noble-backports

Ich habe jetzt die Einträge von PC genommen, wo auditd installiert werden konnte.

Stellt sich die Frage ob Bug oder Malware-Angriff. Ist natürlich genial einen Teil der Updates zu deaktivieren.

Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Aktualisierung für 89 Pakete verfügbar. Führen Sie »apt list --upgradable« aus, um sie anzuzeigen.

Das hat gefehlt:

# apt upgrade
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Paketaktualisierung (Upgrade) wird berechnet… Fertig
Get more security updates through Ubuntu Pro with 'esm-apps' enabled:
  vlc-plugin-qt libvlc5 libdcmtk17t64 vlc-data libvlccore9 dcmtk vlc
  libavcodec-extra vlc-bin libdcmtk-dev vlc-l10n libcjson1 libavdevice60
  ffmpeg libpostproc57 vlc-plugin-samba libavcodec-extra60 vlc-plugin-notify
  libavutil58 libswscale7 vlc-plugin-access-extra vlc-plugin-skins2
  vlc-plugin-video-splitter libswresample4 vlc-plugin-video-output
  libavformat60 python3-tqdm libvlc-bin vlc-plugin-base
  vlc-plugin-visualization libavfilter9
Learn more about Ubuntu Pro at https://ubuntu.com/pro
Folgende Aktualisierungen wurden aufgrund von gestaffelter Auslieferung vorerst zurückgehalten:
  grub-common grub2-common libdrm-amdgpu1 libdrm-common libdrm-intel1 libdrm-nouveau2
  libdrm-radeon1 libdrm2 libmpc3 libmpfr6 libnss-systemd libpam-systemd libsystemd-dev
  libsystemd-shared libsystemd0 libudev-dev libudev1 python3-distupgrade systemd
  systemd-dev systemd-resolved systemd-sysv systemd-timesyncd ubuntu-release-upgrader-core
  ubuntu-release-upgrader-gtk udev
Die folgenden Pakete werden aktualisiert (Upgrade):
  alsa-ucm-conf bpftrace bsdextrautils bsdutils eject fdisk firmware-sof-signed
  grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed kmod libaio1t64 libattr1
  libblkid-dev libblkid1 libbsd0 libcap2 libcap2-bin libdebuginfod-common
  libdebuginfod1t64 libdw1t64 libelf1t64 libfdisk1 libgmp10 libgpg-error-l10n
  libgpg-error0 libidn2-0 libisl23 libkmod2 libmd0 libmount1 libnautilus-extension4
  libnghttp2-14 libnl-3-200 libnl-genl-3-200 libnl-route-3-200 libpam-cap libpcre2-16-0
  libpcre2-32-0 libpcre2-8-0 libpcre2-dev libpcre2-posix3 libperl5.38t64 libselinux1
  libselinux1-dev libsmartcols1 libsqlite3-0 libunistring5 libuuid1 linux-firmware mount
  nautilus nautilus-data perl perl-base perl-modules-5.38 rfkill sqlite3 util-linux
  uuid-dev uuid-runtime wireless-regdb xfsprogs
63 aktualisiert, 0 neu installiert, 0 zu entfernen und 26 nicht aktualisiert.
Es müssen 544 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 42,2 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n]

Jetzt lief die Installation auch hier durch:

# apt install auditd
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  libauparse0t64
Vorgeschlagene Pakete:
  audispd-plugins
Die folgenden NEUEN Pakete werden installiert:
  auditd libauparse0t64
0 aktualisiert, 2 neu installiert, 0 zu entfernen und 26 nicht aktualisiert.
Es müssen 274 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 893 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] 
Holen:1 http://at.archive.ubuntu.com/ubuntu noble-updates/main amd64 libauparse0t64 amd64 1:3.1.2-2.1build1.1 [58,9 kB]
Holen:2 http://at.archive.ubuntu.com/ubuntu noble-updates/main amd64 auditd amd64 1:3.1.2-2.1build1.1 [215 kB]
Es wurden 274 kB in 0 s geholt (1.723 kB/s).
Vormals nicht ausgewähltes Paket libauparse0t64:amd64 wird gewählt.
(Lese Datenbank ... 398179 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../libauparse0t64_1%3a3.1.2-2.1build1.1_amd64.deb ...
»Umleitung von /lib/x86_64-linux-gnu/libauparse.so.0 zu /lib/x86_64-linux-gnu/libauparse.so.
0.usr-is-merged durch libauparse0t64« wird hinzugefügt
»Umleitung von /lib/x86_64-linux-gnu/libauparse.so.0.0.0 zu /lib/x86_64-linux-gnu/libauparse
.so.0.0.0.usr-is-merged durch libauparse0t64« wird hinzugefügt
Entpacken von libauparse0t64:amd64 (1:3.1.2-2.1build1.1) ...
Vormals nicht ausgewähltes Paket auditd wird gewählt.
Vorbereitung zum Entpacken von .../auditd_1%3a3.1.2-2.1build1.1_amd64.deb ...
Entpacken von auditd (1:3.1.2-2.1build1.1) ...
libauparse0t64:amd64 (1:3.1.2-2.1build1.1) wird eingerichtet ...
auditd (1:3.1.2-2.1build1.1) wird eingerichtet ...
Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → /usr/lib/system
d/system/auditd.service.
Trigger für man-db (2.12.0-4build2) werden verarbeitet ...
Trigger für libc-bin (2.39-0ubuntu8.3) werden verarbeitet ...

Aber ich habe /usr/local/bin an dem PC verloren, wo auditd installierbar war.

Ich habe nun https://www.ucartz.com/clients/knowledgebase/1186/How-to-use-auditd-to-monitor-a-file-deletion-in-Linux.html folgend das gemacht:

Auf meinem PC nach der Installation:

~# auditctl -l 
No rules

Nach der Installation sieht es so aus:

/etc/audit/rules.d/audit.rules
-D
-b 8192
--backlog_wait_time 60000
-f 1

Nach Neustart:

vim /etc/audit/rules.d/audit.rules

-D auskommentiert und folgendes eingefügt:

-a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat  -S rmdir -k delete

Ergibt folgende Konfiguration:

/etc/audit/rules.d/audit.rules
-a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat  -S rmdir -k delete
-b 8192
--backlog_wait_time 60000
-f 1

Test nach Neustart:

~# auditctl -l 
-a always,exit -F arch=b64 -S rename,rmdir,unlink,unlinkat,renameat -F key=delete

Eigentlich habe ich einiges RAM frei:

$ free
               gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:   13197736     3153064     8996876       12508     1326608    10044672
Auslager:    2169852           0     2169852

-b 8192 erhöhen?

--backlog_wait_time 60000 erhöhen?

So und jetzt bitte eure Konfigurationsempfehlungen?

Ich habe mal testweise mit touch eine Datei angelegt, die finde ich nach dem Löschen nicht. Getestet habe ich Löschen mit der Maus und mit rm.

Hmmh ganz komisch, jetzt sehe ich Gelöschtes (Maus oder rm) meistens im Log, aber manchmal nicht. Ein paar Sekunden warte ich nach dem Löschen, wenn ich das Log prüfe.

Habe mal probiert durch ein Script zu löschen. Datei über kopieren erstellt und dann per Bash-Script gelöscht.

~# cat /var/log/audit/audit.log | grep testscript
type=PATH msg=audit(1738311526.169:2673): item=3 name="/daten/testscript.zip" inode=23571875 dev=103:0a mode=0100664 ouid=1000 ogid=1000 rdev=00:00 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID="ab" OGID="ab"

Wäre ja interessant wodurch die Datei erstellt wurde, in diesem durch Kopieren mit der Maus und umbenennen.

type=PATH msg=audit(1738311625.066:3230): item=1 name="/daten/testscript.zip" inode=23571875 dev=103:0a mode=0100664 ouid=1000 ogid=1000 rdev=00:00 nametype=DELETE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID="ab" OGID="ab"

Ich sehe, dass die Datei gelöscht wurde, aber nicht durch welches Script. Das wäre ja interessant, wenn ein Script unerwünscht was löscht.

Ich sehe da 2 Szenarien, ungewolltes Löschen eines Ordners durch einen User bzw. durch ein Script. Löschen durch Malware, wobei ich da eher annehme, dass man dann in den Logs nichts findet, wenn das gut gemacht ist.