+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    2 661
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 2 661
    Points : 56 466
    Points
    56 466

    Par défaut Plus de 2000 instances MongoDB prises en otage dans l'attente du paiement d'une rançon,

    Plus de 2000 instances MongoDB prises en otage dans l'attente du paiement d'une rançon,
    les administrateurs sont invités à vérifier leurs configurations

    Il y a près de deux ans déjà, un chercheur en sécurité identifiait plus de 33 500 instances MongoDB comportant un port d’administration ouvert, parmi lesquelles près de 19 000 ne demandaient aucune authentification. Les utilisateurs de MongoDB étaient donc prévenus du fait que des instances (près de 600 To de données) mettaient à la merci d’un pirate les sites et applications web qui s’appuyaient sur ces bases de données. Bien entendu ces instances MongoDB ne se retrouvaient pas en danger en raison d'un défaut logiciel, mais à cause d'une mauvaise configuration qui permet à un attaquant à distance d'accéder aux bases de données MongoDB sans même avoir à se servir d’un quelconque outil de piratage.

    Dans une mise à jour, MongoDB a résolu ce problème en définissant par défaut dans les configurations un accès restreint à distance. Il semble que de nombreux administrateurs n’ont pas pris la peine d’effectuer la mise à jour. C’est en tout cas ce que suggère un évènement récent qui affecte MongoDB.

    Victor Gevers, un chercheur en sécurité et accessoirement co-fondateur de la fondation GDI, un organisme à but non lucratif visant à rendre l'Internet plus sûr, a trouvé une instance MongoDB prise en otage. Si elles étaient encore 200 lundi dernier, selon un tweet de John Matherly, le fondateur de Shodan (un moteur de recherche de machines connectées) le nombre a été multiplié par 10 en l’espace de quelques jours. Selon Bob Diachenko, un chercheur de MacKeeper, parmi les victimes figurent une organisation dans le domaine de la santé aux Etats-Unis qui a perdu l’accès à 200 000 enregistrements.

    Tout a commencé le 27 décembre lorsque, dans le cadre de ses activités au sein de la GDI, il a repéré une base de données MongoDB dont l’accès n’était pas protégé par un mot de passe. Cette dernière l’a interpellé parce qu’au lieu de voir du contenu, il est tombé sur le message « SEND 0.2 BTC TO THIS ADDRESS 13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq AND CONTACT THIS EMAIL WITH YOUR IP OF YOUR SERVER TO RECOVER YOUR DATABASE ! ».


    Pour Gevers, il est possible que l'attaquant trouve les installations MongoDB par un scan basique ou Shodan. Il est également possible de trouver des installations MongoDB qui soient vulnérables à différents exploits, comme le fait d'autoriser les utilisateurs authentifiés distants pour obtenir des privilèges systèmes. « Les criminels ciblent souvent les bases de données open source pour déployer leurs activités de vol ou de rançonnage. Mais nous avons aussi vu des cas où des serveurs sont utilisés pour héberger des logiciels malveillants, des botnets et pour cacher des fichiers dans GridFS », a-t-il expliqué.

    Si le procédé s’apparente à celui des ransomwares, notamment une prise en otage des données associée à une demande rançon, l’attaque ne fait pas appel à un malware de ce type. D’ailleurs Gevers le rappelle lorsqu’il dit que « ce n’est pas un ransomware. La base de données n’est pas chiffrée, mais simplement remplacée. Nous avons affaire à quelqu’un qui effectue cette opération manuellement ou via un simple script Python ».

    L’entité derrière cette attaque, qui utilise le pseudonyme harak1r1, exige le paiement d'une rançon de 0,2 bitcoin (ce qui représente environ 200 euros dans le cours actuel de cette monnaie virtuelle) mais aussi d’être contacté par courriel avec l’IP du serveur pour que les données soient restituées.

    Pour l’heure, 16 entités se sont déjà résolues à payer à en croire le Blockchain dédié au paiement de la rançon.

    Lors de ses recherches, Gevers est tombé sur une base de données MongoDB ouverte disposant de plus de 850 milliards de métadonnées d’enregistrement d’appels téléphoniques. « J’ai dû cligner des yeux à deux reprises pour lire le nombre total ».


    Source : John Matherly, Victor Gevers, Blockchain dédiée au paiement de la rançon

  2. #2
    Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2005
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : juin 2005
    Messages : 16
    Points : 42
    Points
    42

    Par défaut

    850 milliards

  3. #3
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    2 661
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 2 661
    Points : 56 466
    Points
    56 466

    Par défaut Les instances MongoDB prises en otage sont passées de 12 000 à plus de 27 000 en moins de 12 heures

    Les instances MongoDB prises en otage sont passées de 12 000 à plus de 27 000 en moins de 12 heures,
    d'après un chercheur

    Il y a près de deux ans déjà, un chercheur en sécurité identifiait plus de 33 500 instances MongoDB comportant un port d’administration ouvert, parmi lesquelles près de 19 000 ne demandaient aucune authentification. Les utilisateurs de MongoDB étaient donc prévenus du fait que des instances (près de 600 To de données) mettaient à la merci d’un pirate les sites et applications web qui s’appuyaient sur ces bases de données. Bien entendu ces instances MongoDB ne se retrouvaient pas en danger en raison d'un défaut logiciel, mais à cause d'une mauvaise configuration qui permet à un attaquant à distance d'accéder aux bases de données MongoDB sans même avoir à se servir d’un quelconque outil de piratage.

    Si dans une mise à jour MongoDB a résolu ce problème, de nombreux administrateurs n’ont pas pris la peine de procéder à la mise à jour comme l’a suggéré un évènement récent : plus de 2000 instances MongoDB ont été prises en otage. L’entité derrière l’attaque, qui utilise le pseudonyme harak1r1, accède, copie et supprime des données provenant de bases de données non patchées ou mal configurées pour les remplacer par le message « SEND 0.2 BTC TO THIS ADDRESS 13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq AND CONTACT THIS EMAIL WITH YOUR IP OF YOUR SERVER TO RECOVER YOUR DATABASE ! ». 22 victimes ont déjà cédé, à en croire le blockchain réservé au paiement.

    Pour Victor Gevers, un chercheur en sécurité et accessoirement cofondateur de la fondation GDI, il est possible que l'attaquant trouve les installations MongoDB par un scan basique ou Shodan. Il est également possible de trouver des installations MongoDB qui soient vulnérables à différents exploits, comme le fait d'autoriser les utilisateurs authentifiés distants pour obtenir des privilèges système. « Les criminels ciblent souvent les bases de données open source pour déployer leurs activités de vol ou de rançonnage. Mais nous avons aussi vu des cas où des serveurs sont utilisés pour héberger des logiciels malveillants, des botnets et pour cacher des fichiers dans GridFS », a-t-il expliqué.

    Selon Niall Merrigan, un chercheur en sécurité basé en Norvège, le nombre de serveurs compromis, qui étaient de 12 000 le 08 janvier 2017, a dépassé les 27 600 ce même jour dans l’après-midi.


    Merrigan et ses associés ont indiqué avoir enregistré environ 15 attaquants distincts. Une entité se servant du pseudonyme kraken0 a compromis 15.482 instances MongoDB, en exigeant une rançon de 1 Bitcoin (855 euros) et de 0,1 Bitcoin pour la récupération de fichiers. Personne ne semble avoir payé la rançon de 1 Bitcoin pour l’heure, mais 67 transactions ont déjà été enregistrées pour la rançon de 0,1 Bitcoin. Own3d, une autre entité, a demandé 0,5 Bitcoin et a déjà reçu 5 paiements.

    Merrigan et Gevers ont déjà aidé 112 administrateurs à sécuriser leurs bases de données MongoDB qui étaient exposées, selon une fiche de travail. Au total, 99 000 installations MongoDB sont exposées, estime Gevers.


    Source : liste des acteurs (Google Docs)

  4. #4
    Membre éprouvé
    Avatar de maske
    Homme Profil pro
    Escla... Thésard
    Inscrit en
    mai 2008
    Messages
    363
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Finistère (Bretagne)

    Informations professionnelles :
    Activité : Escla... Thésard

    Informations forums :
    Inscription : mai 2008
    Messages : 363
    Points : 1 165
    Points
    1 165

    Par défaut

    Alors moi ça vient de m'arriver dimanche dernier sur mon serveur perso. 80 pages de notes et d'analyses perdues (appli maison perso que j'ai développé pour ma thèse), 6 mois de boulot.

    Naivement j'avais juste installé mongo et comme ça marchait me suis pas posé de questions. Le pire c'est que depuis quelques semaines je me disais qu'il faudrait que je mette en place un système de sauvegarde et de restauration. J'avais pas pris la peine non plus de configurer une sauvegarde serveur ou de la base mongo (à vrai dire j'avais même pas les logs).

    Ça m'apprendra...
    [|]

  5. #5
    Membre actif
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    août 2014
    Messages
    160
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Drôme (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : août 2014
    Messages : 160
    Points : 231
    Points
    231

    Par défaut

    Pb de ces BDD experimentales. Alors d'aucun diront que ca arrive aussi sur les grands noms egalement .. mais ce n'est pas du niveau de ces attaques ou c'est carrement de la purge de BDD !
    Perso j'utilise pour faire joujou avec mon environnement .net (parce que c'est pratique et nouveau) mais jamais je ne mettrai une telle BDD en PROD.

    La premiere fois que j'avais installé une telle BDD, j'avais demandé conseil a un gars qui en faisait depuis un an. Et machinalement quand je lui avais posé la question de l'administration/sauvegarde etc. la seule reponse qu'il m'avait sorti c'etait que la BDD etait redondée donc pas un soucis
    Aujourd'hui je sais qu'il a subit egalement des attaques et sa BDD dans son labo de recherches a ete partiellement purgée. Aujourdhui je suis triste pour lui mais c'etait prévisible finalement quand on joue avec le feu sans le maitriser.

  6. #6
    Membre éprouvé
    Avatar de Cafeinoman
    Homme Profil pro
    Couteau suisse d'une PME
    Inscrit en
    octobre 2012
    Messages
    580
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Couteau suisse d'une PME

    Informations forums :
    Inscription : octobre 2012
    Messages : 580
    Points : 1 160
    Points
    1 160

    Par défaut

    Mouais fin bon, jouer avec le feu, c'est pas utiliser mongo en prod. Ca, c'est bien. Nan, jouer avec le feu, c'est a)exposer ses ports sur le wan, b)ne pas mettre d'authentification.
    Une base, ca s'expose pas comme ca, quelque soit la techno, point.
    «Dieu ne joue pas aux dés.» - Albert Einstein. Et pan! 30 ans de retard dans la théorie quantique!
    «Tout n'est pas politique, mais la politique s'intéresse à tout.» - Nicolas Machiavel. Et surtout à ceux qui ne s'y intéressent pas.

  7. #7
    Futur Membre du Club Avatar de zellerda
    Homme Profil pro
    Développeur Web
    Inscrit en
    décembre 2012
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : décembre 2012
    Messages : 5
    Points : 9
    Points
    9

    Par défaut

    ça ne viendrait pas à l'idée de personne de simplement autoriser les connexions à Mongo uniquement depuis localhost !

  8. #8
    Membre confirmé Avatar de ypicot
    Profil pro
    Inscrit en
    mai 2004
    Messages
    400
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations forums :
    Inscription : mai 2004
    Messages : 400
    Points : 549
    Points
    549

    Par défaut

    Cela me rappelle ceci.

    Règle de base : modifier tout ce qui est par défaut. Ne jamais utiliser le port 22 pour du ssh, supprimer le compte admin proposé par défaut (et en créer un autre), etc.
    Même les dev doivent savoir ça.

    Yvan
    Une solution n'est valable que dans un contexte donné

  9. #9
    Membre confirmé
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    juin 2004
    Messages
    190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : Belgique

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 190
    Points : 601
    Points
    601

    Par défaut

    J'avoue ne pas comprendre l'intérêt de ne pas utiliser le port 22 pour le ssh (sauf peut-être si c'est pour utiliser un port > 1024 sans l'accès root, mais bonjour les compliquations au niveau de la config des clients). Quand à supprimer le compte admin, c'est parfois impossible (postgres sous postgresql ne peut être supprimé), et encore une fois j'ai du mal à comprendre l'utilité d'une telle démarche ? En général la configuration par défaut est faite pour matcher un max de cas sans avoir à changer quoi que ce soit.

    Par contre changer le mot de passe par défaut c'est une évidence ...

  10. #10
    Membre confirmé Avatar de ypicot
    Profil pro
    Inscrit en
    mai 2004
    Messages
    400
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations forums :
    Inscription : mai 2004
    Messages : 400
    Points : 549
    Points
    549

    Par défaut

    Citation Envoyé par Shepard Voir le message
    J'avoue ne pas comprendre l'intérêt de ne pas utiliser le port 22 pour le ssh (sauf peut-être si c'est pour utiliser un port > 1024 sans l'accès root
    Effectivement, le but est d'utiliser un port >1024 (et de virer l'accès root)
    Le but est de rendre l'accès un peu plus difficile. C'est comme pour les serrures de porte : elles sont classées par temps moyen pour être fracturée.
    L'idée est de faire perdre le maximum de temps (et donc de ressource) à l'attaquant.

    Merci pour l'info sur postgresql, je ne savais pas. Ne peut-on pas réduire les droits d'accès de ce compte ?

    Yvan
    Une solution n'est valable que dans un contexte donné

  11. #11
    Membre confirmé
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    juin 2004
    Messages
    190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : Belgique

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 190
    Points : 601
    Points
    601

    Par défaut

    Ok, je viens d'aller voir à quoi ressemblait la sécurité chez MongoDB. Par défaut, le serveur ne requiert pas d'authentification; tout le monde se connecte en tant qu'admin dessus ... Oo

    https://docs.mongodb.com/manual/tuto...uthentication/

    Je ne comprends pas bien ... Le cas d'utilisation principal de MongoDB est de stocker des données perso ? (comme kilroyFR) Je pensais que c'était l'un des leaders dans le NOSQL ...

  12. #12
    Membre confirmé
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    juin 2004
    Messages
    190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : Belgique

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 190
    Points : 601
    Points
    601

    Par défaut

    Citation Envoyé par ypicot Voir le message
    Effectivement, le but est d'utiliser un port >1024 (et de virer l'accès root)
    Le but est de rendre l'accès un peu plus difficile. C'est comme pour les serrures de porte : elles sont classées par temps moyen pour être fracturée.
    L'idée est de faire perdre le maximum de temps (et donc de ressource) à l'attaquant.

    Merci pour l'info sur postgresql, je ne savais pas. Ne peut-on pas réduire les droits d'accès de ce compte ?

    Yvan
    Pour l'analogie avec les serrures de portes, SSH (avec un bon mot de passe) c'est comme utiliser une porte blindée ronde de 60cm d'épaisseur comme on en voit dans les films

    Quand quelqu'un arrive à passer c'est généralement en faisant sauter le sol (ou le toit). Du coup je ne suis toujours pas convaincu par l'utilité de changer le port utilisé ... D'autant plus qu'un scan des ports suffit à contourner cette mesure ...

    Pour l'utilisateur postgres, je n'en ai aucune idée Mais par défaut on ne peut pas se connecter à ce compte à moins d'être déjà connecté en tant que l'utilisateur (unix) postgres local sur le serveur.

  13. #13
    Membre averti
    Profil pro
    Inscrit en
    mai 2011
    Messages
    166
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2011
    Messages : 166
    Points : 347
    Points
    347

    Par défaut

    Citation Envoyé par ypicot Voir le message
    Cela me rappelle ceci.

    Règle de base : modifier tout ce qui est par défaut. Ne jamais utiliser le port 22 pour du ssh, supprimer le compte admin proposé par défaut (et en créer un autre), etc.
    Même les dev doivent savoir ça.

    Yvan

    Parfaitement d'accord, toujours des excuses pour ne pas faire ce qui aurait du etre fait.

  14. #14
    Membre averti
    Profil pro
    Inscrit en
    mai 2011
    Messages
    166
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2011
    Messages : 166
    Points : 347
    Points
    347

    Par défaut

    Je me rappelle ou le probleme ce n'était pas le système NOSQL mongodb, mais le RDMS mysql.

    On était tout content, on avait appris comment utiliser la couche LAMP stack (Linux Apache MySQL PHP) sur un site, a l'école, parfois par des "pros".
    Mais on n'avait jamais appris a le sécurisé, juste appris qu'il fallait soit installer wamp/xamp, soit installer la ligne magique sur Linux.

    Et aujourd'hui, on recommence la même connerie avec le MEAN stack (Mongo Express Angular Node).

    Je pense que le problème, c'est que beaucoup de debutant/pros ne sachent réellement configurer une base de données. Surtout qu'on apprend aux gens comment s'y connecter directement au lieu de créer un intermédiaire. Car créer un intermédiaire est plus compliqué dans le planning de développement d'une entreprise que d'utiliser les bonnes pratiques de la séparation des couches applicatives. Après tout ce n'est pas une connaissance basique de le savoir.

  15. #15
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    2 661
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 2 661
    Points : 56 466
    Points
    56 466

    Par défaut MongoDB : comment éviter les attaques qui prennent en otage vos donnés ?

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

    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é

  16. #16
    Nouveau Candidat au Club
    Homme Profil pro
    .
    Inscrit en
    mai 2015
    Messages
    431
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : .

    Informations forums :
    Inscription : mai 2015
    Messages : 431
    Points : 0
    Points
    0

    Par défaut

    Le processus installation de MongoDb est a revoir. C'est certain...

    Toutes ces config devraient se faire par defaut lors de l'installation...

  17. #17
    Membre éprouvé
    Avatar de maske
    Homme Profil pro
    Escla... Thésard
    Inscrit en
    mai 2008
    Messages
    363
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Finistère (Bretagne)

    Informations professionnelles :
    Activité : Escla... Thésard

    Informations forums :
    Inscription : mai 2008
    Messages : 363
    Points : 1 165
    Points
    1 165

    Par défaut

    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).
    [|]

  18. #18
    Nouveau Candidat au Club
    Homme Profil pro
    .
    Inscrit en
    mai 2015
    Messages
    431
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : .

    Informations forums :
    Inscription : mai 2015
    Messages : 431
    Points : 0
    Points
    0

    Par défaut

    Le principe des droits minimum a l'installation n'est pas appliqué par MongoDB. C'est une erreur (de debutant ?)

  19. #19
    Membre actif
    Inscrit en
    mai 2006
    Messages
    135
    Détails du profil
    Informations forums :
    Inscription : mai 2006
    Messages : 135
    Points : 212
    Points
    212

    Par défaut

    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.

  20. #20
    Nouveau Candidat au Club
    Homme Profil pro
    .
    Inscrit en
    mai 2015
    Messages
    431
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : .

    Informations forums :
    Inscription : mai 2015
    Messages : 431
    Points : 0
    Points
    0

    Par défaut

    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....

Discussions similaires

  1. [Win 2000] Ajouter un compte du domaine dans le groupe Admin
    Par drinkmilk dans le forum Windows Serveur
    Réponses: 4
    Dernier message: 14/03/2006, 12h03
  2. Quel SGBD peut gérer plus de 2000 champs par table?
    Par colorid dans le forum Bases de données
    Réponses: 9
    Dernier message: 23/11/2005, 20h58

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo