Les certificats, de l’émission à la révocation

L’art de se téléporter n’est plus réservé au cinéma ! Suite au développement de nouveaux paradigmes tels que le SDN, facilitant le déploiement de firewalls, la sécurité du plan de données a considérablement augmenté. Mais est-il possible d’éviter ces points de passage pour exfiltrer des données entre deux extrémités d’un réseau ? Au lieu de chercher un trou dans le mur, ne serait-il pas plus simple de trouver un moyen de le contourner ? C’est là l’ambition des techniques de téléportation. Nous explorerons les différentes techniques exploitant ce concept, puis nous reproduirons l’une de celles-ci sur un contrôleur SDN, ONOS.

Les protocoles de chiffrement de données, tels que SSL et son successeur TLS, sont au cœur des problématiques de la sécurisation des échanges sur les réseaux informatiques (dont Internet est le plus vaste représentant). Pour un développeur, comme pour un administrateur système, il est donc essentiel de bien comprendre à quoi ils servent, ce qu’ils font, et aussi quand s’en servir. Dans cet article, nous nous proposons de revenir sur toutes ces notions afin de s’assurer de leur bonne compréhension.

Lier le monde de l’administration système et celui du réseau n’est pas chose aisée, ni donné à tout le monde. De nombreux outils présents issus du monde de l’open source essaient désespérément d’y trouver une place. L’un d’entre eux a par ailleurs une longueur d’avance. Permettant de jouer avec la création de socket sur la couche transport du modèle OSI, Netcat rayonne dans le monde underground depuis déjà de nombreuses années. Rien de tel qu’une petite histoire pour parler de ce programme légendaire...

Comment protéger facilement tout son réseau des publicités sur Internet, en agissant au niveau serveur et non pas au niveau client ? Installez Pi-hole et utilisez-le comme serveur DNS local. C'est simple et très efficace.

Dans cet article, nous réfléchirons aux besoins de sécurité auxquels nos serveurs devront répondre. Il sera d’ailleurs plus question d’architecture que de serveur personnel. Pourquoi cela ? Car nos besoins vont à coup sûr évoluer dans le temps. L’approche la plus pérenne sera donc de mener une réflexion basée sur des services et non sur un serveur unique. Nous allons aussi nous attacher à assurer la résilience de nos services de base. Nos choix d’architecture auront pour objectif de pouvoir mieux détecter, contrer et éventuellement réparer les dommages causés par une attaque informatique. Nous pourrons par exemple restaurer nos services si un attaquant réussissait à prendre le contrôle du serveur. Notre plan de bataille commencera par la définition des grandes lignes de notre infrastructure, puis par la sélection de nos fournisseurs. Nous déploierons ensuite le serveur avec un premier palier de sécurisation système.