[FRsAG] Re: RAID et SSD : hardware ou software ?

[Olivier Cochard-Labbé]

On Tue, Jul 12, 2022 at 2:18 PM Matic Vari  wrote:

>
>
> Aujourd'hui : Raid Logiciel ou Matériel ?
>

Alors ici:
- Use case: Un certain nombre de serveurs CDN;
- Raid soft (100% FreeBSD: gmirror pour les anciennes machines, raidz pour
les nouvelles) pour les disques supportant l'OS uniquement;
- Pas de réplication pour les disques dédiés au contenu (car répliqué sur
les autres serveurs).

Pourquoi:
- Simplification de la supervision: Pas d'outil spécifique pour remonter
l'état du raid matériel;
- Simplification de la maintenance: On maîtrise l'ensemble du code.

Cdlt,

Olivier
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: RAID et SSD : hardware ou software ?

[David Ponzone]

Faut mettre des cartes très courantes, très dispos en broke et avoir un bon 
broker.
Une carte RAID qui part en vrille, ça doit arriver je dis pas le contraire. 
Mais ça m’est jamais arrivé.
Mais je suis d’accord avec vous sur le fond, je préfèrerais être très à l’aise 
avec le soft pour faire que de l’install soft.
Hélas, y a encore pas si longtemps, installer une Debian avec / sur un RaidZ1, 
c’était pas vraiment trivial.

> Le 12 juil. 2022 à 16:54, Matic Vari  a écrit :
> 
> => "Les cartes RAID hardware, déjà quand elles claquent, faut avoir du
> spare" et la bonne version du firmware, voire la bonne révision de la
> carte...
> 
> Le 12/07/2022, Stéphane Rivière a écrit :
>> 
>>> Je suis personnellement plus serein (peut-être à tort) avec mon / sur
>>> un Raid 1 HW, pour le moment en tout cas.
>> 
>> Mon expérience est strictement inverse. Les cartes RAID hardware, déjà
>> quand elles claquent, faut avoir du spare, ensuite quand le RAID claque,
>> ça peut aller jusqu'à la perte totale (sans rien comprendre, même avec
>> de la carte RAID haut de gamme). Avec du RAID soft, au pire, sur une
>> reconstruction "difficile" en RAID1 on prend un disque pas mort et... on
>> "juste le lit" (puisque on est dans du standard).
>> 
>> Une remarque, toujours par expérience, quand c'est du lourd (médical par
>> exemple), RAID1 3 disques (et pas 2 disques).
>> 
>> --
>> Stéphane Rivière
>> Ile d'Oléron - France
>> 
>> 

___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: RAID et SSD : hardware ou software ?

[Matic Vari]

=> "Les cartes RAID hardware, déjà quand elles claquent, faut avoir du
spare" et la bonne version du firmware, voire la bonne révision de la
carte...

Le 12/07/2022, Stéphane Rivière a écrit :
>
>> Je suis personnellement plus serein (peut-être à tort) avec mon / sur
>> un Raid 1 HW, pour le moment en tout cas.
>
> Mon expérience est strictement inverse. Les cartes RAID hardware, déjà
> quand elles claquent, faut avoir du spare, ensuite quand le RAID claque,
> ça peut aller jusqu'à la perte totale (sans rien comprendre, même avec
> de la carte RAID haut de gamme). Avec du RAID soft, au pire, sur une
> reconstruction "difficile" en RAID1 on prend un disque pas mort et... on
> "juste le lit" (puisque on est dans du standard).
>
> Une remarque, toujours par expérience, quand c'est du lourd (médical par
> exemple), RAID1 3 disques (et pas 2 disques).
>
> --
> Stéphane Rivière
> Ile d'Oléron - France
>
>
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: RAID et SSD : hardware ou software ?

[Stéphane Rivière]

Si NVMe, logiciel
Si HDD, Hard


Pourquoi ?


Ayant du raid soft depuis plus de 15 ans.
Avec du HDD scsi 15K de récup (sur des servs de récup), en RAID10 (bien 
tuné), des perfs limite pas loin des premiers SSD ;)

Avec du HDD sata 7,2K, ça marchait aussi très bien.

Un cas où je verrais l'utilisation du RAID matériel est l'OS qui exige 
de ne voir qu'un disque au boot.


Pour le reste, le KISS est le mieux.

--
Stéphane Rivière
Ile d'Oléron - France



OpenPGP_0x68A4C5C1D498F92F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: RAID et SSD : hardware ou software ?

[Matic Vari]

Ca marche pas avec des SSD NVMe, si j'ai bien compris.

Le 12/07/2022, David Ponzone a écrit :
> Je mets un bémol purement perso, mais je suis peut-être pas le seul:
>
> Les procédures de recovery quand on a une situation anormale, avec / sur un
> raid soft, que ça soit MDADM ou ZFS, c’est pas forcément trivial quand on le
> fait pas tous les jours.
> Je suis personnellement plus serein (peut-être à tort) avec mon / sur un
> Raid 1 HW, pour le moment en tout cas.
>
>> Le 12 juil. 2022 à 15:56, Stéphane Rivière  a écrit :
>>
>>
>>> Aujourd'hui : Raid Logiciel ou Matériel ?
>> Logiciel
>>
>> Observé depuis longtemps que le raid soft est généralement beaucoup rapide
>> qu'une carte raid dédiée
>>
>> Aujourd'hui, le fonctionnement même d'un NVMe me semble rendre (imho) les
>> cartes dédiées obsolètes.
>>
>> Sur des CM Asrock de serveur + NVMe en raid1 soft (infra ou advance OVH),
>> on a juste des perfs de oufs.
>>
>> --
>> Stéphane Rivière
>> Ile d'Oléron - France
>> ___
>> Liste de diffusion du %(real_name)s
>> http://www.frsag.org/
>
>
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: RAID et SSD : hardware ou software ?

[Stéphane Rivière]

Je suis personnellement plus serein (peut-être à tort) avec mon / sur 
un Raid 1 HW, pour le moment en tout cas.


Mon expérience est strictement inverse. Les cartes RAID hardware, déjà 
quand elles claquent, faut avoir du spare, ensuite quand le RAID claque, 
ça peut aller jusqu'à la perte totale (sans rien comprendre, même avec 
de la carte RAID haut de gamme). Avec du RAID soft, au pire, sur une 
reconstruction "difficile" en RAID1 on prend un disque pas mort et... on 
"juste le lit" (puisque on est dans du standard).


Une remarque, toujours par expérience, quand c'est du lourd (médical par 
exemple), RAID1 3 disques (et pas 2 disques).


--
Stéphane Rivière
Ile d'Oléron - France



OpenPGP_0x68A4C5C1D498F92F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: Mails bloqués par orange

[open doc]

Bonjour,

on est alerté en cas de problème, on un plugin qui supervise via
https://www.dnsbl.info/dnsbl-database-check.php si nous sommes backlist, et
nos ip n'y sont pas mais elles sont peut être ailleurs, sur une autre
liste.

Effectivement, entre le ressenti utilisateur du "j'ai pas mon mail" et le
traitement réelle, c'est que très souvent cela arrive en spam.

Le mar. 12 juil. 2022 à 10:01, Pierre-Philipp Braun  a
écrit :

> Cela sonne comme un problème de réputation IP et que les messages venant
> de chez vous arrivent systématiquement dans la boîte spam des
> utilisateurs.  Est-ce que Orange a renforcé son système de RBL ?  J'ai
> vu cela chez GMX en tous cas.  Cela devient de plus en plus dure d'avoir
> son propre MTA sortant.
>
> « Si t'es pas un GAFAM, tu finis dans les SPAM... »
>
> Il est peu probable que les mails disparaissent vraiment, simplement les
> utilisateurs oublient toujours de regarder dans la boîte spam, que
> parfois ils ne voient même pas (thunderbird > server settings advanced >
> UNCHECK show only subscribed folders).
>
> Bon conrage.
> --
> Pierre-Philipp Braun
> SMTP Health Campaign: enforce STARTTLS and verify MX certificates
> 
>
> On 11/07/2022 18:31, open doc wrote:
> > Bonjour à tous,
> >
> > désolé de ce thème évoqué très fréquemment, mais nous avons un vrai
> > problème de traitement de mail par orange. Nous envoyons environs 110
> > 000 mails par jour, on a fait attention au SFP, DKIM ... Je me suis basé
> > aussi sur www.mail-tester.com  pour valider
> > le contenu du mail, et le score est pas mal, 9,1/10, ca donne une
> tendance.
> >
> > On a eu plusieurs problèmes (sendertool.vadesecure.com
> > ), mais au final, on fini par trouver
> > des solutions. (inscription, déclaration des ip ...)
> >
> > Sauf que depuis 2 semaine avec orange, c'est un peu n'importe quoi. Les
> > mails sont bien acceptés (code 250) et hop disparition !
> >
> > ---
> > 2022-07-11 07:16:39 1oAlXi-0002uo-34 => xx...@orange.fr
> >  R=dnslookup T=remote_smtp
> > H=smtp-in.orange.fr  [80.12.26.32]
> > X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128
> > DN="C=FR,L=Paris,O=Orange,CN=smtp-in.orange.fr
> > " C="250 2.0.0 AlmgoeTIHnwFpAlmgoELJo mail
> > accepted for delivery"
> > 2022-07-11 07:16:39 1oAlXi-0002uo-34 Completed
> > ---
> >
> > Le retour de nos utilisateurs est que les mails arrivent en spam ou
> > n'arrive pas du tout, et j'ai pas de résumé "dmarc" via orange. Bref je
> > ne sais pas trop quoi faire, on fait sûrement des erreurs dans nos
> > envoies, mais j'aimerai échanger avec une personne qui pourrait nous
> > aider à comprendre ce phénomène sachant, que le contenu envoyé, est du
> > contenu payant et ca énerve très fortement nos clients.
> >
> > Si vous avez une idée, je suis preneur.
> >
> > Par avance merci pour vos réponses.
> >
> > Alex
> >
> > ___
> > Liste de diffusion du %(real_name)s
> > http://www.frsag.org/
>
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: RAID et SSD : hardware ou software ?

[David Ponzone]

Je mets un bémol purement perso, mais je suis peut-être pas le seul:

Les procédures de recovery quand on a une situation anormale, avec / sur un 
raid soft, que ça soit MDADM ou ZFS, c’est pas forcément trivial quand on le 
fait pas tous les jours.
Je suis personnellement plus serein (peut-être à tort) avec mon / sur un Raid 1 
HW, pour le moment en tout cas.

> Le 12 juil. 2022 à 15:56, Stéphane Rivière  a écrit :
> 
> 
>> Aujourd'hui : Raid Logiciel ou Matériel ?
> Logiciel
> 
> Observé depuis longtemps que le raid soft est généralement beaucoup rapide 
> qu'une carte raid dédiée
> 
> Aujourd'hui, le fonctionnement même d'un NVMe me semble rendre (imho) les 
> cartes dédiées obsolètes.
> 
> Sur des CM Asrock de serveur + NVMe en raid1 soft (infra ou advance OVH), on 
> a juste des perfs de oufs.
> 
> -- 
> Stéphane Rivière
> Ile d'Oléron - France
> ___
> Liste de diffusion du %(real_name)s
> http://www.frsag.org/

___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: RAID et SSD : hardware ou software ?

[Guillaume PUTIER via FRsAG]

Hello,

Si NVMe, logiciel
Si HDD, Hard

Cdt


———

Guillaume PUTIER

guilla...@putier.fr



Ce courriel et toutes ses pièces jointes peuvent contenir de l'information de 
nature confidentielle ou privilégiée. Si vous avez reçu ce courriel par erreur, 
merci de ne pas le transférer, le copier ou l'utiliser. Veuillez communiquer 
immédiatement avec l'expéditeur et supprimer le message dans son intégralité. 
Le fait de vous avoir envoyé ce courriel par erreur ne signifie pas que 
l'expéditeur renonce à ses droits. Je ne peut être tenue responsable de toute 
perte ou dommages liés au présent courriel et peut effectuer un suivi de ce 
courriel, le conserver et l'examiner.

> Le 12 juil. 2022 à 15:56, Stéphane Rivière  a écrit :
> 
> 
>> Aujourd'hui : Raid Logiciel ou Matériel ?
> Logiciel
> 
> Observé depuis longtemps que le raid soft est généralement beaucoup rapide 
> qu'une carte raid dédiée
> 
> Aujourd'hui, le fonctionnement même d'un NVMe me semble rendre (imho) les 
> cartes dédiées obsolètes.
> 
> Sur des CM Asrock de serveur + NVMe en raid1 soft (infra ou advance OVH), on 
> a juste des perfs de oufs.
> 
> -- 
> Stéphane Rivière
> Ile d'Oléron - France
> ___
> Liste de diffusion du %(real_name)s
> http://www.frsag.org/

___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: RAID et SSD : hardware ou software ?

[Stéphane Rivière]

Aujourd'hui : Raid Logiciel ou Matériel ?


Logiciel

Observé depuis longtemps que le raid soft est généralement beaucoup 
rapide qu'une carte raid dédiée


Aujourd'hui, le fonctionnement même d'un NVMe me semble rendre (imho) 
les cartes dédiées obsolètes.


Sur des CM Asrock de serveur + NVMe en raid1 soft (infra ou advance 
OVH), on a juste des perfs de oufs.


--
Stéphane Rivière
Ile d'Oléron - France



OpenPGP_0x68A4C5C1D498F92F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: PHP Sury Debian9

[Wallace]

Bonjour,

Il y a beaucoup de cas où ce sont les clients qui bloquent pour des 
raisons obscures les mises à jour ou les remplacements en reportant 
indéfiniment.


On a beau mettre les recommandations en avant, insister ça ne passe pas, 
par contre quand c'est franchement abusé et que l'on arrive plus à 
intervenir dessus (version openssl qui empêche de se connecter à la 
moitié des sites de la planète avec LE, ssh trop obsolète qui oblige de 
réduire la sécurité des algos pour se connecter dessus, ...) là on 
impose la migration et s'ils ne veulent toujours pas on arrête ces 
dossiers et là ils acceptent ou partent.


Le 12/07/2022 à 07:36, Maxime DERCHE a écrit :

Bonjour Jérôme,

J'espère que tu vas bien. :)

Ma question ne porte pas sur l'existence de logiciels obsolètes donc 
sur la gestion du risque qu'ils induisent, mais sur le risque induit 
par la publicité qui en est faite, à plus ou moins bon escient.


Des vieuseries plus ou moins cachées dans les coins, il y en a 
partout, et des ingénieur-es de qualité qui font du mieux possible 
pour concilier des objectifs antagonistes de gestion de production et 
de gestion du risque il y en a aussi (mais pas partout..). Tu en 
donnes la preuve en annonçant à la fois une réponse opérationnelle 
(protection périmétrique) et une réponse de gestion de la sécurité 
(feuille de route), ce qui est considéré comme une bonne réponse dans 
le cadre d'un cycle d'amélioration continue (Plan-Do-Control-Act dans 
ISO27001 par exemple).


Là où je m'interroge, c'est sur la pratique du partage d'information 
communautaire, sans laquelle Internet n'aurait jamais existé, dans un 
monde où les professions du numérique sont devenues des professions 
encadrées juridiquement (il y a même aujourd'hui un Code de la 
Cybersécurité publié aux éditions Dialloz [1]). Comment demander de 
l'aide, rapporter un bug ou annoncer l'ouverture d'un poste sans se 
mettre hors-la-loi (et accessoirement risquer de violer l'intimité de 
personnes concernées innocentes qui nous font toute confiance à nous, 
numéristes combattant-es) ?



[1] : 
, 
publié le mois dernier, cf 




Bien cordialement,

-- Maxime

Le 11/07/2022 à 19:56, Jérôme Nicolle a écrit :

Maxime,

Sur un de mes projets en cours, je dois gérer des machines qui ont 
entre 12 et 19 ans d'uptime.


Globalement, elles ont toutes l'âge de boire.

J'assure la fonction de RSSI néanmoins, pour deux raisons :

- Elles sont correctement firewallées et avec du SNORT bien vener en 
frontal


- On a une roadmap pour toutes les reconstruire d'ici un an (170 
machines…)


Le 11/07/2022 à 18:49, Maxime DERCHE a écrit :

Bonjour,

Le 04/07/2022 à 17:54, Pierre DOLIDON a écrit :

Bonjour a tous

a tout hasard, quelqu'un aurait cloné le repo Sury pour les 
versions PHP de Debian 9 ? Comme elle est passée EOL, les dépots de 
sury semblent avoir été purgés également.

Par avance, merci !


Question un peu bête mais je termine à peine mon vendredi :

Vos RSSI vous autorisent encore à avouer publiquement que vous 
faites tourner des OS obsolètes ?


(Je précise que j'adresse la question à l'assemblée non seulement à 
la personne ayant ouvert le sujet, je ne cherche pas à pointer des 
coupables mais juste à sonder l'opinion.)


frsag est une liste publique, archivée par des moteurs de recherche 
web, n'importe quel agent de la CNIL pourrait tomber dessus soit 
fortuitement (et ajouter le nom de la boîte à sa liste) soit lors 
d'un audit, par exemple suite à déclaration d'une fuite de données 
personnelles. Le ou la DPO aurait alors du mal à démentir ou à 
justifier. :)


Notez que j'ai la même question pour les offres d'emploi où le 
référentiel technique est décrit avec les noms voire les versions 
des logiciels utilisés, cela fait une excellente source ouverte de 
renseignement (OSINT blah blah blah).


Z'en pensez quoi ?


Bien cordialement,
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] RAID et SSD : hardware ou software ?

[Matic Vari]

Bonjour,

Nous sommes en train de voir à faire évoluer notre serveur d'entreprise.

Je me posais quelques questions au niveau stockage:

Le raid matériel peut-il encore encaisser les débits d'une grappe SSD ?

Est-ce toujours possible avec des SSD NVMe d'avoir une carte RAID  ?

En Raid Logiciel (ZFS par exemple) : peut-on espérer des gains en
vitesse d'écriture ?

Aujourd'hui : Raid Logiciel ou Matériel ?

Cdlt,

VM
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: PHP Sury Debian9

[Rémy Dernat]

Bonjour,

Si je peux me permettre, je pense que la remarque de Maxime valait autant pour 
l'utilisation de logiciels obsolètes que pour le dévoilement d'informations 
jugées sensibles sur une liste de diffusion. Une des 1ères étapes de hacking 
consiste en prise d'informations, d'empreintes... Travail prémaché ici.

Et pour le risque lui-même, je pense qu'une vieille version de PHP, ça craint 
plus que du debian 9 maintenue, dans l'absolu. Mais, oui, le risque se gère 
aussi.

Cordialement,

Le 12 juillet 2022 11:39:41 GMT+02:00, Christophe Casalegno via FRsAG 
 a écrit :
>Le mardi 12 juillet 2022, 10:11:37 IST Maxime DERCHE a écrit :
>
>> Là encore, cela relève de l'analyse au doigt mouillé, pas de la gestion de
>> risque. :)
> 
>Pas vraiment, ce genre de sujet est parfaitement documenté et traité dans de 
>nombreuses analyses de risques de nombreuses entreprises. Les mêmes qui sont 
>effectuées correctement et ne se contentent pas de reporter l'indice de 
>gravité 
>d'un CVE publié sur internet, mais qui l'appliquent au contexte de 
>l'entreprise (exemple : un remote exploit flagué au max sur un équipement 
>déconnecté de tout réseau, n'a aucun sens). Même si chez 90% des acteurs c'est 
>le bordel : certains font le boulot, proprement et en détail pour chaque 
>composant.
> 
>> (L'équipe d'OpenBSD a maintenu Apache HTTPd 1.3 pendant des années sans
>> problème. C'est par contre inimaginable dans le monde
>> propriétaire/commercial.) 
>
>Il s'agit juste d'une question de volonté et de capacité de l'éditeur. Il est 
>parfaitement possible de maintenir une vieille version d'un logiciel pour une 
>ancienne version ad vitam.  Contrairement aux idées reçues cela ne signifie 
>pas 
>toujours une quantité de travail astronomique. 
>
>> prestataire qui maintient un service obsolète depuis longtemps d'avoir
>> cassé quelque chose avec un patch artisanal introduisant un bug quelconque
>> (par exemple) ?
>
>ça veut dire quoi "artisanal" ici ?  Les responsabilités des prestataires et 
>des éditeurs sont généralement dans tous les cas déterminées par le contexte 
>juridique (et dans la plupart des licenses, qu'elles soient libres ou 
>propriétaires, il y a peu de garanties coté éditeur en dehors du fait de 
>corriger après coup certains bugs)
>
>> Au passage l'argument des trucs tellement anciens qu'ils sont devenus sûrs
>> ne tient 
> ni techniquement (Internet n'oublie jamais rien, l'exploit
>> publié en 19xy est toujours disponible et fonctionnel) ni juridiquement
>> ("security by design"), et encore moins moralement face aux personnes
>> concernées qui nous font confiance pour protéger leurs données...
>
>Ce n'est pas du tout ce que j'ai écrit : je dis qu'une fois qu'on a patché 
>tout ce qui a été publié, le % de risque de voir sortir une *nouvelle* 
>vulnérabilité sur un système vieux de 15 ans et peu utilisé est quasiment nul. 
>Ce n'est pas un argument d'autorité : c'est un argument statistique.  Cela ne 
>signifie pas que le produit est plus ou moins sur : seulement qu'on ne publie 
>plus de vulnérabilités à son sujet car tout le monde s'en fou. 
>
>Peut être que quelqu'un qui n'a que ça à faire va publier un jour une nouvelle 
>vulnérabilité sur apache 1.3 ou php4, mais ça n'intéresse personne. Si 
>quelqu'un fait ça, c'est qu'il sera probablement le plus concerné lui même par 
>la faille et son correctif.. Là encore c'est statistique. 
>
>> marché pour héberger des applications PHP 4 non-maintenues (ou maintenues
>> mais faibles voire indéfendables) au risque que les données fuitent, et
>> tant pis pour les victimes, même si l'hébergeur a bien fait son travail.
>
>Bon courage pour démontrer qu'une application développée en php4 et qui a été 
>capable de résister à 15 ans d'attaques quotidiennes avec une exposition 
>maximale est de facto moins sécure qu'une application développée en php 8.1 il 
>y a 2 mois... 
>
>Attention, je ne dis pas que c'est *ce qu'il faut faire*, je dis juste que 
>l'aspect sécurité est beaucoup plus complexe qu'en première apparence et 
>dépend à chaque fois du contexte. 
>
>Aujourd'hui un serveur en apache 1.3 et php4 a moins de change de pouvoir se 
>faire défoncer qu'un serveur en apache 2.4 avec php 8.1 : les logiciels sont 
>de plus en plus gros, de plus en plus lourd, et tout programme de plus de 
>100kb est *toujours* bugué. L'épreuve du temps reste sécuritairement parlant 
>une valeur sure, surtout en environnement libre / opensource sur un logiciel 
>qui a été très utilisé (et ou donc beaucoup de personnes y ont cherché, moi le 
>premier des vulnérabilités). 
>
>
>amicalement,
>
>-- 
>Christophe Casalegno
>https://www.christophe-casalegno.com
>
>
>___
>Liste de diffusion du %(real_name)s
>http://www.frsag.org/___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: PHP Sury Debian9

[Christophe Casalegno via FRsAG]

Le mardi 12 juillet 2022, 10:11:37 IST Maxime DERCHE a écrit :

> Là encore, cela relève de l'analyse au doigt mouillé, pas de la gestion de
> risque. :)
 
Pas vraiment, ce genre de sujet est parfaitement documenté et traité dans de 
nombreuses analyses de risques de nombreuses entreprises. Les mêmes qui sont 
effectuées correctement et ne se contentent pas de reporter l'indice de gravité 
d'un CVE publié sur internet, mais qui l'appliquent au contexte de 
l'entreprise (exemple : un remote exploit flagué au max sur un équipement 
déconnecté de tout réseau, n'a aucun sens). Même si chez 90% des acteurs c'est 
le bordel : certains font le boulot, proprement et en détail pour chaque 
composant.
 
> (L'équipe d'OpenBSD a maintenu Apache HTTPd 1.3 pendant des années sans
> problème. C'est par contre inimaginable dans le monde
> propriétaire/commercial.) 

Il s'agit juste d'une question de volonté et de capacité de l'éditeur. Il est 
parfaitement possible de maintenir une vieille version d'un logiciel pour une 
ancienne version ad vitam.  Contrairement aux idées reçues cela ne signifie pas 
toujours une quantité de travail astronomique. 

> prestataire qui maintient un service obsolète depuis longtemps d'avoir
> cassé quelque chose avec un patch artisanal introduisant un bug quelconque
> (par exemple) ?

ça veut dire quoi "artisanal" ici ?  Les responsabilités des prestataires et 
des éditeurs sont généralement dans tous les cas déterminées par le contexte 
juridique (et dans la plupart des licenses, qu'elles soient libres ou 
propriétaires, il y a peu de garanties coté éditeur en dehors du fait de 
corriger après coup certains bugs)

> Au passage l'argument des trucs tellement anciens qu'ils sont devenus sûrs
> ne tient 
 ni techniquement (Internet n'oublie jamais rien, l'exploit
> publié en 19xy est toujours disponible et fonctionnel) ni juridiquement
> ("security by design"), et encore moins moralement face aux personnes
> concernées qui nous font confiance pour protéger leurs données...

Ce n'est pas du tout ce que j'ai écrit : je dis qu'une fois qu'on a patché 
tout ce qui a été publié, le % de risque de voir sortir une *nouvelle* 
vulnérabilité sur un système vieux de 15 ans et peu utilisé est quasiment nul. 
Ce n'est pas un argument d'autorité : c'est un argument statistique.  Cela ne 
signifie pas que le produit est plus ou moins sur : seulement qu'on ne publie 
plus de vulnérabilités à son sujet car tout le monde s'en fou. 

Peut être que quelqu'un qui n'a que ça à faire va publier un jour une nouvelle 
vulnérabilité sur apache 1.3 ou php4, mais ça n'intéresse personne. Si 
quelqu'un fait ça, c'est qu'il sera probablement le plus concerné lui même par 
la faille et son correctif.. Là encore c'est statistique. 

> marché pour héberger des applications PHP 4 non-maintenues (ou maintenues
> mais faibles voire indéfendables) au risque que les données fuitent, et
> tant pis pour les victimes, même si l'hébergeur a bien fait son travail.

Bon courage pour démontrer qu'une application développée en php4 et qui a été 
capable de résister à 15 ans d'attaques quotidiennes avec une exposition 
maximale est de facto moins sécure qu'une application développée en php 8.1 il 
y a 2 mois... 

Attention, je ne dis pas que c'est *ce qu'il faut faire*, je dis juste que 
l'aspect sécurité est beaucoup plus complexe qu'en première apparence et 
dépend à chaque fois du contexte. 

Aujourd'hui un serveur en apache 1.3 et php4 a moins de change de pouvoir se 
faire défoncer qu'un serveur en apache 2.4 avec php 8.1 : les logiciels sont 
de plus en plus gros, de plus en plus lourd, et tout programme de plus de 
100kb est *toujours* bugué. L'épreuve du temps reste sécuritairement parlant 
une valeur sure, surtout en environnement libre / opensource sur un logiciel 
qui a été très utilisé (et ou donc beaucoup de personnes y ont cherché, moi le 
premier des vulnérabilités). 


amicalement,

-- 
Christophe Casalegno
https://www.christophe-casalegno.com


___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: PHP Sury Debian9

[Maxime DERCHE]

Bonjour,

Le 12/07/2022 à 10:19, Christophe Casalegno via FRsAG a écrit :

Le lundi 11 juillet 2022, 17:49:49 IST Maxime DERCHE a écrit :


Question un peu bête mais je termine à peine mon vendredi :

Vos RSSI vous autorisent encore à avouer publiquement que vous faites
tourner des OS obsolètes ?


Hello

Je dirais que le fait qu'une distribution GNU / Linux (ou qu'un autre
logiciel), soit déclaré "end of life" ne signifie (surtout dans le domaine du
logiciel libre), ni qu'il n'est plus maintenu, ni qu'il est "obsolète" (à
définir précisément).

J'ai maintenu des machines avec des OS (notamment Mandriva) qui étaient
obsolètes depuis bien longtemps, et faisant tourner des applications en php4
tournant sur apache 1.3. Et je suis sur de ne pas être la seule personne au
monde dans ce cas là.

Pour autant, elles ont continué d'être patchées régulièrement lorsque c'était
nécessaire en terme de sécurité (kernel, ghost, shellshock, ssl, etc.) ou de
correction de bugs fonctionnels (MySQL) et n'ont jamais posé le moindre
problème.

Ceci étant, tant qu'il y aura des clients pour avoir ce besoin, il existera
des prestataires pour y répondre : la situation crée le marché.  De plus au
bout d'un temps : plus personne ne recherche de vulnérabilités sur ces
versions trop anciennes et trop peu utilisées.. et le risque de 0day est bien
plus important sur un logiciel récent qu'un logiciel obsolète.

Et je ne parle même pas des clients "industriels" on trouve des choses bien
plus anciennes... parfois à des fonctions critiques.

Cela n'engendre pas de problèmes de sécurité particuliers : ces machines
fonctionnent généralement en circuit fermé et la surface d'exposition est
quasi nulle.

Par contre cela peut engendrer de gros problèmes de SAV si les pièces de
rechanges ne sont pas dispo. Le pire que j'ai vu jusqu'à présent, il n'y a pas
si longtemps, c'est un 286 sous MS-DOS enfermé dans une pièce en verre et dont
dépend beaucoup d'activités non seulement de l'organisme mais de tiers.

Bonne semaine à tous,


Là encore, cela relève de l'analyse au doigt mouillé, pas de la gestion de 
risque. :)

(Et il faut avouer que même en gestion de risque, la notation du risque se fait sur 
une échelle de valeur souvent subjective car il est difficile de construire un barème 
raisonné... Donc la gestion de risque au doigt mouillé ne vaut pas mieux.)


Maintenir un service reposant sur des logiciels libres "obsolètes" (obsolètes au 
moins sur le papier), c'est effectivement faisable même sur un temps très long 
puisqu'il est toujours techniquement et légalement faisable de rétroporter les 
corrections. Et le travail peut être réalisé de manière qualitative par des personnes 
qualifiées, donc la gouvernance sécurité peut s'organiser et fonctionner correctement 
sur cette base, avec une gestion de risque clairement posée.


(L'équipe d'OpenBSD a maintenu Apache HTTPd 1.3 pendant des années sans problème. 
C'est par contre inimaginable dans le monde propriétaire/commercial.)


Mais le coût économique devient lourd, et la responsabilité en cas d'erreur devient 
de plus en plus floue au fil du temps, car comment reprocher au prestataire qui 
maintient un service obsolète depuis longtemps d'avoir cassé quelque chose avec un 
patch artisanal introduisant un bug quelconque (par exemple) ?


Je comprend bien qu'il y a des antiquités parfaitement fonctionnelles qui font très 
bien leur travail et qu'on a su et pu maintenir en condition de sécurité raisonnable 
en durcissant l'environnement puisqu'on ne peut plus durcir le service. Mais 
gouverner la sécurité au cas par cas individuel chaque antiquité coûte très cher et 
le risque d'erreur est croissant avec le temps.


Au passage l'argument des trucs tellement anciens qu'ils sont devenus sûrs ne tient 
ni techniquement (Internet n'oublie jamais rien, l'exploit publié en 19xy est 
toujours disponible et fonctionnel) ni juridiquement ("security by design"), et 
encore moins moralement face aux personnes concernées qui nous font confiance pour 
protéger leurs données...



Réfléchir en terme de marché avantage l'attaquant, pas le défenseur, et cela se fait 
au détriment des personnes humaines : il y aura toujours un marché pour héberger des 
applications PHP 4 non-maintenues (ou maintenues mais faibles voire indéfendables) au 
risque que les données fuitent, et tant pis pour les victimes, même si l'hébergeur a 
bien fait son travail.



Il est beaucoup plus simple et sain de se donner une règle claire à partir de 
laquelle on gère l'obsolescence comme étant un risque que l'on va traiter de manière 
prévisible en fonction du niveau de criticité et des possibilités financières, non ?



Bien cordialement,
--
Maxime DERCHE
OpenPGP public key ID : 0xAE5264B5
OpenPGP public key fingerprint : 7221 4C4F D57C 456F 8E40 3257 47F7 29A6 AE52 
64B5

___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: Mails bloqués par orange

[open doc]

Mea culpa, ne pas tenir compte de ce doublon.

Alexandre

Le mar. 12 juil. 2022 à 10:28, open doc  a écrit :

> Bonjour à tous,
>
> désolé de ce thème évoqué très fréquemment, mais nous avons un vrai
> problème de traitement de mail par orange. Nous envoyons environs 110 000
> mails par jour, on a fait attention au SFP, DKIM ... Je me suis basé aussi
> sur www.mail-tester.com pour valider le contenu du mail, et le score est
> pas mal, 9,1/10, ca donne une tendance.
>
> On a eu plusieurs problèmes (sendertool.vadesecure.com), mais au final,
> on fini par trouver des solutions. (inscription, déclaration des ip ...)
>
> Sauf que depuis 2 semaine avec orange, c'est un peu n'importe quoi. Les
> mails sont bien acceptés (code 250) et hop disparition !
>
> ---
> 2022-07-11 07:16:39 1oAlXi-0002uo-34 => xx...@orange.fr R=dnslookup
> T=remote_smtp H=smtp-in.orange.fr [80.12.26.32]
> X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 DN="C=FR,L=Paris,O=Orange,CN=
> smtp-in.orange.fr" C="250 2.0.0 AlmgoeTIHnwFpAlmgoELJo mail accepted for
> delivery"
> 2022-07-11 07:16:39 1oAlXi-0002uo-34 Completed
> ---
>
> Le retour de nos utilisateurs est que les mails arrivent en spam ou
> n'arrive pas du tout, et j'ai pas de résumé "dmarc" via orange. Bref je ne
> sais pas trop quoi faire, on fait sûrement des erreurs dans nos envoies,
> mais j'aimerai échanger avec une personne qui pourrait nous aider à
> comprendre ce phénomène sachant, que le contenu envoyé, est du contenu
> payant et ca énerve très fortement nos clients.
>
> Si vous avez une idée, je suis preneur.
>
> Par avance merci pour vos réponses.
>
> Alex
>
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Mails bloqués par orange

[open doc]

Bonjour à tous,

désolé de ce thème évoqué très fréquemment, mais nous avons un vrai
problème de traitement de mail par orange. Nous envoyons environs 110 000
mails par jour, on a fait attention au SFP, DKIM ... Je me suis basé aussi
sur www.mail-tester.com pour valider le contenu du mail, et le score est
pas mal, 9,1/10, ca donne une tendance.

On a eu plusieurs problèmes (sendertool.vadesecure.com), mais au final, on
fini par trouver des solutions. (inscription, déclaration des ip ...)

Sauf que depuis 2 semaine avec orange, c'est un peu n'importe quoi. Les
mails sont bien acceptés (code 250) et hop disparition !

---
2022-07-11 07:16:39 1oAlXi-0002uo-34 => xx...@orange.fr R=dnslookup
T=remote_smtp H=smtp-in.orange.fr [80.12.26.32]
X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 DN="C=FR,L=Paris,O=Orange,CN=
smtp-in.orange.fr" C="250 2.0.0 AlmgoeTIHnwFpAlmgoELJo mail accepted for
delivery"
2022-07-11 07:16:39 1oAlXi-0002uo-34 Completed
---

Le retour de nos utilisateurs est que les mails arrivent en spam ou
n'arrive pas du tout, et j'ai pas de résumé "dmarc" via orange. Bref je ne
sais pas trop quoi faire, on fait sûrement des erreurs dans nos envoies,
mais j'aimerai échanger avec une personne qui pourrait nous aider à
comprendre ce phénomène sachant, que le contenu envoyé, est du contenu
payant et ca énerve très fortement nos clients.

Si vous avez une idée, je suis preneur.

Par avance merci pour vos réponses.

Alex
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: PHP Sury Debian9

[Christophe Casalegno via FRsAG]

Le lundi 11 juillet 2022, 17:49:49 IST Maxime DERCHE a écrit :

> Question un peu bête mais je termine à peine mon vendredi :
> 
> Vos RSSI vous autorisent encore à avouer publiquement que vous faites
> tourner des OS obsolètes ?

Hello

Je dirais que le fait qu'une distribution GNU / Linux (ou qu'un autre 
logiciel), soit déclaré "end of life" ne signifie (surtout dans le domaine du 
logiciel libre), ni qu'il n'est plus maintenu, ni qu'il est "obsolète" (à 
définir précisément). 

J'ai maintenu des machines avec des OS (notamment Mandriva) qui étaient 
obsolètes depuis bien longtemps, et faisant tourner des applications en php4 
tournant sur apache 1.3. Et je suis sur de ne pas être la seule personne au 
monde dans ce cas là. 

Pour autant, elles ont continué d'être patchées régulièrement lorsque c'était 
nécessaire en terme de sécurité (kernel, ghost, shellshock, ssl, etc.) ou de 
correction de bugs fonctionnels (MySQL) et n'ont jamais posé le moindre 
problème. 

Ceci étant, tant qu'il y aura des clients pour avoir ce besoin, il existera 
des prestataires pour y répondre : la situation crée le marché.  De plus au 
bout d'un temps : plus personne ne recherche de vulnérabilités sur ces 
versions trop anciennes et trop peu utilisées.. et le risque de 0day est bien 
plus important sur un logiciel récent qu'un logiciel obsolète.

Et je ne parle même pas des clients "industriels" on trouve des choses bien 
plus anciennes... parfois à des fonctions critiques.

Cela n'engendre pas de problèmes de sécurité particuliers : ces machines 
fonctionnent généralement en circuit fermé et la surface d'exposition est 
quasi nulle. 

Par contre cela peut engendrer de gros problèmes de SAV si les pièces de 
rechanges ne sont pas dispo. Le pire que j'ai vu jusqu'à présent, il n'y a pas 
si longtemps, c'est un 286 sous MS-DOS enfermé dans une pièce en verre et dont 
dépend beaucoup d'activités non seulement de l'organisme mais de tiers. 

Bonne semaine à tous,

-- 
Christophe Casalegno
https://www.christophe-casalegno.com


___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: Mails bloqués par orange

[Pierre-Philipp Braun]

Cela sonne comme un problème de réputation IP et que les messages venant 
de chez vous arrivent systématiquement dans la boîte spam des 
utilisateurs.  Est-ce que Orange a renforcé son système de RBL ?  J'ai 
vu cela chez GMX en tous cas.  Cela devient de plus en plus dure d'avoir 
son propre MTA sortant.


« Si t'es pas un GAFAM, tu finis dans les SPAM... »

Il est peu probable que les mails disparaissent vraiment, simplement les 
utilisateurs oublient toujours de regarder dans la boîte spam, que 
parfois ils ne voient même pas (thunderbird > server settings advanced > 
UNCHECK show only subscribed folders).


Bon conrage.
--
Pierre-Philipp Braun
SMTP Health Campaign: enforce STARTTLS and verify MX certificates


On 11/07/2022 18:31, open doc wrote:

Bonjour à tous,

désolé de ce thème évoqué très fréquemment, mais nous avons un vrai 
problème de traitement de mail par orange. Nous envoyons environs 110 
000 mails par jour, on a fait attention au SFP, DKIM ... Je me suis basé 
aussi sur www.mail-tester.com  pour valider 
le contenu du mail, et le score est pas mal, 9,1/10, ca donne une tendance.


On a eu plusieurs problèmes (sendertool.vadesecure.com 
), mais au final, on fini par trouver 
des solutions. (inscription, déclaration des ip ...)


Sauf que depuis 2 semaine avec orange, c'est un peu n'importe quoi. Les 
mails sont bien acceptés (code 250) et hop disparition !


---
2022-07-11 07:16:39 1oAlXi-0002uo-34 => xx...@orange.fr 
 R=dnslookup T=remote_smtp 
H=smtp-in.orange.fr  [80.12.26.32] 
X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 
DN="C=FR,L=Paris,O=Orange,CN=smtp-in.orange.fr 
" C="250 2.0.0 AlmgoeTIHnwFpAlmgoELJo mail 
accepted for delivery"

2022-07-11 07:16:39 1oAlXi-0002uo-34 Completed
---

Le retour de nos utilisateurs est que les mails arrivent en spam ou 
n'arrive pas du tout, et j'ai pas de résumé "dmarc" via orange. Bref je 
ne sais pas trop quoi faire, on fait sûrement des erreurs dans nos 
envoies, mais j'aimerai échanger avec une personne qui pourrait nous 
aider à comprendre ce phénomène sachant, que le contenu envoyé, est du 
contenu payant et ca énerve très fortement nos clients.


Si vous avez une idée, je suis preneur.

Par avance merci pour vos réponses.

Alex

___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: PHP Sury Debian9

[Maxime DERCHE]

Bonjour Laurent,

Le 12/07/2022 à 08:25, Laurent Barme a écrit :


Le 12/07/2022 à 07:36, Maxime DERCHE a écrit :

Bonjour Jérôme,

J'espère que tu vas bien. :)

Ma question ne porte pas sur l'existence de logiciels obsolètes donc sur la gestion 
du risque qu'ils induisent, mais sur le risque induit par la publicité qui en est 
faite, à plus ou moins bon escient.


Le "risque induit par la publicité qui en est faite" est certainement encore plus 
dérisoire que celui des logiciels "obsolètes". Comme si une debian 9 devenait 
dangereuse à partir du 01/07/22, fin de sa LTS !


La frénésie des mises à jour comme solution universelle de sécurité tiens davantage 
d'une posture dogmatique que d'une réalité opérationnelle.


C'est une réponse opérationnelle donc partielle à une question beaucoup plus générale 
et par ailleurs largement dépassée aujourd'hui. :)


La question de la date d'obsolescence du logiciel est aujourd'hui un consensus dans 
toute l'industrie, car tout le monde en a besoin :
  * le logiciel libre en a besoin pour clarifier sa gouvernance (cycle de vie et 
gestion de l'effort collectif) ;
  * le logiciel propriétaire en a besoin pour des raisons économiques (fin de 
support contractuel) ;
  * la sécurité en a besoin pour clarifier sa gouvernance (la même règle pour tout 
le monde, infra et dev inclus) ;

  * les financier-es en ont besoin pour gérer les coûts à l'avance (eh ouais).

À titre de simple exemple, choisi hors du champ de l'infrastructure : il n'est pas 
possible de stopper toute l'activité de développement un lundi matin de décembre 
juste avant les vacances de fin d'année pour exiger une correction immédiate de tous 
les Apache log4j (ou Spring Boot quelques semaines plus tard) dans tous les projets 
de toutes les équipes sans avoir une gouvernance claire sur le moment où un logiciel 
est "considéré" comme obsolète. Ça peut paraître arbitraire, mais d'une part ça ne 
l'est pas tant que cela puisque clairement affiché par toute une industrie, et 
d'autre part il n'est pas envisageable de gérer l'obsolescence au cas par cas dans le 
cadre d'une négociation entre la sécurité et chaque équipe (la sécurité est déjà 
suffisamment en souffrance comme cela...).


L'arbitraire d'une date fixe d'obsolescence est de plus largement atténué par la 
pratique sécurité habituelle qui fonctionne en cycles d'amélioration continue 
reposant sur des "feuilles de routes" généralement trimestrielles... (Sauf cas où 
le-la RSSI est un-e imbécile qui exige seul-le l'impossible du haut de sa tour 
d'ivoire.) Donc non Debian 9 n'est pas "dangereuse" à date de fin de support, mais 
elle peut le devenir quelques heures/jours/semaines/mois plus tard au gré des 
publications de sécurité : c'est un vrai risque.


Pour conclure, la frénésie des mises à jour n'est que très rarement la solution 
universelle de sécurité : la doctrine (pire qu'un dogme ?) actuelle est à la défense 
en profondeur où chaque composant/couche/maillon doit pouvoir assurer sa propre 
défense individuellement et en autonomie.


C'est très bête mais si la mise à jour était la seule mesure de sécurité cela 
n'obligerait le crime organisé qu'à migrer massivement vers du 0day, le problème 
resterait donc le même...



Le débat aujourd'hui dans le milieu sécurité n'est donc plus à justifier la gestion 
de l'obsolescence du logiciel, mais à couvrir les angles morts comme les offres 
d'emploi ou l'entraide technique publique. D'où ma question initiale.



Bien cordialement,
--
Maxime DERCHE
OpenPGP public key ID : 0xAE5264B5
OpenPGP public key fingerprint : 7221 4C4F D57C 456F 8E40 3257 47F7 29A6 AE52 
64B5

___
Liste de diffusion du %(real_name)s
http://www.frsag.org/