Файлы исчезают на сервере Linux


13

У меня есть 4 конкретных файла, которые, кажется, продолжают исчезать из домашнего каталога пользователя. Насколько нам известно, нет cronjobs или других автоматизированных задач, которые могли бы их удалить. Я настроил на них Audit, но в журналах ничего интересного нет. Я вижу, как наша утилита резервного копирования получает к ним доступ каждую ночь, пока их больше нет, но больше ничего. Есть ли что-нибудь, что могло бы привести к удалению этих файлов, что обошло бы audd?

Рассматриваемые файлы:

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

а также несколько файлов в каталоге .ssh этого пользователя. Копии этих файлов, помещенные в подпапку «хранители», также удаляются одновременно. Изменение разрешений для них на 000 и владение ими root не помогло.

В настоящее время у меня есть inotifywait setup, чтобы регистрировать создание, удаление, перемещение в этой подпапке, так что, надеюсь, что-то появится, хотя это не вносит много изменений, когда это произошло, а не то, что вызвало это.


1
Пожалуйста, добавьте их имена и пути к вашему сообщению, это может помочь.
Шадок

2
Также может быть полезно опубликовать журналы аудита.
Янне Пиккарайнен

3
Также вы можете попробовать создать файлы с правами root и chmod 000, чтобы увидеть, удаляются ли они по-прежнему (или это вызывает что-то еще, что выдает жалобу / ошибку).
полином

5
В дополнение к chmod 0000, вы можете попробовать chattr + i, чтобы предотвратить даже удаление root
mer

1
Имейте в виду, что chattr просто помогает в файловых системах ext. но чаттр должен помочь. :-) Вы также можете использовать SELINUX вместо chattr, чтобы предотвратить изменение этих файлов. но ИМХО удаление должно исходить от процесса или пользователя.
JMW

Ответы:


20

Решение 1 : systemtap
Вы можете использовать systemtap, чтобы показать все PID, которые пытаются использовать unlink () в inode of .bashrcи .bash_profileфайлах.

Установите systemtap и символы отладки для вашего ядра.

Создайте файл с именем unlink.stapсо следующим содержанием:

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

Затем запустите его с sudo stap unlink.stap

Решение 2 : inotify
Вы также можете использовать inotify, чтобы увидеть, когда файл удаляется.

Решение 3 : ftrace
Другое решение заключается в использовании ftrace :

trace-cmd record -e \*unlink\*

Подождите, пока файл будет удален, нажмите CTRL + C, чтобы остановить trace-cmd record ..., а затем выполните:

trace-cmd report

Решение 4 :
установите bpftrace bpftrace, затем запустите:

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

5

В дополнение к ответу micea, вы можете chattr + i файлы от имени root и посмотреть, не регистрирует ли что-либо ошибку при попытке их удалить.


4

Вы абсолютно уверены, что пользователь сам (случайно) не удаляет их?

У меня было несколько невежественных (Windows) пользователей с той же проблемой. Оказалось, что они сами удаляли эти файлы каждый раз, когда посещали домашний каталог с помощью FTP-клиента. Они заметили файлы .xxxx (клиент ftp их не скрывал) и удалили «беспорядок».

Мне никогда не приходило в голову, что они сделали это сами, пока один из них не пожаловался на спонтанно появляющиеся файлы, которые он удалил несколько дней назад.


2
Поверьте мне, я бы хотел, чтобы это было так просто.
Чад П

Это было забавно :)
оснастка

3
Это смешно сейчас ... Не так много, когда это происходило, и я не мог понять, что происходит. @ Чед П: Пожалуйста, дайте нам знать, что вы найдете. Я нахожу это довольно любопытным.
Тонни

3

Мы используем сценарии bash logout (~ / .bash_logout) для очистки определенных файлов при выходе из системы - вы можете проверить, есть ли у вас такая настройка, возможно, с толстым шариком в ней.


2

Больше похоже на злоумышленника, который выполняет поиск / home / user -name имя-файла -exec rm -f {} \; ведь его крадут :). Просто угадайте, потому что вы упомянули, что файлы резервных копий также удаляются.


1

Чтобы предотвратить потерю файлов и их содержимого, вы можете настроить libtrash через LD_PRELOAD. Используя libtrash, вы можете делать множество вещей, но те, которые могут быть вам интересны,

INTERCEPT_UNLINK
INTERCEPT_RENAME
INTERCEPT_FOPEN
INTERCEPT_OPEN

Хорошую статью о libtrash можно найти здесь

Другая вещь, которую вы упомянули, это то, что вы загрузили файлы в корневой каталог, и они все еще были удалены. Это потому, что / home / username принадлежит username; и если режиссер сказал мод 755; затем любой файл или каталог в этом каталоге, принадлежащий независимо от того, кто может быть удален пользователем; даже если это корневой файл или каталог. В основном это связано с тем, что удаление файла в dir означает изменение содержимого dir, и у пользователя есть 7 (в 755) из этого dir, чтобы он мог делать все, что захочет.

Есть способы заблокировать это, так как другие люди уже предложили через chattr в файловых системах ext установить файлы как неизменяемые (+ i). Затем нужно будет снять флаг неизменности, прежде чем вносить какие-либо изменения в файл / каталог, который имеет флаг + i. Неизменяемый флаг / chattr может использоваться только пользователем root.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.