Я хотел бы знать, как лучше всего отслеживать действия суперпользователя в среде Linux.
В частности, я ищу эти функции:
Подумайте об этом с точки зрения безопасности / аудита в среде, где различным системным администраторам (или даже третьим лицам) необходимо разрешить выполнение привилегированных операций на сервере.
У каждого администратора должна быть своя собственная номинальная учетная запись, и каждый интерактивный сеанс должен полностью регистрироваться с возможностью воспроизведения при необходимости (например, если кто-то использовал mc для удаления или изменения важных файлов, этого было бы недостаточно, чтобы знайте, что этот человек ввел команду mc; должен быть способ точно увидеть, что было сделано после запуска mc).
Дополнительные замечания:
Для сред с несколькими администраторами просто не используйте root - по возможности.
Используйте sudo для всего - sudo чрезвычайно настраивается и легко регистрируется.
Зарегистрируйте любые / все входы в систему или su для получения root-прав и исследуйте их, поскольку кто-то затем нарушает ваши установленные правила.
Что вы могли бы сделать, так это использовать этот библиотека для sudo, дайте каждому свою учетную запись пользователя и поместите sudo -i в профиль каждого. Таким образом, у них есть мгновенный root-доступ, и каждая команда, которую они используют, регистрируется.
Во-первых, какой тип доступа пользователя root вы хотите отслеживать? Глупые админские ошибки или злонамеренный инсайдер? Первое - вам понадобится хорошее решение для управления конфигурацией, как уже было предложено. Последнее - если они знают, что делают, вы можете только надеяться поймать достаточно, чтобы указать, что произошло что-то, заслуживающее расследования. Вы просто хотите знать, что началась некоторая форма несанкционированной активности, и получать уведомления об этом факте. Если они умны, они отключат большую часть встроенных вами журналов (изменив состояние сервера или добавив свои собственные инструменты), но, надеюсь, вы сможете уловить начало инцидента.
При этом я предлагаю несколько инструментов, которые вы можете использовать. Во-первых, начните с хорошей политики sudo (которая уже предлагалась). Во-вторых, проверьте Sudoshell, если вам нужно предоставить этим администраторам доступ к корневой оболочке. В-третьих, возможно, лучше всего (хотя и наиболее интенсивно) изучить аудит ядра Linux.
У них есть рут. Лучшее, на что вы можете надеяться, - это хотя бы увидеть, когда они решат вырваться из вашей маленькой утопии мониторинга, но кроме этого, что они сделали, остается только догадываться.
«Лучший» вариант, который я могу придумать, - это санкционировать использование повсеместной автоматизации и управления конфигурацией, а также управлять своими манифестами с помощью системы контроля версий и развертывать через нее обновления. Затем предотвратите фактический вход на серверы root. (Экстренный доступ «о нет, я что-то сломал» может быть предоставлен с помощью пароля, который не распространяется и не изменяется после каждого использования, или ключа SSH, и каждый может наблюдать за системным администратором, который облажался, чтобы убедиться, что они не изменить что-либо).
Да, это будет неудобно и раздражать, но если вы достаточно параноик, чтобы до такой степени контролировать действия каждого, я предполагаю, что вы находитесь в среде, которая неудобна и достаточно раздражает в других отношениях, чтобы это победило. это не кажется большой проблемой.
Как уже говорили другие, практически невозможно регистрировать пользователей с полным корневым доступом таким образом, чтобы они не могли отключить, но если вы используете debian / ubuntu, посмотрите любопытный, что довольно близко к тому, что вы хотите
snoopy - это просто разделяемая библиотека, которая используется как оболочка для функции execve (), предоставляемой libc, для регистрации каждого вызова syslog (authpriv). Системные администраторы могут найти подглядывание полезным в таких задачах, как мониторинг легкой / тяжелой системы, отслеживание действий других администраторов, а также получение хорошего «ощущения» того, что происходит в системе (например, 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 предотвращается таким образом.
Надо подумать, что тут root не может.
sudo должно быть хорошо. Резервное копирование файлов конфигурации каталога / etc должно быть хорошо. / var / directory Файлы журналов следует периодически отправлять по электронной почте или хранить в отдельном NFS.
Как насчет написания сценариев, которые интегрируют API-интерфейсы от компаний, занимающихся мобильными шлюзами, которые группируют по SMS все мобильные телефоны корневых пользователей, один из которых находится вне дома на работе. Я знаю, что это будет раздражать, но все же.
Взлом SSH почти не обсуждается.
У нас на сайте заказчика есть такая настройка:
Он будет регистрировать каждое использование sudo на серверах, а также отслеживать любые изменения файлов, установку пакетов, подозрительные процессы и т. Д.
У нас есть несколько терминальных серверов для доступа ко всему нашему оборудованию, это означает, что можно подключиться к чему угодно либо с терминального сервера, либо при наличии физического доступа.
Sshd на терминальных серверах исправлен с помощью http://www.kdvelectronics.eu/ssh-logging/ssh-logging.html , работает нормально, но давно не обновлялся. Я немного изменил его, чтобы работать с openssh 4.7, но не смог этого сделать с 5.1. Исправлены ошибки sshd segfaults, и пока у меня нет достаточно времени, чтобы исправить это, я почти перешел на ttyrpld.
Пока вот что у меня есть:
Знаете ли вы какие-либо другие подобные инструменты, которые не включают исправление ядра или других компонентов системы?