les passkeys ne nécessitent pas d'authentification biométrique
ce n'est pas l'authentification biométrique qui permet le "chiffrement" et "l'infalsibialité" de l'authentification, c'est l'usage de clés privées détenues par un périphérique utilisateur dédiées à chaque service (l'accès à ces clés pouvant être protégé par le périphérique par une vérification biométrique)
Idée de "truc" sur le réseau qui permette à la machine de démarrer : le couple clevis (côté client, qui doit déchiffrer) / tang (côté "serveur", sans lequel le client ne peut pas démarrer automatiquement).
L'avantage, par rapport à d'autres solutions, c'est que tang (le serveur) n'a pas la clé. Il a juste un élément indispensable pour que clevis puisse reconstruire la clé de son côté. Si ta machine a été volée, il suffit d'éteindre tang ou de le rendre inaccessible à clevis pour que le déchiffrement n'ait plus lieu.
Note : au moins dispo sur Debian et Fedora a priori, probablement dispo sur d'autres distributions Linux.
en règle générale, le code est relu et signé avant déploiement
mais cette règle ne s'appliquait pas sur le dépôt NPMJS interne contenant les dépendances de certains codes créés par Ledger
en règle générale, les accès des employés partis sont révoqués
mais au moins un ancien employé avait toujours des accès actifs
cet employé a été victime de phishing
les attaquants ont utilisé cet accès pour pousser du code sur le dépôt NPMJS insuffisamment protégé
ce code est appelé par les applications web qui interagissent avec le porte-feuille matériel (wallet)
le code d'attaque faisait transférer les fonds du wallet vers un porte-feuille contrôlé par l'attaquant
ce code serait resté actif 2h environ
C'est encore une faille liée à la chaîne d'approvisionnement logiciel, mais cette fois-ci via un dépôt interne. Cette attaque est soigneusement ciblée, chapeau aux attaquants. Elle a été très rapidement contre-carrée, chapeau aux défenseurs.
Est-ce que ça contourne le bridage de commandes si tu fais : ssh -J bastion bastion
Non : la première connexion au bastion fonctionne, mais la seconde tente d'ouvrir un shell et elle ne peut pas, elle échoue.
Enfin, je me demande comment ça se passe si la clé sur le bastion a besoin d'un déverrouillage via Smartcard ou Yubikey justement.
Je ne comprends pas la situation que tu as en tête. "la clé sur le bastion" = la clé publique autorisée à se connecter, celle présente dans authorized_keys ? Ou une clé privée permettant de se connecter à un serveur cible ?
Dans tous les cas, si tu as une clé qui demande une confirmation physique pour chaque utilisation, elle ne peut pas être utilisée sans ton accord par l'agent SSH même en cas de forwarding d'agent sur le bastion. Cependant, le bastion peut tout de même utiliser toutes les clés auxquelles l'agent a accès pour se connecter ailleurs, donc ça reste une situation risquée. À moins de n'avoir que des clés stockées sur des yubikey et soumises à confirmation, auquel cas l'agent ne sert à rien.
Bref, je ne vois pas de situation où le forwarding d'agent serait une bonne idée.
L'interception s'est faite en déroutant le trafic destiné au serveur vers un intermédiaire malveillant qui, du coup, a pu obtenir un certificat TLS valide via let's encrypt. Ça correspond à ce que propose le produit Jupiter, proposé par Nexa et vendu comme un logiciel d'interception légale (j'en parlais ici il y a quelques jours).
On note que les intercepteurs ont fait une petite boulette en oubliant de renouveller leur certificat a temps, ce qui a permis à l'administrateur système de détecter le problème.
Comme ils le notent en conclusion, la surveillance des journaux certificate transparency (cf. journal précédemment cité) aurait permis à l'administrateur de repérer le problème plus tôt. Ils notent aussi qu'on peut aussi demander à let's encrypt, via le DNS, de limiter la délivrance de certificats à un compte let's encrypt bien précis, de façon à empêcher l'attaque.
Le seul cas serait si la boite est mise devant ton IP publique mais a ce niveau il y a beaucoup de choses de corrompues.
C'est justement ce qui est fait ici : Jupiter est vendu à des États ou autorités militaires, et il est bien précisé que le site servant pour l'infection doit être "domestique", c'est-à-dire physiquement hébergé sur le territoire contrôlé par l'autorité client de l'Alliance Intellexa.
En effet, c'est une situation où "beaucoup de choses sont corrompues". Le but de ce journal est de signaler que même dans le cas où l'État fait partie de votre modèle de menace, TLS et Certificate Transparency fournissent des outils pour vous défendre.
Cependant le gestionnaire d'identité numérique sait qu'un site XXX l'a interrogé pour savoir si j'ai plus de 18 ans non ?
Non, le principe du double-anonymat doit te garantir que celui qui connait ton identité et donne une preuve "cette personne a plus de 18 ans" ne connait pas le destinataire de l'attestation (tu es anonyme vis-à-vis du site que tu veux visiter - modulo ta majorité ou non - et les sites que tu veux visiter ne sont pas transmis à ceux qui te connaissent).
Après, il faut que les protocoles soient correctement implémentés et que les entités qui opèrent les 2 services (site que tu visites / garant de l'identité numérique) soient réellement indépendants.
Contrairement à ce que plusieurs ont affirmé ici, utiliser httpS n'empêche pas totalement au FAI de deviner les pages que vous consultez : en faisant une analyse statistique de la taille des requêtes envoyées et reçues et les différences de temps entre les différentes requêtes, et en comparant ça au contenu du site web visité et au graphe de lien entre les pages, il peut "deviner" quelles pages vous avez visité. Selon les sites, cette attaque fonctionnera plus ou moins bien :
ça ne fonctionnera pas pour google.com, facebook.com
ça fonctionnera bien pour linuxfr.org, wikipedia.org, etc.
En revanche, les petites données que vous envoyez (mot de passe, code de carte bancaire …) ne seront pas devinables par l'attaquant.
L'application est incroyablement défaillante, à un niveau difficilement inimaginable (je vous laisse lire l'article).
Le plus incroyable, c'est leur réponse au "responsible disclosure" de l'auteur de l'article : « "How were you able to decompile the source code of the app and what do you think should be done to protect against that in the future?" ».
C'est beaucoup plus large que la configuration SSH, mais les recommandations de sécurité relatives à un système GNU/Linux proposées par l'Anssi (agence de l'État français pour la sécurité informatique) ont plein de recommandations chouettes, et classent les 80 recommandations en 4 niveaux de durcissement (minimal, intermédiaire, renforcé et élevé).
HS : Sur le port knocking comme méthode d'authentification, j'avais lu (en anglais) quelqu'un qui expliquait que ça revenait à encoder un mot de passe, éventuellement tournant (façon TOTP ou HOTP) sous forme d'une suite d'octets, et que pour gérer ça on avait rudement plus efficace que le port knocking, dans les protocoles eux-mêmes (= les modes d'authentification à clé publique proposée par SSH, ou par mot de passe pour certaines applications - mots de passe auxquels il convient de donner la longueur adéquate, cela va de soi). Je ne retrouve plus la source, si quelqu'un me lit et l'a sous le coude, je suis preneur !
(note : le commentaire cité dans l'article parle du port knocking comme d'une méthode ayant pour effet de limiter le bruit dans les logs, pas comme d'une mesure apportant une sécurité supplémentaire … donc la remarque au paragraphe précédent ne s'y oppose pas).
Si tu RSSI te force à changer de mot de passe, c'est :
soit que tu as un compte à privilèges
soit qu'il est en retard sur les recommandations de l'Anssi. La nouvelle politique préconisée en matière de mot de passe (donc après la mise en place d'authentification forte ou à plusieurs facteurs), c'est :
renouvellement régulier des mots de passe pour les comptes d'administration
renouvellement d'un mot de passe utilisateur en cas de suspicion de compromission (piratage du poste ou d'un serveur, mot de passe entré au mauvais endroit, …)
J'aime bien aussi ce qu'elle en fait avec redbean, qui est à la fois:
- un fichier zip dans lequel on peut mettre, par exemple, des scripts JS, des pages HTML, du CSS, des scripts LUA
- un exécutable compilé contre la cosmopolitan qui fait serveur web et exécute les scripts LUA que vous voulez en réponse aux requêtes. Ça embarque sqlite en bonus si vous voulez faire du travail avec une BDD.
Du coup, vous remplissez le zip avec votre webapp et vous la mettez à disposition soit des clients finaux (-> ça fait une alternative lightweight à electron), soit sur un serveur quelconque (-> ça fait une alternative lightweight à Docker pour une part significative des usages de celui-ci).
Every modern web service implements a session with a user after successful authentication so that the user doesn’t have to be authenticated at every new page they visit.
Une alternative consiste à authentifier la connexion plutôt que la session, via des certificats TLS. En plus, ça rend le phishing inopérant: une réponse valide pour attacker.tld n'est pas valide pour company.tld, donc attacker.tld ne peut pas se servir de la connexion obtenue par phishing pour se faire passer pour la victime auprès de company.tld.
L'authentification par certificat peut être à 2 facteurs si on protège la clé privée par mot de passe ou code pin.
Le débat n'est pas sans rappeler d'autres controverses politiques actuelles, avec peu ou prou les mêmes questions en toile de fond (qui doit imposer quoi ? au bénéfice de qui ? qui est "nous" ?)
Il y a les commandes disponibles par défaut: CPU, mémoire, espace disques.
Et il y a les plugins qui sont sur la machine cliente et écris par un admin ou quelqu'un d'autres.
Du coup le serveur ne peut pas reconfigurer l'agent ou lui faire exécuter une commande arbitraire, exact ? (sauf plugin mal écrit…)
La communication est cryptée avec comme version SSl par défaut: ssl_version = TLSv1_2
Merci de la précision ! Mais du coup, ça nécessite d'avoir une autorité de certification interne (ou d'en créer une pour cet usage), exact ?
J'ai quelques questions qui me restent, notamment au regard des dégâts qu'ont pu avoir la faille solarwinds où un logiciel de supervision compromis permettait à l'intrus de prendre le contrôle de la totalité du parc :
si je comprends bien, la supervision peut faire exécuter au système supervisé des commandes arbitraires (dans le but de remonter des infos), exact ?
Avec quels privilèges l'agent exécute-t'il ces checks ?
les échanges entre la supervision et l'agent semblent authentifiés par la "community string". Est-ce la même pour tous les systèmes supervisés ? Du coup, un système supervisé X peut interroger de la même manière son voisin Y supervisé lui aussi ?
Ces échanges sont-ils chiffrés ? i.e. un attaquant qui snifferait le lien ethernet peut-il extraire la community string ?
En réalité, vu que le code Javascript qui réalise les opérations cryptographiques dans le navigateur du client vient des serveurs de ProtonMail, il faut tout de même leur faire confiance pour ne pas t’envoyer une version qui exfiltre ta phrase de passe…
C'est un problème que rencontrent toutes les solutions avec du chiffrement de bout en bout qui offrent une appli web (protonmail, matrix, bitwarden, etc.) : si un pirate prend le contrôle d'un serveur qui te sert l'app (ou se place en homme du milieu entre le client et le serveur), il peut servir un JS vérolé et récupéré les secrets.
Sais-tu si des gens commencent à travailler à traiter correctement cette difficulté ?
A priori, il serait assez simple de signer le code JS avec GPG, puis de "pinner" une association clé GPG / site distant pour indiquer aux les navigateurs de n'exécuter du code depuis ce site X que s'il est correctement signé, mais je n'ai pas connaissance de réflexion ou de début de mise en œuvre.
(Se pose bien évidemment la question de la distribution de l'info "tel site requiert telle clé publique", et on retombe soit sur la PKI du web avec tous ses défauts, soit sur du TOFU, soit sur des listes préchargées, soit une autre solution à inventer).
Attention, contrairement à ce que la présentation de l'article peut laisser entendre, seul la première partie ("L’intégralité du commentaire de l’OSI") est la traduction du communiqué de l'OSI : Open source ‘protestware’ harms Open Source.
Les parties suivantes, qui parlent de la version Notepad++ baptisée "free uyghur", ne sont pas issues du texte de l'OSI (et sont, j'imagine, l'œuvre de l'auteur de l'article indiqué sur developpez.com, Patrick Ruiz).
Ta demande couvre plusieurs aspects de la supervision :
la remontée de métriques (= mesures en continu, discrétisé par le temps)
la remontée de logs (= évènements ponctuels)
En général, on veut aussi un système de vérification d'état (faire des "checks" réguliers sur les métriques et/ou les logs remontés, ou vérifier à distance que le serveur web répond bien, que le certificat n'est pas trop proche de l'expiration).
Côté métriques, tu as plusieurs écoles : telegraf/influx (mode push, supervisé -> superviseur), prometheus (mode pull), collectd avec rrd ou graphite (mode push). Dans tous les cas, la visualisation se fait souvent avec grafana. Mon option favorite, c'est collectd pour la collecte et l'envoi de métriques (installé sur les "supervisés"), graphite pour le stockage et grafana pour la visu (installés sur le superviseur). Influx est plus efficace que graphite pour le stockage des métriques, mais il rend beaucoup plus difficile l'échantillonage (passer d'une résolution de 1 mesure / minute sur les dernières 24h à 1 mesure / heure sur le dernier mois, puis 1 mesure / jour sur un an). Je préfère le "push" au "pull" pour des raisons de sécurité : je ne souhaite pas que mon système de supervision ait un accès privilégié d'une façon ou d'une autre aux autres machines (sinon, ça fait un SPOF d'un point de vue sécu).
Collectd permet de récupérer les infos via ipmi si tu ne souhaites pas utiliser sensors.
Pour l'émission d'alertes et la composition d'un tableau de bord "ce qui va / ce qui va pas", j'utilise icinga2, un nagios-like. On peut interroger graphite à partir d'icinga2 pour "surveiller" les métriques. Comme je suis devOps, j'envoie mes alertes dans gitlab.
Pour la remontée de logs, je m'appuie sur systemd-journal-upload et -remote mais j'ai rencontré une fois un bug provoquant une inflation inutile de l'espace occupé par les journaux, alors je ne suis pas sûr de le recommander. rsyslog est pas mal, mais tu collectes beaucoup moins d'info que dans le journal systemd.
Ça prend un peu de temps pour configurer ça aux petits oignons, mais ça permet ensuite d'avoir une belle visibilité sur tes systèmes.
# Mauvais article
Posté par Samuel (site web personnel) . En réponse au lien Les passkeys, nouvelle arme des Big Tech pour enfermer les internautes dans leurs écosystèmes ?. Évalué à 9 (+8/-0).
L'article est faux sur plusieurs points :
Je me suis arrêté au premier paragraphe.
[^] # Re: Questions
Posté par Samuel (site web personnel) . En réponse au message Autohébergement et chiffrement, Proxmox. Évalué à 2.
Idée de "truc" sur le réseau qui permette à la machine de démarrer : le couple clevis (côté client, qui doit déchiffrer) / tang (côté "serveur", sans lequel le client ne peut pas démarrer automatiquement).
L'avantage, par rapport à d'autres solutions, c'est que tang (le serveur) n'a pas la clé. Il a juste un élément indispensable pour que clevis puisse reconstruire la clé de son côté. Si ta machine a été volée, il suffit d'éteindre tang ou de le rendre inaccessible à clevis pour que le déchiffrement n'ait plus lieu.
Note : au moins dispo sur Debian et Fedora a priori, probablement dispo sur d'autres distributions Linux.
# Explications par Ledger
Posté par Samuel (site web personnel) . En réponse au lien Ledger, entreprise française de sécurité des cryptomonnaies, a été piratée. Évalué à 10.
Sur l'attaque, Ledger a publié une explication sur son blog. Si j'ai bien compris :
C'est encore une faille liée à la chaîne d'approvisionnement logiciel, mais cette fois-ci via un dépôt interne. Cette attaque est soigneusement ciblée, chapeau aux attaquants. Elle a été très rapidement contre-carrée, chapeau aux défenseurs.
[^] # Re: Merci
Posté par Samuel (site web personnel) . En réponse au journal Dédier une clé SSH au rebond sur un serveur. Évalué à 3.
Non : la première connexion au bastion fonctionne, mais la seconde tente d'ouvrir un shell et elle ne peut pas, elle échoue.
Je ne comprends pas la situation que tu as en tête. "la clé sur le bastion" = la clé publique autorisée à se connecter, celle présente dans
authorized_keys? Ou une clé privée permettant de se connecter à un serveur cible ?Dans tous les cas, si tu as une clé qui demande une confirmation physique pour chaque utilisation, elle ne peut pas être utilisée sans ton accord par l'agent SSH même en cas de forwarding d'agent sur le bastion. Cependant, le bastion peut tout de même utiliser toutes les clés auxquelles l'agent a accès pour se connecter ailleurs, donc ça reste une situation risquée. À moins de n'avoir que des clés stockées sur des yubikey et soumises à confirmation, auquel cas l'agent ne sert à rien.
Bref, je ne vois pas de situation où le forwarding d'agent serait une bonne idée.
# Le coupable probable : interception légale (et pieds nickelés)
Posté par Samuel (site web personnel) . En réponse au lien Interception de traffic sur les serveurs jabber.ru xmpp.ru. Évalué à 10. Dernière modification le 20 octobre 2023 à 21:41.
L'interception s'est faite en déroutant le trafic destiné au serveur vers un intermédiaire malveillant qui, du coup, a pu obtenir un certificat TLS valide via let's encrypt. Ça correspond à ce que propose le produit Jupiter, proposé par Nexa et vendu comme un logiciel d'interception légale (j'en parlais ici il y a quelques jours).
On note que les intercepteurs ont fait une petite boulette en oubliant de renouveller leur certificat a temps, ce qui a permis à l'administrateur système de détecter le problème.
Comme ils le notent en conclusion, la surveillance des journaux certificate transparency (cf. journal précédemment cité) aurait permis à l'administrateur de repérer le problème plus tôt. Ils notent aussi qu'on peut aussi demander à let's encrypt, via le DNS, de limiter la délivrance de certificats à un compte let's encrypt bien précis, de façon à empêcher l'attaque.
[^] # Re: un doute sur le cert LE
Posté par Samuel (site web personnel) . En réponse au journal Predator files : surveillez les logs Certificate transparency sur vos domaines. Évalué à 8.
C'est justement ce qui est fait ici : Jupiter est vendu à des États ou autorités militaires, et il est bien précisé que le site servant pour l'infection doit être "domestique", c'est-à-dire physiquement hébergé sur le territoire contrôlé par l'autorité client de l'Alliance Intellexa.
En effet, c'est une situation où "beaucoup de choses sont corrompues". Le but de ce journal est de signaler que même dans le cas où l'État fait partie de votre modèle de menace, TLS et Certificate Transparency fournissent des outils pour vous défendre.
[^] # Re: Petite question ...
Posté par Samuel (site web personnel) . En réponse au lien Contrôler l’accès aux sites web pour adultes : est-ce possible ?. Évalué à 3.
Non, le principe du double-anonymat doit te garantir que celui qui connait ton identité et donne une preuve "cette personne a plus de 18 ans" ne connait pas le destinataire de l'attestation (tu es anonyme vis-à-vis du site que tu veux visiter - modulo ta majorité ou non - et les sites que tu veux visiter ne sont pas transmis à ceux qui te connaissent).
Après, il faut que les protocoles soient correctement implémentés et que les entités qui opèrent les 2 services (site que tu visites / garant de l'identité numérique) soient réellement indépendants.
# HTTPs n'empêche pas le FAI de savoir les pages que vous consultez
Posté par Samuel (site web personnel) . En réponse au journal Comment, via un résolveur DNS alternatif, se protéger : 1) de la censure et 2) du pistage ?. Évalué à 10.
Contrairement à ce que plusieurs ont affirmé ici, utiliser httpS n'empêche pas totalement au FAI de deviner les pages que vous consultez : en faisant une analyse statistique de la taille des requêtes envoyées et reçues et les différences de temps entre les différentes requêtes, et en comparant ça au contenu du site web visité et au graphe de lien entre les pages, il peut "deviner" quelles pages vous avez visité. Selon les sites, cette attaque fonctionnera plus ou moins bien :
En revanche, les petites données que vous envoyez (mot de passe, code de carte bancaire …) ne seront pas devinables par l'attaquant.
Cette attaque est décrite dans Analysing user behaviors despite encryption sur le blog rabexc.org.
# Sécurité lourdement défaillante
Posté par Samuel (site web personnel) . En réponse au lien Testing a new encrypted messaging app's extraordinary claims. Évalué à 4.
L'application est incroyablement défaillante, à un niveau difficilement inimaginable (je vous laisse lire l'article).
Le plus incroyable, c'est leur réponse au "responsible disclosure" de l'auteur de l'article : « "How were you able to decompile the source code of the app and what do you think should be done to protect against that in the future?" ».
# redbean ?
Posté par Samuel (site web personnel) . En réponse au lien MRSK: Deploy web apps anywhere. Évalué à 2.
"Deploy web apps anywhere" me fait plutôt penser à redbean, encore plus portable! (et incroyablement plus léger).
# Mailcow ?
Posté par Samuel (site web personnel) . En réponse au message Serveur smtp/map. Évalué à 1.
Bonjour,
Ton besoin me fait penser à mailcow. Je n'ai jamais testé, donc je ne connais pas la qualité du produit.
[^] # Re: Client GitHub et serveur à la fois ?
Posté par Samuel (site web personnel) . En réponse au lien whoarethey: Determine Who Can Log In to an SSH Server. Évalué à 2.
C'est ce qu'indique la doc. man ssh_config :
# Recommandations de sécurité relatives à un système GNU/Linux de l'Anssi
Posté par Samuel (site web personnel) . En réponse au journal ssh : et si nous sensibilisions par un label, ou autre impératif?. Évalué à 7.
C'est beaucoup plus large que la configuration SSH, mais les recommandations de sécurité relatives à un système GNU/Linux proposées par l'Anssi (agence de l'État français pour la sécurité informatique) ont plein de recommandations chouettes, et classent les 80 recommandations en 4 niveaux de durcissement (minimal, intermédiaire, renforcé et élevé).
HS : Sur le port knocking comme méthode d'authentification, j'avais lu (en anglais) quelqu'un qui expliquait que ça revenait à encoder un mot de passe, éventuellement tournant (façon TOTP ou HOTP) sous forme d'une suite d'octets, et que pour gérer ça on avait rudement plus efficace que le port knocking, dans les protocoles eux-mêmes (= les modes d'authentification à clé publique proposée par SSH, ou par mot de passe pour certaines applications - mots de passe auxquels il convient de donner la longueur adéquate, cela va de soi). Je ne retrouve plus la source, si quelqu'un me lit et l'a sous le coude, je suis preneur !
(note : le commentaire cité dans l'article parle du port knocking comme d'une méthode ayant pour effet de limiter le bruit dans les logs, pas comme d'une mesure apportant une sécurité supplémentaire … donc la remarque au paragraphe précédent ne s'y oppose pas).
[^] # Re: Sécurité adaptée
Posté par Samuel (site web personnel) . En réponse au journal Mutuelle et mot de passe. Évalué à 6.
Si tu RSSI te force à changer de mot de passe, c'est :
# -> Redbean : une alternative lightweight à Docker + electron (compile once, run everywhere)
Posté par Samuel (site web personnel) . En réponse au lien Cosmopolitan : la libc pour faire des exécutables multi OS (et même sans OS). Évalué à 8.
J'aime bien aussi ce qu'elle en fait avec redbean, qui est à la fois:
- un fichier zip dans lequel on peut mettre, par exemple, des scripts JS, des pages HTML, du CSS, des scripts LUA
- un exécutable compilé contre la cosmopolitan qui fait serveur web et exécute les scripts LUA que vous voulez en réponse aux requêtes. Ça embarque sqlite en bonus si vous voulez faire du travail avec une BDD.
Du coup, vous remplissez le zip avec votre webapp et vous la mettez à disposition soit des clients finaux (-> ça fait une alternative lightweight à electron), soit sur un serveur quelconque (-> ça fait une alternative lightweight à Docker pour une part significative des usages de celui-ci).
[^] # Agilité cryptographique
Posté par Samuel (site web personnel) . En réponse au lien Bruce Schneier: NIST’s Post-Quantum Cryptography Standards. Évalué à 1.
Des critiques de l'agilité cryptographique (par exemple Against Cipher Agility in Cryptography Protocols, paragon IE, en), je retiens surtout la proposition d'utiliser des protocoles versionnés, par exemple dans la présentation de paseto, un concurrent à JWT/Jose (en) :
Ça représente une forme de souplesse cryptographique (= on peut déprécier un algo) sans laisser l'utilisateur final se tirer une balle dans le pied.
# De l'intérêt de l'authentification des connexions
Posté par Samuel (site web personnel) . En réponse au lien Retour sur une campagne de phishing qui a réussi à contourner la double authentification. Évalué à 3.
Une alternative consiste à authentifier la connexion plutôt que la session, via des certificats TLS. En plus, ça rend le phishing inopérant: une réponse valide pour attacker.tld n'est pas valide pour company.tld, donc attacker.tld ne peut pas se servir de la connexion obtenue par phishing pour se faire passer pour la victime auprès de company.tld.
L'authentification par certificat peut être à 2 facteurs si on protège la clé privée par mot de passe ou code pin.
# Un débat enflammé (en)
Posté par Samuel (site web personnel) . En réponse à la dépêche PyPI déploie le système 2FA pour les projets critiques écrits en Python. Évalué à 8.
Certains, comme Armin Ronacher se sont élevés de façon véhémente contre cette nouvelle obligation imposée aux développeurs bénévoles, qui se voient "punis" d'avoir partagé gentiment leur création.
James Bennett lui répond qu'il faut être singulièrement asocial pour refuser un geste simple qui permet de limiter les risques pour tout le monde.
Le débat n'est pas sans rappeler d'autres controverses politiques actuelles, avec peu ou prou les mêmes questions en toile de fond (qui doit imposer quoi ? au bénéfice de qui ? qui est "nous" ?)
[^] # Re: Et la sécurité ?
Posté par Samuel (site web personnel) . En réponse à la dépêche NCPA, un agent pour Nagios. Évalué à 1.
Du coup le serveur ne peut pas reconfigurer l'agent ou lui faire exécuter une commande arbitraire, exact ? (sauf plugin mal écrit…)
Merci de la précision ! Mais du coup, ça nécessite d'avoir une autorité de certification interne (ou d'en créer une pour cet usage), exact ?
# Et la sécurité ?
Posté par Samuel (site web personnel) . En réponse à la dépêche NCPA, un agent pour Nagios. Évalué à 3.
Merci pour cette présentation !
J'ai quelques questions qui me restent, notamment au regard des dégâts qu'ont pu avoir la faille solarwinds où un logiciel de supervision compromis permettait à l'intrus de prendre le contrôle de la totalité du parc :
[^] # Re: Coïncidence ?
Posté par Samuel (site web personnel) . En réponse au lien Moi, journaliste fantôme au service des lobbies…. Évalué à 6.
Oui, c'est la même source qui témoigne dans Fakir et qui a répondu à Mediapart.
Sur Mediapart, on trouve aussi une explication du ménage qu'ils ont fait dans la section participative du site (a priori en accès libre).
[^] # Re: Ah m....
Posté par Samuel (site web personnel) . En réponse au lien Le développeur de FairEmail jette l'éponge après que Google a classé l'app libre comme spyware. Évalué à 5.
K9mail. Je le trouve moins pratique, mais il est libre aussi.
[^] # Re: Bref résumé
Posté par Samuel (site web personnel) . En réponse au lien Attaque sur le format d’échange des clefs privées OpenPGP. Évalué à 2.
C'est un problème que rencontrent toutes les solutions avec du chiffrement de bout en bout qui offrent une appli web (protonmail, matrix, bitwarden, etc.) : si un pirate prend le contrôle d'un serveur qui te sert l'app (ou se place en homme du milieu entre le client et le serveur), il peut servir un JS vérolé et récupéré les secrets.
Sais-tu si des gens commencent à travailler à traiter correctement cette difficulté ?
A priori, il serait assez simple de signer le code JS avec GPG, puis de "pinner" une association clé GPG / site distant pour indiquer aux les navigateurs de n'exécuter du code depuis ce site X que s'il est correctement signé, mais je n'ai pas connaissance de réflexion ou de début de mise en œuvre.
(Se pose bien évidemment la question de la distribution de l'info "tel site requiert telle clé publique", et on retombe soit sur la PKI du web avec tous ses défauts, soit sur du TOFU, soit sur des listes préchargées, soit une autre solution à inventer).
# L'article reprend le communiqué de l'OSI et y ajoute 3 parties
Posté par Samuel (site web personnel) . En réponse au lien « Les modules de protestation [...] nuisent au mouvement open source [...] », lance l'OSI. Évalué à 10.
Attention, contrairement à ce que la présentation de l'article peut laisser entendre, seul la première partie ("L’intégralité du commentaire de l’OSI") est la traduction du communiqué de l'OSI : Open source ‘protestware’ harms Open Source.
Les parties suivantes, qui parlent de la version Notepad++ baptisée "free uyghur", ne sont pas issues du texte de l'OSI (et sont, j'imagine, l'œuvre de l'auteur de l'article indiqué sur developpez.com, Patrick Ruiz).
# Collectd, graphite, grafana, icinga2, rsyslog ou systemd-journal-remote
Posté par Samuel (site web personnel) . En réponse au message Outils de monitoring “distribué”. Évalué à 3. Dernière modification le 10 février 2022 à 13:11.
Ta demande couvre plusieurs aspects de la supervision :
En général, on veut aussi un système de vérification d'état (faire des "checks" réguliers sur les métriques et/ou les logs remontés, ou vérifier à distance que le serveur web répond bien, que le certificat n'est pas trop proche de l'expiration).
Côté métriques, tu as plusieurs écoles : telegraf/influx (mode push, supervisé -> superviseur), prometheus (mode pull), collectd avec rrd ou graphite (mode push). Dans tous les cas, la visualisation se fait souvent avec grafana. Mon option favorite, c'est collectd pour la collecte et l'envoi de métriques (installé sur les "supervisés"), graphite pour le stockage et grafana pour la visu (installés sur le superviseur). Influx est plus efficace que graphite pour le stockage des métriques, mais il rend beaucoup plus difficile l'échantillonage (passer d'une résolution de 1 mesure / minute sur les dernières 24h à 1 mesure / heure sur le dernier mois, puis 1 mesure / jour sur un an). Je préfère le "push" au "pull" pour des raisons de sécurité : je ne souhaite pas que mon système de supervision ait un accès privilégié d'une façon ou d'une autre aux autres machines (sinon, ça fait un SPOF d'un point de vue sécu).
Collectd permet de récupérer les infos via ipmi si tu ne souhaites pas utiliser sensors.
Pour l'émission d'alertes et la composition d'un tableau de bord "ce qui va / ce qui va pas", j'utilise icinga2, un nagios-like. On peut interroger graphite à partir d'icinga2 pour "surveiller" les métriques. Comme je suis devOps, j'envoie mes alertes dans gitlab.
Pour la remontée de logs, je m'appuie sur systemd-journal-upload et -remote mais j'ai rencontré une fois un bug provoquant une inflation inutile de l'espace occupé par les journaux, alors je ne suis pas sûr de le recommander. rsyslog est pas mal, mais tu collectes beaucoup moins d'info que dans le journal systemd.
Ça prend un peu de temps pour configurer ça aux petits oignons, mais ça permet ensuite d'avoir une belle visibilité sur tes systèmes.