GKrellM, une loupe pour serveur - 2^e partie

Sécuriser avec un tunnel SSH

La suite logique à l’introduction à GKrellM : la mise en place de GKrellM en mode client-serveur, afin de surveiller à distance une ou plusieurs machines. La communication client-serveur de GKrellm se passant en clair sur le réseau, un tunnel SSH doit être déployé pour sécuriser la connexion lorsqu’elle transite par internet.

Introduction et installation

Cet article décrira une première configuration client-serveur insécuritaire, puis une seconde configuration sécuritaire. Les explications seront approfondies pour le client et serveur roulant Mandriva, cependant en principe les directives valent pour n’importe quelle distribution GNU/Linux avec des modifications mineures.

Pour les fins d’exemple, le serveur à surveiller sera désigné comme serveurasurveiller.example.com.

Les étapes de l’installation de GKrellM en mode local suivies sur le poste client, il reste à installer le serveur sur la machine à surveiller. Le nom de l’application : gkrellmd. Sur un serveur Mandriva, une fois authentifié, il suffit de taper :

su -c "urpmi gkrellm-server"

Première exécution, insécuritaire

Mandriva ajoute dans son paquetage gkrellm-server un script d’initialisation dans /etc/init.d/ qui s’appelle gkrellmd ; il suffit donc de démarrer le démon et le serveur pourra dès lors recevoir des connexions (il écoute au port 19150) :

su -c "service gkrellmd start"

Sur le client, il suffit de démarrer GKrellM en lui spécifiant qu’il doit se connecter au serveur :

gkrellm -P 19150 -s serveurasurveiller.example.com

Dès lors, une fenêtre de GKrellM affiche les signes vitaux du serveur.

Pourquoi insécuritaire ? que se passe-t-il ?

Par défaut, gkrellmd écoute au port 19150 et accepte les connexions provenant de n’importe quel ordinateur branché sur internet ;
L’information transmise par le serveur au client n’est pas chiffrée, c’est à dire que comme pour le courriel, n’importe qui branché sur internet entre le client et le serveur pourrait lire les données qui transitent.

Schématiquement, la connexion client-serveur établie à l’étape précédente ressemble à la Figure 1 :


Figure 1: Communication client-serveur de GKrellM, insécuritaire.

La commande gkrellm -s serveurasurveiller.example.com ouvre un port quelconque (appellé P sur le schéma) et se branche au port 19150 du serveur.

Creuser un tunnel

SSH permet en plus de se connecter à un shell sur une machine distante de relier un port d’une machine locale à un port d’une machine distante. La connexion entre les deux ports est cryptée donc indéchiffrable pour les gens situés entre la machine locale et la machine distante.

Tout comme pour l’utilisation classique de SSH, une authentification par mot de passe et/ou clefs numériques doit être effectuée. Pour creuser un tunnel entre la machine locale et le serveur distant, deux ports doivent être choisis : le port sur la machine locale, le port sur la machine distante.

Pour les besoins de GKrellM, le port de la machine distante est déjà connu : 19150. Pour la machine locale, n’importe quel port libre pourrait être utilisé [1], 19151 sera utilisé ici. La commande à taper, sur le client :

ssh -N -L 19151:monserveurasurveiller.example.com:19150 monserveurasurveiller.example.com

L’option « -L » sert à dire à ssh d’établir le tunnel. L’option « -N » quant à elle sert à indiquer que la connexion n’a pas besoin de démarrer un shell (par défaut, SSH démarrera un shell en plus d’établir le tunnel). L’exécution de cette commande mettra le tunnel en place. Aucune réponse ne vous sera donnée suite à cette commande. Si vous voulez libérer le shell et faire exécuter la commande en arrière-plan, vous pouvez ajouter un « & » à la fin de la commande avant de l’exécuter. (Note : le tunnel sera fermé si vous fermez la fenêtre de votre terminal).

Schématiquement, la commande précédente établit un lien comme sur la Figure 2 :


Figure 2: Déploiement d’un tunnel SSH

SSH ouvre un port quelconque (appellé Q sur le schéma) et se branche au port SSH (22) du serveur. Une fois la communication approuvée, du côté client, le port 19151 est ouvert ; du côté serveur un port quelconque (R) est lié au port 19150.

Repris en d’autres termes, toute communication établie au port 19151 sur la machine locale devient en fait une communication chiffrée au port 19150 de la machine distante.

Désormais, avec le tunnel, pour se connecter au serveur distant, il ne faut plus indiquer à gkrellm du côté client de se connecter au serveur serveurasurveiller.example.com mais bien au serveur local (localhost).

gkrellm -P 19151 -s localhost

Schématiquement, encore une fois, Figure 3 :


Figure 3: Communication de GKrellM à l’intérieur du tunnel SSH

gkrellm ouvre un port quelconque (désigné comme P sur le schéma) et va se connecter au port 19151 sur la machine locale. Le port 19151 local étant déjà lié par SSH au port 19150 de la machine distante, la connexion est établie au même titre que la connexion de la Figure 1 mais le transit par internet est chiffré et donc sécuritaire.

Sécuriser complètement

Un des deux problèmes de sécurité étant réglé, il reste à s’assurer que le serveur gkrellmd ne reçoive pas ses connexions à partir de n’importe où. Cependant, SSH a déjà réglé ce problème. Dans la Figure 1, le serveur gkrellmd reçoit une connexion provenant du client au port P ; dans la Figure 3, la connexion apparaît provenir localement (donc du port R de serveurasurveiller.example.com au port 19150 de serveurasurveiller.example.com).

Il suffit donc pour empêcher les connexions de n’importe où de forcer gkrellmd à n’écouter que les connexions provenant du serveur (serveur à serveur !), en modifiant [2] /etc/gkrellmd.conf. Une directive allow-host telle que celle-ci :

allow-host 127.0.0.1

Devrait suffire à rendre sécuritaire l’emploi de gkrellm en mode client-serveur. Ne pas oublier de redémarrer gkrellmd une fois le fichier /etc/gkrellmd.conf modifié :

su -c "service gkrellmd start"

Après ?

GKrellM a servi de prétexte pour voir comment établir et utiliser des tunnels SSH ; n’importe quel service port-à-port pourrait être sécurisé ainsi. Par exemple, telnet, cvs, pop, imap, smtp, finger, nntp, ldap pourraient être encapsulés dans un tunnel SSH, bien que souvent il existe des versions déjà sécuritaires des services (telnets, pop3s, imap4s, smtps, nntps, ldaps, ...) et qu’il s’avère plus aisé d’utiliser ces versions.

Une généralisation de ce principe de tunnel se trouve dans les VPN qui eux au lieu de lier port-à-port lient plutôt des adresses IP virtuelles de manière chiffrée. À explorer surtout pour des besoins d’entreprise.