Linux как посмотреть кто удалил файл

Узнать кто или что удаляет файл

Здравствуйте, подскажите такую штуку, на сервере (centos) постоянно пропадает один файл. Поставил inotify для отслеживания. Видно что в 5 утра файл был перемещен, скорее всего cron какой-то, но не могу понять, как определить что это за крон, то есть inotify показывает мне что файл был перемещен, но куда и кем непонятно, кронов в системе очень много просматривать и изучать каждый кронтаб — не вариант, есть ли способ узнать, кто или что перемещает этот файл и куда?

chattr +i на файл, и смотреть по логам, что не выполнилось

просматривать и изучать каждый кронтаб — не вариант

Это плохо, ибо получается машина вами командует, а не вы ей.

Ну я имел ввиду, что может есть какй-то способ автоматизировать, поиск такой информации, думаю вариант с chattr +i вполне подойдет

Спасибо большое, то что надо!

поиск такой информации, думаю вариант с chattr +i вполне подойдет

Это решение из серии: в метро приникают зайцами, а давайте забетонируем вход и не будут проникать.

Завтра вдруг обнаружится, что раз в три месяца пропадает ещё один файл, а через полгода — раз в год ещё один файл.

Чище будет настроить auditd, он для этого и создан.

Источник

Как найти пользователя, который удалил файл?

Какой-то пользователь на моем сервере просто удалил файл, я хочу узнать, кто это сделал. Просматривать историю каждого невозможно, и команда не может быть такой простой, как rm -rf file . Можно ли узнать, кто внес последние изменения в папку? Я нахожусь на Linux.

2 ответа 2

В общем, сложно определить, кто удалил файлы, кто изменил файлы, не зная о «системе журналирования» или предварительно настроенных событиях.

Попробуйте выяснить, кто вошел в тот момент, когда каталог был удален.

проверьте системный журнал ОС (/var/adm/syslog/syslog.log для hp-ux, /var /log /messages для linux)

Попробуйте последний коммандос, чтобы получить список тех, кто вошел в систему, когда

Проверьте историю команд sidadm, пользователя root, используйте команду history или псевдоним h

Проверьте, есть ли запущенные скрипты, которые регулярно удаляют файлы

Также Вы можете посмотреть на ваших пользователей. bash_history, предполагая, что они используют bash:

Выполните следующие команды в терминале:

это файл, который может удалить только пользователь root, затем посмотрите на .bash_history пользователя root, но затем вы должны выяснить, кто был зарегистрирован как пользователь root или имеет права root. Для этого вам может помочь команда last root | more

Поскольку каталог trans может быть подключен по NFS к другим серверам, возможно, вам также потребуется выполнить проверки там.

Также для будущего использования установите любые решения SIEM с открытым исходным кодом, такие как alienvault и т.д., Которые могут помочь вам поддерживать и регистрировать события.

Источник

Выполняю установку, настройку, сопровождение серверов. Для уточнения деталей используйте форму обратной связи

В сети есть сервак с поднятой на нём samb’ой и собстенно есть папка public, где все хранят свои файлы. Права на шару 777, то есть всем всё можно. Поскольку место под шару ограничено, то бывает такое, что места не хватает, и какой-то редиска удаляет файлы другого такого же редиски, что бы залить очередную Санту-Барбару. Потом начинаются жалобы, кто удалил и подобное.

И так, что имеем: samba 3.0.34. Данное тестировалось на samb’e версии 3.0.23, 3.0.32. Так что если ваша самба не такой версии — большая вероятность, что на ней тоже это будет работать.

Что бы всё это реализовать в конфиг samb’ы вносим такое

vfs object = full_audit
log level = 1 vfs:1
syslog = 7
full_audit:prefix = %u|%I
full_audit:success = connect, open, mkdir, rmdir, unlink, write, rename
full_audit:failure = connect, open, mkdir, rmdir, unlink, write, rename

prefix — может принимать любые значения или комбинацию из набора %u, %I, %U, %m, %s, %S, %a, %h, %H

success/failure — какие именно события писать. Полный список можно найти здесь

Куда его вносить, так это зависит от того, что хотим аудировать. Если внести такое в , то будут мониторится все шары. Если нужно мониторить только избранные, то вносим это только туда, что хотим мониторить. Например,

vfs object = full_audit
log level = 1 vfs:1
syslog = 7
full_audit:prefix = %u|%I
full_audit:success = connect, open, mkdir, rmdir, unlink, write, rename
full_audit:failure = connect, open, mkdir, rmdir, unlink, write, rename

comment = Public
path = /data/samba/share/public
writeable = yes
public = yes
browseable = yes
guest ok = yes

Теперь перечитываем конфиги самбы или делаем рестарт и смотрим /var/log/messages (юзер nobody с IP=10.0.3.111 зашёл, создал, переименовал папку)

Feb 19 14:24:15 fileserver smbd_audit: nobody|10.0.3.111|mkdir|ok|Новая папка (2)
Feb 19 14:24:18 fileserver smbd_audit: nobody|10.0.3.111|rename|ok|./Новая папка (2)|./new
Feb 19 14:24:21 fileserver smbd_audit: nobody|10.0.3.111|rmdir|ok|new

Для того, что бы это дело не сыпалось в messages, а в другой файл, например, audit.log включаем логгирование события smbd_audit в файл и выключаем его во всё остальное. Как это сделать читаем здесь.

Теперь можно не боятся, а смело бить по рукам 🙂

ПС. Кстати, если у вас уже используется какой-то vfs object, то перечисляем все объекты через пробел, например,

Источник

Как узнать, какие файлы и папки были недавно удалены в Linux?

У меня есть одна конкретная папка ( /home/sam/officedocuments ), которая имеет сотни папок и файлов.
Я думаю, что я удалил некоторые файлы и папки по ошибке, но я не уверен.

Как найти, какие файлы / папки были:

• недавно удален в Linux?
• недавно изменились в Linux?

Я просто хочу знать, какие файлы и папки были удалены. Восстановление удаленных файлов и папок не важно для меня.

3 ответов

использовать find для поиска по времени последнего изменения. Например, чтобы найти файлы, затронутые за последние 3 дня:

find /home/sam/officedocuments -mtime -3

для «старше 3 дней», использовать +3 .

практически невозможно. Когда файл удаляется, он просто ушел. В большинстве систем это нигде не регистрируется.

вероятно, вам следует установить Inotify Tools. тогда вы можете использовать inotifywait команда для прослушивания событий, происходящих в указанном каталоге.

в частности, если вы хотите, чтобы наблюдать за удаленные файлы и папки использовать это

и журнал этот вывод в какой-то файл.

надеюсь, что это решит вашу проблему

Linux обычно не запрашивает подтверждения перед удалением файлов, если вы используете rm из командной строки.

чтобы найти файлы, измененные за последние 30 минут, используйте touch —date=»HH:MM» /tmp/reference создать файл reference с отметкой времени 30 минут назад (где HH: MM соответствует 30 минутам назад). Тогда используйте find /home/sam/officedocuments -newer /tmp/reference для поиска файлов новее ссылки.

если вы удалили файлы с помощью инструмента GUI, они все еще могут быть в каком-то «мусорном баке». это зависит от о том, что вы используете для настольного компьютера. Если вы использовали rm из командной строки, то попробуйте одну из утилит, упомянутых в ответ. (Подсказка шляпы к @Sampo для этой ссылки.)

Источник

Лог файлы Linux по порядку

Невозможно представить себе пользователя и администратора сервера, или даже рабочей станции на основе Linux, который никогда не читал лог файлы. Операционная система и работающие приложения постоянно создают различные типы сообщений, которые регистрируются в различных файлах журналов. Умение определить нужный файл журнала и что искать в нем поможет существенно сэкономить время и быстрее устранить ошибку.

Журналирование является основным источником информации о работе системы и ее ошибках. В этом кратком руководстве рассмотрим основные аспекты журналирования операционной системы, структуру каталогов, программы для чтения и обзора логов.

Основные лог файлы

Все файлы журналов, можно отнести к одной из следующих категорий:

Большинство же лог файлов содержится в директории /var/log .

• /var/log/syslog или /var/log/messages содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра Linux, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого.
• /var/log/auth.log или /var/log/secure — информация об авторизации пользователей, включая удачные и неудачные попытки входа в систему, а также задействованные механизмы аутентификации.
• /var/log/dmesg — драйвера устройств. Одноименной командой можно просмотреть вывод содержимого файла. Размер журнала ограничен, когда файл достигнет своего предела, старые сообщения будут перезаписаны более новыми. Задав ключ —level= можно отфильтровать вывод по критерию значимости.

• /var/log/alternatives.log — Вывод программы update-alternatives , в котором находятся символические ссылки на команды или библиотеки по умолчанию.
• /var/log/anaconda.log — Записи, зарегистрированные во время установки системы.
• /var/log/audit — Записи, созданные службой аудита auditd .
• /var/log/boot.log — Информация, которая пишется при загрузке операционной системы.
• /var/log/cron — Отчет службы crond об исполняемых командах и сообщения от самих команд.
• /var/log/cups — Все, что связано с печатью и принтерами.
• /var/log/faillog — Неудачные попытки входа в систему. Очень полезно при проверке угроз в системе безопасности, хакерских атаках, попыток взлома методом перебора. Прочитать содержимое можно с помощью команды faillog .
• var/log/kern.log — Журнал содержит сообщения от ядра и предупреждения, которые могут быть полезны при устранении ошибок пользовательских модулей встроенных в ядро.
• /var/log/maillog/ или /var/log/mail.log — Журнал почтового сервера, используемого на ОС.
• /var/log/pm-powersave.log — Сообщения службы экономии заряда батареи.
• /var/log/samba/ — Логи файлового сервера Samba , который используется для доступа к общим папкам Windows и предоставления доступа пользователям Windows к общим папкам Linux.
• /var/log/spooler — Для представителей старой школы, содержит сообщения USENET. Чаще всего бывает пустым и заброшенным.
• /var/log/Xorg.0.log — Логи X сервера. Чаще всего бесполезны, но если в них есть строки начинающиеся с EE, то следует обратить на них внимание.

Для каждого дистрибутива будет отдельный журнал менеджера пакетов.

• /var/log/yum.log — Для программ установленных с помощью Yum в RedHat Linux.
• /var/log/emerge.log — Для ebuild -ов установленных из Portage с помощью emerge в Gentoo Linux.
• /var/log/dpkg.log — Для программ установленных с помощью dpkg в Debian Linux и всем семействе родственных дистрибутивах.

И немного бинарных журналов учета пользовательских сессий.

• /var/log/lastlog — Последняя сессия пользователей. Прочитать можно командой last .
• /var/log/tallylog — Аудит неудачных попыток входа в систему. Вывод на экран с помощью утилиты pam_tally2 .
• /var/log/btmp — Еже один журнал записи неудачных попыток входа в систему. Просто так, на всякий случай, если вы еще не догадались где следует искать следы активности взломщиков.
• /var/log/utmp — Список входов пользователей в систему на данный момент.
• /var/log/wtmp — Еще один журнал записи входа пользователей в систему. Вывод на экран командой utmpdump .

И другие журналы

Так как операционная система, даже такая замечательная как Linux, сама по себе никакой ощутимой пользы не несет в себе, то скорее всего на сервере или рабочей станции будет крутится база данных, веб сервер, разнообразные приложения. Каждое приложения или служба может иметь свой собственный файл или каталог журналов событий и ошибок. Всех их естественно невозможно перечислить, лишь некоторые.

• /var/log/mysql/ — Лог базы данных MySQL.
• /var/log/httpd/ или /var/log/apache2/ — Лог веб сервера Apache, журнал доступа находится в access_log , а ошибки — в error_log .
• /var/log/lighthttpd/ — Лог веб сервера lighttpd.

В домашнем каталоге пользователя могут находится журналы графических приложений, DE.

/.xsession-errors — Вывод stderr графических приложений X11.

/.xfce4-session.verbose-log — Сообщения рабочего стола XFCE4.

Чем просматривать — lnav

Почти все знают об утилите less и команде tail -f . Также для этих целей сгодится редактор vim и файловый менеджер Midnight Commander. У всех есть свои недостатки: less неважно обрабатывает журналы с длинными строками, принимая их за бинарники. Midnight Commander годится только для беглого просмотра, когда нет необходимости искать по сложному шаблону и переходить помногу взад и вперед между совпадениями. Редактор vim понимает и подсвечивает синтаксис множества форматов, но если журнал часто обновляется, то появляются отвлекающие внимания сообщения об изменениях в файле. Впрочем это легко можно обойти с помощью .

Недавно я обнаружил еще одну годную и многообещающую, но слегка еще сыроватую, утилиту — lnav, в расшифровке Log File Navigator.

Установка пакета как обычно одной командой.

Навигатор журналов lnav понимает ряд форматов файлов.

• Access_log веб сервера.
• CUPS page_log
• Syslog
• glog
• dpkg.log
• strace
• Произвольные записи с временными отметками
• gzip, bzip
• Журнал VMWare ESXi/vCenter

Что в данном случае означает понимание форматов файлов? Фокус в том, что lnav больше чем утилита для просмотра текстовых файлов. Программа умеет кое что еще. Можно открывать несколько файлов сразу и переключаться между ними.

Программа умеет напрямую открывать архивный файл.

Показывает гистограмму информативных сообщений, предупреждений и ошибок, если нажать клавишу . Это с моего syslog-а.

Кроме этого поддерживается подсветка синтаксиса, дополнение по табу и разные полезности в статусной строке. К недостаткам можно отнести нестабильность поведения и зависания. Надеюсь lnav будет активно развиваться, очень полезная программа на мой взгляд.

Источник