Безопасная настройка TLS всегда был головной болью. Как для владельцев небольших ресурсов, так и для компаний, размер инфраструктуры которых может достигать нескольких сотен или даже тысяч доменов. Проблемы с TLSSSL появляются постоянно — уязвимости в самих протоколах, крипто-алгоритмах или их имплементациях. От всем известных Poodle и HeartBleed, до достаточно экзотичных и свежих (CVE-2016-2107) проблем с AES-NI.
А к чему приводят проблемы с TLS?
К краже учетных записей пользователей, администраторов, внедрению в трафик вредоносного контента, рекламы или, как это было с HeartBleed, даже к прямому доступу к памяти сервера.
Давайте взглянем на картину в целом.
На июль 2016 по данным проекта SSL Pulse, который анализирует настройки Alexa Top 200k доменов:
- 40% из них имеют ошибки в конфигурации или используют недостаточно стойкие наборы алгоритмов шифрования
- 25% имеют серьезные проблемы приводящие к реальной реализации атак на пользователей ресурсов или на сами ресурсы
А значит, у всех нас проблемы!
Кто виноват ?
Нам кажется, что это во многом это является следствием того, что TLSSSL это достаточно сложная штука и разобраться в том, как готовить её безопасно — совсем не просто. К счастью, в нашем распоряжении имеются несколько сервисов, здорово облегчающих эту задачу:
» Qualis SSL Labs
» Comodo SSL Analyzer
» Mozilla SSL configuration Generator
А что конкретно мы хотим узнать, когда ставим себе задачу проверки настроек TLS:
- Есть ли уязвимости в используемой нами версии библиотеки ?
- Достаточна ли надежность используемых нами алгоритмов и длин ключей ?
- Поддерживаем ли мы механизмы ускоряющие работу TLS, и делающие наш сайт быстрее для пользователей ?
- Когда подойдет время устаревания сертификатов для наших доменов ?
А также другие важные вещи — наличие PFS, Secure Renegotiation, HSTS, Key Pinning, Session Resumption и пр. Перечисленных терминов хватит на пяток отдельных статей, так что не будем углубляться в дебри.
Давайте посмотрим как это выглядит на примере Qualys SSL Labs: сервис отличный и выдает практически всю требуемую нам информацию:
Что делать?
В своё время, мы c Crait задумались над мониторингом SSL/TLS у нас. Надо сказать, что несмотря на то, что публичные сервисы по проверке SSL уже существовали, мы не смогли извлечь из этого пользы, ведь размер нашей инфраструктуры был очень большим. А это разнесенные по нескольким ДЦ в разных городах, управляемые разными системами деплоя конфигов, не связанные между собой сервера, что делало ручной анализ или какой-либо персонифицированный подход невозможным.
Нам нужен был инструмент, который позволит удобно собрать в одном месте информацию о всех наблюдаемых доменах. Выделить проблемы настройки и наличие уязвимостей, отсортировать сервера по интересующим нас критериям, построить удобную инфографику и обеспечивать актуальность информации. Вы, наверное, уже догадались, что речь идет об Elastic + Kibana. Давайте приступим.
Создание решения
Для начала нам нужен функционал который позволит собирать информацию о доменах. У Qualys SSL Labs есть API и консольный клиент для него. К сожалению, он работает медленно, а для нас время обхода серверов было критично + клиент имеет определенные баги, вроде умения уходить в бесконечный сон, в случае, если одновременно посылается слишком много запросов к API.
Мы c вами ведь модные ребята? Модные, поэтому будем делать не просто враппер для cli, а микросервис! Вернее несколько. Почему именно так — будет понятно дальше. Большое спасибо за Михаилу Аксенову Crait за написание и упаковку.
Был написан скрипт реализующий многопоточные запросы к ssllabs с помощью их cli, умеющий по итогам выполнения запроса собрать данные в JSON, отправить в Elastic, писать логи и обходить имеющиеся проблемы api. Код доступен на github, будем рады любому вкладу в проект!
Что нам еще нужно? Поднять Elastic, Kibana и подружить это все друг с другом. Разумеется мы не хотим делать это все руками, а воспользуемся Docker. Cлинкуем контейнеры и запустим с помощью Compose.
У нас получится следующая схема взаимодействия:
+--------------+
|tls-monitoring| ------> Internet
+--------------+
|
| Post data to Elastic REST api at port 9200
|
+--------------+
|Elasticsearch |
+--------------+
|
| Get data from Elastic REST api at port 9200
|
+---------------+
| Kibana | -----> UI localhost:5601
+---------------+ Предварительно вы можете организовать сбор информации о ваших (или чужих) доменах, с помощью (например) выгрузки зон с DNS серверов.
Docker-Compose лучше установить из pip, т.к версии имеющихся в репозиториях некоторых дистрибутивов настолько свежие, что не могут удовлетворить зависимости Compose к Python.
pip3 install docker-compose
wget https://raw.githubusercontent.com/dordyan/tls-monitoring/master/docker-compose.yml
# Записываем интересующие вас домены в файл ./all_domains
docker-compose upЧто получилось
Через несколько минут вы получите результаты первых сканирований. Реализованная на текущий момент дашборда достаточно информативна, чтобы на её основе строить процессы мониторинга и контроля состоянии инфраструктуры.
Вы можете отсортировать дашборд по оценке, чтобы увидеть на какие сервера нужно обратить внимание в первую очередь.
И добавлять свои визуализации, например по уязвимости к POODLE, Heartbleed или по любым другим данным, которые предоставляет скрипт. Чтобы посмотреть что еще есть в базе, откройте вкладку Discover и разверните JSON. Если вам чего-то не хватает — просто добавьте нужные проверки в скрипт сканирования.
Теперь, после того, как мы выявили проблемные места, вам пригодится сервис по генерации безопасных настроек от Mozilla.
TODO
В следующих релизах мы планируем добавить:
- Авторизацию
- Функционал проверки настроек HTTP-Заголовков
- Удобный интерфейс для поиска по любым параметрам веб-сервера
- Посылка почтовых уведомлений для интеграции с Remedy
В случае если вас заинтересовал проект — пишите, будем рады вашим коммитам и предложениям по улучшению.
Безопасного вам веба и помните, только тот защищен, кто видит свои уязвимости со стороны!
Автор: dordyan
