Различные типы окружений firewall’а

Администрирование firewall’а

Встраивание firewall’ов в ОС

Другим ключевым фактором успешного управления окружением firewall’а является согласованность платформы. Firewall’ы должны быть реализованы на системах, содержащих встроенные ОС, которые специальным образом урезаны и усилены для приложений безопасности, например, представляют собой так называемый "бастионный хост". Firewall’ы никогда не должны размещаться на системах, которые имеют какие-либо опции, позволяющие проводить инсталляцию.

Конфигурирование ОС firewall’а должно быть основано на принципе оставления минимального множества возможностей. Все ненужные функциональности ОС, особенно компиляторы, редакторы и другие инструментальные средства разработки должны быть удалены до того как firewall начнет функционировать. Все необходимые patches ОС должны быть применены перед инсталляцией компонент firewall’а.

Конфигурирование ОС не должно абсолютно полагаться на модификации, сделанные в процессе инсталляции firewall’а. Программы инсталляции firewall’а основаны на минимально необходимых установках; дополнительные пакеты или модули при инсталляции могут быть не удалены или не запрещены.

Процедура укрепления, используемая при инсталляции, должна основываться на свойствах конкретной ОС, лежащей в основе. Должны быть выполнены следующие действия:

• Любые неиспользуемые сетевые протоколы должны быть удалены из ОС, на которой выполняется firewall. Неиспользуемые сетевые протоколы могут потенциально использоваться для получения доступа к firewall’у. Запрещение неиспользуемых протоколов гарантирует, что атаки на firewall, использующие технологии инкапсуляции протокола, не будут эффективны.
• Любые неиспользуемые сетевые сервисы или приложения должны быть удалены или запрещены. Неиспользуемые приложения часто применяются для атаки на firewall’ы, потому что многие администраторы небрежно относятся к модификации установок по умолчанию для управления доступом firewall’а. Кроме того, неиспользуемые сетевые сервисы и приложения обычно выполняются, используя конфигурации по умолчанию, которые, как правило, намного менее безопасны, чем реальные конфигурации.
• Любые неиспользуемые пользовательские или системные аккаунты должны быть удалены или запрещены. Данная проблема специфична для каждой ОС, так как все ОС различаются в терминах, в которых представлены аккаунты по умолчанию.
• Применение всех соответствующих patches ОС также является критичным. Так как patches и hot fixes обычно адресованы для решения проблем, относящихся к безопасности, они должны быть интегрированы в процесс построения firewall’а. Patches всегда должны быть протестированы на непроизводственной системе перед тем, как ставить их на производственную систему.
• Неиспользуемые физические сетевые интерфейсы должны быть удалены с сервера.

Стратегии восстановления после сбоев firewall’а

Существует много опций для выполнения дублирования и восстановления после сбоев сервисов для окружений firewall’ов. Данный диапазон возможностей включает как использование специально разработанных сетевых коммутаторов, так и применение настраиваемых "пульсирующих" механизмов для проверки доступности первичного firewall’а, чтобы в случае сбоя backup мог взять на себя функции основного.

Сетевые коммутаторы, которые обеспечивают балансировку загрузки и возможности восстановления после сбоя, представляют собой новейшие и наиболее продвинутые решения, доступные на сегодняшний день. В конфигурации восстановления коммутаторы просматривают ответную реакцию от основного firewall’а и перенаправляют весь трафик на запасной firewall в случае сбоя основного. Основным преимуществом такого решения является то, что коммутатор скрывает оба firewall’а за одним и тем же МАС-адресом. Этим обеспечивается возможность бесшовного восстановления после сбоя; во многих случаях установленные через firewall сессии не замечают сбоя основного firewall’а.

Решения, основанные на пульсации, обычно включают back-end или настраиваемый сетевой интерфейс, используемый для оповещения backup-системы в случае сбоя основного firewall’а. Такие системы реализуют надежную технологию восстановления после сбоя. Основной недостаток данного подхода состоит в том, что сессии, установленные к производственному firewall’у, всегда сбрасываются при перенаправлении на backup-ресурсы.

Решение, при котором реализуется метод восстановления после сбоя, часто имеет меньшую стоимость; решение, основанное на восстановлении на основе коммутаторов, является более дорогостоящим.

Возможности создания логов firewall’а

Практически все системы firewall’а обеспечивают ту или иную функциональность создания логов. Как обсуждалось ранее, логи в прикладном прокси являются более объемными, чем логи пакетных фильтров или firewall’ов stateful inspection. Причина в том, что прикладные фильтры анализируют большее число уровней модели OSI, чем пакетные фильтры.

Общим примером функциональности создания логов является приложение syslog в UNIX. UNIX syslog предназначен для централизованного создания логов, а также имеет много опций для их проверки и обработки. Данная программа создания логов доступна практически во всех основных ОС, включая Windows NT, 2xxx и все разновидности UNIX и Linux.

После того как логи firewall’а будут переданы централизованному серверу логов, могут использоваться различные пакеты для их обработки. Логи, основанные на syslog, могут также подаваться в качестве входа в пакеты анализа проникновения и использоваться для судебного расследования.

Те firewall’ы, которые не поддерживают интерфейса syslog, должны использовать свою собственную внутреннюю функциональность создания логов. В зависимости от платформы firewall’а, существует много инструментальных пакетов третьих фирм для поддержки и обработки логов.

Инциденты безопасности

Не существует простого ответа на вопрос, что такое инцидент безопасности.

В общем случае инцидентом безопасности является любое событие, в котором неавторизованный индивид получает или пытается получить доступ к компьютерным системам или ресурсам, на которые у него нет привилегий. Серьезность инцидента может отличаться, и компания сама дает строгое определение инциденту безопасности.

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

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

В сущности, определение инцидента безопасности определяется политикой безопасности организации.

Firewall’ы могут являться критичными элементами в контексте инцидента безопасности – они указывают на корреляцию событий. Корреляцию событий обеспечивает тот факт, что firewall’ы являются рубежом, который должны пересечь все сетевые атаки, чтобы войти в сеть. Это ставит firewall в уникальное положение по анализу неавторизованной деятельности. По этой причине все firewall’ы и другие системы создания логов, такие как IDS, должны выполнять синхронизацию времени. Наиболее общим механизмом для синхронизации времени является Network Time Protocol (NTP).

Создание backup’ов firewall’ов

Создание и сопровождение backup’ов является ключевой точкой в любой политике администрирования firewall’а. Для всех firewall’ов должен выполняться ежедневный backup.

В принципе, на всех firewall’ах всегда должны выполняться полные backup’ы. В инкрементальных backup’ах нет необходимости.

Обычно бывает трудно реализовать централизованную схему управления с доступом к firewall’у. Также предоставление доступа к централизованному серверу backup’а, который обычно расположен за firewall’ом, будет представлять большой риск с точки зрения секретности backup’ов. Следовательно, большинство firewall’ов должно использовать свои собственные устройства архивирования.

Также желательно (но не всегда возможно) использовать firewall’ы, у которых все критичные конфигурационные файлы расположены на CDROM. Для UNIX это является более реальным; основной директорией, требующей доступа по записи, является директория /var все логи обычно хранятся в данной директории. Развертывание firewall’ов, основанных на Windows, с read-only файловыми системами в настоящее время невозможно.