OpenSSL под лупой: аудит кода накануне новых релизов

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

Для нас это хороший повод наконец разобраться, где именно у нас живёт OpenSSL и что с ним будет, когда пойдут патчи.

Почему OpenSSL - это везде

OpenSSL - это не просто библиотека. Это фактически стандарт де-факто для TLS в Linux-мире. Что бы вы ни запустили на сервере, шансы что оно линкуется с OpenSSL - очень высокие. Nginx, Apache, Postfix, Dovecot, OpenVPN, stunnel, curl, Python-запросы через ssl - все они тянут одну и ту же библиотеку.

Это означает: один патч OpenSSL - это перезапуск всего, что его использует. И желательно понимать это заранее.

Что мы делаем: реестр сервисов

Мы прошлись по нескольким клиентским окружениям и составили типовой реестр того, что реально живёт на серверах и использует OpenSSL. Получилось несколько слоёв.

HTTPS и веб. Самое очевидное. Nginx и Apache на фронте, HAProxy если есть балансировка. У всех - OpenSSL. После патча нужен рестарт, и в большинстве случаев это zero-downtime если настроен graceful reload. Но нужно не забыть.

Почта. SMTP/TLS через Postfix, IMAP/POP3 через Dovecot. Здесь рестарт болезненнее - активные соединения рвутся, очередь может задуматься. Окно обслуживания желательно планировать, а не делать в час дня в пятницу.

VPN. OpenVPN у нескольких клиентов работает именно на OpenSSL - это не IPsec, не strongSwan, а именно OpenVPN поверх TLS. После патча нужно перезапустить демон, все активные туннели упадут и поднимутся заново. Если туннель один и он site-to-site - пара секунд простоя. Если это road warrior с двадцатью пользователями в рабочее время - нужно предупредить людей.

stunnel. Вот где регулярно забывают. stunnel - это TLS-обёртка для протоколов, которые сами TLS не умеют. Используется для шифрования legacy-трафика: старые базы данных через незащищённый порт, внутренние сервисы без нативного TLS. Линкуется с OpenSSL, требует рестарта. И про него вспоминают последним.

Системные утилиты. curl, wget, ldap-клиенты, различные агенты мониторинга - они тоже могут тянуть OpenSSL. Здесь рестарт не нужен в классическом смысле, но если библиотека обновляется без перезагрузки - старый процесс продолжает держать старую версию в памяти. lsof | grep libssl после патча показывает кто ещё работает на старом.

Как выглядит инвентаризация на практике

Быстрый способ найти всё что линкуется с OpenSSL на работающей системе:

lsof | grep -i libssl | awk '{print $1}' | sort -u

Более аккуратный вариант - через пакетный менеджер:

# Debian/Ubuntu
apt-cache rdepends --installed libssl1.0.0

# RHEL/CentOS
rpm -q --whatrequires openssl

Второй вариант честнее: показывает статически установленные зависимости, не только то, что сейчас открыто. Но первый полезен для проверки - иногда что-то линкуется динамически и в зависимостях пакета не числится.

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

Что с самим аудитом OpenSSL

Аудит, о котором идут разговоры в сообществе, - это попытка системно разобраться с кодовой базой, которая росла с начала 90-х и несёт в себе слои разных стилей и подходов. Код OpenSSL - это, мягко говоря, не образец для учебника по чистому коду. Там есть своя реализация malloc, своя обработка памяти, логика которую понимает полтора человека в мире. Аудит именно такого кода - работа трудоёмкая.

Нас как операторов инфраструктуры детали аудита интересуют меньше, чем его результаты. Если найдут что-то серьёзное - будет патч. Наша задача - быть готовыми к этому патчу, а не бегать по серверам с вопросом «а где у нас вообще OpenSSL».

Подготовка к патч-циклу

На уровне процессов это несложно. Реестр сервисов - готов. Для каждого прописан порядок перезапуска и ответственный. Для почтового сервера - окно обслуживания ночью. Для VPN - предупреждение пользователям. Для stunnel и аналогичных - включить в чеклист, потому что они иначе выпадут.

Мониторинг версии OpenSSL на хостах через Zabbix уже настроен у нескольких клиентов - item system.run[openssl version] раз в сутки, триггер на изменение. Не rocket science, но фиксирует факт обновления.

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

Пока тихо. Аудит идёт. Смотрим.