Guacamole sur un plateau (1/5) : on monte un bastion sécurisé

Un peu de technique, beaucoup de lignes de commande et quelques images pour changer un peu. C’est le menu du jour, proposé par Jean. Dans une série de cinq épisodes, il nous propose un tuto pour monter un serveur bastion sécurisé, y ajouter quelques ingrédients nécessaires, y placer le fameux guacamole, saupoudrer d’une couche de sécurité et enfin en profiter pleinement.

Les plus bidouilleurs de nos lecteurs disposent souvent de machines réparties un peu partout, et rien n’est plus énervant que d’être au bureau (ou, pour les plus chanceux, en vacances) sans pouvoir bichonner vos VM chéries à cause d’un wifi bridé sur le port 80 ou d’un réseau dont les règles de sécurité interdisent les protocoles RDP, SSH ou VNC (et les ports exotiques de façon générale).

Or, il existe des solutions, dites de bastionnage, dont le rôle est de centraliser ce type de flux et d’accès, tout en assurant la sécurité des échanges. Et, grâce à HTML 5, il est également possible de le réaliser via un simple navigateur ! Un outil tel que Guacamole, de la fondation Apache, nous permet d’accéder librement à nos chères machines. Il en existe d’autres, mais celle-ci est open source et gratuite (rappel : ce ne sont pas des synonymes).

Comme il est dit sur le site du projet : « Because the Guacamole client is an HTML5 web application, use of your computers is not tied to any one device or location. As long as you have access to a web browser, you have access to your machines ». Pour résumer, comme Guacamole est une application web HTML5, avoir simplement accès à un navigateur suffit pour accéder à vos machines.

On profitera aussi de cette occasion pour réviser quelques bases de sécurité (et de sécurisation) d’un serveur (Guacamole ou pas).

Le mot de la sécurité

Cette présentation a un but éducatif : vous aurez ici des bases, mais pour faire de la production, il faudra aller bien au-delà des conseils prodigués ici, en termes de sécurité, de résilience et de conformité.

Les accès distants, qu’ils soient entrants ou sortants, sont des sujets hérissant régulièrement les cheveux et autres poils des spécialistes de sécurité (pour ceux à qui il en reste).

Proxy ou bastion ?

Un proxy est un serveur relais entre deux infrastructures. Un proxy devient un bastion quand tout autre moyen de communication direct est interdit. Par exemple, si vous utilisez Guacamole pour accéder à des serveurs Windows en RDP, tout en laissant la connexion RDP possible, vous avez un proxy. Dans un tel cas, il ne sert qu’à faciliter la communication, quand les accès directs sont impossibles.

Par contre, si vous interdisez (volontairement) toute connexion autre que celle entre vos serveurs Windows et votre instance Guacamole, vous avez un bastion : cela devient le point de passage obligatoire pour accéder à vos machines, avec ainsi la possibilité d’ajouter des contrôles, du traçage et même l’enregistrement des sessions si votre activité est critique.

Ajoutons un serveur (de Guacamole) à nos serveurs

Allons de ce pas créer une nouvelle machine serveur, et pour cela une machine virtuelle légère fera l’affaire. Conformément à la politique et à la déontologie stricte que nous nous imposons, aucun des conseils qui va suivre ne comportera de lien publicitaire (il n’y aura d’ailleurs aucun lien, comme ça les choses seront claires).

Une VM très légère devrait suffire pour un usage personnel, et on en trouve à pas cher chez ionos.fr (ex 1&1) à 1 euro par mois la pièce, ou une stardust chez Scaleway à environ 4 euros par mois, plus chère, mais avec l’avantage de pouvoir être éteinte pour réduire la facture. Chez OVHcloud on démarre à 4,20 euros, mais sans le gain financier sur l’extinction.

Vous pouvez également mettre vos bons plans en commentaire. Partons de l’hypothèse d’une machine sous Ubuntu, mais les manipulations sur d’autres Linux ressembleront beaucoup à ce qui sera indiqué ici.

Sécurisons un peu

Sans creuser trop le sujet, car il mérite en soi des bouquins entiers, prenez quelques bonnes habitudes. On commence par mettre à jour tout ce qu’il faut. Ensuite on change le port SSH par défaut. Ça n’évitera que la brute force en masse d'attaquants ne faisant pas de reconnaissance de ports au préalable, mais c’est déjà ça.

Pour cela, un coup d’œil à /etc/ssh/sshd_config et on relance ssh. Sécurisez aussi l’accès du compte root (avec toutes les variantes possibles : authentification par certificat uniquement, second facteur, interdiction de la connexion root et utilisation de sudo, etc.) mais on risque de déborder largement du sujet.

Un point de vigilance : un pare-feu est très probablement configuré par votre hébergeur, il faudra l’adapter en conséquence. Pour ionos, il faut aller dans le menu « Serveurs & cloud », puis « Réseau » et « Stratégie de pare-feu » (à gauche) et éditer la stratégie appliquée à votre VM pour l’adapter au nouveau port choisi.

Ici le port 8443 est ouvert, on s’en servira pour Guacamole. Chez ionos, il est ouvert pour permettre l’utilisation de Plesk, mais il est également couramment utilisé pour des applications web Java en https (ce qui est le cas ici).

Pour les pointilleux, installez aussi tiger (pas le langage, l’outil d’audit de sécurité), et lancez-le de temps en temps. Attention à l’interprétation des logs qui peut être complexe.

On se donne rendez-vous demain pour l’installation des pré-requis, avec Tomcat et Let’s Encrypt.