Защита работающих под root сервисов и suid/sgid исполняемых файлов
Предусмотрительный системный администратор запускает только те сервисы, в которых нуждается, ни больше ни меньше. Учитывайте, что сервисы сторонних разработчиков наиболее подвержены ошибкам. К примеру, работа со старыми версиями imapd или popper это все равно что раздача доступа root всему миру. Никогда не запускайте сервисы, которые вы не проверили достаточно внимательно. Многим сервисам не требуется работа под root. Например, даемоны ntalk, comsat, и finger могут быть запущены в так называемых песочницах (sandboxes). Песочница это не идеальное решение, поскольку вызывает много проблем, но она подходит под модель послойной безопасности: если кто-то сможет взломать сервис, работающий в песочнице, ему потребуется взломать еще и саму песочницу. Чем больше уровней (''слоев'') потребуется пройти атакующему, тем меньше вероятность его успеха. Ошибки, позволяющие получать root доступ, находили фактически во всех сервисах, запускаемых под root, включая основные системные сервисы. Если вы обслуживаете машину, на которую входят только через sshd и никогда не входят через telnetd, rshd или rlogind, отключите эти сервисы!
В FreeBSD сервисы ntalkd, comsat и finger теперь по умолчанию работают в ''песочнице''. Другая программа, которая может быть кандидатом на запуск в ''песочнице'' это named(8). /etc/defaults/rc.conf включает необходимые для запуска named в ''песочнице'' аргументы в закомментированой форме. В зависимости от того, устанавливаете ли вы новую систему, или обновляете старую, учётные записи пользователей, используемые этими ''песочницами'' могут не быть созданы. Предусмотрительный системный администратор должен узнать о ''песочницах'' для сервисов и установить их если есть возможность.
|
|
|
Есть множество других сервисов, которые обычно не работают в ''песочницах'': sendmail, popper, imapd, ftpd, и другие. Некоторым из этих сервисов есть альтернативы, но их установка может потребовать больше работы, чем вы готовы выполнить (фактор удобства). Вы можете запустить эти сервисы под root и положиться на другие механизмы обнаружения вторжений, которые могут пройти через них.
Другая большая потенциальная root брешь в системе это suid-root и sgid исполняемые файлы. Большинство этих исполняемых файлов, таких как rlogin, установлены в /bin, /sbin, /usr/bin, или /usr/sbin. Хотя ничто не может быть безопасно на 100%, находящиеся по умолчанию в системе suid и sgid исполняемые файлы могут быть признаны достаточно безопасными. Но root бреши все еще обнаруживаются в этих исполняемых файлах. root брешь, обнаруженная в Xlib в 1998 делала xterm (который обычно suid) подверженным взлому. Лучше сразу принять меры предосторожности, чем сожалеть потом. Предусмотрительный системный администратор ограничит права запуска suid исполняемых файлов, которые должны запускаться пользователями группы staff, только этой группой, а также запретит доступ (chmod 000) к тем исполняемым файлам suid, которые никем не используются. Серверу без монитора обычно не требуется исполняемый файл xterm. Исполняемые sgid исполняемые файлы могут быть почти так же опасны. Если нарушитель сможет взломать sgid-kmem исполняемый файл, он возможно сможет прочесть /dev/kmem и таким образом получить файл зашифрованных паролей, что потенциально делает возможным взлом любой защищённой паролем учётной записи. Аналогично нарушитель, проникший в группу kmem, может отслеживать последовательности клавиш, отправляемые через псевдо-терминалы, включая те, что используют защищённые соединения. Нарушитель, вошедший в группу tty может сделать вывод почти на любой пользовательский терминал. Если пользователь работает с терминальной программой или эмулятором с возможностью эмуляции клавиатуры, взломщик может потенциально сгенерировать поток данных, который заставит терминал пользователя ввести команду, и она будет запущена с правами этого пользователя.
|
|
|
Защита учётных записей пользователей
Учетные записи пользователей обычно сложнее всего защитить. Вы можете ввести драконовские ограничения доступа к служебным учётным записям, заменив их пароли на символ ''*'', но возможно не сможете сделать то же с обычными учётными записями пользователей. Если есть такая возможность, вы возможно сможете защитить учётные записи пользователей соответствующим образом. Если нет, просто более бдительно отслеживайте эти учётные записи. Использование ssh и Kerberos для учётных записей пользователей более проблематично, поскольку требует дополнительной административной работы и технической поддержки, но все же это решение лучше, чем файл с шифрованными паролями.
|
|
|
Защита файла паролей
Единственный абсолютно надежный способ это замена на * максимально возможного количества паролей и использование ssh или Kerberos для доступа к таким учётным записям. Хотя файл с шифрованными паролями (/etc/spwd.db) доступен для чтения только root, возможно, что нарушитель сможет получить доступ на чтение к этому файлу, даже если не получит права root на запись.
Ваши скрипты безопасности должны всегда проверять и составлять отчет об изменениях файла паролей (обратитесь к разделу Проверка целостности файлов ниже по тексту).
Дата добавления: 2018-10-26; просмотров: 142; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!