Просмотров: 3652

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


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

MySQL ЬнЫЙД ,tpjgfcyjcnm Безопасность security защита рецепты решения укрепление Securich Openark Kit хакеры взлом роли SQL база данных СУБД мускул запрос инекция sql injection блокировка пользователи

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

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

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

Попробуем, учтя эту человеческую слабость, закончить статью приглашением в ситуацию «контролируемого расставания с иллюзиями», воспользовавшись для этого (строго в образовательных целях) известным хакерским скриптом для активного исследования БД 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).
  • Учитывать «человеческий фактор» или говоря иначе — проводить жесткую организационную политику среди обслуживающего персонала.

    На этом у меня всё, но ежели кто-то потерялся в этом обилии информации, то общее оглавление и начало всей этой серии статей можно найти вот здесь.

    Игорь Савчук ©  Системный Администратор, 2012
    twitter.com facebook.com vkontakte.ru odnoklassniki.ru mail.ru ya.ru pikabu.ru blogger.com liveinternet.ru livejournal.ru google.com bobrdobr.ru yandex.ru del.icio.us

    Подписка на обновления блога → через RSS, на e-mail, через Twitter
    Теги: , , , , ,
    Эта запись опубликована: Понедельник, 28 мая 2012 в рубрике Unix'овое.

    Оставьте комментарий!

    Не регистрировать/аноним

    Используйте нормальные имена. Ваш комментарий будет опубликован после проверки.

    Зарегистрировать/комментатор

    Для регистрации укажите свой действующий email и пароль. Связка email-пароль позволяет вам комментировать и редактировать данные в вашем персональном аккаунте, такие как адрес сайта, ник и т.п. (Письмо с активацией придет в ящик, указанный при регистрации)

    (обязательно)

    
    ⇑ Наверх
    ⇓ Вниз