Як я можу дізнатися, який користувач увійшов як root?

У нас є кілька серверів, якими керує велика група адміністраторів. Зазвичай вони входять як користувачі сервісів (скажімо hudson), а потім переходять на rootневеликі виправлення. Це означає, що ми часто не можемо відобразити зміни, внесені до людини.

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

Мені б хотілося, щоб це сценарій, який слідкує за віддаленими входами (у локальній локальній мережі) та друкує ім'я користувача протягом певного часу. Ви можете припустити, що сценарій може зайти через ssh на будь-який комп'ютер у локальній локальній мережі як root, не запитуючи пароль.

Передумови: У мене є сценарій, який зберігає резервні копії всіх файлів, відредагованих root. Проблема полягає у тому, щоб з’ясувати, хто насправді змінив.

Безпека - це не проблема; це не знайти хакерів, які, можливо, очистили wtmp, це з’ясувати, хто помилився, щоб дати відгуки.

[EDIT] Деякі вказівники: Команда 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увійшли через via 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

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

Якщо хтось, крім адміністратора, помилково входить у систему як root, вам обов'язково потрібно змінити пароль root :-)

Гаразд, ви переглянули питання, щоб уточнити, чого саме ви хочете досягти. Вам потрібно мінімізувати кількість сервісів, які дозволяють входити в систему, і забезпечити, щоб усі вони записували успішний вхід. SSH записує успішні входи через syslog.

Якщо у вас кілька людей, які входять у систему як "Гудзон", вам потрібно це припинити. Це має бути політика щодо сайту, яка адмініструє кожен вхід, використовуючи унікальний userid.

Вам потрібно переконатися, що обертання файлів журналу відрегульовано так, щоб ви могли шукати старі журнали протягом будь-якого періоду, який вам потрібен.

Ви, звичайно, можете встановити сценарій, запланований cron, який щодня виконує вхід з системою log, а також перевіряє часові позначки на критичні файли конфігурації.

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

Особисто я підозрюю, що найкращий спосіб надати зворотній зв'язок у випадку помилки - це не полювати на когось, хто покладає на себе вину, а пояснити проблему всій групі, пояснити, чому зміна була помилкою, і висловити ідеї щодо запобігання помилок .

ви повинні мати можливість визначити, хто стає корінним шляхом аналізу /var/log/auth.log.

Наприклад, якщо я вкорінююсь у власному полі, вводиться такий рядок /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 для файлу, який ви досліджуєте.

Звичайно, якщо хтось повинен викорінити і просто виконає touchкоманду над досліджуваним файлом, він встановить mtime, і ви помилково повірите, що саме вони відредагували файл.

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

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

будь-який час файли на живих виробничих системах редагуються на місці під коренем, це основна проблема. я не можу сказати у вашому запитанні, чи Хадсон - справжня людина у вашій системі або синтетичний користувач для послуги (тобто, послуга Хадсона). якщо це синтетичний користувач, я б запитав, чому цей 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

Я зробив невелику програму , яка при використанні, розповість вам , який користувач увійшов в систему з правами адміністратора , якщо вони використовуються sudo su, sudo bashабо sudo -i. Тільки знайте, що останнім часом я його доволі трохи оновлював, тому що сюди-сюди додаю дрібниці, щоб зробити це краще та ефективніше. Але якщо вам цікаво його використовувати, просто перейдіть за цим посиланням: https://github.com/StrangeRanger/monitor/tree/master/RLSpy . Існує файл README.md, що пояснює призначення програми та її функції / несправності. Просто знайте, що сценарій інформуватиме вас лише про користувачів, які увійшли в root протягом останніх 7 днів.

Обидва команди su та sudo можуть бути налаштовані для зберігання журналів.

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

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

Як описано в розділі Як я можу отримати коментар поточного ключа autsh_keys ssh , можна використовувати поле коментаря у файлі key, щоб ідентифікувати зареєстровану особу.

Решта все те саме: Використання часової позначки модифікації файлу проти auth.log для ідентифікації передбачуваного сеансу ssh, який редагував цей файл.

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

З розуміння Linux Audit я бачу, що він може бути налаштований також для відстеження входів SSH на додаток до змін файлів, так що це може бути можливим рішенням вашої проблеми.

Зауважте також, що ми зазвичай змінюємо користувача на ssh, а не на sudo або su. Це дозволяє ввімкнути єдиний вхід і уникає необхідності вказувати адміністраторам будь-які паролі.

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

gandalf     ALL = NOPASSWD: ALL

Якщо ми хочемо надати / відкликати доступ до чогось, ми просто додаємо / видаляємо відкритий ключ із облікового запису послуги.

Ви також можете /etc/sudoersзамість цього видалити відповідний запис .

Я також знаю, що ssh записує в syslog, але повідомлення не кажуть мені, хто користувач перейшов на root

Ви також можете перевірити ~/.history(або ~/.bash_history) всіх адміністраторів на наявність ssh-викликів приблизно в часи, зафіксовані в sshd. Звичайно, це досить легко, щоб помірно обумовлений nogoodnick ухилився, звичайно, але так це все для людини з кореневим доступом.

Однак використання правильно налаштованого судо є набагато кращим варіантом. Сучасні версії навіть підтримують /etc/sudoers.d/, тому ви можете кидати / видаляти (малі) файли у підкаталог замість редагування єдиного (великого) /etc/sudoers.