Наверняка все знают, что 8 апреля 2014 Сотрудники The OpenSSL Project выпустили бюллетень безопасности, в котором сообщается о критической уязвимости CVE-2014-0160 в популярной криптографической библиотеке OpenSSL.
Подробнее об этой уязвимости уже писали на хабре, а тут мы рассмотрим как обезопасить свой Drupal сайт.
Проверить подвержен ли ваш сайт уязвимости можно с помощью данного сервиса — http://filippo.io/Heartbleed/ (либо по вкусу — http://possible.lv/tools/hb/ или http://www.ssllabs.com/ssltest/).
Т.к. уязвимость касается SSL, то проверять необходимо только HTTPS хосты.
Если вам не повезло и уязвимость есть, то в первую очередь необходимо обновить библиотеку OpenSSL, либо обратиться в поддержку в случае арендуемого хостинга.
Далее рассмотрим пункты, которые я бы рекомендовал выполнить всем, независимо от предыдущего теста, так как к моменту вашей проверки, уязвимость уже могла быть закрыта, а узнать была ли она эксплуатирована нельзя.
Необходимо сменить SSL сертификаты на основе нового закрытого ключа и отозвать старые сертификаты.
Эти пункты довольно таки специфичные. И зависят от того, где вы покупали сертификаты.
Если вы используете SSO-аунтентификацию, то вам необходимо заменить свой приватный ключ. Например в случаем с модулем Bakery, замену ключа можно произвести на странице настроек модуля.
Для этого есть три способа:
Тут можно посоветовать следующее:
На этом вроде бы всё.
Подробнее об этой уязвимости уже писали на хабре, а тут мы рассмотрим как обезопасить свой Drupal сайт.
Проверить подвержен ли ваш сайт уязвимости можно с помощью данного сервиса — http://filippo.io/Heartbleed/ (либо по вкусу — http://possible.lv/tools/hb/ или http://www.ssllabs.com/ssltest/).
Т.к. уязвимость касается SSL, то проверять необходимо только HTTPS хосты.
Если вам не повезло и уязвимость есть, то в первую очередь необходимо обновить библиотеку OpenSSL, либо обратиться в поддержку в случае арендуемого хостинга.
Далее рассмотрим пункты, которые я бы рекомендовал выполнить всем, независимо от предыдущего теста, так как к моменту вашей проверки, уязвимость уже могла быть закрыта, а узнать была ли она эксплуатирована нельзя.
Сменить SSL сертификаты
Необходимо сменить SSL сертификаты на основе нового закрытого ключа и отозвать старые сертификаты.
Эти пункты довольно таки специфичные. И зависят от того, где вы покупали сертификаты.
Заменить значения приватных переменных
- Обновление drupal_private_key
с помощью hook_update()
function your_module_update_X() { variable_set('drupal_private_key', drupal_random_key()); }
либо drush-командой
drush eval “variable_set('drupal_private_key', drupal_random_key());”
- Обновление drupal_hash_salt
с помощью hook_update()
function your_module_update_X() { variable_set('drupal_hash_salt', drupal_hash_base64(drupal_random_bytes(55))); }
либо drush-командой
drush eval “variable_set('drupal_hash_salt', drupal_hash_base64(drupal_random_bytes(55)));”
Заменить закрытый ключ SSО-аунтентификации
Если вы используете SSO-аунтентификацию, то вам необходимо заменить свой приватный ключ. Например в случаем с модулем Bakery, замену ключа можно произвести на странице настроек модуля.
Удалить активные сессии
Для этого есть три способа:
- Модуль Session expire
- sql-запрос в терминале БД или phpmyadmin:
TRUNCATE TABLE sessions - drush команда:
drush sqlq 'TRUNCATE TABLE sessions'
Сбросить пароли пользователям с широкими правами доступа (а лучше всем пользователям)
Тут можно посоветовать следующее:
- уведомить пользователей о необходимости смены пароля, и надеяться на их сознательность
- насильно сменить пароли пользователям, с соответствующим уведомлением по почте. Для этого может помочь модуль Mass Password Reset
- если предыдущий вариант по вашему мнению слишком испугает пользователей, можно воспользоваться модулем Password policy. С его помощью можно сделать все пароли “просроченными”, а это значит при следующей авторизации пароль будет необходимо сменить. Вообще этот модуль рекомендую использовать всегда. Он входит в список модулей рекомендованных Аквоей для повышения безопасности сайта.
На этом вроде бы всё.