L’attaque contre CloudNordic et Azero (qui appartiennent au même groupe, Certiqa Holding ApS) s’est produite le 18 aout et les pirates sont entrés dans le système informatique de la société. Ils ont alors « détruit tous les systèmes », aussi bien les sites web que les messageries, selon un communiqué en danois traduit (DeepL/Google). « La majorité de nos clients ont perdu toutes leurs données chez nous », ajoute la société. La rançon était de six bitcoins (environ 150 000 euros), mais les sociétés « ne peuvent pas et ne veulent pas » la payer.
Et il ne faut malheureusement pas compter sur les sauvegardes : « Les attaquants ont réussi à chiffrer les disques de tous les serveurs, ainsi que ceux des systèmes de sauvegarde primaires et secondaires, ce qui a entraîné une panne de toutes les machines et nous avons perdu l’accès à toutes les données », toujours selon le communiqué traduit automatiquement. Seule « bonne » nouvelle, les pirates n’auraient pas récupéré les données.
S’il en était besoin, c’est l’occasion de rappeler l’importance des sauvegardes et de la manière de les gérer.
Commentaires (86)
#1
Et l’importance de ne pas se reposer entièrement sur les compétences d’un seul sous traitant pour gérer ses données et sauvegardes.
#1.1
Bah aujourd’hui, faire “confiance” a un presta unique c’est pas choquant en fonction de la taille et de l’expertise de la société (ou de l’utilisateur).
Ce qui l’est plus c’est qu’ils n’ont pas détecté le chiffrement complet des serveurs.
+1
Et pas de sauvegarde froide
Encore des utilisateurs de Linux ! Ces barbus ont ne peu rien leur confier
Bah oui, les OS troués y’en a partout ou presque. Unix/Linux/MacOS/Windows même combat
Merci CERT-FR pour ces petites notifs régulières.
Il n’a pas précisé quel OS
Qu’une boite avec un service spécialisée dans le stockage de données n’en ait pas.
#2
Un employé qui a cliqué sur une pièce jointe ?
#3
Si une seule attaque suffit à compromettre toute la prod et toutes les sauvegardes, c’est qu’à la base ils ont un gros problème…
#3.1
C’est la même réflexion que je me suis faite. Comment sauvegarder les données sur la même archi que le reste ? D’où ça se fait encore aujourd’hui ?
Il n’est pas dit que les clients n’ont plus aucunes données de leur production mais que toutes les données du data-center ont été détruites, nuance !
Certainement, que les bonnes boites avaient prévues des sauvegardes ailleurs.
#4
Déjà, il y a la sauvegarde en 3-2-1-1 à faire, par défaut (à adapter selon l’entreprise évidemment) pour les clients, d’un côté.
Mais de l’autre l’hébergeur qui se fait chiffrer l’ensemble de ses disques, incluant sauvegarde, il y a déjà un autre gros problème…
#5
Encore un coup de fsociety et dark army !
#6
Pourquoi utilise t’on encore des OS troués pour les postes de travail ?
#6.1
Parce que le problème ne vient pas de l’OS, Linux serait l’OS majoritaire qu’il y aurait les mêmes problèmes (des failles trouvées avec des utilisateurs de toute façon humains qui feront donc forcément des erreurs)
#7
#7.1
A moitié …
Quand on sait que la grande majorité des attaques se font via les utilisateurs et leur poste de travail ….
#7.2
Ok, je mords à l’hameçon : tu proposes quel OS pour les postes de travail des employés ?
#7.5
Ben comme dit précédemment, un OS où les correctifs de sécurité sont publiés plus vite que les mises à jour des bases de signatures antivirus.
Spoiler alert : Aujourd’hui, les plus réactifs sont Debian et ses dérivés (Ubuntu, KDE Neon, …)
(Android n’est pas une solution parce que obsolescence programmée, collecte des informations personnelles, failles à gogo, pomme-isation rampante … Ils ne cherchent pas à faire marcher mais à gagner de l’argent)
#7.6
Tous les OS actuels ont eu et auront des vulnérabilités 0-day. Windows, mac OS et Linux sont sur un pied d’égalité sur ce point. Et Debian les plus réactifs ? Je vois que tu as décidé de troller aujourd’hui 🤣
#7.8
Tu dis ça parce que tu n’as pas cherché …
Debian publie les correctifs le jour même ou le lendemain de la publication de la faille. Redhat publie les correctifs entre une semaine et 2 mois. Quant à MS et Apple … là, c’est la fête du slip.
(ok, on est ‘dredi, mais bon)
#7.9
Je veux bien que tu me dises qu’ils mettent le patch a disposition dans les repos dans la journée suivant sa mise à disposition par les devs du soft vulnérable. Et même là dessus j’ai de gros doutes, mais je n’ai pas été vérifier, donc admettons.
Mais même dans le monde Linux il n’y a pas toujours de patchs pour les vulnérabilités dans les 24h. Ils font comment dans ce cas chez Debian, ils font le patch eux-même ?
Toutes les vulnérabilités publiées n’ont pas de patch disponible au moment de la publication (c’est d’ailleurs ce que l’on appelle une 0-day)
#7.10
Que le correctif soit distribué à J+1 de sa publication soit… (et encore j’ai des doutes il y a toute une partie vérification pour contrôler son absence de nocivité au sein de la distri) mais que pour une faille J0 un correctif soit publié le lendemain c’est pas possible.
Pour qu’un correctif sorte, il faut que la faille étudiée, le correctif doit être produit, le correctif doit être testé (parfois il faut ajouter une période de debugage) enfin il faut contrôler son intégration dans la distribution. Et tout ça se fera en 24 heures ?
#7.11
Il mélange conception du patch et diffusion du patch une fois disponible.
#7.12
Vérifie les dates du dirtypipe et après on cause. A moins que le risque d’avoir tort te fasses dire des tas de bêtises histoire de garder la face.
Et pour info, je ne mélange pas la conception et le déploiement.
Ton raisonnement est valable dans une entreprise, pas dans le fonctionnement du logiciel libre.
Pratique la chose, tu seras surpris.
#7.13
Je connais suffisamment bien Debian pour savoir qu’ils ne publient pas des correctifs sans un minimum de contrôle pour éviter de tout casser.
#7.3
Le problème c’est pas le poste, c’est l’interface chaise-clavier
#7.4
Définissons “OS troué” … il s’agit d’un OS ayant des publications de correctifs de sécurité tardifs voir très tardifs après publication de la faille (CVE).
Maintenant, la bonne question est “Quel OS publie les correctifs le plus rapidement ?”. Les antivirus ne sont pas une solution car ils dépendent des mises à jour des bases de signatures ; et ces bases sont alimentées après publication des malwares.
Mieux vaut un antivirus pas trop en retard ou une faille de sécurité corrigée ?
(je vous laisse enquêter sur les dates de publication des CVE vs les dates de publication des correctifs OS chez les gros éditeurs du marché.)
#7.7
Tu peux flinguer une machine sans faille directe dans l’OS juste parce que des dev d’app ou de progiciels ont fait du caca mou où parce que les puces en silicium ont des bugs ou leurs drivers.
En tant que tel, je suis désolé, mais l’OS c’est qu’un petit bout de l’équation, et non la plus grosse partie.
Pas toujours il me semble, sans compter les fois où les failles sont uniquement chez eux
Cisco c’est fait volé/violé les sources ce son OS y’a quelques années, du coup, bah… déjà tu peux rhabillé ta boite (et ton RSSI si c’est lui qui se base là dessus).
Sans audit tiers/pentest bah avoir un OS fermé/proprio c’est comme avoir une grenade dans la main et lâcher la sécurité. Tu sais juste pas quand ça fa te pété à la gueule.
Ensuite, les normes obligatoires y’en a pas des masses, y’a des recommandations (RGS entre autre) qui sont obligatoires uniquement pour certains organismes sur certains périmètres (PCI-DSS, RGPD, …).
Respecter l’ISO27001 par exemple c’est juste un gage d’amélioration continue, et d’avoir une base. Je connais quelques boites qui sont pas certifiées ISO27001 mais qui sont mieux foutues que des boites qui sont certifiées.
Dans ton exemple, et sauf mauvaise lecture, t’as aucune sauvegarde à froid de tes données (interne ou client). C’est … aussi bien que la boîte dont il est question dans l’article et qui s’est faite violée jusqu’à l’os ses données et celles de ses clients.
Ah et juste pour le fun, généralement, dans les boites pas trop mal gérées, la redondance pour la prod ça donne 2 DC et tu double aussi l’ensemble (alim / réseau /firewall) en prenant des fournisseurs différents pour le matos Info.
Et tu as un PUPA/PCA que tu test régulièrement.
#8
Ça semble quand même dingue qu’un hébergeur n’ait pas de sauvegardes offline….
Il vont certainement disparaître.
#9
Je pense qu’ils risquent maintenant de vraiment faire faillite. Je n’imagine pas une société confier maintenant ses données à cet hébergeur après avoir lu qu’ils se sont fait complètement défoncer tous leurs systèmes, pas un seul qui tenu contre… sauf le chiffrement des données mais bon comme on dit :
.
“ it’s totally rubbish now”.
#10
Tout de même, quelle belle invention le bitcoin…
#11
“les pirates sont entrées” : que des femmes ?
#11.1
Non, sinon ça aurait été des piratesses.
En fait, c’est “DeepL/Google” qui traduit mal en l’absence de suffisamment d’information sur le genre des pirates Et le rédacteur qui n’a pas bien relu.
#12
Dire que sans ce truc, la délinquance économique sur internet n’aurait jamais existé. Le monde était un Eden avant 2009
#13
L’avenir c’est android + chatgpt.
Tous les sites webs que je visite sont dimensionnés pour les smartphones. Windows et MacOS ressemblent de plus en plus à des smartphones en mode paysage. Y a bien qqn qui va se rendre compte que c’est mieux de mettre l’écran en mode portrait. Et Linux suivra le mouvement de windows/macos, comme d’hab.
Quand a ChatGPT (ou autre IA), tout le monde dit que c’est l’avenir.
je ne vois même pas pourquoi c’est un sujet de discussion.
#14
Pourquoi demander du BTC alors que le XMR est fait pour çà ?
En plus, au cours du jours du BTC, çà nous fait que 144934,82
#15
Sifflote
Et heu, je ne pense pas que tu sois si loin de la réalité, une des utilité smartphone pliables est d’avoir un écran plus grand tout en pouvant rester dans la poche.
Je trouve qu’il y a beaucoup de pc portables de 15” ou moins.
Le docking (non pas celui-là est de plus en plus utilisé (petit écran transportable et grand écran en station fixe).
Coté Apple la frontière entre l’IPAD et le macbook ce n’est plus que l’OS (en simplifiant).
Et je pense que la popularité naissante des steam deck et équivalent semblent montrer une volonté de changement des usages.
Je ne serai pas surpris si dans quelques années (décennies) Microsoft nous sort une version custom d’Android (un peu comme ils l’ont fait pour Chrome).
#16
Ben voilà pourquoi on utilise un os non courant pour notre data center on est sur l’OS Cisco qui n’est pas libre et dont les sources ne sont pas dans la nature par conséquent plus difficile d’être sensible aux attaques les seules qu’on rencontre fréquemment ce sont des attaques DDOS mais ça ne tient pas non plus. Et la répartition sécuritaire se fait conformément aux aux normes obligatoire donc déjà un site qui se fait hacker de la sorte ne respectait pas les normes iso de base.
Si on l’applique de base on a je résume hein je vous donne pas le détails….
1 data test interne
1 data prod interne
1 data admin interne
1 bank serveur client externe
1 bank sauvegarde externe
#17
C’est tellement faux…
#17.1
C’est surtout que cisco s’est fait piquer son OS y’a un moment par des hackers
C’est ça le plus drôle de l’explication, et l’exemple avec 1 DC de prod … genre 1 … Bisounours .. toussa toussa …
#17.3
Ah oui ça je sais mais comme leur service coute une blinde crois moi qu’ils n’ont pas mis longtemps à réagir. Je sais qu’on a une mise offline des services qui est intervenu sur la prod.
J’ai bien précisé que je n’allais pas donner le “ détails ” c’est une OIV.
#17.2
La sécurité par l’obscurité concept intéressant s’il en est n’est pas ce qu’on promeut. On a fait un choix qui jusqu’à présent et je dis bien jusqu’à présent à fait ses preuves. Oui je parlais bien des équipements réseaux cisco en effet. Derrière c’est du Freebsd qui gèrent les serveurs. Et en soit une interface graphique n’est pas toujours utiles la ligne de commande à toujours nos préférences. Le plus dur étant de trouver des administrateurs Freebsd ça ne court pas les rues mais par contre ils sont très bien payés….
#17.4
Pour l’interface graphique absente sur des serveurs en DC
Nan mais, entre dire 1 DC en prod et dire ce qui se fait dans toutes les “grosses” boites quelque soit le secteur d’activité sans aller jusqu’aux specs de détail de matos et des firmware que vous avez /utilisez, y’a clairement genre … une galaxie entre les deux.
Les OIV je connais , et même sans entré dans le détail, ce que j’ai décrit c’est la base de toute infra de prod qui se respecte, que tu sois proprio de DC ou juste locataire de DC opéré par un tiers.
#17.5
Organisation internationale de la vigne et du vin ?
#17.6
Opérateur d’Importance Vitale. Normalement les agents de ces entreprises/agences/administrations ne doivent pas en faire état mais le plus souvent c’est un secret de polichinelle. Dans la liste tu dois avoir les grandes banque françaises, engie/edf, l’AP-HP, les entreprises de l’armement, …
#18
J’espère qu’ils pourront réutiliser ses serveurs, sinon on dira qu’ils sont briqué
#19
Ça c’est OIVV
OIV : Organe Interne Ventilé
#20
J’ai l’impression que, depuis quelques jours, mes signalements de fautes d’orthographe ne sont plus traités/pris en compte. Donc je le fais ici : “récupérés” ne prend pas de “s”.
#21
Alors, pour les serveurs j’espère bien !
Mais revenons au commentaire qui a initialement lancé ce débat sur les OS :
Ha mince ! On parlait de postes de travail ! La secrétaire elle rédige ses mails en ligne de commande ?
#22
Là tu touches du doigt la différence entre les personnes qui cherchent à faire fonctionner avec celles qui cherchent à faire de l’argent.
Pour te donner un aperçu, regarde les dates de publication et celles des correctifs sur le dirtypipe. Perso, j’étais à jour 2 semaines avant la publication de la faille parce que j’utilise des noyaux Linux directement depuis le site kernel.org. Mais la plupart des distros, back-portent les modifications sur le noyau de leur dépôt.
#23
Là je veux bien que tu m’expliques, car je ne suis pas certains de comprendre ce que tu veux dire.
#24
Côté GNU/Linux, ce sont des bénévoles qui font les mises à jour. Ils le font pour faire fonctionner.
Du côté des éditeurs propriétaires, ce sont des entreprises à but lucratif. Les corrections de failles de sécurité ne leur rapportent pas d’argent car ce type de service se fait sur des produits déjà vendus. Du coup, l’aspect financier va venir jouer un rôle modérateur sur la réactivité. En gros, les corrections de failles de sécurité passent après le développement des nouvelles fonctionnalités (celles qui vont rapporter des sous). Un savant arbitrage planning / finance / marketing est opéré pour dire quand les développeurs auront le droit de se pencher sur les correctifs de sécurité. Cet aspect à lui seul explique en grande partie les délais de publication des correctifs.
Après, le déploiement dépend de l’entreprise cliente et/ou de l’utilisateur. La logique Windows Update n’est pas un foudre de réactivité en elle même.
#24.1
Désolé mais tu es légèrement à côté de la plaque.
Ces développeurs bénévoles travaillent pour beaucoup d’entre eux sur le noyau Linux (et tout ce qui tourne autour) dans le cadre de leur travail rémunéré. Hé oui, beaucoup d’entreprises dépendent de Linux pour fonctionner et investissent dans son développement.
Et pour l’argument comme quoi les patchs de sécurité ne ramènent pas d’argent, c’est encore assez stupide de penser comme ça (et les entreprises qui pensent de la sorte ne durent pas longtemps). Avoir un système troué ça fait perdre de l’argent, donc les patchs sont importants.
Après je pense que tu ne sais pas comment ça fonctionne au niveau de la publication des infos sur les vulnérabilités. Dans la majorité des cas, un chercheur en sécurité va trouver quelque chose (et encore une fois, de grosses boites investissent fortement là dedans, comme Cisco Talos ou Google Project Zero), et va informer en privé l’éditeur. Ils se mettent d’accord sur une calendrier de publication (“Coordinated Vulnerability Disclosure” ou “Responsible Disclosure”), laissant le temps à l’éditeur de préparer le patch. Souvent quand les détails de la CVE sortent, le patch est déjà dispo.
Bien sûr il y a le cas des 0-day où une vulnérabilité est trouvée alors qu’elle est déjà exploitée, cas dans lequel l’éditeur va le plus rapidement possible donner toutes les infos nécessaires pour détecter une exploitation, fournir des informations de mitigation pour réduire l’exposition, et se dépêcher à sortir un patch. Et ça pour Windows comme pour Linux.
EDIT : j’ai mis du temps à rédiger et je suis largement grillé par Myifee 😅
#25
Lol
https://lwn.net/Articles/915435/
Lol²
Oui bien sûr, c’est exactement ça. Parce que les devs doivent bien sur arrêter toute affaire cessante pour n’importe quelle CVE (et pas de sommeil/vacances/maladie les gars), et qu’on doit pousser la correction le plus rapidement possible à n’importe quel prix.
Parce que ça n’a jamais été une demande des entreprises, tout simplement, qui veulent N cycles de validation/qualification/déploiement.
Je sais qu’on est vendredi, mais tous tes messages sont à côté de la plaque, et restent basés sur des poncifs d’il y a des années (décennies ?) …
#25.1
Décénnies definitely
Suis en retraite depuis 13 ans et ça poncifiait quand je travaillais
#25.2
Tu te moques, mais tu es fort en bullshit.
Va bosser et après on cause.
#26
Surtout que NX-OS est basé sur une distrib Linux (Wind River Linux) :)
#27
Lol, on te parle de développeurs Debian, tu réponds développeurs noyau.
Reprenons : combien de développeurs Debian sont payés spécifiquement pour leur travail de packaging Debian ?
#27.1
Ils sont nombreux…
Par exemple, l’un des principaux contributeur, Wookey : “working professionally on Arm Linux since 2000ish, at Aleph One Ltd, Toby Churchill Ltd, and now Linaro (as an ARM secondee)”
Je t’invite à consulter la liste des contributeurs Debian et vérifier pour chacun d’eux : https://contributors.debian.org/
#27.2
Il a pourtant raison (et je suis souvent en désaccord avec lui) : s’il y a un bug dans le noyau, c’est un développeur du noyau qui va le corriger et mettre la correction dans le git du noyau.
Ensuite seulement, le
développeurmainteneur Debian va mettre à jour la distribution à partir de la correction faite par le développeur du noyau et la fournir aux utilisateurs.#27.3
Faut pas briser ses rêves comme ça, s’il a envie d’y croire au fait qu’un système comme le Linux qu’on a aujourd’hui peut émerger comme ça juste avec quelques dizaines de personnes qui y consacrent leur week-ends gracieusement ! 🤣
#27.4
Easy avec ChatGPT et GitHub Copilot.
#27.5
Sais-tu seulement comment fonctionne Debian ? As-tu déjà participé à une DebConf pour voir un peu la faune qui y traîne ?
#27.6
Et ça donne quoi Debian sans le kernel, sans GNU, sans toutes les briques qui composent une distribution moderne ?
Et pour reprendre ton exemple d’OpenSSL : https://www.openssl.org/blog/blog/2023/07/17/who-writes-openssl/
82.6% des commits ont été réalisés par des gens payés pour travailler sur OpenSSL, soit directement par OpenSSL (qui est financé comment déjà ?), soit par des entreprises.
Alors oui, c’est du boulot de tout empaqueter proprement (et côté Debian c’est très bien fait, mais ce ne sont pas les seuls), mais il faut avoir quelque chose à empaqueter.
EDIT : je rajoute le dernier paragraphe de l’article, traduit, pour que tout le monde puisse en profiter :
C’est les gens d’OpenSSL qui le disent.
EDIT2 : je ne doit pas compter comme eux, j’ai 82.6%, ils ont 87%. Dans l’idée c’est pareil, mais bon…
EDIT3 : j’ai trouvé, ils font leur pourcentage sur les commits “non-triviaux”, j’ai calculé sur l’ensemble…
#27.7
T’es tu posé la question pourquoi certaines entreprises payent des gens pour maintenir du logiciel libre ? … Coeur de business garçon. Si le logiciel libre n’existait pas, ce genre d’entreprises n’existeraient pas non plus.
Tes chiffres n’amènent rien à la discussion, cela pollue le sujet de départ : sécurité des postes de travail.
#28
Bien sûr, beaucoup de développeurs Debian travaillent dans le domaine du logiciel libre. Mais combien ont dans leur fiche de poste le fait de travailler explicitement sur Debian ? Très peu.
Je connais personnellement une petite dizaine de développeurs Debian, personne n’a “Debian” marqué sur sa fiche de poste.
#29
On parlait de Debian, là. C’est toi qui n’arrête pas d’embrayer sur le noyau. Or, donc, et si le bug est dans OpenSSL par exemple, qui est la grande multinationale qui s’en occupe ? Et qui va s’occuper de déployer le patch dans les distribs ?
#30
Fallait le dire tout de suite que t’étais d’accord. Parce que là tu t’évertues à chercher à me donner tort, alors qu’en fait t’es parfaitement d’accord sur la question de départ : Debian est la seule grosse distrib à ne pas être portée par une boîte privée, et pourtant ils sont les plus réactifs pour intégrer les correctifs de sécurité.
#31
Tu veux dire que les bonnes pratiques de développement, tests et diffusion ne sont pas applicables aux OS libres ?
Il te répondait juste sur ton affirmation que ce sont principalement des bénévoles qui patchent.
#32
Normal, je ne peux pas être partout en même temps.
#32.1
Edit :
parceque j’ai quand même ri, j’ai été mechant 
#33
#34
C’est une question que je me posais déjà dans les années 2000 avancées, quand Outlook permettait à tant de virus/vers de se propager, et quand certaines sociétés (certes très peu) utilisaient déjà des postes de travail sous Linux, essentiellement celles fournissant du service autour du libre ainsi que certains petits hébergeurs (j’en connais).
Le problème a beau se situer en partie entre la chaise et le clavier, encore en 2023 on évite beaucoup de problèmes (quasiment tous en pratique) si on a une infrastructure sans Windows sur les postes de travail, et ceux qui sont entièrement sous Linux le vivent.
Et si certains contestent en disant « oui c’est normal, Linux est très peu utilisé donc peu ciblé par les attaquants » (discours que j’entendais déjà dans les années 2000), eh bien raison de plus d’utiliser un OS minoritaire sur le poste de travail, s’il permet de diminuer les risques.
#34.1
En plus de l’aspect minoritaire, si tu as un OS qui est patché plus rapidement que les autres, cela te donne des garanties de sécurité supplémentaires.
Je comprends ta remarque sur les postes de travail dans les années 2000. Aujourd’hui cette question est au 1er plan alors que c’était ignoré et considéré comme contraignant il y a encore à peine 10 ans.
#35
J’ose espérer qu’un hébergeur prendra soin de faire des analyses de mails entrants avec filtrage des pièces jointes type macro et autres trucs.
#36
Comme ça il devient majoritaire et de plus en plus ciblé.
Ce qui est déjà le cas vu que Linux est le backbone de quasiment tout le Public Cloud via diverses distributions soit spécialisées, soit généralistes.
Une stratégie sécurité reposant sur la popularité d’un système est complètement aux fraises. C’est même encore plus dangereux car cela créé un sentiment d’immunité totalement faux. Les systèmes Linux et les éléments qui les composent sont tout autant scrutés et attaqués que n’importe quel autre système. Créé une VM sur un cloud provider, expose le ssh 22 et un serveur httpd / nginx qui sert juste un hello world pendant une journée. Regarde les logs de connexion et tu comprendras.
#36.1
Je sais bien qu’un serveur est scruté, peu importe son OS (mon PC perso est sous Linux depuis 25 ans et il est exposé h24 depuis 2000 en ADSL, il a juste un serveur SSH ; j’ai mis un fail2ban depuis longtemps pour éviter de me faire pourrir les logs - et mitiger le risque si SSH a une vulnérabilité).
Je répondais au commentaire sur l’OS utilisé sur le poste de travail.
Les faits sont avec moi, encore en 2023. C’est juste du bon sens de ne pas utiliser Windows sur un poste de travail en entreprise, mais bon…
Même si Linux devenait majoritaire (c’est pas près d’arriver), ça resterait probablement moins risqué.
#36.2
Poste de travail ou serveur, même combat : les distributions utilisent peu ou prou les mêmes composants. Si un de ces composants est troué, il y a risque pour le SI. Et le principe d’un 0 day, c’est de l’exploiter aussi longtemps que possible avant qu’elle ne soit dévoilée.
Il faut définitivement arrêter de considérer que la sécurité informatique peut reposer sur la croyance que X, Y ou Z est moins risqué parce que pas majoritaire ou que sais-je. C’est une posture au mieux stupide. Désolé d’être sec, mais c’est franchement lassant après 20 ans de Linux de toujours lire ce genre d’ânerie. Je ne sais pas de quels “faits” tu parles, mais si c’est juste une expérience perso, je trouve ça très faible vis à vis de l’actualité IT qui fait régulièrement état d’attaques incluant tout systèmes.
La sécurité IT, c’est du concret : de l’audit, des études, du hardening, des tests de vulnérabilité, de la proactivité, de la réactivité, du suivi, de la gouvernance, etc. Pas une marque ou un produit. Jamais.
Perso je préfère considérer le poste de travail comme étant vulnérable, peu importe le truc machin sur lequel il tourne et mettre les protections en conséquence pour éviter qu’il n’emporte le reste du SI avec lui en cas de vérole.
#36.3
+1000
#36.4
Donc les gars ils ont déployé un patch qui n’existait pas, c’est ce que tu essayes de me dire ?
Bien évidemment que s’ils y consacrent des ressources c’est parce qu’ils en retirent un profit, je n’ai jamais dit le contraire. Ce sont des entreprises, pas des œuvres de charité. Faudrait lire mes messages avant de rétorquer n’importe quoi, car je n’ai jamais essayé de dire que ces entreprises font ça par pure bonté. Allez, je te laisse relire le message pour essayer de déterminer mon propos.
C’est pas moi qui ait amené la conversation sur le terrain de entreprises vs. bénévoles hein…
Par ce commentaire tu montres ta méconnaissance. Je suis sûr qu’en réfléchissant plus de 30 secondes tu peux me ressortir quelques grosses distro Linux, qui ne sont pas non plus portées par des entreprises (Arch par exemple, après j’imagine que tu vas me sortir que ce n’est pas une distro suffisamment grosse ?). Et ta méconnaissance de ce qu’attendent les clients des distros “professionnelles” comme RHEL.
🤣🤣🤣
Je connais probablement moins le fonctionnement de Debian que toi, mais je ne pense pas me tromper en disant qu’ils contrôlent moins que les gars de Red Hat. Mais encore une fois, ce n’est pas une mauvaise chose. Les clients de RHEL cherchent la stabilité avant tout.
Par expérience professionnelle, je peux t’assurer que c’est faux. Même avec un poste de travail sous Linux un utilisateur est susceptible de se faire phisher, ou de lancer un malware (oui, il y a des malwares pour Linux…)
Tout à fait d’accord. La défense en profondeur est cruciale.
#36.5
J’ajouterai à ça qu’il y a un intérêt supplémentaire à avoir un poste de travail sous windows si tu as tes serveurs sous linux, c’est l’hétérogénéité. Une faille sur le poste client ne concernera pas le serveur, donc potentiellement tu limites la casse. Tu augmentes la probabilité qu’il y ait un problème, mais réduit l’impact. Ça s’analyse. Avec du linux partout et un environnement très homogène, l’impact pourra être énorme.
Ceci suppose, bien sûr, que tu n’aies pas eu l’idée tordue d’avoir tes serveurs sous windows
.
#36.6
Tu devrais arrêter l’IT, ça n’a pas l’air d’être ton truc.
#37
L’un des principes de base est de ne pas permettre l’accès admin aux serveurs avec les identifiants utilisés pour se connecter sur les postes de travail, peu importe si c’est un Linux ou Windows.
#37.1
Il peut exister des vulnérabilités dans les systèmes qui s’exploitent sans s’authentifier. Donc oui, il ne faut pas avoir les mêmes accès pour l’admin de l’infra de prod que pour la bureautique, mais c’est une mesure parmi tant d’autres. C’est ce que les anglophones appelle le Swiss Cheese Modèle ( je ne sais pas si ça a un nom en français).
J’adore la manière dont les sujets et propos sont déformés petit à petit pour correspondre aux arguments de gens qui ne veulent pas avoir tort. A la base tout ce sujet est parti d’un commentaire concernant les postes de travail, et même si je ne vois pas plus de souci que ça pour inclure également les serveurs si ça te fait plaisir, je ne vois pas pourquoi s’y limiter. Pour ma part j’ai déjà vu un admin sys qui avait sa machine pro sous Arch, même si je dois bien reconnaitre que ce n’est pas commun; mais ce n’est pas le sujet. Si tu souhaites définir “grosse distro” par “distro massivement utilisé en datacenter” c’est ton droit, personnellement je considère Arch comme une distro majeure.
Et bien sûr que les entreprises souhaitent la sécurité, mais pas au détriment de la stabilité. Ça leur fait une belle jambe une machine patchée qui ne fonctionne pas. Ils préfèrent largement avoir une machine vulnérable mais fonctionnelle, toutes les mesures en amont permettant d’abaisser le niveau du risque (pare-feu, segmentation réseau, WAF, …). Parce que bon, c’est vrai qu’on n’a jamais vu le moindre patch de sécurité casser des choses…
Sans oublier que pour se prémunir d’une vulnérabilité, le patch n’est pas la seule et unique solution. Souvent les vulnérabilités ne sont exploitables que dans certaines configuration, et les Security Advisories indiquent les mesures de mitigations pour réduire au maximum les risques d’exploitation avant que le(s) patch(s) soi(en)t disponibl(s)e et déployé(s).
Après si la machine ne fonctionne pas suite à un patch, c’est sûr que c’est bien sécurisé vu que personne ne peut plus y accéder…
#38
T’es dur
#38.1
C’est pas très fairplay (merde impossible de trouver le mot juste) de faire un jeu de mot avec son propre pseudo :p
Pis tu m’a fait renverser mon café à cause du rire du coup je t’en veux
M’aller je m’arrête là, à force on va me prendre pour un
(m’enfin c’est les vacances je me lâche 
)
#39
En effet, j’ai des lacunes. En particulier, je n’ai jamais rencontré de Arch en datacenter. Je n’y ai croisé que Debian, Ubuntu, RHEL, CentOS, et occasionnellement SuSE et Fedora.
Et sinon, évidemment je ne sais pas ce qu’attendent les clients RHEL ; idiot que je suis, ils ne veulent pas la sécurité. Du moins, pas trop vite.
#40
Les patchs bien bourrins, appliqué de façon dogmatique par des intégristes de la sécurité, j’ai connu. Quand il y a eu le pb avec Log4j, tous les serveurs ont été patchés en urgence, comme si s’était la fin du monde, alors que nos serveurs ne sont pas connectés à internet, donc pas de possibilité d’appel d’un serveur pirate.
Autre patch passé sans réfléchir sur tous les serveurs de développement qui supprimait l’exécution de ‘make’ ou celui qui désactivait un paramètre ipv4, bloquant tous les lancements docker, y compris en prod.
#40.1
C’est effectivement un bel exemple de politique de sécurité défaillante. La réaction passe toujours par une évaluation du risque à faire, à ne pas faire, et combien de temps il faut pour s’assurer que la remédiation ne tanke pas la prod.
Des cas assez courants aussi en dehors des exceptions comme log4shell : les règles firewall. Une personne un peu trop zélée qui voit une ouverture trop large, la fait supprimer, et tanke la prod parce que 50 serveurs se retrouvent en blackout (quand ça nique pas le lien entre deux DC, ça c’est fun).
Si un système d’information était bien géré, cartographié, documenté, et maîtrisé, les 3⁄4 du personnel de l’IT serait au chômage.
#41
Mouais, toutes les écoles de pensée ont leur arguments plus ou moins valables. Je n’ai jamais vu de solution idéale. C’est toujours une histoire de compromis.
Autant il y a 10 ans, le conservatisme morbide (tant que ça marche on touche pas) dans le plus pur style IBM pouvait se comprendre et se gérer de manière pas trop compliquée. Aujourd’hui, les apôtres IBM ne peuvent plus gérer les vagues de changement (ie sécuriser le SI) liées aux évolutions d’infra / fonctionnelle d’une part et aux campagnes des cyber-attaquants qui exploitent rapidement toutes les nouvelles CVE publiées. L’impact de ces événements amène des questions sur l’organisation et les modes de fonctionnement des SI. Tous les DSI ne sont pas forcément prêts à se réorganiser pour faire face.
La grosse question à répondre : L’opérationnel ou la sécurité d’abord ?
#42
100% d’accord
Normalement, en appliquant ça, on est censé se retrouver avec un système qui répond aux besoins, avec une juste balance entre opérationnel et sécurité. Il faut bien sûr garder à l’esprit qu’aucun système n’est parfait (ni stable à 100%, ni sécurisé à 100%).