Case Study

Dans certains cas on peut se retrouver avec la problématique suivante : Devoir manager différents serveurs à distance. Le problème ? C’est que l’ensemble de nos serveurs doivent être visibles depuis Internet afin que l’on puisse (via SSH et/ou HTTP/HTTPS) les administrer. Forcément on augmente notre surface d’attaque de ce fait.

Que faire ?

1. Splitter le réseau et mettre un serveur SSH en frontal.

Si vous avez la main sur l’architecture, vous pouvez splitter le réseau en deux parties :

• Une partie « INSIDE » qui contiendra les serveurs (avec des adresses IP privées) qui ne seront plus accessibles depuis l’extérieur.
• Une partie « DMZ » qui contiendra un serveur SSH utilisé pour la gestion.

Le rôle du serveur SSH devient central car c’est une fois connecté à lui que vous allez pouvoir vous connecter sur vos autres serveurs. Le SSH offre beaucoup d’avantages car il permet de pusher des données au travers du tunnel (notamment via SCP) sur vos serveurs mais il permet également de créer un proxy SOCKS si vous avez d’autres protocoles de gestion à utiliser (HTTP par exemple).

Note : Dans ce cas de figure, le serveur SSH doit avoir au moins deux interfaces réseaux (l’un dans le réseau isolé des serveurs et l’autre accessible depuis Internet).

2. Mettre un serveur SSH en frontal et faire du filtrage IP.

Si vous n’avez pas la main sur l’architecture, vous pouvez appliquer des filtres IP grâce à IPTables sur vos serveurs. L’idée est que seul le serveur SSH puisse accéder à vos autres serveurs (même si la surface d’attaque reste inchangée, on limite les accès et donc les possibilités de compromission).

3. Faire passer des flux de données dans le tunnel SSH (Proxy SOCKS).

Le gros avantage avec un tunnel SSH c’est que l’on peut créer un Proxy SOCKS. L’idée est de faire passer des flux de données par le biais du tunnel SSH pré-établi. Le concept du Proxy SOCKS est simple : on ouvre un port réseau en local (sur notre machine) et tout flux de données à destination de 127.0.0.1:xxx (où « xxx » est le port local utilisé pour le Proxy SOCKS) passera par le tunnel SSH. La notion de Proxy vient du fait que nous allons « prendre l’identité du serveur SSH distant ». Attention avec ce terme, quand j’entends prendre l’identité, cela veut dire que notre adresse IP deviendra celle du serveur SSH (utile si vous avez configuré des filtres IP).

Voici un exemple de Proxy SOCKS pour du trafic WEB (HTTP/HTTPS) :

Dans cet exemple, on ouvre le port « 8080 » sur notre machine en tant que Proxy SOCKS. Il suffira de configurer le proxy (127.0.0.1:8080) sur notre navigateur WEB afin que tout le trafic émanent de ce dernier passe par le tunnel SSH. Ce qui vous permettra (filtre IP ou pas) d’accéder à vos serveurs distants en HTTP/HTTPS si vous avez de la gestion à faire (et cela fonctionne pour les deux cas de figures vu ci-dessus).

Pour établir un Proxy SOCKS sur Linux, rien de plus simple :

ssh user@mon_serveur.com -D 8080

Où « -D 8080 » défini le port local du Proxy SOCKS.

4. Quelques notes.

• Pour rappel le protocole HTTP n’est pas sécurisé (les données passent en clair) et il est donc fortement conseillé d’utiliser le protocole HTTPS si vous avez des tâches d’administration à exécuter sur vos serveurs distants (Proxy SOCKS ou pas Proxy SOCKS).
• Le serveur SSH devenant un élément clé de votre infrastructure, il faut être très rigoureux concernant sa sécurité et il est donc conseillé de renforcer, notamment, la sécurité concernant la connexion au serveur.