Stateful-файрволы и NGFW

Урок объясняет, как файрвол принимает решения о трафике — от простой пакетной фильтрации до application-aware политик NGFW — и как выстроить безопасную базовую конфигурацию.

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

Файрвол — это первая линия сетевой обороны и почти всегда самая недооценённая. Защитнику важно понимать не «как закрыть порт», а как именно устройство принимает решение «пропустить или отбросить», потому что от модели принятия решения зависит, какие атаки вы вообще способны остановить. Этот урок — про эволюцию логики фильтрации и про то, как настроить её надёжно.

Зачем это знать защитнику

Большинство сетевых вторжений начинается с того, что атакующий находит «дырку» в правилах: забытый открытый порт управления, разрешённый исходящий трафик на произвольные адреса (через который потом уходит exfiltration данных), либо правило, которое смотрит только на порт и легко обходится туннелированием. Понимая внутреннюю механику файрвола, вы проектируете правила, которые трудно обойти, и замечаете, когда конфигурация деградировала со временем.

От пакетного фильтра к stateful

Самый ранний тип — пакетный фильтр без состояния (stateless). Он смотрит на каждый пакет изолированно: адрес и порт источника, адрес и порт назначения, протокол, иногда флаги TCP. Такой фильтр не помнит, что было до этого пакета. Проблема очевидна: чтобы разрешить ответы от веб-сервера клиенту, приходилось открывать широкие диапазоны портов в обе стороны, и атакующий мог слать пакеты с подделанными флагами, выдавая их за «ответную часть» несуществующего соединения.

Stateful-файрвол решает это, ведя таблицу состояний (state table / connection tracking). Когда изнутри сети уходит первый пакет нового TCP-соединения, файрвол записывает «четвёрку» (src/dst адрес и порт) и состояние соединения. Ответные пакеты пропускаются автоматически, потому что они соответствуют существующей записи. Пакет, который притворяется ответом, но не имеет записи в таблице, отбрасывается. Это закрывает целый класс трюков со спуфингом флагов.

# Иллюстрация концепции на nftables (лабораторная ВМ).
# Разрешаем уже установленные/связанные соединения по таблице состояний:
nft add rule inet filter input ct state established,related accept
# Новый входящий SSH — только с доверенной подсети управления:
nft add rule inet filter input ip saddr 10.0.0.0/24 tcp dport 22 ct state new accept
# Всё остальное на входе — отбросить (политика по умолчанию ниже).
nft add rule inet filter input drop

Ключевое слово здесь — ct state established,related. Это и есть «магия» stateful: одно правило вместо десятков обратных разрешений.

NGFW: фильтрация уровня приложения

NGFW (Next-Generation Firewall) добавляет к stateful-логике понимание уровня приложения (L7 модели OSI). Классический файрвол видит «TCP-порт 443» и считает, что это HTTPS. NGFW идёт глубже и определяет фактическое приложение внутри потока: действительно ли это веб-трафик, или кто-то туннелирует через 443 свой протокол управления ботнетом. Эту технику называют application awareness или Deep Packet Inspection (DPI).

Что умеет NGFW сверх обычного файрвола

  • Application-aware правила — политика формулируется в терминах приложений и пользователей: «отделу маркетинга разрешён Slack, запрещён BitTorrent», а не «порт 6881 закрыт».
  • Идентичность пользователя — интеграция с каталогом (LDAP/AD) позволяет писать правила на людей и группы, а не только на IP.
  • Инспекция TLS — контролируемая расшифровка исходящего HTTPS (с корпоративным CA), чтобы видеть содержимое и ловить вредонос. Делается строго прозрачно для сотрудников и с соблюдением закона.
  • Встроенные IPS и фильтрация репутации — многие NGFW совмещают функции файрвола и системы предотвращения вторжений (о ней — следующий урок).

Политика по умолчанию: default deny

Самый важный принцип проектирования файрвола — default deny (запрет по умолчанию, он же «whitelist-модель»). Политика строится так: запрещено всё, что не разрешено явно. Противоположность — default allow, когда разрешено всё, кроме явно запрещённого. Default allow обречён: вы не можете перечислить все плохие вещи, новые угрозы появляются ежедневно, и одна забытая строка открывает дверь.

# Псевдо-политика файрвола (концепция).
set default policy for INPUT   = DROP    # ничего не впускаем без причины
set default policy for FORWARD = DROP
set default policy for OUTPUT  = DROP    # да, исходящий тоже фильтруем

allow OUTPUT to DNS, HTTP, HTTPS (нужные адреса)
allow INPUT  established,related
allow INPUT  to web-app on 443 from any
allow INPUT  to SSH on 22 from management-subnet only
# конец списка — остальное падает в DROP по умолчанию

Обратите внимание на фильтрацию исходящего трафика (egress filtering). Её часто опускают, а зря: именно по исходящим каналам данные утекают наружу и вредонос связывается со своим командным сервером (C2). Ограничив, куда сервер вообще может ходить, вы превращаете успешную компрометацию в тупик для атакующего.

Как это работает под капотом

Под капотом stateful-движок поддерживает хэш-таблицу соединений с тайм-аутами: каждое соединение имеет таймер, и «зависшие» записи вычищаются, чтобы таблица не переполнилась. У этого есть оборонительное следствие — атака на исчерпание таблицы состояний (например, лавина полуоткрытых TCP-соединений, SYN flood) может переполнить state table и вызвать отказ. Поэтому в файрволах есть SYN-cookies и лимиты на число соединений с одного адреса.

DPI в NGFW работает иначе: движок реассемблирует поток, складывая пакеты в правильном порядке, и прогоняет полученные данные через сигнатуры приложений. Это дороже по ресурсам, поэтому NGFW — про баланс между глубиной инспекции и пропускной способностью. Расшифровка TLS — самая тяжёлая операция, её включают выборочно.

Как защититься

  • Стройте от default deny на входе, на форвардинге и на выходе. Любое разрешение — осознанное и задокументированное.
  • Минимизируйте поверхность: интерфейсы управления (SSH, web-админка файрвола) доступны только из выделенной management-сети, никогда из интернета.
  • Включите egress-фильтрацию — это ломает каналы exfiltration и C2.
  • Регулярно ревизуйте правила: правила накапливаются и «протухают». Удаляйте теневые (shadowed) и неиспользуемые правила, ищите слишком широкие any-any.
  • Логируйте отброшенный трафик выборочно — всплеск дропов часто первый признак сканирования или атаки.
  • Защититесь от исчерпания state table: лимиты соединений, SYN-cookies, rate limiting.

Итоги

  • Stateless-фильтр смотрит на пакеты изолированно; stateful ведёт таблицу соединений и пропускает только легитимные части диалога.
  • NGFW добавляет L7-понимание: application-aware правила, идентичность пользователя, инспекцию TLS, встроенный IPS.
  • Default deny — фундамент: запрещено всё, что не разрешено явно, включая исходящий трафик.
  • Egress-фильтрация ломает exfiltration и C2 — не пренебрегайте ею.
  • Регулярная ревизия правил и защита state table критичны для устойчивости.
Проверьте себя
1. Чем stateful-файрвол принципиально отличается от пакетного фильтра без состояния (stateless)?
AОн работает быстрее, потому что игнорирует заголовки пакетов
BОн ведёт таблицу активных соединений и пропускает пакеты как часть уже разрешённого диалога
CОн шифрует весь проходящий трафик
DОн отключает протокол TCP и оставляет только UDP
2. Что добавляет NGFW по сравнению с обычным stateful-файрволом?
AПонимание уровня приложения (L7): application-aware правила, идентичность пользователя, инспекцию TLS
BВозможность работать без электропитания
CЗапрет на использование протокола HTTPS
DАвтоматическое удаление всех логов
3. Почему политика по умолчанию должна быть «default deny», а не «default allow»?
ADefault deny быстрее обрабатывает пакеты
BНевозможно заранее перечислить все угрозы, поэтому безопаснее разрешать только явно нужное
CDefault allow требует больше оперативной памяти
DЭто требование протокола TCP/IP