В облачной сети исходящее соединение разрешено, но отдельного входящего правила для ответа нет. За счёт какого механизма ответный трафик всё же проходит?
В типичной облачной stateful-группе безопасности ответный трафик проходит благодаря отслеживанию состояния соединения. Правило разрешает инициирующий пакет, а система фиксирует соединение в таблице состояний и автоматически пропускает пакеты, относящиеся к его обратному направлению.
Это не означает, что любой входящий трафик разрешён. Новое входящее соединение по-прежнему блокируется, если для него нет отдельного разрешающего правила.
Ранние сетевые фильтры часто работали как stateless ACL: каждый пакет проверялся независимо от предыдущих. Для TCP-соединения в таком случае пришлось бы явно разрешать обратные пакеты по эфемерным портам клиента, что усложняло правила и увеличивало риск слишком широкого доступа.
Stateful-фильтрация появилась как практический способ учитывать контекст соединения. Облачные группы безопасности обычно используют эту модель, чтобы правила описывали намерение: например, разрешить экземпляру инициировать HTTPS-соединения, не открывая весь входящий HTTPS-трафик.
Пусть виртуальная машина отправляет запрос к внешнему сервису на TCP-порт 443. Сервер отвечает с порта 443 на эфемерный порт клиента, поэтому ответ приходит во входящем направлении относительно виртуальной машины.
Если считать направление пакета достаточным основанием для блокировки, ответы будут потеряны, хотя исходящий запрос разрешён. Неверное понимание механизма приводит либо к недоступности внешних сервисов, либо к опасной попытке разрешить широкий входящий диапазон портов.
При первом разрешённом пакете фильтр создаёт запись о потоке: адреса и порты сторон, протокол и состояние TCP-соединения. Ответный пакет сопоставляется с этой записью и пропускается как часть уже разрешённого соединения.
Для UDP, не устанавливающего соединение в том же смысле, устройство обычно создаёт временное состояние по разрешённому потоку и использует его для обратных пакетов. Такая запись имеет тайм-аут, поэтому долго бездействующий поток перестаёт считаться разрешённым.
Важно различать stateful-группу безопасности и stateless сетевой ACL. Для ACL каждый пакет оценивается отдельно, поэтому обратное направление часто нужно разрешать явно. Конкретные правила, уровни применения и ограничения зависят от облачного провайдера, но сама логика stateful-фильтра требует именно ранее разрешённого и распознанного потока.
Состояние не отменяет проверку других механизмов: маршрут должен существовать, сетевой интерфейс и подсеть должны быть доступны, а локальный брандмауэр операционной системы не должен блокировать пакет. Кроме того, состояние обычно привязано к конкретному сетевому интерфейсу или потоку; изменение маршрута, адресации или истечение тайм-аута может нарушить сопоставление.
Компромисс stateful-подхода — необходимость хранить таблицу состояний и обрабатывать её на сетевом пути. При большом числе короткоживущих соединений заполнение таблицы или частые тайм-ауты могут стать ограничением, поэтому проектируют лимиты соединений и контролируют сетевые метрики.
Приложение в приватной подсети должно обращаться к внешнему API по HTTPS, но принимать входящие подключения только от внутреннего балансировщика. Команда заметила, что запросы к API проходят, а попытка исправить диагностику добавлением разрешения на входящий TCP-трафик с любого адреса устраняет проблему ценой потери изоляции.
Рассматривались два варианта. Первый — открыть входящий эфемерный диапазон: это плохо, потому что диапазон широк, правила сложны, а открытый источник увеличивает поверхность атаки. Второй — оставить разрешённым исходящий HTTPS и проверить работу stateful-группы безопасности, маршрута, DNS и локального брандмауэра: этот вариант сохраняет минимально необходимый доступ.
Выбрали второй вариант. После проверки выяснилось, что сетевой фильтр действительно пропускал ответы по состоянию, а причина сбоя находилась в маршруте приватной подсети к шлюзу выхода. После исправления маршрута внешний API стал доступен без добавления входящего разрешения.
1. Достаточно ли stateful-группы безопасности для прохождения ответа, если обратный маршрут отсутствует?
Нет. Отслеживание состояния отвечает только на вопрос фильтрации: относится ли пакет к ранее разрешённому потоку. Пакету всё равно нужен рабочий обратный маршрут, корректная маршрутизация через шлюз или транслятор адресов, а также отсутствие блокировки на конечном хосте.
2. Защищает ли разрешённый исходящий трафик от входящих соединений?
Да, но только в пределах модели фильтра и конкретного состояния. Ответ на соединение, инициированное изнутри, считается частью разрешённого потока. Новое соединение, инициированное снаружи, не должно пройти только потому, что наружу разрешён тот же порт: для него требуется отдельное входящее правило.
3. Чем опасно переносить модель stateful-группы безопасности на stateless ACL?
В stateless ACL обратный пакет проверяется самостоятельно. Поэтому нужно явно разрешить соответствующее обратное направление, включая необходимые адреса, протоколы и порты; набор правил зависит от используемого протокола и сетевой архитектуры.
Если такого правила нет, соединение будет выглядеть односторонним: запрос уйдёт, но ответ будет отброшен. Если же разрешить слишком широкий диапазон портов или адресов, доступность восстановится ценой ослабления сетевой политики.