Logo journal du hacker middle
  1. 1

    J'apprécie de moins en moins les services en ligne, le risque est de toute façon supérieur à un KeePass en local. Pour ma part il est synchronisé sur mes différents postes via Syncthing.

    Tcho !

    1. 2

      Tout à fait d'accord ! Chez moi c'est KeePassXC et fichier synchronisé avec Seafile.

      1. 1

        C'est aussi ma crainte, concernant ce que l'on peut appeler des “données sensibles”. Dépendre d'un tiers, online de surcroît… J'en connais qui se passe même d'une solution éprouvée, telle que Keepass, sous une de ses moutures ou l'autre, et utilise un pur fichier texte, chiffré par GPG ! C'est une idée. À creuser ?!

        Les deux reproches majeurs que je fais à Syncthing, malgré son excellente capacité à sync des datas, c'est 1/ d'être mono-utilisateur, 2/ d'être lourd, c'est un “bouffeur de ressources”…

        1. 1

          Tu as Password-store (la commande pass) qui utilise de multiples fichiers gpg et qui s'interface avec git.

          Plusieurs articles à son propos sont passés sur le jdh déjà comme par exemple 1 2

      1. 2

        Attention sur Ubuntu à partir de la 17.10 on ne peut plus bricoler systemd-networkd comme on veut, il faut passer par l'outil netplan et son fichier de conf en yaml situé dans /etc.

        1. 3

          Il est possible de désactiver netplan via une option kernel à passer à GRUB, "netcfg/do_not_use_netplan=true"

        1. 3

          Je n'avais pas osé le proposer moi-même de peur d'un conflit d'intérêts. Je suis très content que mon article arrive ici :)

          1. 4

            Salute,

            Il n'y a pas de conflit d'intérêts, il ne faut pas hésiter à remonter ses propres articles ;)

            Tcho !

            1. 1

              oui, n'hésite pas, l'auto-promotion est un des moteurs du Journal du hacker, tant que les articles entrent dans les buts du Journal.

            1. 2

              Super nouvelle !

              1. 2

                Si c'est sur un VPS ça ne sert à rien vu que votre hébergeur peut faire un dump de la mémoire, et que la mémoire, elle, n'est pas chiffrée.

                1. 3

                  C’est toujours utile parce qu’en cas de saisie, ils n’y vont généralement pas avec des pincettes et n’iront pas jusqu’à réclamer un dump de la mémoire.

                  Et même dans le cas d’un dédié, ça ne protège pas non plus d’une saisie intelligente à coup de DMA. Ou encore la corruption du /boot pour y planter un keylogger d’exfiltration de la phrase de passe.

                  De toute façon c’est comme à chaque fois, la sécurité à 100% n’existe pas :) Elle ne fait que répondre à un modèle de menace, ici une saisie offline des disques.

                  1. 1

                    La loi ne nous oblige pas à fournir les mots de passe dans ce genre de situation normalement ?

                  1. 1

                    Retour d'expérience très très intéressant, exhaustif, précis. J'ai particulièrement apprécié l'humilité des intervenants et la manière dont l'incident a été pris en charge. Le challenge était loin d'être évident, j'espère que l'ANSSI nous proposera d'autres perles comme celle-ci !

                    1. 1
                      1. 2

                        Je travaille sur la mise en oeuvre d'OSSEC HIDS au boulot. Le premier “poc” ronronne sur un cluster de plus de 800 serveurs web traitant chaque jour plus de 550 millions de requêtes web. À terme ce seront près de 6 000 machines qui seront surveillées en temps réel par cet outil !

                        Les patterns d'alertes sont ajoutés petit à petit et les premiers résultats sont très encourageant ! OSSEC est vraiment un produit formidable, du coup j'ai commencé en parallèle la rédaction d'un article sur le blog pour partager mes péripéties.

                        http://ossec.github.io/

                        1. 1

                          Impressionnant lol, vivement l'article.

                          Tcho !