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

Question

У нас есть пара серверов, которыми управляет большая группа администраторов. Они обычно входят в систему как пользователи сервиса (скажем, hudson), а затем переключаются на root чтобы сделать небольшое исправление. Это означает, что мы часто не можем отобразить изменения, внесенные в человека.

У кого-нибудь есть скрипт для Unix/Linux, который может сказать мне, какой пользователь вошел в систему как root? Вход в систему может быть со всех компьютеров в локальной сети. Удаленный доступ извне локальной сети как root невозможен; Администраторы должны сначала войти в систему с пользователем локальной сети, а затем могут перейти в root (все они используют SSH).

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

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

Безопасность не проблема; дело не в том, чтобы найти хакеров, которые могли очистить wtmp , а в том, чтобы выяснить, кто допустил ошибку, чтобы оставить отзыв.

[РЕДАКТИРОВАТЬ] Некоторые указатели: last команда помогает:

> last -t 20101029174200 root
root     pts/26       :0.0             Wed Oct 20 15:36 - 15:03  (23:27)    

wtmp begins Fri Oct  1 16:34:36 2010

Таким образом, root был авторизован через pts/26 . Кто еще сидел на этом псевдо TTY?

> last -t 20101029174200 pts/26
adigulla pts/26       :0               Mon Oct 25 09:45   still logged in   
adigulla pts/26       :0               Fri Oct 22 14:00 - 17:29  (03:29)    
adigulla pts/26       :0               Thu Oct 21 15:04 - 16:05  (01:01)    
root     pts/26       :0.0             Wed Oct 20 15:36 - 15:03  (23:27)    
adigulla pts/26       :0.0             Fri Oct 15 15:57 - 15:57  (00:00)    

wtmp begins Fri Oct  1 16:34:36 2010

Хм ... должно быть я. Так что я могу следить за изменениями пользователя на локальной машине. Если я войду в удаленную машину:

$ last -1 hudson 
hudson   pts/0        192.168.0.51     Fri Oct 29 17:52   still logged in   

Таким образом я получаю PTY и IP-адрес, откуда я пришел. Как я могу сделать подключение с выхода last для hudson к пользователю на 192.168.0.51?

[EDIT2] Также обратите внимание, что мы обычно меняем пользователя с помощью ssh , а не sudo или su . Это позволяет осуществлять единый вход и избегать необходимости сообщать администраторам любые пароли. Если мы хотим предоставить / отозвать доступ к чему-либо, мы просто добавляем / удаляем открытый ключ из учетной записи службы. Я также знаю, что ssh регистрирует в syslog, но сообщения не говорят мне, какой пользователь переключился на root:

sshd[7460]: Accepted publickey for root from ::1 port 36689 ssh2

Answer 1

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

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

---

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

Если несколько человек вошли в систему как "hudson", вам нужно это остановить. Это должна быть политика сайта, которая управляет каждым входом в систему с использованием уникального ИД пользователя.

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

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

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

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

Answer 2

вы должны быть в состоянии определить, кто становится пользователем root, проанализировав /var/log/auth.log .

например, если я имею права root на моем собственном ящике, такая строка вводится в /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 с именем. Написание сценария perl для этого должно быть очень простым, вы просто присоединяете uid через /var/log/auth.log и /etc/passwd течение определенного промежутка времени, а именно mtime для исследуемого файла.

конечно, если кто-то su получит root и просто выполнит команду touch для файла, который вы исследуете, он установит его mtime, и вы ошибочно поверите, что именно он отредактировал файл.

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

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

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

Answer 3

Переименуйте 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

Answer 4

Я создал небольшую программу, которая при использовании скажет вам, кто из пользователей вошел в систему как root, если он использовал sudo su , sudo bash или sudo -i . Просто знайте, что я обновлял его в последнее время, потому что я добавлял мелочи здесь и там, чтобы сделать его лучше и эффективнее. Но если вы заинтересованы в его использовании, просто перейдите по этой ссылке: https://github.com/StrangeRanger/monitor/tree/master/RLSpy . Существует файл README.md, объясняющий назначение программы и ее особенности / недостатки. Просто знайте, что скрипт будет информировать вас только о пользователях, которые вошли в систему в течение последних 7 дней.

Answer 5

Для ведения журналов можно задавать параметры как команды su, так и sudo.

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

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

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

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

Answer 6

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

Это кажется довольно нелепым. Вы готовы мириться с использованием ресурсов ssh-ing в localhost (сетевые буферы, tty-распределения, бесполезное шифрование и дешифрование и т.д.) Вместо того, чтобы настраивать sudo просто не запрашивать пароли?

gandalf     ALL = NOPASSWD: ALL

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

Вы также можете удалить соответствующую запись из /etc/sudoers .

Я также знаю, что ssh регистрирует в syslog, но сообщения не говорят мне, какой пользователь переключился на root

Вы также можете проверить ~/.history (или ~/.bash_history) всех администраторов для ssh-вызовов во времена, зарегистрированные sshd. Конечно, этого достаточно, чтобы уклончиво умолкнуть, но то же самое можно сказать и о человеке с root-доступом.

Тем не менее, использование правильно сконфигурированного sudo - гораздо лучший вариант. Современные версии даже поддерживают /etc/sudoers.d/ , поэтому вы можете удалять / удалять (маленькие) файлы в подкаталог вместо редактирования одного (большого) /etc/sudoers .

Answer 7

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

Из « Понимания аудита Linux» я вижу, что он может быть настроен также на отслеживание SSH-входов в дополнение к изменениям файлов, так что это может быть возможным решением вашей проблемы.