Protéger son ownCloud de la Force (brute)

Commençons cet article par une question simple : existe-t-il encore un intérêt à installer et gérer une autorité de certification (AC) dans son réseau privé ? À première vue, questionner cette nécessité semble être une sage décision. Cependant, nous allons voir ensemble les avantages qu’apporte ce type de composant, aujourd’hui encore plus qu’hier, au sein d’un système d’information (SI). Nous installerons ensuite step-ca, l’autorité de certification open source de Smallstep, et l’utiliserons dans un cas d’usage qui mettra en évidence sa simplicité et son efficacité.

L’autorité de certification (AC) Let’s Encrypt a ouvert son service au public le 12 avril 2016. La part du trafic web chiffré ne cessa alors d'augmenter pour représenter actuellement près de 90% du trafic total. Sur le plan technique, Let’s Encrypt a pu réaliser un tel exploit notamment grâce à ACME, son protocole normalisé par l’IETF d’obtention automatisée de certificats. De nombreux clients ACME en ligne de commandes ont été développé et ont répondu à beaucoup de cas d’usage. Plus récemment, une étape supplémentaire a été franchie avec l’intégration de l’obtention de certificats Let’s Encrypt directement au sein de composants d'infrastructures comme HAProxy, Traefik ou les serveurs web Caddy et Apache et son module mod_md. C’est de ce dernier dont nous allons parler ensemble aujourd’hui.

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.

Nos serveurs présentent désormais une surface d’attaque réseau maîtrisée et une sécurisation système d’un niveau cohérent avec notre modèle de menaces. De même, le service SSH tournant sur ces serveurs est configuré de manière optimisée. Nous pouvons donc être relativement sereins si nos adversaires sont d’un niveau intermédiaire. Et si malgré toutes ces protections, une attaque comme un rançongiciel réussissait ? Et bien dans ce cas-là, pour l’instant, notre infrastructure serait particulièrement vulnérable. Aucune sauvegarde externalisée. Pas de centralisation des traces. Une supervision sécurité inexistante. Remédions à cette situation afin d’élever le niveau de maturité de la sécurité de notre infrastructure.