Вторжения в файловую систему можно обнаружить с помощью таких инструментов, как Snort, но гораздо труднее обнаружить вторжения в базу данных, такие как удаление строк, изменение таблиц и т. Д. Как лучше всего отслеживать это для обнаружения нежелательных изменений в базе данных?
Я использую MySQL, поэтому все, что не зависит от базы данных, в идеале должно быть нацелено на MySQL.
Это зависит от того, как вы подключаетесь к своей базе данных. Если вы используете веб-приложение, Snort (и другие NIDS) смогут обнаруживать SQL-инъекции и другие атаки, происходящие через HTTP.
Проблема в том, что если вы используете SSL или зашифрованные соединения с вашей базой данных, ваши NIDS не будут видеть трафик.
Вот почему анализ журнала очень важен. Единственный способ, которым ваша база данных отвечает вам, - это журналы, и многие администраторы баз данных не знакомы с этим. Я действительно не понимаю, почему все принимают ведение журнала как знакомое, но пренебрегают ведением журнала в базе данных (я расскажу об этом подробнее в другой раз).
Чтобы включить журнал mysql: http://www.ossec.net/wiki/index.php/SQL_Logging#MySQL_Logging
Я также использую OSSEC с открытым исходным кодом для мониторинга журналов MySQL, и он отлично работает.
Фырканье все еще может быть полезным. Уловка состоит в том, чтобы знать, откуда должен поступать трафик вашей базы данных. Если он исходит из источника, отличного от одобренного, вы, очевидно, можете заблокировать его в MySQL. Однако вы также можете настроить оповещения в своей IDS, чтобы видеть подобные вещи.
Что касается атаки, исходящей с авторизованного IP-адреса, это небольшая проблема. Ключевой вопрос здесь - что должно быть разрешено подключению, а что нет? И это возвращается к правильной настройке разрешений. Если легитимный пользователь подключается с легитимного IP-адреса и ему нужны разрешения на УДАЛЕНИЕ, и он хочет быть злоумышленником, во время фактического изменения вы мало что можете с этим поделать. Было предложено провести аудит, но это вредит вашей работе. Я не уверен, что у вас есть эффективный контроль, если пользователи могут напрямую обращаться к базе данных и вносить изменения. Все платформы баз данных, не только MySQL, борются с этим. У вас есть доверенный пользователь, который вносит авторизованные изменения. Ты можешь сделать так много.
Если вы действительно хотите отслеживать каждое изменение в своих таблицах, вам придется сделать что-нибудь безумное, например, включить журнал запросов MySQL и сканировать плохие вещи, используя что-то вроде Simple Event Correlator. Не делайте этого, потому что это снизит производительность вашего сервера.
Честно говоря, лучше всего предотвратить нежелательные изменения в первую очередь с помощью разрешений MySQL.
Я не использую MySQL, поэтому не могу говорить о каких-либо конкретных функциях платформы.
Похоже, вам нужен какой-то контрольный след. Говоря в общем смысле РСУБД, вы можете использовать триггеры, чтобы получить некоторые из функций, которые вы ищете. Я не думаю, что вы получите контрольный журнал изменения схемы, если MySQL не представляет схему в виде таблиц, которые, в свою очередь, могут иметь триггеры.
Конечно, все, что триггер бред спорно, если кто-то получает «корень» уровень доступа к базе данных и просто отцепляется триггеры, прежде чем они начинают monkeying с данными. В этот момент все ставки отменены. (... и это даже не касается тех, кто получает доступ на уровне «root» к ОС, на которой размещена база данных ... манипулирование файлами базы данных на уровне байтов, монтирование их на экземпляре базы данных, который имеет безопасность особенности "взломанные" из него и т.д ... улыбка)
Для этого существуют коммерческие продукты. Я думаю, мы смотрели на DbProtect (www.appsecinc.com), и на его реализацию были потрачены большие деньги, но в итоге мы этого не сделали. Я также видел Guardium (www.guardium.com). Оба утверждают, что поддерживают некоторую версию MySQL.
В SQL Server 2005 появились триггеры DDL, которые можно запускать всякий раз, когда кто-то запускает код языка определения данных, например, при изменении таблицы, добавлении индекса или удалении представления.
Я не верю, что в MySQL есть какие-либо подходящие методы для этого. Вы должны убедиться, что контрольная сумма безопасности применяется ко всем законным изменениям, используя какой-то секретный ключ, поэтому, если данные строки отличаются от контрольной суммы, вы знаете, что было внесено несанкционированное изменение.
Что касается того, как вы используете контрольную сумму и как вы храните ключ в секрете, это совсем другая история, о которой вы можете свободно написать мне по электронной почте, если вы выясните это с этого сайта или через него (я здесь новичок и не настроен должным образом пока).
На самом деле, только резервные копии за пределами сайта помогут вам защититься от удаления строк, и обратите внимание, что использование mysqldump является единственным «официально» поддерживаемым методом для этого.
Хотя копирование базовых файлов (MyISAM) работает в подавляющем большинстве случаев для этого типа таблиц, оно действительно иногда падает, поэтому я бы не стал доверять ему одному для чего-либо критически важного.
Мы реализовали DbProtect в базе данных SQL Server. Это было не так уж сложно и позволяло проводить довольно подробные политики аудита. Однако, как сказал bobwood, это не дешево.