Этот пост был изначально написан Эрни Сухрада
Если вы следили за этим блогом (мой коллега Дэвид Басби писал о нем вчера ) или за любыми новостями в области технологий за последние несколько дней, вы, вероятно, видели упоминание об уязвимости «Heartbleed» в некоторых версиях OpenSSL. библиотека.
Так что же такое «Heartbleed», правда?
Короче говоря, Heartbleed — это проблема утечки информации. Злоумышленник может воспользоваться этой ошибкой, чтобы извлечь содержимое памяти сервера без необходимости локального доступа. По словам исследователей, которые обнаружили это, это можно сделать, не оставляя никаких следов компромисса в системе. Другими словами, если вы уязвимы, они могут украсть ваши ключи, и вы даже не заметите, что они пропали без вести. Я использую слово «ключи» буквально здесь; Имея возможность доступа к содержимому памяти затронутой службы, злоумышленник может, среди прочего, получить частные ключи шифрования для служб на основе SSL / TLS, что означает, что злоумышленник сможет расшифровать сообщения, выдать себя за другого пользователи (см. здесь, например, для атаки захвата сеансана основе этой ошибки) и обычно получают доступ к данным, которые в противном случае считаются безопасными. Это большое дело. Не часто у ошибок есть свои собственные веб-сайты и доменные имена, но этот: http://www.heartbleed.com
Почему это так важно?
Во-первых, потому что он, по-видимому, существует по крайней мере с 2012 года. Во-вторых, потому что шифрование SSL широко распространено в Интернете. И третье, потому что нет способа узнать, были ли ваши ключи скомпрометированы. Лучшее обнаружение, которое в настоящее время существует для этого, — это некоторые правила Snort, но если вы не используете Snort или какой-либо другой IDS, то вы в основном в неведении.
На какие виды услуг это влияет?
Любое программное обеспечение, которое использует функции SSL / TLS уязвимой версии OpenSSL. Это означает Apache, NGINX, Percona Server, MariaDB, коммерческую версию MySQL 5.6.6+, Dovecot, Postfix, программное обеспечение SSL / TLS VPN (например, OpenVPN), клиенты для обмена мгновенными сообщениями и многое другое. Кроме того, пакеты программного обеспечения, которые связывают собственную уязвимую версию SSL, а не полагаются на версию системы, которая может быть исправлена. Другими словами, вероятно, легче объяснить, что не затронуто.
На что НЕ повлияло?
SSH не использует SSL / TLS, так что все в порядке. Если вы загрузили двоичную установку сообщества MySQL из Oracle, у вас тоже все в порядке, потому что сборки сообщества используют yaSSL, который, как известно, не подвержен этой ошибке. Очевидно, что любая служба, которая не использует SSL / TLS, также не будет уязвимой, так как пути существенного кода не будут выполняться. Так, например, если вы не используете SSL для ваших подключений MySQL, то эта ошибка не повлияет на ваш сервер базы данных, хотя, вероятно, все же повлияет на вас другими способами (например, вашими веб-серверами).
А как насчет облачных сервисов Amazon?
Согласно бюллетеню по безопасности Amazon по этому вопросу, все уязвимые сервисы были исправлены, но они по-прежнему рекомендуют вам повернуть сертификаты SSL.
Нужно ли обновлять Percona Server, MySQL, NGINX, Apache или другое серверное программное обеспечение?
Нет, если вы не создали ни одного из них и не статически связали их с уязвимой версией OpenSSL. Это не распространено. 99% затронутых пользователей могут решить эту проблему, обновив свои библиотеки OpenSSL и зациклив свои ключи / сертификаты.
А как насчет инструментов уровня клиента, таких как Percona Toolkit или XtraBackup?
Опять нет. Клиентские стороны Percona Toolkit, Percona XtraBackup и Percona Cloud Tools (PCT) не подвержены влиянию. Более того, сайт РСТ уже был исправлен. Зашифрованные резервные копии все еще безопасны.
Есть несколько противоречивых сообщений о том, сколько именно утечки информации позволяет эта ошибка. В чем дело?
В некоторых новостных статьях и блогах утверждается, что с этой ошибкой можно получить доступ к любому фрагменту памяти сервера. Другие заявили, что раскрытие ограничено пространством памяти, принадлежащим процессам, использующим уязвимую версию OpenSSL. Насколько нам известно, и, как сообщается в базе данных CERT об уязвимостях , влияние ошибки является последним; То есть злоумышленник НЕ может использовать этот эксплойт для извлечения произвольных битов памяти вашего сервера, только битов памяти из ваших уязвимых сервисов. Тем не менее, ваши уязвимые сервисы могут по-прежнему пропускать информацию, которую злоумышленники могут использовать другими способами.
Как я узнаю, что на меня это повлияло?
Вы можете проверить свой веб-сервер по адресу http://filippo.io/Heartbleed/ — введите URL своего сайта и посмотрите, что на нем написано. Если у вас установлен Go, вы также можете получить инструмент командной строки от Github и протестировать его на собственной рабочей станции. Также есть реализация Python. Вы также можете проверить версию OpenSSL, установленную на ваших серверах. Если вы используете OpenSSL 1.0.1 — 1.0.1f или 1.0.2-beta, вы уязвимы. (Примечание: здесь некоторые дистрибутивы, такие как RHEL / CentOS, исправили проблему, фактически не обновляя номер версии OpenSSL; в системах на основе RPM вы можете просмотреть список изменений, чтобы увидеть, исправлен ли он, например:
rpm -q --changelog openssl | head -2 * Mon Apr 07 2014 Tomáš Mráz <tmraz@redhat.com> 1.0.1e-16.7 - fix CVE-2014-0160 - information disclosure in TLS heartbeat extension
Также обратите внимание, что версии OpenSSL до 1.0.1 не известны как уязвимые. Если вы все еще не уверены, мы будем рады помочь вам определить масштабы проблемы в вашей среде и предпринять необходимые корректирующие действия. Просто позвоните нам.
Как я могу узнать, был ли я скомпрометирован?
Если вы уже были скомпрометированы, вы не будете. Однако если вы используете Snort в качестве IDS, вы можете использовать некоторые правила, разработанные Fox-IT, для обнаружения и отсрочки новых атак; другие поставщики IDS / IPS могут иметь аналогичные доступные обновления правил. Однако без какой-либо IDS атаки могут и останутся незамеченными.
Есть ли какие-либо подвиги для этого в настоящее время там?
В настоящее время, да, есть некоторые доказательства концепции, распространяющиеся вокруг, хотя до этой недели это было неопределенным. Но учитывая, что это, вероятно, ошибка 2-летней давности, я был бы весьма удивлен, если бы кто-то где-то (вы пришли на мою речь в Percona Live на прошлой неделе , не так ли? Помните, что я сказал о предположении, что вы уже в собственности?) не было прочного, жизнеспособного подвига.
Итак, что мне делать?
Ubuntu, RedHat / CentOS, Amazon и Fedora уже выпустили исправленные версии библиотеки OpenSSL. Обнови сейчас. Сделай это сейчас, как сейчас. Если вы скомпилировали свою собственную версию OpenSSL из исходного кода, обновитесь до 1.0.1g или пересоберите существующий исходный код с флагом -DOPENSSL_NO_HEARTBEATS.
Как только это будет сделано, остановите все службы, использующие сертификаты, сгенерируйте закрытые ключи для любых служб, которые используют SSL (Apache, MySQL и т. Д.), А затем получите новый сертификат SSL от любого центра сертификации, который вы используете. После того, как новые сертификаты установлены, перезапустите сервисы. Вы также можете, конечно, выполнить регенерацию закрытого ключа и циклическую обработку сертификатов на отдельном компьютере, и отключить службу достаточно долго, чтобы установить новые ключи и сертификаты. Да, вам нужно будет перезапустить MySQL. Или апач. Или что угодно. Полный останов, полный старт, нет SIGHUP (или эквивалент).
К сожалению, это еще не все. Принимая во внимание природу этой ошибки, вы также должны изменить / сбросить любые пароли пользователей и / или сеансы пользователей, которые были в силе, до установки исправлений в вашей системе и утилизации ключей. См., Например, эксплойт с захватом сессии, упомянутый выше. Также обратите внимание, что службы Google до исправления ошибки были уязвимы для этой проблемы, что означает, что вполне возможно, что ваш логин Gmail (или любой другой логин, связанный с Google) мог быть скомпрометирован.
Могу ли я сойти с рук, просто обновив OpenSSL?
NO. Как минимум, вам нужно будет перезапустить свои службы, но для того, чтобы действительно убедиться, что вы устранили проблему, вам также нужно циклически переключать свои ключи и сертификаты (и, если возможно, отзывать старые). Это трудоемкая часть, но, поскольку у вас нет возможности узнать, кто-то ранее скомпрометировал ваши закрытые ключи (и вы можете поспорить, что теперь, когда ошибка общедоступна, будет много потенциальных злоумышленников. там ищут серверы для злоупотреблений), единственная безопасная вещь, которую нужно сделать, это зациклить их. Вы бы не оставили свои замки без изменений после того, как были ограблены, не так ли?
Также обратите внимание, что после обновления OpenSSL вы можете получить быстрый список служб, которые необходимо перезапустить, выполнив следующее:
sudo lsof | grep ssl | grep DEL
Где я могу получить помощь и / или дополнительную информацию?
В дополнение к различным ссылкам, уже упомянутым, вы можете прочитать о гайках и болтах этой ошибки , или различных новостных статьях, таких как эта или эта. Сейчас существует множество статей, большинство из которых характеризуют это как серьезную проблему. Это. Проверьте свою уязвимость, обновите OpenSSL и поверните свои личные ключи и сертификаты, а затем измените свои пароли.