Як відстежувати діяльність суперпользователя

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

Я конкретно шукаю такі функції:

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

Подумайте про це з точки зору безпеки / аудиту в умовах, коли різним системним адміністраторам (або навіть третім сторонам) потрібно дозволити виконувати привілейовані операції на сервері.

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

Додаткові примітки :

1. Як зазначає Умбл, найкращим варіантом може бути відсутність доступу людей до корневих привілеїв для здійснення змін на серверах, а замість цього через систему управління конфігурацією. Тож давайте припустимо ситуацію, коли у нас немає такої системи, і нам потрібно надати кореневий доступ різним людям на одному сервері .
2. Мені зовсім не цікаво робити це приховано: кожна людина, що входить на сервер із привілеями root, буде повністю усвідомлений, що сеанс буде записаний (так само, як, наприклад, оператори телефонного центру знають, що їх розмови є записується)
3. Ніхто не використовує загальний обліковий запис суперпользователя ("root")
4. Мені відомо про ttyrpld і, здається, роблю те, що я шукаю. Але перш ніж піти цим шляхом, я хотів би знати, чи можна це вирішити за допомогою немодифікованого ядра. Хочу знати, чи існують якісь інструменти для Debian зокрема (або Linux взагалі), які дозволяють провести повний аудит облікових записів суперпользователя без виправлення оболонки або ядра.

Для середовищ із кількома адміністраторами просто не використовуйте root - завжди, якщо це можливо.

Використовуйте судо для всього - судо надзвичайно настроюється та легко переноситься.

Реєструйте будь-які / всі логіни або дані, щоб викорінювати та досліджувати їх, як тоді хтось обходить ваші встановлені правила.

Для одного, який тип доступу користувачів root ви шукаєте для моніторингу? Дурні помилки адміністратора чи злісний інсайдер? Перший - вам потрібне хороше рішення управління конфігурацією, як уже було запропоновано. Останнє - якщо вони знають, що роблять, ви можете лише сподіватися зловити достатньо, щоб вказати на те, що сталося, що варто розслідувати. Ви просто хочете знати, що почалася деяка форма несанкціонованої діяльності, і попередити про цей факт. Якщо вони розумні, вони відключать більшість журналів, які ви будуєте (змінивши стан сервера або ввівши власні інструменти), але, сподіваємось, ви зможете зрозуміти початки інциденту.

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

Що ви можете зробити, це використати цю бібліотеку для sudo, дати кожному власний рахунок і поставити sudo -i у профіль для кожного. Таким чином вони мають миттєвий доступ до кореня, і кожна команда, яку вони використовують, реєструється.

Вони прижилися. Найкраще, на що ви можете сподіватися, - це принаймні побачити, коли вони вирішили вирватися з вашої невеликої моніторингової утопії, але поза тим, що вони зробили, - це не здогадки.

"Найкращий" варіант, про який я можу придумати, - це дозволити використання автоматизованої та керуючої автоматизованої конфігурації та керувати своїми маніфестами за допомогою системи контролю ревізії та розгортати оновлення через неї. Потім запобігайте фактичним кореневим входам на сервери. (Аварійний "о, ні, я щось зламав", доступ може бути наданий нерозподіленим та зміненим паролем після кожного використання або ключем SSH, і кожен може спостерігати за сисадміном, який викрутив, щоб переконатися, що вони не що-небудь змінити).

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

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

snoopy - це лише спільна бібліотека, яка використовується як обгортка функції execve (), що надається libc, для реєстрації кожного виклику в syslog (authpriv). системні адміністратори можуть вважати snoopy корисним у таких завданнях, як легкий / важкий моніторинг системи, відстеження інших дій адміністратора, а також добре розуміти те, що відбувається в системі (наприклад, Apache, що працює із скриптами cgi).

Я погоджуюся з коментарями disabledleopard щодо використання sudo для всього. Це, безумовно, полегшує вхід у систему.

Також я періодично додаю резервну копію файлу історії башів. Здається, що часто не помічають, але іноді можуть бути чудовим джерелом інформації ... просто запитайте Goldman Sachs. ;-)

http://www.guardian.co.uk/business/2009/jul/12/goldman-sachs-sergey-aleynikov

Це було б складно ...

root може запускати ретельно перевірені сценарії, які можуть порушити всі заходи безпеки (вбити процеси моніторингу), подрібнити файли журналів / обрізати їх і т.д. ... Але все-таки ...

Припускаючи, що декілька адміністраторів, яким надається привілей на root, працюють як команда. І root також може вбити будь-який процес моніторингу. І, на жаль, цей логін / пароль стає загальнодоступним. Або вони отримують небажану компанію.

Створення декількох кореневих облікових записів з UID 0, хоча і не рекомендується, тут може бути застосовано.

В / etc / ssh / sshd_config Зміна рядка на: PermitRootLogin ні

рекомендується. Так що тут, користувач входить у систему, використовуючи свій / її звичайний обліковий запис (штамп часу реєструється разом із (можливо, підробленою IP-адресою)) Потім переходить на root. використовуючи команду su

І прямого входу в систему як root запобігається подібним чином.

Ми повинні подумати, що тут не можна робити.

Судо має бути гарним. Резервне копіювання файлів / тощо. Конфігураційні файли повинні бути хорошими. / var / каталог Файли журналу повинні періодично надсилатись електронною поштою або зберігатись на окремих NFS.

Як щодо написання сценаріїв, які інтегрують API від компаній Mobile Gateway, які групують SMS усі мобільні користувачі, що один із них не вдома, щоб працювати. Я знаю, що це би дратувало, але все ж.

Порушення SSH здебільшого не викликає сумнівів.

На сайті клієнта є така настройка:

• Так само відкрийте для автентифікації Kerberos на AD (особисті акаунти)
• Авторизація лише для певних груп AD адміністраторів Unix
• група судорів == група AD
• OSSEC HIDS- агенти на кожному сервері та менеджер на загартованому сервері
• OSSEC Web UI
• Splunk 3 за допомогою Splunk-for-OSSEC

Він буде реєструвати кожне використання sudo на серверах, а також відстежувати будь-які зміни у файлах, встановлення пакетів, підозрілі процеси тощо.

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

Sshd на термінальних серверах виправлено з http://www.kdvelectronics.eu/ssh-logging/ssh-logging.html , працює чудово, але довго не оновлювався. Я трохи змінив його для роботи на openssh 4.7, але не зміг цього зробити з 5.1. Виправлена ​​segfault sshd, і поки у мене не вистачає часу, щоб виправити це, я майже перейшов на ttyrpld.

Поки що це:

• sudosh : схоже, підтримує A і B (не зовсім впевнений у A)
• Sudoscript : начебто, підтримує B (Sudoscript має компонент, який називається sudoshell, і якщо це запропонував Романда, дякую за пораду)
• Snoopy Logger або sudo_exetrace : не саме те, що я шукаю, але може стати гарним доповненням (завдяки theotherreceive та blauwblaatje за ці посилання)

Чи знаєте ви будь-які інші подібні інструменти, які не передбачають виправлення ядра чи інших системних компонентів?