Проблемы и подвохи NGFW

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

Пример 1 ( https://t.me/safebdv/1497 ): TLS Inspection — «блокировка по умолчанию»
Пример 2 ( https://t.me/safebdv/1494 ): Сделали коммит правил — «парализовали компанию»
Пример 3 ( https://t.me/safebdv/1495 ): Скорость отправки и записи логов — пропуски системы управления
Пример 4 ( https://t.me/safebdv/1496 ): Обновления  = обрыв связи

1. TLS Inspection — «блокировка по умолчанию»

📉 Что было
- Заказчик включает инспекцию TLS, как требует его политика безопасности.
- После обновления браузеры Chrome/Firefox перестают открывать сайты с современными протоколами шифрования.
- Пользователи жалуются: «интернет сломался».

🔍 Причина
- NGFW не поддерживает новые механизмы (ALPN h2, ECH, новые cipher suites).
- По умолчанию такие сессии помечаются как «неизвестные» и блокируются.

🚨 Последствия
- Админы начинают массово добавлять исключения.
- Через месяц список «no-decrypt» = сотни доменов → фактически половина трафика проходит без инспекции.

✅ Вывод
- В тестах нужно проверять совместимость с современными TLS-функциями. А не только те, что у вас были в настройках IXIA в тестах.
- Иначе в продакшене TLS инспекция превращается в профанацию.


2. Сделали коммит правил — «парализовали компанию»

📉 Что было
- В NGFW создано 10 000 правил.
- При каждом изменении (даже маленьком) админ запускает «commit».
- Коммит длится 15–20 минут. Я встречал заказчика, у которого коммит длился 40 минут.

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

🚨 Последствия
- Время на внесение изменений увеличивается в 10 раз после смены поставщика. Это то что вы хотели?
- В аварийных ситуациях админы просто не могут быстро внести правило. А что если админ ошибся и текущий коммит обрушит сеть? Нужно снова ждать 20 минут чтобы вернуть правила обратно?

✅ Вывод
- В тестах NGFW обязательно замерять время компиляции и установки правил, с учетом распределенной инсталляции всех NGFW в стране.
- И проверять, есть ли поддержка partial commit.

3. Скорость отправки и записи логов — пропуски системы управления

📉 Что было
- Заказчик подключил NGFW к системе управления.
- При всплеске трафика (DoS-атака) система управления перестала принимать логи.

🔍 Причина
- Очередь логов переполнилась.
- Вместо буферизации и повторной доставки — просто сброс записей.
- Есть NGFW где локально вообще не хранятся события - их можно отправить только на систему управления или в SIEM.

🚨 Последствия
- SOC теряет видимость на время атаки и самой атаки
- Расследование инцидента невозможно - нет логов

✅ Вывод
- В тестах надо проверять устойчивость отправки логов под нагрузкой.
- Метрика: потери логов <0.1% даже при пиковых нагрузках.


4. Обновления  = обрыв связи

📉 Что было
- Вендор выпускает апдейт сигнатур.
- После установки — массовый сброс сессий у пользователей.
- В случае с кластером: failover + потеря состояния.

🔍 Причина
- Нет механизма hitless update или rollback.
- Обновления загружаются «наживую», не тестируются на стенде.

🚨 Последствия
- Каждый апдейт превращается в ночное «боевое окно».
- Часто админы откладывают обновления, что увеличивает риски уязвимостей.

✅ Вывод
- В тестах NGFW проверять: можно ли обновиться без разрыва сессий и откатить апдейт за минуты.