SysFailure

Imprimer

Stunnel - Configuration

.

Configuration de Stunnel

La configuration de stunnel ne se fait plus par des options sur la ligne de commande, mais par l'intermédiaire d'un fichier (/usr/local/etc/stunnel/stunnel.conf par défaut).

Stunnel peut fonctionner dans deux modes :

  • en mode serveur, il reçoit des connexions (SSL), procède au décodage et renvoie le résultat vers un port local. Il s'agit, comme le nom l'indique, de l'extrémité donnant accès au service protégé.
  • en mode client, il reçoit des données en clair sur un port déterminé et met en place une connexion vers un service SSL.

Un même fichier de configuration peut mélanger des services de type "serveur" et des services de type "client".

Configuration simple

Un service est défini par une chaîne placée entre crochets. Les principales directives sont :

  • accept : port (forcément local) sur lequel STunnel attendra des connexions. Obligatoire.
  • connect : port (ou machine:port) sur lequel STunnel renverra les données reçues sur le port précédent. Obligatoire.
  • client : définition du type de fonctionnement de STunnel pour ce service.

Si client = yes, STunnel fonctionne en mode client. STunnel mettra alors en place une connexion SSL vers le port (la machine/le port) indiqué(e) par la directive connect. A l'inverse, si client = no (ou en l'absence de la directive client), STunnel fonctionnera en mode serveur. Les connexions reçue sur le port défini par accept doivent alors être des connexions SSL, qui seront décodées et transmises vers le port (ou vers la machine:port) indiqué(e) par la directive connect.

Une remarque : si tous les ports définis par des directives accept sont supérieurs à 1024, STunnel pourra être lancé par un utilisateur non privilégié. Sinon, il faudra que STunnel soit lancé par le super-utilisateur.

Par exemple :

[6543]
accept = 6543
connect = une.machine.tld:443
client = yes

définit un service écoutant sur le port 6543, en mode client, et routant ensuite les données vers le port 443 de une.machine.tld. Cet exemple correspond à l'utilisation d'un client incapable de dialoguer en SSL, afin d'accéder à un serveur SSL. Le client est configuré pour dialoguer, en local, avec STunnel sur le port 6543 (dialogue en clair, donc), et SSL est géré par STunnel.

La définition d'un service de type serveur est identique, à l'exception de la directive client :

[443]
accept = 443
connect = 4433

Dans le cas précédent, STunnel écoute sur le port 443, décodera les connexions SSL qu'il reçoit sur ce port et transmettra les données (en clair) sur le port local 4433.

Nous soulignerons que rien n'oblige les connexions en clair à être strictement locales, de même que les connexions SSL n'ont aucune obligation à être faites vers un système distant (mais l'utilisation de SSL pour une connexion purement locale à la machine ne présente qu'un intérêt limité). Il est donc tout à fait possible de configurer un service comme

[1234]
accept = 1234
connect = un.systeme.ailleurs:4321

Les données reçues sur le port 1234 (terminaison d'une connexion SSL, puisqu'il s'agit ici d'un service de type serveur) sont, après déchiffrement, renvoyées vers le port 4321 sur un.systeme.ailleurs. Il est évident, toutefois, qu'avec une telle configuration les données reçues vont ensuite transiter en clair entre la machine sur laquelle s'exécute STunnel et la véritable destination (un.systeme.ailleurs). Cela ne peut être envisagé que si le chemin réseau entre ces deux systèmes est totalement sous votre contrôle et bien sécurisé.