🔒 The Bastion

Présentation

Les bastions sont un groupe de machines utilisées comme point d'entrée unique par les équipes opérationnelles (administrateurs systèmes, développeurs, administrateurs de bases de données, ...) pour se connecter de manière sécurisée à des périphériques (serveurs, machines virtuelles, instances cloud, équipements réseau, ...), généralement via ssh.

The Bastion fournit des mécanismes d'authentification, d'autorisation, de traçabilité et d'auditabilité pour l'ensemble de votre infrastructure.

En se plaçant entre vos utilisateurs et votre infrastructure, The Bastion ajoute une couche d'abstraction, de sorte que votre infrastructure n'ait pas besoin de connaître individuellement les membres de vos équipes opérationnelles.

Chaque membre de votre équipe dispose d'un compte individuel sur The Bastion, et peut être membre d'un ou plusieurs groupes bastion qui peuvent leur donner accès à une ou plusieurs infrastructures. Les périphériques de l'infrastructure n'ont besoin de connaître et de faire confiance qu'au(x) groupe(s) bastion dont ils peuvent faire partie.

Le système RBAC fin de The Bastion permet de déléguer certaines responsabilités à n'importe quel compte, à l'échelle d'un groupe ou du bastion, y compris à des comptes qui pourraient être utilisés par votre automatisation pour, par exemple, gérer le cycle de vie des comptes (lié à votre système de gestion des ressources humaines, votre LDAP ou AD), garantir la mise à jour des ACL d'un groupe (lié à votre CMDB), etc. Les processus automatisés sont faciles à mettre en œuvre via l'API JSON sur SSH.

Ressources de connaissances

Vous voulez en savoir plus tout en voyant de jolis dessins ? Voici une série d'articles de blog qui approfondissent les fonctionnalités et principes fondamentaux de The Bastion :

• Partie 1 - Genèse
• Partie 2 - Vertige de la délégation
• Partie 3 - La sécurité au cœur
• Partie 4 - Une nouvelle ère

Autres ressources qui pourraient vous intéresser :

• Documentation en ligne
• (Vidéo en français, slides en anglais) The Bastion au Very Tech Trip 2023, étude de cas de gestion d'une infrastructure avec et sans The Bastion
• (Vidéo en français, slides en anglais) The Bastion à l'OSSIR, 2021, explication rapide des principes fondamentaux, puis détail de la fonctionnalité des realms, et enfin focus sur les raisons pour lesquelles les choix techniques de mise en œuvre améliorent la sécurité (en ajoutant volontairement une vulnérabilité de sécurité dans le code pour le prouver !)
• (Podcast en français) The Bastion chez NoLimitSecu, 2021, interview avec questions-réponses

♻️ Aucune hypothèse sur votre environnement

Rien de sophistiqué n'est nécessaire, ni du côté entrant ni du côté sortant de The Bastion pour le faire fonctionner.

Seul votre bon vieux client ssh est nécessaire pour se connecter à travers lui, et de l'autre côté, n'importe quel serveur sshd standard fera l'affaire. Cela inclut, par exemple, les équipements réseau sur lesquels vous n'avez peut-être pas la possibilité d'installer un logiciel personnalisé.

Les anciens équipements qui ne prennent en charge que des algorithmes de cryptographie à faible sécurité ou telnet peuvent être cachés d'Internet en les plaçant derrière un pare-feu et en n'autorisant que The Bastion, évitant ainsi un compromis de sécurité en n'autorisant que des connexions de haute sécurité du côté entrant du bastion.

➰ Fiabilité

• Seules quelques bibliothèques bien connues sont utilisées, moins de code tiers signifie une surface d'attaque plus petite
• The Bastion est conçu pour être autonome : aucune dépendance telle que des bases de données, d'autres démons, d'autres machines ou des services cloud tiers, ni pour la phase d'authentification ni pour celle d'autorisation, signifie statistiquement moins de temps d'arrêt
• La haute disponibilité peut être configurée pour que plusieurs instances de bastion forment un cluster de plusieurs instances, avec n'importe quelle instance utilisable à tout moment (schéma actif/actif)

:godmode: Liste non exhaustive des fonctionnalités

• Schémas d'accès personnels et de groupe avec délégation des rôles de groupe pour garantir l'autonomie des équipes sans compromis sur la sécurité
• Rupture de protocole SSH entre les connexions entrante et sortante
• Enregistrement de session interactive (dans des fichiers ttyrec standard)
• Enregistrement de session non interactive (stdout et stderr via ttyrec)
• Support de logging étendu via syslog pour une consommation aisée par les SIEM
• Les fonctionnalités d'authentification incluent le support du MFA/2FA (mot de passe, TOTP) en plus de l'authentification par clé publique
• Support de l'attestation et de l'application des clés Yubico PIV du côté de la connexion entrante
• Support de mosh du côté de la connexion entrante
• Support du passage de scp, sftp et rsync pour télécharger et/ou téléverser des fichiers depuis/vers des serveurs distants
• Support du passage du sous-système SSH netconf
• Support des realms, pour créer une relation de confiance entre deux bastions de deux entreprises potentiellement différentes, en séparant les phases d'authentification et d'autorisation tout en appliquant les politiques locales
• Support de l'autologin SSH par mot de passe du côté sortant pour les appareils hérités ne supportant pas l'authentification par clé publique, tout en forçant une authentification par clé publique correcte du côté entrant
• Support de l'autologin telnet par mot de passe du côté sortant pour les appareils très anciens ne supportant pas SSH, tout en forçant une authentification SSH par clé publique correcte du côté entrant
• Support du proxy HTTPS avec gestion de l'authentification et de l'autorisation par intermédiaire, pour le découplage des mots de passe entrants et sortants (principalement utile pour les API des équipements réseau)

🔧 Installation, mise à jour, utilisation de The Bastion

Veuillez consulter la documentation en ligne, ou la version textuelle correspondante dans le dossier doc/.

🎥 Exemple rapide de connexion et de rejeu

⚡ TL;DR : testez-le : bac à sable jetable avec Docker

C'est un bon moyen de tester The Bastion en quelques secondes, mais lisez la FAQ si vous envisagez sérieusement d'utiliser la conteneurisation en production.

L'image du bac à sable est disponible pour les architectures suivantes : linux/386, linux/amd64, linux/arm/v6, linux/arm/v7, linux/arm64, linux/ppc64le, linux/s390x.

Lançons l'image Docker :

docker run -d -p 22 --name bastiontest ovhcom/the-bastion:sandbox

Ayez votre clé publique SSH à portée de main, puis configurez le premier compte administrateur :

docker exec -it bastiontest /opt/bastion/bin/admin/setup-first-admin-account.sh poweruser auto

Nous sommes maintenant opérationnels avec la configuration par défaut ! Configurons un alias pratique pour le bastion, et testons la commande info :

PORT=$(docker port bastiontest | cut -d: -f2)
alias bastion="ssh [email protected] -tp $PORT -- "
bastion --osh info

Cela devrait vous saluer en tant qu'administrateur du bastion, ce qui signifie que vous avez accès à toutes les commandes. Passons en mode interactif :

bastion -i

Ceci est utile pour appeler plusieurs plugins --osh à la suite. Maintenant, nous pouvons demander de l'aide pour voir tous les plugins :

$> help

Si vous avez une machine distante à laquelle vous souhaitez vous connecter via le bastion, récupérez votre clé de sortie :

$> selfListEgressKeys

Copiez cette clé publique dans le fichier authorized_keys de la machine distante, dans le dossier .ssh/ du compte auquel vous souhaitez vous connecter, puis :

$> selfAddPersonalAccess --host <remote_host> --user <remote_account_name> --port-any
$> ssh <remote_account_name>@<remote_host>

Notez que vous pouvez vous connecter directement sans utiliser le mode interactif, avec :

bastion <remote_account_name>@<remote_machine_host_or_ip>

C'est tout ! Bien sûr, il y a beaucoup plus à découvrir, la documentation est disponible dans le dossier doc/ et en ligne. Assurez-vous de consulter l'aide du bastion (bastion --help) et l'aide de chaque plugin osh (bastion --osh command --help). N'oubliez pas non plus de personnaliser votre fichier bastion.conf, qui se trouve dans /etc/bastion/bastion.conf (pour Linux).

🔀 Systèmes d'exploitation supportés pour l'installation

Les distributions Linux ci-dessous sont testées à chaque version, mais comme il s'agit d'un produit de sécurité, il est vivement conseillé de l'exécuter sur la dernière version stable à jour de votre système d'exploitation préféré :

• Debian 13 (Trixie), 12 (Bookworm), 11 (Bullseye)
• RockyLinux 10.x, 9.x, 8.x
• Ubuntu LTS 26.04, 24.04, 22.04
• OpenSUSE Leap 16.0

Toute autre version Linux dite "moderne" n'est pas testée à chaque version, mais devrait fonctionner avec des ajustements mineurs ou nuls.

Les systèmes d'exploitation suivants sont également testés à chaque version :

• FreeBSD 15.1, 15.0, 14.4

FreeBSD a un support partiel du MFA, en raison de son ensemble réduit de plugins pam disponibles. Le support d'un facteur supplémentaire (mot de passe ou TOTP) peut être configuré, mais pas les deux en même temps.

🆗 Qualité du code

• Le code est passé sous perltidy
• Le code est également passé sous perlcritic
• Des tests fonctionnels sont effectués avant chaque version

🛂 La sécurité au cœur

Même avec le processus de codage le plus conservateur, précautionneux et paranoïaque, le code contient des bugs, il ne faut donc pas lui faire aveuglément confiance. C'est pourquoi le bastion ne fait pas confiance à son propre code. Il exploite les primitives de sécurité du système d'exploitation pour obtenir une sécurité supplémentaire, comme vu ci-dessous.

• Utilise le contrôle d'accès discrétionnaire UNIX bien connu et fiable :

  • Les utilisateurs du bastion sont mappés à des utilisateurs système réels
  • Les groupes du bastion sont mappés à des groupes système réels
  • Tout le code vérifie constamment les droits avant d'autoriser une action
  • Le DAC UNIX est utilisé comme filet de sécurité pour empêcher une action de réussir même si le code est trompé et l'autorise

• Le script principal du bastion est déclaré comme shell système de l'utilisateur bastion :

  • Aucun utilisateur n'a d'accès shell réel (de type bash) sur le système
  • Tout le code est exécuté sous les droits du compte système non privilégié de l'utilisateur
  • Même si un utilisateur parvenait à s'échapper vers un shell réel, il ne pourrait pas se connecter aux machines auxquelles il n'a pas accès, car il n'a pas d'accès en lecture au niveau du système de fichiers aux clés SSH

• Le code est modulaire

  • Le code principal vérifie principalement les droits, enregistre les actions et permet l'accès ssh à d'autres machines
  • Toutes les commandes secondaires, appelées plugins, sont dans des modules séparés du code principal
  • Les modules peuvent être ouverts ou restreints
    • Seuls les comptes qui ont été spécifiquement autorisés sur la base du besoin d'utilisation peuvent exécuter un plugin restreint spécifique
    • Ceci est vérifié par le code, et également appliqué par le DAC UNIX (le plugin n'est lisible et exécutable que par le groupe système spécifique au plugin)

• Tout le code nécessitant des privilèges système étendus est séparé du code principal, dans des modules appelés helpers

  • Les helpers sont exécutés exclusivement sous sudo
  • La configuration sudoers est attachée à un groupe système spécifique à la commande, qui est accordé aux comptes sur la base du besoin d'utilisation

🔍 Auditabilité

• Les administrateurs du bastion doivent utiliser la logique du bastion pour se connecter à lui-même afin de l'administrer (ou mieux, utiliser un autre bastion pour le faire), cela garantit l'auditabilité dans tous les cas

• Chaque accès et action (qu'ils soient autorisés ou refusés) est enregistré avec :
  • syslog, qui doit également être envoyé à un serveur syslog distant pour garantir que même les administrateurs du bastion ne peuvent pas falsifier leurs traces, et/ou
  • des bases de données locales sqlite3 pour une recherche facile
• Chaque session est enregistrée avec ttyrec, des scripts d'aide sont fournis pour chiffrer et pousser ces enregistrements vers un serveur d'entiercement distant
• Ce code est utilisé en production dans plusieurs environnements certifiés PCI-DSS, ISO 27001, SOC1 et SOC2

🔗 Liens connexes

Dépendances

• ovh-ttyrec - une version améliorée mais compatible de ttyrec, un enregistreur de terminal (tty)

Outils optionnels

• yubico-piv-checker - un binaire Go autonome pour vérifier la validité des clés et certificats PIV. Optionnel, pour activer les fonctionnalités PIV de The Bastion
• puppet-thebastion (GitHub) - un module Puppet pour automatiser et maintenir la configuration des machines The Bastion
• the-bastion-ansible-wrapper - un wrapper pour permettre l'exécution de playbooks Ansible via The Bastion
• debian-cis - un script pour appliquer et surveiller le durcissement des hôtes Debian selon les recommandations CIS

Outils communautaires

Une liste non exhaustive d'outils connexes maintenus par la communauté :

• chef-cookbook - un cookbook chef pour installer the-bastion et configurer sa configuration par défaut
• ansible role - un rôle ansible pour installer et configurer the-bastion

📝 Licence

Sous licence Apache, Version 2.0 (la "Licence") ; vous ne pouvez utiliser ce fichier qu'en conformité avec la Licence. Vous pouvez obtenir une copie de la Licence à l'adresse

http://www.apache.org/licenses/LICENSE-2.0

Sauf si requis par la loi applicable ou convenu par écrit, le logiciel distribué sous la Licence est distribué "EN L'ÉTAT", SANS GARANTIES NI CONDITIONS D'AUCUNE SORTE, expresses ou implicites. Voir la Licence pour les autorisations spécifiques et les limitations sous la Licence.