Journal Après WannaCry, un 2e ransomware utilisant une cyberarme volée à la NSA ?

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
27
28
juin
2017

Un ransomware appelé "Petya" attaque actuellement de nombreux postes de travaux Windows dans plusieurs pays. Il chiffre le disque dur et exige un versement de Bitcoin pour récupérer une clé servant à déchiffrer le disque. Il semble que l'Ukraine ait été touchée en premier. Le ransomware exploite la faille EternalBlue volée à la NSA en avril dernier. Bien que Microsoft ait diffusé un correctif depuis avril, il semble que de nombreuses entreprises n'aient pas mis à jour leurs postes de travail. Pourtant, WannaCry, un premier ransomware ayant sévi le 19 mai dernier, avait déjà exploité cette même faille. Microsoft avait même publié un correctif pour Windows XP, alors que Windows XP n'est plus supporté depuis 3 ans (avril 2014) !

J'en comprends que les services IT peinent à mettre à jour les postes de travail Windows.

Pour WannaCry, l'outil WannaKey permet de récupérer la clé secrète sous Windows XP si le PC n'a pas été rebooté. Dans Windows XP, la fonction CryptReleaseContext() ne nettoie pas la mémoire et il est donc possible de récupérer la clé privée en scannant la mémoire du ransomware (à priori, on peut lire la mémoire des autres processus sous Windows, il me semble que c'est pareil sous Linux nan ?).

Avant de se moquer de Windows, assurez-vous que vos postes de travail Linux soient régulièrement et automatiquement mis à jour…

Faut-il se mettre à lancer Firefox dans un container et/ou une machine virtuelle ? Voir dans le cloud (souverain ou non) ? Faut-il rediriger tous les mails entrant dans /dev/null ?

  • # Compléments

    Posté par  (site web personnel) . Évalué à 10.

    (1) Infection

    La mise à jour automatique du logiciel de compatibilité Ukrainien MeDoc est suspecté d'avoir servi de moyen d'infection initial. Selon l'article TheVerge (cité plus bas), en général, les système de mise à jour automatique ont les droits d'administrateur Windows, utilisent des connexions chiffrées, sont mis en liste blanche par les parefeux, ont le droit aux connexions sortantes vers Internet, etc. Le "graal" des attaquants.

    (2) Propagation du virus

    Petya utilise élégamment les fonctionnalités Windows d'administration des postes de travail, Windows Management Instrumentation (WMI) et PsExec, pour infecter les autres ordinateurs du LAN. Autrement dit : une fois qu'un poste administrateur Windows est infecté, il peut infecter tous les postes de travail auxquels ils ont accès, même si ces postes sont ultra sécurité, car c'est volontaire de permettre d'exécuter du code arbitraire.

    Techniquement, WMI et PsExec ne sont pas mis en cause, on peut aisément imaginer la même chose sous Linux (SSH, Ansible, Puppet, Chef & cie).

    J'en comprends que le problème initial est le vecteur d'infection. Là je pense que Linux se défend mieux car les logiciels proviennent généralement de la distribution Linux utilisée qui signe les dépôts et les paquets, et sécurise correctement ses serveurs…

    … Oui bon, parfois les serveurs Debian, Ubuntu, freedesktop, gnome.org, kernel.org, etc. se sont pirater, mais bon, c'est rare nan ? …

    Source: https://www.theverge.com/2017/6/27/15883110/petya-notpetya-ransomware-software-update-wannacry-exploit

    • [^] # Re: Compléments

      Posté par  . Évalué à 9.

      Si les gens n'installent pas les correctifs de sécurité publiés depuis 3 mois, inutile de discuter statégie de sécurité.
      La seule chose que l'on semble pouvoir reprocher à Microsoft est d'avoir un système de mise à jour tellement rigide et contraignant que les gens sont enclins à le désactiver ? Au boulot, les quelques postes windows qui restent se mettent à jour au moment de partir, le soir, lorsqu'on éteint les postes, et que forcément, on est pressé.

      • [^] # Re: Compléments

        Posté par  . Évalué à 4.

        Le problème des mises à jour de sécurité c'est qu'elles modifient parfois la fonctionnalité. J'ai eu à enlever deux fois des mises à jour de sécurité sur toutes mes machines car un logiciel ne fonctionnait plus, et pourtant nous n'installons pas aveuglément toutes les maj m$, il y a un processus de validation.

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: Compléments

          Posté par  (Mastodon) . Évalué à 5.

          Deux fois en combien d'années et ça touchaient combien d'applis ?

          Comme tu le dis les retour arrières restent possible il vaut mieux gérer 2 - 3 exceptions, savoir les isoler dans un vlan si besoin le temps que le fournisseur produit une version patchée qui fonctionne avec les maj que de ne faire passer aucune mise à jour de sécurité par peur nébuleuse d'un éventuel bug une fois de temps en temps.

          Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

          • [^] # Re: Compléments

            Posté par  . Évalué à 9.

            le temps que le fournisseur produit une version patchée

            mmmh, nous vivons pas dans le meme monde, vu que je ne travaille pas chez AIRBUS,IBM etc … je n'ai helas pas encore vu le cas ou cela existe. Meme chez Atos il ne le font pas cf les histoires précédentes.

            essaye d'appeler Ciel! compta pour leur demander de modifier leur logiciel pour respecter les mise a jour microsoft

      • [^] # Re: Compléments

        Posté par  . Évalué à 4.

        pourquoi les maj ne sont pas silencieuses ? Ça s'installe tranquillement en tâche de fond et quand l’utilisateur reboot la machine la machine redémarre tranquillement sur la maj. Combien de fois mon windows m'a rebooté dans les dents alors que j'étais en plein counter strike :)

        • [^] # Re: Compléments

          Posté par  (site web personnel) . Évalué à 5.

          Ça s'installe tranquillement en tâche de fond et quand l’utilisateur reboot la machine la machine redémarre tranquillement sur la maj. Combien de fois mon windows m'a rebooté dans les dents alors que j'étais en plein counter strike :)

          Windows est un peu agressif pour cela, c'est vrai, mais après il y a aussi un problème avec ton raisonnement : beaucoup d'utilisateurs ne redémarrent jamais leur machine. En entreprise (et même à la maison) les ordinateurs sont souvent allumés la nuit, et pour les ordinateurs portables beaucoup utilisent l'hibernation ou la mise en veille plutôt que l'extinction complète.

          Résultat, beaucoup d'utilisateurs malgré l'installation des mises à jour exécutent en réalité un système non corrigé. Il me semble sain que l'OS avertisse l'utilisateur du problème. Et aujourd'hui Windows 10 laisse 1 journée ou deux de répits avant de forcer la main (avec la possibilité de renouer le délai si nécessaire). Les 4h de XP ou 7 étaient en effet assez courts…

          • [^] # Re: Compléments

            Posté par  . Évalué à 4.

            Et aujourd'hui Windows 10 laisse 1 journée ou deux de répits avant de forcer la main (avec la possibilité de renouer le délai si nécessaire)

            Heu non, en fait il attend d'être "hors des heures d'activité" (que tu peux pas forcer à 24/24 bien sûr) pour rebooter…

            • [^] # Re: Compléments

              Posté par  (site web personnel) . Évalué à 5.

              Heu non, en fait il attend d'être "hors des heures d'activité" (que tu peux pas forcer à 24/24 bien sûr) pour rebooter…

              Oui c'est vrai qu'en 8 et 10, le comportement a changé.
              Cependant, Windows 10 ne redémarrera que si l'ordinateur est dans la plage d'inactivité et que l'ordinateur est effectivement inutilisé (comment il décide ? Je ne sais pas, mais je suppose que les tâches en plein écrans et les activités claviers / souris sont prises en compte comme pour la mise en veille automatique en somme).

              Bref, la situation a quand même évolué positivement depuis XP et ses redémarrages pour mise à jour alors que tu étais sur l'ordinateur en train de faire quelque chose…

              • [^] # Re: Compléments

                Posté par  . Évalué à -3.

                je suppose que les tâches en plein écrans et les activités claviers / souris sont prises en compte comme pour la mise en veille automatique en somme

                C’est une excellente justification à l’enregistrement de tous les faits et gestes « digitaux » de l’utilisateur, qui ne l’oublions pas, est aux yeux de beaucoup un simple consommateur potentiel :)

                Il me semble que certains écrans, comme des bornes de commande de fastfood, sont munies de caméra, qui si elle n’enregistre pas l’image, l’analyse en temps réel pour enregistrer des données comme le poids, la taille, le regard ou le nombre de personne qui utilisent cette interface.

                • [^] # Re: Compléments

                  Posté par  (site web personnel) . Évalué à 4.

                  Je ne vois pas le rapport, on parle juste de garder en mémoire qu'il y a eu un évènement interactif sur la machine avant de mettre en veille. Tous les OS modernes font ça, même Linux et *BSD donc bon…

                  Cela n'implique en aucun cas le flicage de l'utilisateur et de ce qu'il fait.

                  • [^] # Re: Compléments

                    Posté par  . Évalué à 3.

                    chut ! ;)

                    J’étais cynique en disant ça. Mais c’est vrai que ce n’est pas très pertinent je le reconnais.

                    • [^] # Re: Compléments

                      Posté par  (site web personnel) . Évalué à 0.

                      Oui sauf qu'en fait t'as raison voir ici dans l'article de numerama

                      Les joueurs sous Windows 10 ont passé 4 milliards d’heures à jouer à des jeux PC

                      Il y a vraiment une surveillance des actions et une remontée d'info

                      • [^] # Re: Compléments

                        Posté par  (site web personnel) . Évalué à 6.

                        Sauf que cela fait parti des programmes de collectes de données de Windows que tu peux désactiver et qui n'ont rien à voir avec des procédures locales pour déterminer si un utilisateur utilise l'ordi ou pas pour savoir si l'ordi doit entrer en veille ou redémarrer ou pas.

                        Cela n'a pas grand chose à voir et cette digression met un peu dans la confusion.

                        • [^] # Re: Compléments

                          Posté par  . Évalué à 3. Dernière modification le 30 juin 2017 à 19:08.

                          que tu peux désactiver

                          Que tu dois désactiver. Ça veut bien dire que pour les fameux Régis et Nathalie Michu, c’est openbar pour la collecte de leurs méta-données…

                          Quand Debian me demande si je veux participer à l’étude statistique sur l’utilisation des packages c’est de l’opt-in. J’ai l’impression qu’avec Windows 10 on est plutôt dans l’opt-out bien vicieux (mais bon je connais pas trop, j’ai plus de Windows sur mes ordis perso depuis Windows 98…)

                  • [^] # Re: Compléments

                    Posté par  . Évalué à 5.

                    Tous les OS modernes font ça, même Linux et *BSD donc bon…

                    C'est marrant cette tournure de phrase, ça laisse penser que Linux et *BSD ne sont pas modernes…

          • [^] # Re: Compléments

            Posté par  . Évalué à 2.

            beaucoup d'utilisateurs ne redémarrent jamais leur machine. En entreprise (et même à la maison) les ordinateurs sont souvent allumés la nuit, et pour les ordinateurs portables beaucoup utilisent l'hibernation ou la mise en veille plutôt que l'extinction complète.

            Oui, ben je vais te donner la raison:

            Mon ordi, sous Win7, met 10 bonnes minutes à démarrer si je l'éteins complètement, et 2-3min à s'éteindre!

            Alors sur une journée complète, c'est peu, mais je te jure la perception du temps perdu devant ton ordi le matin alors que tu t'es levé et t'es venu abattre du boulot et pas passer 10min à glandouiller bêtement, c'est pas mal frustrant.

            Pareil le soir: tu peux enfin rentrer chez toi… ou pas, parce que l'ordi met une plombe à s'arrêter, et c'est pire en cas de mise à jour.

            Je ne sais pas comment ça se passe pour Win10, mais faudrait se rendre compte: si on veut que les utilisateurs redémarrent régulièrement, il ne faut pas que ça devienne une punition. Des décennies de Windows, et c'est toujours pas résolu: après un moment, démarrages et arrêts deviennent interminables.

            Et là je me dis que ça ne sera jamais résolu? On attend juste que tout le monde passe au SSD?

            • [^] # Re: Compléments

              Posté par  . Évalué à 3. Dernière modification le 28 juin 2017 à 14:13.

              Ce n'est pas résolu car c'est un problème qui ne provient pas de Microsoft.

              Ça n'a jamais été le cas.

              Le démarrage/arrêt lent, c'est à cause de… plein de raisons potentielles :
              - fragmentation importante (n'affecte que les disques durs)
              - disque dur trop lent (4200 RPM, euh…)
              - pas assez de mémoire (Moins de 2 Go sous Vista ou ultérieur, ouch !)
              - trop de programmes à démarrer
              - programmes qui s'arrêtent difficilement / ne savant pas s'arrêter proprement.
              - variations : fuite mémoire d'un programme/service, …

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: Compléments

                Posté par  . Évalué à 3. Dernière modification le 28 juin 2017 à 16:50.

                trop de programmes à démarrer

                Il aurait fallu que Ms propose un système d'enregistrement de mise à jour, avec une api pour s'enregistrer.

                Actuellement sur un Windows, pleins de programmes gèrent leur mise à jour de façon anarchique, chrome, firefox, foxit reader, vlc, flash, java, nvidia, ati…

                Tout ces programmes, dont certains sont automatiquement lancés au démarrage prennent des ressources. Si le mécanisme de mise à jour était géré par le système, ce serait mieux.

                Maintenant avec le store j'imagine que c'est mieux.

                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

              • [^] # Re: Compléments

                Posté par  . Évalué à 7.

                fragmentation importante (n'affecte que les disques durs)

                Non, je vérifie ce genre de choses.

                disque dur trop lent (4200 RPM, euh…)

                C'est le même disque depuis le début, et ça n'a pas toujours été aussi lent

                pas assez de mémoire (Moins de 2 Go sous Vista ou ultérieur, ouch !)

                8Go, et pareil: elle n'a pas diminué depuis le début

                trop de programmes à démarrer

                C'est le PC du boulot, je n'ajoute pas de trucs à démarrer.

                programmes qui s'arrêtent difficilement / ne savant pas s'arrêter proprement.

                Ben faudrait au moins donner une info claire sur le problème, ou tuer les récalcitrants plus vite. Maintenant Outlook informe sur les extensions qui plombent les perfs (et Skype for Business est systématiquement en haut de la liste, je ne peux qu'applaudire…)

                variations : fuite mémoire d'un programme/service, …

                Je devrais en voir les effets tout le temps, pas juste au démarrage et à l'extinction.

                Ce n'est jamais la faute de Windows, mais pourquoi donc mon PC fixe à la maison, sous Sid, sur lequel je teste et installe puis désinstalle un tas de bordel régulièrement, et qui est bien plus vieux, ne me cause pas tant de mal au démarrage et à l'extinction?

                • [^] # Re: Compléments

                  Posté par  . Évalué à 6.

                  Généralement, si ça met de plus en plus longtemps c'est lié à la taille du profil. En particulier sur les PC pros où y a de fortes chances qu'ils soit en roaming (donc synchro via le réseau).
                  C'est pas la faute de Windows mais des applicatifs (coucou Thunderbird et tes gigas de mails stockés par défaut dans le %APPDATA%)

                  • [^] # Re: Compléments

                    Posté par  . Évalué à 5.

                    Généralement, si ça met de plus en plus longtemps c'est lié à la taille du profil. En particulier sur les PC pros où y a de fortes chances qu'ils soit en roaming (donc synchro via le réseau).

                    Je plussoie. Là où je travail le profil en roaming est inutilisable.

                    Démarrer Windows tous les matins, avec un profile local, ça permet de réfléchir 3 minutes, en buvant éventuellement un café, afin d’organiser, mentalement, sa journée.

                    Je pense qu’un poste de travail se doit d’être éteint quand il ne sert pas, pour des raisons évidente d’économie. Donc à moins d’une bonne raison (ie: il se passe des traitements la nuit sur ce poste et ceux-ci sont justifiés) le parc « bureautique » doit être éteint.

                    Évidement, pour ne pas gêner l’utilisateur il faut faire certains traitements hors des heures de travail de la personne, notamment les mises à jour, pour un antivirus c’est très souvent par exemple… Il faut donc que l’extinction soit automatique et que l’utilisateur n’ait pas à le faire ! Son poste est démarré le matin (par exemple à 5h00 du mat…) de la même manière, par le réseau.

                    J’ai même connu quelqu’un qui m’a dit avoir imposé de re-descendre une image toute les nuits sur le parc bureautique… et avoir ainsi réduit drastiquement le nombre d’incident/call dans la structure (un hôpital si mes souvenirs sont bons)…

                    • [^] # Re: Compléments

                      Posté par  (site web personnel) . Évalué à 0.

                      Je serai pour ça effectivement et encore plus généralisé : le soir on désinstalle tout, on détruit le SI qui se repli sur un seul système de stockage que l'on backup. On coupe l’électricité. Et le matin on rallume et repart du backup.

            • [^] # Re: Compléments

              Posté par  (Mastodon) . Évalué à 4. Dernière modification le 28 juin 2017 à 14:37.

              Autant je préfère la méthode "linux" (on remplace des paquets par une version plus récente plutôt que passer des patches) et je trouve débile qu'on demande aussi souvent de redémarrer sous windows là où à priori un redémarrage des services concernés devrait suffir, autant sous win 7 et 10 je n'ai plus vu de démarrage vraiment long (à part lors de la première installation). Les seuls trucs parfois longuet c'est justement à l'arrêt pour l'application des patches mais bon pour l'arrêt du pc on s'en branle que ce soit long vu qu'on ne l'utilise plus (et en plus il nous laisse choisir si on veut le faire ou pas).

              Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

              • [^] # Re: Compléments

                Posté par  (site web personnel) . Évalué à 4.

                je trouve débile qu'on demande aussi souvent de redémarrer sous windows là où à priori un redémarrage des services concernés devrait suffir, autant sous win 7 et 10 je n'ai plus vu de démarrage vraiment long

                En théorie la méthode traditionnelle sous Linux est belle mais en pratique il y a des soucis.

                Déjà, pour que la mise à jour se fasse, il faut au minimum arrêter le logiciel concerné pour le relancer. En cas de mise à jour de MS Office dans Windows (qui passe par Windows Update), il faut relancer MS Office. Est-ce que l'utilisateur y pense ? Pas vraiment. Et tu ne peux pas le forcer à le faire.

                Les mises à jour de Windows Update sont en général : Office, le cœur de Windows, Explorer / Edge, la BDD antivirus et des pilotes. Je crois que la BDD antivirus est le seul cas où un redémarrage n'est pas nécessaire et d'ailleurs, c'est la politique de MS sur le sujet.

                Ensuite, une mise à jour à chaud cela pose des problèmes de cohérence entre les binaires des applications et des bibliothèques. Cela peut conduire à des bogues difficiles à identifier, prévoir ou éviter. Quand cela ne conduit pas à un crash de la machine.

                Par exemple, il y a pas si longtemps, chez Fedora (https://forums.fedora-fr.org/viewtopic.php?id=65807), un crash du serveur X survenait lors d'une maj de systemd (et non, systemd n'est pas le seul coupable, X11 l'était aussi). Résultat, si tu faisais ta mise à jour via un émulateur de terminal graphique, ta session plantait, ta maj avec et tu avais un système dans un état bien pénible à récupérer.

                Exécuter la mise à jour effective dans un environnement minimal est la meilleure solution pour garantir que ton système est à jour, sécurisé et stable et que le processus ait peu de chances d'échouer. D'ailleurs chez Fedora (et GNOME) c'est la politique recommandée et GNOME Logiciels procède aux mises à jour au redémarrage aussi.

                • [^] # Re: Compléments

                  Posté par  (Mastodon) . Évalué à 2.

                  En théorie la méthode traditionnelle sous Linux est belle mais en pratique il y a des soucis.

                  Déjà, pour que la mise à jour se fasse, il faut au minimum arrêter le logiciel concerné pour le relancer. En cas de mise à jour de MS Office dans Windows (qui passe par Windows Update), il faut relancer MS Office. Est-ce que l'utilisateur y pense ? Pas vraiment. Et tu ne peux pas le forcer à le faire.

                  Les mises à jour de Windows Update sont en général : Office, le cœur de Windows, Explorer / Edge, la BDD antivirus et des pilotes. Je crois que la BDD antivirus est le seul cas où un redémarrage n'est pas nécessaire et d'ailleurs, c'est la politique de MS sur le sujet.

                  Ensuite, une mise à jour à chaud cela pose des problèmes de cohérence entre les binaires des applications et des bibliothèques. Cela peut conduire à des bogues difficiles à identifier, prévoir ou éviter. Quand cela ne conduit pas à un crash de la machine.

                  Dans le cas des applis les bibliothèques sont chargées au démarrage de l'appli et donc ne changent en mémoire que si l'appli est redémarrée. Et pour la gestion du redémarrage tous les OS modernes fournissent des mécanismes de notifications. C'est donc faisable.

                  Sous debian on a l'outil checkrestart qui permet de lister les process qui nécessitent un redémarrage suite à une upgrade. Un utilisateur chevronné sait relativement facilement quelles applis doivent être redémarrées, parfois c'est tout le bureau, pour d'autre autant redémarrer la machine. Mais la décision pourrait être facilitées en jouant sur une catégorisation des composants (paquets dont dépendent des composants systèmes, un bureau dans son ensemble (exemple tout ce qui touche à des composants gnome/kde), ou seulement des applis isolées.

                  Crash de la machine ? Cas hyper extrême et que je n'ai pas souvenir d'avoir vu, en tout cas dans le monde debian/BSD. Il n'y a que les composants très bas niveau qui peuvent avoir une influence importante.

                  Par exemple, il y a pas si longtemps, chez Fedora (https://forums.fedora-fr.org/viewtopic.php?id=65807), un crash du serveur X survenait lors d'une maj de systemd (et non, systemd n'est pas le seul coupable, X11 l'était aussi). Résultat, si tu faisais ta mise à jour via un émulateur de terminal graphique, ta session plantait, ta maj avec et tu avais un système dans un état bien pénible à récupérer.

                  Je ne crois pas que Fedora, une distribution qui a pour vocation d'implémenter les technos les plus récentes, soit un cas d'école. C'est plus un prototype qu'un OS.

                  Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

                  • [^] # Re: Compléments

                    Posté par  (site web personnel) . Évalué à 5.

                    Dans le cas des applis les bibliothèques sont chargées au démarrage de l'appli et donc ne changent en mémoire que si l'appli est redémarrée.

                    Tu oublies que les applications communiquent entre elles et que l'évolution des programmes ou bibliothèques sous-jacents peut induire des problèmes.

                    Sous debian on a l'outil checkrestart qui permet de lister les process qui nécessitent un redémarrage suite à une upgrade. Un utilisateur chevronné sait relativement facilement quelles applis doivent être redémarrées, parfois c'est tout le bureau, pour d'autre autant redémarrer la machine. Mais la décision pourrait être facilitées en jouant sur une catégorisation des composants (paquets dont dépendent des composants systèmes, un bureau dans son ensemble (exemple tout ce qui touche à des composants gnome/kde), ou seulement des applis isolées.

                    Fedora a ce genre de catégorisation aussi (te prévenir s'il faut relancer le service, la machine ou la session courante). Mais la granularité reste grossière car gérer l'ensemble finement c'est beaucoup de boulot.

                    Le plus simple, c'est de redémarrer, vraiment. De toute façon pour de nombreux composants (type glibc, noyau, systemd, autres bibliothèques ou utilitaires de base) tu n'as pas le choix pour que ce soit appliqué. Et comme il y a des mises à jour du noyau presque chaque semaine, en gros tu n'as pas à laisser ta machine sans redémarrer trop longuement.

                    Crash de la machine ? Cas hyper extrême et que je n'ai pas souvenir d'avoir vu, en tout cas dans le monde debian/BSD. Il n'y a que les composants très bas niveau qui peuvent avoir une influence importante.

                    Il n'empêche que cela peut arriver, et que tu as en dehors du crash de la session graphique d'autres bogues qui ne sont peut être pas si impactant mais qui peuvent l'être. Mais c'est très difficile à identifier et donc à quantifier.

                    Je ne crois pas que Fedora, une distribution qui a pour vocation d'implémenter les technos les plus récentes, soit un cas d'école. C'est plus un prototype qu'un OS.

                    Je te prierais de montrer un peu de respect envers Fedora s'il te plaît. Fedora a beaucoup amélioré sa QA depuis quelques années et est bien assez stable pour un usage bureautique normal. Si Fedora ne peut être qualifié d'OS, alors pas beaucoup peuvent avoir ce qualificatif également.

              • [^] # Re: Compléments

                Posté par  (site web personnel) . Évalué à 5.

                Je vous raconte pas le nombre de fois que j'ai buté sur la limitation Windows "on ne peut pas supprimer un fichier ouvert" en développant avec Python … Cette limitation explique certainement l'obligation de rebooter à tout va, nan ?

              • [^] # Re: Compléments

                Posté par  . Évalué à 8. Dernière modification le 28 juin 2017 à 15:36.

                je trouve débile qu'on demande aussi souvent de redémarrer sous windows là où à priori un redémarrage des services concernés devrait suffir

                Toi, t'as pas connu Windows 9X, ni XP.

                Aujourd'hui, on ne redémarre même pas pour étendre la partition sur laquelle Windows s'exécute !

                Avant, fallait utiliser gparted depuis un système GNU/Linux (enfin, à partir du moment où il a commencé à exister et être compatible avec FAT/NTFS)

                • 9X : Changement de la profondeur des couleurs ? -> Redémarrage (ou couleurs mauvaises si le pilote graphique ne veut pas changer dynamiquement)
                • 9X/XP : Activation du DMA sur les contrôleurs IDE ? -> Redémarrage
                • 9X : Un logiciel a bouffé toutes les ressources USER et GDI ? -> Redémarrage
                • 9X : Un logiciel ne laisse pas la main et bloque l'OS (multitâche coopératif) ? -> Redémarrage
                • 9x : Un pilote VXD a planté ? -> Redémarrage
                • 9X : Un nouveau matériel ou volume quelconque ? -> Redémarrage
                • 9X : Tu as installé .NET 2.0, IE6, DirectX, Windows Installer 2.0, Daemon Tools ? -> Redémarrage
                • 9X/XP : Tu te mets sur un domaine, ou tu sors du domaine ? -> Redémarrage (ah, j'ai pas vérifié sous 7 ou 10, remarque …)
                • 9X : Tu changes de DNS ou d'IP Fixe ou tu te mets en DHCP ? -> Redémarrage
                • 9x : Un périphérique est supprimé depuis le gestionnaire de périphériques ? -> Redémarrage
                • 9X : T'as installé une imprimante ? -> Redémarrage
                • pré-Vista : Changement de pilote graphique ? -> Redémarrage
                • pré-Vista : Pilote graphique qui plante ? -> Redémarrage

                Le fait est que ça s'est vachement amélioré.

                Et comme dit plus haut, un redémarrage est le seul moyen d'être sûr qu'on est à jour.

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Re: Compléments

                  Posté par  (Mastodon) . Évalué à 1. Dernière modification le 28 juin 2017 à 16:21.

                  Si j'ai connu. Ce n'est pas parce que ça s'est un peu amélioré que ça reste toujours pertinent.

                  Par ailleurs :

                  checkrestart

                    $ sudo checkrestart
                    Found 12 processes using old versions of upgraded files
                    (5 distinct programs)
                    (5 distinct packages)
                  
                    Of these, 3 seem to contain init scripts which can be used to restart them:
                    The following packages seem to have init scripts that could be used
                    to restart them:
                    nginx-extras:
                        20534   /usr/sbin/nginx
                        20533   /usr/sbin/nginx
                        20532   /usr/sbin/nginx
                        19113   /usr/sbin/nginx
                    openssh-server:
                        3124    /usr/sbin/sshd
                        22964   /usr/sbin/sshd
                        25724   /usr/sbin/sshd
                        22953   /usr/sbin/sshd
                        25719   /usr/sbin/sshd
                    exim4-daemon-light:
                        3538    /usr/sbin/exim4
                  
                    These are the init scripts:
                    service nginx restart
                    service ssh restart
                    service exim4 restart
                  
                    These processes do not seem to have an associated init script to restart them:
                    python2.7-minimal:
                        2548    /usr/bin/python2.7
                    openjdk-7-jre-headless:amd64:
                        4348    /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java

                  needrestart :

                  $ needrestart 
                  Scanning processes...                                                                                                                                                                                                                              
                  Your outdated processes:
                  akonadi_akonote[2643], akonadi_archive[2644], akonadi_birthda[2645], akonadi_contact[2647], akonadi_control[2459], akonadi_followu[2648], akonadi_ical_re[2649], akonadi_imap_re[2650], akonadi_indexin[2651], akonadi_maildir[2653], akonadi_maildis[2654], akonadi_mailfil[2657], akonadi_migrati[2658], akonadi_newmail[2660], akonadi_notes_a[2661], akonadi_sendlat[2662], akonadiserver[2467], baloo_file[2347], evolution[3708], evolution-addre[2924, 2907], evolution-alarm[2867], evolution-calen[2887, 12588, 2879, 2910, 2932], evolution-sourc[9829], file.so[2771], kaccess[2314], kactivitymanage[2411], kdeconnectd[2778], kded5[2306], kdeinit5[2302], KeeWeb[5458], kglobalaccel5[2338], klauncher[2303], knotes[2376], korgac[2461], krdc[7013, 5324], krunner[2348], kscreen_backend[2343], ksmserver[2327], kuiserver[2775], kwalletd5[2215], kwin_x11[2344], org_kde_powerde[2364], plasmashell[2350], pulseaudio[2368], sky[7273], systemd[2196], xembedsniproxy[2353], yakuake[2456]`
                  
                  ![Imgur](http://i.imgur.com/2a1fbWo.png)
                  
                  et 
                  
                  [yum-utils needs-restarting](http://man7.org/linux/man-pages/man1/needs-restarting.1.html) :
                  
                  `$ sudo needs-restarting
                  458 : /usr/lib/systemd/systemd-journald 
                  668 : /usr/bin/vmtoolsd 
                  748 : /usr/sbin/NetworkManager --no-daemon 
                  705 : login -- root      
                  20350 : /usr/sbin/zabbix_agentd: listener #2 [waiting for connection]
                  129282 : /usr/sbin/crond -n 
                  20352 : /usr/sbin/zabbix_agentd: active checks #1 [idle 1 sec]    
                  20351 : /usr/sbin/zabbix_agentd: listener #3 [waiting for connection]
                  19974 : /usr/sbin/chronyd 
                  697 : /usr/sbin/atd -f 
                  112099 : /usr/bin/ruby /usr/bin/puppet agent help 
                  1 : /usr/lib/systemd/systemd --system --deserialize 20 
                  704 : /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid 
                  19707 : /usr/sbin/sshd -D 
                  129183 : -bash 
                  129182 : sshd: admtle@pts/0   
                  1036 : /usr/bin/ruby /usr/bin/puppet agent --no-daemonize 
                  1035 : /usr/sbin/rsyslogd -n 
                  674 : /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation 
                  672 : /usr/lib/polkit-1/polkitd --no-debug 
                  673 : /usr/lib/systemd/systemd-logind 
                  10887 : -bash 
                  20347 : /usr/sbin/zabbix_agentd -c /etc/zabbix/zabbix_agentd.conf 
                  20348 : /usr/sbin/zabbix_agentd: collector [idle 1 sec]           
                  20349 : /usr/sbin/zabbix_agentd: listener #1 [waiting for connection]
                  129179 : sshd: admtle [priv]  
                  20308 : /sbin/auditd -n 
                  1039 : /usr/bin/python -Es /usr/sbin/tuned -l -P 
                  849 : /sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf /var/run/dhclient-ens160.pid -lf /var/lib/NetworkManager/dhclient-ea74cf24-c2a2-ecee-3747-a2d76d46f93b-ens160.lease -cf /var/lib/NetworkManager/dhclient-ens160.conf ens160 
                  476 : /usr/lib/systemd/systemd-udevd 
                  474 : /usr/sbin/lvmetad -f

                  Et enfin needs-restart.pl

                  In order to complete the installation of glibc-2.18-11.fc20.x86_64,
                  you should restart the following services:
                  
                      - accounts-daemon.service - Accounts Service   
                      - console-kit-daemon.service - Console Manager
                      - udisks2.service - Disk Manager
                      - auditd.service - Security Auditing Service
                      - dbus.service - D-Bus System Message Bus
                      - rtkit-daemon.service - RealtimeKit Scheduling Policy Service
                      - upower.service - Daemon for power management
                      - colord.service - Manage, Install and Generate Color Profiles
                      - firewalld.service - firewalld - dynamic firewall daemon
                      - polkit.service - Authorization Manager
                      - rsyslog.service - System Logging Service 
                      - NetworkManager.service - Network Manager   
                      - libvirtd.service - Virtualization daemon
                      - gdm.service - GNOME Display Manager
                  
                  In order to complete the installation of glibc-2.18-11.fc20.x86_64,
                  you should tell the following users to log out and log in:
                  
                      - session-1.scope - Session 1 of user rjones`
                  

                  Bref il y'a des choses possibles à faire.

                  Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

                  • [^] # Re: Compléments

                    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 28 juin 2017 à 16:20.

                    En particulier, avec needrestart et sur le besoin de redémarrer ou non lors d'une mise à jour noyau (en l'occurrence le redémarrage sera nécessaire sur la dernière faille stackclash ([DSA 3886-1] linux security update et [DSA 3886-2] linux regression update)) :

                    ┌─────────────────────────────────────────────┤ Pending kernel upgrade ├─────────────────────────────────────────────┐                      
                    │                                                                                                                    │                      
                    │ Newer kernel available                                                                                             │                      
                    │                                                                                                                    │                      
                    │ The currently running kernel version is 3.16.0-4-amd64 and there is an ABI compatible upgrade pending.             │                      
                    │                                                                                                                    │                      
                    │ Restarting the system to load the new kernel will not be handled automatically, so you should consider rebooting.  │      
                    │                                                                                                                    │                      
                    │                                                       <Ok>                                                         │                      
                    │                                                                                                                    │                      
                    └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘          
                    
                • [^] # Re: Compléments

                  Posté par  . Évalué à 3.

                  9X/XP : Tu te mets sur un domaine, ou tu sors du domaine ? -> Redémarrage (ah, j'ai pas vérifié sous 7 ou 10, remarque …)

                  C'est toujours là sous 7, et me semble-t-il sous 10 aussi.

            • [^] # Re: Compléments

              Posté par  . Évalué à 5.

              C'est parce que windows te ment : http://www.commitstrip.com/fr/2013/06/27/scumbag-windows/ :)

            • [^] # Re: Compléments

              Posté par  . Évalué à 2.

              pareil chez moi l'icone du réseau tourne bien 10 minute, et Outlook ne veut démarrer QUE si il est content avec l'icone du réseau, pareil avec IE

              alors que sous powershell je vois bien que le réseau est monté /o\

        • [^] # Re: Compléments

          Posté par  . Évalué à 9.

          Mais tout simplement parce que beaucoup de systèmes industriels/SCADA se basent sur du Windows et que tu ne dois jamais les arrêter à moins de bloquer une production, un process (entrepôt frigorifique, cuisson d'aliments, chimie), d'éteindre l'éclairage de la piste d'un aéroport, ou de modifier le comportement de centrifugeuses d'enrichissement d'uranium etc. ;-)
          Et quand il y a des millions d'euros/des vies en jeu parce que ton système ne redémarre pas correctement, assez rapidement ou qui a un comportement légèrement différent, tu ne trouves personne qui veut prendre la "responsabilité" de faire une mise à jour. Le dicton "Tant que ça marche, on ne touche pas!" prend tout son sens.

          Alors, oui, les systèmes n'ont pas toujours été installés avec des redondances ce qui peut être considéré comme une faute pour certains systèmes mais c'est comme ça!
          Et même si les màj étaient totalement transparentes, tu ne déploies pas sans être sûr, ce qui peut prendre des jours/mois/années avant de le faire.

          Il est très désagréable pour un responsable informatique (qui doit être disponible 24h/24 365jours/an) de se prendre une remarque comme tu l'exprimes (à juste titre ou non!) par des non-connaisseurs qui n'ont jamais vu de systèmes informatiques/process industriels autres que leur petit PC personnel.
          Donc ça ne me surprend pas plus que ça que le ransomware basé sur cette faille continue de se diffuser.

          • [^] # Re: Compléments

            Posté par  . Évalué à 1.

            PS: je ne suis pas vexé, je ne suis pas administrateur de systèmes informatiques, mais pour avoir vu des cas compliqués à gérer, je compatis avec eux!
            Bon courage à tous ceux qui s'arrachent les cheveux actuellement!

          • [^] # Re: Compléments

            Posté par  (site web personnel) . Évalué à 3.

            Dans ce cas, ces systèmes ne doivent pas être connectés à Internet ni au réseau local… oui, facile à dire…

            Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: Compléments

      Posté par  . Évalué à 1. Dernière modification le 28 juin 2017 à 09:26.

      Petya utilise élégamment les fonctionnalités Windows d'administration des postes de travail, Windows Management Instrumentation (WMI) et PsExec, pour infecter les autres ordinateurs du LAN. Autrement dit : une fois qu'un poste administrateur Windows est infecté, il peut infecter tous les postes de travail auxquels ils ont accès, même si ces postes sont ultra sécurité, car c'est volontaire de permettre d'exécuter du code arbitraire.

      Euh, c'est pas Windows 9X, hein.

      La capacité d'utiliser ces APIs dépend de la bonne configuration des droits sur le poste.

      WMI et tout autre API d'automatisation/interrogation sont sujets à restrictions (notamment via les GPO).

      Autrement dit : mauvais admin, changer admin.

      (ou sinon moi aussi je peux déformer la vérité en disant que le moteur Javascript de Firefox, ou le shell de GNU/Linux, provient d'une volonté de pouvoir exécuter du code arbitraire, peu importe la sécurité mise en place sur le poste. Ce sera toujours aussi faux, mais quand on applique ça à Windows ça fait du karma sur TrollFR, alors on va pas se plaindre !)

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Compléments

        Posté par  . Évalué à 2. Dernière modification le 28 juin 2017 à 09:55.

        Autrement dit : mauvais admin, changer admin.

        Je pense qu'il veut dire que l'exploit trouve par la NSA EternalBlue, a été développé volontairement par Microsoft.

        Je goute peu aux théories du complot, mais ton admin n'est quand même pas responsable des trous dans Windows, et par conséquent ca ne serait pas sympa de le virer pour ca.

        • [^] # Re: Compléments

          Posté par  . Évalué à 4. Dernière modification le 28 juin 2017 à 10:16.

          L'exploit en question utilise une faille de sécurité patchée par Microsoft depuis Mars.

          On est en Juin.

          Il suffisait de laisser Windows Update faire son boulot.

          -> Mauvais admin.

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Compléments

            Posté par  (site web personnel) . Évalué à 1.

            patché en urgence seulement en mai sur XP à la suite de wannacry précisément (sauf erreur de ma part)

            • [^] # Re: Compléments

              Posté par  . Évalué à 4. Dernière modification le 28 juin 2017 à 12:43.

              De ce que j'en comprends de

              -> Patché en Mars pour Windows XP à Windows 10.

              -> Publiée en Mars via Windows Update pour Windows Vista (si on en croit la fin du support étendu de Vista qui est le 11 avril 2017) à 10.

              -> La correction pour XP et Windows Serveur 2003 a été exceptionnellement publiée sur TechNet en accès libre (et non pas uniquement pour ceux qui paient le prix fort pour avoir du support pour un OS abandonné depuis 2014 et vieux de 16 ans) devant l'ampleur de l'attaque WannaCry (merci les mauvais admins qui utilisent non-seulement un OS abandonné par Microsoft, mais en plus antédiluvien, et sans protection réseau digne de ce nom mise en place, ET sans disposer d'un contrat de support exceptionnel avec Microsoft comme l'on fait certains gouvernements, du moins en 2014).

              Et après on se demande encore pourquoi Microsoft essaie de tuer Windows XP.
              Non, ce n'est pas parce que c'est "le meilleur Windows".

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Compléments

          Posté par  (site web personnel) . Évalué à 3.

          Je pense qu'il veut dire que l'exploit trouve par la NSA EternalBlue, a été développé volontairement par Microsoft.

          Euh non pas du tout. Attention, je connais très Windows. J'ai répêté les infos que j'ai entendu à droite et à gauche. Mais je pense qu'il est encore tôt pour comprendre en détail ce qui s'est passé.

          Ce que je voulais dire : c'est que le malware est assez malin et sait exploiter correctement les fonctionnalités d'administration de Windows. Je ne vois pas ce qu'il y a d'étonnant à ce qu'un admin puisse modifier des postes clients. Linux a des technologies similaires.

          • [^] # Re: Compléments

            Posté par  . Évalué à 7. Dernière modification le 28 juin 2017 à 19:24.

            Ce que je voulais dire : c'est que le malware est assez malin et sait exploiter correctement les fonctionnalités d'administration de Windows. Je ne vois pas ce qu'il y a d'étonnant à ce qu'un admin puisse modifier des postes clients. Linux a des technologies similaires.

            Le problème c'est la complexité des process de maj et l'historique du bazard Windows/AD.

            NotPetya a plusieurs moyens de réplication :

            • l'exploitation de MS17-10. Ca permet tranquillou de passer SYSTEM à distance et de propager l'infection d'une machine à une autre. Ca se règle par l'installation du patch kivabien. Sur un Windows normal, ça se met gentiment à jour chez MS, ça reboote et le problème est réglé, tout seul comme un grand. Dans les boîtes et les grands groupes ça ne se fait pas comme ça, pour plusieurs raisons : les boîtes essayent d'avoir des reportings qui tiennent la route pour nourrir les équipes opérationnels et le RSSI et être capable de gérer ce qui est déployé et quand (tient, là par exemple avec le dernier patch tuesday, outlook fait chier avec les PDF) pour savoir ce qui va se passer et ne pas déployer n'imp ; il est compliqué de forcer les utilisateurs à rebooter leur machine (si si), nécessaire pour que le patch soit actif. Ces machins sont souvent immondes (kikoo SCCM), et ce process rajoute du temps. Et il y a du déchet. X% de machines ne choppent pas les patchs. Go figure. Pas de bol, les admins sites ont autre chose à faire que courir après les machines qui n'obeissent pas au patch management.
            • les partages d'admin, WMI/Psexec et consorts. Ca permet, lorsqu'un compte est compromis avec des droits suffisants sur une machine cible, de lancer l'infection avec des commandes légitimes (et très pratiques - je voudrais que ce ne soit pas possible, mais c'est un autre débat).
            • la capacité de choper les crédentials de l'utilisateur, et des autres personnes connectées s'il en a les droits.

            Dans le cas présent toute machine compromise par le premier moyen de réplication ayant un compte connecté ayant des privilèges d'admin sur le domaine ou l'OU locale permettait la réplication via le deuxième moyen sur toutes les machines, mêmes patchées.

            Et on touche à un des problèmes intrinsèques de Windows, avec sa manie de cacher des trucs partout, à être capable de bien cloisonner les credentials d'admin. Sous Windows, dès que vous avez des droits d'admin locaux, il y a moyen de récupérer en clair les mdps des utilisateurs connectés, y compris de niveau domaine. Il me semble aussi qu'il y a moyen de récupérer des hashs (non salés) de mdp de gens qui se sont connectés précédemment.
            Un de ces hashs d'admin est rejouable pour des raisons de compatibilité, donc si deux machines ont le même mdp sur ce compte, on peut se propager de machine en machine jusqu'à tomber sur un compte d'admin domaine (game over).

            Du coup, comment on fait pour se protéger de ça ? Les solutions sont connues et poussées par MS :

            • Un mot de passe différent pour chaque compte "Administrateur" et renommage de ce dernier;
            • Interdiction aux admin domaine de se connecter en local et via le réseau sur des PDT pour sanctuariser ces comptes
            • Interdiction des communications machine à machine.

            Sauf que c'est compliqué à faire, surtout quand on parle de petites structures. (et par défaut, cela reste possible)

  • # Mise à jour automatiques

    Posté par  . Évalué à 3.

    Avant de se moquer de Windows, assurez-vous que vos postes de travail Linux soient régulièrement et automatiquement mis à jour…

    Et saurais-tu nous indiquer comment mettre à jour automatiquement un poste Linux ?
    Parce que moi j'en suis toujours à faire des apt update et apt upgrade à la main…

    • [^] # Re: Mise à jour automatiques

      Posté par  . Évalué à 6.

      Sur une ubuntu LTS:

      Le petit engrenage en haut a droite -> System Settings -> Softwares and Updates -> Onglet "Update" -> "When there are security updates"

      Choisir l'option qui va bien.

      Je met toutes mes machines avec cette option depuis des années, pas de problème a signaler.

    • [^] # Re: Mise à jour automatiques

      Posté par  . Évalué à 9.

      Pour Debian et dérivés, il y a le paquet unattended-upgrades.

      • [^] # Re: Mise à jour automatiques

        Posté par  . Évalué à 2.

        Pour Debian et dérivés

        unattended-upgrades pour Debian stable, oui, pour les autres distro, non. J'ai vu des problèmes avec les mises à jour auto sur Ubuntu.

        Poster une information ne signifie pas nécessairement adhésion

  • # En cas d'infection...

    Posté par  . Évalué à 9.

    Deux informations au cas où vous auriez à faire à des machines infectées:

    • Pas la peine de payer la rançon. L'adresse Email servant a contacter les auteurs pour qu'ils envoient la clé de décryptage une fois le payement effectué a été bloquée par le fournisseur d'accès.

    • Si le PC redémarre et affiche au démarrage CHKDSK / réparation du système de fichier, c'est à ce moment là que le disque est chiffré --> il est encore temps d'éteindre le PC et monter le disque dans une autre machine ou de booter sur une clé USB pour récupérer les fichiers!

    • [^] # Re: En cas d'infection...

      Posté par  . Évalué à 4.

      Perso je formate tout et je réinstall Windows et les programmes/fichiers importants depuis une sauvegarde.

      Le seul moyen d'être sûr de pas récupérer des fichiers infectés.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: En cas d'infection...

        Posté par  (Mastodon) . Évalué à 3.

        Je pense que le fond de commerce de ce type de ransomware est justement les gens sans sauvegarde.

        Sinon c'est trop facile en effet :)

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: En cas d'infection...

          Posté par  (Mastodon) . Évalué à 7.

          Ouais faut pas oublier tous ceux qui se font avoir quand leur concept de sauvegarde est un share sur leur NAS 24/24 sur leur machine et qui se fait cryptolocker avec le reste.

          Où qui se font cryptoplocker la seule et unique clé leur permettant de déchiffrer leurs sauvegardes.

          Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

  • # Incitation

    Posté par  . Évalué à 10.

    Il faudrait ajouter un périphérique permettant de synthétiser des odeurs sur les machines. En cas d'absence de mise à jour, elles se mettraient à sentir de plus en plus mauvais.

    Ça serait rigolo, surtout dans les lieux public.

    Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

    • [^] # Re: Incitation

      Posté par  (site web personnel) . Évalué à 3.

      Je vote pour.

      En voilà une idée qui n'est ni une douce utopie sur le comportement les utilisateurs, ni une dictature brutale.

      :)

      • [^] # Re: Incitation

        Posté par  . Évalué à 2.

        Bah tu remplaces une alerte basée sur un truc qui marche pas très bien (l'intelligence) chez les users par une alerte basée sur un truc qui marche (l'instinct) depuis des millions d'années.

        Moralement je sais pas trop quoi en penser mais ce qui est bien c'est que comme ça mêmes les animaux sauront qu'il faut faire la mise à jour (sauf ce ceux qui aiment les trucs qui puent).

        *splash!*

        • [^] # Re: Incitation

          Posté par  . Évalué à 5.

          Ou bien, simplement, on mettra les machines qui refusent de se mettre à jour dans le bureau des stagiaires.

    • [^] # Re: Incitation

      Posté par  . Évalué à 2.

      Ça serait rigolo, surtout dans les lieux public.

      C'est pas déjà le cas ? o.O

      *splash!*

    • [^] # Re: Incitation

      Posté par  . Évalué à 1.

      Avec 2 "saveurs" distinctes :
      - sauvegardes non réalisées
      - mises à jour non réalisées

    • [^] # Re: Incitation

      Posté par  . Évalué à 3.

      Certains ont déjà essayé en essayant de cramer de la poussière sur le radiateur du CPU. Mais c'est le CPU qui a cramé.

  • # enquête sur le paiement bitcoin

    Posté par  . Évalué à 3.

    Je ne suis pas sûr de bien comprendre comment le pirate bénéficiaire du versement de bitcoin peut rester hors d'atteinte des enquêtes.

    En effet, si j'ai bien compris :
    - d'une part on connaît la clé publique du pirate (nécessaire pour y faire le versement)
    - d'autre part toutes les transactions bitcoin sont publiques (de par le principe de la blockchain distribuée et publique)
    - donc à partir de là, on peut tracer où vont les bitcoins du pirate
    - ensuite pour convertir les bitcoins en dollars, il y a des transactions privées (non traçables, en nature ou espèces), mais il y a aussi des transactions publiques qui, elles, sont connues (marchands de bitcoins qui ont pignon sur rue).
    - donc un enquêteur peut démarrer l'enquête auprès d'un marchand officiel dès que le moindre bitcoin frauduleux est converti

    Qu'est-ce qui complique l'investigation dans ces conditions ?

    • [^] # Re: enquête sur le paiement bitcoin

      Posté par  . Évalué à 4.

      Avant de passer dans le monde physique tes bictoins peuvent être convertis en une centaine de crypto-monnaies différentes et ce un très grand nombre de fois. En théorie c'est simple de retracer ces conversion mais dans la pratique cela devient vite impossible surtout que pas mal d'intermédiaires ne gardent pas toujours les traces des conversions.

      Et pour le retrait physique. S'ils sont bien organisés, ils font ça dans un pays comme la Chine et le cashout est confié à des centaines de personnes qui retourne ensuite l'argent tout en gardant un petit pourcentage.

      Du moment que l'argent a quitté ton compte c'est peine perdue :-)

      Je trolle dès quand ça parle business, sécurité et sciences sociales

      • [^] # Re: enquête sur le paiement bitcoin

        Posté par  (Mastodon) . Évalué à 3.

        De manière générale, on peut dire que les techniques de blanchiement d'argent ne datent pas d'hier, et que les différentes organisations criminelles / mafia savent très bien faire.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: enquête sur le paiement bitcoin

      Posté par  . Évalué à 3.

      Il y a des services d’« anonymisation » de bitcoin : https://en.wikipedia.org/wiki/Cryptocurrency_tumbler

  • # Faut-il payer ?

    Posté par  (site web personnel) . Évalué à 2.

    Merci pour ce journal.

    Il (« la police ») nous est généralement déconseillé de payer la rançon !

    Mais la question que je me pause, est de savoir si les victimes qui ont payées ont reçu, oui ou non (statistiques ? témoignages ?) la clé de déchiffrement…

    Le conseil de ne pas payer est-il fondé sur un « principe moral » ou sur le fait avéré que cela ne permet pas la récupération des données ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.