Мы подготовили перевод статьи Райана Сирса об обработке логов Google’s Certificate Transparency, состоящей из двух частей. В первой части дается общее представление о структуре логов и приводится пример кода на Python для парсинга записей из этих логов. Вторая часть посвящена получению всех сертификатов из доступных логов и настройке системы Google BigQuery для хранения и организации поиска по полученным данным. С момента написания оригинала прошло уже три года и с тех пор количество доступных логов и, соответственно, записей в них возросло многократно. Тем более важно правильно подойти к обработке логов, если целью является максимизация количества получаемых данных. В процессе разработки нашего первого проекта - phisfinder, я потратил много времени размышляя об анатомии фишинговых атак и источниках данных, которые позволяли бы идентифицировать следы, указывающие на предстоящие фишинговые кампаний еще до того, как они смогут нанести какой-либо реальный ущерб.  Одним из источников, которые мы интегрировали (и определённо одним из лучших), стал Certificate Transparency Log (CTL) - проект, начатый Беном Лори и Адамом Ленгли в Google. По сути CTL - это лог, содержащий неизменяемый список сертификатов, выпущенных CA, который хранится в дереве Меркла, что позволяет при необходимости криптографически проверить каждый сертификат.  Чтобы понять, с какими объемами данных придется иметь дело, давайте посмотрим, сколько записей содержится в каждом логе из списка с сайта CTL:  На выходе получаем:  285,037,607 на момент написания статьи. Это не такой большой объем данных, но все равно придется приложить определенные усилия, чтобы эффективно организовать хранение и поиск по сертификатам. Подробнее об этом во второй части.  Стоит отметить, что API выдает количество записей в логе, значительную часть которых составляют PreCerts (о них далее) и не представляют особого интереса. Также важно учитывать, что сертификаты могут дублироваться между разными логами, к примеру, данный сертификат присутствует одновременно в 6 различных логах, поддерживаемых Chrome. Таким образом, реальное число сертификатов значительно меньше, чем суммарное число записей в логах. Тем не менее, на момент написания перевода, учитывая только логи, удовлетворяющие политике Google и включенные в Chrome, в списке присутствует 46 логов, содержащие в сумме 6,861,473,804 записей, что уже потребует значительных ресурсов для полной обработки. Получение записей из CTL осуществляется по HTTP, что позволит нам легко получать данные с помощью современных библиотек. К сожалению, сами данные в записях представляют собой запутанные бинарные структуры, что несколько усложняет процесс парсинга. Пример записи в логе:  Каждая запись содержит поля leaf_input и extra_data в формате base64. Обращаясь к RFC6962 видим, что leaf_input - закодированная структура MerkleTreeLeaf, а extra_data - PrecertChainEntry.  Мне потребовалось довольно много времени, чтобы разобраться, что вообще такое PreCert (можете попробовать сами, почитайте RFC, и, по всей видимости, я такой не один. Сохраню вам кучу времени на раздумья и поиски в гугле и сформулирую назначение PreCerts следующим образом: PreCerts это отдельный тип сертификата, выпускаемого CA до того, как тот выпустит “настоящий” сертификат. Фактически, это копия исходного сертификата, но содержащая специальное расширение x509 v3, называемое poison и отмеченное как критическое. Таким образом, сертификат не будет валидирован как платформами, распознающими это расширение, и знающими что это PreCert, так и платформами, которые это расширение не распознают. Мой опыт в ИБ говорит о том, что такая мера не сильно эффективна, хотя бы потому, что баги при парсинге x509/ASN.1 встречаются довольно часто и отдельные реализации могут быть уязвимы к различным махинациям, которые в конечном счете позволят валидировать PreCert. Я понимаю, зачем это было сделано, но складывается ощущение, что полностью убрать PreCerts и оставлять в CTL только сертификаты, действительно выпущенные CA, было бы намного разумнее.  Как для человека, занимающегося реверс-инжинирингом и время от времени участвующего в разных CTF, задача парсинга бинарных структур для меня не нова. Большинство людей в таких случаях обращаются к модулю struct, но много лет назад, во время работы на Филлипа Мартина, он познакомил меня с отличной библиотекой Construct, которая заметно упрощает парсинг подобных структур. Ниже приведены структуры, которые я использовал для парсинга, а также пример их использования для обработки записей:  Получаем массив X509 сертификатов из цепочки с сертификатом из leaf_input в качестве первого элемента Как можете заметить, Construct позволяет довольно легко определять бинарные структуры на Python. Теперь, понимая, что такое CTL и как парсить отдельные записи, можем переходить ко второй части - получению и сохранению всех записей из логов с возможностью последующего поиска по сертификатам. Сбор сертификатов В соответствии с RFC, для получения записей из логов используется эндпоинт get-entries. К сожалению, задача осложняется ограничением на максимальное количество записей, которое можно получить в одном запросе (контролируется параметрами start и end), и большинство логов позволяют получить лишь 64 записи за раз. Однако CTL от Google, составляющие большинство всех логов, используют максимальный размер запроса в 1024 записи. На момент написания перевода большинство логов Google (Argon, Xenon, Aviator, Icarus, Pilot, Rocketeer, Skydiver) предоставляют лишь по 32 записи для каждого запроса, но для ускорения получения записей можно одновременно отправлять несколько запросов на один и тот же лог, насколько позволяет пропускная способность, но работает такой подход не для всех логов. Отдельные логи позволяют получать по 1024 и более записей за раз, но большинство CTL, помимо Google, выдает по 256 записей за один запрос.  Так как задача одновременно IO-bound (получение записей по http) и CPU-bound (парсинг сертификатов), для эффективной обработки необходимо будет подключить как асинхронность, так и многопроцессность.  Так как не было никаких инструментов, которые позволили бы легко и безболезненно получить и распарсить все CTL (помимо не особо примечательной утилиты от Google, было решено потратить немного времени и написать свой инструмент, который соответствовал бы всем нашим потребностям. Результатом стал Axeman, который использует asyncio и замечательную библиотеку aioprocessing для загрузки, парсинга и сохранения сертификатов в несколько CSV файлов, ограничиваясь при этом только скоростью интернет-соединения. После получения инстанса (_прим. перев._ так в Google Cloud называются VM) c 16 ядрами, 32Гб памяти и SSD на 750Гб (спасибо Google за бесплатные 300$ на счете для новых аккаунтов!), я запустил Axeman, который загрузил все сертификаты меньше чем за сутки и сохранил результаты в /tmp/certificates/$CTL_DOMAIN/ На начальном этапе для осуществления хранения и поиска по данным был выбран Postgres, но, хотя я и не сомневаюсь, что с правильной схемой Postgres легко бы справился с 250 миллионами записей (в отличии от моей первой попытки, в которой на один запрос уходило примерно 20 минут!), я начал искать решения, которые:  позволяют дешево хранить большой объем данных обеспечивают быстрый поиск позволяют легко обновлять данные Вариантов было несколько, но с точки зрения стоимости, почти все рассмотренные варианты (AWS RDS, Heroku Postgres, Google Cloud SQL) были весьма затратны. К счастью, так как наши данные в принципе никогда не изменяются, у нас появляется дополнительная гибкость в выборе платформы для размещения данных. В целом, это как раз тот тип поиска по данным, который прекрасно ложится на модель map/reduce с использованием, к примеру, Spark или Hadoop Pig. Просматривая предложения различных провайдеров в категории “big data” (хотя в нашей задаче данных явно мало для включения в эту категорию), я наткнулся на Google BigQuery, который удовлетворяет всем обозначенным параметрам. Загрузка данных в BigQuery осуществляется довольно легко, благодаря предоставляемой Google утилите gsutil. Создаем новый бакет для наших сертификатов: Когда бакет готов, используем gsutil для транспортировки всех сертификатов в хранилище Google (а затем в BigQuery). После настройки аккаунта командой gsutil config, запускаем процесс загрузки: И видим следующий результат в нашем бакете: Далее создаем новый датасет в BigQuery: Теперь мы можем импортировать данные из хранилища в наш новый датасет. К сожалению, в BigQuery нет кнопки “пожалуйста, импортируй все папки рекурсивно”, так что придется импортировать каждый CTL отдельно, но занимает это не так долго. Создаем таблицу и импортируем наш первый лог (обратите особое внимание на отмеченные настройки): Так как схема нужна всякий раз при импорте очередного лога, воспользуемся опцией “Edit as Text”. Использованная схема:  Далее просто повторяем процесс для каждого лога. Убедитесь, что каждый импорт завершился успешно (ошибки обычно можно игнорировать, просто убедитесь, что вы задали адекватное значения для максимального количества ошибок). В итоге должен получиться примерно такой датасет:  Настало время пожинать плоды наших трудов и опробовать систему на различных запросах. В последнее время часто говорят о доменах, использующих punycode и связанных с ними омоглифных атаках. Попробуем следующий запрос:  И всего через 15 секунд получаем результат со всеми punycode доменами из всех известных CTL! Рассмотрим другой пример. Попробуем получить все сертификаты доменов Coinbase, записанные в Certificate Transparency:  Всего через две секунды получаем все интересующие нас результаты: Возможность легко проводить подобный анализ на таком обширном датасете - сильный инструмент для идентификации различных трендов, которые невозможно было бы обнаружить каким-либо другим способом. Проводя исследования, я обнаружил нечто странное. Домен flowers-to-the-world.com постоянно возникал в различных логах. Практически каждый лог имел огромное число сертификатов, содержащих этот домен: Whois позволяет определить, что этот домен принадлежит Google, так что мне интересно, не является ли это частью какой-то тестовой рутины. Если вы инженер Google, который может разузнать что-то у товарищей, занимающихся Certificate Transparency, было бы очень интересно услышать об этом. Ответ инженера Google в комментариях под оригинальным постом Привет, Райан. Пишет Пол Хэдфилд из команды Certificate Transparency. flowers-to-the-world.com действительно принадлежит Google. Мы используем этот домен чтобы генерировать сертификаты, которые затем добавляются в каждый CTL в рамках периодической проверки логов на соответствие стандартам RFC6962. Проверка проводится с целью удостоверится, что логи работают в соответствии со стандартами и имеют приемлемый аптайм.  Наблюдаемое распределение количества раз, которое домен встретился в каждом логе, является в основном функцией от того, сколько этот лог существует, но также зависит от того, насколько быстро лог может добавить новый сертификат в свое дерево Меркла. Если проследить полную цепочку при добавлении сертификата с flower-to-the-world.com, можно увидеть, что она заканчивается в корне со следующим эмитентом: “C=GB, ST=London, O=Google UK Ltd., OU=Certificate Transparency, CN=Merge Delay Monitor Root” Надеюсь, это помогло.  Совсем скоро мы планируем выпустить собственный продукт — NetLas.io. Это своеобразный технический атлас всей сети Интернет, который будет включать не только сертификаты, но и данные по доменам и поддоменам, ответы серверов по популярным портам и много другой полезной для исследователей безопасности информации.  В России, насколько нам известно, это первый такой продукт. В США и Китае у нас есть сильные конкуренты, но мы надеемся превзойти их по некоторым параметрам. Например, актуальность данных — уже сейчас наша реализация поискового движка позволяет включать в поисковую выдачу данные, от сканов не старше минуты. На сегодняшний день Netlas.io доступен в формате "раннего доступа". Если есть желание потестировать — переходите на сайт и регистрируйтесь.