Какова лучшая стратегия для обнаружения вторжений в базу данных?

Это зависит от того, как вы подключаетесь к своей базе данных. Если вы используете веб-приложение, Snort (и другие NIDS) смогут обнаруживать SQL-инъекции и другие атаки, которые происходят через HTTP.

Проблема в том, что если вы используете SSL или зашифрованные соединения с вашей базой данных, ваш NIDS будет закрыт для трафика.

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

Чтобы включить журнал mysql: http://www.ossec.net/wiki/index.php/SQL_Logging

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

Для этого есть коммерческие продукты. Я думаю, что мы посмотрели на DbProtect (www.appsecinc.com), и это были основные средства для реализации, но в итоге мы этого не сделали. Я также видел Guardium (www.guardium.com). Оба утверждают, что поддерживают некоторую версию MySQL.

Фырканье все еще может быть полезным. Уловка в том, чтобы знать, откуда должен поступать трафик вашей базы данных. Если он исходит из источника, отличного от утвержденного, вы можете заблокировать его, очевидно, в MySQL. Однако вы также можете настроить оповещения в своей IDS, чтобы увидеть подобные вещи.

Что касается атаки с авторизованного IP-адреса, это немного сложная задача. Ключевой вопрос: что следует разрешить соединению, а что нет? И это восходит к правильной настройке разрешений. Если законный пользователь подключается с законного IP-адреса и нуждается в разрешениях DELETE и хочет быть злонамеренным, во время реальной модификации вы не сможете ничего с этим поделать. Было предложено провести аудит, но это повредит вашей работе. Я не уверен, что у вас есть эффективный контроль, если пользователи могут напрямую обращаться к базе данных и вносить изменения. Все платформы баз данных, не только MySQL, борются с этим. У вас есть доверенный пользователь, который делает авторизованное изменение. Есть только так много, что вы можете сделать.

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

Похоже, вы хотите какой-то аудиторский след. Говоря в общем смысле СУРБД, вы можете использовать триггеры, чтобы получить необходимую вам функциональность. Я не думаю, что вы получите контрольный журнал изменения схемы, если MySQL не представит схему в виде таблиц, в которые, в свою очередь, могут быть помещены триггеры.

Конечно, все эти триггерные споры являются спорными, если кто-то получает доступ к базе данных "корневого" уровня и просто отключает триггеры, прежде чем они начнут манипулировать данными. В этот момент все ставки отключены. (... и это даже не начинает иметь дело с кем-то, получающим доступ на уровне "root" к ОС, на которой размещена база данных... манипулирование файлами базы данных на уровне байтов, монтирование их на экземпляре базы данных, который имеет безопасность черты "взломаны" из него и т.д... :))

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

Честно говоря, вам лучше всего предотвратить нежелательные изменения с помощью разрешений MySQL.

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

Что касается того, как вы проверяете контрольную сумму и как вы храните ключ в секрете, это совсем другая история, о которой вы можете не стесняйтесь писать мне по электронной почте, если вы выясните это с или через этот сайт (я новичок здесь и не настроен) правильно пока).

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

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

Мы реализовали DbProtect в базе данных SQL Server. Это не было слишком сложно, и это позволило некоторые довольно детальные политики для аудита. Однако, как упомянул Бобвуд, это не дешево.

SQL Server 2005 представил триггеры DDL, которые можно запускать всякий раз, когда кто-то запускает код языка определения данных, например, изменение таблицы, добавление индекса или удаление представления.