Blog

Tous les articles

27/06/2022
Alexandre KOLACZ

sécurité
Sécurité de la configuration des containers dans GKE
(String: La nouvelle fonctionnalité de sécurité s’appelle “Protect pour GKE” et inclut actuellement une solution de scan automatique des problèmes de configuration des charges de travail. Cette solution n’a pas de coût supplémentaire et les scans n'utilisent pas de ressources de calcul de vos nœuds.)
Google vient de mettre à disposition en pre-GA (General Availability) un nouveau moyen de sécuriser et de contrôler les conteneurs qui tournent dans vos clusters Google Kubernetes Engine (GKE).

Attention ! Les fonctionnalités proposées avant la mise à disposition générale peuvent être limitées, et les modifications apportées à ces fonctionnalités peuvent ne pas être compatibles avec d'autres versions pré-disponibles).

Lire la suite
22/06/2022
Teddy FERDINAND

sécurité
Quand vos certificats TLS vous trahissent
(String: <div> <h2 id="un-besoin-de-transparence">Un besoin de transparence</h2> Pour comprendre pourquoi vos certificats peuvent être un vecteur d’attaque, nous allons nous pencher sur le fonctionnement même d’un certificat TLS, du point de vue de votre navigateur. <h3 id="fonctionnement-du-tls-%C2%AB-classique-%C2%BB">Fonctionnement du TLS « classique »</h3> Sur un certificat classique, voici ce qui va se passer lorsque vous allez vous connecter à un site web exploitant une négociation chiffrée. <figure> <figcaption> Fonctionnement du TLS « classique » </figcaption> </figure> Votre navigateur se connecte à l’adresse demandée, puis récupère son certificat. Ensuite, il va se connecter à l’autorité de certification qui a délivré ledit certificat pour contrôler si le certificat est bien valide. <h3 id="fonctionnement-du-tls-avec-transparence-des-certificats"> Fonctionnement du TLS avec transparence des certificats</h3> Lorsque votre navigateur supporte la transparence des certificats, le flux de contrôle est plus complet. En effet, en plus de vérifier le certificat auprès de l’autorité de certification qui l’a émis, il va aussi le contrôler via un serveur de log tiers. Il existe plusieurs serveurs de logs, vous pouvez d’ailleurs voir <a href="https://certificate.transparency.dev/logs/">la liste actuelle</a>. Cela permet de confronter plusieurs informations afin de ne pas valider un certificat auprès d’une seule source. C’est une précaution importante dans le cas où une autorité serait compromise, mais permet aussi de mieux gérer la révocation des certificats, sur laquelle nous reviendrons plus bas. <figure> <figcaption> Fonctionnement du TLS avec transparence des certificats </figcaption> </figure> Voici d’ailleurs la description qu’en fait l’ANSSI (Autorité Nationale de la Sécurité des Systèmes d’Information) : <blockquote> Certificate Transparency vise à renforcer les contrôles sur les certificats émis par des autorités de certification, notamment ceux utilisés par HTTPS. Initié par Google, ce mécanisme est désormais standardisé par l’IETF. L’objectif de cette technologie est de faciliter la détection de certificats frauduleux ou invalides. Pour cela, les certificats émis par les autorités de certification reconnues par les navigateurs sont enregistrés dans des journaux en ajout seul. </blockquote> Les serveurs de logs obéissent à certaines règles importantes pour garantir la transparence des informations : <ul> <li>On peut uniquement pousser des nouvelles informations, jamais modifier ou supprimer une information</li> <li>Les informations doivent exploiter la cryptographie <a href="https://en.wikipedia.org/wiki/Merkle_tree">Merkle tree</a> pour leur transmission</li> <li>Tous les logs sont auditables publiquement</li> </ul> On retrouve ici certains préceptes que les amateurs de blockchain reconnaîtront, le but est le même : assurer la traçabilité des certificats. Ainsi, dans le cas où un certificat serait révoqué, il suffit de pousser l’information de sa révocation sur le registre public et votre navigateur saura que malgré le fait que le certificat soit « techniquement » valide, il n’est en réalité plus utilisable. Cela permet aussi de suivre la chronologie du certificat (création, invalidation, etc.). <h2 id="quand-la-transparence-vous-expose">Quand la transparence vous expose</h2> Si on suit le raisonnement que j’ai eu plus haut, la transparence des certificats apporte énormément d’avantages. Toutefois, de par sa nature publique, il est facile de manipuler les logs pour extraire et exploiter des informations. Il existe pour cela de nombreux outils, parmi lesquels : <ul> <li><a href="https://crt.sh/">crt.sh</a> : Un site web sur lequel on peut retrouver les certificats émis pour un domaine donné</li> <li>Les <a href="https://github.com/google/certificate-transparency">outils</a> fournis par Google</li> </ul> Le fonctionnement restera le même pour un domaine, dont on peut extraire les certificats associés. Prenons l’exemple du très populaire <a href="https://hashicorp.com/">hashicorp.com</a>, site de l’éditeur d’outils et de solutions d’automatisation et de gestion pour le cloud dont vous pouvez retrouver nombre de billets les concernant <a href="https://blog.wescale.fr/tag/hashicorp/">sur ce blog</a>. En allant sur crt.sh, on retrouve donc les certificats émis pour ce domaine : <figure> <figcaption> crt.sh </figcaption> </figure> À partir de là, un attaquant va chercher à trouver les ressources qui sont plus susceptibles d’être mal protégées, comme : <ul> <li>Des sites hors production, où la sécurité est parfois perçue comme non nécessaire</li> <li>Des applicatifs connus comme étant des portes d’entrée et avec de gros privilèges, comme les outils de CI/CD par exemple (GitLab, Jenkins, etc.)</li> <li>Des projets « confidentiels », qui sont encore en R&D ou non annoncés</li> </ul> Pour poursuivre l’exemple, sur HashiCorp, un domaine a attiré mon attention, recherchant un mot clé « staging » : <figure> <figcaption> Le résultat de la recherche sur crt.sh </figcaption> </figure> <figure> <figcaption> Le site « staging » identifié </figcaption> </figure> En essayant d’accéder au dit domaine, surprise, ça fonctionne ! Dans cet exemple, rien de grave, le site contient une authentification et les ressources présentes ne sont pas jugées critiques par Hashicorp. Il m’est arrivé cependant de trouver des serveurs Jenkins exposés publiquement par cette méthode lors d’un simple audit.   <h2 id="mes-conseils-pour-g%C3%A9rer-vos-certificats">Mes conseils pour gérer vos certificats</h2>   <h3 id="scanner-r%C3%A9guli%C3%A8rement-vos-domaines">Scanner régulièrement vos domaines</h3> Vu que ces listes sont publiques, je vous recommande fortement de scanner régulièrement vos propres domaines pour identifier rapidement les nouveaux certificats et les dangers associés.   <h3 id="ne-pas-utiliser-de-vrai-nom-ou-type-de-solutions-en-rd">Ne pas utiliser de vrai nom ou type de solutions en R&D</h3> C’est la technique utilisée par énormément de gros acteurs du web : utiliser des noms de code pour vos projets en cours de développement. En cas de divulgation, cela permet de complexifier l’identification de la solution que votre domaine cache et éviter qu’un concurrent puisse se positionner face à vous.   <h3 id="sensibiliser-les-%C3%A9quipes">Sensibiliser les équipes</h3> Comme souvent en sécurité, le point majeur est le même : sensibiliser les équipes. Si vous n’expliquez pas à vos équipes DevOps ce vecteur d’attaque, elles continueront de créer des certificats sans appréhender ce risque. Il faut aussi rappeler que les environnements hors production doivent respecter les mêmes critères de sécurité que la production (par exemple avec une authentification obligatoire, ségrégation du réseau, etc.).   <h2 id="utiliser-des-certificats-wildcard-une-bonne-id%C3%A9e">Utiliser des certificats wildcard, une bonne idée ?</h2> L’une des solutions que l’on peut voir serait aussi d’exploiter des certificats wildcard sur vos applications. Dans le cas d’HashiCorp évoqué ci-dessus, cela donnerait « *. hashicorp.com ». Sur le papier, cela limite les risques évoqués plus haut, mais en crée en réalité de nouveaux. L’un des plus importants étant qu’en cas de compromission et révocation de votre certificat, l’impact sera bien plus large et vous obligera à redéployer un certificat sur un plus grand nombre d’applications. De plus, mutualiser un certificat augmente aussi les risques que celui-ci soit exfiltré.   <h2 id="pour-finir">Pour finir</h2> Vous l’aurez compris, un attaquant cherchera toujours la moindre information disponible. Il faut garder à l’esprit que la transparence des certificats est l’un des premiers vecteurs d’attaque exploités, car il donne souvent bien trop d’informations. Il est donc important de le protéger autant que possible comme chaque information publique que vous mettez à disposition. Dans les faits, la transparence des certificats reste un outil très puissant et sécurisant pour vous et vos utilisateurs, avec les limites évoquées plus haut.   <h3 id="remerciements">Remerciements</h3> Merci à notre partenaire HashiCorp avec qui nous avançons chaque année pour échanger et partager nos expertises et solutions. La sécurité fait partie de nos valeurs communes et ils nous ont permis de les citer comme exemple pour partager cette culture. </div>)
Les certificats TLS font partie du quotidien pour n’importe qui manipule les technologies du web. Mais saviez-vous que vos certificats peuvent trahir vos projets confidentiels, vos environnements non productifs ou la topologie de votre entreprise ?

Lire la suite
14/06/2022
Guillaume GUÉRARD

Actualités
Le meilleur de la HashiConf Europe 2022
(String: Après deux ans de pause, la HashiConf Europe était de retour à Amsterdam les 21 et 22 juin derniers. Nos  consultants Vincent et Guillaume étaient sur place pour représenter WeScale qui est partenaire d’HashiCorp. Dans cet article, vous trouverez un condensé de l’ensemble des annonces faites par HashiCorp et un résumé des conférences qu’ils ont le plus apprécié.)
Après deux ans de pause, la HashiConf Europe était de retour à Amsterdam les 21 et 22 juin derniers. Nos consultants Vincent et Guillaume étaient sur place pour représenter WeScale qui est partenaire d’HashiCorp. Dans cet article, vous trouverez un condensé de l’ensemble des annonces faites par HashiCorp et un résumé des conférences qu’ils ont le plus apprécié.

Lire la suite
08/06/2022
Alexis Morelle

Actualités
Les meilleures conférences du WeShare de mai
(String: <h2 id="sur-la-route-53-au-pays-du-dns">Sur la Route 53 au pays du DNS</h2> Chris fait peu d’histoire d’Internet à la manière de Père Castor, en ratissant de TCP/IP à DNS. On fait le tour des notions importantes de serveur d’autorité, de résolveur, de TTL et des différents types d’enregistrements (A, AA, CNAME, MX…) jusqu’à DNSSec et GeoDNS. Chris nous rappelle les pièges à éviter, les boucles DNS… Un exemple concret sur le blog de <a href="https://www.bortzmeyer.org/attaque-sous-domaine-caisse-epargne.html">Stéphane Bortzmeyer</a>. À coups d’outils tels que dig (l’assemblée propose drill également), ping, nslookup, on expérimente DNS, en jouant aussi avec /ect/hosts, avant de parler d’outils plus haut niveau tels que <a href="https://intodns.com/">intodns</a> (pour les recommandations), <a href="https://zonemaster.net/">zonemaster</a> (vérifié par l’afnil), <a href="https://dnsviz.net/">dnsviz</a> (visu), <a href="https://dnschecker.org/">dnschecker</a> (vérifier la propagation). Il est important de vérifier au travers de plusieurs sources. Enfin, on parle du service AWS Route 53 et de ses nombreuses fonctionnalités qu’il a fallu bidouiller à la main dans un passé lointain comme l’application recovery controller (round robin dynamique)…)
Le WeShare, c’est le premier lundi de chaque mois pendant lequel l’ensemble de la tribu se retrouve pour une journée de partage et d’échange. Voici le programme des conférences des deux dernières journées de WeShare d’avril et de mai.

Lire la suite
31/05/2022
Romain Davaze

Actualités
Le top des conférences KubeCon Valencia 2022

WeScale s’est rendue à la KubeCon 2022 organisée par la CNCF à Valence, en Espagne. Dans cet article, ses émissaires Mathieu et Romain vous ont condensé le résumé des meilleures conférences auxquelles ils ont assisté.

Lire la suite
25/05/2022
Élodie Billiot

Cloud Native
Packerisez les toutes
(String: <h2 id="les-bases-de-packer">Les bases de Packer</h2> Packer est un logiciel open source fourni par Hashicorp. En une phrase, c’est un logiciel qui vous sert à faire des images de manière automatisée. Il introduit un modèle pour vos images vous permettant d’uniformiser vos déploiements. Il est multi-providers et se déploie très facilement sur AWS, GCP et Azure. Il est stable et simple d'utilisation, en une commande, vous pourrez avoir votre instance déployée, configurée et uniformisée. Tout ça, en un rien de temps !)
Ici, on invente un nouveau verbe et oui ! Mais on va principalement parler de Packer avec AWS. Nous allons industrialiser la création de vos images machine avec la mise en place d’une pipeline de CI/CD, d’un modèle Packer et d’une post configuration avec Ansible, le tout sur AWS.

Lire la suite
20/05/2022
WeScale

sécurité
#WeSpeakCloud : Le podcast - Saison 2 - Episode 1 : La sécurité du point de vue de Teddy Ferdinand, DevSecOps chez Wescale
(String: )
Dans ce nouveau format, nous abordons des problématiques de l'informatique en observant comment plusieurs métiers y répondent et tentent de relever les nouveaux défis que celles-ci apportent.

Lire la suite
18/05/2022
Aurélien Maury

Cloud Native
Abhra Shambhala, le codingame développé sur Scaleway
(String:  )
Il y a bientôt un an naissait l'idée d'un coding game orienté DevOps et Infra-as-Code, un jeu de piste qui puisse autant amuser les experts que pousser les débutants à creuser et à se perfectionner pour relever les énigmes techniques proposées. Sur le chemin de sa réalisation nous avons acquis une certaine expérience autour de Rancher, l'outillage GitOps et Scaleway Elements qu'il est temps de vous partager.

Lire la suite
18/05/2022
Ismael HOMMANI

Cloud Native
A la découverte de Google Cloud Run Jobs
(String: Sortie en 2019, Cloud Run est un service serverless spécialisé dans la mise en place de workloads de serveurs Web scalables de zéro à l’infini. L’idée principale est de rester concentré sur la valeur du code plutôt que les problématiques sous-jacentes à son hébergement. Avec Cloud Run Jobs, Google nous propose une offre qui reste la même sur le fond mais change de cible de workload en nous faisant sortir du paradigme web serveur. Il est désormais possible de faire tourner des batchs, ce qui ouvre l’audience de Cloud Run à d’autres types de profils que les seuls développeurs Web.)
Lors de la Google IO 2022, Google a dévoilé le service Cloud Run Jobs.

Lire la suite