Защита FreeBSD

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

В последующем разделе будут рассмотрены методы защиты системы FreeBSD, упомянутые в предыдущем разделе этой главы.

14.3.1. Защита учётной записи root и служебных учётных записей

Во-первых, не беспокойтесь о защите служебных учётных записей, если не защищена учётная запись root. В большинстве систем у учётной записи root есть пароль. Использование пароля root опасно всегда. Это не означает, что вы должны удалить пароль. Пароль почти всегда необходим для доступа по консоли. Но это означает, что вы должны сделать невозможным использование пароля не из консоли или может быть даже с помощью команды su(1). Например, убедитесь, что псевдо-терминалы в файле /etc/ttys перечислены с параметром insecure, что делает невозможным вход на них под root напрямую с помощью telnet или rlogin. При использовании других средств входа, таких как sshd, убедитесь что вход под root напрямую отключен и в них. Сделайте это, открыв файл /etc/ssh/sshd_config, и убедившись, что параметр PermitRootLogin установлен в NO. Проверьте каждый метод доступа — сервис FTP и ему подобные часто подвержены взлому. Прямой вход под root должен быть разрешен только с системной консоли.

Конечно, как системный администратор вы должны иметь доступ root, поэтому потребуется открыть несколько ''лазеек''. Но убедитесь, что для доступа к ним необходим дополнительный пароль. Одним из способов доступа к root является добавление соответствующих учётных записей к группе wheel (в файле /etc/group). Это позволяет использовать su для доступа к root. Вы никогда не должны давать таким учётным записям доступ к wheel непосредственно, помещая их в группу wheel в файле паролей. Служебные учётные записи должны помещаться в группу staff, а затем добавляться к группе wheel в файле /etc/group. Только те члены группы staff, которым действительно нужен доступ к root, должны быть помещены в группу wheel. При работе с такими методами аутентификации как Kerberos, возможно также использование файла.k5login в каталоге пользователя root для доступа к учётной записи root с помощью ksu(1) без помещения кого-либо в группу wheel. Это решение возможно лучше, поскольку механизм wheel все еще позволяет взлом root, если злоумышленник получил копию файла паролей и смог взломать служебную учётную запись. Хотя использование механизма wheel лучше, чем работа через root напрямую, это не обязательно самый безопасный способ.

Непрямой способ защиты служебных учётных записей и конечно root это использование альтернативных методов доступа и замена зашифрованных паролей на символ ''*''. Используя команду vipw(8), замените каждый зашифрованный пароль служебных учётных записей на этот символ для запрета входа с аутентификацией по паролю. Эта команда обновит файл /etc/master.passwd и базу данных пользователей/паролей.

Служебная учётная запись вроде этой:

foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh

Должна быть заменена на такую:

foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh

Это изменение предотвратит обычный вход, поскольку зашифрованный пароль никогда не совпадет с ''*''. После этого члены группы staff должны использовать другой механизм аутентификации, например kerberos(1) или ssh(1) с парой ключей: публичным и приватным. При использовании такой системы как Kerberos, потребуется защитить сервер Kerberos и рабочую станцию. При использовании пары публичного/приватного ключей с ssh, потребуется защитить компьютер, с которого происходит вход (обычно это рабочая станция). Дополнительных слой защиты может быть добавлен путем защиты пары ключей при создании их с помощью ssh-keygen(1). Возможность заменить пароли служебных учётных записей на ''*'' гарантирует также, что вход может быть осуществлен только через защищенные методы доступа, которые вы настроили. Это принуждает всех членов staff использовать защищенные, шифрованные соединения для всех входов, что закрывает большую брешь, используемую многими нарушителями: перехват паролей с другого, слабо защищенного компьютера.

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

Использование такой системы как Kerberos дает возможность заблокировать или изменить пароль в одном месте, что сразу отразиться на всех компьютерах, где существует служебная учётная запись. Если эта учётная запись будет взломана, возможность немедленно изменить пароль на всех компьютерах нельзя недооценивать. Без этой возможности изменение паролей на N машинах может стать проблемой. Вы можете также наложить ограничения на смену паролей с помощью Kerberos: не только установить значения timeout в Kerberos, но и добавить требование смены пароля пользователем после определенного периода времени (скажем, раз в месяц).

14.3.2. Защита работающих под 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 может сделать вывод почти на любой пользовательский терминал. Если пользователь работает с терминальной программой или эмулятором с возможностью эмуляции клавиатуры, взломщик может потенциально сгенерировать поток данных, который заставит терминал пользователя ввести команду, и она будет запущена с правами этого пользователя.

14.3.3. Защита учётных записей пользователей

Учетные записи пользователей обычно сложнее всего защитить. Вы можете ввести драконовские ограничения доступа к служебным учётным записям, заменив их пароли на символ ''*'', но возможно не сможете сделать то же с обычными учётными записями пользователей. Если есть такая возможность, вы возможно сможете защитить учётные записи пользователей соответствующим образом. Если нет, просто более бдительно отслеживайте эти учётные записи. Использование ssh и Kerberos для учётных записей пользователей более проблематично, поскольку требует дополнительной административной работы и технической поддержки, но все же это решение лучше, чем файл с шифрованными паролями.