Средняя
В правилах межсетевых экранов редко ищут драму. Обычно это воспринимается как эксплуатационная рутина: завести доступ, поправить объект, добавить сервис, согласовать исключение, закрыть заявку. Потом ещё одну. И ещё. Через несколько лет политика превращается в живой археологический слой: здесь следы миграции ЦОДа, здесь временный доступ подрядчика, здесь аварийное правило, здесь «не удалять, никто не знает зачем», здесь старый проект, который вроде бы уже закрыт, но лучше не трогать.
Проблема в том, что для атакующего все это не архив. Это инфраструктура движения.
Lateral movement — боковое перемещение внутри сети — начинается не тогда, когда злоумышленник «магически» оказывается в критичном сегменте. Оно начинается с маршрутов, которые уже есть. С разрешений, которые когда‑то были нужны. С широких правил, которые никто не пересмотрел. С доступов, которые открывали «на время», а потом забыли. С сервисов администрирования, которые доступны чуть шире, чем должны быть.
Именно поэтому гигиена правил МЭ — это не косметика и не бюрократия. Это способ уменьшить количество дорог, по которым атакующий может двигаться после первичной компрометации.
Содержание
- Первичный взлом — это только начало
- Старое правило — это будущий маршрут
- Не каждое разрешение одинаково опасно
- Lateral movement любит легитимные протоколы
- «Работает — не трогай» плохо сочетается с безопасностью
- Какие правила стоит искать в первую очередь?
- Hit count помогает, но не отвечает на все вопросы
- Хорошее правило должно быть скучным
- Гигиена правил — это процесс, а не генеральная уборка
- Меньше маршрутов — меньше ущерб
- Что стоит иметь в виду компаниям?
- Вывод
Первичный взлом — это только начало
Многие обсуждения кибератак сосредоточены на точке входа: фишинг, эксплуатация уязвимости, компрометация подрядчика, украденные учетные данные, внешний сервис. Это важно. Но первичный доступ сам по себе еще не всегда означает большой ущерб.
Настоящая проблема начинается дальше.
- Что доступно с первой скомпрометированной машины?
- Какие сегменты видны?
- Куда разрешены подключения?
- Открыт ли RDP, SSH, SMB, WinRM, базы данных, интерфейсы управления?
- Есть ли доступ к системам мониторинга, резервного копирования, каталогам, файловым шарам, административным подсетям?
- Можно ли использовать один сервер как плацдарм для следующего шага?
Атакующий не обязательно ломает сеть «в лоб». Часто он идёт по уже разрешённым путям. Использует легитимные протоколы, существующие правила, старые доверенные связи и привычную для инфраструктуры коммуникацию. Поэтому чем больше в сети лишних разрешений, тем больше вариантов для движения после первичного доступа.
В этом смысле политика МЭ — это не только механизм фильтрации. Это карта потенциального распространения атаки.
Старое правило — это будущий маршрут
У каждого широкого правила обычно есть история. Его редко создавали из злого умысла. Чаще всего всё выглядело разумно.
- Нужно срочно открыть доступ для проекта.
- Нужно временно подключить подрядчика.
- Нужно не сорвать запуск системы.
- Нужно быстро восстановить бизнес-процесс.
- Нужно «пока открыть шире, потом сузим».
- Нужно «не трогать, потому что работает».
Проблема не в том, что такие ситуации возникают. Они неизбежны. Проблема в том, что временные решения часто становятся постоянными.
- Правило остаётся после завершения проекта.
- Доступ остаётся после увольнения владельца системы.
- Подсеть меняет назначение, но правило не меняется.
- Сервис переезжает, но старые разрешения продолжают жить.
- Объект в группе расширяется, а вместе с ним незаметно расширяется доступ.
- Комментарий устаревает, заявка теряется, владелец забывается.
Так появляется «сетевой долг». Он не всегда виден в мониторинге. Он не обязательно ломает эксплуатацию. Более того, он часто делает жизнь удобнее: меньше заявок, меньше блокировок, меньше срочных разборов. Но с точки зрения безопасности этот долг превращается в набор готовых маршрутов.
Не каждое разрешение одинаково опасно
Гигиена правил не означает «всё закрыть». Сеть существует для взаимодействия, и бизнесу нужны доступы. Вопрос не в самом факте разрешения, а в его точности и обоснованности.
Опаснее всего правила, которые дают атакующему свободу выбора.
Например, доступ «сеть в сеть» вместо доступа от конкретного источника к конкретному назначению. Разрешение «any service» вместо одного порта. Доступ из пользовательских сегментов к серверным подсетям. Разрешение административных протоколов из широких зон. Старые правила для подрядчиков без срока действия. Группы объектов, куда годами добавляли новые адреса, но никто не пересматривал, какие правила начинают на них распространяться.
Такие правила могут быть незаметны в обычной эксплуатации. Но они резко увеличивают blast radius — радиус возможного распространения атаки.
Одно дело, если компрометация рабочей станции даёт атакующему доступ только к нескольким необходимым сервисам. Другое — если с этой станции можно обращаться к десяткам серверов, файловым ресурсам, базам данных или административным интерфейсам. В первом случае инцидент ещё можно локализовать. Во втором — сеть сама помогает атакующему двигаться дальше.
Lateral movement любит легитимные протоколы
Боковое перемещение не обязательно выглядит как что‑то экзотическое. Часто используются вполне нормальные для корпоративной сети протоколы и сервисы: RDP, SSH, SMB, WinRM, WMI, VNC, базы данных, панели управления, средства администрирования.
С точки зрения сети это может быть обычное соединение. Порт разрешён. Маршрут есть. Правило давно существует. Логирование, возможно, отключено или включено формально. Владелец доступа неизвестен. Исключение добавляли несколько лет назад.
Именно поэтому бороться с lateral movement только средствами обнаружения сложно. Нужно не только ловить подозрительную активность, но и уменьшать количество легитимных путей, которыми можно злоупотребить.
Сегментация и принцип минимальных привилегий звучат как базовые истины, но на практике они упираются в состояние правил доступа. Нельзя говорить о минимальных привилегиях, если правила МЭ годами не пересматриваются. Нельзя говорить о сегментации, если между сегментами остались широкие исключения. Нельзя говорить о контроле подрядчиков, если после VPN им доступно больше, чем требуется для работы.
«Работает — не трогай» плохо сочетается с безопасностью
В сетевой эксплуатации есть понятный страх: удалить правило и что‑то сломать. Этот страх не надуман. В больших инфраструктурах действительно сложно понять, используется ли доступ, кто его владелец и что произойдёт после отключения.
Поэтому правила часто не удаляют. Максимум — добавляют новые поверх старых. Политика растёт, усложняется, в ней появляются дубли, перекрытия, устаревшие объекты и правила без понятного назначения.
С точки зрения надёжности это кажется осторожностью. С точки зрения безопасности — это накопление неопределённости.
- Если никто не может объяснить, зачем нужно правило, это уже риск.
- Если у правила нет владельца, это риск.
- Если правило не использовалось годами, это риск.
- Если правило разрешает широкий доступ «на всякий случай», это риск.
- Если правило невозможно удалить, потому что все боятся последствий, это признак процессной проблемы.
Хорошая гигиена правил начинается не с удаления, а с понимания. Что разрешено? Зачем? Кому? На какой срок? Используется ли сейчас? Что произойдёт, если сузить или отключить доступ? Есть ли более точная альтернатива?
Какие правила стоит искать в первую очередь?
В любой крупной политике можно найти десятки типов потенциально опасных правил. Но для противодействия lateral movement особенно важны несколько категорий.
Первая — широкие межсегментные доступы. Особенно между пользовательскими и серверными зонами, между подрядческими и внутренними сегментами, между DMZ и внутренней сетью, между филиалами и ЦОД.
Вторая — административные протоколы. RDP, SSH, WinRM, WMI, VNC, SNMP write, доступ к web-интерфейсам управления, базам данных и системам резервного копирования должны быть ограничены максимально строго.
Третья — правила без ограничения сервисов. Если доступ нужен к одному приложению, он не должен превращаться в полный сетевой доступ между узлами или подсетями.
Четвёртая — устаревшие временные разрешения. Особенно созданные под миграции, аварии, внедрения, сопровождение и подрядчиков.
Пятая — правила без владельца и бизнес-обоснования. Если непонятно, кто отвечает за доступ, непонятно и кто принимает риск.
Шестая — неиспользуемые правила. Они могут не мешать сегодня, но создают потенциальную поверхность атаки завтра.
Седьмая — перекрывающие и дублирующие правила. Они усложняют анализ, создают ложное ощущение контроля и мешают понять, какое именно разрешение фактически работает.
Восьмая — правила без логирования. Особенно для чувствительных направлений, административных сервисов и межсегментных доступов.
Это не значит, что каждое такое правило нужно немедленно удалить. Но каждое из них заслуживает внимания.
Hit count помогает, но не отвечает на все вопросы
Статистика срабатываний правил полезна. Если правило не использовалось 180 или 365 дней, это сильный аргумент для пересмотра. Если правило срабатывает миллионы раз, это повод понять, какой именно трафик через него идёт. Если широкое правило используется только для одного сервиса, его можно сузить.
- Но hit count не должен превращаться в единственный критерий.
- Правило может редко срабатывать, но быть критичным для аварийного сценария.
- Правило может часто срабатывать, но быть слишком широким.
- Правило может не иметь срабатываний, потому что логирование отключено или данные собираются неполно.
- Правило может использоваться, но не теми источниками, ради которых его создавали.
Поэтому статистику нужно дополнять смыслом: владельцем доступа, назначением сервиса, критичностью направления, зоной источника и назначения, типом протокола, историей изменения.
Гигиена правил — это не механическое удаление всего неиспользуемого. Это регулярная проверка того, соответствует ли доступ текущей реальности.
Хорошее правило должно быть скучным
У хорошего правила МЭ нет ореола загадочности. Оно должно быть понятным.
- Кто источник?
- Кто назначение?
- Какой сервис?
- Зачем нужен доступ?
- Кто владелец?
- По какой заявке создан?
- Есть ли срок действия?
- Нужно ли логирование?
- К какому бизнес-процессу относится?
- Что будет, если доступ закрыть?
Если на эти вопросы невозможно ответить, правило становится проблемой. Даже если оно не содержит obvious horror вроде any-any.
В зрелой политике правила должны быть не только технически корректными, но и объяснимыми. Потому что безопасность начинается не с запрета, а с управляемости.
Гигиена правил — это процесс, а не генеральная уборка
Самая плохая стратегия — не трогать правила несколько лет, а потом объявить большой проект по очистке. Такие проекты обычно болезненны: много неизвестных зависимостей, владельцы систем не готовы, сетевики опасаются аварий, ИБ хочет быстрых результатов, бизнес боится простоев.
Гораздо лучше работает регулярная гигиена.
- Новые временные доступы должны иметь срок жизни.
- Широкие правила должны пересматриваться после стабилизации проекта.
- Подрядческие доступы должны проверяться отдельно.
- Административные протоколы должны быть вынесены в особый контроль.
- Неиспользуемые правила должны проходить процедуру подтверждения или отключения.
- Изменения в группах объектов должны анализироваться с точки зрения влияния на доступы.
- Критичные межсегментные направления должны периодически проверяться на соответствие политике безопасности.
Это не обязательно должно быть тяжёлым процессом. Важно, чтобы он был постоянным. Потому что правила стареют каждый день: меняется инфраструктура, появляются новые системы, уходят старые владельцы, завершаются проекты, меняются подрядчики, переезжают сервисы.
Если доступы не пересматривать, сеть постепенно начинает разрешать больше, чем бизнес реально требует.
Меньше маршрутов — меньше ущерб
Главная цель гигиены правил МЭ — не идеальная красота политики. Цель — снижение последствий компрометации.
Невозможно гарантировать, что первичного доступа никогда не будет. Пользователь может открыть фишинговое письмо. Подрядчик может быть скомпрометирован. На внешнем сервисе может появиться уязвимость. Где‑то может остаться слабая учётная запись. Это неприятно, но реалистично.
Вопрос в том, что произойдёт дальше.
Если сеть построена по принципу минимально необходимых доступов, атакующему придётся преодолевать больше барьеров. Если сегменты действительно разделены, а не только нарисованы на схеме, движение будет сложнее. Если административные сервисы доступны только из выделенных зон, их труднее использовать для распространения. Если временные доступы закрываются вовремя, старые проекты не превращаются в новые маршруты атаки.
Гигиена правил не отменяет EDR, SIEM, управление уязвимостями, контроль учётных записей и резервное копирование. Но она делает все эти меры сильнее, потому что уменьшает пространство, в котором атакующий может действовать.
Меньше маршрутов — меньше ущерб
Если смотреть на правила МЭ как на элемент противодействия lateral movement, важно держать в фокусе несколько принципов.
Первый: каждое разрешение должно иметь смысл. Не только технический, но и бизнесовый.
Второй: временные доступы должны быть действительно временными. Если срок неизвестен, это уже постоянный доступ.
Третий: административные протоколы требуют отдельного режима контроля. Их нельзя рассматривать как обычный прикладной трафик.
Четвёртый: подрядческие и сервисные зоны нужно анализировать отдельно. Компрометация такой зоны не должна открывать широкую дорогу внутрь сети.
Пятый: hit count полезен, но решение о правиле должно учитывать контекст.
Шестой: группы объектов опасны своей незаметностью. Добавление одного адреса в группу может расширить доступ сразу по десяткам правил.
Седьмой: правила без владельца и описания должны считаться техническим долгом.
Восьмой: очистка политики должна быть регулярной, а не героической разовой акцией.
Вывод
Lateral movement — это не только техника атакующего. Это ещё и отражение того, насколько сеть позволяет двигаться внутри себя.
Если в политике МЭ накопились широкие, устаревшие и плохо описанные правила, они становятся частью атакующей поверхности. Не потому что каждое из них обязательно опасно само по себе, а потому что вместе они создают лишние маршруты, увеличивают радиус поражения и усложняют локализацию инцидента.
Поэтому гигиена правил МЭ — это не наведение порядка ради порядка. Это практический способ уменьшить возможности атакующего после первичной компрометации.
Хорошая политика доступа должна отвечать не только на вопрос «почему это работает?», но и на вопрос «что произойдёт, если один из узлов будет скомпрометирован?». Если ответ неприятный, значит, правило пора пересматривать.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
