Средняя
В безопасности есть соблазн верить в хорошие списки. Запретить опасные порты. Закрыть лишние направления. Отфильтровать подозрительные адреса. Заблокировать известные домены. Настроить категории. Добавить сигнатуры. Обновить правила. Повторить.
Это работает. Более того, без этого нельзя. Типовые правила фильтрации отсекают огромное количество мусора, автоматизированного сканирования, известных вредоносных сценариев и просто плохих инженерных решений. Они создают базовый санитарный слой, без которого сеть быстро превращается в проходной двор.
Но у этого подхода есть ограничение: типовое правило хорошо против типового нарушения.
А современная атака всё чаще старается выглядеть не как нарушение, а как обычный трафик. Она не всегда спорит с правилом. Она ищет разрешённую дорогу.
В отчёте УЦСБ SOC по ландшафту киберугроз 2025/2026 есть важная формулировка: алгоритмы помогают генерировать адаптивный вредоносный трафик и обходить типовые правила фильтрации. Этот тезис не стоит понимать как магию, где искусственный интеллект «взламывает firewall». Смысл гораздо практичнее и неприятнее: атаки становятся менее шаблонными, лучше маскируются под нормальное поведение и чаще используют те каналы, которые уже разрешены в корпоративной инфраструктуре.
И это меняет вопрос. Недостаточно спросить: «Мы заблокировали опасное?» Нужно спросить ещё и другое: «Мы понимаем, что у нас разрешено?»
Содержание
- Типовая фильтрация защищает от типовых сценариев
- Атакующий не спорит с правилом — он ищет разрешенную дорогу
- Алгоритмы делают атаку менее шаблонной
- Разрешённый трафик тоже должен быть объяснимым
- Нетиповая атака особенно любит широкие разрешения
- Нужна модель нормального доступа
- Сегментация должна быть не на схеме, а в правилах
- Типовые правила не должны быть одинокими
- Что стоит иметь в виду компаниям?
- Вывод
Типовая фильтрация защищает от типовых сценариев
Типовые правила нужны. Они закрывают очевидные ошибки и снижают шум. Не должно быть лишних открытых административных портов. Не должно быть широких доступов из недоверенных зон. Не должно быть прямых разрешений туда, где они не нужны. Не должно быть доступа «куда угодно и на что угодно», потому что однажды кому‑то было лень разобраться.
Но типовая фильтрация обычно строится вокруг заранее известных признаков: адрес, порт, протокол, категория, сигнатура, репутация, шаблон поведения.
Проблема в том, что атакующий тоже это понимает.
- Если порт заблокирован, можно попробовать другой.
- Если домен попал в список, можно сменить домен.
- Если сигнатура известна, можно изменить полезную нагрузку.
- Если прямой канал закрыт, можно использовать легитимный сервис.
- Если грубый скан заметён, можно двигаться медленнее.
- Если автоматический трафик палится, можно имитировать человеческие интервалы.
Типовые правила продолжают работать против массовых и грубых сценариев. Но чем более целевой становится атака, тем меньше она похожа на учебный пример из политики фильтрации.
Атакующий не спорит с правилом — он ищет разрешённую дорогу
Часто обход фильтрации звучит так, будто атакующий проламывает защиту. На практике он нередко делает другое: ищет то, что уже разрешено.
- Разрешён HTTPS наружу? Отлично.
- Разрешён DNS? Можно попробовать использовать его как канал.
- Есть доступ к облачным сервисам? Можно спрятаться в легитимной инфраструктуре.
- Есть подрядческий VPN? Можно использовать его как более доверенный вход.
- Есть удалённое администрирование? Можно идти по привычным для сети протоколам.
- Есть широкие межсегментные правила? Можно не ломать двери, а ходить по коридорам.
В этом смысле атака может быть нетиповой не потому, что использует невероятно сложную технику, а потому что использует обычные возможности сети не по назначению.
Это как с пропускной системой в здании. Можно пытаться взломать дверь. А можно войти вместе с курьером, воспользоваться служебным лифтом и пройти по маршруту, который формально никто не запрещал. Проблема не в том, что дверь плохая. Проблема в том, что внутри слишком много маршрутов без понятного контроля.
Так же и в сети. Если разрешённый канал слишком широкий, плохо описан и давно не пересматривался, он становится удобной дорогой для того, кто умеет выглядеть достаточно «нормально».
Алгоритмы делают атаку менее шаблонной
Когда говорят, что алгоритмы помогают обходить фильтрацию, речь не обязательно о чем‑то фантастическом. Часто это более простые, но эффективные вещи.
- Можно генерировать множество вариантов фишингового текста, чтобы он хуже попадал под типовые признаки.
- Можно менять структуру запроса, чтобы он отличался от известной сигнатуры.
- Можно подбирать интервалы активности, похожие на действия человека.
- Можно дробить передачу данных на небольшие части.
- Можно менять домены, пути, параметры, user-agent и другие признаки.
Можно быстрее адаптироваться к тому, что блокируется. - Можно использовать легитимные сервисы как промежуточную инфраструктуру.
То есть атака становится не обязательно «умнее» в человеческом смысле. Она становится пластичнее. Менее похожей на один заранее известный образец.
Для защиты это неприятно, потому что типовое правило часто ожидает типовой контур угрозы. А если угроза постоянно чуть-чуть меняет форму, простая проверка начинает хуже работать.
Это не отменяет фильтрацию. Но заставляет признать: нельзя строить защиту только на наборе заранее известных запретов.
Разрешённый трафик тоже должен быть объяснимым
Главный сдвиг здесь — от контроля запретов к пониманию разрешений.
Безопасность часто обсуждает, что нужно заблокировать. Но не менее важно понимать, что уже разрешено:
- почему этот сегмент ходит в тот сегмент;
- зачем этому серверу доступ наружу;
- почему пользовательская сеть видит административный интерфейс;
- почему подрядчик может обращаться не к одному хосту, а к целой подсети;
- почему тестовый контур имеет доступ к продуктивным системам;
- почему через это правило проходит такой объём трафика;
- почему сервис доступен всем, хотя используется двумя приложениями.
Пока разрешение объяснимо, им можно управлять. Когда оно превращается в «так исторически сложилось», оно становится риском.
Хорошее правило должно быть скучным: понятный источник, понятное назначение, понятный сервис, понятный владелец, понятный срок жизни, понятная причина существования. Если правило нельзя объяснить простыми словами, оно уже подозрительно — даже если формально ничего не нарушает.
Нетиповая атака особенно любит широкие разрешения
Широкое правило удобно бизнесу, эксплуатации и атакующему. Всем по разным причинам.
- Бизнесу — потому что «ничего не блокируется».
- Эксплуатации — потому что меньше заявок и инцидентов.
- Атакующему — потому что больше вариантов движения.
Чем шире разрешение, тем проще встроить в него нетиповой сценарий. Если между двумя сегментами разрешён большой набор сервисов, сложнее понять, какой трафик действительно нужен. Если наружу может ходить почти всё, сложнее заметить странный канал. Если подрядчику открыт целый диапазон адресов, сложнее доказать, что конкретное соединение лишнее. Если административные протоколы доступны из широких зон, атакующему не нужно искать сложный путь — он может использовать обычные инструменты.
Нетиповая атака не всегда требует нетипового протокола. Иногда ей достаточно типового протокола в нетипичном месте.
Именно поэтому гигиена правил доступа становится частью защиты от адаптивных атак. Чем точнее описана нормальная коммуникация, тем меньше пространства для маскировки.
Нужна модель нормального доступа
Типовые правила отвечают на вопрос: «Что мы точно не хотим разрешать?»
Но для современной защиты нужен ещё один вопрос: «Что для нас является нормой?»
Норма — это не абстрактное «разрешён HTTPS». Норма — это понимание связей:
- какой источник;
- к какому назначению;
- по какому сервису;
- для какого бизнес-процесса;
- с какой частотой;
- в каком направлении;
- из какой зоны;
- с каким владельцем;
- с каким ожидаемым поведением.
Если у компании нет модели нормального доступа, то ей сложнее отличить рабочее взаимодействие от злоупотребления разрешённым каналом. Всё начинает выглядеть одинаково: трафик есть, порт разрешён, соединение прошло.
Но безопасность начинается не только с запрета плохого. Она начинается с понимания хорошего.
Сегментация должна быть не на схеме, а в правилах
Ещё одна проблема типовой фильтрации — расхождение между архитектурной картинкой и реальной политикой доступа.
На схеме сеть может быть красиво разделена: пользователи, серверы, DMZ, подрядчики, технологический сегмент, управление, тестовые среды, продуктивные системы. В презентации всё выглядит строго. Но потом открываешь правила и видишь старые исключения, широкие доступы, временные разрешения, пересекающиеся группы, устаревшие объекты и маршруты, которые никто уже не готов объяснить.
Формально сегментация есть. Практически — между сегментами остались мосты.
И нетиповая атака как раз пользуется такими мостами. Она идёт не через идеальную архитектуру, а через фактическую сеть. Не через то, что нарисовано, а через то, что разрешено.
Поэтому защита от адаптивных атак требует регулярного сравнения архитектурного замысла с реальными правилами доступа. Если сегменты должны быть разделены, это должно подтверждаться не только схемой, но и политиками фильтрации.
Типовые правила не должны быть одинокими
Нельзя сделать вывод, что типовые правила бесполезны. Наоборот: они обязательны. Но они должны быть не единственным слоем защиты.
Типовые запреты должны дополняться контекстом:
- инвентаризацией активов;
- пониманием критичных сервисов;
- контролем межсегментных доступов;
- регулярным пересмотром исключений;
- анализом подрядческих подключений;
- контролем административных протоколов;
- проверкой неиспользуемых и широких правил;
- поведенческим мониторингом;
- историей изменений;
- понятной ответственностью владельцев доступов.
Если правило говорит «разрешить», рядом должен существовать ответ «почему». Если правило говорит «запретить», нужно понимать, не появился ли обходной разрешённый путь. Если фильтрация построена на типовых шаблонах, нужно регулярно проверять, не стала ли реальная инфраструктура слишком сложной для этих шаблонов.
Что стоит иметь в виду компаниям?
Первое: атака не обязана нарушать сетевую политику, чтобы быть опасной. Она может использовать то, что уже разрешено.
Второе: адаптивный трафик сложнее ловить простыми признаками. Если поведение меняется, одних статических шаблонов становится мало.
Третье: широкие разрешения увеличивают пространство для маскировки. Чем менее точное правило, тем легче спрятать в нем нежелательное поведение.
Четвёртое: разрешённый доступ должен быть объяснимым. Если никто не знает, зачем существует правило, значит, это уже не контроль, а наследство.
Пятое: сегментация должна проверяться по фактическим маршрутам, а не только по архитектурным схемам.
Шестое: подрядческие, пользовательские и сервисные зоны требуют отдельного внимания. Именно из таких зон часто начинается движение внутрь.
Седьмое: типовые правила нужны, но они должны жить внутри более широкой модели — модели нормального доступа.
Вывод
Типовое правило — хороший инструмент. Оно снижает шум, закрывает очевидные ошибки и помогает удерживать базовый уровень безопасности. Но против нетиповой атаки одного набора типовых запретов уже недостаточно.
Атакующий может не ломать правило. Он может выбрать разрешённый канал, подстроить поведение, использовать легитимный сервис, спрятаться в широком доступе или пройти через старое исключение.
Поэтому вопрос безопасности сегодня звучит шире: не только «что мы запрещаем?», но и «что мы разрешили, зачем, кому и насколько широко?».
Чем умнее и адаптивнее становится атака, тем опаснее защита, построенная только на списке типовых запретов. И тем важнее иметь понятную, скучную и регулярно пересматриваемую модель нормального доступа.
Потому что нетиповая атака чаще всего начинается не с преодоления запрета. Она начинается с поиска разрешённой дороги.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
