Cisco *

Как я ловил «двойной вход» удалённого объекта и закольцованный маршрут в распределённой сети

На днях разбирал инцидент, который на первый взгляд выглядел как «магия»: на одном из удалённых объектов внезапно пропали из сети три дома. Провайдер уверяет, что транспорт работает. В ядре ЦОД всё чисто. На объекте тоже — никаких видимых аварий.

Но в реальности всё было куда интереснее. Под катом — подробная диагностика, тонкости взаимодействия L2VPN-каналов и OSPF, и главное: как я решил ситуацию.

Архитектура, чтобы понимать контекст

В ЦОД у меня работает пара коммутаторов Cisco Nexus N3K-C3064PQ-10GX, которые образуют ядро. Через L2VPN приходят два транспортных VLAN-а:

• VLAN 3680 — основной

• VLAN 3790 — резервный

На обоих VLAN-ах настроены SVI из подсети 10.201.10.0/24 и они участвуют в маршрутизации.
OSPF area ядра — 0.

На объекте установлен Cisco C3750-48TS-S, который маршрутизирует локальные VLAN-ы (10, 20, 30, 40) в транспортную подсеть 10.201.10.0/24.

На объекте установлен:

• Cisco C3750-48TS-S — L3 коммутатор ядра объекта

• К нему подключены обычные L2-коммутаторы доступа (VLAN 10, 20, 30, 40 — локальные VLANы объекта)

• Именно C3750 маршрутизирует локальные VLANы в транспортную подсеть 10.201.10.0/24, через которую объект выходит в ЦОД

В штатной схеме дом должен ходить через VLAN 3680 → ЦОД → ядро.

Где всё сломалось

На объекте проводились аварийно-восстановительные работы, и три коммутатора доступа были подключены напрямую в ЦОД, минуя локальный C3750.
Подключены они были в транспорт VLAN 3790, который в норме является резервным.

То есть получилась такая картина:

Дома → три L2-коммутатора → VLAN 3790 → ядро в ЦОД → OSPF решает что маршрут в 10.10.20.0/24 через 10.201.10.24 → отправляет трафик назад → по VLAN 3680 → обратно на объект → C3750 → снова в ядро.

Это классический двойной вход одного и того же объекта с двух разных VLAN-ов.

Результат — кольцевой маршрут уровня L3:

1. Коммутаторы уходят в ЦОД через 3790

2. ЦОД видит маршрут на объект через 10.201.10.24 (который доступен только через 3680)

3. Возвращает трафик обратно на объект

4. Объект отправляет его снова в ЦОД

5. И так по кругу

В итоге дома — «в сети», но по факту недоступны: поток ESTABLISHED-сессий рвётся, ARP гуляет не туда, задержки скачут.

Почему это произошло?

Потому что:

1. Оба VLAN-а (3680 и 3790) настроены одинаково и оба включены в транспортную L3-схему.

2. В OSPF ядра есть маршрут в 10.10.20.0/24 через 10.201.10.24, а 10.201.10.24 живёт только по VLAN 3680.

3. Коммутаторы шли в ядро по другому VLAN-у — 3790, где нет “обратного” шлюза.

4. Получился L3 hairpinning с возвратом на тот же объект, но по другому пути.

Как я устранил проблему

Шаг 1 — исключил второй вход объекта

На ядре отключил маршрутизацию из VLAN 3790, оставив его чистым L2-транспортом. Конкретно:

• SVI с VLAN 3790 удалил

• Убрал его участие в OSPF

• Оставил VLAN 3790 только как резервный канал на случай L2-аварии

После этого пакеты, входящие на ядро по VLAN 3790, перестали “участвовать” в маршрутизации и не могли вернуться на объект по альтернативному пути.

Шаг 2 — вернул нормальный путь трафика

После того как VLAN 3790 перестал работать как L3-вход, трафик трёх коммутаторов:

• поднимался в ЦОД по 3790

• не находил для себя маршрута в сторону 10.201.10.24

• возвращался в объект уже по штатному пути, но через C3750

• корректно маршрутизировался

• и отправлялся обратно в ЦОД по VLAN 3680

Цикл прекратился.

Шаг 3 — восстановил схему объекта

Переключил три коммутатора:

• снял временные подключения в обход

• вернул их uplink-и за C3750

• восстановил штатную топологию

После этого связи на всех трёх домах восстановились.

Итог

Причиной инцидента стало то, что пакеты из резервного VLAN-а 3790 возвращались в объект по основному VLAN 3680, проходили через C3750 и снова отправлялись в ЦОД.

PS:. пишу данный пост накануне своего дня рождения, буду сильно благодарен, если в качестве подарка подпишитесь на мой (надеюсь хотя бы сейчас) начинающийся канал в Telegram

Cisco IOS/IOS XE CVE-2025-20352 — открытый SNMP ≠ «всё ок»

СКИПА фиксирует >30 000 устройств с SNMP v1/v2c в Рунете. Из них ≈1 700 выглядят потенциально уязвимыми к CVE-2025-20352.

Об уязвимости

CVE-2025-20352 — переполнение стека в подсистеме SNMP Cisco IOS/IOS XE. Нужны валидные SNMP-учётные данные:

• при низких правах возможен DoS (перезагрузка);

• на IOS XE при повышенных правах — RCE через специально сформированные SNMP-пакеты.

• уязвимость 0-day, т.е. уже используется злоумышленниками.

Что это значит по данным СКИПА

• Много устройств всё ещё отвечают по v1/v2c и/или на дефолтные сообщества public/private.

• ≈1 700 — версии и платформы, требующие проверки в Cisco Software Checker; наличие фикса зависит от релизной ветки (train) и конкретной платформы.

Признаки в логах/метриках

• Всплески SNMP auth failure, noSuchName, аномально частые запросы.

• Падение sysUpTime, повторные перезагрузки, записи в crashinfo.

• Нетипичные источники трафика UDP/161.

Рекомендации

1. Ограничить SNMP по ACL/CoPP (только менеджмент-хосты).

2. По возможности отключить v1/v2c, перейти на SNMPv3 (authPriv); сменить сообщества, если вынуждены оставить v1/2.

3. Обновить IOS/IOS XE до исправленных билдов по результатам Cisco Software Checker.

4. Мониторить sysDescr/sysUpTime и аномалии по UDP/161.

Быстрый самоаудит

Эксперты СайберОК опубликовали скрипт для экспресс-проверки.

О скрипте: быстрая и безопасная оценка экспозиции устройств Cisco IOS/IOS XE, связанная с CVE-2025-20352 (подсистема SNMP).

Сканируем подсети на SNMP через onesixtyone с дефолтными сообществами. Парсим баннеры sysDescr.0 Python-скриптом: помечаем Cisco IOS/IOS XE и проставляем статус Fixed (если в белом списке) или Potentially Vulnerable (проверить в Cisco Software Checker).

Проект не эксплуатирует уязвимость. Он лишь определяет устройства, отвечающие на дефолтные SNMP-сообщества, и извлекает версию из sysDescr.0.

Базовая настройка шифрования в Cisco ASA

Первым делом после установки лицензии надо сгенерировать сертификаты и настроить шифрование для ASDM, эти же настройки дадут A+/A- в тесте от SSL Lab:

crypto key generate rsa modulus 2048
crypto key generate ecdsa elliptic-curve 256
ssl server-version tlsv1.2
ssl client-version tlsv1.2
ssl dh-group group14
ssl ecdh-group group19
ssl cipher default custom "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256"
ssl cipher tlsv1.2 custom "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256"

Настройки соответствуют рекомендациям Mozilla с добавлением ECDHE-RSA-AES128-SHA256 для максимальной совместимости. На ASA 5506/5508/5516 изменить server-version можно только через CLI из-за отсутствия DTLS 1.2 в этих платформах.

И бонусом SSH:

ssh version 2
ssh key-exchange group dh-group14-sha256
ssh cipher integrity custom hmac-sha2-256:hmac-sha1
ssh cipher encryption custom aes256-ctr:aes192-ctr:aes128-ctr

AES-GCM, ChaCha20-Poly1305 и Ed25519 появились только в 9.16, а настройки выше достаточно безопасны и работают в пока ещё актуальной версии 9.12 для ASA 5500-X.