Connexion
Abonnez-vous

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

Vous cherchez le bastion ?

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.

Le 11 décembre 2023 à 17h13

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).

Principe d’un proxy bastion : un serveur web présente l’affichage d’une session RDP, VNC ou SSH.
https://guacamole.apache.org/

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.

Stratégie pare-feu

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.

Commentaires (24)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
je lirais plus tard, même si perso je n'en ai pas besoin. j'utilise un VPN SSL sur le port 443 et ça passe presque partout (sauf si le FW fait de l'analyse https et le bloque ce qui est quand même rare hors entreprise)
votre avatar
D'ailleurs, je me tâte pour l'installation d'un VPN sur mon Rpi chez moi (juste pour router la connexion internet, pas d'accès à mon réseau domestique).

Dans la lignée de cette article, on aura un dossier du genre, avec les avantages et les inconvénients (surtout en terme de sécu) ?
votre avatar
Pour avoir essayé ça marche plutôt bien, vnc et rdp sur un desktop Linux ne sont malheureusement pas au point Teamviewer reste plus fluide...
votre avatar
De notre côté on utilise MeshCentral qui fait très bien le taff aussi :)
votre avatar
chouette article, ça donne envie de lire la suite, merci !
votre avatar
Je recommande la solution. Tous nos teletravailleurs passent par Guacamole. Ils en sont contents. Un utilisateur content ça n'a pas de prix, pour le reste y a master...
votre avatar
Nous on doit subir wallix au boulot ... du coup j'aurais bien envie de tester, faut juste que je regarde si ca supporte les clés U2F
votre avatar
Pourquoi "subir"?
votre avatar
Parce que je suis sur que le contrat en question doit couter une blinde, alors qu'avec un peu de boulot et ce genre de composants, on pourrait refaire le même ...

J'espère que la DINUM va faire comme pour tchap : contribuer au projet d'origine et fournir une surcouche à destination des agents de l'état
votre avatar
Franchement, il y a quand même pas mal de taff pour faire un bastion tout intégré avec coffre fort et chaine de confiance, tout en gérant l'intégrité des logs.

Tchap aux dernières nouvelles est sur une voie de garage, il y a eu des soucis. Maintenant il est préconisé l'utilisation de OLVID.

Edit: et un énorme problème d'une solution "faite maison" est sa soutenabilité. Surtout dans le secteur public, ce qui explique -hélas- la présence de contrats avec des sociétés privées avec des factures mirobolantes. Parce qu'elles savent qu'elles sont indispensables, faute d'avoir l'attractivité nécessaire à avoir les compétences pour internaliser un tel projet.
Sans parler des contraintes liées à l'homologation, notamment.
votre avatar
Tchap n'est absolument pas sur une voie de garage, crois-moi :-)

Olvid est difficilement déployable sur la cible de Tchap.
votre avatar
Je ne vois pas l'intérêt pour le moment: pas besoin de bricolage pour accéder aux machines en IPv6. Les ports, je les ouvre où je veux et la box n'a qu'à s'occuper du next hop. Pour la sécu, nginx en proxy ou bastion si besoin.
Aucun service en IPv4 hormis http/https donc plus besoin de multiplexer sur ce protocole.
votre avatar
Tu viens de dire que tu as ouvert des ports (RDP ou autre protocole de contrôle à distance, donc on parle de quelque chose de super sensible dans cet article) en accès direct depuis internet. IPv6 ou v4 peu importe c'est le même problème de sécurité. Le bastion est là justement pour éviter ce scénario et garder tes machines sans port ouvert accessible depuis internet. Ou bien je n'ai pas compris où tu voulais en venir.
votre avatar
Le début de l'article évoque les problèmes d'ouvertures et redirection de port d'un routeur IPv4 avant de poursuivre vers l'aspect sécurité.

Donc, en ce qui concerne les problèmes d'accès, le problème est avant tout IPv4.

Pour ce qui est de la sécurité, là encore, tout servir depuis une seule IPv4 partagée n'est pas l'idéal. Perso, mes services web ne sont pas disponibles sur les même adresses que les autres services pour plusieurs raisons dont le fait d'éviter les scans.

En concentrant tout le traffic dans un joli SPOF on facilite sûrement la gestion mais cela fragile le réseau. C'est un peu une habitude avec IPv4 comme le serveur DHCP qui te met une entreprise au chômage en cas de panne.
votre avatar
Doublon. J'ai dû faire un rechargement de force de la page pour avoir les commentaires.
votre avatar
j'avais tenté de l'installer en container docker, sans succès, je n'arrivais pas à le faire communiquer avec les machines clientes à contrôler...

je m'y remettrais à l'occasion, peut-être en dur sur une VM dédiée...
votre avatar
Seul 'probleme' de guacamole (et probablement d'autres faisant pareil), ça nécessite des websockets. Hors, certains proxies tatillons les bloquent, empêchant donc de facto de faire de la purée d'avocats.
votre avatar
Super, merci pour l'article il faudra que je me replonge dedans !
je l'ai benchmarké il y a 2 avec Wallix et d'autres... il a terminé 2eme derrière Teleport, qui est un cran au-dessus en termes de fonctionnalités, y compris dans sa version Community. Mais pour la vaste majorité des usages, Guacamole est largement suffisant (et c'est un vrai projet FOSS)
votre avatar
Article très intéressant et prometteur.

Question : on parle de 2FA pour root (et sur SSH ?) mais je n’ai jamais fait (malgré essais) ça. Mes expériences datent un peu donc ma question est de savoir s’il y a une solution aujourd’hui et si oui laquelle ?

Merci à tous
votre avatar
On peut creuser le sujet. Par contre il faut bien différencier "second facteur" et "second canal" ; j'en parle dans la suite en utilisant une solution multicanale, hélas non open source ;) D'un point de vue pratique, ça pourra faire l'objet d'un petit complément et d'un état des lieux, car ça évolue en permanence (quoique dans le fond, pas trop).
votre avatar
Je me permet un feedback -personnel- (il va probablement faire sourire les aguerris de Next impact)
Je trouve l'article clair (surtout au debut). Étant intéressé par -peu être un jour- avoir une petite instance quelque part, je vais suivre les articles.

Néanmoins je suis resté très perplexe sur cette phrase "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.) [...]"

Je suis d'accord que cela nécessiterais un article dedié! Avoir une instance et un ssh "ouvert au cartes vents" est problématique, et en fait même sur mon reseau local (e.g. RPI avec Pihole), je serais preneur d'explications!!

Merci pour la série d'articles!
votre avatar
La réponse courte, voici un guide de sécurisation avec quelques explications
cyber.gouv.fr République Française
votre avatar
Super article. Très hâte de lire la suite pour mettre en place un bastion. Merci !
votre avatar
La partie 2 est en ligne depuis hier :
https://next.ink/117621/guacamole-sur-un-plateau-2-5-apache-tomcat-et-lets-encrypt/
La 3 aujourd’hui :)

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

  • Le mot de la sécurité

  • Proxy ou bastion ?

  • Ajoutons un serveur (de Guacamole) à nos serveurs

  • Sécurisons un peu

Fermer