Вопросы Теги

Как зарегистрировать команды в “sudo su -”?

Решение @l0b0 переписывается для лучшей устойчивости:

printf '%s\0' index-*.txt |
  sort --zero-terminated --field-separator - --key 2rn |
  xargs -0r rename --verbose '
    s/^index-([0-9]+)\.txt$/$1/;
    $_="index-" . ($_ + 1) . ".txt"'

Не стесняйтесь включать в свое решение, и я удалю свой ответ позже.

Обратите внимание, что это и решения @l0bo - конкретный GNU, не Unix (GNU Не Unix).

12
15.01.2014, 08:29
11 ответов

Так как Вы находитесь на Ubuntu 12.04, взглянули на способности к входу ввода-вывода, активированные через 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 и зарегистрирует весь вывод, который отправляется в экран, подобный команде сценария (1). Если стандартный вывод или стандартная погрешность не подключены к tty пользователя, из-за перенаправления ввода-вывода или потому что команда является частью конвейера, которые производят, также получен и сохранен в отдельных файлах журнала.

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

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

РЕАЛИЗАЦИЯ: версия Sudo, по крайней мере: 1.7.4p4 необходимый.

/etc/sudoers modifcation: Все, что необходимо сделать, должно добавить, что два тега ко всем потребовали sudoers записей (где "su" указал, или с командой или с псевдонимом). LOG_INPUT и LOG_OUTPUT.

Пример:

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

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

Defaults iolog_dir=/var/log/sudo-io/%{user}
16
27.01.2020, 19:54
  • 1
    это является большим, но не работает над более старыми системами..:\ –  newuser999 21.01.2014, 19:31
  • 2
    Да, возможно, создайте пакет текущей sudo версии или обновите систему? –  serverhorror 29.07.2015, 11:39

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

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

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

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

13
27.01.2020, 19:54
  • 1
    , но как я могу зарегистрироваться "sudo su -"? –  newuser999 09.01.2014, 20:12
  • 2
    Это зарегистрировано. Вы пробовали grep 'COMMAND=/bin/su -' * (или без подстановочного знака: grep 'COMMAND=/bin/su -' /var/log/auth.log)? –  Patrick 09.01.2014, 21:40
  • 3
    , я обновил вопрос. что еще я должен доказать, что при использовании "sudo su -" команды не зарегистрированы?? –  newuser999 10.01.2014, 16:45
  • 4
    Команда (sudo -) зарегистрирован, и Ваш обновленный вывод показывает это. Это - все, о чем мы говорим здесь. Другие команды, такой как echo после переключения пользователей с sudo -, не команды sudo, и следовательно (согласно моему ответу) не зарегистрированы auth.log. Только человек управляет явно снабженный предисловием с sudo будет зарегистрирован. Так sudo echo зарегистрирован, но просто echo не, независимо от того, что Вы переключились на суперпользователя. отказ диска –  goldilocks 10.01.2014, 17:20

В увеличивающейся сложности вот три способа зарегистрировать команды, данные в "sudo su -":

  1. Полагайтесь на историю команд удара
  2. Установите execve регистрирующаяся обертка
  3. Используйте auditd SELINUX

Относительно которого подходит, это действительно зависит от того, что Вы пытаетесь выполнить с входом.

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

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

2) обертка execve

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

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

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

3) auditd

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

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

Существуют некоторые другие предложения к подобному вопросу на serverfault.

12
27.01.2020, 19:54

Почему?

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

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

9
27.01.2020, 19:54

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

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

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

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

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

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

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

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

5
27.01.2020, 19:54
  • 1
    О, для контрольных журналов, которым будут доверять, они должны быть отправлены на отдельный сервер. Любым журналам, находящимся на машине, где у недоверяемого пользователя есть корень, нельзя доверять. –  Jenny D 15.01.2014, 11:51
  • 2
    даже затем, Вы не можете доверять тому, что делает или не выходит из поставленного под угрозу сервера. –  Matt 15.01.2014, 12:12
  • 3
    правила udev, Но у Вас будет трассировка вплоть до времени, когда это поставлено под угрозу. –  Jenny D 15.01.2014, 12:13
  • 4
    , Которая в случае op является технически, как только они работали sudo su - таким образом, Вы вернулись в самое начало –  Matt 15.01.2014, 12:29
  • 5
    Недоверяемый не то же, как поставленный под угрозу. Это не становится поставленным под угрозу, пока они на самом деле не делают что-то низкое, в котором cse контрольный журнал на удаленном сервере покажет Вам, что было сделано и кем - включая кто это было, это отключило auditd. И даже кроме этого, удаленный журнал поможет, когда кто-то удалит локальный журнал по ошибке или защищать себя от вины за ошибку. –  Jenny D 15.01.2014, 12:33

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

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

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

2
27.01.2020, 19:54

Что относительно этого:

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 выполняется перед каждой подсказкой

1
27.01.2020, 19:54
  • 1
    , который не делает первый, дает мне консоль И если бы я поместил второй в/root/.bashrc затем, то я должен поразить CTRL+C, если я хочу получить корневую консоль после "sudo su -" :D какие-либо возможности зафиксировать это (или добавить "дату" функционируют к нему?).Большое спасибо! –  newuser999 16.01.2014, 11:49
  • 2
    I, боящийся, Вы неправильно использовали его. Отредактированный это для создания более явным. –  Costa 16.01.2014, 15:25

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

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

2
27.01.2020, 19:54

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

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

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

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

0
27.01.2020, 19:54

Вы могли бы хотеть создать машинописный текст своего использования сессии 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 это имеет еще больше дополнительных свойств.

0
27.01.2020, 19:54

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

Вам нужно определить ее как 

USER_NAME         ALL=(ALL) NOEXEC : ALL

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

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

1
20.08.2021, 12:59

Теги

Похожие вопросы