Как регистрировать команды внутри «sudo su -»?

12

Если я:

[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]
newuser999
источник
Если кто-то злоумышленник (или даже просто ненадежный) имеет доступ к нему sudo su -, он также имеет возможность удалить все записи журнала, которые вы могли бы сделать из своих действий. Если вы хотите 100% достоверности при ведении журнала, вам нужно sudoсильно ограничить и sudo suполностью запретить .
Wildcard

Ответы:

17

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

log_input

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

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

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

log_output

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

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

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

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

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

Пример:

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

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

Defaults iolog_dir=/var/log/sudo-io/%{user}
Марк Вагнер
источник
это здорово, но не работает на старых системах ..: \
newuser999
Да, может быть, создать пакет текущей версии sudo или обновить систему?
Мартин М.
13

Ваша grepработа sudo su -не выполняется, потому что вы не работаете echo 1234567zz, вы работаете su -, что запускает оболочку. Оболочка тогда работает echo.

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

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


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

Патрик
источник
но как я могу войти в "sudo su -"?
newuser999
1
Это зарегистрировано. Вы пробовали grep 'COMMAND=/bin/su -' *(или без подстановочных знаков :) grep 'COMMAND=/bin/su -' /var/log/auth.log?
Патрик
Я обновил вопрос. Что еще я должен доказать, что при использовании "sudo su -" команды не регистрируются ??
newuser999
4
Команда ( sudo -) является зарегистрированным, и ваш обновленный выход показывает это. Это все, о чем мы здесь говорим. В другие команды, такие как echoпосле переключения пользователей sudo -, не SUDO команды, и , следовательно , (в соответствии с моим ответом) не вошли в систему auth.log. sudoБудут регистрироваться только отдельные команды с явным предваряющим . Так sudo echoчто регистрируется, но просто echoнет, независимо от того, что вы переключились на суперпользователя.
Златовласка
12

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

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

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

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

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

2) execve обертка

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

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

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

3) ревизия

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

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

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

Р Перрин
источник
9

Почему?

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

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

лютик золотистый
источник
5

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

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

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

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

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

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

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

Там больше информации на страницах руководства для auditctl, audit.rulesи ausearch.

Дженни Д
источник
2
О, для того, чтобы журналы аудита были доверенными, они должны быть отправлены на отдельный сервер. Любые журналы, находящиеся на компьютере, где у недоверенного пользователя есть root, нельзя доверять.
Дженни Д
даже тогда вы не можете доверять тому, что работает или не выходит из скомпрометированного сервера.
Мэтт
Но у вас будет след до того момента, когда он будет скомпрометирован.
Дженни Д
2
Что в случае с опом технически, как только они бегут, sudo su -так что вы вернулись на круги своя
Мэтт
Ненадежный - это не то же самое, что скомпрометированный. Он не будет скомпрометирован, пока они на самом деле не сделают что-то гнусное, в котором cse журнал аудита на удаленном сервере покажет вам, что было сделано и кем - в том числе кто был тем, кто отключил Auditd. И даже помимо этого, удаленный журнал поможет, когда кто-то удалил локальный журнал по ошибке или защитит себя от вины за ошибку.
Дженни Д
2

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

echo 1234567zzбудет, /root/.bash_historyесли оболочка root - bash.

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

YoMismo
источник
2

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

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

X Тянь
источник
1

Что насчет этого:

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 выполняется перед каждым приглашением

ребро
источник
первый не дает мне консоли И если я помещаю второй в /root/.bashrc, тогда я должен нажать CTRL + C, если я хочу получить корневую консоль после «sudo su -»: D любые шансы чтобы исправить это (или добавить к нему функцию «дата»?). Огромное спасибо!
newuser999
Боюсь, вы неправильно использовали это. Отредактировал это, чтобы сделать более явным.
Коста
1

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

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

USER_NAME         ALL=(ALL) NOEXEC : ALL

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

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

ankidaemon
источник
0

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

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

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

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

Alexis
источник
0

Возможно, вы захотите создать машинописный текст вашей сессии, используя 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содержит информацию, когда каждая команда была вызвана. Есть другие инструменты, такие как ttyrecили shelrкоторые имеют еще больше наворотов.

tkrennwa
источник