Les intrusions dans les systèmes de fichiers peuvent être détectées à l'aide d'outils tels que Snort, mais il est plus difficile de détecter les intrusions dans une base de données, comme la suppression de lignes, la modification de tables, etc. Quelle est la meilleure façon de surveiller cela pour détecter les changements non désirés dans la base de données ?
J'utilise MySQL, donc tout ce qui n'est pas agnostique par rapport à la base de données devrait idéalement être destiné à MySQL.
Cela dépend de la façon dont vous vous connectez à votre base de données. Si vous utilisez une application Web, Snort (et d'autres NIDS) sera en mesure de détecter les injections SQL et d'autres attaques qui se produisent via HTTP.
Le problème est que si vous utilisez des connexions SSL ou cryptées à votre base de données, votre NIDS ne verra pas le trafic.
C'est pourquoi l'analyse des journaux est très importante. La seule façon pour votre base de données de vous répondre est à travers les logs et beaucoup de DBAs ne sont pas familiers avec cela. Je ne comprends vraiment pas pourquoi tout le monde accepte la journalisation web comme familière, mais néglige la journalisation de la base de données (j'en parlerai plus longuement une autre fois).
Pour activer le journal mysql : http://www.ossec.net/wiki/index.php/SQL_Logging#MySQL_Logging
J'utilise également le logiciel libre OSSEC pour surveiller mes journaux MySQL et il fonctionne très bien.
Je n'utilise pas MySQL, donc je ne peux pas parler des caractéristiques spécifiques de la plateforme.
On dirait que vous voulez une sorte de piste d'audit. Dans le sens général du SGBDR, vous pourriez être en mesure d'utiliser des déclencheurs pour obtenir certaines des fonctionnalités que vous recherchez. Je ne pense pas que vous obtiendrez une piste d'audit de la modification du schéma à moins que MySQL ne représente le schéma comme des tables qui peuvent, à leur tour, avoir des déclencheurs placés sur elles.
Bien sûr, toute cette histoire de déclencheurs est sans intérêt si quelqu'un obtient un accès de niveau "root" à la base de données et décroche les déclencheurs avant qu'ils ne commencent à manipuler les données. A ce moment-là, tous les paris sont ouverts. (...et ce n'est même pas la peine de penser à quelqu'un qui obtiendrait un accès de niveau "root" au système d'exploitation hébergeant la base de données... manipulation au niveau de l'octet des fichiers de la base de données, montage sur une instance de base de données dont les fonctions de sécurité ont été "piratées", etc...). sourire )
Si vous voulez vraiment suivre chaque changement apporté à vos tables, vous devrez faire quelque chose de fou comme activer le journal des requêtes MySQL et rechercher les mauvaises choses en utilisant quelque chose comme Simple Event Correlator. Mais ne faites pas cela, car les performances de votre serveur en pâtiraient.
Honnêtement, votre meilleure chance est d'empêcher les changements non désirés en premier lieu en utilisant les permissions MySQL.
Snort peut encore être utile. Le problème est de savoir d'où doit provenir le trafic de votre base de données. S'il provient d'une source autre que celle qui est approuvée, vous pouvez le bloquer, bien évidemment, dans MySQL. Cependant, vous pouvez également configurer des alertes dans votre IDS pour détecter ce genre de choses.
En ce qui concerne une attaque provenant d'une adresse IP autorisée, c'est un peu plus difficile. La question clé est de savoir ce qu'une connexion doit être autorisée à faire et ce qu'elle ne doit pas faire. Et cela revient à définir correctement les autorisations. Si un utilisateur légitime se connecte à partir d'une adresse IP légitime, qu'il a besoin des autorisations DELETE et qu'il veut être malveillant, il n'y a pas grand-chose que vous puissiez faire pendant la modification proprement dite. Une suggestion a été faite pour l'audit, mais cela nuit à vos performances. Je ne suis pas sûr que vous ayez un contrôle efficace si les utilisateurs peuvent accéder directement à la base de données et effectuer des modifications. Toutes les plateformes de base de données, et pas seulement MySQL, sont confrontées à ce problème. Vous avez un utilisateur de confiance qui effectue une modification autorisée. Il n'y a pas grand-chose que vous puissiez faire.
Il existe des produits commerciaux conçus pour cela. Je crois que nous avons examiné DbProtect (www.appsecinc.com) et que sa mise en œuvre a coûté très cher, mais nous avons fini par ne pas le faire. J'ai également vu Guardium (www.guardium.com). Les deux prétendent prendre en charge une certaine version de MySQL.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
