Как отслеживать действия суперпользователя

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

В частности, я ищу эти функции:

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

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

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

Дополнительные примечания :

1. Как указывает Womble, возможно, лучшим вариантом будет не входить в систему с правами суперпользователя для внесения изменений на серверах, а делать это через систему управления конфигурацией. Итак, давайте предположим ситуацию, когда у нас нет такой системы, и нам нужно предоставить доступ на уровне root разным людям на одном сервере .
2. Я совершенно не заинтересован в том, чтобы делать это тайно: каждый, кто входит в систему на сервере с привилегиями root, будет полностью осведомлен о том, что сеанс будет записан (так же, как, например, операторы центра обработки вызовов знают, что их разговоры записывается)
3. Никто не будет использовать общую учетную запись суперпользователя («root»)
4. Я знаю о ttyrpld, и он, кажется, делает то, что я ищу. Но прежде чем идти по этому пути, я хотел бы знать, можно ли решить эту проблему с помощью неизмененного ядра. Я хочу знать, существуют ли какие-либо инструменты для Debian в частности (или для Linux в целом), которые позволяют проводить полный аудит учетных записей суперпользователя без исправления оболочки или ядра.

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

Используйте sudo для всего - sudo чрезвычайно легко настраивается и легко регистрируется.

Регистрируйте любые / все логины или su для получения root-прав и исследуйте их, как кто-то затем нарушает ваши установленные правила.

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

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

То, что вы могли бы сделать, это использовать эту библиотеку для sudo, дать каждому свой useraccount и поместить sudo -i в профиль everyones. Таким образом, они получают мгновенный root-доступ, и каждая команда, которую они используют, регистрируется.

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

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

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

Как уже говорили другие, практически нет возможности регистрировать пользователей с полным доступом к root так, как они не могут отключить, но если вы используете Debian / Ubuntu, взгляните на Snoopy , который довольно близок к тому, что вы хотите

snoopy - это просто разделяемая библиотека, которая используется в качестве оболочки для функции execve (), предоставляемой libc, чтобы регистрировать каждый вызов syslog (authpriv). Системные администраторы могут найти Snoopy полезным в таких задачах, как легкий / тяжелый мониторинг системы, отслеживание действий других администраторов, а также хорошее представление о том, что происходит в системе (например, Apache запускает сценарии CGI).

Я согласен с комментариями disabledleopard об использовании sudo для всего. Это, безусловно, делает вещи немного проще для входа.

Я также периодически добавляю резервное копирование файла истории bash. Казалось бы, часто упускают из виду, но иногда могут быть отличным источником информации ... просто спросите Goldman Sachs. ;-)

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

Это было бы сложно ...

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

Предполагая, что несколько администраторов, которым предоставлены привилегии root, работают как команда. И root может убить любой процесс мониторинга. И, к сожалению, этот логин / пароль становится публичным. Или они получают нежелательную компанию.

Создание нескольких учетных записей root с UID 0, хотя это и не рекомендуется, может быть применимо здесь.

В / etc / ssh / sshd_config Изменение строки на: PermitRootLogin no

Рекомендовано. Таким образом, здесь пользователь входит в систему, используя свою обычную учетную запись (отметка даты и времени регистрируется вместе с (возможно, подделка IP-адреса)), а затем переключается на root. используя команду su

И прямой вход в систему как root предотвращен, как это.

Мы должны думать, что корень не может сделать здесь.

Судо должно быть хорошо. Резервное копирование файлов конфигурации каталога / etc должно быть хорошим. / var / directory Файлы журнала должны периодически отправляться по электронной почте или храниться в отдельной NFS.

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

О взломе SSH в основном не может быть и речи.

У нас есть следующие настройки на сайте клиента:

• Аналогично - открыть для аутентификации с помощью Kerberos в AD (личные учетные записи)
• Авторизация только для определенных групп AD администраторов Unix
• группа sudoers == группа AD
• Агенты OSSEC HIDS на каждом сервере и менеджер на защищенном сервере
• OSSEC Web UI
• Splunk 3 с Splunk-для-OSSEC

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

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

Sshd на терминальных серверах исправлен с помощью http://www.kdvelectronics.eu/ssh-logging/ssh-logging.html , отлично работает, но долгое время не обновлялся. Я немного изменил его для работы с openssh 4.7, но не смог сделать это с 5.1. Пропатчены sshd segfaults, и пока у меня нет достаточно времени, чтобы это исправить, я почти переключился на ttyrpld.

Пока это то, что у меня есть:

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

Знаете ли вы какие-либо другие подобные инструменты, которые не включают исправления ядра или других компонентов системы?