Как я могу узнать, какой пользователь вошел в систему как корень?

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

Если кто-либо кроме администратора по ошибке входит в систему как корень, определенно необходимо, по крайней мере, изменить пароль корня :-)

Хорошо, Вы пересмотрели вопрос разъяснить то, что это - Вы, хотят достигнуть. Необходимо минимизировать номер служб, которые позволяют логины и гарантируют, что все они записывают успешный вход в систему. SSH записывает успешные логины с помощью системного журнала.

Если у Вас есть несколько человек, входящих в систему как "Гудзон", необходимо остановить это. Это должна быть политика сайта, что администраторы каждый входит в систему с помощью уникального идентификатора пользователя.

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

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

Кроме того, существует много инструментов для того, чтобы наблюдать изменения конфигурационного файла. Много систем Unix имеют контрольную подсистему, которая может быть включена и которая могла также помочь.

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

необходимо смочь определить, кто становится корнем путем парсинга /var/log/auth.log.

например, если я su для укоренения на моем собственном поле строка как это вводится в /var/log/auth.log:

Oct 29 20:10:33 localhost su: pam_unix(su:session): session opened for user root by (uid=1000)

теперь заглядывание /etc/passwd, мы видим:

brad:x:1000:100:brad clawsie,,,:/home/brad:/bin/zsh

который позволяет нам коррелировать uid 1000 к имени. запись сценария жемчуга, чтобы сделать это должно быть очень просто, Вы просто присоединяетесь к uid через /var/log/auth.log и /etc/passwd по определенному диапазону времени а именно, mtime для файла Вы занимаетесь расследованиями.

конечно, если кто-то su's для укоренения и просто выполняется touch команда на файле, который Вы исследуете, они установят его mtime, и Вы будете ложно полагать, что это - они, кто отредактировал файл.

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

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

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

Переименуйте su к log_su, затем помещает фактический su (теперь его log_su) вызов в обертке, названной su

#!/usr/bin/env bash
$SU_LOG=<path to log file>
echo "User: $USER running su at $(date)" >> $SU_LOG
log_su

И su и команды sudo могут быть параизмерены для хранения журналов.

При предположении, что (1) попытка базироваться не является частым действием и что (2) обычно не больше чем один администратор становится корнем одновременно, и, учитывая любую метку времени модификации файла, сценарий может просто искать в журналах su/sudo для определения местоположения администратора, который был корнем в то время.

Если Вы используете ssh, то можно генерировать аутентификационный ключ для каждого администратора и заставить их использовать его при входе в систему, а не механизмом пароля.

Как описано в том, Как я могу получить комментарий текущего authorized_keys ssh ключ, можно использовать поле комментария в файле ключей для идентификации зарегистрированного человека.

Остальное - то же: Используя файл модификация устанавливает метку времени против auth.log для идентификации предполагаемой ssh сессии, которая отредактировала тот файл.

Linux содержит усовершенствованную систему аудитов, которую может установить для отслеживания всех изменений в определенных файлах.

От Понимания Аудита Linux я вижу, что это может быть установлено до также дорожки логины SSH в дополнение к изменениям файла, таким образом, это могло быть возможное решение Вашей проблемы.