Administration de serveur Unix en DMZ via serveur de rebond

Posté par  (site web personnel) . Modéré par Mouns.
Étiquettes : aucune
2
7
mar.
2008
Sécurité
Dans ce qui va suivre, j'essaierai de vous présenter une technique que j'utilise pour accéder à mes serveurs via des points de montage sshfs (basé sur fuse) encapsulé dans des tunnels SSH.

Dans ce qui va suivre, je ferai des références à un ensemble de produits. Je vais en faire ici une rapide présentation :
  • openssh (que je ne présenterai pas)
  • fuse : module noyau permettant de manipuler des points de montage en tant qu'utilisateur lambda
  • tsocks : bibliothèque permettant l'encapsulation des requêtes réseaux d'un programme.
  • afuse : utilitaire permettant de se servir de fuse pour faire des automounts.
Installation

Pour ce qui va suivre, je me baserai sur une installation standard de Kubuntu 7.10 et nous allons notamment avoir besoin des paquets suivants :
  • sshfs
  • tsocks
  • afuse
Si vous choisissez aptitude pour faire votre installation, vous procéderez comme suit :

sudo aptitude install fuse tsocks afuse

L'installation ne posant pas de problème insurmontable, je ne m'étendrai pas plus sur le sujet.

Vous devez en revanche vous assurer que votre utilisateur (dans mon cas yannig) doit bien appartenir au groupe fuse :

yannig@yannig-desktop:~$ id -a
uid=1000(yannig) gid=1000(yannig) groups=4(adm),20(dialout),...106(fuse),108(lpadmin),...1000(yannig)

Si ce n'est pas le cas, vous pouvez rajouter l'utilisateur avec la commande suivante :

yannig@yannig-desktop:~$ sudo usermod -G fuse yannig

Attention de vous déloguer/reloguer si vous êtes dans une session graphique pour prendre en compte ce changement de groupe. Il faudra également relancer votre terminal si vous êtes logué en ssh sur votre machine.

Mise en place

La première étape va consister à mettre en place nos moyens de communication avec le serveur de rebond et entre autre la mise en place de clé d'authentification. Pour se faire, nous allons user des clés d'authentification que nous déposerons dans le répertoire adhoc de l'utilisateur du serveur de rebond :

1/ Génération de la clé :

yannig@yannig-desktop:~$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/yannig/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/yannig/.ssh/id_dsa.
Your public key has been saved in /home/yannig/.ssh/id_dsa.pub.
The key fingerprint is:
a9:xx:7d:xx:d9:xx:ea:xx:bd:xx:66:xx:98:xx:47:xx yannig@yannig-desktop

2/ Dépôt de la clé sur le serveur de rebond :

yannig@yannig-desktop:~$ cat .ssh/id_dsa.pub | ssh yannig@rebond "cat >> /home/yannig/.ssh/authorized_keys"
The authenticity of host 'rebond (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is 78:xx:ab:xx:d7:xx:26:xx:49:xx:ec:xx:aa:xx:47:xx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'rebond' (RSA) to the list of known hosts.
yannig@rebond's password:

Nous recopions ici le contenu de la clé publique que nous venons de générer dans la liste des clés autorisées à se connecter sur mon compte sur le serveur de rebond. Ainsi, la prochaine fois que nous chercherons à nous connecter sur la machine de rebond, je n'aurai pas de mot de passe à saisir :

yannig@yannig-desktop:~$ ssh yannig@rebond
Last login: Wed Mar 5 09:21:35 2008 from xx.xx.xx.xx
Authorized uses only. All activity may be monitored and reported.
yannig@rebond#

3/ Création d'un point de montage sshfs

yannig@yannig-desktop:~$ mkdir test
yannig@yannig-desktop:~$ sshfs yannig@rebond:/tmp test
yannig@yannig-desktop:~$ ls test
croxxLa crxxLa getxxxt psxxta
crouxxiLa get_xxp lxxe
croxxiLa gexxxt PPCxx303

Ça à l'air de fonctionner !

Accès à nos serveurs via serveur de rebond

Nous avons maintenant configuré une connexion à notre serveur de rebond et nous pouvons même monter en local le système de fichier via SSH du serveur de rebond. Problème, si nous devons accéder aux serveurs derrière le serveur de rebond, nous sommes obligés de nous reconnecter à chaque fois sur ce dernier pour ensuite lancer la connexion :

yannig@yannig-desktop:~$ ssh -o ConnectTimeout=2 yannig@host-dmz1
ssh: connect to host host-dmz1 port 22: Connection timed out

=> impossible de se connecter directement sur le serveur host-dmz1

yannig@yannig-desktop:~$ ssh yannig@rebond
Last login: Wed Mar 5 09:45:36 2008 from 10.251.100.134
yperre@rebond#ssh yannig@host-dmz1
yannig@host-dmz1's password:

Ce genre de chose entraîne plusieurs inconvénients :
  • multiplication du nombre de connexions sur la machine de rebond
  • perte de temps et multiplication des opérations pour se connecter à vos machines. Lorsque vous avez un parc de 200 machines à administrer, vous n'avez pas forcément envie de vous reconnecter 50 fois par jour.
L'idée est donc de réutiliser tout le temps la même connexion pour faire transiter vos connexions vers la DMZ. Pour se faire nous allons utiliser les tunnels SSH et notamment, l'attribution des connexions dynamiques (option -D).

Pour se faire, nous allons relancer notre connexion sur le serveur de rebond en y ajoutant l'option '-D 8888' permettant la création d'un port dynamique sur le port 8888 (le port dynamique est en réalité vu comme un serveur socks) :

yannig@yannig-desktop:~$ ssh -D 8888 yannig@rebond
Could not request local forwarding.
Last login: Wed Mar 5 09:48:38 2008 from 10.251.100.134
yannig@rebond#

Remarque, si vous voyez les lignes suivantes :
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 8888

2 possibilités s'offrent à vous :
  • vous avez déjà une connexion ouverte avec un tunnel
  • vous avez un programme en local qui fait appel au port 8888 => Changez en !
Remarque : par la suite, je ne parlerai plus de port dynamique mais de serveur SOCKS.

C'est très bien tout ça mais ssh ne peut pas utiliser de serveur SOCKS pour se connecter sur nos serveurs. Il va donc falloir trouver une autre solution : une bibliothèque 'socksificatrice' (ouf!)

Vous avez le choix entre dante-client et tsocks. Mon choix c'est porté sur tsocks en raison de sa simplicité mais ce qui va suivre est tout à fait utilisable sous dante !

Comme nous l'avons vu plus haut, tsocks (sous *Ubuntu) s'installe simplement via le système de packaging. Par défaut, il vous proposera un fichier de configuration /etc/tsocks.conf. Je vous propose de le modifier de la manière suivante :

yannig@yannig-desktop:~$ cat /etc/tsocks.conf
#
server = 127.0.0.1
# Server type defaults to 4 so we need to specify it as 5 for this one
server_type = 5
# The port defaults to 1080 but I've stated it here for clarity
server_port = 8888

Il nous reste maintenant à socksifier nos appels ssh et tadam :

yannig@yannig-desktop:~$ LD_PRELOAD=/usr/lib/libtsocks.so ssh yannig@host-dmz1
yannig@host-dmz1's password:

Nous sommes maintenant en mesure d'accéder directement à notre serveur en DMZ depuis notre poste de travail. Essayons maintenant de combiner ceci avec un montage sshfs encapsulé dans un tunnel ssh :

yannig@yannig-desktop:~$ LD_PRELOAD=/usr/lib/libtsocks.so sshfs yannig@host-dmz1:/usr/local/lib test
yannig@yannig-desktop:~$ ls test
libcharset.a libgcc_s.so.1 libpopt.la
libcharset.la libiconv.la libpopt.so
libcharset.so libiconv.so libpopt.so.0
libcharset.so.1 libiconv.so.2 libpopt.so.0.0.0
libcharset.so.1.0.0 libiconv.so.2.4.0 libstdc++.a
libg2c.a libintl.a libstdc++.la
libg2c.la libintl.la libstdc++.so
libg2c.so libintl.so libstdc++.so.6
libg2c.so.0 libintl.so.3 libstdc++.so.6.0.3
libg2c.so.0.0.0 libintl.so.3.4.0 preloadable_libiconv.so
libgcc_s.so libpopt.a

Et hop, on a directement accès en local, de manière transparente, à nos fichiers sur la machine en DMZ. De là, il est tout à fait possible de recopier nos fichiers d'un serveur à un autre en s'appuyant sur ces points de montage.

Vous me direz que c'est déjà pas mal comme situation mais je suis malheureusement au regret de vous annoncer qu'on peut faire encore mieux : l'utilisation d'un automount fuse !

Automount avec fuse

Nous avons vu jusqu'à maintenant les points suivants :
  • utilisation d'un serveur de rebond
  • échange des clés privés / publiques
  • montage d'un système de fichier à l'aide du protocole ssh
  • connexion sur un serveur au travers d'un serveur SOCKS / tunnel / port dynamique
  • connexion d'un système de fichier par l'utilisation d'un serveur SOCKS.
Nous allons maintenant nous attacher à monter les partitions automatiquement à l'aide de afuse.

Pour se faire, nous allons lancer une commande qui prendra comme paramètre un template de montage fuse sshfs.

Voici la commande en question :

afuse -f -o \
mount_template="LD_PRELOAD=/usr/lib/libtsocks.so sshfs yannig@%r:/ %m" -o \
unmount_template="fusermount -u -z %m" ~/sshfs

A remarquer que cette commande bloquera votre terminal. Si vous désirez la lancer en tant que démon, il faudra la précéder de la commande nohup ainsi que '&' pour la lancer en arrière plan.

Autre remarque important, si vous utilisez une distribution récente (*ubuntu, debian, mandriva, etc), votre distribution utilisera certainement un encodage UTF8. Si vous utilisez un vieil Unix / Unix proprio (Solaris 8, AIX 5.x etc), vous aurez surement un encodage de type ISO8859-1. Il vous faudra surement renseigner l'option '-o from_code=ISO8859-1'.

Voyons maintenant le résultat :

yannig@yannig-desktop:~$ cd sshfs/
yannig@yannig-desktop:~/sshfs$ ls
yannig@yannig-desktop:~/sshfs$ cd host-dmz1
yannig@yannig-desktop:~/sshfs/host-dmz1$ ls
bin cdrom etc initrd lib media opt root srv tmp var
boot dev home initrd.img lost+found mnt proc sbin sys usr vmlinuz
yannig@yannig-desktop:~/sshfs/host-dmz1$ cd ..
yannig@yannig-desktop:~/sshfs$ ls
host-dmz1
yannig@yannig-desktop:~/sshfs$ cd recette-dmz1
yannig@yannig-desktop:~/sshfs/recette-dmz1$ ls
1 dead.letter HDS lost+found proc root
11 dev home mnt prod sbin
devices kernel mnt2 doc legal noautoshutdown
bin etc lib opt var usr
LICENSE.txt platform
yannig@yannig-desktop:~/sshfs/recette-dmz1$ cd ..
yannig@yannig-desktop:~/sshfs$ ls
host-dmz1 recette-dmz1

Vous voici maintenant capable de faire des recopies de manière transparente entre 2 machines pouvant se trouver sur 2 DMZ différentes depuis votre poste (ou encore en éditant ceci avec un emacs ou autre kate et vi) et tout ceci de manière complétement transparente tout en facilitant l'accès à vos machines en DMZ.

C'est les gars de la sécurité qui vont être contents !

Aller plus loin

  • # ProxyCommand

    Posté par  . Évalué à 6.

    je trouve la méthode utilisant Proxycommand bien plus simple et transparente:
    voir par exemple ici: http://ensl.free.fr/softrez/faq/faq-9.html#ss9.1

    (cela necessite d'avoir tcpconnect ou netcat sur le serveur rebond)

    • [^] # Re: ProxyCommand

      Posté par  (site web personnel) . Évalué à 2.

      Pour ma part, je préfère tsocks ou dante pour une raison simple : tu n'as besoin de rien sur ton serveur de rebond sauf de pouvoir créer des tunnels SSH.

      • [^] # Re: ProxyCommand

        Posté par  . Évalué à 3.

        En l'occurrence, pour la technique utilisant ProxyCommand, le seul prérequis dont tu as besoin, c'est d'avoir netcat sur le serveur de rebond. Rien d'autre n'est requis sur aucune des 3 machines (client, serveur, et serveur de rebond). Il se trouve en plus que nc est installé par défaut sur certains OS (OpenBSD, par ex.).

    • [^] # Re: ProxyCommand

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      je suis clairement d'accord avec toi, de plus je vais briser un mythe :

      Attention de vous déloguer/reloguer si vous êtes dans une session graphique pour prendre en compte ce changement de groupe. Il faudra également relancer votre terminal si vous êtes logué en ssh sur votre machine.

      et là je dis NON, la commande newgrp existe et autant s'en servir donc : newgrp fuse

      de plus si je peux faire quelque remarques :

      sudo usermod -G fuse yannig -> adduser yannig fuse

      et :

      cat .ssh/id_dsa.pub | ssh yannig@rebond "cat >> /home/yannig/.ssh/authorized_keys" -> ça peut se simplifier en utilisant ssh-copy-id sur les distribs basé sur debian.

      M.

  • # Dépêche

    Posté par  . Évalué à 10.

    Bonjour,

    Ce didacticiel est de qualité mais suis-je le seul à me demander ce qu'il fait parmi des dépêches ? N'aurait-il pas sa place parmi les astuces plutôt ?

    J'ai appris des choses sur ssh mais si on commence à mettre des tutos on ne verra plus les news.
    Une place pour chaque chose et chaque chose à sa place...

    FAb

    • [^] # Re: Dépêche

      Posté par  (site web personnel) . Évalué à 4.

      Y'a eu polémique lors de l'étape de modération. Le problème, je crois, c'est que peu de gens lisent les astuces alors qu'une dépêche à plus de visibilité. C'est ce qui a conduit à l'acceptation en tant que news.

      • [^] # Re: Dépêche

        Posté par  . Évalué à 4.

        Pourquoi ne pas faire les deux tout simplement lorsque on a une petite doc de qualité comme celle là ?
        Plus de visibilité, dispo dans les astuces et une petite dépêche sympa en plus sur le site... qui ne croule pas non plus sous les news (patapai c'est juste pour dire que la première page ne se renouvelle pas aussi vite que sur d'autres sites moins regardants sur la qualité du contenu.)

        • [^] # Re: Dépêche

          Posté par  (site web personnel) . Évalué à 10.

          Suggestion qui découle de la précédente : faire, de temps en temps (par exemple 1 ou 2 fois par mois), un article qui récapitulerait les (meilleures ?) astuces postées pendant la période.

          On resterait dans une optique "News", tout en donnant plus de visibilité aux astuces (et à davantage d'astuces, au passage).

          • [^] # Re: Dépêche

            Posté par  (site web personnel) . Évalué à 3.

            C'est toujours cool d'avoir des suggestions de rédacteurs en puissance, merci d'avance de vos dépêches à venir :-)

            • [^] # Re: Dépêche

              Posté par  . Évalué à 1.

              Mes news c'est une sorte de cycle naturel : y'en a deux par décennies comme les grosses tempêtes, on a passé le cap des 5 ans alors les probabilité d'en voir une débarquer augmentent fortement ;).

              Plus sérieusement si j'ai quelque chose d'intéressant à dire, je le dis, sinon je me tais et je n'embête pas les gentils modérateurs de linuxfr avec des trucs qui ne méritent même pas un journal ;-).

              • [^] # Re: Dépêche

                Posté par  . Évalué à 1.

                s/probabilité/probabilités.

                <déconne>
                Et l'édit sur lfr c'est pour quand ? Faut passer au waib 2.0 les gars ;)

                Je sais j'envoie un patch...
                </déconne>

    • [^] # Re: Dépêche

      Posté par  . Évalué à 3.

      perso, ce didactiel aurait à mon avis mieux eu sa place sur un site comme lea-linux.

      vu le nombre de dépèches sur linuxfr, celui ci partira vite dans les oubliettes...

      Allez y, vous pouvez me moinsser ;)

  • # introduction ?

    Posté par  (site web personnel) . Évalué à 4.

    Je crois que c'est cette partie qui fait le plus cruellement défaut. Pour que cette news puisse être comprises par la majorité des lecteurs de Linuxfr, il me semble qu'il auait fallu passer au moins 3 voir peut-être dix lignes a expliquer l'objectif de la manoeuvre pour les ignorants du réseaux et autres paresseux de la sécurité qui se contente de quelques ALL:ALL dans leurs hosts.deny en guise de configuration.

    Je ne prétend pas être un génie mais j'utilise Linux depuis environs 10 ans et pourtant je suis presque incapable de me figurer les tenants et aboutissants de ce tutotrial en lisant :
    Dans ce qui va suivre, j'essaierai de vous présenter une technique que j'utilise pour accéder à mes serveurs via des points de montage sshfs (basé sur fuse) encapsulé dans des tunnels SSH.
    En lisant les commentaires des autres jai l'impression d'être le seul ??? quelqu'un veux bien m'expliquer ?

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: introduction ?

      Posté par  . Évalué à 2.

      Oui effectivement, je trouve aussi que ca fait tres abrupt pour commencer, je me suis dit : "mais qu'est ce que ca fout la ?". Apres, pour l'histoire de la visibilité des news par rapport aux astuces, OK, mais une petite introduction n'aurait pas fait de mal ...

      BTW : au lieu d'essayer de me rappeler a chaque dans quel fichier il faut rajouter ma clé publique, j'utilise ssh-copy-id, ce qui rend les choses beaucoup plus simple :
      ssh-copy-id yannig@rebond
      Et roule ma poule.

    • [^] # Re: introduction ?

      Posté par  (site web personnel) . Évalué à 1.

      Effectivement, j'aurai peut-être dû rajouter ça. Mais comme qui dirait, ce n'est pas trop mon fort. J'ai plutôt axé le tout la partie technique ce qui est effectivement un tort.

  • # Astuces OpenSSH : le multiplexage

    Posté par  . Évalué à 7.

    Bon, ça n'a pas grand chose à voir avec le contenu de la dépêche, mais puis qu'on parle d'astuces OpenSSH...

    Depuis la version 4.2, OpenSSH est capable de réduire fortement le temps d'initialisation de la connexion (en éliminant le besoin de re-négociation des algos, ré-authentification, ...), car il permet de multiplexer les connexions vers un même hôte.

    Les cas d'utilisations qui bénéficient typiquement de cette fonctionnalité sont ceux qui requiert des re-connexions régulières à une même machine, par exemple pour accéder à un serveur Subersion, ou CVS, ou un distcc, ou ceux qui ont l'habitude de se connecter pour lancer une seule commande à la fois (« ssh user@serveur commande »)...

    Le principe est simple : on crée une connexion « maitre » initiale, celle-ci est maintenue en fond et sera réutilisée pour toutes les connexions suivantes vers le même hôte.

    En pratique :

    1) Placer ceci dans son ~/.ssh/config (ce fichier doit être en mode 0600) :

    Host *
    ControlPath ~/.ssh/mux_socket-%r@%h:%p


    2) Ensuite, on crée une socket « maître » utilisée pour le multiplexage (cela crée aussi un processus ssh qui maintient cette socket, en arrière plan) vers monhotedistant:

    ssh -fMN monhotedistant


    Et voila ! On peut maintenant profiter de nouvelles connexions très rapides. Exemple chez moi :


    # Avant la mise en place du multiplexage :
    $ time ssh monserveur exit
    real 0m0.530s

    # Avec le multiplexage :
    $ time ssh monserveur exit
    real 0m0.018s


    Autant dire que les opérations courantes (svn diff, log, up, ...) sur mon dépôt subversion sont beaucoup plus confortables.

    Une autre astuce dont il faudrait parler : les dernières versions d'OpenSSH permettent de créer des VPN (utilisant des tunnels sur des interfaces virtuelles tun(4), à la façon d'OpenVPN) de façon très simple et ne nécessitant que OpenSSH. Je suis sûr que ça aurait pu être utilisé pour arriver à des résultats similaires à ce qui est présenté dans la dépêche, mais en n'utilisant qu'OpenSSH.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.