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

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

В частности, я ищу следующие функции:

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

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

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

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

  1. Как отметил womble, лучшим вариантом может быть отсутствие доступа пользователей с правами root для выполнения изменений на серверах, но вместо этого это делается через систему управления конфигурацией. Итак, давайте предположим ситуацию, когда у нас нет такой системы, и нам нужно предоставить доступ на уровне root для разных людей на одном сервере .
  2. Мне неинтересно делать это тайно: каждый, кто войдет на сервер с привилегиями root, будет полностью осведомлен о том, что сеанс будет записан (так же, как, например, операторы call-центра знают, что их разговоры записываются)
  3. Никто не будет использовать общую учетную запись суперпользователя («root»)
  4. Я знаю ttyrpld и, похоже, делает то, что я находясь в поиске. Но прежде чем идти этим путем, я хотел бы знать, можно ли это решить, используя немодифицированное ядро. Я хочу знать, есть ли какие-либо инструменты для Debian, в частности (или Linux в целом), которые позволяют полностью контролировать учетные записи суперпользователей без исправления оболочки или ядра.
21 голос | спросил mfriedman 6 AM00000040000005331 2009, 04:58:53

10 ответов


8

В средах с несколькими админами просто не используйте root - если это возможно.

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

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

ответил DisabledLeopard 6 AM00000050000003831 2009, 05:49:38
2

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

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

ответил romandas 6 AM00000080000001231 2009, 08:00:12
2

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

ответил blauwblaatje 6 PM000000120000005931 2009, 12:44:59
1

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

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

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

ответил womble 6 AM00000050000004031 2009, 05:25:40
0

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

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

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

ответил KPWINC 6 AM00000060000000331 2009, 06:10:03
0

Это будет сложно ...

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

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

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

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

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

И Прямое ведение журнала как root предотвращается таким образом.

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

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

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

Нарушение SSH в основном не может быть и речи.

ответил KPWINC 6 AM00000060000000331 2009, 06:10:03
0

Как говорили другие, практически невозможно зарегистрировать пользователей с полным доступом к корневому файлу таким образом, что они не могут отключиться, но если вы используете debian /ubuntu, посмотрите snoopy , который близок к тому, что вы хотите

  

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

ответил theotherreceive 6 AM00000070000001631 2009, 07:31:16
0

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

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

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

ответил chmeee 6 AM00000090000002131 2009, 09:35:21
0

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

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

ответил Dima Medvedev 6 PM000000120000005631 2009, 12:07:56
0

До сих пор это то, что у меня есть:

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

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

ответил mfriedman 6 PM00000090000000031 2009, 21:18:00

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132