Connexion
Abonnez-vous

Des centaines de bases MongoDB attaquées à cause de mauvaises configurations

Entrez, la porte est ouverte

Des centaines de bases MongoDB attaquées à cause de mauvaises configurations

Le 05 janvier 2017 à 16h20

Des centaines de bases de données MongoDB sont actuellement attaquées par un pirate, qui en remplace le contenu et demande une rançon. Une attaque qui ne se base sur aucun outil particulier, mais exploite des défauts de configuration.

Un pirate, se faisant appeler Harak1r1, s’attaque actuellement à des centaines de bases de données MongoDB dans lesquelles certaines étapes simples de configuration n’ont pas été accomplies par les administrateurs. Ces bases sont ainsi laissées ouvertes aux quatre vents, ceux qui savent où chercher pouvant s’y connecter depuis Internet sans que des identifiants particuliers ne soient réclamés.

Un vol de données contre une petite rançon en bitcoin

L’attaque a été découverte il y a maintenant un peu plus d’une semaine par Victor Gevers de la GDI Foundation, et ne cesse depuis de faire des victimes. Quand le chercheur s’est aperçu de la situation le 27 décembre, environ 400 bases avaient été attaquées. Quelques heures plus tard, le nombre de victimes était grimpé à 1 800.

Le schéma d’attaque est simple. Le pirate s’introduit dans la base et en télécharge les données. Puis il remplace chaque champ par un message, le mot « WARNING » apparaissant un peu partout. Il ne chiffre pas les données mais réclame une rançon de 0,2 bitcoin, soit un peu plus de 200 euros actuellement, le cours de la crypto-monnaie ne cessant de grimper.

Harak1r1 a obtenu la liste de ses victimes en scannant tout simplement Internet. Il ne s’agit pas d’un ransomware, puisqu’à aucun moment un malware n’intervient. Le pirate n’utilise pas non plus d’outil spécifique : il se contente de se connecter et de réaliser des opérations assez classiques sur une base de données, via un simple script en Python.

Une sécurité qui ne préoccupe pas assez

Qui est à blâmer ? Essentiellement les entreprises et autres structures qui déploient ces instances MongoDB, souvent à travers des services de cloud. Elles ne s’occupent plus après de la version utilisée, ni même d’une configuration adaptée. Or, les moutures de MongoDB se sont enchainées, notamment pour contrebalancer un problème récurrent de configuration. Mais ces versions n’ont pas été installées. Pour Victor Gevers, 78 % des instances ouvertes via Amazon Web Services par exemple sont vulnérables.

L'information n'est pas étonnante en elle-même. En février 2015, un groupe d'étudiants allemands avait déjà tiré la sonnette d'alarme sur ce problème : environ 40 000 bases étaient librement accessibles sur Internet. Une partie a visiblement été reprise en main, mais il resterait encore dans les 30 000 bases concernées, selon Bleeping Computer.

Environ 2 000 victimes ont été recensées à ce jour. Parmi elles, seules 18 ont accepté de payer pour l’instant (selon l’adresse Bitcoin utilisée), encouragées probablement par la faible somme demandée. L’immense majorité a résisté au chantage, et il est probable que des sauvegardes récentes des bases attaquées aient permis de gérer le problème. À condition de revoir la configuration de MongoDB et, encore mieux, de mettre à jour la version utilisée.

Quelques conseils simples de vérification et de protection

Dans tous les cas, aucun contact extérieur ne devrait être autorisé sur les bases de données, à moins qu’il ne soit expressément autorisé. Le fichier de configuration de MongoDB doit donc être édité et le paramètre « auth » doit passer en « true ». Il est également conseillé de configurer le trafic sur le port 27017, utilisé par MongoDB pour communiquer à distance.

Sachez que l’on peut également vérifier si la base de données a été visitée, notamment par Harak1r1 ou un autre pirate. Il faut commencer par inspecter la liste des comptes et chercher un éventuel utilisateur avec droits administrateur qui n’aurait rien à faire là. Les journaux de MongoDB gardent également la trace des connexions extérieures. On peut également vérifier GridFS à la recherche de fichiers qui auraient été entreposés.

Autant de conseils qui sont fournis par le site officiel de MongoDB, autour d’un guide des bonnes pratiques. Au vu du danger actuel, certains auraient d’ailleurs tout intérêt à se replonger dans ses explications.

Commentaires (57)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Ouep, ça craint.




 C'est un peu la même chose pour MySQL ou MariaDB, sur linux famille debian/ubuntu       






 $ nano /etc/mysql/my.cnf       

 

[...]



# Instead of skip-networking the default is now to listen only on

# localhost which is more compatible and is not less secure.



bind-address           = 127.0.0.1   



[…]




 n'oubliez pas lancer :        






 $ mysql\_secure\_installation       






 Change the root password? [Y/n] <-- n      

Remove anonymous users? [Y/n] <-- y

Disallow root login remotely? [Y/n] <-- y



Remove test database and access to it? [Y/n] <– y

Reload privilege tables now? [Y/n] <– y




 Sortez couverts :yes:  





Edit : faute de frappe

votre avatar

Une configuration MongoLienne.



Je suis deja loin…

votre avatar

réclame une rançon de 0,2 bitcoin, soit un peu plus de 200 euros actuellement, le cours de la crypto-monnaie ne cessant de grimper. 

&nbsp;<img data-src=" />Bitcoin vient de crasher. -18%

Toujours ça d’économisé&nbsp;<img data-src=" />



EDIT: -20%

&nbsp;

votre avatar

Ma conf par défaut avait déjà cette config mais merci pour la piqûre de rapel&nbsp; <img data-src=" />

votre avatar

Ah oui, des backup non versionnées ça ne sert à rien effectivement !&nbsp;<img data-src=" />



&nbsp;





KP2 a écrit :



Bah, tu serais surpris de la situation des sauvegardes dans les entreprises… et quand y’en a, y’a aucune garantie qu’ils fonctionnent ni même qu’ils sont faits sur les bonnes données.

Alors je te raconte pas la situation sur le web, c’est encore pire…





Je pensais que les entreprises commençaient à prendre conscience de la valeur des données…&nbsp;<img data-src=" />


votre avatar







KP2 a écrit :



Non, pas tout à fait, ça fait longtemps que les install par défaut de Mysql sont complètement fermées pour les accès extérieurs.

Pour Mongo, c’est encore ouvert et c’est débile…





si c’est pareil, je voulais montrer que la config à faire est toute simple, et du coup faire une piqûre de rappel au cas où y’aurai pas l’ecoute en local seul. Après je suis d’accord avec toi c’est incroyable que par défaut mongoDb écoute “partout” par défaut, je ne le savais pas (je n’utilisa pas) j’en tombe des nues.



Normalement par défaut ça devrait en mode liste noire : on refuse tout, c’est l’admin qui ouvre. Et pas l’inverse.


votre avatar







CryoGen a écrit :



J’ai même envie de dire, que si la bdd est accessible sans auth, il y a peu de chance d’avoir des backups dans cette entreprise <img data-src=" />



Et pour celles qui en auraient, je parie qu’une partie a ecrasé la sauvegarde sans versionning avec la version déjà piratée de la base avant de s’en rendre compte <img data-src=" />







Mais carrément !



A la rigueur, ce genre de piratage m’arrange perso, ça me fait du boulot… Mais bon, ça fait chier de connaitre la situation dans les coulisses et de voir aussi que le moindre site débile réclame un compte en laissant une adresse mail, un pass, etc

Parce quand on parle de “données” sur le web qui se font faites piratées, ce sont NOS données personnelles dont on parle. Les bases pourries et mal gérées en question sont remplies de NOS données.



votre avatar







t0FF a écrit :



Je pensais que les entreprises commençaient à prendre conscience de la valeur des données… <img data-src=" />







Elles en prennent conscience APRES la première perte, en général.


votre avatar







boogieplayer a écrit :



Ouep, ça craint.




 C'est un peu la même chose pour MySQL ou MariaDB, sur linux famille debian/ubuntu       






 $ nano /etc/mysql/my.cnf       

 

[...]



# Instead of skip-networking the default is now to listen only on

# localhost which is more compatible and is not less secure.



bind-address           = 127.0.0.1   



[…]





Encore faut-il que la base soit sur la même machine que le site, sinon on risque d’avoir un peu de mal a y accéder <img data-src=" /> Sinon, chiffrement de la connexion + FW avec autorisation uniquement du serveur qui doit se connecter + maintenance



Perso chez moi c’est sur la même machine + phpmyadmin autorisé que sur le LAN. Si j’ai besoin d’y accéder de l’extérieur, je monte un p’tit tunnel SSH avant.


votre avatar







KP2 a écrit :



Bah, tu serais surpris de la situation des sauvegardes dans les entreprises… et quand y’en a, y’a aucune garantie qu’ils fonctionnent ni même qu’ils sont faits sur les bonnes données.

Alors je te raconte pas la situation sur le web, c’est encore pire…







Sur le web on peut prendre un hébergeur qui fait des sauvegardes automatiques de la base tous les jours.


votre avatar







KP2 a écrit :



C’est un peu toujours le cas : y’a toujours pas d’authentification par défaut par exemple…

Les mecs se sont dit : “on fait une base, l’auth, le chiffrage et la sécurité, on laisse ça au système”. OK, sauf que la moitié des mecs qui installent ce genre de trucs sont des devs neuneu sans aucune notion de système et de sécurité qui ne font que suivre des “tutos” faits par d’autres neuneus qui en savent pas plus qu’eux…

Et quand ils arrivent à faire tomber leur bazar en marche, ils lèvent les mains et ne touchent surtout plus à rien…





C’est sympa pour le débutant sur MongoDB qui ne connait pas ce système de base de données et qui suit la documentation qu’il trouve.



Ceci dit, maintenant, je peux me mettre à baliser, parce que chez Framasoft, dans leur tuto d’installation d’Etherpad, ils utilisent MongoDB et ils parlent pas de la configuration de la sécurité, c’est open bar.



/me commence à avoir peur pour ses framapad <img data-src=" /> ou pas, vu ce que je m’en suis servi <img data-src=" /> Et en plus, c’est pas ouvert vers l’extérieur.


votre avatar







renaud07 a écrit :



Sur le web on peut prendre un hébergeur qui fait des sauvegardes automatiques de la base tous les jours.







Ca, c’est valable pour les sites qui tournent sur des mutus… Pour les sites qui tournent sur des dédiés ou des VPS, c’est pas la même…



Et avec l’arrivée de Docker un peu partout, ça va être encore pire au niveau sécurité. Pas à cause de Docker lui-même (que j’apprécie beaucoup pour info) mais parce que plein de tutos font l’éloge du déploiement en 1 commande mais personne ne parle comment sécuriser la tuyauterie, personne se pose la question de ce qu’il y a dans les images du Hub, personne se pose la question de la conf par défaut des trucs déployés, etc etc etc

Bref, avec Docker, y’a plein de noob qui vont se mettre à déployer des archi micro-services avec des dizaines ou des centaines de containers sans aucune sécurité car il faudrait passer un temps fou à checker et corriger tout service par service… Ca va être un beau bordel…


votre avatar

quoi, un backup c’est pas cp -ar données/ backup/ ? <img data-src=" />

(avec le serveur en fonctionnement ofc)

votre avatar







boogieplayer a écrit :



Normalement par défaut ça devrait en mode liste noire : on refuse tout, c’est l’admin qui ouvre. Et pas l’inverse.







Je ne connais pas les tenants et aboutissants mais quelque chose me dit que c’est plus compliqué que ça…. Par exemple pour mysql tu peux bind une ip qui a les accès, mais une seule. Sinon c’est ouverture pour tout le monde, pour le reste il faut passer par iptables.


votre avatar







Fuinril a écrit :



Je ne connais pas les tenants et aboutissants mais quelque chose me dit que c’est plus compliqué que ça…. Par exemple pour mysql tu peux bind une ip qui a les accès, mais une seule. Sinon c’est ouverture pour tout le monde, pour le reste il faut passer par iptables.







Non, il a raison…

Par défaut, l’authentification devrait être active, un mot de passe admin demandé à l’install et avec aucun binding ou un binding sur localhost.

Or, c’est pas du tout comme ça… c’est openbar par défaut et les doc officielles ont une petite ligne à la fin dans le QuickStart Guide : “oubliez pas de sécuriser votre install”

Ah.


votre avatar







psn00ps a écrit :



quoi, un backup c’est pas cp -ar données/ backup/ ? <img data-src=" />

(avec le serveur en fonctionnement ofc)







Ou pire : “quoi ? un snapshot, ça suffit pas pour backup une base de données ?”


votre avatar

Réponse véridique que j’ai eu de la part d’un des audités à qui je demandais quelle politique de sauvegarde il avait mis en place. Je l’interrogeai sur la politique de rétention et les emplacements des backups.



Par décence, je ne ferai pas un copier coller de la réponse mais globalement Il m’a répondu qu’il n’y en avait pas mais qu’on avait rien à craindre car on était dans le cloud OVH et que le serveur loué était en RAID.

Il m’a précisé que cependant il faisait un export de base avant des grosses MAJ. Quand je lui ai demandé comment il les faisait, il m’a dit qu’il utilisait phpmyadmin. En grattant, c’était en http et le mot de passe était d’un niveau que je qualifierai de très amateur.

La boîte qui fait çà est à la base une agence Web d’une quinzaine de personnes et le produit en question était utilisé par une quarantaine de personnes comme outil métier assez critique. Comme l’a fait remarqué dufakeacademy, aussi invraisemblable que cela puisse paraître, ils n’ont pas d’admin, c’est un développeur qui s’occupe de monter les serveurs par ce que c’est “facile”

Et ce n’est malheureusement qu’une de mes nombreuses expériences en la matière, je pourrai en écrire un bouquin…..

votre avatar

J’imagine juste un mailing applicatif après l’attaque de la base :



WARNING, le NULL



W. WARNING WARNING,

il semble que, sauf erreur de notre part, vous êtes redevable de NULL € suite à notre prestation facturée le NULL référence #WARNING.



Nous vous remercions de procéder, W. WARNING WARNING au règlement de cette facture avant le NULL prochain.



WARNING WARNING, responsable clientèle.

votre avatar

“un groupe d’étudiants allemandes” ?????&nbsp;&nbsp;Je dirais plutôt “un groupe d’étudiants allemands”

&nbsp;Et j’aimerais tant :&nbsp;“un groupe d’étudiantes allemandes” &nbsp;<img data-src=" />

&nbsp;Plaisanterie à part, sécurisez vos accès web, VNC, ssh et encore plus vos bases de données, SVP pensez au bien de l’humanité !&nbsp;<img data-src=" />

votre avatar

un tout petit peux plus compliqué

https://docs.mongodb.com/manual/security/

/usr/local/etc/mongodb.conf

votre avatar

Il y avait eut un article de nextinpact il y a presque 2 ans sur le sujet :

&nbsp;

nextinpact.com Next INpactFaut croire que ça n’a pas servi de leçon aux admins …

votre avatar

Ce qui est dingue au final, c’est que l’équipe de MongoDB, dans ses premières versions, n’a jamais fait le moindre effort pour sécuriser à minima une fresh install.

votre avatar







Rokin a écrit :



Une configuration MongoLienne.



Je suis deja loin…





Propositon de changement de nom: MongolitoDB!

<img data-src=" />


votre avatar







Jarodd a écrit :



Ma conf par défaut avait déjà cette config mais merci pour la piqûre de rapel&nbsp; <img data-src=" />





<img data-src=" />



Skywa a écrit :



Il y avait eut un article de nextinpact il y a presque 2 ans sur le sujet :

&nbsp;

nextinpact.com Next INpactFaut croire que ça n’a pas servi de leçon aux admins …





Quand tu penses que ce n’est quelques minutes de conf&nbsp;<img data-src=" />


votre avatar

il est également conseillé de configurer firewallé le trafic sur le port 27017

&nbsp;



&nbsp; :prof:
votre avatar

Avec un simple tuto bien fait , super simple pour mettre en place la base … et ruleZZZZZ !

votre avatar







ledufakademy a écrit :



Avec un simple tuto bien fait , super simple pour mettre en place la base … et ruleZZZZZ !





pour ça faut un back up… je prends le pari que beaucoup d’entre eux n’en ont pas&nbsp;<img data-src=" />


votre avatar

Bah justement, pour beaucoup de serveurs c’est pas admins sys qui les montent mais des gens qui croient s’y connaître en la matière.

&nbsp;

J’ai fait des audits sur des solutions hébergées de ce type pendant plusieurs mois et c’est assez inimaginable le nombre de machines pas configurées que j’ai pas trouvé : pas de mises à jour, pas de sauvegarde, login par défaut sur les interfaces d’admins, etc.

votre avatar







boogieplayer a écrit :



pour ça faut un back up… je prends le pari que beaucoup d’entre eux n’en ont pas&nbsp;<img data-src=" />





Tu peux justement acheter des backups… à 0.2 bt. <img data-src=" />


votre avatar

eh oui les économies …

votre avatar







Ricard a écrit :



Tu peux justement acheter des backups… à 0.2 bt. <img data-src=" />





t’es con&nbsp;<img data-src=" />


votre avatar

Tu as trouvé beaucoup de cas (d’entreprise) ou aucun backup n’est prévu ? Une erreur de conf, ça arrive facilement, mais ne pas prévoir de backup là ça relève de la faute professionnel.&nbsp;

votre avatar







boogieplayer a écrit :



Ouep, ça craint.

C’est un peu la même chose pour MySQL ou MariaDB, sur linux famille debian/ubuntu







Non, pas tout à fait, ça fait longtemps que les install par défaut de Mysql sont complètement fermées pour les accès extérieurs.

Pour Mongo, c’est encore ouvert et c’est débile…









AlexKevler a écrit :



Ce qui est dingue au final, c’est que l’équipe de MongoDB, dans ses premières versions, n’a jamais fait le moindre effort pour sécuriser à minima une fresh install.







C’est un peu toujours le cas : y’a toujours pas d’authentification par défaut par exemple…

Les mecs se sont dit : “on fait une base, l’auth, le chiffrage et la sécurité, on laisse ça au système”. OK, sauf que la moitié des mecs qui installent ce genre de trucs sont des devs neuneu sans aucune notion de système et de sécurité qui ne font que suivre des “tutos” faits par d’autres neuneus qui en savent pas plus qu’eux…

Et quand ils arrivent à faire tomber leur bazar en marche, ils lèvent les mains et ne touchent surtout plus à rien…







yulpocket a écrit :



Bah justement, pour beaucoup de serveurs c’est pas admins sys qui les montent mais des gens qui croient s’y connaître en la matière.







Exactement…


votre avatar







t0FF a écrit :



Tu as trouvé beaucoup de cas (d’entreprise) ou aucun backup n’est prévu ? Une erreur de conf, ça arrive facilement, mais ne pas prévoir de backup là ça relève de la faute professionnel.







Bah, tu serais surpris de la situation des sauvegardes dans les entreprises… et quand y’en a, y’a aucune garantie qu’ils fonctionnent ni même qu’ils sont faits sur les bonnes données.

Alors je te raconte pas la situation sur le web, c’est encore pire…


votre avatar







ledufakademy a écrit :



Avec un simple tuto bien fait , super simple pour mettre en place la base … et ruleZZZZZ !







Tout le problème est dans le “bien fait”.

Or, un noob ne sait pas faire la différence entre un tuto “bien fait” et un “mal fait”. Et bien souvent, les tutos “bien faits” sont longs et un peu chiants à lire donc ils sont zappés et on part sur un petit tuto court et rapide mais qui n’aborde pas la sécurité, les backups et tous les trucs “chiants” justement…



Et pis pour pleins de noobs, on part d’une petite maquette rapide et ça finit en prod sans être touché pendant 2 ans jusqu’au 1er incident où on se dit “oups ! où sont les backups ? comment je récupère des données dans cette base toute bousillée ?, etc”


votre avatar

J’ai même envie de dire, que si la bdd est accessible sans auth, il y a peu de chance d’avoir des backups dans cette entreprise <img data-src=" />



Et pour celles qui en auraient, je parie qu’une partie a ecrasé la sauvegarde sans versionning avec la version déjà piratée de la base avant de s’en rendre compte <img data-src=" />

votre avatar

Oui c’est vrai que j’ai zappé un peu cet aspect, en mutu tout est géré par l’hébergeur alors qu’un dédié c’est toi qui t’en occupe.

votre avatar







KP2 a écrit :



Ca, c’est valable pour les sites qui tournent sur des mutus… Pour les sites qui tournent sur des dédiés ou des VPS, c’est pas la même…



Et avec l’arrivée de Docker un peu partout, ça va être encore pire au niveau sécurité. Pas à cause de Docker lui-même (que j’apprécie beaucoup pour info) mais parce que plein de tutos font l’éloge du déploiement en 1 commande mais personne ne parle comment sécuriser la tuyauterie, personne se pose la question de ce qu’il y a dans les images du Hub, personne se pose la question de la conf par défaut des trucs déployés, etc etc etc

Bref, avec Docker, y’a plein de noob qui vont se mettre à déployer des archi micro-services avec des dizaines ou des centaines de containers sans aucune sécurité car il faudrait passer un temps fou à checker et corriger tout service par service… Ca va être un beau bordel…







+1000


votre avatar







renaud07 a écrit :



Oui c’est vrai que j’ai zappé un peu cet aspect, en mutu tout est géré par l’hébergeur alors qu’un dédié c’est toi qui t’en occupe.







Quel que soit le type d’hébergement, si vous tenez à vos données ne partez jamais du principe que les autres font leur travail.



Faites vos propres sauvegardes et surtout, vérifiez les. L’expérience montre qu’on n’est jamais trop prudent.


votre avatar







KP2 a écrit :



Ca, c’est valable pour les sites qui tournent sur des mutus… Pour les sites qui tournent sur des dédiés ou des VPS, c’est pas la même…



Et avec l’arrivée de Docker un peu partout, ça va être encore pire au niveau sécurité. Pas à cause de Docker lui-même (que j’apprécie beaucoup pour info) mais parce que plein de tutos font l’éloge du déploiement en 1 commande mais personne ne parle comment sécuriser la tuyauterie, personne se pose la question de ce qu’il y a dans les images du Hub, personne se pose la question de la conf par défaut des trucs déployés, etc etc etc

Bref, avec Docker, y’a plein de noob qui vont se mettre à déployer des archi micro-services avec des dizaines ou des centaines de containers sans aucune sécurité car il faudrait passer un temps fou à checker et corriger tout service par service… Ca va être un beau bordel…





+1


votre avatar







sr17 a écrit :



Quel que soit le type d’hébergement, si vous tenez à vos données ne partez jamais du principe que les autres font leur travail.



Faites vos propres sauvegardes et surtout, vérifiez les. L’expérience montre qu’on n’est jamais trop prudent.





+10


votre avatar

T’en es à 11, Ricards. Ça fait un peu beaucoup.

Allez, c’est la mienne!

<img data-src=" />

votre avatar







KP2 a écrit :



Tout le problème est dans le “bien fait”.

Or, un noob ne sait pas faire la différence entre un tuto “bien fait” et un “mal fait”. Et bien souvent, les tutos “bien faits” sont longs et un peu chiants à lire donc ils sont zappés et on part sur un petit tuto court et rapide mais qui n’aborde pas la sécurité, les backups et tous les trucs “chiants” justement…



Et pis pour pleins de noobs, on part d’une petite maquette rapide et ça finit en prod sans être touché pendant 2 ans jusqu’au 1er incident où on se dit “oups ! où sont les backups ? comment je récupère des données dans cette base toute bousillée ?, etc”





Tout à fait d’accord. Et malheureusement, beaucoup de noob sont sur le marché.



La différence entre un sysadmin et un bon sysadmin, c’est la source d’information.



Passé le “quick start” pour setup quelquechose en 5mn et tester vite fait, il faut passer par se taper les heures de lecture de documentation fourni par l’éditeur.



Je prends un exemple criant de vérité, ElasticSearch. Monter un cluster, dans tout les “tuto” sur le net, ca prend 1mn =&gt; yum install elasticsearch sur N noeud. C’est tout beau, tout magique, tes serveurs communiquent en eux en multicast, la conf vide par défaut fonctionne. Et voilà…

Mais en fait non… quand tu commences à lire la doc, tu te rends compte que c’est pas du tout production ready. Mais je suis persuadé que beaucoup se contente de copier/coller des “tuto” de site sans rien comprendre à ce qu’ils font.


votre avatar







barlav a écrit :



T’en es à 11, Ricards. Ça fait un peu beaucoup.

Allez, c’est la mienne!

<img data-src=" />





<img data-src=" />


votre avatar







ForceRouge a écrit :



Tout à fait d’accord. Et malheureusement, beaucoup de noob sont sur le marché.



La différence entre un sysadmin et un bon sysadmin, c’est la source d’information.



Passé le “quick start” pour setup quelquechose en 5mn et tester vite fait, il faut passer par se taper les heures de lecture de documentation fourni par l’éditeur.



Je prends un exemple criant de vérité, ElasticSearch. Monter un cluster, dans tout les “tuto” sur le net, ca prend 1mn =&gt; yum install elasticsearch sur N noeud. C’est tout beau, tout magique, tes serveurs communiquent en eux en multicast, la conf vide par défaut fonctionne. Et voilà…

Mais en fait non… quand tu commences à lire la doc, tu te rends compte que c’est pas du tout production ready. Mais je suis persuadé que beaucoup se contente de copier/coller des “tuto” de site sans rien comprendre à ce qu’ils font.





+100


votre avatar

<img data-src=" />

ca va?

Allez, viens, on va te ramener.

votre avatar







barlav a écrit :



<img data-src=" />

ca va?

Allez, viens, on va te ramener.





+1000 <img data-src=" />


votre avatar







KP2 a écrit :



Non, il a raison…

Par défaut, l’authentification devrait être active, un mot de passe admin demandé à l’install et avec aucun binding ou un binding sur localhost.

Or, c’est pas du tout comme ça… c’est openbar par défaut et les doc officielles ont une petite ligne à la fin dans le QuickStart Guide : “oubliez pas de sécuriser votre install”

Ah.





+1, j’ai toujours trouvé surréaliste que les install de bdd / services web ou autres ne soient pas sécurisées par défaut.



Et +1 également pour les services déployés avec des conteneurs, ça promet de joyeux moments …


votre avatar







yulpocket a écrit :



Réponse véridique que j’ai eu de la part d’un des audités à qui je demandais quelle politique de sauvegarde il avait mis en place. Je l’interrogeai sur la politique de rétention et les emplacements des backups.



Par décence, je ne ferai pas un copier coller de la réponse mais globalement Il m’a répondu qu’il n’y en avait pas mais qu’on avait rien à craindre car on était dans le cloud OVH et que le serveur loué était en RAID.

Il m’a précisé que cependant il faisait un export de base avant des grosses MAJ. Quand je lui ai demandé comment il les faisait, il m’a dit qu’il utilisait phpmyadmin. En grattant, c’était en http et le mot de passe était d’un niveau que je qualifierai de très amateur.

La boîte qui fait çà est à la base une agence Web d’une quinzaine de personnes et le produit en question était utilisé par une quarantaine de personnes comme outil métier assez critique. Comme l’a fait remarqué dufakeacademy, aussi invraisemblable que cela puisse paraître, ils n’ont pas d’admin, c’est un développeur qui s’occupe de monter les serveurs par ce que c’est “facile”

Et ce n’est malheureusement qu’une de mes nombreuses expériences en la matière, je pourrai en écrire un bouquin…..







T’inquiète, les devops (20% dev, 20% ops, 60% de je sais pas ce que je fou) sauveront le monde :)



Quant à Mongodb, le problème c’est qu’il sert de bdd embeded dans plein de soft. Et pas forcement le Mongodb livré avec la distrib. Donc conf en dure pas forcement sécurisé, binaire jamais à jour, …


votre avatar

Sur Sql server par défaut les connexions distantes sont bloqués en fait les ports ne sont pas ouvert et les protocoles genre tcp désactivé. Il faut passer par l’utilitaire de conf pour changer ce qui va bien pour avoir l’accès à distance avec obligatoirement un user/password.

votre avatar

C’est quoi ces admin système en carton ?

votre avatar

Pas sûr que ce soit des admin système…

votre avatar

  • 10 000.

    Bon on commence tous par un tuto (oui c’est un des moments le plus fun !)… mais ensuite il y a l’expérience et le métier … de la prod justement ! (design, test, maquette, redaction, pilote, mise en pro, maintenance , rextex etc ….)

    Moi ca fait plus de 25 ans … lol.

votre avatar







KP2 a écrit :



Ou pire : “quoi ? un snapshot, ça suffit pas pour backup une base de données ?”







Ou l’inverse : “on ne peut pas TOUT sauvegarder tous les jours, et tout conserver ?”

Les politiques de sauvegardes/Arcivages/conservation : le combat éternel, film d’horreur <img data-src=" />









KP2 a écrit :



Et avec l’arrivée de Docker un peu partout, ça va être encore pire au niveau sécurité. (…) Ca va être un beau bordel…







Mais clair. Je viens tout juste de tenter l’expérience pour me monter un petit environnement de dev LAMP sous Windows 10. Le coté “magique” de Docker est dans tous les tuto… c’est vrai que c’est cool, mais c’est un coup à avoir tout en accès libre facilement ce truc… Et même si la doc Docker est bien fournie, je la trouve un peu fouille parfois avec des termes qui se chevauchent un peu (les volumes par exemple).







yulpocket a écrit :



Réponse véridique que j’ai eu de la part d’un des audités à qui je demandais quelle politique de sauvegarde il avait mis en place. Je l’interrogeai sur la politique de rétention et les emplacements des backups.



Par décence, je ne ferai pas un copier coller de la réponse mais globalement Il m’a répondu qu’il n’y en avait pas mais qu’on avait rien à craindre car on était dans le cloud OVH et que le serveur loué était en RAID.

Il m’a précisé que cependant il faisait un export de base avant des grosses MAJ. Quand je lui ai demandé comment il les faisait, il m’a dit qu’il utilisait phpmyadmin. En grattant, c’était en http et le mot de passe était d’un niveau que je qualifierai de très amateur.

La boîte qui fait çà est à la base une agence Web d’une quinzaine de personnes et le produit en question était utilisé par une quarantaine de personnes comme outil métier assez critique. Comme l’a fait remarqué dufakeacademy, aussi invraisemblable que cela puisse paraître, ils n’ont pas d’admin, c’est un développeur qui s’occupe de monter les serveurs par ce que c’est “facile”

Et ce n’est malheureusement qu’une de mes nombreuses expériences en la matière, je pourrai en écrire un bouquin…..







Un classique, malheureusement.







sr17 a écrit :



Quel que soit le type d’hébergement, si vous tenez à vos données ne partez jamais du principe que les autres font leur travail.



Faites vos propres sauvegardes et surtout, vérifiez les. L’expérience montre qu’on n’est jamais trop prudent.







+1


votre avatar

C’est pas des admins système.



C’est une floppée de webdevs front à qui des malades ont promis des technos backend adaptées à leur niveau.

votre avatar







KP2 a écrit :



[…]personne ne parle comment sécuriser la tuyauterie, personne se pose la question de ce qu’il y a dans les images du Hub, personne se pose la question de la conf par défaut des trucs déployés, etc etc etc

Bref, avec Docker, y’a plein de noob qui vont se mettre à déployer des archi micro-services avec des dizaines ou des centaines de containers sans aucune sécurité car il faudrait passer un temps fou à checker et corriger tout service par service… Ca va être un beau bordel…





Bah quand t’es dans une grosse structure, ça inquiète les OPS et du coup il se retrouvent à faire les configs qu’ils faisaient avant sur les VM/machines, dans les docker, ça change pas grand chose.



Pour les “indépendants” (mec en pyjama chez lui, TPE,…) ça existait avant des “prods” qui tournent sur un wamp configuré à l’arrache sur un vieux pc que la femme de ménage débranche pour passer l’aspirateur.

&nbsp;Ou des mecs qui choisissent une librairie trouée de partout que personne utilise.

&nbsp;Est ce que ça va être pire qu’avant ? Peu être …



&nbsp;Ya un avantage à docker, c’est que tu peux tomber sur une image bien configurée. Du coup sur un malentendu tu te retrouves avec plus de sécurité qu’avant, ça compense peut être partiellement le “pire” ^^


votre avatar







RomRomRomRom a écrit :



Ya un avantage à docker, c’est que tu peux tomber sur une image bien configurée. Du coup sur un malentendu tu te retrouves avec plus de sécurité qu’avant, ça compense peut être partiellement le “pire” ^^







HAHAHAHA <img data-src=" />


Des centaines de bases MongoDB attaquées à cause de mauvaises configurations

  • Un vol de données contre une petite rançon en bitcoin

  • Une sécurité qui ne préoccupe pas assez

  • Quelques conseils simples de vérification et de protection

Fermer