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

Зачем вообще смотреть на периметр

Классическая схема держится на идее, что до доверенного сегмента можно пропустить только «правильные» пакеты. На практике это значит, что атакующий всё равно достаёт до сетевого стека, драйверов, библиотек TLS и парсера прикладного протокола.

Именно поэтому firewall, WAF и IPS часто защищают не так, как ожидают владельцы систем: они уменьшают шум, но не убирают саму атакуемую поверхность. Если на одном из слоёв есть ошибка памяти или логики, удалённая атака может сработать ещё до авторизации.

Три подхода: от фильтра до разрыва пути

Один: классический периметр

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

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

Два: усиленный периметр с WAF и сегментацией

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

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

Три: схема без прямого входящего пути

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

Плюс в том, что исчезает большая часть pre-auth-поверхности атаки. Минус — выше сложность архитектуры и дороже перестраивать старые системы.

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

Кому что подходит

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

Если вы отвечаете за внутренние API, админские панели, финансовые системы или инфраструктуру с ценными данными, стоит смотреть на архитектуру без прямого входящего канала. Именно там firewall перестаёт быть главным щитом и становится лишь одним из элементов.

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

Почему это важно не только для серверов

Проблема периметра касается не одних дата-центров. Любой человек, который подключается к чужой Wi‑Fi-сети, доверяет не только точке доступа, но и всему пути до сервиса: от роутера до библиотек, через которые проходит его трафик.

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

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

Практический чек-лист

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