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

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


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

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

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

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

Например, здесь вы можете выдать через 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 даже не знали контакты друг друга, при этом администрируя одни и те же ресурсы

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

Игорь Савчук ©  Системный Администратор, 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-пароль позволяет вам комментировать и редактировать данные в вашем персональном аккаунте, такие как адрес сайта, ник и т.п. (Письмо с активацией придет в ящик, указанный при регистрации)

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


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