MySQL: Безопасность и аудит

Posted: 15/07/2012 in Uncategorized

MySQL: Безопасность и аудит. Оглавление

Рассмотрим методы и инструменты для повышения безопасности MySQL, а также первоочередные меры необходимые сразу после новой инсталляции этой СУБД. Обращаю ваше внимание, что это логически-самостоятельная серия-продолжение «Безопасность и аудит» из моей давней MySQL-серии «Программное окружение MySQL» (Часть 1Часть 2).

Обзорно рассмотреть узкие места в безопасности MySQL я предлагаю на примере описания возможностей двух популярных сторонних инструментов, эти задачи успешно решающих. Этим подходом мы убиваем сразу трех зайцев: не только знакомимся с проблемами MySQL и простыми, доступными методами их исправления, но и попутно сравниваем между собой особенности конкурирующих продуктов, позволяющих сделать всю «грязную работу» по наведению порядка в системе автоматически.

Речь пойдет о двух специализированных скриптах из состава сервисного пакета Openark Kit, а также о пакете существенно улучшающего уровень безопасности MySQL — Securich.

 

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

Итак, какие проблемы имеют текущие реализации MySQL?

  • Отсутствие встроенных возможностей по созданию и управлению группами пользователей или их ролями (по-крайней мере в таком виде, в котором они известны в других известных СУБД).
  • Отсутствие развитой подсистемы управления паролями:
    • Нет ограничений по размеру пароля;
    • Нет истории операций над паролями и привилегиями;
    • Нет измерения сложности и надежности задаваемого пароля;
    • Нет минимального срока жизни пароля;
  • Нет возможности клонирования настроек, создания множества однотипных учетных записей, управления и мониторинга большого числа пользовательских аккаунтов.
  • Настройки по-умолчанию небезопасны.

 

Я намеренно не упоминаю здесь о более глубоких проблемах в архитектуре MySQL: о неких уязвимых компонентах, потенциально опасных местах в SQL или ошибках в настройках отдельных версий этой СУБД — цель этой серии статей нивелировать лишь базовые неудобства и недочеты, которые перманентно имеют место в этой замечательной СУБД (при её стандартной базовой настройке и установке «из коробки»).

MySQL: Безопасность и аудит. Часть 1

Продолжаем начатый ранее разговор.

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

 

Такой загадочный GRANT

Для иллюстрирования сказанного выберем важную тему — присвоение и делегирования прав с помощью GRANT . Эта команда позволяет назначать как отдельные привилегии, так и выдавать весь спектр возможностей для администраторов БД (в таком случае можно воспользоваться мета-подстановкой ALL PRIVILEGES ).

После очень краткой теории, давайте посмотрим, как это работает:

root@mysql-5.5.17> GRANT ALL PRIVILEGES ON consumer.* TO 'super_usr'@'localhost';
root@mysql-5.5.17> SHOW GRANTS FOR 'super_usr'@'localhost';
+-----------------------------------------------------------------+
| Grants for super_usr@localhost                                  |
+-----------------------------------------------------------------+
| GRANT USAGE ON *.* TO super_usr'@'localhost'                    |
| GRANT ALL PRIVILEGES ON `consumer`.* TO 'super_usr'@'localhost' |
+-----------------------------------------------------------------+

Как видим, мы получили аккаунт с полными привилегиями.

Продолжим демонстрацию ещё одним примером присвоения прав, который вскрывает коварность этой команды:

root@mysql-5.5.17> GRANT EXECUTE, INSERT, SELECT, UPDATE ON `consumer`.* TO 'usual_usr'@'localhost';
root@mysql-5.5.17> SHOW GRANTS FOR 'usual_usr'@'localhost';
+----------------------------------------------------------------+
| Grants for usual_usr@localhost                                 |
+----------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'usual_usr'@'localhost'                  |
| GRANT ALL PRIVILEGES ON `consumer`.* TO 'usual_usr'@'localhost'|
+----------------------------------------------------------------+

Здесь мы присваиваем четко ограниченный набор привилегий другому пользователю этого же домена, но в итоге видим, что он получил сразу весь набор привилегий.

Удивлены? Если кто-то в Oracle считает это логичным, когда мы явно присваиваем одно, а неявно получаем совсем другое — я так не считаю. Перейдем к следующему примеру, связанному с перетеканием привилегий уже через оператор «WITH GRANT OPTION »:

root@mysql-5.5.17> GRANT INSERT, UPDATE ON consumer.City TO 'alaura'@'localhost';
root@mysql-5.5.17> GRANT SELECT ON consumer.City TO 
'alaura'@'localhost' WITH GRANT OPTION;
root@mysql-5.5.17> SHOW GRANTS FOR 'alaura'@'localhost';
+---------------------------------------------------------+
| Grants for alaura@localhost                             |
+---------------------------------------------------------+
| GRANT USAGE ON *.* TO 'alaura'@'localhost'              |
| GRANT SELECT,INSERT,UPDATE ON `consumer`.`City`         |
| TO 'alaura'@'localhost' WITH GRANT OPTION               |
+---------------------------------------------------------+

Синтаксис второй команды недвусмысленно говорит, что мы передаем «WITH GRANT OPTION » для привилегии SELECT , но вывод результата утверждает обратное. Думаю, администраторы MySQL вряд ли будут хоть сколько-то удивлены подобной логикой, но как я неоднократно имел возможность наблюдать, операторы других известных СУБД были явно озадачены подобным развитием событий.

В этом плане синтаксис MySQL вводит в заблуждение, хотя бы тем, что позволяет без ошибки исполнять подобные действия
 

Я привел лишь один вариант неоднозначности, хотя в MySQLтаковых имеется множество. И если администратор в этой ситуации может просто быть внимательным, то многие веб-приложения для управления этой СУБД, (например популярный phpMyAdmin), не всегда учитывают такие мелочи.

 

Положение отчасти усугубляется и тем, что в последнее время на многих западных хостинговых площадках получили широкое распространение известные «легковесные заменители» phpMyAdmin, такие как Adminerи phpMiniAdmin (которые часто используются параллельно с phpMyAdmin), логика передачи прав у них в отдельных случаях отличается от принятой в phpMyAdmin, но также не всегда идеальна и безупречна. С учетом всего выше сказанного — не всегда можно гарантировать однотипность или консистентность подходов при администрировании политик доступа в MySQL.

 

Но цель сегодняшнего обзора не в обсуждении подобных «слабых мест» и нелогичностей в MySQL — наш подход более конструктивен:

далее мы обсудим инструменты, позволяющие оперативно отслеживать и активно выявлять подобные аномалии (и их последствия), которые неизбежны в любой большой и сложной MySQL-системе 

MySQL: Безопасность и аудит. Часть 2

Разговор о контроле и безопасности в 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

 

 

Openark kit: краткая справка
Этот известный вспомогательный набор для администрирования MySQL на данный момент включает в себя 14 скриптов, функциональная тематика которых очень разнообразна: эффективная работа с лог-файлами, безопасность, исправление кодировок, репликация и т.д. Сегодня мы рассматриваем лишь два из них: oak-block-account и oak-security-audit .
 

Openark kit свободно распространяется по лицензии BSD и поддерживается Шломи Нoах (Shlomi Noach). Для использования этих скриптов требуется аккаунт суперпользователя, а также установленные Python и драйвер python-mysqldb на вашем компьютере.

 
 

MySQL: Безопасность и аудит. Часть 3

Продолжаем начатый ранее разговор.

Необходимость гибкого управления существующими аккаунтами при повседневном администрировании действительно велика, и в MySQL это ещё одно узкое место.

 

Управление аккаунтами

Например, здесь вы можете выдать через GRANT привилегию USAGE , но никогда не сможете сделать REVOKE для неё. В рамках MySQL выполнение REVOKE USAGE полностью эквивалентно выполнению команды DROP USER . Поэтому сам факт существования аккаунта в MySQL позволяет его обладателю безусловно подключаться к базе — здесь не существует встроенной функциональности аналогичной гипотетической команде:

GRANT/REVOKE login ON *.*

 

В силу этого в пакет Openark Kit включена специализированная утилита oak-block-account с удобной возможностью временного блокирования/разблокирования аккаунта пользователя, которая может применяться в следующих наиболее очевидных случаях:

  • Автоматически блокировать аккаунт в случае нескольких последовательных попыток ввода неправильных паролей (вероятность попытки подбора пароля).
  • При неоплаченном использовании БД, когда сразу удалять учетную запись было бы неправильным.
  • По запросу от пользователя и любой необходимости «временной заморозки» аккаунта, например, при поступлении жалобы на сайт пользователя.
  • Временно отключать привилегированных пользователей организации, пока они находятся в отпуске, на больничных, в декрете или курсах повышения квалификации.

При этом учетная запись со всеми настройками физически остается в базе СУБД, но для неё устанавливается новый технический пароль, а все текущие соединения сбрасываются, поэтому вновь подключиться к сервису он не сможет. Естественно, когда вопрос с пользователем решен, старый пароль будет автоматически восстановлен, с помощью этой утилиты можно получить полный список подобных «временно замороженных» аккаунтов в системе.

Вот примеры вызова oak-block-account :

// заморозить пользователя mag@samag.ru
oak-block-account --block --aсcount--defaults-file=nt-user=mag --account-host=samag.ru
// снова активировать этого пользователя
oak-block-account --release --account-user=mag --account-host=samag.ru
// временно отключить логин пользователя mag на любых хостах и сбросить все
// его активные подключения к БД
oak-block-account --block --account-user=mag --kill

 

Здесь значение основных опций --block и --release очевидно — заблокировать и разблокировать пользователя соответственно. Более подробно утилита описана в официальной документации.

 

mysql.com: работа над ошибками
Я думаю, никто не будет спорить, что учиться лучше на чужих ошибках. И будет гораздо наглядней, если в статье о безопасности MySQL рассмотреть пример самих разработчиков этой СУБД. В прошедшем 2011 году сайт mysql.comвзламывался уже трижды, в образовательных целях приведем список уязвимостей, приведших к его первому мартовскому взлому (похищено содержание баз данных, включавших информацию о всех клиентах и сотрудниках компании):
 

  • недостаточная изолированность и качество используемых веб-приложений, что привело к успешной «слепой» SQL-инъекции и многоуровневой XSS-атаке
  • устаревшее, давно не обновляемое серверное ПО, имеющее множество давно закрытых уязвимостей
  • избыточный набор привилегий у рядовых пользователей БД
  • свободный доступ к СУБД из внешних сетей с привилегией root
  • часть паролей удалось быстро восстановить методом перебора (brute force), так как для их хранения использовался DES-хэш (кстати, этот устаревший блочный шифр был разработан ещё в 1972 году прошлого века)
  • исключительная простота некоторых паролей. Например, привилегированные пользователи с логинами «sys» и «sysadm» имели пароли «phorum5» и «qa» соответственно. Один из руководителей высшего звена MySQL имел пароль «2228» (как оказалось впоследствии, эти цифры — номер пин-кода его пластиковой карты).
  • низкая оперативность и организованность обслуживающего персонала: XSS-уязвимости оставались открытыми ещё 2 месяца после их обнаружения. Некоторые администраторыmysql.com даже не знали контакты друг друга, при этом администрируя одни и те же ресурсы

 

MySQL: Безопасность и аудит. Часть 4

А что же в связи с ранее рассмотренной проблематикой предлагает второй герой нашего обзора — Securich?

 

Администрирование в стиле Securich

Не будем подробно останавливаться на его инсталляции, которая не представляет никаких сложностей и зависимостей, и чаще всего сводится к запуску единственного скрипта — securich_install.sh(подробная инструкция идет в комплекте поставки — смотрите файлы INSTALL.txt и README.txt).

Текущая версия Securich v0.6.2 распространяется свободно по лицензии GPLv2, при этом совместима только с MySQL версии 5.1.12 или выше
 

В качестве первого знакомства с новичком сначала приведем общие возможности Securich в MySQL, чтобы потом продолжить тему управления аккаунтами. В силу большого количества функционала перечислим только главные особенности этой утилиты:

  • Поддержка концепции динамических ролей для пользователей MySQL;
  • Временная блокировка и разблокировка аккаунтов;
  • Сохранение даты/времени создания и модификаций паролей всех пользователей;
  • Возможность задать возраст пароля, с автоматическим уведомлением на e-mail пользователя о необходимости сменить старый пароль и приближении срока блокировки его аккаунта;
  • При установке пароля проводится проверка по словарю (его вы можете создать сами или скачать уже готовый из общеупотребительных слов);
  • Настройка контроля сложности нового пароля (только пользователю root разрешается самостоятельно устанавливать любые пароли);
  • Мониторинг и хронология смены ролей и привилегий у пользователей;
  • Безопасная схема переименования пользователей;
  • Возможность автоматически сбрасывать все текущие сетевые подключения к СУБД при изменении привилегий/ролей пользователя;
  • Запрет и дополнительный контроль любого изменения (в обход этой утилиты) в служебной базе ‘mysql ’.

 

В целом и общем можно уверенно констатировать, что на данный момент Securich предлагает очень цельную и логичную систему по расширенному пользовательскому администрированию СУБД MySQL, нивелирующий почти все слабые стороны MySQL и заметно упрощающий его аккаунт-менеджмент.

 

Вот список команд имеющих отношение к администрированию учетных записей:

  • show_user_list() – получить список всех пользователей в системе с полными данными по ним;
  • show_reserved_usernames() – получить список всех зарезервированных (запрещенных администратором для регистрации) имен пользователей. Добавление и удаление этих имен осуществляется соответственно через командыadd_reserved_username() и remove_reserved_username() ;
  • clone_user() – клонировать уже существующие учетные записи (то есть его настройки и права будут взяты за основу при создании новой);
  • block_user() — временно заблокировать пользователя (при этом все его настройки и сам пользователь в базе сохраняются);
  • unblock_user() – разблокировать указанного пользователя (восстановление возможности подключаться и работать с БД), операция противоположна по смыслу block_user() .

А теперь пример команды блокирования пользователя на сервере через Securich:

mysql> call block_user ('savgor');
Query OK, 1 row affected (0.08 sec)

 

Со стороны клиента ’savgor ’, подключенного к серверу БД в момент его блокировки, эффект применения к нему этой команды будет выглядеть так:

mysql> show processlist;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
ERROR 1045 (28000): Access denied for user 'savgor'@'localhost' (using password: YES)
ERROR: 
Can't connect to the server
mysql>

 

Вернуть доступ к БД можно также легко и непринужденно:

mysql> call unblock_user ('savgor');

 

Как видите, Securich обладает более расширенными возможностями в сравнении с Openark Kit, — здесь можно контролировать возраст паролей и выполнять мониторинг над всеми операциями по администрированию каждого отдельного аккаунта, всегда имея возможность уточнить детали по ведущемуся журналу всех операций.

Плюсом же oak-block-account является большая мобильность и простота Perl-скрипта, узкую функциональность которого можно использовать выборочно и отдельно от всего комплекса утилитOpenark Kit, чего нельзя сказать о монолитном решении Securich, технически реализованного в виде большого и универсального набора хранимых процедур для MySQL.

 

Храним юзеров СУБД в системе управления версиями
Здесь также уместно напомнить об альтернативном подходе утилиты mk-show-grants (в ранее мною рассмотренном пакете Maatkit), позволяющей организовать централизированный репозиторий контроля версий, в качестве содержимого которого можно использовать всех пользователей на серверах MySQL, с информацией о правах их доступа и полномочиях. Упомянутая утилита позволяет автоматизировать двухстороннюю синхронизацию такого репозитория с указанными серверами баз данных, а сам репозиторий (который вы можете выбрать самостоятельно) — обеспечит авторизованный доступ администраторов БД и широкие возможности для контроля их деятельности.

 

 

MySQL: Безопасность и аудит. Часть 5

Продолжаем ранее начатое рассмотрение Securich.

Я думаю, что повседневная работа любого администратора БД очень плотно связана с настройкой и выделением прав/привилегий пользователям и системным объектам самой БД. С другой стороны — это один из самых ответственных участков работы, ошибки в котором, особенно в условиях интенсивного совместного использования сервера между множеством пользователей и в открытой сетевой среде, может приводить к его компрометации и утечке хранимых на нем данных.

 

В связи с этим, концепции групп и ролей могут значительно упростить и стандартизировать раздачу привилегий. Первоначально реализацию ролей разработчики MySQL обещали в 5-ой версии, но после её выхода, поддержку этой важной особенности в очередной раз перенесли в планы на реализацию в будущую 7-ую.

Что же делать в ситуации, когда эти возможности остро нужны уже здесь и сейчас?
 

Управление ролями через Securich

Расширенное управление аккаунтами MySQL — только один аспект возможностей Securich, сейчас мы рассмотрим его возможности по созданию ролей и контролю над правами пользователей БД, для чего сначала приведем список всех команд, ответственных за это:

  • create_update_role() — запуск этой процедуры приведет к созданию (или обновлению уже имеющейся) роли, drop_role()— удаляет роль;
  • show_privileges_in_role() — показ всех привилегий присвоенных указанной роли;
  • show_roles() — выдать список всех ролей доступных в системе;
  • show_users_with_privilege() — показ списка пользователей, имеющих любые права доступа к указанной в аргументах таблице и/или базе данных;
  • show_user_entries() — выдает список всех ролей для указанного пользователя со всеми деталями: в каких базах данных и хостах эти привилегии имеют силу на текущем сервере;
  • grant_privileges() — используется для задания привилегий для указанного пользователя, в том числе через регулярные выражения (например, для выделения диапазона таблиц, к которым получит доступ пользователь). Попытка дать права на несуществующие таблицы/БД приведет к их автоматическому созданию перед применением всех установок;
  • rename_user() — переименовывает логин пользователя сохраняя все его текущие привилегии и роли, при этом также дается возможность сменить его пароль и контактный e-mail;
  • password_check() — внутренняя проверка согласованности данных о паролях между служебными таблицами securichи mysql ;
  • mysql_reconciliation() — используется совместно с аналогичной командой grant_privileges_reverse_reconciliation () для принудительной синхронизации всех данных по привилегиям между таблицами mysql и securich (вторая команда — выполняет такую же синхронизацию, но в обратном направлении);
  • sеt_pаssword_expirable() — присвоение паролю уже существующего, указанного в аргументах пользователя статуса «ограниченный по времени действия» (или его отмена);
  • sеt_passwоrd() — изменение своего пароля пользователем (или принудительная установка root`ом). Автоматически анализируется история, и запрещаются предыдущие 5 вариантов, также сохраняет дату и время всех проводимых операций. Позволяет автоматически проверять структуру и сложность создаваемого пароля по маске значений задаваемых в таблице sec_cоnfig :
    • Проверка минимальной и/или максимальной разрешенной длины пароля;
    • Проверка пароля по словарю из слов;
    • Контроль наличия разных регистров;
    • Контроль наличия цифр в пароле;
    • Контроль наличия специальных символов;
    • Контроль совпадения или модификаций пароля, коррелирующего с именем пользователя (например, пароль получен путем написания логина задом наперед).

Показать исчерпывающие примеры использования всех упомянутых команд в короткой обзорной статье просто нереально, поэтому приведу типичный сеанс работы с использованием некоторых упомянутых выше команд, чтобы составить общее впечатление о Securich:

<code>$ mysql -u savgor -p -h 127.0.0.1 -P 3306
mysql> show databases; 
+--------------------+
| Database           |
+--------------------+
| information_schema | 
| securich           | 
+--------------------+
mysql> use securich; 
Database changed
mysql> call my_privileges('test'); 
+-----------+
| PRIVILEGE |
+-----------+
| DELETE    | 
| INSERT    | 
| SELECT    | 
| UPDATE    | 
+-----------+
mysql> call create_update_role('add','role1','insert'); 
mysql> call revoke_privileges('peter' , 'localhost' , 'test' , '' , '' , 'role1' , 'Y');
mysql> call sеt_pаssword('paul' , '10.0.0.2' , '2f791928c4ef44ddd7c', 'password123');

 

Для получения оперативной справки по Securich, прямо в консоли mysql нужно вызвать команду help , в качестве аргумента передав ей имя процедуры из арсенала Securich. Их общий список и примеры использования доступны в подробной online-документации, как дополнение в файле securich.pdf (включаемый в комплект поставки Securich) предоставляется схема отношений всех служебных таблиц комплекса.

MySQL ЬнЫЙД ,tpjgfcyjcnm Безопасность security защита рецепты решения укрепление  Openark Kit хакеры взлом роли SQL база данных СУБД мускул запрос инъекция sql injection блокировка пользователи SecurichВ заключении приведу ещё одну приятную особенность Securich — наличие собственного графического фронтенда — SAM-My. Его web-интерфейс позволяет управлять политиками MySQL, даже не вникая в особенности богатого командного арсенала Securich, что также придется по душе определенной категории администраторов БД.

 

MySQL: Безопасность и аудит. Заключение

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

 

Лучше проверь себя сам

Дело в том, что как любили высокомерно говаривать древние новаторы и государственники греки в те далекие годы, когда никаким дефолтом у них ещё и не пахло: «недостаток опыта у всякого вызывает уверенность в себе». Многие современные администраторы БД, подобно древним грекам, иногда склонны относиться к сухой теории несколько пренебрежительно, и в этом плане я полностью согласен с Бернардом Шоу:

«Наш личный опыт чаще всего обретается через боль утраченных иллюзий, но не в учебе и старательном постижении мудрости ».

Попробуем, учтя эту человеческую слабость, закончить статью приглашением в ситуацию «контролируемого расставания с иллюзиями», воспользовавшись для этого (строго в образовательных целях) известным хакерским скриптом для активного исследования БД MySQL на различные базовые уязвимости в администрировании. Упомянутый mysqlaudit написанКарлосом Пересом (Carlos Perez) для известного хакерского проектаMetasploit. Для его работы потребуется аккаунт на тестируемой БД, а также установленные Python и драйвер python-mysqldb.

Приведу пример его запуска (справку можно получить, запустив скрипт без ключей):

~: /mysqlaudit# ./mysqlaudit.py 192.168.2.77 root r00t /tmp/audit-report.txt
~: /mysqlaudit# cat /tmp/audit-report.txt | less

 

После чего вы увидите длинный и комментированный листинг найденных ошибок в настройках СУБД. Фактически, mysqlauditне делает ничего сверхъестественного — он просто пытается обнаружить и эксплуатировать те самые опасные возможности, оставляемые MySQL после установки по-умолчанию, которые заботливо закрывает симбиоз из вышеописанных выше скриптов —mysql_secure_installation и oak-security-audit, а также правильная и вдумчивая настройка прав пользователей, в чем поможет расширенная модель управления пользователями, реализованная в Securich.

 

Краткая памятка администратору MySQL
Невозможно в рамках короткой статьи осветить все меры по укреплению безопасности MySQL, поэтому изложение в ней вынужденно сконцентрировалось лишь на базовых, минимально необходимых моментах для каждой инсталляции MySQL. Тем не менее, ниже приводится краткий список дополнительных мер, которые могут усилить безопасность сервера БД: 

    • MySQL может быть запущен в chroot , также при множестве соседствующих экземпляров подходит вариант MySQL Sandbox.
    • Процесс сервера БД должен иметь уникальные UID/GID , которые не используются никаким другим системным процессом.
    • В идеале только локальный доступ к серверу должен быть разрешен, в этом случае прослушивание сервером БД сетевых портов может быть отключено (параметр skip-networking ), делая внешние подключения из сети невозможными. Как альтернатива — ограничить сетевой доступ только с доверенных IP-адресов или подсетей.
    • Аккаунты администраторов должны использовать заведомо надежные пароли, канал доступа подобных суперпользователей должен быть обязательно защищенным.
    • Разработать эффективные ограничения для локальной файловой системы, делающие невозможным для посторонних чтение или запись конфигурационных файлов, истории, а также лог-файлов относящихся к MySQL. Помните когда размещаете дополнительное ПО на сервере: прочность всей цепи не выше её самого слабого звена, поэтому при росте количества пользователей и компонентов системы — её надежность будет неизбежно понижаться.
    • Уделять повышенное внимание всем установленным веб-ориентированным системам администрирования СУБД, типа известного phpMyAdmin (например, его недавние проблемыс глобализацией переменных сделали уязвимыми колоссальное количество серверов). Заведите специальную роль для подобных систем и установите повышенный контроль над её операциями. Таким пользователям можно превентивно ограничить некоторые малоиспользуемые, но опасные возможности (отключить LOAD DATA LOCAL , лишить правPROCESS, SUPER, FILE и так далее).
    • Использовать специализированные инструменты для контроля целостности конфигурационных и других файлов MySQL, важнейших системных таблиц БД.
    • Автоматически блокировать попытки перебора паролей, также рекомендуется использовать SQL-файерволлы (например —GreenSQL).
    • Учитывать «человеческий фактор» или говоря иначе — проводить жесткую организационную политику среди обслуживающего персонала.
Взято с

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s