Heartbleed: ночной режим, обновляем OpenSSL и перевыпускаем сертификаты

Понедельник начался с того, что в районе восьми утра по нескольким чатам одновременно пошли ссылки на CVE-2014-0160. Heartbleed. К девяти стало понятно, что это не «надо обновиться на неделе», а «надо обновиться сегодня». К десяти мы уже работали в аварийном режиме.

Если коротко: уязвимость в реализации расширения TLS heartbeat в OpenSSL позволяет любому желающему читать случайные 64 КБ из памяти сервера за один запрос, без аутентификации, без следов в логах. Там могут оказаться приватные ключи, сессионные токены, пароли пользователей из буфера, что угодно. Уязвимость существует в OpenSSL 1.0.1 - 1.0.1f. Она присутствует в коде уже два года.

Это не «теоретическая возможность». Это работающий публичный эксплойт в день объявления.

Что мы делали весь день

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

Алгоритм был простой:

• Определить версию OpenSSL на каждом публичном сервере. openssl version на каждом хосте. Если 1.0.1 до буквы g - уязвим.
• Обновить пакет. На Debian/Ubuntu - apt-get update && apt-get install openssl libssl1.0.0. На CentOS - yum update openssl. Патч уже был в репозиториях.
• Перезапустить все сервисы, которые держат libssl в памяти. lsof | grep libssl показывает, что всё ещё работает на старой версии. Рестарт nginx, apache, postfix, dovecot, openvpn - по списку, с логированием времени.
• Отозвать и перевыпустить SSL-сертификаты. Вот здесь началось самое трудоёмкое.

Про сертификаты - отдельно

Обновить OpenSSL - это час работы при наличии реестра. Перевыпустить сертификаты - это несколько часов на каждого клиента, потому что у каждого свой CA, свои процедуры, своя скорость ответа саппорта.

Логика такая: если сервер был уязвим - его приватный ключ нужно считать скомпрометированным. Не «возможно скомпрометированным», а именно скомпрометированным - без возможности это проверить. Поэтому:

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

Второе - подаём запросы на перевыпуск во все удостоверяющие центры. У разных клиентов разные CA. Кто-то работает через Comodo, кто-то через отечественные. Скорость обработки запросов на перевыпуск в первые сутки после Heartbleed была... занятной. Все побежали одновременно.

Третье - после получения нового сертификата - отзываем старый через CRL/OCSP. Это не опциональный шаг: нужно, чтобы браузеры и клиенты не могли доверять потенциально скомпрометированному сертификату.

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

Где было сложнее всего

Не на Linux-серверах с apt/yum - там всё предсказуемо. Сложнее было там, где OpenSSL сидит глубже:

HAProxy, собранный из исходников несколько месяцев назад - его пакетный менеджер не обновляет. Пришлось пересобирать. Один из клиентов держит несколько внутренних сервисов с самодельной TLS-обвязкой поверх stunnel - как раз тот случай, про который мы предупреждали ещё в марте. Нашли и перезапустили.

Несколько устройств на периметре - балансировщики и reverse-прокси - работают на прошивках вендора с собственным OpenSSL. Там ждём обновления прошивки. Это единственное, что осталось не закрытым к концу дня.

Про ночной режим

К 23:00 все публичные серверы клиентов были обновлены, все сертификаты либо перевыпущены, либо заявка подана с контролируемым сроком. Это был длинный день. Не катастрофический, но плотный.

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

Что не помогло: рассчитывать на быстрый CA. Если перевыпуск сертификатов не автоматизирован через ACME или что-то подобное - в аварийной ситуации это ручной процесс с ожиданием.

Детальный постинцидентный чеклист - отдельным постом. Пока что Heartbleed не закончился: следующий шаг - ротация всего, что могло оказаться в той памяти.