CVE-2015-6323: как мы за сутки обновили Cisco ASA у нескольких клиентов и почему сетевое железо тоже надо патчить

В октябре Cisco выпустила бюллетень безопасности с несколькими уязвимостями в ASA - серии, которая стоит на периметре у большой части корпоративного рынка. Главная из них, CVE-2015-6323, затрагивает механизм аутентификации в ASDM и позволяет обойти её без валидных учётных данных. Есть и другие в том же пакете - часть касается WebVPN, часть - обработки IKE-пакетов. Все критические.

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

Как реагировали

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

Дальше - стандартный, но важный шаг: уведомили клиентов. Не в режиме «всё горит, немедленно», а с нормальным описанием: что за уязвимость, почему критическая, что нужно сделать, какой риск в случае промедления. Клиент должен понимать, зачем его беспокоят в четверг вечером и просят согласовать работы.

С каждым согласовали окно обслуживания. ASA - это периметр, просто так обновить и перезагрузить нельзя: есть время, когда трафик упадёт, есть люди, которые зависят от VPN. Кто-то дал окно в ту же ночь, кто-то попросил перенести на выходные. В рамках суток уложились со всеми.

Сама процедура обновления несложная, но требует аккуратности:

• Скачать образ с Cisco.com на локальный TFTP/SCP - заранее, а не в момент работ.
• Снять полный бэкап конфига - copy running-config куда-нибудь надёжное. На ASA это две минуты, но потом очень помогает.
• Проверить совместимость - не все версии ASDM работают с новым ASA OS, и наоборот. Cisco публикует матрицу, надо смотреть.
• Залить образ через CLI или ASDM, убедиться что boot variable указывает на новый файл.
• Reload - и ждать.
• Проверить что всё поднялось, VPN-туннели восстановились, трафик идёт.

Звучит как рутина. Но рутина, которую надо делать по каждому устройству, с бэкапом, с проверкой, без спешки - это и есть нормальный patch management.

Что неприятно осознавать

Пока делали обходы, поймали себя на мысли: патч-менеджмент для серверов у большинства клиентов есть. Windows Update настроен, yum cron-job крутится, за ядром Linux следят. А вот сетевое оборудование - роутеры, коммутаторы, файрволы - живёт в какой-то особой зоне, куда руки доходят по остаточному принципу.

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

Но CVE-2015-6323 хорошо иллюстрирует, почему это плохая идея. Файрвол - это не «просто железо», это единственный барьер между внешним миром и внутренней сетью. Уязвимость в нём интереснее, чем уязвимость на рядовом сервере: там сразу периметр, сразу VPN, сразу доступ внутрь.

Cisco выпускает security advisories регулярно. У них есть нормальный RSS-фид и почтовые уведомления - можно подписаться и получать бюллетени сразу при публикации. Это занимает пять минут на настройку и снимает вопрос «а откуда вообще узнавать». Аналогично у Juniper, Palo Alto и других вендоров.

Что теперь

По итогам этого эпизода решили формализовать процесс. Для клиентов на managed-обслуживании добавим в регламент явный пункт: сетевое оборудование - такой же объект мониторинга на предмет security advisories, как серверный стек. Не «обновляем когда вспомним», а подписка на уведомления вендора, оценка критичности в течение рабочего дня и планирование работ с приоритетом по severity.

Это не откровение и не изобретение велосипеда - просто оказалось, что очевидная вещь не была явно зафиксирована. Теперь будет.

Параллельно ещё раз напомнили клиентам про сегментацию периметра и политики доступа: даже если атакующий получит доступ через уязвимость в VPN-концентраторе, глубина проникновения определяется тем, что он увидит внутри. Но это уже отдельная история - про неё писали раньше в контексте микросегментации VLAN.