Взяли один агент, один навык и одну выгрузку правил Ideco NGFW – и прогнали её через GigaChat Max и Claude Opus 4.8. Рассказываем, что из этого получилось, почему «настоящего» агентского теста не вышло и сколько всё это стоило в токенах и рублях.
Зачем мы это затеяли
В прошлой статье – «Пещера Аладдина для безопасника» – мы показывали, как автономный агент Hermes с открытой библиотекой Agent Skills разбирает IPS-логи и проводит аудит правил межсетевого экрана Ideco NGFW. Тогда мы сравнивали бесплатную фронтир-модель и платную Claude Opus и сделали осторожный вывод: для первичного triage хватает дешёвой модели, а для глубокого расследования лучше брать сильную.
Тот эксперимент оставил открытым один очевидный вопрос. Все «сильные» модели в нём были западными. А что покажет российская LLM на той же задаче?
Вопрос не праздный. Если вы – банк, госкомпания или объект КИИ, отправлять выгрузку правил вашего боевого файрвола в облако Anthropic – это в лучшем случае разговор с юристами, в худшем – прямое нарушение. GigaChat от Сбера работает в российском контуре, и если он справляется с аудитом конфигураций на приемлемом уровне, это меняет картину для целого класса заказчиков.
Поэтому мы взяли один и тот же агент (Hermes), один и тот же навык аудита и одинаковые входные данные – и подставили под него две модели: GigaChat Max и Claude Opus 4.8 (задумку с тестированием Claude Fable 5 для этой же задачи реализовать не удалось, со всеми нашими ИБ-скиллами он работать отказался, даже когда был доступен).
Идея простая: зафиксировать всё, кроме LLM, и посмотреть, что меняет именно модель.
Где сломался «честный» агентский тест
Сразу о неудаче, потому что она сама по себе результат.
Изначально мы хотели прогнать полноценный агентский сценарий: агент с навыком ideco-auditing-firewall (скоро откроем его в нашей документации) сам подключается к NGFW по API, выгружает правила, анализирует их и формирует отчёт. Навык специально оптимизирован для минимизации затрат токенов и размера контекста в запросах. Именно так работает агент на Opus.
С GigaChat этот сценарий не запустился на первом же шаге. Агент не смог подключиться к NGFW по API и выполнить нужную последовательность действий – то есть споткнулся ещё до того, как добрался до самого аудита. Computer/tool use у него еще явно не достаточен для автономной работы.
Агентский режим – это не про «умный чат, с которым можно обсудить Пушкина», а про умение надёжно вызывать инструменты: формировать корректные вызовы API, разбирать ответы, удерживать состояние между шагами и не терять цель в длинной цепочке. Модель может прекрасно рассуждать в чате и при этом разваливаться на tool calling. Здесь мы увидели ровно это.
Чтобы не сравнивать тёплое с мягким, мы упростили условия для обеих моделей: оставили тот же навык аудита, но вместо живого подключения к NGFW дали агенту готовую выгрузку правил в CSV. То есть убрали из задачи самый хрупкий для агента слой – работу с инструментами – и оставили чистую аналитику: «вот конфигурация, найди в ней проблемы».
Это уже не агентский тест в полном смысле. Но это тест на способность модели разобраться в реальной конфигурации файрвола – тоже полезная способность для специалистов по ИБ. И именно в таком виде сравнение стало корректным.
Подопытная конфигурация: 104 правила с заложенными ошибками
Выгрузка – это секция FORWARD реального по структуре конфига Ideco NGFW: 104 правила, CSV-экспорт из веб-интерфейса объёмом около 34 КБ. Мы специально насытили её типовыми ошибками, которые встречаются в живых инсталляциях, чтобы было что находить.
Несколько параметров выгрузки, чтобы понимать масштаб:
Сетевые зоны: LAN-Офис (192.168.10.0/24), LAN-Серверы (192.168.20.0/24), DMZ (172.16.30.0/24), Гостевая-WiFi (192.168.50.0/24), Управление (192.168.99.0/24), Филиал-СПб (10.20.0.0/16).
Формат правил: тип, протокол (tcp, udp, tcp_or_udp, icmp), источник и назначение (объекты ip, subnet, domain, ip_range, ip_address_list), интерфейсы, порты, расписание, флаги профилей IPS/DPI, действие (accept/drop), логирование и состояние (Enabled/Disabled).
Какие ошибки мы заложили – краткий список «закладок»:
ID правила | Что не так | Класс проблемы |
100 | drop any→any с комментарием «ВРЕМЕННЫЙ ЗАПРЕТ ВСЕГО (забыли убрать!)» перед финальным default-deny, логирование выключено (затеняет несколько дополнительных разрешающих правил) | критическая |
70–75 | Гостевой хост → внутренние серверы по RDP/SQL/SSH/HTTP/HTTPS/DNS | критическая |
16 | «Гость → офис разрешить (ОШИБКА КОНФИГ.)» | высокая |
58–69 | Серверы DMZ → внутренняя серверная сеть с админ-портами | высокая |
8, 10 | Публикация HTTP (80) и SMTP (25) из Интернета в DMZ без инспекции IPS/DPI | высокая |
26 | «Временное правило: разрешить ВСЁ из офиса в Интернет» | средняя |
21 | Полный дубликат правила 18 (блокировка одного и того же IP) | низкая |
33 | Бессмысленное правило LAN→LAN внутри одной зоны | низкая |
Отдельная тонкость, ради которой конфиг и собирался: часть опасных accept перекрыта вышестоящими drop. То есть формально дыры есть, но прямо сейчас они не «стреляют» – их спасает удачный порядок правил. Хороший аудитор должен это увидеть.
Что увидел Opus
Claude Opus 4.8 (через агент Hermes с навыком аудита) выдал структурированный отчёт по чек-листу с разбивкой находок по серьёзности.
Серьёзность | Находок |
CRITICAL | 2 |
HIGH | 5 |
MEDIUM | 8 |
LOW | 6 |
INFO | 2 |
Главное – он поймал смысл, а не только синтаксис. Несколько примеров.
Правило 100 как «тихий убийца». Opus не просто отметил drop any→any не на своём месте. Он проследил последствия: это правило делает мёртвыми нижестоящие 101–103 (egress ПК-Директора, AD и Mail-сервера в Интернет) и перекрывает штатный финальный default-deny с логированием – а значит, дропнутый трафик перестаёт логироваться, и появляется слепая зона для расследований. Не просто нашел ошибку, а понял ее опасность.
Перекрытые правила. По связкам гость→серверы (70–75), DMZ→серверы (58–69), гость→офис (16) Opus корректно зафиксировал: сейчас они перекрыты вышестоящими drop (ID 11/14/15) и не действуют, но это «мина замедленного действия» – при любой перестановке правил в веб-UI опасные accept оживут. Вывод модели: удалять, а не полагаться на порядок.
Контекст продукта. По публикациям без инспекции (HTTP на 80, SMTP на 25) Opus не ограничился «включите IPS», а предложил архитектурно верное решение в логике Ideco: публиковать веб через обратный прокси (там возможна защита модулем WAF и ограничения по источнику, в том числе GeoIP), а почту – через встроенный почтовый релей (также с соответствующей фильтрацией и защитой), со ссылками на нашу документацию. И отдельно отметил как образец правила, где IPS уже включён.
Главный тезис отчёта Opus сформулирован верно: конфигурацию «спасает» порядок правил, но это не должно считаться надёжной защитой. Дальше – приоритетный план действий из семи пунктов. Ровно тот уровень, которого ждёшь от инженера ИБ.
Что увидел GigaChat
GigaChat Max получил тот же навык и тот же CSV. Отчёт получился принципиально другим.
Сначала модель честно предупредила, что полный отчёт превышает лимит вывода (в какой конкретно лимит «уперлись» осталось не понятно, контекстное окно 256К, должно было хватить), и дала «основные моменты». Вот его итоговая сводка:
Проанализировано правил: 105
Выявлено избыточных правил: 4083
Обнаружено небезопасных правил: 0
Потенциально отсутствующих правил: 0
Цифра 4083 избыточных правила на конфиге из 104 строк – это сразу красный флаг. Из расшифровки видно, откуда она взялась: модель посчитала «перекрытием» почти любую пару правил, где совпадает источник или назначение:
Правило 2 перекрывается с Правилами 3, 4, 5, …, 103
Правило 3 перекрывается с Правилами 4, 5, 6, …, 103
Получился комбинаторный перебор пар, а не анализ. Получилось примерно ~5300 потенциальных пар, из которых модель отметила больше четырёх тысяч. Реального дубликата в конфиге ровно один – правило 21 повторяет 18. Остальные «перекрытия» – ложные срабатывания.
Но куда серьёзнее вторая строка: небезопасных правил – 0. Дословно:
Не обнаружено явно небезопасных правил, позволяющих произвольный доступ к ресурсам. Все обнаруженные правила соответствуют заданной политике безопасности.
Напомним, что было в конфиге: drop any→any, забытый перед default-deny; гость с доступом к серверам по RDP и SQL; публикации из Интернета без инспекции; «временное» правило «разрешить ВСЁ из офиса». GigaChat не отметил ни одной из этих проблем. Хуже того – он не увидел даже правила, которые сам автор подписал как «ОШИБКА КОНФИГ.» в комментарии.
Получилась картина, опасная не отсутствием ответа, а ложным успокоением: отчёт уверенно сообщает, что с безопасностью всё в порядке, при том что в конфиге заложены критические дыры.
Сравнение лоб в лоб
Критерий | Claude Opus 4.8 | GigaChat Max |
Запуск полного агентского режима (API к NGFW) | Да | Нет, не подключился на первом шаге |
Анализ CSV-выгрузки | Да | Да |
Критические находки (заложено 2) | Обе найдены и разобраны | 0 |
Высокие находки (заложено 5) | Все найдены | 0 |
Реальный дубликат правил (один) | Найден (ID 21 ↔ 18) | Утонул среди 4083 «перекрытий» |
Ложные срабатывания | Нет | ~4000 ложных «перекрытий» |
Понимание перекрытия правил порядком | Да, с выводом «удалять, а не полагаться на порядок» | Нет |
Привязка к продукту (реверс-прокси, почтовый релей, IPS) | Да, со ссылками на документацию | Нет |
Итоговый вердикт | «Конфиг спасает порядок – это хрупко» + план из 7 шагов | «Небезопасных правил не обнаружено» |
Разрыв в этом конкретном тесте получился не требующим дополнительных комментариев.
Почему так вышло и что из этого следует
Не будем делать из одного теста глобальных выводов о моделях – это было бы нечестно. Мы тестировали только конкретную применимость модели для узкой задачи информационной безопасности. Но несколько наблюдений отметим.
Агентность и качество рассуждений – разные оси. GigaChat не смог даже войти в агентский режим с инструментами, а на упрощённой аналитической задаче выдал поверхностный результат. Opus прошёл оба этапа. Для практической эксплуатации AI-агента в ИБ важны обе способности сразу: надёжный tool calling и глубина анализа. Просадка по любой из них делает агента бесполезным или, что хуже, опасным.
Навык не вытягивает слабую модель. Один и тот же навык ideco-auditing-firewall дал на двух моделях несопоставимый результат. Чек-лист и инструкции задают рамку, но интерпретировать конфигурацию внутри этой рамки модель должна сама. Навык – это усилитель, а не протез.
Ложноотрицательный результат опаснее отказа. Если бы GigaChat просто сказал «не справился» – это был бы честный исход. Но он выдал уверенное «всё безопасно» на дырявом конфиге. В руках неопытного администратора такой отчёт хуже, чем его отсутствие.
Важная оговорка про справедливость сравнения: мы тестировали конкретную версию GigaChat Max в конкретном агентском обвесе. Российские LLM развиваются быстро, и через несколько релизов картина вполне может измениться. Этот текст – срез на сегодня.
И ещё одно, ради чего всё затевалось. Сценарий, где чувствительный конфиг боевого файрвола не покидает российский контур, остаётся стратегически правильным – именно поэтому мы и хотим, чтобы локальные модели дозрели до уровня, на котором им можно доверить такой аудит. Пока же для серьёзного анализа конфигураций разрыв с фронтиром заметен.
Сколько это стоило
Отдельно – про экономику, потому что это та часть, где интуиция чаще всего обманывает.
Opus 4.8 (тариф $15/М вход, $75/М выход, чтение из кэша ~$1.5/М):
Вход: ~85–110 тыс. токенов без кэша, ~40 тыс. эффективных с prompt-кэшем.
Выход: ~9 тыс. токенов.
Итого за сессию: порядка $1–2 (с кэшем ближе к $0.9–1.3).
Основные «пожиратели» токенов – сам CSV-экспорт (34 КБ) и относительно большой файл навыка, которые частично переотправлялись на каждом ходу.
GigaChat Max (из панели управления):
Израсходовано: ~700 000 токенов.
Стоимость: 455 рублей (по тарифу GigaChat MAX)
Сопоставим напрямую:
Модель | Токены (≈) | Стоимость за сессию |
Claude Opus 4.8 | ~95–120 тыс. вход + ~9 тыс. выход | ~$1–2 (порядка 100–180 ₽) |
GigaChat Max | ~700 тыс. | 455 ₽ |
Парадокс налицо: модель, которая не справилась с задачей, сожгла в несколько раз больше токенов и обошлась дороже в рублях, чем модель с качественным отчётом. Большой расход токенов сам по себе ничего не говорит о пользе – он скорее намекает, что модель крутилась в задаче вхолостую. Оценивать стоимость AI-агента стоит не по цене за миллион токенов и не по абсолютному расходу, а по стоимости полезного результата.
Итог
Мы хотели сравнить GigaChat и Opus в агентском режиме – и не смогли: GigaChat не прошёл этап подключения к Ideco NGFW по документированному в навыке API. На упрощённой аналитической задаче по CSV разрыв оказался качественным: Opus поймал все заложенные критические и высокие проблемы и дал план действий, GigaChat свёл аудит к перебору пар правил и отчитался, что небезопасных правил нет.
Практический вывод на сегодня прежний, что и в прошлой статье, но теперь с поправкой на локальные модели:
Для реального аудита конфигураций нужна сильная модель и надёжный tool calling – по обоим пунктам фронтир пока впереди.
Российские LLM критичны там, где данные не должны покидать контур, поэтому их прогресс мы продолжим отслеживать и перепроверять.
Цена за токен и объём токенов – плохой ориентир. Считайте стоимость полезного результата.
Навык ideco-auditing-firewall, на котором строился тест, мы планируем открыть в нашей документации – чтобы вы могли воспроизвести эксперимент на своих данных и своих моделях. CSV с заложенными ошибками – доступен по ссылке.