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 ! <3 Pierre.
mail avec du retard j'ai fini par trouver. http://185.34.32.134/snapshots/sury-php/20220702010403/ 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 !
<3
Pierre.
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Le 07/07/2022 à 14:17, Pierre DOLIDON a écrit :
mail avec du retard
j'ai fini par trouver.
Bonjour, Je vous invite à préférer utiliser le nom de domaine : http://debian.octopuce.fr/snapshots/sury-php/20220702010403/ Ça vous ouvre la possibilité d’utiliser IPv6 et assurer la continuité de service si nous changeons d’adresses IP. J’ai d’ailleurs mis en place les redirections vers le fqdn cet après-midi. ,Cyprien
Le lundi 4 juillet 2022, 16:54:53 IST 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 !
Hello, http://185.34.32.134/snapshots/sury-php/20220702010403/ amicalement, -- Christophe Casalegno https://www.christophe-casalegno.com
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, -- Maxime DERCHE OpenPGP public key ID : 0xAE5264B5 OpenPGP public key fingerprint : 7221 4C4F D57C 456F 8E40 3257 47F7 29A6 AE52 64B5 <https://www.mouet-mouet.net/maxime/blog/>
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,
-- Jérôme Nicolle +33 6 19 31 27 14
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] : <https://www.boutique-dalloz.fr/code-de-la-cybersecurite-p.html>, publié le mois dernier, cf <https://actu.dalloz-etudiant.fr/index.php?id=11&no_cache=1&tx_ttnews[tt_news]=39606> 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,
-- Maxime DERCHE OpenPGP public key ID : 0xAE5264B5 OpenPGP public key fingerprint : 7221 4C4F D57C 456F 8E40 3257 47F7 29A6 AE52 64B5 <https://www.mouet-mouet.net/maxime/blog/>
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.
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 <https://www.mouet-mouet.net/maxime/blog/>
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] : <https://www.boutique-dalloz.fr/code-de-la-cybersecurite-p.html>, publié le mois dernier, cf <https://actu.dalloz-etudiant.fr/index.php?id=11&no_cache=1&tx_ttnews[tt_news]=39606>
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,
Bonjour Nous sommes une TPE d'experts télécoms, réseauxet sécurité. Nous sommes 4 ingénieurs et nousrecherchons un nouveau membre dans l'équipe. Nous sommes basés à Montesson dans le 78.Le poste est basé à Montesson et est en sédentaire. Nous recherchons un(e)ingénieur système réseauet sécurité passionné. Nous souhaitons faire évoluer cecollaborateur vers la direction technique et le pilotage des projets qui luisont attribués. Il doit être à la fois technique (pourdécouvrir et configurer les solutions) et fonctionnel pour proposer,inventer des architectures et de solutions pour le client. Lorsque la solutionest validée par le client il devra piloter ce projet en le déployant et en gérantla communication avec le client jusqu'à la recette finale Ensuite il participe avec l'équipe au SAV et à l'administration des nos plateformes de services. Les qualités humaines d'écoute, de curiosité,de service et de communication sont importantes. Côté technique, le profil recherché devraavoir une bonne connaissance et une expérience des système linux(virtualisation sous dokker/proxmox/kvm, déploiement sur cloud), Il aimescripter sous linux ou faire du développement d'api, il a une bonneconnaissance du réseau (Microtik /Cisco). Nous faisons du sur mesure en téléphonie,en réseau WAN/LAN/WIFI/VPN en intégration applicatifs (intégration office365/teamsavec des outils de communication tiers (asterisk, avaya,mitel, microsoft etc...), intégration de la téléphonieavec des CRM, intégration avec des outils de générateur d'appels, de relationsclients etc... Dans le domaine du réseau, nous déployonsnos propres lien WAN (fibre /ADSL/ADSL/4G) avec des partenaires en marqueblanche. Nous travaillons avec plusieurs éditeursde solutions (telecoms /reseaux/applications telephonie /Applications CRM/Centre d'appels/Studio enregistrements/securité par la gestion des alertes par exemple)et notre objectif faire communiquer les applications de différentséditeurs entre elles pour répondre à un besoin spécifique client. Si vous êtes intéressés vous pouvezpostuler à contact@alter-telecom.fr ou me contacter en privé.
Envoyé avec la messagerie sécurisée [Proton Mail](https://proton.me/). ------- Original Message ------- Le lundi 18 juillet 2022 à 14:04, fatiha boudj via FRsAG <frsag@frsag.org> a écrit :
Bonjour
Nous sommes une TPE d'experts télécoms, réseaux et sécurité.
Nous sommes 4 ingénieurs et nous recherchons un nouveau membre dans l'équipe.
Nous sommes basés à Montesson dans le 78. Le poste est basé à Montesson et est en sédentaire.
Nous recherchons un(e)ingénieur système réseau et sécurité passionné.
Nous souhaitons faire évoluer ce collaborateur vers la direction technique et le pilotage des projets qui lui sont attribués.
Il doit être à la fois technique (pour découvrir et configurer les solutions) et fonctionnel pour proposer, inventer des architectures et de solutions pour le client. Lorsque la solution est validée par le client il devra piloter ce projet en le déployant et en gérant la communication avec le client jusqu'à la recette finale
Ensuite il participe avec l'équipe au SAV et à l'administration des nos plateformes de services.
Les qualités humaines d'écoute, de curiosité, de service et de communication sont importantes.
Côté technique, le profil recherché devra avoir une bonne connaissance et une expérience des système linux (virtualisation sous dokker/proxmox/kvm, déploiement sur cloud), Il aime scripter sous linux ou faire du développement d'api, il a une bonne connaissance du réseau (Microtik /Cisco).
Nous faisons du sur mesure en téléphonie, en réseau WAN/LAN/WIFI/VPN en intégration applicatifs (intégration office365/teams avec des outils de communication tiers (asterisk, avaya,mitel, microsoft etc...), intégration de la téléphonie avec des CRM, intégration avec des outils de générateur d'appels, de relations clients etc...
Dans le domaine du réseau, nous déployons nos propres lien WAN (fibre /ADSL/ADSL/4G) avec des partenaires en marque blanche.
Nous travaillons avec plusieurs éditeurs de solutions (telecoms /reseaux/applications telephonie /Applications CRM/Centre d'appels/Studio enregistrements/securité par la gestion des alertes par exemple)et notre objectif faire communiquer les applications de différents éditeurs entre elles pour répondre à un besoin spécifique client.
Si vous êtes intéressés vous pouvez postuler à contact@alter-telecom.fr ou me contacter en privé.
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
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 <https://www.mouet-mouet.net/maxime/blog/>
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
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 <frsag@frsag.org> 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/
participants (11)
-
Christophe Casalegno -
Christophe Casalegno (Brain 0verride)
-
Cyprien Nicolas -
fatiha boudj -
Jérôme Nicolle -
Laurent Barme -
Maxime DERCHE -
Pierre DOLIDON -
Rémy Dernat -
Thomas -
Wallace