Ошибки настройки файрвола: почему сеть остается уязвимой

Я прогнал типовой набор правил через свою тестовую модель ревью конфигураций — не как магический сканер, а как быстрый генератор гипотез. Первый результат был предсказуемый: модель нашла 17 потенциально опасных правил, но половина оказалась шумом. После второй итерации промпта, где я заставил ее искать только сетевые риски с понятным путем эксплуатации, остались пять настоящих красных флагов: политика «разрешить всё», открытый RDP наружу, мертвые правила для старой подсети, VPN без многофакторной аутентификации и управление через небезопасный протокол. Именно эти ошибки настройки файрвола чаще всего и объясняют, почему не работает защита сети, хотя «файрвол же включен».

Файрвол не защищает, если его логика построена от удобства

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

Самая токсичная конфигурация выглядит невинно: сначала разрешаем всё, потом точечно запрещаем опасное. На практике такой режим быстро превращается в сетевую версию «оставили дверь открытой, но повесили табличку не входить». Сканер увидит открытые порты. Ботнет попробует стандартные учетные данные. Ошибка в сервисе получит сетевую поверхность для атаки.

Правильная логика обратная: запрещено всё, что явно не разрешено. Это и есть нормальный старт для принципа наименьших привилегий. Не «серверу нужен интернет», а «серверу нужен исходящий HTTPS к конкретному API». Не «офису нужен доступ к базе», а «приложению из подсети app нужен TCP-доступ к PostgreSQL на конкретном порту». Чем точнее правило, тем меньше модель атаки.

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

Разница между двумя подходами хорошо видна в базовой таблице.

Здесь нет романтики, только дисциплина параметров. Если правило нельзя объяснить одной фразой — «кто, куда, по какому протоколу, зачем» — оно уже подозрительное.

Ловушка «разрешить всё»: открытые порты как приглашение для сканера

Открытый порт сам по себе не взлом. Но открытый порт — это поверхность. А поверхность сегодня сканируется постоянно: автоматические боты ищут RDP, SSH, панели администрирования, базы данных, старые веб-консоли, тестовые API. Им все равно, малый у вас бизнес или крупная инфраструктура. Они не читают брендбук, они перебирают диапазоны.

Классический набор проблем сетевой безопасности начинается так:

1. Открыт административный доступ из интернета.

SSH, RDP, WinRM, панели управления гипервизором, web-admin сетевого устройства — все это не должно жить в публичной зоне без жесткого ограничения источников. Если доступ нужен администратору, делайте его через VPN, bastion host, jump server или отдельную управляемую зону.

2. Правило разрешает слишком широкий источник.

0.0.0.0/0 в source — это не «удобно для команды», а приглашение всем. Для публичного веб-сервера это нормально на 80/443, но странно для базы данных, брокера сообщений, Redis, Elasticsearch или внутреннего API.

3. Открыт диапазон портов вместо одного нужного.

Иногда в конфигурации встречается «разрешить 10000–20000», потому что «иначе приложение не заводилось». Это типичный след аварийной настройки. После запуска надо вернуться и сузить диапазон, иначе временный костыль становится постоянным туннелем.

4. Входящие и исходящие правила считаются одинаково безобидными.

Многие команды жестко фильтруют входящий трафик, но оставляют исходящий почти свободным. При компрометации сервера это помогает вредоносному коду стучаться наружу, скачивать payload, отправлять данные или подключаться к управляющему узлу.

Если нужно быстро понять, как настроить защиту сервера на базовом уровне, начинайте не с покупки нового решения, а с инвентаризации сетевой поверхности. Какие порты видны извне? Какие сервисы за ними стоят? У каждого ли есть бизнес-причина? Кто владелец правила? Когда оно последний раз пересматривалось?

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

«Мертвые» правила: невидимый мусор, который становится маршрутом атаки

Файрволы стареют не физически, а логически. За год инфраструктура меняется: переезжают приложения, закрываются стенды, меняются подрядчики, выводятся старые VPN-пулы, появляются новые облачные подсети. А правила остаются. Они уже никому не нужны, но продолжают работать.

Так появляются «мертвые» правила. Они опасны не потому, что прямо сейчас обязательно ведут к взлому. Они опасны тем, что создают скрытые связи между зонами. Сегодня старый адрес не используется. Завтра его получает новый сервер. Послезавтра этот сервер оказывается доступен из сегмента, который никто не планировал соединять.

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

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

Быстрая ревизия: найти очевидно лишнее

На этом уровне не надо строить идеальную Zero Trust-модель. Цель — убрать грубый мусор:

• правила без описания и владельца;
• правила с источником any, где он не нужен;
• доступ к выключенным или мигрировавшим системам;
• исключения для подрядчиков после окончания проекта;
• временные разрешения без даты удаления;
• дублирующие правила, где одно перекрывает другое;
• разрешения к тестовым средам из продуктивных сегментов.

Хороший маркер: если никто в команде не может объяснить правило за две минуты, его нельзя молча оставлять. Сначала переводим в режим наблюдения или ограничиваем, затем удаляем после проверки логов.

Глубокий аудит: проверить логику зон

Здесь смотрим не на отдельные строки, а на архитектуру. Есть ли сегментация? Отделены ли пользовательские рабочие станции от серверов? Может ли компрометированный ноутбук бухгалтера достучаться до базы? Есть ли отдельная зона для администрирования? Изолированы ли бэкапы? Не торчит ли мониторинг так, будто он сам не критичный актив?

Настройка файрвола ошибки часто прячет именно в связях между зонами. На схеме все выглядит прилично: DMZ, LAN, PROD, DEV, VPN. В правилах же обнаруживается, что DEV ходит в PROD «для удобства тестирования», VPN-пользователи видят слишком много, а сервер мониторинга имеет почти королевские права.

Аудит изменений: поймать источник хаоса

Отдельно надо смотреть процесс. Кто может добавлять правила? Есть ли заявка? Есть ли срок действия? Проверяется ли, что новое правило не конфликтует со старыми? Логируется ли изменение? Можно ли откатиться?

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

VPN-шлюз: не запасной вход, а главный объект атаки

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

Именно поэтому MFA для VPN — не украшение и не «добавим потом». Это обязательный параметр. В рекомендациях по защите сетевых устройств и VPN-шлюзов с 2020 года отдельно подчеркивалась необходимость усиливать удаленный доступ, потому что массовые атаки часто идут именно через него.

Слабая VPN-конфигурация обычно выглядит так:

• всем пользователям выдается одинаково широкий сетевой доступ после подключения;
• нет многофакторной аутентификации;
• нет разделения по группам и ролям;
• устаревшие учетные записи остаются активными;
• не проверяется состояние устройства пользователя;
• логи входов просматриваются только после инцидента;
• география и аномалии входа не анализируются.

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

VPN без MFA — это не защищенный периметр, а парольная дверь в инфраструктуру. Иногда крепкая, иногда нет, но все равно парольная.

Отдельный нюанс — аварийные аккаунты. Они нужны, но должны жить по строгим правилам: отдельное хранение, редкое использование, мониторинг каждого входа, регулярная смена секрета, ограничение источников. Иначе break-glass превращается в «вечный ключ под ковриком».

Управление файрволом: Telnet и HTTP должны уйти без церемоний

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

Для управления должны использоваться защищенные варианты: SSH вместо Telnet, HTTPS вместо HTTP. Но одной замены протокола мало. Управляющая плоскость файрвола должна быть отделена от пользовательского и публичного трафика. Админка не должна открываться из интернета просто потому, что «так удобнее подключаться из дома».

Минимальный рабочий набор для management plane:

1. Отдельная административная сеть.

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

2. Доступ только с доверенных адресов или через bastion.

Администратор сначала проходит через контролируемую точку входа, затем попадает в управляющий сегмент. Так проще логировать действия, применять MFA и ограничивать маршруты.

3. Индивидуальные учетные записи вместо общего admin.

Общий аккаунт убивает расследование. После инцидента вы не поймете, кто внес правило, кто отключил логирование и кто открыл порт наружу. Индивидуальная учетная запись плюс роль — базовая гигиена.

4. Отключение небезопасных сервисов.

Если Telnet, HTTP, старые версии протоколов или ненужные демоны включены «на всякий случай», они должны быть выключены. Не спрятаны, не забыты, а именно отключены.

5. Логирование административных действий.

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

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

Zero Trust без маркетингового тумана: меньше доверия, больше параметров

Zero Trust часто продают как большой ребрендинг безопасности. На практике полезная часть проще: не доверять автоматически сети, пользователю, устройству или приложению только потому, что они «внутри». Проверять контекст и давать минимальный доступ под задачу.

Для файрвола это означает переход от периметрового мышления к параметрическому. Раньше схема была такая: внешняя сеть плохая, внутренняя хорошая. Сейчас это не работает. Ноутбук может быть заражен внутри офиса. Учетка сотрудника может быть украдена. Облачная нагрузка может переехать. Подрядчик может подключаться из другой страны. Контекстное окно безопасности расширилось, и старый промпт «разрешить LAN» уже дает галлюцинации в виде лишнего доверия.

Zero Trust в настройке файрвола можно приземлить на понятные действия:

• Сегментировать сеть по функциям, а не по историческим VLAN.

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

• Применять least privilege для сетевых потоков.

Разрешать не «подсеть к подсети», а конкретный сервисный поток: источник, назначение, порт, протокол, назначение правила.

• Проверять идентичность и состояние устройства.

Особенно для удаленного доступа. Один пароль не должен быть единственным параметром решения.

• Логировать критичные переходы между зонами.

Если пользовательская сеть обращается к серверной, если DEV идет в PROD, если VPN-пользователь стучится к базе — это должно быть видно.

• Делать правила временными, если причина временная.

Доступ для миграции, теста, подрядчика, аварийной диагностики должен иметь срок жизни. Иначе он останется навсегда.

• Встраивать файрвол в эшелонированную оборону.

Файрвол не заменяет MFA, EDR, резервное копирование, управление уязвимостями, шифрование данных и мониторинг. Он закрывает сетевой слой, но не лечит всю безопасность разом.

Вот компактная модель, которую я использую при ревью. Не как чек-лист ради галочки, а как фильтр для каждого спорного правила.

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

Где ИИ помогает, а где опасно делегировать

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

Но у генерации есть лимит. Модель не знает вашу реальную топологию лучше команды. Она может уверенно предложить удалить правило, которое держит платежный шлюз. Может назвать нормальный поток подозрительным, если не видит архитектуру. Может не понять временную миграционную схему. Поэтому ИИ здесь — не автопилот, а ускоритель аудита.

Рабочий промпт для внутреннего использования я обычно строю по формуле:

1. роль модели: «ты анализируешь правила файрвола как сетевой security reviewer»;

2. границы: «не предлагай удаление без проверки логов и владельца»;

3. формат входа: зоны, правила, комментарии, последние срабатывания;

4. критерии риска: any-source, any-destination, admin protocols, VPN, межзоновые переходы;

5. требуемый вывод: риск, причина, уточняющий вопрос, безопасная итерация изменения.

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

Что реально исправляет уязвимую сеть

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

Исправление начинается с жесткой смены логики: запрет по умолчанию, разрешение по необходимости, MFA на удаленный доступ, SSH/HTTPS для управления, регулярный аудит правил, сегментация и least privilege. Zero Trust здесь не лозунг, а способ перестать доверять трафику только потому, что он пришел «изнутри».

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