Так уж повелось, что свои статьи мною принято завершать неким лаконичным выводом, емко подводя практическую черту под всеми теоретическими построениями. Эта статья не станет исключением из этого золотого правила, но сегодня этот вывод будет сформулирован каждым читателем самостоятельно в качестве некоего домашнего задания, что потребует некоторых минимальных усилий, но зато позволит увидеть всю описанную выше проблематику безопасности 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.
chroot
, также при множестве соседствующих экземпляров подходит вариант MySQL Sandbox.UID/GID
, которые не используются никаким другим системным процессом.skip-networking
), делая внешние подключения из сети невозможными. Как альтернатива — ограничить сетевой доступ только с доверенных IP-адресов или подсетей.LOAD DATA LOCAL
, лишить прав PROCESS, SUPER, FILE
и так далее).На этом у меня всё, но ежели кто-то потерялся в этом обилии информации, то общее оглавление и начало всей этой серии статей можно найти вот здесь.