ПРОБЛЕМА:
У меня есть несколько отсутствующих каталогов на внешнем сервере Linux / Apache. Я отслеживал, когда они пропадали, в журналах ошибок httpd, и у меня есть список логинов SSL на машину (вместе с сетевыми адресами).
Есть несколько человек, у которых есть доступ к моей учетной записи на машине, поэтому я пытаюсь подтвердить, были ли файлы удалены случайно или намеренно. Если я могу определить, что сеанс пришел с внешнего сетевого адреса, то могу быть уверен, что это было намеренно. В противном случае мне понадобится дополнительная информация.
ВОПРОС:
Есть ли способ определить, какая учетная запись пользователя (моя или root), сетевой сеанс или процесс удалили файлы? Я не беспокоюсь о их восстановлении, поскольку резервные копии сделаны недавно.
СВЯЗАННЫЙ ВОПРОС:
Я пробовал посмотреть историю bash для своей собственной учетной записи (единственной, кроме root с разрешением), и кажется, что она распространяется только на начало моего сеанса SSL. Означает ли это, что история bash была изменена, или это нормальное поведение?
По умолчанию это не регистрируется (представьте, какого размера будут журналы). Вы можете добавить ведение журнала с помощью auditctl или inotify / iwatch (интересные варианты, проверьте их), или журналы вашей панели управления или ftp (обычно все где-то в / var / log) или история bash могут помочь вам немного отследить это. Проверьте журналы доступа HTTP на случай, если какой-то запрос GET смог это сделать (маловероятно, но возможно)
Если вашей истории нет, она была очищена. Это делается либо вручную, либо командой в ваших файлах .bash_logout или .logout.
Кроме того, это SSH, а не SSL :)
Уборка всегда трудна. Ресурсы, которые вы можете использовать:
Чтобы определить, кто вошел в систему и откуда:
Чтобы определить, что происходило в то время:
Если с момента инцидента не было большого оттока, mtime в каталоге может содержать полезную информацию (возможно, нет, но я обычно люблю собирать такие данные в любом случае)
На будущее предоставьте каждому человеку, имеющему доступ к машине, собственную учетную запись. То, что у вас есть сейчас, очень глупо по причине, которую вы только что обнаружили; Вы не можете знать, кто что сделал.
Если вы выполняете учет процессов, вы можете найти вызов (ы) к rm в журнале учета процессов.
История оболочки могла быть удалена или может быть настроена для частной истории сеанса. Параллельные сеансы также могут вызвать проблемы с историей оболочки.
История bash записывается только тогда, когда вы закрываете оболочку (вы можете деактивировать ее для текущего сеанса). В запущенном сеансе bash вы не можете видеть команды, которые вы ввели в этом сеансе, в файле истории bash - закройте сеанс, запустите новый, и вы сможете его увидеть.
Единственный надежный способ сделать это - запустить системный учет (например, sar или аналогичный). Другие вещи могут дать вам ответ, но не гарантируются:
История bash не гарантируется, потому что (а) существует ограничение истории; (б) по умолчанию он не записывается мгновенно; (c) вам необходимо просмотреть всю историю bash всех учетных записей пользователей; (d) варианты истории влияют на поведение; (e) Пользователь может очистить свою собственную историю bash (предотвратить ее запись в файл).
sftp по умолчанию не регистрирует транзакции, но при необходимости это можно включить на сервере sftp. файлы, добавленные или удаленные через sftp или ftp, не регистрируются в файле истории оболочки или в любом другом месте.
В вашем конкретном случае, если вы еще не ведете учет, то ваш единственный выход - выполнить поиск в истории команд оболочки для всех учетных записей пользователей в надежде, что они сохранятся.