Прикладное проектирование брандмауэров: от теории к внедрению

Брандмауэры часто рассматривают как галочку: развернуть один, написать несколько правил, двигаться дальше. Но прикладное проектирование брандмауэров — это дисциплина сама по себе, и она определяет, действительно ли сегментация вашей сети сдержит злоумышленника или просто даст вам ложное чувство безопасности. В этом материале рассматриваются практические решения, которые отличают хорошо спроектированное развертывание брандмауэра от набора ad hoc правил.

Начните с зон, а не с правил

Перед написанием единого ACL определите ваши доверительные зоны. Типичная корпоративная архитектура отделяет хосты DMZ, обращенные в интернет, внутренние сети пользователей, уровни серверов/данных и сети управления/OOB. Каждая зона должна представлять определенный уровень доверия, и трафик между зонами должен быть исключением, которое требует обоснования, а не по умолчанию.

Четко определите, что должно законно взаимодействовать с чем. Этот инвентарь потоков трафика утомителен, но это основа, на которой строится все остальное. Пропуск этого этапа приводит к чрезмерно разрешительным правилам вроде "allow any-any between subnets", которые полностью сводят на нет цель сегментации.

Запрет по умолчанию — не подлежит обсуждению

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

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

Порядок правил и специфичность

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

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

Отслеживание состояния соединения и его пределы

Современные брандмауэры отслеживают состояние соединения, что позволяет писать правила только для направления инициирования и полагаться на механизм для разрешения обратного трафика. Это значительное упрощение по сравнению с фильтрацией пакетов без состояния, но это не замена осведомленности на уровне приложения. Брандмауэр с отслеживанием состояния, разрешающий исходящий TCP/443, не знает и не волнует, является ли этот трафик законным HTTPS или C2 каналом, туннелированным через тот же порт. Где это возможно, сочетайте принудительное применение брандмауэра с видимостью на уровне приложения — прокси, TLS инспекция, если политика позволяет, или идентификация приложений NGFW — вместо того, чтобы полагаться на номера портов как на прокси для намерения.

Фильтрация исходящего трафика заслуживает равного внимания

Организации одержимы входящими правилами и пренебрегают исходящими. Это противоположно взгляду с точки зрения реагирования на инциденты: как только злоумышленник получил точку опоры, средства контроля исходящего трафика определяют, смогут ли они экспортировать данные или связаться с инфраструктурой. Определите явные политики исходящего трафика для каждой зоны — серверы редко нуждаются в неограниченном исходящем доступе в интернет, и рабочие станции редко нуждаются в инициировании соединений с произвольными внешними IP адресами на произвольных портах. Строгое управление исходящим трафиком не остановит все, но это повысит стоимость деятельности после эксплуатации и повысит вероятность того, что аномальный трафик будет выявлен.

Управление изменениями и дрейф

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

Логирование и корреляция

Брандмауэр, который молча блокирует трафик, только наполовину полезен. Убедитесь, что блокированный и разрешенный трафик, представляющий интерес, логируется и отправляется в ваш SIEM или конвейер логов, с достаточным контекстом (зона, ID правила, источник/назначение, протокол) для поддержки расследования позже. Во время инцидента логи брандмауэра часто — это самый быстрый способ установить временную шкалу латерального движения или попыток экспортирования данных — но только если хранение и качество были настроены заранее.

Заключительные мысли

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

Для получения дополнительной информации о сегментации сети, корреляции логов и основах синей команды изучите связанные разделы в библиотеке DEFENSE_GRID Korra Studio.