Heartbleed: постинцидентный чеклист - что проверить, когда веб уже обновлён

Через день после того, как первый шок от Heartbleed прошёл и все обновили nginx с apache, начали выясняться интересные вещи. У большинства клиентов «закрытый Heartbleed» оказался закрытым только по веб-части. Остальная инфраструктура - VPN, почта, базы, внутренние сервисы - осталась в статусе «разберёмся позже». Позже - это сейчас.

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

Шаг 0: инвентаризация OpenSSL-версий

Прежде чем что-то патчить - нужно знать, где OpenSSL вообще присутствует. Это не только веб-серверы. Список мест, где мы обнаруживали уязвимую версию:

• nginx, Apache, lighttpd - очевидно, это обновили в первый день.
• OpenVPN - использует системный или собственный OpenSSL. Если VPN-шлюз на Ubuntu 12.04/13.10 или CentOS 6 - почти гарантированно был уязвим. Это не веб, и об этом легко забыть.
• Postfix + Dovecot - SMTPS и IMAPS тоже ходят через OpenSSL. Почтовый шлюз с Heartbleed - это возможность читать из памяти сессионные данные входящих соединений.
• stunnel - часто используется как TLS-обёртка для того, у чего нет нативного TLS. Обновление пакета stunnel не всегда тянет за собой обновление libssl, которую он использует.
• HAProxy - если собирался из исходников, пакетный менеджер его не трогал. Проверяем ldd /usr/sbin/haproxy | grep ssl.
• PostgreSQL и MySQL с SSL-соединениями - если сервер принимает зашифрованные клиентские соединения через OpenSSL, он в списке.
• Nagios / Zabbix с TLS-агентами - мониторинг обычно не первый в очереди на обновление, и зря.

Команда для быстрой инвентаризации по хосту:

# Что слушает сеть и тянет libssl
lsof -n | grep libssl | awk '{print $1}' | sort -u

# Версия OpenSSL
openssl version -a

# Проверка уязвимости (heartbleed-тест)
openssl s_client -connect localhost:443 2>&1 | head -5

Для массовой проверки по парку серверов - Ansible-таск с openssl version по всем хостам и фильтрация по версии. У кого есть реестр с прошлого аудита - это работает за двадцать минут. У кого нет - придётся потратить больше.

Шаг 1: приоритеты перевыпуска сертификатов

Не всё можно перевыпустить одновременно - CA работают с очередями, у каждого клиента своя процедура. Поэтому расставляем по приоритетам:

Первые в очереди - всё публичное с клиентскими данными: HTTPS с авторизацией, API-эндпоинты, всё, куда ходят пользователи с паролями.

Вторые - почтовые шлюзы (SMTPS/IMAPS). Там в памяти могут быть учётные данные почтовых клиентов, которые подключались в период уязвимости.

Третьи - VPN. Обоснование: через VPN обычно ходит внутренний трафик, и клиентская база меньше. Но приватный ключ VPN-шлюза - это доступ к внутренней сети. Третий приоритет, не последний.

После всего - внутренние сервисы с self-signed сертификатами. Там тоже надо сменить ключи, но срочность ниже.

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

Шаг 2: что делать после смены ключей

Смена ключей и сертификатов - это ещё не финал. Параллельно:

• Ротация сессий и токенов. Если приложение хранит сессионные токены в памяти - они могли быть прочитаны. Принудительный разлогин всех активных сессий, ротация CSRF-токенов, API-ключей.
• Смена паролей служебных учёток на системах, которые были уязвимы и принимали соединения с авторизацией - хотя бы административных.
• Проверка CRL/OCSP. Отзыв старого сертификата должен быть зарегистрирован у CA. Если этого не сделать - клиенты, которые проверяют CRL, будут продолжать доверять компрометированному сертификату.

Про VPN отдельно

OpenVPN - особый случай. Несколько наблюдений из текущей работы:

Во-первых, многие держат OpenVPN на внутренних адресах, думая, что «снаружи недоступно, значит не страшно». Но если хотя бы один клиентский хост подключался к VPN-шлюзу из сети, где есть MITM-позиция, - уязвимость работает.

Во-вторых, у OpenVPN есть собственный механизм TLS-аутентификации (tls-auth). Если он настроен с pre-shared ключом - его тоже надо ротировать, этот ключ мог оказаться в памяти.

В-третьих, перезапуск OpenVPN после обновления - это разрыв всех активных VPN-сессий. Планируйте окно обслуживания.

Устройства, которые ждут вендора

Это отдельный, неприятный пункт. Несколько позиций в инфраструктуре клиентов пока не закрыты, потому что там OpenSSL зашит в прошивку:

• Сетевые балансировщики и L7-прокси с веб-интерфейсом управления.
• UTM-устройства с SSL VPN (Fortinet, Check Point, Cisco - у всех есть патчи, но скорость выкатки разная).
• Некоторые NAS с HTTPS-доступом к веб-интерфейсу.

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

Что из всего этого следует

Heartbleed показал кое-что очевидное, но неудобное: инвентаризация OpenSSL-зависимостей по инфраструктуре - это не разовое мероприятие «в момент кризиса». Когда в понедельник утром нужно за день обновить всё - ты либо уже знаешь, что где стоит, либо теряешь часы на разведку. У нас к 7 апреля был реестр с предыдущего аудита, и это реально помогло. У тех, у кого не было - пятница выдалась длинной.

Чеклист не закрыт: ждём прошивки от двух вендоров и завершаем ротацию токенов на нескольких приложениях. Это нормально - полная ликвидация последствий такого инцидента занимает не день и не два.