Cela faisait longtemps que je zieutais les solutions de bastion / proxy autant dans une optique de veille technologique sur nos accès fournisseurs divers que pour certains besoins internes de sécurisation. Assez récemment, et après pas mal de pérégrinations diverses zé variées (notamment avec SSHportal ou Guacamole), je suis finalement tombé en milieu d’année dernière sur la solution Teleport, que j’ai finalement pris le temps d’expérimenter … Et c’est génial ! Il faut que je vous en parle !
Teleport ? Energie, Scotty !
Dès qu’on a un besoin d’accès distant à des ressources d’infrastructure, se pose toujours la question du risque “d’ouvrir” un minimum nos barrières périmétriques et donc potentiellement d’augmenter notre surface d’attaque. Même avec un système de service VPN bien durci, il y a toujours un risque de s’exposer et accroitre mécaniquement notre vulnérabilité à toute sorte de tentatives de pénétration, préméditées ou non.
Teleport – comme certains autres bastion d’ailleurs, (Systancia Gate anciennement IPdiva ou Wallix Bastion, en france) – part du principe que pour ne rien exposer, il “suffit” de ne rien ouvrir. C’est une idée assez ancienne bien entendu, mais ses concepteurs sont partis d’un socle encore plus novateur et robuste à mon goût, une approche centrée sur l’Open Source et très orientée vers les métiers DevOps.
Teleport est donc un bastion, dans la plus pure tradition : vous créez des utilisateurs ayant des accès spécifiques à certaines ressources, mais n’ayant aucun besoin de connaitre les credentials réels (accès administrateurs ou exploitant) des ressources que vous allez leur présenter. Il sont authentifiés nécessairement en double facteur (impossible de se connecter à Teleport avec un seul facteur, vous le verrez) doivent uniquement leurs accès grâce à l’utilisation de mécanismes basés sur les échanges des traditionnels certificats (et clef privées/publiques associées).
Lors de leurs utilisation de la solution, toutes les sessions sont logguées, mais également, pour les plus interactives (SSH, RDP), enregistrées et rejouables à la demande (via un lecteur video ad-hoc). Teleport utilise aussi sa capacité à s’intégrer à des PKI externes pour générer tout ce qu’il faut pour garantir la sécurité globale du système (c’est notamment le cas lorsque vous souhaitez vous connecter à des postes de travail intégrés à votre Active Directory via RDP). Accesoirement il est également possible de mettre en place un partage de sessions à plusieurs, chacun se connectant au même client et pouvant interagir ensemble.
Bref, sur le papier c’est une vrai solution d’accès distant sécurisé, très complet et relativement facile à déployer aujourd’hui. Il existe deux formules différentes, dont les objectifs sont forcément différents : le mode Community, totalement Open Source et fourni gratuitement avec quasiment toutes les fonctions disponibles ; le mode Enterprise, toujours basé sur le même socle de sources et disponible en SAAS ou toujours en OnPremise pour la partie bastion proprement dite (à vous de choisir).
Teleport Community Edition
Je vous présente ici les quelques exemples que j’au pu déployer chez moi, directement (je n’utilise plus que cela désormais ^^), avec la solution Community. Si vous êtes pressé, il est possible aussi de tester la version Enterprise grâce à une solution SaaS (la partie Bastion du moins) disponible en trial pour 15 jours ; essayez-là, elle est à mon avis suffisante pour en tester le potentiel complet.
Pour simplifier à l’extrême, le bastion est la seule partie critique qui doit être accessible sur Internet, via son portail web. Ensuite, chaque noeud serveur ou client vien établir une connexion montante vers le bastion, grâce à un agent, et maintient ce lien tant que nécessaire. Cet agent assure tous les échanges in/out nécessaires à son accès à distance. Aucune règles particulière n’est nécessaire, en dehors du bastion lui même si vous choissez de le positionner en coupure interne/externe.
De mon coté, j’ai opté pour un bastion hébergé via une instance (VPS) chez Scaleway. Donc techniquement je n’ai aucun port ouvert chez moi depuis l’extérieur.
Au sujet de l’installation, la documentation disponible est relativement claire, cependant la courbe d’apprentissage reste assez longue pour bien comprendre la complexité intrinsèque du produit. Cela dépend vraiment de votre maturité vis à vis des nombreux principes de la philosophie DevOps (Kubernetes et autre Ansible sont vos amis ^^). Disons qu’un développeur rompu à l’exercice de manipulation de json, yaml, certificats etc, ne devrait pas rencontrer de problème. Pour votre info, il a fallu que je lise calmement et complètement la documentation, additionnée de quelques videos sur Youtube pour maîtriser à peu près la bête et cela m’a pris quelques jours. Bon, oui, on est d’accord, RTFM au final hein ? Oui, mais là c’est particulièrement vrai :)
Il faut signaler aussi que j’ai du jouer du Let’s Encrypt car ce bastion doit absolument être parfait en terme de certification publique, si vous comptez l’utiliser au quotidien. C’est un point d’accès critique, donc on déconne pas avec ça (sinon, vous risquez de galérer). A cette occasion j’ai découvert que OVH (et quelques autres hébergeurs sans doute) fournissent un jeux d’API très bien adaptée à la génération et renouvelement des certificats SSL sur un domaine hébergé chez eux. Je vous en parlerai sans doute bientôt car je n’utilise que cela désormais (encore une découverte récente). En attendant, vous trouverez des liens vers des sites qui en parlent et expliquent cette nouvelle méthode uniquement basé sur les DNS d’OVH, bien plus efficace et pratique, que l’utilisation plus classique de certbot, en fin de billet.
Noeuds server, mais en fait clients, enfin c’est pas si clair …
Une fois votre bastion installé sur un serveur dédié , Teleport se présente directement sous la forme d’un portail web, qui centralise les ressources (ssh, Kubernetes, accès direct aux BDD, RDP windows, web services, utilisateurs habilités, connecteurs d’annuaires ou de sources d’authentification additionnelles etc.) :
Mais, on est d’accord qu’un beau portail sans ressources accessible, c’est chouette, mais un peu limité. On va donc connecter notre premier “node” à notre cluster Teleport (tout le monde appelle des groupes de machines des clusters, maintenant, c’est désespérant … ). Etant donné la parenté très forte de Teleport avec le monde Linux/Containers/Kubernetes, une connexion avec un système traditionnel basé peu ou prou sur une distribution Linux, reste relativement simple. Voyez plutot sur une petite Debian 11. D’abord, on va préparer le bastion à accepter une connexion entrante :
A noter que vous pouvez déployer Teleport aussi sur MacOS mais il y a encore des limitations sur les Apple Silicon
Une fois fait, on va lancer la ligne de commande dédiée, qui va installer le package Teleport, activer le lancement du service automatiquement via systemd et configurer le server de ressource teleport (la configuration principale est dans /etc/teleport.yaml) avant de lancer le démon :
Si on retourne ensuite sur l’assistant du portail, il aura normalement détecté cette nouvelle ressource et vous permettre de vérifier que tout fonctionne bien. Quand vous déployez un server sous Linux, par défaut, il est capable de servir du SSH directement sur la machine :
Forwarding/proxying avec nos nouveaux noeuds ?
Chaque noeud déclaré offre donc déjà un accès SSH directement via le portail, mais peut aussi servir de relais/proxy local (à la manière du port forwarding à travers SSH) pour fournir un accès des ressources réseau au sein de votre Intranet (refaites un tour sur mon premier schéma en haut de ce billet). Par exemple, vous pouvez déclarer a peut près tout type de web service et les déclarer comme une “application”. C’est vrai pour les web services spécifiquement, mais aussi pour des ports TCP. On va prendre un exemple simple pour illustrer cette possibilité.
Vous êtes en train de mettre en oeuvre l’application Minio (il faut que je vous en parle aussi de ce truc là …), un logiciel dédié qui vous offre tout simplement un service S3 en littéralement quelques minutes chronos sur votre infra. Il se compose donc d’un service S3 classique mais aussi d’une console d’administration web. On va déployer un agent Teleport dédié pour avoir accès à cette console à partir du bastion.
Vous lancez encore une fois l’assistant de configuration ad-hoc depuis la console du bastion Teleport :
Une fois l’assistant déployé et la configuration spécifique lancée sur la machine, on a en théorie plus qu’à se connecter directement depuis le bastion. Sauf que … ooops, apparement une erreur “Internal server error”. En fait rien de très grave ni compliqué. Le souci est ici qu’on tente de se connecter à travers un site sécurisé vers une URL , elle-aussi sécurisée, mais dont le certificat n’est pas valide. Dans ce cas précis, il suffit d’ajouter au lancement de l’agent spécifique sur le proxy, la machine “minio” en l’occurrence la directive –insecure :
Et ce n’est qu’un avant goût !
Je ne viens que d’éffleurer le potentiel de Teleport, ici. Je n’ai pas parlé de la prise de main RDP sur potentiellement tous les postes déclarés dans un AD. Il existe, je l’ai dit, aussi des fonctions pour ouvrir des connexions sécurisées vers des Base de données, des clusters Kubernetes, voir plus avec les application “TCP”.
D’une manière générale, la logique de Teleport reste toujours la même. Ce bastion Open Source reste une petite pépite particulièrement puissante et sécurisée (justement car elle est Open Source), qui correspond vraiment à des besoins de plus en plus importants dans les entreprises. Son potentiel est quasiment illimité quand vous avez compris son mécanisme. La seule chose qu’il vous reste, c’est de l’essayer et de partager votre propre expérience avec moi bien sûr, mais aussi avec tous les autres adminsys et autres responsables sécurité !