MongoDB : comment éviter les attaques qui prennent en otage vos données ?
Un billet de l'entreprise pour essayer d'endiguer ce phénomène

Le , par Stéphane le calme, Chroniqueur Actualités
Des attaques impliquant des pirates informatiques qui copient des données de bases de données non sécurisées, suppriment l'original et demandent une rançon de quelques centaines d’euros en Bitcoin pour renvoyer les données volées au propriétaire se sont multipliées. En une semaine, près de 30 000 bases MongoDB ont été ainsi prises en otage sur 100 000 qui ont été répertoriées par des chercheurs comme étant vulnérables..

Comme d'autres bases de données NoSQL, MongoDB a souffert de lacunes de sécurité pendant des années. Lorsque MySQL, PostgreSQL et d'autres bases de données relationnelles tendent à avoir recours à une forme quelconque d'autorisation, les bases de données MongoDB sont exposées à Internet et ne nécessitent pas d'informations d'identification immédiatement par défaut.

Face à ces vagues d’attaques qui visent à prendre en otage des instances MongoDB, Andreas Nilsson, Director of Product Security chez MongoDB a publié un billet dans lequel il explique aux administrateurs comment éviter ce type d’attaque. « Ces attaques peuvent être évitées grâce aux nombreuses protections de sécurité intégrées à MongoDB. Vous devez utiliser ces fonctionnalités correctement et notre documentation de sécurité vous aidera à le faire », assure-t-il.

Il rappelle par exemple que la dernière version de MongoDB 3.4 vous permet de configurer l'authentification sur un système non protégé sans encourir de temps d'arrêt.

Le service hébergé de base de données MongoDB Atlas fournit plusieurs niveaux de sécurité pour votre base de données. Il s'agit notamment du contrôle d'accès robuste, de l'isolement du réseau à l'aide des VPC d'Amazon et du VPC Peering, des listes blanches IP, du cryptage des données en vol utilisant TLS / SSL et du chiffrement optionnel du système de fichiers sous-jacent.

Il propose également quelques étapes pour diagnostiquer et répondre à une attaque et rappelle également l’existence d’une liste de vérification de sécurité qui peut s’avérer très utile. .
Néanmoins, Chris Wysopal, le directeur de la technologie chez Veracode, a soutenu qu’un logiciel doit être sécurisé dès qu’il est installé : « pourquoi la liste de contrôle de sécurité MongoDB n'est-elle pas la valeur par défaut? », s’est-il indigné.


Mais Victor Gevers a eu des propos plus modérés à l’endroit de MongoDB. Il a rappelé l’avoir critiqué par le passé mais a insisté sur le fait que les propriétaires de base de données doivent prendre leurs responsabilités lorsqu’il s’agit de configurations. Pour lui, la croissance des installations MongoDB mal configurées est le reflet des pressions du temps sur le marché. « Les gens aiment bien suivre un tutoriel pour installer un serveur, mais n'ont aucune idée de ce qu'ils font », a-t-il dit. Il n’a pas épargné l'automatisation DevOps qui tend à déployer des serveurs distants sans nécessairement les sécuriser correctement. Le chercheur a recommandé de suivre les recommandations de sécurité de MongoDB, de bloquer le port 27017 sur votre pare-feu ou de configurer MongoDB pour un accès en localhost (127.0.0.1) via /etc/mongodb.conf puis redémarrer la base de données.

Un porte-parole de MongoDB dans les locaux de New York a insisté sur le fait que MongoDB n’est pas moins sécurisé qu’une base de données relationnelles comme MySQL ou PosteSQL : « MongoDB dispose des capacités de sécurité robustes que l'on pourrait attendre d'une base de données moderne (...) C'est dans la nature d’un logiciel de base de données que les administrateurs puissent activer et désactiver certaines options. Ceci n'est pas spécifique à MongoDB et demeure important pour la façon dont de nombreuses applications peuvent être développées ».

Et d'ajouter « qu’être open-source signifie également que n'importe qui peut télécharger le produit et le déployer comme bon lui semble ». « En fin de compte, la sécurité des bases de données se résume à deux choses : le logiciel bien fait et l'utilisation responsable. Par exemple, avec MongoDB Atlas, notre base de données prête à la production en tant que service, le contrôle d'accès est activé par défaut. Les utilisateurs de MongoDB Cloud Manager ou Ops Manager peuvent permettre aux alertes de détecter si leur déploiement est exposé sur Internet ».

Source : comment éviter les attaques malveillantes qui prennent en otage vos données, check-list de sécurité


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Aeson Aeson - Nouveau Candidat au Club https://www.developpez.com
le 12/01/2017 à 0:26
Le processus installation de MongoDb est a revoir. C'est certain...

Toutes ces config devraient se faire par defaut lors de l'installation...
Avatar de maske maske - Membre éprouvé https://www.developpez.com
le 13/01/2017 à 10:31
Citation Envoyé par koyosama  Voir le message
C'est plutot la formation des developpeurs/devops/sysadmin qui est a revoir. Le preservatif ce n'est pas automatique. On utilise pas un truc en production si on se sait pas ce qu'on fait.

C'est vrai dans l'absolu, mais quand même. Quand j'installe un soft ou un outil, je ne m'attends pas à ce qu'il soit ouvert au monde entier par défaut.

Ça me parait bizarre de reporter la faute exclusivement sur l'utilisateur, surtout de la part d'un outil open source qui vante sa simplicité d'utilisation (je ne parle pas de mongo spécifiquement).
Avatar de Aeson Aeson - Nouveau Candidat au Club https://www.developpez.com
le 13/01/2017 à 10:51
Le principe des droits minimum a l'installation n'est pas appliqué par MongoDB. C'est une erreur (de debutant ?)
Avatar de Paenitentia Paenitentia - Membre actif https://www.developpez.com
le 13/01/2017 à 17:12
Par défaut, le fichier de configuration de MongoDB n'écoute que sous localhost:27017 (c'était le cas sur les 3.2 que j'ai installé). Ça veut dire que les bases de données exposées ont un fichier de conf "maison" et qu'il a été touché non ?

PostgreSql fonctionne sur le même principe il me semble. Lorsque j'ai installé la 9.4, mon user par défaut n'avait pas de mot de passe mais il n'écoutait que sur localhost:32.

Habituellement, lorsque les bases de données sont installées en dehors de mon poste local de dev, j'ai systématiquement forcé une authentification avec un utilisateur 'root', un 'app', et deux users par personne, un en lecture seule, l'autre en lecture + écriture. Ça me semble essentiel pour conserver une bonne traçabilité des actions, ça aide beaucoup et ce n'est pas très long à mettre en place qui plus est.
Avatar de Aeson Aeson - Nouveau Candidat au Club https://www.developpez.com
le 13/01/2017 à 18:02
Do not make mongod.exe visible on public networks without running in “Secure Mode” with the auth setting. MongoDB is designed to be run in trusted environments, and the database does not enable “Secure Mode” by default

Par default il n'y a pas de Login. Donc si on travail sur mongoDB en local ca peut aller. Mais c'est vrai que de le mettre sur le reseaux sans le securiser au moin par un mot de passe est une erreur.

Mais avoir une base de donnée sans authentification par mot de passe a l'install et qui donc accepte les connexion anonyme, je n'ai jamais vu ca....
Avatar de koyosama koyosama - Membre confirmé https://www.developpez.com
le 14/01/2017 à 14:32
Citation Envoyé par maske  Voir le message
C'est vrai dans l'absolu, mais quand même. Quand j'installe un soft ou un outil, je ne m'attends pas à ce qu'il soit ouvert au monde entier par défaut.

Ça me parait bizarre de reporter la faute exclusivement sur l'utilisateur, surtout de la part d'un outil open source qui vante sa simplicité d'utilisation (je ne parle pas de mongo spécifiquement).


Deja j'ai envie de dire que "ouvert" n'a rien a voir avec le monde professionel. Tu peux mettre un mot de passe par defaut comme wordpress, my sql, cela va rien changer.
Un utilisateur a des chances d'etre un developeur, sysadmin, deveops; whatever ils ont une responsabilite envers nos donnees. Celon le type d'applications, on joue avec la vie des gens. Le piratage est parfois une lecon par des crackers pour nous dire de mieux controller nos donnes. Est-ce que un medecin doit faire le minimum, c'est un peu trop facile. Il y a une limite a la feignantise.

Quand on est paye 30-45 k, je m'attends a ce que le gars puisse au minimum creer un system utilisateur minimal. Si tu peux creer un compte user sur windows, tu peux largement prendre un heure pour lire, tester la securite de mongo de DB. Il faut arreter avec le poil de la main. Aujourd'hui on arrive dans une ere ou certaine donnes sont critiques pour n'importe quel utilisateur.



Chercher pas d'excuse, faite le neccessaire.
Avatar de Spouick Spouick - Candidat au Club https://www.developpez.com
le 24/01/2017 à 10:42
100% en accord avec koyosama.

Il faut arrêter de vous tourner les pouces et faire votre job => vous êtes payé pour ça même en tant que simple DEV.
Quand j'installe un nouveau soft, je lis TOUJOURS la doc, la config et la sécu. Oui je sais "on doit lire"... (payé pour).
Premier principe, vérifier les accès, vérifier les ports, les comptes, les directories, en un mot "être maître de VOTRE architecture".
Si un port peut être changé, changez le (faite votre carto)! idem pour les comptes, créez vos admin puis supprimez tous les comptes, c'est basic mais combien sont encore accessible avec juste "admin/admin" ?!

Si vous pouvez découpler l'accès, faite le (évitez les accès direct autant que faire ce peu) ça vous évitera les sempiternel faille de sécu.
etc, etc, etc

Pour les anciens qui avaient l'habitude de manipuler les IRQ ça semble logique qu'une config n'est qu'un "default usage" et non un "ready to use", mais vous êtes tellement habitué au conformisme et moutonnage que vous ne vous rendez même plus maitre de vos archi/install. Edifiant !
Avatar de maske maske - Membre éprouvé https://www.developpez.com
le 24/01/2017 à 14:52
Il faut faire la part des choses quand même. Évidemment que la responsabilité revient à l'entreprise, lorsqu'elle se fait pirater des données à cause d'un défaut de sécurisation - charge à cette dernière d'en tirer les conséquences. De l'autre coté, moi (qui n'y connais rien), je cherche pour une appli perso un système de base simple et reconnu : mongodb. Si on regarde, c'est vendu comme un truc efficace dans son périmètre, facile à installer et à utiliser. Je lis ça, je ne me demande pas si l'installation par défaut ouvre le système sur le monde entier.

Alors j'ai perdu ma base, il ne m'en reste qu'un export pdf (complet, heureusement) est-ce que c'est ma faute ? Oui. Est-ce que c'est intégralement ma faute ? Je ne pense pas, j'ai l'habitude d'attendre de l'open source suffisemment d'informations claires - surtout quand on me vend un truc simple et efficace - pour savoir d'un coup d'oeil qu'il faut prendre soin de bloquer plein de trucs. Peut-être que je n'ai pas les bonnes attentes, ou peut-être que les gens dont c'est le métier ont l'habitude de ça (mais vu le nombre de bases piratées, faudrait voir).
Offres d'emploi IT
Développeur e-commerce expérimenté H/F Bordeaux
Smile - Aquitaine - Bordeaux (33000)
Développeur BI Big Data
AUBAY - Ile de France - Boulogne-Billancourt (92100)
Développeur Drupal H/F Lyon
Smile - Rhône Alpes - Lyon (69000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil