j'ai un doute sur la construction a | b && c | d. Amha cela ne fait pas ce que tu souhaites. cat cmdline | xargs -0 n'a pas de sens non plus puisque cmdline est, comme son nom l'indique, une ligne (ou alors une sublitité m'échappe, dans quel cas je te serais reconnaissant de m'éclairer). Quelque chose de la forme grep -q log4j /proc/$pid/cmdline /proc/$pid/maps && echo $pid serait à la fois plus lisible et correct.
En résumé:
1. la sécurité dépends du maillon le plus faible
2. un commentaire sur linuxfr est à l'extrème basse du niveau de confiance (anonymes, admins bénévoles, etc)
De ce fait, qu'https soit ou non sécure* est totalement accessoire au crédit d'un post sur linuxfr. Baser son jugement sur cet unique critère est dommage pour toi, donner des leçons aux autres est méprisant (et ridicule).
*: ce n'est pas binaire—c'est ce que j'écris depuis le début—mais je te concède une ultime simplification afin de ne pas te perdre une fois de plus.
Je n'ai jamais dit qu'https ne sert à rien (relis bien la dernière phrase de mon premier message!!!), je critique ton discours en noir et blanc. Je dis que la sécurité d'https n'existe pas d'elle-même mais dépends d'au moins 3 facteurs (dans son utilisation générale (==sans configuration spécifique du client)): 1. de l'utilisateur 2. du système de CA 3. de DNS. J'ai donné 3 exemples pour chacun de ces points faibles. Si tu écartes chacun de mes exemples en disant qu'ils sont invalides (1 bookmark, 2 CA infaillible, 3 dns != http(s)), évidement le débat n'est pas possible.
Mais avant de partir dans cet argument technique (admettons qu'https n'aie aucun problème (ce qui est faux mais je veux bien bien abandonner pour te faire plaisir)), je dis simplement que de ne pas donner du crédit à quelqu'un en fonction du lien qu'il donne est absurde. Si ma page perso c'est https://gensapoils.fr , tu m'accorderas plus ou moins de crédit? Tu pense qu'il y a plus ou moins de chance de chopper un virus que de visiter http://ftp.debian.org/ ? Note bien que c'est un site en https hein…
J'attends toujours que tu réagisses à mon lien documents certaines failles du système CA. Problèmes documentés et avérés! Pas besoin de parler de la NSA ou de la Russie qui force l'installation d'une CA sur les télephonnes.
PS: L'argument, je le rappelle, est de contre-dire "ne pas mettre https facilite la propagation de malware grâce au mitm", je ne prétends pas réinventer la sécurité informatique ou de pouvoir casser https dans tous les cas, je pointe juste un contre-exemple où cela ne sert à rien.
Oui, la redirection est en http. J'ai fais le raccourci car je ne voulais pas rendre plus lourd la discussion qui l'est déjà, et vu le commentaire auquel je répondais, cela me semblait évident de ne pas devoir le mentionner.
client: dns/udp qui a mon-blog.fr ?
hacker: mon-blog.fr est 1.2.3.4
client: https get Host: mon-blog.fr 1.2.3.4
hacker: RST
client: http get Host: mon-blog.fr
hacker: 301 https://m0n-blog.fr
Voilà, un mitm du pauvre. Après il y a certaines contre-mesures côté client, mais si on part du principe que le site est visité pour la première fois, ça peut marcher. Il suffit juste d'avoir un domaine qui permet de générer des homonymes visuels (et avec LE, on génère le certificat à la demande). C'est pas tellement plus compliqué qu'un mitm en pure http…
Mais bon… on peut arguer pendant des heures sur le fait qu'un mitm est un treath model réaliste ou pas, je ne comprends pas la pertinence de dire que parce quelqu'un publie l'adresse d'un site http, ses propos sur la sécurité sont peu crédibles. On ne sait même pas si c'est son site. Et on s'en fout.
La sécurité c'est une question de chaîne de confiance (DNS, CA, prestataire du service, réseau, etc.), et la confiance est une valeure graduelle. On applique une exigeance de garanties différente en fonction du contexte. C'est nuancé, c'est faire la part des chose… Publier son blog en http ça n'est pas la fin du monde, publier des mirroirs de logiciels sur http ça a certains avantages (moins de resources) sans compromettre l'authenticité garantie par un système de signature hors-bande. Aller sur sa banque en ligne avec le laptop de l'entreprise dans le réseau de celle-ci, hors de question: le fait que le site de la banque propose https n'est pas suffisant, les autres maillons sont trop faibles pour garantir l'absence d'un MitM.
Oui, enfin le requirement dnssec c'est moi qui l'ai introduit. DNSSEC n'est pas utilisé de manière majoritaire alors que c'est la base pour que https soit fiable. Promouvoir sa généralisation est à mon avis plus productif que de s'acharner sur les sites perso qui ne proposent pas https.
bookmark
Il faudrait savoir, tu veux te protéger de n'importe quel site ou un site précis finalement ? Si tu changes ton threat-model à chaque réponse, la discussion devient compliquée.
Et sur des réseaux d'entreprise […] c'est beaucoup plus fréquent que tu ne pourrais le penser.
Typiquement des réseaux où tu n'as pas dnssec, et une CA d'entreprise* donc… pré-requis 2&3 manquant. Dans ce cas de figure, le fait qu'un site perso soit uniquement accessible en clair est certainement le dernier de mes soucis.
M'accuser de ne pas faire la part des choses, alors que tu ne comprends pas comment le simple fait de ne pas utiliser HTTPS peut faciliter la propagation de scripts malveillants
J'ai de mauvaises nouvelles pour toi: 1) obtenir un certificat https est à la portée de tout le monde, c'est toi qui l'as dit (y compris des pirates donc) 2) un mitm n'est clairement pas la technique la plus répandue/efficace pour propager des malwares.
Je te propos un autre scénario: de retour au mc-do (ou dans ton entreprise), un petit malin intercepte les requetes dns mon-blog.fr, puis fait un redirect sur https://m0m-blog.fr Je résume: j'ai un cadena mais le pirate peut lire tout le contenu de ma lecture voir remplacer mes images. Le fait que mon-blog.fr soit disponible ou non en https ne change rien.
*:(ou pire un proxy https MITM au nom de la sacro-sainte sécurité)
qu'on favorise soi-même la propagation de ransomware
S'il voulait vraiment favoriser la propagation de ransomware, il aurait mis https et des virus sur son site.
il n'y a pas besoin de cibler un site en particulier
Donc il reste le point 2. (CA) et 3. (DNS) à régler, je maintiens proposer https ne résoud pas ces problèmes…
profiter des failles de ton système, de ton navigateur
idem, en quoi proposer https sur son site perso supprime les failles des visiteurs potentiels?
Ne pas vouloir faire la part des choses ("favoriser […] la propagation des ransonware", ben voyons…), c'est exactement l'attitude qui m'exaspère et que je dénnonçais dans mon message précédent. Mais ce n'est pas grâve, je te laisse à tes certitudes.
(enfin bon pour la vérif c'est quif-quif, c'est tout aussi facile où que soient fait les hardlinks, faut juste pas oublier le --inplace si c'est fait côté destination). donc bref, je retire ce que je dis :D
Bonne idée, si je peux me permettre le plus simple serait de gèrer les liens côté source, avec comme avantage: ne pas devoir gèrer le 'inplace' et une vérification ultra simple: find dirsource dir_liens -type f \! -links 2, et pour enlever les liens exédentaires find dir_liens -type f -links 1 -delete.
Https ne te protège que dans une infime mesure, en l'occurrence pour l'example donné: 1. tu connais l'url de téléchargement par coeur (généralement les gens/moi prennent le premiere résultat sur google…), 2. tu audites ta liste de CA (généralement les gens/moi font confiance à mozilla, MS ou apple—qui sont loin d'être des entreprises philantropiques) (3. tu utilises dnssec).
Il faut un peu arrêter de raisonner par réflexe et vouloir donner des leçons à tout le monde. Le gars qui est prêt à donner plus de crédit à un blog random parce qu'il y a un cadena dans la bare d'adresse, ou pire dénigrer ceux qui n'en n'ont pas, il devrait commencer par apprendre à réfléchir pour soit-même.
(qu'on ne me fasse par dire ce que je n'ai pas dit, exiger https pour visiter le site de sa banque en ligne est une bonne chose… pour un blog, peut-être pas…)
Au fait, si tu cherches toujours un portable d'occasion, je veux bien t'en offrir un contre ton M1, ça t'évitera de devenir captif et ça me donnera bonne conscience ;-)
Je mettrai ton M1 dans mon salon, pour faire chic.
Regardes toujours du côté du traffic dns, au cas où ton tomcat/app ferait des résolutions inverses. Peut-être un truc qui a changé au niveau de la glibc, ou cette crasse de systemd-resolvd qui a décidé de changer de dns parcequ'il y a eu un drop UDP (quelle crasse ce truc, je me répète)… 'fin au doigt mouillé, je dirais ça, un timeout réseau quelque part, voir un rate limiting à l'extérieur… La version de la JVM a aussi peut-être changé quant à la gestion du cache DNS ou à la préférence IPv4/IPv6. Un tcpdump sur autre chose que ton port 8080 pourra peut-être t'éclairer…
La plupart des admins windows le font mensuellement, un sysadmin unix/linux qui ne le fait pas ou n'en est pas capable est une honte pour la profession.
Des entreprise où tu as une équipe d'admin windows mais qu'un seul sysadmin linux, j'ai vu ça aussi… Entre la db oracle, le(s) site(s) web, les serveurs d'applications, on hésiterait bien deux fois avant de tout mettre à jour (qui plus est, de manière automatique). Dans les entreprises mixtes linux/windows, les trucs un peu pointus ont tendance à se trouver sous linux (sinon pourquoi avoir du linux?), et ce sont rarement des trucs évidents à automatiser/clusteriser/etc. Possible, certes comme tu dis "bonne gestion et connaissance des applis clusterisées, des fenêtres de maintenance bien précises pour les bascules de noeud primaires, etc." mais l'adminsys s'il est tout seul n'a jamais eu le temps de préparer cela pour chaque type d'application différente, et dans ce cas on appelle un contractant (comme toi si j'ai bien compris… ).
À côté de ça, mettre-à-jour un clusteur d'Active Directory, un exchange ou un parc de desktop, cela me semble assez banale finalement, et puis ça justifie bien le salaire de deux ou trois admins windows.
Et si tu grattes un peu, tu trouveras aussi une application critiques sous windows, et comme par hasard, elle n'est pas mise-à-jour… Et c'est soit une application hyper spécifique, ou un setup hyper customisé… Genre un apache httpd avec un cgi écrit en visualbasic qui gère la borne du parking, tu vois, ce genre de truc.
Alors que cela ne soit pas les bonnes pratiques, ok, mais avant de parler de honte pour la profession peut-être qu'il faut essayer de comparer ce qui est comparable au niveau de l'effort-coût et des ressources (temps-homme) mises en oeuvres par la direction? Il faut bien tout comparer: 1) la complexité de l'application 2) sa criticité 3) les ressources disponibles.
La différence d'effectifs admin win/unix peut s'expliquer assez facilement:
Linux a longtemps été bien plus facile à mettre à jour qu'un Windows (apt-get existait bien avant qu'active directory fut une chose). Aussi l'équipe windows a un périmètre qui s'étend à tous les utilisateurs. Le jour où tous les desktop se sont retrouvés bloqués, le budget pour engager des winsys supplémentaire a subitement été débloqué. Entre temps, Windows s'est amélioré au niveau de la facilité d'administration. D'un autre côté, on n'a pas cessé de complexifier les applications qui tournent sous linux (un truc "HA" par ici, un autre truc proprio par là, etc). Il s'en suit, je pense, que cela a entrainé un certain déséquilibre dans le recrutement des équipes IT, qui n'est plus en phase avec les besoins actuels.
OVH a préconisé cette méthode par mail dès le 13 mars
je n'ai pas reçu les même mails, force est de constater. Le mail du 13 mars contient chez moi:
«Pour vos activités les plus critiques, qui nécessitent un redémarrage plus rapide, nous vous conseillons de commander une solution alternative dans notre datacentre de Gravelines (GRA), dans lequel nous renforçons nos capacités. Dans ce cas, la gratuité sera appliquée a posteriori sur ce nouveau service.»
Donc tu commandes un nouveau service, mais celui pour lequel tu as déjà payé et dont tu n'as plus besoin vu que tu dois en commander un nouveau, on ne te dit pas si tu vas être rembourser (non tu ne le seras pas).
3h
arf, c'est clair qu'ils sont plus réactifs lorsqu'il s'agit de faire rentrer des sous…
Dans un sens, c'est peut être une bonne chose cet incendie, car cela a montré aux gens l'importance d'avoir des sauvegardes et des plans de reprise d'activité.
(J'aimerais bien voir ton PRA sur un serveur perso ;-) je suis d'accord avec cet argument, mais cela ne dédouane pas ovh pour autant. C'est comme dire "ah j'ai accidenté ta voiture… comme quoi, on a bien fait d'imposer le port de la ceinture de sécurité".
La moindre des chose c'est de faire en sorte que cela soit le moins douloureux pour leurs clients, pas de simplement faire du bullshit commercial comme ils l'ont fait. Tu le dis toi même, ça ne t'as pas trop impacté car tu étais bien préparé (et tu payais au mois ou tu as un volume de commande suffisant pour que cela ne te gène pas). Si tu réinstalle 15 serveurs par mois, cela t'impacte forcément moins. Cela ne veut pas dire que le gus (moi) qui n'a qu'un serveur ne fait pas bien son boulot…
j'interprète ça comme "je n'ai pas de backup"
je me suis mal exprimé alors, je voulais dire qu'au contraire ayant été témoin de précédents problèmes chez ovh, j'avais assuré mes arrières. Il n'empêche, que cela aie pris 5 minutes (propagation dns toussa…) ou 5 heures, le faire 2 fois est toujours 2 fois plus coûteux. Ne pas pas vouloir admettre ce fait, c'est une forme d'incompétence, je suis désolé mais ce métier impose une certaine forme de rigueur mathématique.
Donc bref, le temps que j'ai perdu je l'aurais bien passé à autre chose, c'est pour cela que le multiplier par deux n'est pas acceptable. Commenter sur linuxfr, c'est un hobby :)
À cause du "libre"-washing probablement (de la monnaie "libre", très amusant comme concept, on m'en remet un peu?). Peut-être aussi à cause de la logique très approximative: "il y a plus de X.. on voit bien que X est une voie de garage" (heu il dit qu'il ne voit pas le rapport). Sinon peut-être parce que l'auteur est un énergumène qui s'amuse à propager des idéologies qui n'ont rien à faire sur ce site depuis de trop longues années (regarde parmis ses journaux… parmis 2-3 truc dans le sujet, dès qu'il a du karma il ne gène pas on dirait…). À vrai dire, je n'en sais rien et je m'en fout. La science du -1 est impénétrable.
Laisse tomber, c'est un attrape nigeau pour ceux qui pensent pouvoir spéculer, comme toutes les autre crypto monnaie. Va plustôt donner ton fric aux bonnes oeuvres si tu en as trop ;)
Zurvan est connu ici pour avoir défendu des thèses d'extrème droite très dures. De là, on peut imaginer qu'il est suceptible de suivre n'importe quel autre délire idéologique, tel que celui de penser qu'une crypto monnaie puisse survivre à la chute d'un système économique, voir que le système économique est en train de se vautrer. À mon avis pour ce genre de cas, une puce à l'oreille ne sert à rien, il faut d'abord retirer la poutre dans l'oeil.
Au fait, seaweedfs permet depuis peu de répliquer vers un autre S3, ce qui peut être utile pour limiter les coûts quand on a beaucoup de données mais avec des besoins d'accès différents (froid/chaud).
moi aussi j'aime bien seaweedfs… j'ai un peu peur que ce soit un single-man project avec de temps à autres de bugs assez "gros", mais sinon c'est sexy et assez amusant à utiliser (la réplication active-active ou active-passive du filer/s3 par bucket, la topologie flexible, miam :) .
Oops pardon, j'ai lu de travers et je pensais que nextcloud proposait un service s3 et que tu critiquais le fais qu'il ne permettait pas un chiffrement au travers de ce sevice. Je suis bien d'accord avec ta critique.
…est-ce qu'il n'est pas plus simple de mettre le chiffrement au niveau fs ou stockage (luks) pour avoir du même coup le chiffrement de toutes les méta-données (par là j'entends les logs, la base relationnel, etc.)
…est-ce qu'il n'est pas plus simple de stocker des objects déjà chiffrés dans s3, afin de ne pas dépendre de la technologie sous-jacente ?
Ou bien tu penses plus à quelque chose du style "server side encryption" (je ne me souvient plus du nom exacte) de s3 ? À mon sens, pour le commanditaire ce n'est qu'une façon de cocher une case dans un cahier des charges, ou pour aws (d'une manière plus positive :p), une façon de te faire payer plus cher quelque chose qui a un coup marginal. Si c'est vraiment ça que tu veux, même si c'est sans doute vrai que techniquement il s'agit simplement d'envoyer une clef de chiffrement à l'object store, amha ça serait toujours un peu bancale car il manquera l'intégration du gestionnaire d'accès et de secrets qu'offre une plateforme "nuage". (pour le côté positif: la possibilité d'auditer la qualité de l'implémentation, ce que ne permet pas un provider cloud commercial… d'où mon sentiment qu'il s'agit dans la majorité des cas d'un besoin "cocher une case": si tu veux être sûr, tu chiffres avant de stocker dans s3)
Est-ce que la base de données sur ses 2 versions serait différente ?
oui, la version 13 est sensé contenir la même chose qu'il y a avait au moment où le script de post-installation de la version 13 a tourné. Les 2 clusters (c'est le nom donné à une simple instance d'un serveur postgresql) utilisent un répertoire de données distinct, car le format binaire entre version majeur n'est pas compatible. Les outils pg_cluster sont des outils spécifiques au packaging debian qui permettent de faire tourner facilement un ou plusieurs server pg sur le même hôte, en s'occupant notemment de leur initialization (et accessoirement de gèrer des upgrades donc). Normalement tu as du voir un message explicatif durant l'upgrade…
Comment faire pour supprimer la version 11 ?
man pg_dropcluster
Aucune conséquence particulière ?
la version 13 tourne sur un autre port, 5433 en toute vraissemblance (pg_lsclusters)
Si l'application n'a pas été modifiée pour communiqué avec la version 13 (changer de port, donc) au moment de la mise à jour, il est fort probable que les données de la version 13 sont déjà obsolètes…
[^] # Re: Une ligne de commande pour savoir si on est impacté ou pas par la faille
Posté par benja . En réponse à la dépêche Détectez et bloquez les tentatives d'exploitation de Log4j avec CrowdSec. Évalué à 1.
(Bon je viens d'apprendre que xargs sans commande équivaut à echo. Je ne comprends pas trop l'intérêt de cette construction… bref)
Chez moi grep log4j dans /proc/pid/map ne fonctionne pas, sur un process java qui utilise log4, avec openjdk11 sur debian stable.
[^] # Re: Une ligne de commande pour savoir si on est impacté ou pas par la faille
Posté par benja . En réponse à la dépêche Détectez et bloquez les tentatives d'exploitation de Log4j avec CrowdSec. Évalué à 2. Dernière modification le 16 décembre 2021 à 14:42.
j'ai un doute sur la construction
a | b && c | d. Amha cela ne fait pas ce que tu souhaites.cat cmdline | xargs -0n'a pas de sens non plus puisque cmdline est, comme son nom l'indique, une ligne (ou alors une sublitité m'échappe, dans quel cas je te serais reconnaissant de m'éclairer). Quelque chose de la formegrep -q log4j /proc/$pid/cmdline /proc/$pid/maps && echo $pidserait à la fois plus lisible et correct.[^] # Re: Windows, c'est de la verole à ransomware
Posté par benja . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 2. Dernière modification le 12 décembre 2021 à 17:19.
En résumé:
1. la sécurité dépends du maillon le plus faible
2. un commentaire sur linuxfr est à l'extrème basse du niveau de confiance (anonymes, admins bénévoles, etc)
De ce fait, qu'https soit ou non sécure* est totalement accessoire au crédit d'un post sur linuxfr. Baser son jugement sur cet unique critère est dommage pour toi, donner des leçons aux autres est méprisant (et ridicule).
*: ce n'est pas binaire—c'est ce que j'écris depuis le début—mais je te concède une ultime simplification afin de ne pas te perdre une fois de plus.
[^] # Re: Windows, c'est de la verole à ransomware
Posté par benja . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 2.
Je n'ai jamais dit qu'https ne sert à rien (relis bien la dernière phrase de mon premier message!!!), je critique ton discours en noir et blanc. Je dis que la sécurité d'https n'existe pas d'elle-même mais dépends d'au moins 3 facteurs (dans son utilisation générale (==sans configuration spécifique du client)): 1. de l'utilisateur 2. du système de CA 3. de DNS. J'ai donné 3 exemples pour chacun de ces points faibles. Si tu écartes chacun de mes exemples en disant qu'ils sont invalides (1 bookmark, 2 CA infaillible, 3 dns != http(s)), évidement le débat n'est pas possible.
Mais avant de partir dans cet argument technique (admettons qu'https n'aie aucun problème (ce qui est faux mais je veux bien bien abandonner pour te faire plaisir)), je dis simplement que de ne pas donner du crédit à quelqu'un en fonction du lien qu'il donne est absurde. Si ma page perso c'est https://gensapoils.fr , tu m'accorderas plus ou moins de crédit? Tu pense qu'il y a plus ou moins de chance de chopper un virus que de visiter http://ftp.debian.org/ ? Note bien que c'est un site en https hein…
J'attends toujours que tu réagisses à mon lien documents certaines failles du système CA. Problèmes documentés et avérés! Pas besoin de parler de la NSA ou de la Russie qui force l'installation d'une CA sur les télephonnes.
[^] # Re: Windows, c'est de la verole à ransomware
Posté par benja . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 1.
PS: L'argument, je le rappelle, est de contre-dire "ne pas mettre https facilite la propagation de malware grâce au mitm", je ne prétends pas réinventer la sécurité informatique ou de pouvoir casser https dans tous les cas, je pointe juste un contre-exemple où cela ne sert à rien.
[^] # Re: Windows, c'est de la verole à ransomware
Posté par benja . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 1. Dernière modification le 12 décembre 2021 à 10:44.
Ça marche si l'utilisateur tape l'url… sans le 's' (ou sans le scheme), on est bien d'accord.
[^] # Re: Windows, c'est de la verole à ransomware
Posté par benja . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 1. Dernière modification le 11 décembre 2021 à 20:28.
Oui, la redirection est en http. J'ai fais le raccourci car je ne voulais pas rendre plus lourd la discussion qui l'est déjà, et vu le commentaire auquel je répondais, cela me semblait évident de ne pas devoir le mentionner.
client: dns/udp qui a mon-blog.fr ?
hacker: mon-blog.fr est 1.2.3.4
client: https get Host: mon-blog.fr 1.2.3.4
hacker: RST
client: http get Host: mon-blog.fr
hacker: 301 https://m0n-blog.fr
Voilà, un mitm du pauvre. Après il y a certaines contre-mesures côté client, mais si on part du principe que le site est visité pour la première fois, ça peut marcher. Il suffit juste d'avoir un domaine qui permet de générer des homonymes visuels (et avec LE, on génère le certificat à la demande). C'est pas tellement plus compliqué qu'un mitm en pure http…
Mais bon… on peut arguer pendant des heures sur le fait qu'un mitm est un treath model réaliste ou pas, je ne comprends pas la pertinence de dire que parce quelqu'un publie l'adresse d'un site http, ses propos sur la sécurité sont peu crédibles. On ne sait même pas si c'est son site. Et on s'en fout.
La sécurité c'est une question de chaîne de confiance (DNS, CA, prestataire du service, réseau, etc.), et la confiance est une valeure graduelle. On applique une exigeance de garanties différente en fonction du contexte. C'est nuancé, c'est faire la part des chose… Publier son blog en http ça n'est pas la fin du monde, publier des mirroirs de logiciels sur http ça a certains avantages (moins de resources) sans compromettre l'authenticité garantie par un système de signature hors-bande. Aller sur sa banque en ligne avec le laptop de l'entreprise dans le réseau de celle-ci, hors de question: le fait que le site de la banque propose https n'est pas suffisant, les autres maillons sont trop faibles pour garantir l'absence d'un MitM.
[^] # Re: Windows, c'est de la verole à ransomware
Posté par benja . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 2.
Oui, enfin le requirement dnssec c'est moi qui l'ai introduit. DNSSEC n'est pas utilisé de manière majoritaire alors que c'est la base pour que https soit fiable. Promouvoir sa généralisation est à mon avis plus productif que de s'acharner sur les sites perso qui ne proposent pas https.
Il faudrait savoir, tu veux te protéger de n'importe quel site ou un site précis finalement ? Si tu changes ton threat-model à chaque réponse, la discussion devient compliquée.
Typiquement des réseaux où tu n'as pas dnssec, et une CA d'entreprise* donc… pré-requis 2&3 manquant. Dans ce cas de figure, le fait qu'un site perso soit uniquement accessible en clair est certainement le dernier de mes soucis.
J'ai de mauvaises nouvelles pour toi: 1) obtenir un certificat https est à la portée de tout le monde, c'est toi qui l'as dit (y compris des pirates donc) 2) un mitm n'est clairement pas la technique la plus répandue/efficace pour propager des malwares.
Je te propos un autre scénario: de retour au mc-do (ou dans ton entreprise), un petit malin intercepte les requetes dns mon-blog.fr, puis fait un redirect sur https://m0m-blog.fr Je résume: j'ai un cadena mais le pirate peut lire tout le contenu de ma lecture voir remplacer mes images. Le fait que mon-blog.fr soit disponible ou non en https ne change rien.
*:(ou pire un proxy https MITM au nom de la sacro-sainte sécurité)
[^] # Re: Windows, c'est de la verole à ransomware
Posté par benja . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 4.
Pas du tout, es-tu sûr de m'avoir lu et compris ? pour 1: seo, typosquatting, etc, pour 2: https://sslmate.com/resources/certificate_authority_failures et pour 3 ça me semble évident que c'est une attaque remote…
S'il voulait vraiment favoriser la propagation de ransomware, il aurait mis https et des virus sur son site.
Donc il reste le point 2. (CA) et 3. (DNS) à régler, je maintiens proposer https ne résoud pas ces problèmes…
idem, en quoi proposer https sur son site perso supprime les failles des visiteurs potentiels?
Ne pas vouloir faire la part des choses ("favoriser […] la propagation des ransonware", ben voyons…), c'est exactement l'attitude qui m'exaspère et que je dénnonçais dans mon message précédent. Mais ce n'est pas grâve, je te laisse à tes certitudes.
[^] # Re: Une idée de contournement
Posté par benja . En réponse au message rsync, plusieurs sources, plusieurs destination. Évalué à 1. Dernière modification le 10 décembre 2021 à 17:09.
(enfin bon pour la vérif c'est quif-quif, c'est tout aussi facile où que soient fait les hardlinks, faut juste pas oublier le --inplace si c'est fait côté destination). donc bref, je retire ce que je dis :D
[^] # Re: Une idée de contournement
Posté par benja . En réponse au message rsync, plusieurs sources, plusieurs destination. Évalué à 1. Dernière modification le 10 décembre 2021 à 17:01.
Bonne idée, si je peux me permettre le plus simple serait de gèrer les liens côté source, avec comme avantage: ne pas devoir gèrer le 'inplace' et une vérification ultra simple:
find dirsource dir_liens -type f \! -links 2, et pour enlever les liens exédentairesfind dir_liens -type f -links 1 -delete.[^] # Re: Windows, c'est de la verole à ransomware
Posté par benja . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 4. Dernière modification le 10 décembre 2021 à 16:19.
Https ne te protège que dans une infime mesure, en l'occurrence pour l'example donné: 1. tu connais l'url de téléchargement par coeur (généralement les gens/moi prennent le premiere résultat sur google…), 2. tu audites ta liste de CA (généralement les gens/moi font confiance à mozilla, MS ou apple—qui sont loin d'être des entreprises philantropiques) (3. tu utilises dnssec).
Il faut un peu arrêter de raisonner par réflexe et vouloir donner des leçons à tout le monde. Le gars qui est prêt à donner plus de crédit à un blog random parce qu'il y a un cadena dans la bare d'adresse, ou pire dénigrer ceux qui n'en n'ont pas, il devrait commencer par apprendre à réfléchir pour soit-même.
(qu'on ne me fasse par dire ce que je n'ai pas dit, exiger https pour visiter le site de sa banque en ligne est une bonne chose… pour un blog, peut-être pas…)
[^] # Re: Twitter
Posté par benja . En réponse au message Linux sur MacBook Air m1 ( résolu ). Évalué à 1. Dernière modification le 16 novembre 2021 à 23:51.
Au fait, si tu cherches toujours un portable d'occasion, je veux bien t'en offrir un contre ton M1, ça t'évitera de devenir captif et ça me donnera bonne conscience ;-)
Je mettrai ton M1 dans mon salon, pour faire chic.
# on sait jamais, le grand classique
Posté par benja . En réponse au message Tomcat - Application qui devient lente sans raison apparente. Évalué à 3.
Regardes toujours du côté du traffic dns, au cas où ton tomcat/app ferait des résolutions inverses. Peut-être un truc qui a changé au niveau de la glibc, ou cette crasse de systemd-resolvd qui a décidé de changer de dns parcequ'il y a eu un drop UDP (quelle crasse ce truc, je me répète)… 'fin au doigt mouillé, je dirais ça, un timeout réseau quelque part, voir un rate limiting à l'extérieur… La version de la JVM a aussi peut-être changé quant à la gestion du cache DNS ou à la préférence IPv4/IPv6. Un tcpdump sur autre chose que ton port 8080 pourra peut-être t'éclairer…
[^] # Re: limite mémoire de la JVM
Posté par benja . En réponse au message Tomcat - Application qui devient lente sans raison apparente. Évalué à 1.
Dans ce cas cela se verrait au niveau de la charge cpu.
[^] # Re: Utilisation en production
Posté par benja . En réponse au journal RHEL 9 beta is out : 1 an après , quid des successeurs ? . Évalué à 1.
Des entreprise où tu as une équipe d'admin windows mais qu'un seul sysadmin linux, j'ai vu ça aussi… Entre la db oracle, le(s) site(s) web, les serveurs d'applications, on hésiterait bien deux fois avant de tout mettre à jour (qui plus est, de manière automatique). Dans les entreprises mixtes linux/windows, les trucs un peu pointus ont tendance à se trouver sous linux (sinon pourquoi avoir du linux?), et ce sont rarement des trucs évidents à automatiser/clusteriser/etc. Possible, certes comme tu dis "bonne gestion et connaissance des applis clusterisées, des fenêtres de maintenance bien précises pour les bascules de noeud primaires, etc." mais l'adminsys s'il est tout seul n'a jamais eu le temps de préparer cela pour chaque type d'application différente, et dans ce cas on appelle un contractant (comme toi si j'ai bien compris… ).
À côté de ça, mettre-à-jour un clusteur d'Active Directory, un exchange ou un parc de desktop, cela me semble assez banale finalement, et puis ça justifie bien le salaire de deux ou trois admins windows.
Et si tu grattes un peu, tu trouveras aussi une application critiques sous windows, et comme par hasard, elle n'est pas mise-à-jour… Et c'est soit une application hyper spécifique, ou un setup hyper customisé… Genre un apache httpd avec un cgi écrit en visualbasic qui gère la borne du parking, tu vois, ce genre de truc.
Alors que cela ne soit pas les bonnes pratiques, ok, mais avant de parler de honte pour la profession peut-être qu'il faut essayer de comparer ce qui est comparable au niveau de l'effort-coût et des ressources (temps-homme) mises en oeuvres par la direction? Il faut bien tout comparer: 1) la complexité de l'application 2) sa criticité 3) les ressources disponibles.
La différence d'effectifs admin win/unix peut s'expliquer assez facilement:
Linux a longtemps été bien plus facile à mettre à jour qu'un Windows (apt-get existait bien avant qu'active directory fut une chose). Aussi l'équipe windows a un périmètre qui s'étend à tous les utilisateurs. Le jour où tous les desktop se sont retrouvés bloqués, le budget pour engager des winsys supplémentaire a subitement été débloqué. Entre temps, Windows s'est amélioré au niveau de la facilité d'administration. D'un autre côté, on n'a pas cessé de complexifier les applications qui tournent sous linux (un truc "HA" par ici, un autre truc proprio par là, etc). Il s'en suit, je pense, que cela a entrainé un certain déséquilibre dans le recrutement des équipes IT, qui n'est plus en phase avec les besoins actuels.
[^] # Re: Même constat chez OVH
Posté par benja . En réponse au journal Intégration continue - Travis, la stratégie commerciale défaillante ?. Évalué à 0. Dernière modification le 16 novembre 2021 à 20:46.
je n'ai pas reçu les même mails, force est de constater. Le mail du 13 mars contient chez moi:
«Pour vos activités les plus critiques, qui nécessitent un redémarrage plus rapide, nous vous conseillons de commander une solution alternative dans notre datacentre de Gravelines (GRA), dans lequel nous renforçons nos capacités. Dans ce cas, la gratuité sera appliquée a posteriori sur ce nouveau service.»
Donc tu commandes un nouveau service, mais celui pour lequel tu as déjà payé et dont tu n'as plus besoin vu que tu dois en commander un nouveau, on ne te dit pas si tu vas être rembourser (non tu ne le seras pas).
arf, c'est clair qu'ils sont plus réactifs lorsqu'il s'agit de faire rentrer des sous…
(J'aimerais bien voir ton PRA sur un serveur perso ;-) je suis d'accord avec cet argument, mais cela ne dédouane pas ovh pour autant. C'est comme dire "ah j'ai accidenté ta voiture… comme quoi, on a bien fait d'imposer le port de la ceinture de sécurité".
La moindre des chose c'est de faire en sorte que cela soit le moins douloureux pour leurs clients, pas de simplement faire du bullshit commercial comme ils l'ont fait. Tu le dis toi même, ça ne t'as pas trop impacté car tu étais bien préparé (et tu payais au mois ou tu as un volume de commande suffisant pour que cela ne te gène pas). Si tu réinstalle 15 serveurs par mois, cela t'impacte forcément moins. Cela ne veut pas dire que le gus (moi) qui n'a qu'un serveur ne fait pas bien son boulot…
je me suis mal exprimé alors, je voulais dire qu'au contraire ayant été témoin de précédents problèmes chez ovh, j'avais assuré mes arrières. Il n'empêche, que cela aie pris 5 minutes (propagation dns toussa…) ou 5 heures, le faire 2 fois est toujours 2 fois plus coûteux. Ne pas pas vouloir admettre ce fait, c'est une forme d'incompétence, je suis désolé mais ce métier impose une certaine forme de rigueur mathématique.
Donc bref, le temps que j'ai perdu je l'aurais bien passé à autre chose, c'est pour cela que le multiplier par deux n'est pas acceptable. Commenter sur linuxfr, c'est un hobby :)
[^] # Re: Moinsé ?
Posté par benja . En réponse au journal la monnaie libre présentée par son créateur. Évalué à 2. Dernière modification le 16 novembre 2021 à 19:50.
À cause du "libre"-washing probablement (de la monnaie "libre", très amusant comme concept, on m'en remet un peu?). Peut-être aussi à cause de la logique très approximative: "il y a plus de X.. on voit bien que X est une voie de garage" (heu il dit qu'il ne voit pas le rapport). Sinon peut-être parce que l'auteur est un énergumène qui s'amuse à propager des idéologies qui n'ont rien à faire sur ce site depuis de trop longues années (regarde parmis ses journaux… parmis 2-3 truc dans le sujet, dès qu'il a du karma il ne gène pas on dirait…). À vrai dire, je n'en sais rien et je m'en fout. La science du -1 est impénétrable.
[^] # Re: Si je me souviens bien ...
Posté par benja . En réponse au journal la monnaie libre présentée par son créateur. Évalué à -3.
Laisse tomber, c'est un attrape nigeau pour ceux qui pensent pouvoir spéculer, comme toutes les autre crypto monnaie. Va plustôt donner ton fric aux bonnes oeuvres si tu en as trop ;)
[^] # Re: Heu...
Posté par benja . En réponse au journal la monnaie libre présentée par son créateur. Évalué à 4.
Zurvan est connu ici pour avoir défendu des thèses d'extrème droite très dures. De là, on peut imaginer qu'il est suceptible de suivre n'importe quel autre délire idéologique, tel que celui de penser qu'une crypto monnaie puisse survivre à la chute d'un système économique, voir que le système économique est en train de se vautrer. À mon avis pour ce genre de cas, une puce à l'oreille ne sert à rien, il faut d'abord retirer la poutre dans l'oeil.
[^] # Re: J'achète !
Posté par benja . En réponse au journal CFS : Système de fichiers sur stockage objet. Évalué à 2.
Au fait, seaweedfs permet depuis peu de répliquer vers un autre S3, ce qui peut être utile pour limiter les coûts quand on a beaucoup de données mais avec des besoins d'accès différents (froid/chaud).
[^] # Re: J'achète !
Posté par benja . En réponse au journal CFS : Système de fichiers sur stockage objet. Évalué à 3. Dernière modification le 09 novembre 2021 à 22:21.
moi aussi j'aime bien seaweedfs… j'ai un peu peur que ce soit un single-man project avec de temps à autres de bugs assez "gros", mais sinon c'est sexy et assez amusant à utiliser (la réplication active-active ou active-passive du filer/s3 par bucket, la topologie flexible, miam :) .
[^] # Re: chiffrement
Posté par benja . En réponse au journal CFS : Système de fichiers sur stockage objet. Évalué à 1.
Oops pardon, j'ai lu de travers et je pensais que nextcloud proposait un service s3 et que tu critiquais le fais qu'il ne permettait pas un chiffrement au travers de ce sevice. Je suis bien d'accord avec ta critique.
[^] # Re: chiffrement
Posté par benja . En réponse au journal CFS : Système de fichiers sur stockage objet. Évalué à 1. Dernière modification le 09 novembre 2021 à 22:09.
D'un autre côté…
…est-ce qu'il n'est pas plus simple de mettre le chiffrement au niveau fs ou stockage (luks) pour avoir du même coup le chiffrement de toutes les méta-données (par là j'entends les logs, la base relationnel, etc.)
…est-ce qu'il n'est pas plus simple de stocker des objects déjà chiffrés dans s3, afin de ne pas dépendre de la technologie sous-jacente ?
Ou bien tu penses plus à quelque chose du style "server side encryption" (je ne me souvient plus du nom exacte) de s3 ? À mon sens, pour le commanditaire ce n'est qu'une façon de cocher une case dans un cahier des charges, ou pour aws (d'une manière plus positive :p), une façon de te faire payer plus cher quelque chose qui a un coup marginal. Si c'est vraiment ça que tu veux, même si c'est sans doute vrai que techniquement il s'agit simplement d'envoyer une clef de chiffrement à l'object store, amha ça serait toujours un peu bancale car il manquera l'intégration du gestionnaire d'accès et de secrets qu'offre une plateforme "nuage". (pour le côté positif: la possibilité d'auditer la qualité de l'implémentation, ce que ne permet pas un provider cloud commercial… d'où mon sentiment qu'il s'agit dans la majorité des cas d'un besoin "cocher une case": si tu veux être sûr, tu chiffres avant de stocker dans s3)
# postgresql-common
Posté par benja . En réponse au message [Résolu] : Debian - Passage de postgresql version 11 à 13. Évalué à 2. Dernière modification le 27 octobre 2021 à 20:31.
oui, la version 13 est sensé contenir la même chose qu'il y a avait au moment où le script de post-installation de la version 13 a tourné. Les 2 clusters (c'est le nom donné à une simple instance d'un serveur postgresql) utilisent un répertoire de données distinct, car le format binaire entre version majeur n'est pas compatible. Les outils pg_cluster sont des outils spécifiques au packaging debian qui permettent de faire tourner facilement un ou plusieurs server pg sur le même hôte, en s'occupant notemment de leur initialization (et accessoirement de gèrer des upgrades donc). Normalement tu as du voir un message explicatif durant l'upgrade…
man pg_dropcluster
la version 13 tourne sur un autre port, 5433 en toute vraissemblance (pg_lsclusters)
Si l'application n'a pas été modifiée pour communiqué avec la version 13 (changer de port, donc) au moment de la mise à jour, il est fort probable que les données de la version 13 sont déjà obsolètes…