Les contraintes de la prod

Lors de mon premier job de sysadmin, je traînais sur Clubic pour m’informer. Je me souviens de commentaires disant que les sysadmins n’ayant pas encore passés les pc de leur parc sur Windows Seven étaient des incompétents. Ça m’a marqué.

Dans la réalité

Quelques principes de base :

  • J’aime mon job, vraiment. Mais je ne suis pas là pour m’amuser, on me verse un salaire pour que je m’occupe de certaines tâches, j’avance des projets, je respecte les consignes. Si on me dit on passera à Windows Seven dans 10 ans, je réponds OK et je bosse sur ce qu’on m’a demandé
  • Si l’entreprise n’a pas les moyens d’acquérir les licences ou de renouveler les postes (licences OEM), je ne paye pas la licence Windows de ma poche
  • Dans toutes les entreprises où je suis passé, la montée de version du système d’exploitation correspondait au changement de la machine (en moyenne 5 ans). On sautait également un O.S sur deux, en gros j’ai jamais vraiment bossé avec Vista et Windows 8/8.1 mais avec XP, Seven et Windows 10
  • N’importe qui ayant 10 ans dans l’IT vous citera des exemples d’entreprises où des serveurs/postes sont sur des versions antédiluviennes. En 2016 j’avais encore des Windows Server 2003 en prod

Tu fais avec : Ce qu’on t’a dit, ce que tu as, ce que tu peux.

Parfois je suis gêné de parler de mon job actuel car je sais que je vais avoir des remarques du genre : « Attends t’es toujours sur *****, t’as pas encore mis en place *****, mais niveau sécurité ***** juste non ». Illustrons le sujet.

FTP

Nous sommes en 2019, je travaille chez un petit hébergeur web. Tout job a ses spécificités mais je dois avouer que celui d’hébergeur est super particulier.

Dans un article Bearstech rappelait que Apple, Google, Microsoft et Mozilla annonçaient il y a un an, la fin du support de TLS 1.0 et TLS 1.1 dans leurs navigateurs pour 2020. TLS 1.0 est vieux de 20 ans, TLS 1.3 date de l’année dernière et la majorité du trafic web chiffré se fait aujourd’hui avec TLS 1.2.

J’ai passé récemment un serveur sous Buster, rôle ftp, normalement easy. Dans mon /etc/proftpd/proftpd.conf j’ai TLSProtocol ALL -SSLv3 (doc) et voici la configuration par défaut de openssl que vous trouverez dans /etc/ssl/openssl.cnf sur Debian Buster.

Quelques jours après la mise en prod, nous avons reçu des tickets de clients signalant que leur accès FTP ne fonctionnait plus. Certains clients utilisent des logiciels datés qui ne savent pas gérer TLS 1.2/1.3 mais seulement TLS 1.0/1.1. Typiquement un logiciel codé avec WinDev, l’utilisateur met des fichiers Excel dans un dossier et appuie sur un gros bouton vert pour envoyer les fichiers par FTP. Le truc a été codé il y a XX années, ça marchait et le client comprend pas que ça marche plus. Il faut que ça fonctionne.

Voyez-vous ma configuration proftpd est correcte mais la configuration par défaut de openssl ne permet pas de négocier en dessous de TLS 1.2 (MinProtocol = TLSv1.2). J’ai donc dû mettre MinProtocol = TLSv1. Pour vérifier ce qui est accepté par votre serveur FTP.

Est-ce que la connexion est moins sécurisée ? Non (bien que cela rende les downgrade attacks possibles). Le logiciel PERMET de se connecter en TLS 1.0/1.1 mais l’immense majorité des clients/utilisateurs UTILISE TLS 1.2/1.3. Juste on ne FORCE pas les clients à utiliser TLS 1.2 au minimum sinon le FTP ne fonctionnerait plus pour certains d’entre eux.

Mais si la connexion se fait en TLS 1.0 par exemple, c’est moins secure ? Oui. Il s’agit du CHOIX des clients, ils préfèrent en général (tous ?) que ça fonctionne PEU sécurisé que PAS DU TOUT.

Et lors d’un audit de sécurité ? Rigolo. De rares clients font auditer l’hébergement que nous proposons, nous avons alors des remarques plus ou moins appuyées sur le fait qu’on permet des connexions TLS 1.0/1.1 dépassées ne devant plus être utilisées. Double dose.

Python et PHP

Python sera EOL (End Of Life) le 1 Janvier 2020, pour être précis : Support officially stops January 1 2020, but the final release (2.7.18) will occur after that date. La première release de la branche 2.7 date du 03/07/2010. La dernière release de la branche PHP 5 est la 5.6.40 EOL le 31/12/2018.

En 2019 nous recevons des tickets pour savoir si ces versions de Python et PHP vont rester disponibles, oui je vais devoir les compiler/fournir au grand minimum jusqu’à la prochaine migration vers Debian 11 (Bullseye). Dans notre cas les clients en ont BESOIN, on répond à leur DEMANDE, ils en assument les CONSÉQUENCES et nous leur rappelons les RISQUES.

Est-ce que c’est secure d’utiliser PHP 5.6.40 ? Non mais il faut toujours prendre en compte le CONTEXTE. Si votre intranet uniquement accessible en interne est en PHP 5.6.40, les risques d’avoir un problème sont très faibles. Si votre site est accessible en ligne par contre…

En résumé

Le prochain qui me dit « Attends t’es toujours sur *****, t’as pas encore mis en place *****, mais niveau sécurité ***** juste non », je le déguste avec une sauce tartare.

J’ai parlé de proftpd (retenu pour ses modules), pour certains ce ne sera peut-être pas le meilleur choix, n’oubliez pas : Il ne s’agit pas d’utiliser la meilleure solution, il s’agit de mettre en place la meilleure SOLUTION en fonction des CONTRAINTES de la prod.

Déjà 12 avis pertinents dans Les contraintes de la prod

  • Quelques précisions :
    * PHP 5.x n’est plus développé, mais est bien sûr toujours supporté (en particulier les patchs de sécurité) par les distributions l’embarquant, et ce pendant encore longtemps, par exemple PHP 5.4 avec Red Hat jusqu’en 2024, PHP 5.6 avec Debian jusqu’en 2020. Un tel système avec PHP 5.x et ses mises à jour dûment installées est aussi sûr voire plus qu’une déploiement dernier cri avec PHP 7.3, et surtout plus stable.
    * Laisser activé des vieux protocoles TLS/SSL, même s’ils ne sont pas utilisés par les clients, permet un certain nombre d’attaques, en particulier celles par déclassement (downgrade attacks) https://fr.wikipedia.org/wiki/Attaque_par_d%C3%A9classement
    * La sécurité est un compromis, car cela affecte négativement les performances et l’expérience utilisateur, coûte cher (souvent de manière non rentable), consomme plus d’énergie, et contribue à l’obsolescence prématurée
    * Je suis personnellement particulièrement sensible à ce dernier point sur l’obsolescence prématurée, et je fais des efforts pour ne pas trop y contribuer, par exemple en supportant les vieilles distributions et vieux matériels (mis en pratique dans FreshRSS, où la faible consommation de ressources et les faibles exigences ont une relativement haute priorité), mais cela requiert des efforts supplémentaires. Green IT 💚
  • bunam
    « Le prochain qui me dit « Attends t’es toujours sur *****, t’as pas encore mis en place *****, mais niveau sécurité ***** juste non », je le déguste avec une sauce tartare. » -> ça veut dire pas cuit ? alors tu prends des risques ;)
    Sinon sans rigoler on a vendu des trucs à des clients qui pensait dans leur tête acheter un produit fini comme une clé à molette, mais non, ces trucs demandent des évolutions permanentes…ou à refaire tous les 3 ans…
  • Plouf
    En tant que fournisseur de services ton travail consiste justement à gérer ses passages de versions. Planifier les mises à jour de configurations, assister les utilisateurs impactés,… Laisser ta plate-forme consciemment avec une sécurité en deçà des normes sans aucune forme de plan pour faire le changement, c’est avoir de la dette technique mais en plus ne rien faire pour l’éponger. Dans un domaine où de plus en plus d’entreprises se font descendre sur des questions de sécurité, c’est plutôt très grave. Tu renvoie la responsabilité de ta plate-forme à tes utilisateurs, mais tu fais comment pour t’assurer que le danger n’impacte pas les autres utilisateurs ? Bien sûr que changer les paramètres à l’arrache ça ne marche pas, mais informer préalablement les utilisateurs, monitorer les usages et explique qu’à partir d’une date buttoir, ils passent dans un mode dégradé (le service reste fourni, mais sur une machine distincte du classique et partout où c’est possible on rappel que c’est du legacy), ça permet de pousser les utilisateurs à migrer.
  • LeXa
    Si ça peut te rassurer, dans l’industrie pharma pour laquelle je bosse, on a toujours des stations d’analyse Win XP connectées au réseau « parce qu’il le faut »… Et des serveurs Win 2003 aussi, parce que le soft ET LE MATERIEL de monitoring température/humidité coûtent le blinde et que le boss ne veut pas comprendre qu’il faudrait changer… Que peut-on faire ? il est au courant, il ne peut pas dire qu’il ne sait pas, mais il ne déliera pas les cordons de la bourse… Eh bien, on fait avec… Jusqu’au prochain audit, où là, peut-être, il nous sera demandé de trouver, tester, qualifier, valider, changer en 15 jours pour un coût de 5 à 6 fois plus élevé que si on l’avait fait dans un rythme moins soutenu…
  • Je comprends tellement… nous en plus de la sécurité y’a pas mal d’outils (monitoring et automatisation, notamment) qui sont un peu à la bourre par rapport à ce qui peut exister ailleurs, mais tout ça demande du travail, du temps, et des autorisations (direction ou client), et même si ça bouge dans le bon sens, c’est une progression lente, et quand on parle (ou qu’on explique aux nouveaux), y’a souvent des critiques sur des point qu’on connaît voire dont on a déjà planifié la correction, et ça deviens rapidement lourd… si on fait ce qu’on fait comme on le fait, c’est rarement parce qu’on aime faire nawak.

Laisser un commentaire

indique des champs obligatoire.