Темная сторона NGFW: проблемы, о которых не говорят вендоры. Уроки неудачных проектов

Денис Батранков, телеграм-канал Топ Кибербезопасности @safebdv

Рынок межсетевых экранов нового поколения (NGFW) переживает новый бум. По оценкам аналитиков, в 2025 году этот рынок оценивается в 5,4 миллиарда долларов по всему миру и будет расти со среднегодовым темпом около 10% до 2032 года. В России в 2024 году производители российских NGFW заработали 40 миллиардов рублей совокупно. Машинное обучение серьезно дополняет возможности NGFW, давая заказчикам обнаружение угроз нулевого дня, фишинговых сайтов и автоматизацию критически важных задач. Функционал межсетевого экрана сегодня еще и визуализирует происходящее в сети, показывая с какими странами и приложениями работают сотрудники и оборудование. Мечта ИБ и ИТ-директора, не так ли?

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

Основываясь на реальном опыте внедрений и анализе неудачных проектов, расскажем о десяти самых болезненных проблемах NGFW, которые почему-то редко упоминаются в глянцевых брошюрах вендоров. Если вы планируете внедрение — считайте это своеобразной "прививкой" от чужих ошибок. Вы обязаны проверить это!

1. TLS-инспекция: когда безопасность превращается в профанацию

Начнем с классики жанра. Ваш новенький NGFW установлен, политики безопасности настроены, TLS-инспекция включена — казалось бы, все идет по плану. И тут начинается веселье.

Пользователи жалуются, что "интернет сломался". Chrome и Firefox отказываются открывать половину сайтов, выдавая загадочные ошибки соединения. А все дело в том, что современные NGFW часто не поддерживают новейшие механизмы шифрования и протоколы вроде ALPN, HTTP/2, ChaCha20 и современные cipher suites.

По умолчанию такие сессии помечаются как "неизвестные" и автоматически блокируются. Что делают мудрые администраторы? Правильно — начинают массово добавлять исключения в список "no-decrypt". Через месяц этот список превращается в телефонный справочник, и половина трафика проходит без всякой инспекции. Ведь они точно также поступали раньше с прокси-серверами.

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

Что тестировать: обязательно проверяйте совместимость с современными TLS-соединениями на реальном трафике, а не только на синтетических тестах из лаборатории.

2. Коммит правил: когда 10 000 правил превращаются в кошмар

Представьте ситуацию: у вас в NGFW красуется солидная политика из 10 тысяч правил безопасности. Выглядит мощно! Но каждое изменение — даже самое мелкое — превращается в 20-минутную пытку ожидания применения этих правил на всех межсетевых экранах компании.

И это еще цветочки. В момент коммита вся система "замораживается" — нельзя ни внести изменения, ни откатить конфигурацию. А если вы ошиблись и текущий коммит может обвалить всю сеть? Добро пожаловать в еще одни 20 минут ожидания для отката! А я знаю клиента, у которого коммит занимает 40 минут. И это огромная компания.

Особенно "приятно" это ощущается в аварийной ситуации, когда каждая секунда на счету. Атака идет полным ходом, а вы сидите и смотрите на прогресс-бар: "Compiling rules... 45% complete".

Что тестировать: обязательно измеряйте время установки правил с учетом распределенной разливки на все устройства. Проверяйте наличие функции частичного коммита (partial commit) — это может спасти вам нервы и время.

3. Скорость записи логов: невидимка во время шторма

Логи — это глаза и уши вашего центра мониторинга. Но что происходит, когда на NGFW обрушивается DDoS-атака? Правильно — система начинает тонуть в собственных логах.

Очередь переполняется, буферизация не справляется, и NGFW начинает просто сбрасывать записи событий. Получается замкнутый круг: именно в момент атаки, когда логи нужны больше всего, система их теряет. В то время как администраторы восклицают: «Try harder» ваш NGFW пишет «conserve mode enabled».

Причем, центр мониторинга безопасности (SOC) ослепнет именно тогда, когда видеть сеть критически необходимо. А потом приходится расследовать инцидент по обрывкам информации — это как собирать пазл, у которого потеряли половину деталей.

Что тестировать: устойчивость отправки логов под максимальной нагрузкой. Хороший показатель — потеря менее 0,1% логов даже при пиковых нагрузках.

4. Обновления: русская рулетка для сетевой инфраструктуры

Вы получаете уведомление о критичном обновлении сигнатур безопасности. Устанавливаете. И тут начинается хаос — массовые обрывы пользовательских сессий, в кластерной схеме происходит failover, состояния соединений теряются.

Проблема в том, что компания купила NGFW, который не умеет обновляться "на лету" (hitless update). Каждое обновление превращается в полноценное "техническое окно" с остановкой сервисов. Администраторы начинают откладывать обновления, что увеличивает риски эксплуатации уязвимостей — получается классическая дилемма безопасности. И отключить межсетевой экран тоже нельзя – ведь потратили на это «добро» миллион долларов. И будут другие «вопросики» к тем, кто закупал. Ведь есть мнение, что за закупку Cisco на увольняют, правда?

Что тестировать: возможность обновления без разрыва сессий и скорость отката обновлений. Если откат занимает больше 5 минут — готовьтесь к бессонным ночам.

5. CPS: когда пропускная способность есть, а сервисы не работают

Финансовая организация закупила NGFW "на гигабит". По расчетам все сходилось — продуктивный трафик едва дотягивал до 600-700 Мбит/с. Устройство ввели в эксплуатацию, и... началось веселье.

Клиенты жаловались на "зависшие" платежи и ошибки в мобильном приложении. Проблема оказалась не в пропускной способности, а в количестве новых соединений в секунду (CPS). Современные приложения, особенно в финтехе и IoT, генерируют огромное количество коротких соединений — онлайн-банкинг, API-запросы, микросервисы.

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

Что тестировать: обязательно тестируйте CPS при реальном профиле трафика (короткие HTTPS-транзакции, API-вызовы, DNS-запросы). Не ориентируйтесь только на цифру "Гбит/с" в техническом паспорте.

6. VoIP: когда специализированный процессор не специализируется

В организации внедрили новый NGFW с рекламируемым "специализированным контентным процессором для ускорения DPI". Звучит впечатляюще! На начальном этапе все работало отлично, но с ростом нагрузки начались проблемы с корпоративной телефонией.

Выяснилось, что VoIP-трафик (RTP и сигнализация) этим чудо-процессором не поддерживался и обрабатывался обычным внутренним CPU с ограниченной производительностью. Результат — искаженный звук, эхо, обрывы соединений и срывающиеся видеоконференции.

Попытки создать исключения в политиках не решили архитектурное ограничение. В итоге пришлось отключать этот NGFW от сети и возвращать старый L4-файрвол.

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

7. HA-failover: кластер есть, отказоустойчивости нет

Схема Active/Passive с синхронизацией состояний выглядит красиво на диаграммах. Вендор обещает "бесшовное переключение", пользователи "ничего не заметят". На практике все оказывается сложнее.

Синхронизация сессий и приложений работает не для всех типов трафика, задержка переключения составляет 3-5 секунд вместо обещанной менее 1 секунды. При нагрузке в десятки тысяч соединений таблица состояний не успевает полностью копироваться, возникают "phantom-drops" — NGFW считает сессию активной, но пакеты теряются.

Результат — обрывы VPN, терминальных сессий, VoIP-звонков. Бизнес-критичные приложения требуют повторной авторизации, транзакции теряются. Администраторы теряют доверие к автоматике и планируют переключения только вручную.

Что тестировать: проверяйте HA под реальной нагрузкой с тысячами активных сессий. Хорошие показатели: переключение менее 1 секунды, потеря сессий менее 0,5%.

8. Active-Active: математика, которая не работает

Схема Active-Active кажется идеальной: два устройства по 1 Гбит/с дают в сумме почти 2 Гбит/с пропускной способности. Вы уже представили как это удобно? Но что происходит при отказе одного узла?

Весь трафик сваливается на единственный работающий узел с его пределом в 1 Гбит/с. Все, что выше этого значения, становится "лишним" и отбрасывается. Вместо плавного переключения получается резкое "срезание" трафика.

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

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

9. Виртуальные контексты: эффект домино в действии

Мульти-тенант режим выглядит привлекательно — один кластер для нескольких подразделений, централизованное администрирование, экономия на лицензиях. Что может пойти не так?

DDoS-атака на один из сервисов создает пиковую нагрузку в одном контексте. Но изоляция оказывается только логической — физические ресурсы (CPU, память, очереди пакетов) разделяются между всеми контекстами.

Результат — "эффект домино". Проблемы в контексте, отвечающем за периметр сети влияют на все остальные. VPN-подключения в соседних подразделениях начинают рваться, внутренние сервисы не работают, хотя их напрямую не атакуют.

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

10. Центр управления: когда централизация становится ахиллесовой пятой

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

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

Что тестировать: работоспособность системы при отключении центра управления. У NGFW должна быть полноценная локальная консоль для базовых изменений в критических ситуациях.

Как не наступить на те же грабли

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

Ключевые принципы успешного внедрения NGFW:

Тестируйте реальные сценарии. Забудьте про синтетические тесты из коробки. Используйте профили трафика, максимально приближенные к вашей продуктивной среде. Короткие HTTPS-транзакции, API-вызовы, VoIP, потоковое видео — все должно быть протестировано.

Проверяйте граничные случаи. Имитируйте отказы, пиковые нагрузки, аварийные ситуации. Именно в стрессовых условиях проявляются скрытые ограничения системы.

Измеряйте правильные метрики. CPS в NGFW важнее throughput, время коммита правил — критичнее количества правил, устойчивость работы системы журналирования — важнее скорости работы NGFW.

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

Думайте о масштабах. Тестируйте не на "лабораторной" нагрузке, а на том объеме, который будет через год-два после внедрения. Обычно трафик повышается на 30% в год.

Заключение: инвестиции в тестирование окупаются многократно

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

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

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