Pull to refresh

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

Reading time 4 min
Views 5.6K
image


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


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


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


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

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


image

Кто виноват ?


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


» Qualis SSL Labs
» Comodo SSL Analyzer
» Mozilla SSL configuration Generator


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


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

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


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


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

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

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

Что делать?


В своё время, мы 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

Что получилось


Через несколько минут вы получите результаты первых сканирований. Реализованная на текущий момент дашборда достаточно информативна, чтобы на её основе строить процессы мониторинга и контроля состоянии инфраструктуры.


image

Вы можете отсортировать дашборд по оценке, чтобы увидеть на какие сервера нужно обратить внимание в первую очередь.


image


И добавлять свои визуализации, например по уязвимости к POODLE, Heartbleed или по любым другим данным, которые предоставляет скрипт. Чтобы посмотреть что еще есть в базе, откройте вкладку Discover и разверните JSON. Если вам чего-то не хватает — просто добавьте нужные проверки в скрипт сканирования.


Теперь, после того, как мы выявили проблемные места, вам пригодится сервис по генерации безопасных настроек от Mozilla.


TODO


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


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

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


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

Tags:
Hubs:
+17
Comments 1
Comments Comments 1

Articles