Plug-and-Get-Security I, безопасность TLS в роще доменов

Безопасная настройка TLS всегда был головной болью. Как для владельцев небольших ресурсов, так и для компаний, размер инфраструктуры которых может достигать нескольких сотен или даже тысяч доменов. Проблемы с TLSSSL появляются постоянно — уязвимости в самих протоколах, крипто-алгоритмах или их имплементациях. От всем известных Poodle и HeartBleed, до достаточно экзотичных и свежих (CVE-2016-2107) проблем с AES-NI ^[1].

А к чему приводят проблемы с TLS?
К краже учетных записей пользователей, администраторов, внедрению в трафик вредоносного контента, рекламы или, как это было с HeartBleed, даже к прямому доступу к памяти сервера.

Давайте взглянем на картину в целом.
На июль 2016 по данным проекта SSL Pulse ^[2], который анализирует настройки Alexa Top 200k доменов:

• 40% из них имеют ошибки в конфигурации или используют недостаточно стойкие наборы алгоритмов шифрования
• 25% имеют серьезные проблемы приводящие к реальной реализации атак на пользователей ресурсов или на сами ресурсы

А значит, у всех нас проблемы!

Кто виноват ?

Нам кажется, что это во многом это является следствием того, что TLSSSL это достаточно сложная штука и разобраться в том, как готовить её безопасно — совсем не просто. К счастью, в нашем распоряжении имеются несколько сервисов, здорово облегчающих эту задачу:

» Qualis SSL Labs ^[3]
» Comodo SSL Analyzer ^[4]
» Mozilla SSL configuration Generator ^[5]

А что конкретно мы хотим узнать, когда ставим себе задачу проверки настроек TLS:

• Есть ли уязвимости в используемой нами версии библиотеки ?
• Достаточна ли надежность используемых нами алгоритмов и длин ключей ?
• Поддерживаем ли мы механизмы ускоряющие работу TLS, и делающие наш сайт быстрее для пользователей ?
• Когда подойдет время устаревания сертификатов для наших доменов ?

А также другие важные вещи — наличие PFS, Secure Renegotiation, HSTS, Key Pinning, Session Resumption и пр. Перечисленных терминов хватит на пяток отдельных статей, так что не будем углубляться в дебри.

Давайте посмотрим как это выглядит на примере Qualys SSL Labs: сервис отличный и выдает практически всю требуемую нам информацию:

Общую оценку рейтингом от A до T, в зависимости от кривизны конфигурации и количества уязвимостей

Настройку поддержки протоколов и наборов криптоалгоритмов веб-сервером

Детали конфигурации, включая информацию о подверженности уязвимостям и поддержке различных механизмов TLSSSL

Что делать?

В своё время, мы c Crait ^[6] задумались над мониторингом SSL/TLS у нас. Надо сказать, что несмотря на то, что публичные сервисы по проверке SSL уже существовали, мы не смогли извлечь из этого пользы, ведь размер нашей инфраструктуры был очень большим. А это разнесенные по нескольким ДЦ в разных городах, управляемые разными системами деплоя конфигов, не связанные между собой сервера, что делало ручной анализ или какой-либо персонифицированный подход невозможным.

Нам нужен был инструмент, который позволит удобно собрать в одном месте информацию о всех наблюдаемых доменах. Выделить проблемы настройки и наличие уязвимостей, отсортировать сервера по интересующим нас критериям, построить удобную инфографику и обеспечивать актуальность информации. Вы, наверное, уже догадались, что речь идет об Elastic + Kibana. Давайте приступим.

Создание решения

Для начала нам нужен функционал который позволит собирать информацию о доменах. У Qualys SSL Labs есть API и консольный клиент для него ^[7]. К сожалению, он работает медленно, а для нас время обхода серверов было критично + клиент имеет определенные баги, вроде умения уходить в бесконечный сон, в случае, если одновременно посылается слишком много запросов к API.

Мы c вами ведь модные ребята? Модные, поэтому будем делать не просто враппер для cli, а микросервис! Вернее несколько. Почему именно так — будет понятно дальше. Большое спасибо за Михаилу Аксенову Crait ^[6] за написание и упаковку.

Был написан скрипт реализующий многопоточные запросы к ssllabs с помощью их cli, умеющий по итогам выполнения запроса собрать данные в JSON, отправить в Elastic, писать логи и обходить имеющиеся проблемы api. Код доступен на github ^[8], будем рады любому вкладу в проект!

Что нам еще нужно? Поднять 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 ^[5].

TODO

В следующих релизах мы планируем добавить:

• Авторизацию
• Функционал проверки настроек HTTP-Заголовков
• Удобный интерфейс для поиска по любым параметрам веб-сервера
• Посылка почтовых уведомлений для интеграции с Remedy

В случае если вас заинтересовал проект ^[9] — пишите, будем рады вашим коммитам и предложениям по улучшению.

Безопасного вам веба и помните, только тот защищен, кто видит свои уязвимости со стороны!

Автор: dordyan

Источник ^[10]