Blogerator.org

× Версия для печати

Разговор о контроле и безопасности в MySQL уместно начать с рассмотрения установки самого сервера баз данных. Я не случайно начал эту статью с примеров того, как два разных пользователя могут подчас неявно объединять свои привилегии в результате выполнения стандартного запроса GRANT .

Давайте подробно рассмотрим, что это значит на практике, как дефолтная установка MySQL по-умолчанию порождает подобные бреши, а также как следует эти риски устранять с помощью специализированных скриптов-аудиторов.

Безопасная установка

Что это значит на только что установленном MySQL? Всем анонимным, также как и всем новым пользователям этого сервера по-умолчанию открыт полный доступ к базе test с полномочиями ALL PRIVILEGES , а также ко всем базам на сервере (уже существующим или созданным в будущем) начинающимся с префикса 'test%' . Это является следствием установок по-умолчанию, а вышеописанное поведение GRANT в некоторых случаях позволяет злоумышленникам выполнять потенциально опасные манипуляции на таком сервере.

Сами разработчики MySQL рекомендуют для устранения подобных «врожденных» уязвимостей использовать свой же скрипт mysql_secure_installation любезно поставляемый вместе с дистрибутивом (поскольку в портах для FreeBSD его нет, предлагаю другой вариант для этого случая), который устанавливает действительно минимально-безопасные установки по-умолчанию для MySQL.

Этот скрипт желательно применять после каждой новой установки MySQL: он работает в консольно-интерактивном режиме, последовательно задавая оператору вопросы, запускается без аргументов:

$ sudo mysql_secure_installation

В пошаговом режиме он предложит скорректировать следующие моменты дефолтной инсталляции:

• установить пароли на все обнаруженные root аккаунты (по-умолчанию root в MySQL идет без пароля).
• запретить доступ к аккаунту root из-за пределов localhost .
• удалить все тестовые аккаунты, которые автоматически создаются при инсталляции MySQL, в силу чего любой пользователь может подключиться к БД.
• удалить базу test , а также права по-умолчанию позволяющие любому получать доступ с правами root ко всем базам данных начинающихся в своем имени на «test_ ».

На применении этого штатного скрипта я не буду останавливаться, чтобы подробней рассмотреть вариант расширенного тестирования системы, — скрипт oak-security-audit, из состава популярного пакета Openark Kit. В частности, вот лишь некоторые проводимые им проверки:

• Поиск пользователей баз данных с пустыми (или отключенными) паролями.
• Детектирование аккаунтов с одинаковым паролем.
• Удобный вывод данных об обладателях полного набора привилегий, с правами записи к таблицам MySQL Schema .
• Общее тестирование установок, например вывод значений sql_mode , использование old_passwords и т.д.
• Создание списка учетных записей содержащих символы подстановок (wildcards)
• Поиск «слабых паролей».

Главное отличие скрипта mysql_secure_installation от oak-security-audit в том, что первый скрипт из этого сравнения обеспечивает более простой набор проверок и идеально подходит для разовой коррекции общих настроек безопасности для новых инсталляций MySQL, поэтому рекомендуется его однократный запуск сразу после установки СУБД. В отличие от него, oak-security-audit предназначен скорее для регулярного использования в целях расширенного мониторинга текущих настроек сервера и его сопровождения на протяжении всего жизненного цикла.

Приведу варианты запуска oak-security-audit :

// запуск скрипта в режиме наивысшего уровня контроля системы
oak-security-audit --audit-level=strict
// запуск скрипта с явным указанием конфигурационного файла сервера БД
oak-security-audit --defaults-file=/myuser/.my-oak.cnf -l normal

Читать этот материал дальше. Оглавление и начало этой серии статей — здесь.

Игорь Савчук ©  Системный Администратор, 2012