Как протоколировать команды в «sudo su -»?

Если я:

[user@notebook ~] sudo echo 123456uu 123456uu [user@notebook ~] 

Тогда я вижу, что в журналах:

 [root@notebook /var/log] grep 123456uu * auth.log:Jan 9 17:01:51 notebook sudo: user : TTY=pts/3 ; PWD=/home/user ; USER=root ; COMMAND=/bin/echo 123456uu [root@notebook /var/log] 

но если я:

 [user@notebook ~] sudo su - [root@notebook ~] echo 1234567zz 1234567zz [root@notebook ~] 

Я не вижу его в журналах:

 [root@notebook /var/log] grep 1234567zz * [root@notebook /var/log] echo $? 1 [root@notebook /var/log] 

Мой вопрос: как я могу включить регистрацию для команд в «sudo su -»?

ОС – Ubuntu 12.04, но вопрос в целом.

UPDATE # 1:

 [user@notebook ~] sudo su - [sudo] password for user: [root@notebook ~] echo zizizi zizizi [root@notebook ~] cd /var/log [root@notebook /var/log] grep -iIR 'zizizi' * [root@notebook /var/log] grep 'COMMAND=/bin/su -' * auth.log:Jan 10 15:42:42 notebook sudo: user : TTY=pts/1 ; PWD=/home/user ; USER=root ; COMMAND=/bin/su - [root@notebook /var/log] 

Поскольку вы находитесь на Ubuntu 12.04, log_output возможностями ведения журнала ввода-вывода, активированными с помощью параметров log_input и log_output .

log_input

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

Вход регистрируется в каталог, указанный параметром iolog_dir (по умолчанию – /var/log/sudo-io ), используя уникальный идентификатор сеанса, который включен в строку обычного журнала sudo, с префиксом TSID= . Параметр iolog_file может использоваться для управления форматом идентификатора сеанса.

Обратите внимание, что пользовательский ввод может содержать конфиденциальную информацию, такую ​​как пароли (даже если они не отображаются на экране), которые будут храниться в незашифрованном файле журнала. В большинстве случаев необходимо регистрировать вывод команды через log_output.

log_output

    Если установлено, sudo будет запускать команду в псевдо-tty и записывать весь вывод, который отправляется на экран, аналогично команде script (1). Если стандартный вывод или стандартная ошибка не подключены к tty пользователя, из-за перенаправления ввода-вывода или из-за того, что команда является частью конвейера, этот вывод также записывается и сохраняется в отдельных файлах журнала.

Вывод регистрируется в каталоге, указанном опцией iolog_dir (по умолчанию – /var/log/sudo-io ), используя уникальный идентификатор сеанса, который включен в обычную строку журнала sudo, с префиксом TSID= . Параметр iolog_file может использоваться для управления форматом идентификатора сеанса.

Выходные журналы можно просмотреть с помощью утилиты sudoreplay (8), которая также может использоваться для отображения или поиска доступных журналов.

ОСУЩЕСТВЛЕНИЕ: Судо версия по крайней мере: 1.7.4p4 необходимо.

/etc/sudoers modifcation: все, что вам нужно сделать, это добавить два тега во все необходимые записи sudoers (где «su» указано либо с помощью команды, либо с помощью псевдонима). LOG_INPUT и LOG_OUTPUT.

Пример:

 %admins ALL=(ALL) NOPASSWD: LOG_INPUT: LOG_OUTPUT: ALL 

Добавьте в sudoers следующую структуру журнала dir по умолчанию:

 Defaults iolog_dir=/var/log/sudo-io/%{user} 

Ваш grep при выполнении sudo su - сбой, потому что вы не используете echo 1234567zz , вы используете su - , который запускает оболочку. Затем оболочка запускает ваше echo .

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

Если вы измените grep на grep 'COMMAND=/bin/su -' * вы увидите его.


sudo su - тоже бесполезное использование su . sudo -i делает то же самое.

При возрастающей сложности три способа регистрации команд, выпущенных в «sudo su -»:

  1. Положитесь на историю команд bash
  2. Установите оболочку execve logging
  3. Использовать SELinux's auditd

Что подходит, это действительно зависит от того, что вы пытаетесь выполнить при регистрации.

1) История команд Bash

Вы хотите настроить хронологию истории, чтобы обеспечить сохранение достаточного количества строк, а не переписывание из разных сеансов, а не игнорирование команд и соответствующих временных меток. (См. Переменные HIST * в руководстве bash ). Легко подрывается, редактируя файл истории, манипулируя средой или запуская другую оболочку.

2) execve wrapper

snoopylogger – один. Добавьте проверку /etc/profile что библиотека регистратора находится в карте памяти процесса ( /proc/<pid>/maps ), а если нет, установите LD_PRELOAD и перезапустите (с помощью exec $SHELL --login "$@" ) , В качестве альтернативы вы можете добавить запись в /etc/ld.so.preload с помощью $LIB/snoopy.so или эквивалентных путей к вашим 32/64-разрядным версиям snoopy.so.

Хотя сложнее, версия переменной окружения LD_PRELOAD из вышеперечисленного может по-прежнему быть подорвана, манипулируя средой выполнения, так что код snoopy больше не работает.

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

3) аудиторский

Чуть более простой для настройки, чем оболочка execve, но сложнее извлечь информацию. Это ответ на вопрос, который вы, вероятно, действительно задаете: «Есть ли способ зарегистрировать, какое влияние пользователь оказал на систему после выпуска sudo su - ». Syslog должен быть отправлен в ящик для содержимого, чтобы быть заслуживающим доверия.

Этот ответ Serverfault представляется довольно полной конфигурацией для использования с auditd.

Есть еще несколько предложений по аналогичному вопросу о serverfault .

Зачем?

Потому что это sudo который выполняет регистрацию; он регистрирует sudo commmands. В первом случае записывается sudo echo . Во втором случае записывается sudo su (ищите его в /var/log/auth.log ).

su – «пользователь-переключатель», по умолчанию – root. Все, что вы делаете после этого , не проходит через sudo . Это похоже на то, что вы вошли в систему как root; сам вход регистрируется, но не каждая команда.

Как говорили другие, sudo не может этого сделать.

Вместо этого используйте auditd . Если вы хотите зарегистрировать все, что было сделано root (включая, например, дела, выполняемые crontab), используйте это:

 sudo auditctl -a exit,always -F euid=0 

ETA: Обратите внимание, что регистрация всех будет влиять на производительность, поэтому вы, вероятно, захотите немного ее ограничить. Для man auditctl см. man auditctl .

Если вы хотите только зарегистрировать системные вызовы, где исходный идентификатор входа не является root, используйте вместо этого:

 sudo auditctl -a exit,always -F euid=0 -F auid!=0 

Журналы обычно попадают в /var/log/audit/audit.log. Вы можете искать их с помощью ausearch .

В man-страницах есть больше информации для auditctl , audit.rules и ausearch .

sudo su - будет в ~/.bash_history если ваша оболочка bash.

echo 1234567zz будет в /root/.bash_history если корневая оболочка bash.

Объяснение этого уже было опубликовано сглаживанием.

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

Если вас беспокоит то, что люди могут делать с sudo, тогда вам нужно будет ограничить его использование. Вы можете ограничить команды, которые они могут выполнять. Ограничьте доступ к / bin / su, если это вас беспокоит.

Как насчет этого:

 export HISTTIMEFORMAT="%d/%m/%y %T " export PROMPT_COMMAND='builtin history 1 >> /var/log/sudo.log' sudo -E su unset PROMPT_COMMAND 

или

 export HISTTIMEFORMAT="%d/%m/%y %T " export PROMPT_COMMAND='builtin history 1 >> /var/log/sudo.log' sudo -E su --preserve-environment - unset PROMPT_COMMAND 

или длинный однострочный:

 HISTTIMEFORMAT="%d/%m/%y %T " PROMPT_COMMAND='builtin history 1 >> /var/log/sudo.log' sudo -E su 

sudo -E сохраняет среду PROMPT_COMMAND выполняется перед каждой подсказкой

Если это помогает, вы можете использовать опцию «NOEXEC» для sudoers.

Вы должны определить его как

 USER_NAME ALL=(ALL) NOEXEC : ALL 

Это предотвратит утечку оболочки, и пользователь не сможет использовать sudo -i или sudo -s или sudo su –

Однако это имеет недостаток, однако любой выход из оболочки будет отключен. для выполнения сценария из сценария также будет отказано.

Давайте не будем делать это сложным: всякий раз, когда вызывается sudo , он сообщает об этом факте в каком-то файле в /var/log (в вашей системе есть auth.log , в моем OS X box это system.log ). sudo сообщает свои аргументы командной строки, но он не знает, что может произойти внутри интерактивной команды, такой как su .

Это не означает, что нет записи о том, что происходит в корневой подоболочке: команды Shell сохраняются в истории оболочки. В моей системе сохранение истории root по умолчанию включено, поэтому все, что мне нужно сделать, это посмотреть в ~root/.sh_history для записи того, что было сделано (если кто-то не вмешался в это, конечно, но они могли одинаково хорошо tamper с /var/log ).

Я думаю, что это лучшее решение для вас. Если нет, отправляйтесь в город с auditd , как предложил @Jenny.

PS. Если история root еще не включена, включение ее зависит от используемой оболочки. Для bash установите HISTORY и HISTFILESIZE на достаточно большое число (по умолчанию – 500, говорится в моем руководстве). Если вы хотите, вы можете указать, где сохранена история, установив HISTFILE в путь (по умолчанию $HOME/.sh_history )

Возможно, вы захотите создать машинописную версию своего сеанса, используя script(1) :

 $ sudo su - # script -t /tmp/my_typescript 2> /tmp/my_typescript.timing Script started, file is /tmp/my_typescript # echo foobar foobar # echo hello world hello world # exit exit Script done, file is /tmp/my_typescript 

Теперь вы можете grep (обратите внимание, что # подсказки фактически записаны в /tmp/my_typescript ):

 $ grep echo /tmp/my_typescript # echo foobar # echo hello world 

Кроме того, вы можете снова просмотреть всю сессию с помощью scriptreplay(1) :

 $ scriptreplay -t /tmp/my_typescript.timing /tmp/my_typescript 

Файл /tmp/my_typescript.timing содержит информацию при /tmp/my_typescript.timing каждой команды. Есть еще инструменты, такие как ttyrec или shelr которые имеют еще больше колоколов и свистов.