Pliki znikają na serwerze Linux

Mam 4 określone pliki, które wydają się znikać z katalogu domowego użytkownika. O ile nam wiadomo, nie ma żadnych cronjobs ani innych zautomatyzowanych zadań, które mogłyby je usunąć. Skonfigurowałem na nich audyty, ale logi tak naprawdę nie pokazują niczego interesującego. Widzę, że nasze narzędzie do tworzenia kopii zapasowych uzyskuje do nich dostęp każdej nocy, aż do momentu, gdy ich już nie ma, ale nic więcej. Czy jest coś, co mogłoby spowodować usunięcie tych plików, które obejdzie się wokół audytu?

Są to następujące pliki:

/home/username/.bashrc
/home/username/.bash_profile

a także kilka plików w katalogu .ssh tego użytkownika. Kopie tych plików umieszczone w podfolderze o nazwie „opiekunowie” również są usuwane w tym samym czasie. Zmiana uprawnień do nich na 000 i posiadanie ich przez roota nie pomogła.

Obecnie mam konfigurację inotifywait do rejestrowania tworzenia, usuwania i przenoszenia w tym podfolderze, więc mam nadzieję, że coś się zmieni, chociaż nie loguje się zbyt wiele, gdy to się stało, a nie to, co spowodowało.

Rozwiązanie 1 : Systemtap
Możesz użyć systemtap, aby wyświetlić wszystkie PID, które próbują użyć unlink () na i-węzle .bashrci .bash_profileplików.

Zainstaluj systemtap i symbole debugowania dla twojego jądra.

Utwórz plik o nazwie unlink.stapo następującej treści:

probe syscall.unlink
{
    printf ("%s(%d) unlink (%s) userID(%d)\n", execname(), pid(), argstr, uid())
}

Następnie uruchom go sudo stap unlink.stap

Rozwiązanie 2 : inotify
Możesz również użyć inotify, aby zobaczyć, kiedy plik zostanie usunięty.

Rozwiązanie 3 : ftrace
Innym rozwiązaniem jest użycie ftrace :

trace-cmd record -e \*unlink\*

Poczekaj na usunięcie pliku, naciśnij CTRL + C, aby zatrzymać trace-cmd record ..., a następnie uruchom:

trace-cmd report

Rozwiązanie 4 :
Zainstaluj bpftrace bpftrace, a następnie uruchom:

bpftrace -e 'tracepoint:syscalls:sys_enter_unlink* { printf("%s %s\n", comm, str(args->pathname)); }'

oprócz odpowiedzi micei, możesz chattr + i pliki jako root i zobaczyć, czy coś rejestruje błąd podczas próby ich usunięcia.

Czy jesteś absolutnie pewien, że sam użytkownik ich (przypadkowo) nie usuwa?

Miałem kilku użytkowników (Windows) z tym samym problemem. Okazało się, że sami usuwali te pliki za każdym razem, gdy odwiedzali swój katalog domowy z klientem ftp. Zauważyli pliki .xxxx (klient ftp ich nie ukrył) i usunęli „bałagan”.

Nigdy nie przyszło mi do głowy, że zrobili to sobie, dopóki jeden z nich nie skarżył się na spontanicznie pojawiające się pliki, które usunął kilka dni wcześniej.

Używamy skryptów bash wylogowania (~ / .bash_logout) do czyszczenia niektórych plików po wylogowaniu - możesz sprawdzić, czy masz taką konfigurację, być może z grubymi palcami globu.

Więcej wydaje się być intruzem, który wykonuje find / home / user -name nazwa -pliku -exec rm -f {} \; przecież jego skradanie się :). Zgaduję, ponieważ wspomniałeś, że pliki kopii zapasowej również są usuwane.

Aby zapobiec utracie plików i ich zawartości, możesz ustawić libtrash poprzez LD_PRELOAD. Korzystając z libtrash możesz robić wiele rzeczy, ale takie, które mogą być dla ciebie interesujące

INTERCEPT_UNLINK
INTERCEPT_RENAME
INTERCEPT_FOPEN
INTERCEPT_OPEN

Dobry artykuł o libtrash można znaleźć tutaj

Inną rzeczą, o której wspomniałeś, jest to, że przeglądałeś pliki do rootowania i nadal zostały usunięte. Jest tak, ponieważ / home / nazwa użytkownika jest własnością nazwy użytkownika; a jeśli dir powiedział mod 755; następnie dowolny plik lub katalog w tym katalogu, którego właścicielem jest bez względu na to, kto może go usunąć; nawet jeśli jest to plik root lub katalog. Zasadniczo wynika to z faktu, że usunięcie pliku w katalogu oznacza zmianę zawartości katalogu, a użytkownik ma 7 (w 755) tego katalogu, dzięki czemu może robić, co chce.

Istnieją sposoby, aby to zablokować, ponieważ inne osoby już sugerowały za pośrednictwem chattr w systemach plików ext, aby ustawić pliki jako niezmienne (+ i). Następnie należałoby rozbroić niezmienną flagę przed dokonaniem jakichkolwiek zmian w pliku / katalogu, który ma flagę + i. Niezmienna flaga / chattr może być używana tylko przez root.