Файрвол всё разрешил: как вернуть нормальную настройку сети

В правилах межсетевого экрана строка: разрешить RDP из any. Комментарий пустой, дата — четыре года назад. Кто просил — неизвестно. Работает ли до сих пор тот подрядчик — тоже. Аудит периметра снова переносят: «пока нет времени, потом разберём». Потом обычно наступает после странного логина или отчёта пентеста.

Firewall «всё разрешил» — это редко из злого умысла: обычно это накопленные исключения, которые никто не отзывал.

Как периметр расползается

Сценарий срочного доступа. Нужно «на час» пустить интегратора. Час превращается в постоянное правило. Человек уходит, правило остаётся.

Сценарий shadow IT. Подняли новый сервис, порт открыли «как в инструкции из интернета», не занесли в схему. Через год таких дыр десяток.

Сценарий «временно any». При отладке разрешили широко, сузить забыли. На нагрузке всё стабильно — стимула закрывать нет, пока не припрёт.

Ошибки, которые оставляют двери открытыми

Правила без владельца и срока жизни. Нет даты пересмотра — нет пересмотра.

Смешивать north-south и east-west без политики. Внутри сети «всем всё» считается нормой, пока ransomware не подтвердит обратное.

Путать «у нас есть firewall» с «у нас есть политика». Железо без дисциплины — декорация.

Как наводить порядок без остановки бизнеса

Начинают с инвентаризации правил и сопоставления с реальными сервисами. Что слушается снаружи, кто этим пользуется, есть ли альтернатива через VPN или-jump-host. Правило без подтверждённого владельца помечают на отзыв.

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

Изменения вводят волнами: сначала мониторинг попыток по кандидатам на закрытие, потом сужение, потом удаление. Резко выпилить всё «лишнее» за ночь можно, но цена ложных простоев высока. Лучше контролируемое сжатие.

Сегментация внутри: платежные и учётные контуры не обязаны видеть весь офисный-Wi-Fi. Даже базовая нарезка-VLAN/зон снижает радиус поражения.

Опытный подход к настройке сети и сопровождению включает регулярный пересмотр правил по календарю — раз в квартал, не «после инцидента». Периметр, который не ревизят, неизбежно дрейфует к any.

Практический набор артефактов

• реестр внешних публикаций с владельцем и сроком;
• запрет правил-without-ticket/change;
• алерты на новые-allow-извне и на сканирование;
• схема зон: что считается DMZ, LAN, management.

Как разговаривать с бизнесом про закрытие доступов

Сужение периметра почти всегда встречает сопротивление: «нам так удобно», «клиент привык», «подрядчик приедет только так». Перевод в язык риска помогает: вот порт, вот кто может стучаться, вот что будет при компрометации учётки. Удобство без срока действия — скрытый кредит под высокий процент.

Для легитимных внешних сценариев готовят безопасную альтернативу до отключения any: VPN, портал заявок, временный доступ с автоотзывом, jump-host. Иначе люди снова проложат дыру «временным» правилом.

После первой волны чистки включают контроль изменений. Любое новое allow — через заявку с владельцем и датой пересмотра. Без этого через год вы вернётесь к той же простыне правил.

Полезно связать сетевую политику с инвентарём сервисов. Если сервиса уже нет, правило должно умереть автоматически в процессе вывода из эксплуатации — а не висеть «на всякий случай».

Итог

Firewall становится защитой только вместе с политикой и регулярной ревизией. Железо с правилом any — декорация.

Для бизнеса порядок на периметре — это меньше шансов на простой инцидент «открытый админский порт» и больше ясности: кто к чему имеет доступ и почему. Такая ясность дорогого стоит в момент проверки или атаки.

Что это даёт бизнесу

Закрытый по смыслу периметр уменьшает вероятность простого внешнего взлома и случайного «засвеченного» админского порта. Но важнее другое: появляется управляемость. Когда правило можно объяснить за минуту, сеть перестаёт быть тёмным лесом.

Инцидент всё ещё возможен. Разница в том, что вы не узнаёте о лишнем 3389 из чужого отчёта. Вы знаете свой внешний контур сами — и держите его в таком виде сознательно, а не по наследству.

Свяжите чистку правил с inventory приложений. Если приложение вывели из эксплуатации, внешние allow должны закрываться в том же change. Иначе периметр хранит память о мёртвых сервисах дольше, чем компания хранит сами сервисы.

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

Введите автоистечение для временных allow и отчёт «что истекло/что продлили» раз в месяц. Временность должна быть технической, не словесной.

Сверьте внешние публикации с данными сканера периметра. Расхождение списка — повод для внеочередной ревизии.

Запретите комментарий к правилу в стиле «не трогать». Требуйте имя владельца и заявка. Анонимные правила живут вечно.

Снимите инвентарь всех any/any и широких allow на админские порты в первую очередь. Это быстрый выигрыш риска.

Каждое оставленное исключение должно иметь дату следующего пересмотра в календаре, не в комментарии «потом».

После чистки покажите бизнесу «было/стало» по числу внешних публикаций. Политика держится, когда прогресс виден.

Сверьте правила с реальными flow-логами: что реально ходят, а что только «разрешено на всякий случай». Мёртвые allow закрывают первыми.

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

Периметр, который нельзя объяснить за пять минут, почти наверняка содержит лишние двери. Объяснимость — хороший тест политики.

Регулярный пересмотр правил дешевле любого красивого «единоразового аудита», который забыли через полгода.