Ransomware :  pris à la gorge, un hébergeur coréen débourse un million de dollars

Ransomware :  pris à la gorge, un hébergeur coréen débourse un million de dollars

To pay or not to pay

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

21/06/2017 7 minutes
60

Ransomware :  pris à la gorge, un hébergeur coréen débourse un million de dollars

En Corée du Sud, une entreprise s’est vue contrainte de payer plus d’un million de dollars de rançon. Ses serveurs, infectés par le ransomware Erebus, hébergeaient les données de nombreux clients. Un cas qui rappelle encore les dangers de ce type de malware, ainsi que l’importance des mises à jour.

Un ransomware est pour rappel un logiciel malveillant dont la finalité est d’obtenir une rançon. Pour y parvenir, la technique employée est toujours la même : chiffrer les données de la machine et menacer l’utilisateur de ne plus jamais y avoir accès s’il ne s’acquitte pas de la somme demandée. Celle-ci est presque toujours exigée en crypto-monnaie, le plus souvent en bitcoins.

Pour autant, la « qualité » et la dangerosité des ransomwares varient. Parfois, des failles dans leur code permettent de créer un logiciel capable de redonner accès aux données, comme on l’a vu avec WannaCrypt. Mais Erebus, qui a infecté la société coréenne Nayana, n’en a a priori aucune exploitable.

De très vieux composants, un nombre élevé de failles potentielles

Comme indiqué par Trend Micro, le ransomware Erebus n’est pas nouveau. On le trouvait déjà l’année dernière, exploitant diverses failles de sécurité selon l’époque, dont certaines dans le lecteur Flash.

Dans le cas présent, on ne sait pas réellement comment il s’est infiltré dans Nayana. Cependant, comme relevé par la société de sécurité, il est fort probable que là encore, des vulnérabilités aient été exploitées. Pourquoi ? Parce que la société coréenne, qui officie dans l’hébergement web, utilisaient des composants logiciels particulièrement anciens.

Les serveurs eux-mêmes utilisaient ainsi une vieille distribution Linux dont le kernel était en version 2.6.24.2, vieille de plusieurs années. Considérant la vitesse à laquelle sont découvertes les failles, il en existait nécessairement que les pirates pouvaient utiliser.

Les soucis détectés ne s’arrêtent pas là. Les versions utilisées d’Apache et PHP pour le site principal de Nayana étaient respectivement les 1.3.36 et 5.1.4, toutes deux datent de 2006. L’analyse est ici la même : plus de dix ans se sont écoulés depuis et les failles de sécurité à disposition des pirates étaient probablement nombreuses.

Un fonctionnement impitoyable

Une fois en place, Erebus n’avait qu’à remplir sa mission. Documents, archives, bases de données et autres fichiers multimédias étaient ainsi passés à la moulinette du malware, qui les renommait ensuite avec l’extension .ecrypt. En tout, 433 formats sont pris en charge.

Erebus fait partie de ce type de malware qui utilise plusieurs algorithmes différents et un découpage de fichier en plusieurs couches. Au-delà de son entête, on trouve ainsi le contenu du fichier chiffré en RC4 et divisé en blocs de 500 ko, tandis que le nom dudit fichier est lui chiffré en RSA-2048. Le résultat final, en .ecrypt, contient la clé RC4, différente pour chaque fichier. Cependant, elle est chiffrée une première fois en AES, puis une seconde en RSA-2048.

Il s’agit en fait de la clé privée. La clé publique en RSA-2048 est de son côté partagée. Selon Trend Micro, un tel fonctionnement rend impossible tout décryptage des données sans posséder la clé. Ce qui amène immanquablement la question de la rançon.

Une rançon très élevée, qui ne doit pas faire des émules

Conscients probablement que leur malware ne pouvait être contourné et que la victime manipulait les données de nombreux clients (153 serveurs infectés pour un total de plus de 3 400 sites commerciaux), les pirates ont réclamé une rançon salée.

Nayana, qui raconte elle-même ses mésaventures dans une série de notes sur son propre site, indique ainsi que la somme demandée initialement était de 550 bitcoins, soit l’équivalent d’environ 1,6 million de dollars.  L’entreprise ajoute qu’elle a cherché à négocier cette rançon, ce que les pirates ont accepté. Résultat, la somme est descendue à 397,6 bitcoins, soit environ un million de dollars, réglables en trois fois.

Le 17 juin, soit il y a trois jours seulement, Nayana indiquait que le deuxième des trois paiements avait été fait. La logique des pirates est simple : chacun permet de retrouver l’accès à un tiers des installations. Le 18 juin, la société déclarait redémarrer ses serveurs par groupes, mais des problèmes se manifestaient dans le deuxième lot de machines libérées d’Erebus. Le dernier paiement ne doit être fait que lorsque les deux premiers tiers des machines seront opérationnels.

Un véritable cas d’école

L’exemple de Nayana synthétise à lui seul tout ce que l’on peut dire d’un ransomware et les problématiques qu’il pose, tant aux victimes qu’aux experts en sécurité.

Les ransomwares peuvent être utilisés de plusieurs manières. Le cas le plus courant est celui d’un logiciel malveillant infectant une machine unique et réclamant une rançon à un utilisateur « simple ». Une petite somme, mais répétée autant de fois que possible. Au contraire, un ransomware peut viser des machines moins fréquentes, mais à l’impact plus important.

Comme on l’a vu au début du mois, des milliers de bases de données sont contaminées ou potentiellement vulnérables à de tels malwares. Puisque les entreprises visées stockent potentiellement des données sensibles et/ou appartenant à des clients, en retrouver l’accès peut faire la différence entre une survie et un dépôt de bilan. Dès lors, comment suivre la recommandation officielle qui est, le plus souvent, de ne pas payer la rançon ?

La question revient perpétuellement, se posant à chaque nouvelle victime. Dans le cas de Nayana cependant, elle constitue une dure leçon sur la nécessité absolue de n’utiliser que des composants logiciels parfaitement à jour. Les vulnérabilités, comme on a pu le voir de nombreuses fois depuis les révélations Snowden, font l’objet d’un véritable trafic. Elles sont ainsi vendues comme cyberarmes dans des marchés noirs et gris, le FBI et l’armée américaine n’hésitant pas par exemple à en acheter, particulièrement celles de type 0-day.

Le brutal chemin vers la sécurité

Le simple fait d’installer les mises à jour de sécurité n’est par ailleurs pas une garantie de protection. Par définition, les patchs ne colmatent que les brèches dont les éditeurs sont au courant. Ces mises à jour doivent donc être accompagnées de mesures d’hygiène informatique, toujours les mêmes : sauvegarde des fichiers, suppression de tout composant ou logiciel qui n’est pas utilisé, n’attribuer que le moins de privilèges possibles à chaque utilisateur, surveiller les fichiers journaux et ainsi de suite. Trend Micro en liste d’ailleurs une série à la fin de son billet.

Il est probable que les entreprises finiront par s’adapter petit à petit à ce type de menace en faisant évoluer leurs règles, quand ce n’est pas déjà le cas. Signe qui ne trompe pas, les éditeurs de solutions de sécurité tablent de plus en plus sur des solutions qui vont bien au-delà du simple antivirus, en renforçant leurs offres d’apprentissage profond et de surveillance distante. Mais au vu des cas que l’on peut voir encore en 2017, un constat s’impose : la route vers la sécurité aura été apprise par beaucoup de manière bien brutale. 

60

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

De très vieux composants, un nombre élevé de failles potentielles

Un fonctionnement impitoyable

Une rançon très élevée, qui ne doit pas faire des émules

Un véritable cas d’école

Le brutal chemin vers la sécurité

Commentaires (60)


Mais cela prend combien de temps pour faire autant de dégats ?

Je ne comprend pas le fait qu’on ne remette pas en ligne une version de sauvegarde non polluée.

Ou alors on n’a pas de sauvegarde ?

c’est une vraie question !


Si je comprends bien, l’hébergeur a cumulé une dette technique d’un million de dollars au cours des dix dernières années. De quoi financer deux administrateurs système à temps plein.


Une solution à développer pour peut-être limiter la casse : bloquer l’accès par application et par utilisateur avec des autorisations très spécifiques (clefs d’accès…). Les fichiers ne pourraient plus être modifiés par n’importe qui, n’importe quoi ou n’importe comment.


Et tout simplement faire de vrais sauvegardes (sur bandes) avec un durée de rétention suffisante ?  Non ? Personnes ? A croire que ça n’effleure même pas l’esprit des gens. Désespérant.








Sans intérêt a écrit :



Si je comprends bien, l’hébergeur a cumulé une dette technique d’un million de dollars au cours des dix dernières années. De quoi financer deux administrateurs système à temps plein.







Bien plus que ça car il faut aussi prendre en compte le cout de remise à niveau









Hoper a écrit :



Et tout simplement faire de vrais sauvegardes (sur bandes) avec un durée de rétention suffisante ?  Non ? Personnes ? A croire que ça n’effleure même pas l’esprit des gens. Désespérant.







Des backup sur bande ? en 2017 ?



Je ne suis pas certain qu’on puisse encore appeler cela “des vraies sauvegardes” . <img data-src=" />



[troll]

Tient bizarre sur cette news on verra personne dire que Linux c’est plus mieux trop bien parce que c’est impossible à pirater.

[/troll]



Dette de 10 ans de mise à jour de sécurité… La ou je bosse (plus ou moins le même domaine), on est à jour niveau sécurité dans la semaine (voir la journée) pour la plupart des serveurs, pour les postes utilisateurs c’est la méthode “pas le choix” (comme ce que fait Microsoft au final) quelque soit l’os.



Pour ceux qui parlent de sauvegarde erebus installe bien avant son exécution (plusieurs semaines voir mois) un driver Bluetooth qui est exécuté dès le lancement de l’os. bien sur tu as la solution si les disques ne sont pas chiffrés de monter le disque sur une autre machine pour le lire mais quel en serait le coup ? a mon avis s’ils ont des milliers de serveurs le coup dépasserait facilement le million.



Et pour finir, maintenir apache à jour va être de pus en plus crucial apache a de nombreuses failles permettant d’escalader de shell à root (voir il tourne toujours en root), cela va certainement être l’une des cibles de choix des prochains mois.


Vu l’ancienneté de leurs systèmes, il y a fort a parier que des failles d’élévation de privilège étaient disponibles.



Comme dit précédemment, au delà d’avoir des systèmes à jour, c’est un système de backup efficace qui aurait du être mis en place.


Cela se fait tjs ,hein ….en plus d’un serveur de sauvegarde, etc….








127.0.0.1 a écrit :



Des backup sur bande ? en 2017 ?



Je ne suis pas certain qu’on puisse encore appeler cela “des vraies sauvegardes” . <img data-src=" />





Je t’invite à aller visiter des datacenters. ;)



C’est toujours très utilisé étant donné le ratio espace de stockage / prix.

Et ça reste lent d’accès en lecture vu que c’est du séquentiel, mais c’est fait pour du backup donc parfait.

Ce qui a besoin d’être accédé rapidement est mis en “cache” sur disque durs.



Les bandes sont toujours une bonne solution.








127.0.0.1 a écrit :



Des backup sur bande ? en 2017 ?



Je ne suis pas certain qu’on puisse encore appeler cela “des vraies sauvegardes” . <img data-src=" />





Aussi surprenant que ça puisse paraître, c’est le choix qu’a fait le CERN pour stocker les données de son collisionneur haute vitesse.



Le problème c’est que l’hébergeur va retrouver ses données, mais il risque de perdre ses clients. Voire se prendre des procès…



J’espère au moins que cela lui servira de leçon, et qu’à l’avenir il fera des sauvegardes et qu’il mettra à jour. En même temps ce n’est pas ce que j’appelle un professionnel s’il utilise des versions vieilles de 10 ans… <img data-src=" />








Jarodd a écrit :



Le problème c’est que l’hébergeur va retrouver ses données, mais il risque de perdre ses clients. Voire se prendre des procès…



J’espère au moins que cela lui servira de leçon, et qu’à l’avenir il fera des sauvegardes et qu’il mettra à jour. En même temps ce n’est pas ce que j’appelle un professionnel s’il utilise des versions vieilles de 10 ans… <img data-src=" />





c’est l’éternelle rengaine du “pourquoi changer si ça marche”, combinée à “on a toujours fait comme ça” <img data-src=" />



[HS]

Justement j’ai refusé ce matin un job de développeur, où on me proposait une évolution jusqu’au poste de CTO, sauf que le boss fait tourner ses applis sur un vieux framework (sorti en 2006, qui a connu 2 nouvelles versions majeures depuis). J’ai demandé s’il souhaitait migrer à l’avenir, il me répond “oh non ça tourne bien ainsi, j’ai pas d’argent et de temps à perdre pour ça, il faut me montrer par a+b ce que ça apporte de migrer”. Il n’a pas compris pouquoi je refusais le poste, pourtant c’est sympa de faire CTO sur une stack technique antique et qui n’évolue pas <img data-src=" /> Donc j’attends qu’il se fasse hacker, et je lui reproposerai mes services avec une petite majoration de mon tarif <img data-src=" />

[/HS]


C’est aussi très résistant, facile à déplacer au besoin et ça se range bien dans les coffres, notamment quand il y a besoin d’archivage longue durée.



Pas de problème de foudroyage électrique, le media n’est pas sensible a une attaque virus via le réseau vu qu’il est complétement détaché et inaccessible.


Prend les devants et hack le (si tu en as la capacité et sans faire de dégât irréparable <img data-src=" />)



“Voilà la preuve”.









127.0.0.1 a écrit :



Des backup sur bande ? en 2017 ?



Je ne suis pas certain qu’on puisse encore appeler cela “des vraies sauvegardes” . <img data-src=" />







Et pourtant, c’est très fiable.



Tu « attends » qu’il se fasse hacker ? <img data-src=" />








Jarodd a écrit :



Le problème c’est que l’hébergeur va retrouver ses données, mais il risque de perdre ses clients. Voire se prendre des procès…



J’espère au moins que cela lui servira de leçon, et qu’à l’avenir il fera des sauvegardes et qu’il mettra à jour. En même temps ce n’est pas ce que j’appelle un professionnel s’il utilise des versions vieilles de 10 ans… <img data-src=" />







+1. La perte de client et l’image de marque risque de couter beaucoup plus cher qu’un million.<img data-src=" />



Sans parler de la fiabilité… Les bandes pro (LTO etc) sont beaucoup, beaucoup plus fiables dans le temps que les disques durs. Et je parle même pas des supports WORM.








Jarodd a écrit :



[HS]

Justement j’ai refusé ce matin un job de développeur, où on me proposait une évolution jusqu’au poste de CTO, sauf que le boss fait tourner ses applis sur un vieux framework (sorti en 2006, qui a connu 2 nouvelles versions majeures depuis). J’ai demandé s’il souhaitait migrer à l’avenir, il me répond “oh non ça tourne bien ainsi, j’ai pas d’argent et de temps à perdre pour ça, il faut me montrer par a+b ce que ça apporte de migrer”. Il n’a pas compris pouquoi je refusais le poste, pourtant c’est sympa de faire CTO sur une stack technique antique et qui n’évolue pas <img data-src=" /> Donc j’attends qu’il se fasse hacker, et je lui reproposerai mes services avec une petite majoration de mon tarif <img data-src=" />

[/HS]





pas con!!!

tu vas le pirater et ensuite tu lui renvoies un CV!



<img data-src=" />





Les serveurs eux-mêmes utilisaient ainsi une vieille distribution Linux dont le kernel était en version 2.6.24.2, vieille de plusieurs années. Considérant la vitesse à laquelle sont découvertes les failles, il en existait nécessairement que les pirates pouvaient utiliser.



&nbsp;Fake ! Y a pas de virus sur Linux, c’est internet qui l’a dit.

&nbsp;News putaclick avec contenu bidon&nbsp;<img data-src=" />



&nbsp;<img data-src=" />


Ah oui, moi je corrige les problèmes, je ne les cause pas (enfin, pas volontairement <img data-src=" /> <img data-src=" />)




Les serveurs eux-mêmes utilisaient ainsi une vieille distribution Linux dont le kernel était en version 2.6.24.2, vieille de plusieurs années.

Les soucis détectés ne s’arrêtent pas là. Les versions utilisées d’Apache et PHP pour le site principal de Nayana étaient respectivement les 1.3.36 et 5.1.4, toutes deux datent de 2006.



Non mais sérieux…

J’aurais augmenté la rançon rien que pour ça

<img data-src=" />


C’est tellement désespérant que c’en est à se flinguer

Ce qu’ils ont fait

<img data-src=" />








XMalek a écrit :



Pour ceux qui parlent de sauvegarde erebus installe bien avant son exécution (plusieurs semaines voir mois) un driver Bluetooth qui est exécuté dès le lancement de l’os. bien sur tu as la solution si les disques ne sont pas chiffrés de monter le disque sur une autre machine pour le lire mais quel en serait le coup ? a mon avis s’ils ont des milliers de serveurs le coup dépasserait facilement le million.



Normalement, on essaye de faire le ménage avant de remettre la sauvegarde (surtout si on connait l’infection). On s’est pris une belle merde de ransomware au taff (pas Erebus), on a passé du temps à bien nettoyer, colmater la faille avant de remettre les bandes. Ah, une bonne vieille bande ou on peut désactiver l’écriture (si, si, cela sert toujours et c’est efficace). Bon c’est sur on a que 3 serveurs et pas 153. Moi ce qui me sidère dans l’histoire outre le fait d’avoir un système aussi ancien sans mise à jour c’est la négociation et en prime en 3 fois sans frais. C’est dingue, cette impunité, c’est au delà du réel…



Non : Les bandes sont toujours la solution à long terme ;)


Ouh putain, ca fait longtemps que j’avais pas entendu son nom à celui là&nbsp;<img data-src=" />








Jarodd a écrit :



[HS]

Justement j’ai refusé ce matin un job de développeur, où on me proposait une évolution jusqu’au poste de CTO, sauf que le boss fait tourner ses applis sur un vieux framework (sorti en 2006, qui a connu 2 nouvelles versions majeures depuis). J’ai demandé s’il souhaitait migrer à l’avenir, il me répond “oh non ça tourne bien ainsi, j’ai pas d’argent et de temps à perdre pour ça, il faut me montrer par a+b ce que ça apporte de migrer”. Il n’a pas compris pouquoi je refusais le poste, pourtant c’est sympa de faire CTO sur une stack technique antique et qui n’évolue pas <img data-src=" /> Donc j’attends qu’il se fasse hacker, et je lui reproposerai mes services avec une petite majoration de mon tarif <img data-src=" />

[/HS]







http://www.commitstrip.com/fr/2017/06/19/security-too-expensive-try-a-hack/



😁









Jarodd a écrit :



Le problème c’est que l’hébergeur va retrouver ses données, mais il risque de perdre ses clients. Voire se prendre des procès…



J’espère au moins que cela lui servira de leçon, et qu’à l’avenir il fera des sauvegardes et qu’il mettra à jour. En même temps ce n’est pas ce que j’appelle un professionnel s’il utilise des versions vieilles de 10 ans… <img data-src=" />







Typiquement dans ce cas précis tu paies pour limiter la casse au niveau juridique par pour garder des clients dont la confiance est définitivement perdue. Donc l’avenir pour lui c’est la clé sous la porte…









XMalek a écrit :



Pour ceux qui parlent de sauvegarde erebus installe bien avant son exécution (plusieurs semaines voir mois) un driver Bluetooth qui est exécuté dès le lancement de l’os. bien sur tu as la solution si les disques ne sont pas chiffrés de monter le disque sur une autre machine pour le lire mais quel en serait le coup ? a mon avis s’ils ont des milliers de serveurs le coup dépasserait facilement le million.







En cas de panne par virus, tu ne restaures pas bêtement une image complète de ton serveur ! Jamais <img data-src=" />

Vu qu’effectivement tu ne peux savoir exactement de quand date l’attaque initiale.



Dans ces cas là, ce qui compte ce sont les DATA (users / config) : soit tu as un très vieux backup de ta machine (genere juste après son install) soit tu refais un serveur propre (et à jour donc) et tu ne restaures que les data possibles (en particulier, check des configs).

Si possible: restuaration des fichiers dans une VM avec antivirus à jour…



Et vous venez de perdre une belle place pour des motifs éthiques vaseux, comme si une plateforme moderne ou un ERP flambant neuf était la garantie d’une sécurité totale. Il n’en est rien, vous le savez.



J’ai une place depuis 17ans comme dev (je suis DSI aussi) sur un ERP écrit en BASIC qui date d’il y a 30 ans et qui roule impec sur un W2000 avec 500-1000 personnes dessus. L’ERP a zéro sécurité, chacun des employés peut effacer l’ERP (base de données, noyau) dans la minute. Le serveur n’a pas d’antivirus (incompatibilité avec l’ERP), pas de backup (juste des snapshots de la VM). Et ? Rien.

Est-ce qu’il n’est jamais rien arrivé ? Non :

· infecté par un ransomware=&gt;restaure d’un backup, 4h d’arrêt, c’est pas la fin du monde.

· répertoires déplacés par erreur=&gt;restaurés

· fichiers ouverts avec un éditeur texte (=endommagé)=&gt;réparés

Mais c’est si peu en regard de l’investissement pour le remplacer (en cours).



Quelqu’un d’autre à pris la place et en est sûrement heureux, comme moi je le suis.








Aloyse57 a écrit :



Et vous venez de perdre une belle place pour des motifs éthiques vaseux, comme si une plateforme moderne ou un ERP flambant neuf était la garantie d’une sécurité totale. Il n’en est rien, vous le savez.



J’ai une place depuis 17ans comme dev (je suis DSI aussi) sur un ERP écrit en BASIC qui date d’il y a 30 ans et qui roule impec sur un W2000 avec 500-1000 personnes dessus. L’ERP a zéro sécurité, chacun des employés peut effacer l’ERP (base de données, noyau) dans la minute. Le serveur n’a pas d’antivirus (incompatibilité avec l’ERP), pas de backup (juste des snapshots de la VM). Et ? Rien.

Est-ce qu’il n’est jamais rien arrivé ? Non :

· infecté par un ransomware=&gt;restaure d’un backup, 4h d’arrêt, c’est pas la fin du monde.

· répertoires déplacés par erreur=&gt;restaurés

· fichiers ouverts avec un éditeur texte (=endommagé)=&gt;réparés

Mais c’est si peu en regard de l’investissement pour le remplacer (en cours).



Quelqu’un d’autre à pris la place et en est sûrement heureux, comme moi je le suis.





Et les possibilités de fuites de données ? Ca ne laisse aucune trace sur le serveur ça. Alors oui, tu répondras que vous n’avez aucune donnée critique, mais je suppose qu’il y a des noms, prénoms, adresses et dates de naissances dans cet erp (donc des possibilités d’usurpation d’identité ou de hack de compte web), que si les mots de passes sont stockés avec un vieux truc genre somme MD5, il est possible de récupérer ces mots de passe et de les tester avec le compte email, dès fois qu’une personne ait pris la même chose …



En résumé, deux choses:




  1. Ce n’est pas parce que tu n’as pas eu d’attaque qu’il n’y en aura pas

  2. Ce n’est pas parce que tu n’as pas VU d’attaque qu’il n’y en a pas eu









Aloyse57 a écrit :



Et vous venez de perdre une belle place pour des motifs éthiques vaseux, comme si une plateforme moderne ou un ERP flambant neuf était la garantie d’une sécurité totale. Il n’en est rien, vous le savez.





Une plateforme moderne n’est pas la garantie d’une sécurité totale, certes. Par contre une plateforme tournant sur des systèmes et frameworks est la garantie d’une sécurité amoindrie. Cette actu en est l’exemple criant.







Aloyse57 a écrit :



Quelqu’un d’autre à pris la place et en est sûrement heureux, comme moi je le suis.



J’envie une telle boule de cristal. Sauf que j’étais le seul candidat. Le gars me faisait un pont d’or parce qu’il a pris des engagements de livraison complètement foireux (il fallait que je développe 2 API complexes en moins de 10 jours). Cette proposition d’évolution (vers le poste de CTO) n’est que de la poudre aux yeux visant à me caresser dans le sens du poil, parce qu’il était en panne de candidats, et a senti mes aspirations. Un responsable qui s’interdit par principe de faire évoluer ses outils, et n’applique même pas les mises à jours mineures de sécurité, personnellement je ne bosse pas avec lui.



Considère que c’est une éthique vaseuse, c’est ton droit. Mais je ne suis pas en recherche d’un poste dans une boite qui prend de tels risques et finira par payer cher cette désinvolture sur le sujet de la sécurité et des mises à jour. Je suis développeur, pas pompier ou voltigeur de l’extrême. Après c’est bibi qui se retrouvera au chômage parce que la boîte n’aura pas assuré le minimum de sécurité. Et on considèrera que c’était de ma responsabilité, le “je voulais mais on m’a empêché” c’est pas vendable en entretien. Et le monde pro est trop petit pour que je prenne un tel risque.



Edit : je n’ai pas précisé mais cette boite bosse avec des administrations, de gros clients, sur de l’identification et de la manipulation de documents officiels. Donc en plus des risques techniques, il y a des risques juridiques. Et c’est trop facile de donner la responsabilité d’un poste à quelqu’un et de l’interdire de prendre des mesures concrêtes pour sécuriser les données. Ce refus n’est pas écrit sur le contrat, donc ma responsabilité serait engagée.





si les mots de passes sont stockés avec un vieux truc genre somme MD5



MD5 en 1985 ? <img data-src=" /> <img data-src=" />

Sérieux, je ne vais pas m’étendre sur le chiffrage utilisé, mais quand je dis zéro sécurité, ce n’est peut-être pas tout à fait zéro, mais c’est pas loin. <img data-src=" />


“4h d’arrêt c’est pas la fin du monde”, dépend de l’impact de ton système mais si c’est potentiellement 4h de commandes perdues c’est une jolie perte sèche…



Le coup de la sécurité / SLA est exponentiel selon la criticité, la multiplicité et la taille de ton système.








Salamandar a écrit :



Non : Les bandes sont toujours la solution à long terme ;)









trOmAtism a écrit :



Les bandes sont toujours une bonne solution.









Papa Panda a écrit :



Cela se fait tjs ,hein ….en plus d’un serveur de sauvegarde, etc….









Ricard a écrit :



Et pourtant, c’est très fiable.







Je pense que vous confondez “archive” et “backup”, mais c’est pas grave… <img data-src=" />









127.0.0.1 a écrit :



Je pense que vous confondez “archive” et “backup”, mais c’est pas grave… <img data-src=" />





Absolument pas. Un “backup” EST une archive de toute façon.<img data-src=" />









Ricard a écrit :



Absolument pas. Un “backup” EST une archive de toute façon.<img data-src=" />







Heu… pas d’accord.





  • Un backup est une copie des données.

  • Une archive c’est un paquet de données conservées hors-ligne.



    Le backup doit être mis à jour lorsque les données originales sont modifiées, alors que les archives sont immuables.









127.0.0.1 a écrit :



Heu… pas d’accord.





  • Un backup est une copie des données.

  • Une archive c’est un paquet de données conservées hors-ligne.



    Le backup doit être mis à jour lorsque les données originales sont modifiées, alors que les archives sont immuables.





    Pas d’accord non plus. Dans mon ancienne boite, on faisait les backup tous les vendredi sur bandes qui étaient conservées dans une salle à part des serveurs. Tous les jours, on devait “restaurer” des fichiers bêtement effacés… Au bout d’un mois, les bandes étaient effacées.

    Les archives étaient sur un serveur distant chez un prestataire externe.

    Et puis on parlais de support. Un backup ou de l’archivage, ça ne dépend pas du support.



M’en fout, moi je fait des sauvegardes <img data-src=" />.








XMalek a écrit :



Et pour finir, maintenir apache à jour va être de pus en plus crucial apache a de nombreuses failles permettant d’escalader de shell à root (voir il tourne toujours en root), cela va certainement être l’une des cibles de choix des prochains mois.





Tu fais tourner apache en root ?! T’es sérieux ? Plus aucune distrib ne fait ça depuis au moins 15 ans.

Apache démarre en root (pour choper le port 80), puis tout de suite change de user pour prendre celui spécifié dans la config (nobody, webadmin, www-data, apache, selon la distrib).

&nbsp;









127.0.0.1 a écrit :



Je pense que vous confondez “archive” et “backup”, mais c’est pas grave… <img data-src=" />







Surement pas ce sont 2 choses qui n’ont rien à voir entre elles

On fait des backups toutes les nuits sur des “bandes” ( qui sont en fait des cartouches sur robots) .

Et les débits en écritures ou en lectures proposés par certains LTO ou Jaguar sont extrèmement impressionants




heu.. tu décris exactement ce que j’ai dit.



Le Backup c’est une copie qui sert de secours en cas de perte de l’original.

L’archive c’est la donnée originale mise hors-ligne (pour gagner de la place).


C’est très daté comme manière de faire, même pour moi.



Le backup sur bande c’était la solution des années 8090 car le stockage sur disque-dur coutait très cher, alors que les bandes beaucoup moins. Ca a été détrône un moment par les DVD-RW. Mais en 2017, le prix du stockage sur disque-dur (ou même en cloud puisque c’est la mode) a considérablement diminué.



Et puis le backup la nuit c’était pour les vieux mainframes avec des I/O poussifs et la nécessité de ne pas toucher aux fichiers pendant la copie. A présent on peut sauvegarder les donnés en journée sans pénaliser les I/O et sans empêcher les accès concurrents.


Oui, les problématiques me paraissent un peu vieilles, je ne pratique pas trop mais vive le snapshot instantané avec les nouveaux filesystems et autres archis SAN. On avait pas ces solutions à l’époque pré-web sur PC.

<img data-src=" />


méfie toi des snapshots de VM, si tu veux récupérer l’espace disque, il faut reconstruire un nouveau fichier et ça prend autant d’espace disque que la somme des snapshots. enfin c’était comme ça sous HyperV de windows 2008 en tout cas








Aloyse57 a écrit :



MD5 en 1985 ? <img data-src=" /> <img data-src=" />

Sérieux, je ne vais pas m’étendre sur le chiffrage utilisé, mais quand je dis zéro sécurité, ce n’est peut-être pas tout à fait zéro, mais c’est pas loin. <img data-src=" />





Ouais bon, j’ai mal calculé la date ^^ OK, donc c’est au mieux un XOR :p

N’empêche que le problème de fuite de données est réel, même si je suppose que le volume même des données fait que ça resterait limité



Nope , malheureusement ….



Pour ne pas les citer, un service clef de edf nucléaire …ont des saves ET des backups sur bande ….


+1 sur le résistant. Ça comprend le “résistant au temps” : environ 30 ans contre moins de 10 ans pour la flash, moins de 5 ans pour le disque dur et le CD.


Va visiter le CERN aussi (gros cas particulier). La bande est le meilleur moyen qu’ils aient trouvé pour

* Résistance au temps, attaques, etc

* Faible consommation électrique (gros hangar climatisé + robot qui va chercher les tapes)

* Bonne densité de stockage, très bonne vitesse d’écriture/lecture

* Assez bon marché

* …

Et oui, tout ça pour des backups qui sont accédés relativement régulièrement (pas trop quand même héhé)

Les résultats des expériences sont dumpées en instantanné sur RAM/SSD (chais plus trop), puis directement après sur bandes.

Sauf erreur c’est du LTO qu’ils utilisent :

https://en.wikipedia.org/wiki/Linear_Tape-Open#Generations








127.0.0.1 a écrit :



heu.. tu décris exactement ce que j’ai dit.



Le Backup c’est une copie qui sert de secours en cas de perte de l’original.

L’archive c’est la donnée originale mise hors-ligne (pour gagner de la place).







Ben sauf qu’on parlait pas de backup/archives à la base, mais de bandes magnétiques. <img data-src=" />



Chacun son opinion



Mais demande à Google pourquoi ils s’en sont sortis en février 2011 ou Amazon en 2013 … les bandes … c’est “has been” mais ça marche parce que c’est offline.



Si HP investit et vend encore beaucoup de robots et IBM des TS1150 c’est que les gros clients font la différence entre sauvegarde et continuité d’opération.



Sauvegarder quelques milliers de serveurs tous les jours ne se fait pas nécessairement sur disques.Souvent les snaps ne sont la que pour être copiés sur bande



Sauvegarder des données en live dans la journée sert plus souvent à faire de la continuité d’opération pour se protèger en cas de panne.( on fait aussi de la copie synchrone mais hélas en dessous de 30km de distance)



Mais dans le cas du ransomware,( ou d’une autre action maléfique virus ou autre ) les données copiées risquent grandement d’être inutilisables car en ligne au moment du massacre et donc affectées.



La théorie c’est sympa, mais l’incrémental live ou la log transactionelle en live ont leurs limites.



L’intégrité des données n’est pas le même combat que celui de leur présence.



De plus emmener quelques k7 de 10to ou 100to chacune à l’autre bout du pays ou à distance suffisante pour éviter une cata est plus pratique que de démonter les disques chaque jour <img data-src=" />.



Alors c’est peut-être antique ( dans le jargon :PTAM .. Pickup Truck Access Method ) mais essayer de backuper quelques centaines de téra via le réseau est compliqué en 24h même avec de gros tuyaux et garder les quelques péta pas facile sur disque ( et cher ) .



Les bandes ont encore de beaux jours devant elles à cause de leur vitesse et de leur capacité et surtout du fait qu’elles sont offline et je suis presque certain que dans le cas de notre hébergeur coréen , s’il avait eu des sauvegardes , il n’aurait pas eu à payer la rançon .

Car si on y réfléchit un erase . ( <img data-src=" /> ) aurait eu les même conséquences.



Après il faut voir le ROI d’une solution robotique adéquate.( c’est quand même pas donné) Mais toutes les grosses banques CA, BNP,SG Natexis,CE ou assurances,google, amazon,EDF, Agirc Arcco, PSA ou Renault en ont et en auront pour un bon bout de temps.



merci pour l’explication de Dette Technique

&nbsp;


Je ne pige pas.



Les bandes j’ai testé, plus jamais je veux entendre parler de cette cochonnerie, ça coute un bras, il faut une bande par jour, une bande pour une semaine, une bande pour un mois, une bande de nettoyage, changer toutes les bandes au bout d’un an, tout ça pour s’apercevoir malgré tout que lorsque la sauvegarde indique un état “OK, j’ai fini et tout s’est bien passé après 12h de sauvegarde” : on peut pas relire la bande parce que la tête à fait je ne sais quoi au dernier moment provoquant la destruction de la bande.



Non merci, une vrai sauvegarde c’est une machine séparé et dans le meilleur des cas déporté qui se connecte au moment voulu sur les serveurs à sauvegarder (et non l’inverse comme tout le monde fait) avec par exemple un système de fichier ZFS digne de ce nom…


Je te renvois au commentaire de JoePike quelques messages au dessus.



Tout est question d’échelle. Peut être que ça n’était pas adéquat à ton niveau et/ou que le matériel ne suivait pas, mais je me répète : à très gros volume c’est encore indispensable.