Укрепление (hardening) сервера
9.4.7 Задачи, характерные для Solaris
Solaris по умолчанию поставляется в четырех возможных конфигурациях: базовая (Core), для конечного пользователя (End-User), для разработчика (Developer) и полный дистрибутив (Entire Distribution). Установка любой конфигурации, отличной от базовой, включает в себя большее количество служб, чем требуется для укрепления сервера. На практике же часто можно убрать даже значительную часть базовой конфигурации в зависимости от тех требований, которые предъявляются к серверу.
О серверах Solaris есть несколько замечательных документов, опубликованных компанией Sun в своем архиве Blueprints Online, который находится по URL:
http://www.sun.com/software/solutions/blueprints/online.html
Следующие три статьи являются прекрасным отправным пунктом для построения безопасных серверов Solaris.
"Минимизация операционного окружения Solaris для целей безопасности: простая, легко повторяемая и безопасная методология установки приложений" ("Solaris Operating Environment Minimization for Security: A Simple, Reproducible and Secure Application Installation Methodology"), написанная Алексом Ноордерграафом (Alex Noordergraaf) и Кейт Уотсон (Keith Watson). Хотя данная статья прежде всего описывает требования Web-сервера iPlanet, к использованию Apache, Domino или других Web-серверов предъявляются аналогичные требования.
"Безопасность операционного окружения Solaris" ("Solaris Operating Environment Security"), написанная Алексом Ноордерграафом и Кейт Уотсон. Это обзор общих настроек безопасности сервера Solaris. В эту статью вошли некоторые особенности SPARC-архитектуры; тем не менее большая часть материала применима и к архитектуре Intel®.
"Сетевые настройки операционного окружения Solaris, влияющие на безопасность" ("Solaris Operating Environment Network Settings for Security"), написанная опять же Алексом Ноордерграафом и Кейт Уотсон, – еще одна превосходная статья о настройке ядра и о влияющих на сетевую безопасность параметрах приложений.
На самом деле Blueprints Online компании Sun – настоящий кладезь документации, описывающей все самое лучшее об операционном окружении Solaris, будь то Web-сервер в DMZ, брандмауэр или внутренний широкодоступный кластер Domino.
У Ланса Шпицнера (Lance Spitzner) тоже есть замечательный документ об укреплении Solaris, в котором для построения брандмауэра Check Point FireWall-1 детально описывается процесс укрепления на нескольких последних версиях Solaris (вплоть до версии 8) под платформы Intel и SPARC. Настоящий документ находится по следующему URL:
http://www.enteract.com/~lspitz/armoring.html
И наконец, для Solaris тоже есть эквивалент укрепляющих сценариев Bastille-Linux, который называется TITAN. Проект TITAN и документация по нему находятся по следующему URL:
9.4.8 Настройка сетевых конфигураций для целей безопасности
Для защиты от наиболее общих атак WAN-соединений, брандмауэра и DMZ-серверов организации надо выполнить следующие простые шаги, чтобы запретить определенную функциональность TCP/IP.
Сброс трафика с явной маршрутизацией
Фактически есть две формы трафика с явной маршрутизацией: жесткий (Strict SourceRouted) и свободный (Loose Source-Routed). Данное отличие не играет роли, поскольку лучше сбрасывать весь трафик с явной маршрутизацией.
Traceroute – самая известная команда, использующая явную маршрутизацию. Она позволяет провести диагностику проблемных мест в сети посредством прямого определения маршрута, по которому будут следовать контрольные пакеты.
К сожалению, возможные взломщики могут использовать явную маршрутизацию для попытки обхода правил брандмауэра и фильтров TCP/IP. Сброс трафика с явной маршрутизацией следует осуществлять на граничных маршрутизаторах и на любых несущих шлюзах безопасности:
в Solaris используйте следующую команду:
ndd -set /dev/ip ip_forward_src_routed 0
в GNU/Linux используйте команду
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
Сброс направленного широковещательного трафика
Атака Smurf типа отказа от обслуживания и подобные ей могут быть побеждены простым запретом направленного широковещания (direct broadcast) на границах маршрутизаторов и серверов, открытых Интернету:
для Solaris используйте следующую команду:
ndd -set /dev/ip ip_forward_directed_broadcasts 0
Игнорирование эха широковещательных запросов ICMP (ICMP echo)
Существует draft RFC, называемый draft-vshah-ddos-smurf-00, который находится по следующему URL-адресу:
http://www.ietf.org/internet-drafts/draft-vshah-ddos-smurf-00.txt
В нем утверждается, что, если в сетевом узле установлено отвечать на IP ICMP-эхо по широковещательным или множественным (multicast) адресам, узел должен убедиться в том, что адрес отправителя находится в локальной по отношению к сетевому узлу сети. Если адрес отправителя нелокален, ответ должен быть отброшен. Изменение поведения, чтобы вообще не отвечать на широковещательные сообщения ICMP, гарантирует, что ответы будут отбрасываться всегда:
в Solaris используйте следующую команду:
ndd -set /dev/ip ip_respond_to_echo_broadcast 0
в GNU/Linux используйте следующую команду:
echo 1 > /proc/sys/net/ipv4/icmp_echo_ ignore_broadcasts
В GNU/Linux имеется дополнительный элемент управления для запрещения вообще всех запросов на эхо-ответы ICMP. Вызов следующей команды заставит ядро Linux игнорировать все запросы эха ICMP:
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
Игнорирование ICMP-сообщений о перенаправлении (ICMP redirect)
Предполагаемый взломщик мог бы попытаться перенаправить трафик с серверов организации к другому, а то и вообще к несуществующему шлюзу. Кроме того, предполагаемый взломщик мог бы попытаться вставить фальшивые маршруты в таблицу маршрутизации сервера.
Все это может быть выполнено посредством скромного ICMP-сообщения о перенаправлении, и это очень эффективная атака типа отказа от обслуживания. Помимо блокирования ICMP-сообщений перенаправления на брандмауэре, если конечно операционная система поддерживает, следует ввести следующие дополнительные уровни защиты для игнорирования ICMP-сообщений о перенаправлении:
в Solaris используйте следующую команду:
ndd -set /dev/ip ip_ignore_redirect 1
в GNU/Linux команда будет такой:
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
Запрещение отправки ICMP-сообщений о перенаправлении
Только маршрутизаторам требуется отправка ICMP-сообщений о перенаправлении. Поскольку DMZ-серверы и брандмауэр организации не занимаются маршрутизацией каких бы то ни было пакетов, совершенно нет причин отправлять их:
в Solaris используйте следующую команду:
ndd -set /dev/ip ip_send_redirects 0
в GNU/Linux команда будет такой:
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
Широковещательный запрос на временной штамп
ICMP-запрос на штамп времени (ICMP type 13) позволяет одной системе запросить другую о текущем времени. Возвращаемое значение – количество миллисекунд с полуночи.
ICMP-запросы на временной штамп используются для синхронизации часов между системами вместо использования команды rdate из-за лучшей точности.
Индивидуальные запросы на штамп времени – это стандартная практика, но нет никакой необходимости системе отвечать на широковещательные запросы. В конце концов для синхронизации времени между серверами следует рассмотреть вариант использования NTP, поскольку для поддерживания времени оно намного лучше и, кроме того, поддерживает аутентификацию и совместную обработку нескольких источников, что делает его намного более устойчивым к фальсификации. Это дает возможность отказаться от использования ICMP типа 13 (запрос на временной штамп) и типа 14 (ответ о временном штампе) совершенно.
В Solaris используйте следующую команду:
ndd -set /dev/ip ip_respond_to_timestamp_ broadcast 0
9.4.9 Удаленный сервер ведения журналов
Одна из многочисленных техник, которые используются предполагаемыми взломщиками для скрытия своего присутствия, – это очистка любых средств журналирования, которые могут (и даже должны) быть включены. Сюда входит: ведение журнала учетных записей, системные сообщения, записи об ошибках, слежение за трафиком и т. п.
Один из способов обойти эту проблему – вести журналы всех серверов организации на отдельной удаленной машине. Этой удаленной машине по ведению журналов следует принимать только журнальный трафик с этих серверов. Таким образом, даже если какой-то сервер был взломан, все равно останутся записи журналов для дальнейшего анализа того, что произошло.
На журнальном сервере следует соответствующим образом настроить пакетный фильтр для отбрасывания любого трафика, кроме UDP/514. Журналы на журнальном сервере могут, помимо прочего, еще и архивироваться на съемные носители, такие ,как CD-R, WORM, или магнитную ленту.
В UNIX имеется очень мощная централизованная система ведения журналов. Действительно, некоторые приложения ведут свои собственные файлы журналов и не пользуются syslog. Тем не менее сама иерархия файловой системы разработана с поддержкой централизованного размещения, /var/log.
Кроме того, большинство систем UNIX и дистрибутивов GNU/Linux поставляются с автоматизированной системой ротации и управления журналами. Журналы автоматически ротируются на основании таких критериев, как размер или возраст, и могут автоматически же сжиматься (компрессироваться), переименовываться и даже архивироваться.
Чтобы еще сильнее улучшить журнальные возможности сервера UNIX или GNU/Linux, следует стандартный syslogd заменить на более прочную, настраиваемую и безопасную альтернативу, известную как syslog-ng. В ней имеются несколько значительных улучшений по сравнению со стандартным syslogd, куда входит возможность фильтрации сообщений на основании их содержимого, а не только пар facility.priority (источник.приоритет).
При помощи регулярных выражений информация об отдельных хостах может сохранятся в индивидуальных журналах. Syslog-ng, вероятно, уже входит в поставку операционной системы UNIX или дистрибутива GNU/Linux. Если же нет, его можно найти по следующему URL:
http://www.balabit.hu/en/products/syslog-ng/
На этом завершается наше обсуждение укрепления операционных систем UNIX и дистрибутивов GNU/Linux. Хотя данный материал также применим и к AIX11Например, настроить сетевую подсистему, как было показано в разделе 9.4.8, в ОС AIX можно при помощи команды "no"., в AIX присутствуют некоторые уникальные особенности, о которых будет рассказано отдельно в следующем разделе.