Page suivante - Page précédente - Table des matières

3. Le serveur

Cette section explique comment mettre en place l'aspect serveur des choses. J'ai placé cette section en premier, étant donné que sans serveur, un client est assez inutile.

3.1 La sécurité - garder les gens dehors

La sécurité est un aspect très important des VPNs. C'est pour ça que vous êtes en train d'en monter un, non? Vous devez garder ces quelques choses à l'esprit en mettant en place votre serveur.

Préparez vos démons

Etant donné que ce serveur va être des deux côtés du firewall et qu'il va être mis en place pour transmettre le trafic sur votre réseau, c'est une bonne idée de sécuriser la machine autant que possible. Vous pourrez en apprendre plus sur la sécurité Linux dans Linux Security HOWTO. Pour ma part, j'ai tué tous les services, excepté sshd et un serveur web Roxen. J'utilise ce dernier pour télécharger quelques fichiers (mes scripts, etc.) pour permettre à d'autres machines d'accéder au VPN. Je n'utilise pas de serveur FTP étant donné qu'il est plus dur d'en sécuriser un que de rendre quelques fichiers disponibles sur un serveur web. De plus, j'ai seulement besoin de pouvoir récupérer des fichiers. Si vous souhaitez réellement exécuter des serveurs différents sur votre passerelle, vous pourriez vouloir envisager de restreindre leur accès aux machines situées sur votre réseau privé.

Ne pas autoriser de mots de passe

Effectivement, cela semble assez stupide, mais ça a retenu votre attention non? Non, vous n'utilisez pas de mots de passe, vous les désactivez complètement. Toute l'authentification nécessaire sur cette machine devrait être faite via le système d'authentification à clé publique de ssh. Ainsi, seul les entités dotées de clés peuvent entrer, et il est pratiquement impossible de se rappeler d'une clé binaire de 530 caractères.

Alors, comment faites-vous ça? Il faut éditer le fichier /etc/passwd. Le second champ contient soit le résumé cryptographique (hash) du mot de passe, ou un 'x' prévenant le système d'authentification qu'il faut regarder dans le fichier /etc/shadow. Vous devez changer ce champ en '*'. Ainsi le système d'authentification est informé qu'il n'y a pas de mot de passe, et qu'aucun ne devrait être autorisé.

Voila à quoi ressemble un fichier /etc/passwd classique: 

...
nobody:x:65534:100:nobody:/dev/null:
mwilson:x:1000:100:Matthew Wilson,,,:/home/mwilson:/bin/bash
joe:*:504:101:Joe Mode (home),,,:/home/vpn-users:/usr/sbin/pppd
bill:*:504:101:Bill Smith (home),,,:/home/vpn-users:/usr/sbin/pppd
frank:*:504:101:Frank Jones (home),,,:/home/vpn-users:/usr/sbin/pppd
...
Remarquez que j'ai fait plus qu'éditer simplement le second champ. J'en dirais plus sur les autres champs par la suite.

3.2 Accès des utilisateur - les laisser rentrer

L'accès des utilisateurs est réalisé via le schéma d'authentification de ssh. Comme je l'ai indiqué précédemment, c'est ainsi que les utilisateurs peuvent accéder au système, tout en maintenant un haut niveau de sécurité. Si vous n'êtes pas familier de ssh, jetez un oeuil à http://www.ssh.org/ Remarquez que j'utilise la version 1 de ssh, pas la version 2. Il y a une grande différence, particulièrement sur le fait que la version 1 est libre, contrairement à la version 2.

Configurer sshd

Vous aurez besoin de configurer sshd. Les options suivantes devraient être présentes. L'idée est de désactiver l'authentification par mot de passe, et les authentifications par rhosts. Les options suivantes devraient être présentes dans votre fichier /etc/sshd_config. 

PermitRootLogin yes
IgnoreRhosts yes
StrictModes yes
QuietMode no
CheckMail no
IdleTimeout 3d
X11Forwarding no
PrintMotd no
KeepAlive yes
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
UseLogin no

3.3 Restreindre les possibilités des utilisateurs

Maintenant que vous maintenez les méchants à l'extérieur et ne laissez entrer que les gentils, vous pourriez avoir besoin de vous assurer que ces derniers se comportent correctement. La manière la plus simple de le faire est de ne rien les laisser faire d'autre que de lancer pppd. Ceci peut être, ou non, nécessaire. J'ai restreins les possibilités des utilisateurs parce que le système que je maintiens est dédié au VPN, et que les utilisateurs n'ont aucune raison de faire quoique ce soir d'autre dessus.

sudo ou pas sudo

Il existe un petit programme propret appelé sudo qui permet à l'administrateur d'un système Unix d'autoriser à certains utilisateurs la possibilité de lancer certains programmes en tant que root. C'est ici certainement le cas, étant donné que pppd doit être lancé ainsi. Vous devrez utiliser cette méthode si vous souhaitez autoriser les accès ligne de commande aux utilisateurs. Référez-vous à la page man de sudo pour savoir comment mettre sudo en place. Utiliser sudo est préférable sur les systèmes multi-usage qui hébergent généralement un faible nombre d'utilisateurs de confiance.

Si vous désirez ne pas autoriser les utilisateurs à disposer d'un accès par ligne de commande, le meilleur moyen de le faire est de faire que leur shell soit pppd. Ceci se fait dans le fichier /etc/passwd. Vous pouvez voir ci-dessous que c'est ce que j'ai fait pour les trois derniers utilisateurs. Le dernier champ du fichier /etc/passwd est le shell de l'utilisateur. Vous n'avez pas besoin de faire quoique ce soit de spécial à pppd pour le faire fonctionner. Il est exécuté en tant que root lorsque l'utilisateur se connecte. C'est certainement la mise en place la plus simple possible, ainsi que la plus sûre. Elle est idéale pour les systèmes industriels et à grande échelle. J'ai décris exactement tout ce qu'il faut faire plus loin dans ce document. Vous pouvez y aller directement si vous le souhaitez.

3.4 Le réseau

Maintenant que vos utilisateurs ont accès au système, nous devons nous assurer qu'ils ont accès au réseau. Pour ce faire, nous utilisons les règles du noyau Linux relatives au firewall et les tables de routage. En nous servant des commandes route et ipfwadm, nous pouvons configurer le noyau pour gérer le trafic réseau de manière correcte. Pour plus d'information sur ipfwadm, ipchains et route, référez vous au Linux Networking HOWTO.

Le noyau

Pour que cela fonctionne, votre noyau doit être configuré correctement. Si vous ne savez pas comment créer votre propre noyau, vous devriez lire le Kernel HOWTO. Vous devez vous assurer que les options suivantes sont activées, en plus des options réseaux de base. J'utilise un noyau 2.0.38 sur mon système.

Pour les noyaux 2.0:

  • CONFIG_FIREWALL
  • CONFIG_IP_FORWARD
  • CONFIG_IP_FIREWALL
  • CONFIG_IP_ROUTER
  • CONFIG_IP_MASQUERADE (optionnel)
  • CONFIG_IP_MASQUERADE_ICMP (optionnel)
  • CONFIG_PPP

Pour les noyaux 2.2:

  • CONFIG_FIREWALL
  • CONFIG_IP_ADVANCED_ROUTER
  • CONFIG_IP_FIREWALL
  • CONFIG_IP_ROUTER
  • CONFIG_IP_MASQUERADE (optionnel)
  • CONFIG_IP_MASQUERADE_ICMP (optionnel)
  • CONFIG_PPP

Rêgles de filtrage

Tout d'abord, nous devons écrire des règles de filtrage de firewall qui permettent aux utilisateurs d'accéder à nos réseaux internes, tout en leur interdisant d'accéder au réseau externe. Cela peut sembler étrange, mais envisagez le sous cet angle: Ils ont déjà accès à l'Internet, alors pourquoi les laisser utiliser le tunnel pour y accéder? Cela gâche à la fois la bande passante et le processeur.

Les règles de filtrage utilisées dépendent du réseau interne utilisé. En gros, elle disent: "Autoriser le trafic venant de nos VPNs et destiné à nos réseaux internes". Comment allons nous faire? Comme toujours, ça dépends. Si vous utilisez un noyau 2.0, vous devez vous servir d'un outil appelé ipfwadm, alors que si vous utilisez un noyau 2.0, vous utiliserez ipchains.

Pour mettre en place les règles avec ipfwadm, lancez le avec les options suivantes:

# /sbin/ipchains -F forward
# /sbin/ipchains -P forward DENY
# /sbin/ipchains -A forward -j ACCEPT -s 192.168.13.0/24 -d 172.16.0.0/12

Pour les utilisateurs de noyau 2.2, se référer à ceci.

Routage

Désormais, nos utilisateurs sont autorisés à accéder à nos réseaux, et nous devons dire au noyau où envoyer les paquets. Sur mon système, je dispose de deux ethernets : L'un d'entre eux est relié au réseau externe, l'autre au réseau interne. Ceci aide à la sécurisation, car le trafic extérieur est masqué par notre passerelle, et n'importe quel trafic entrant est filtré et routé par notre Cisco. Pour la plupart des dispositifs, le routage devrait être une chose simple.

Nous routons l'intégralité du trafic destiné au réseaux privés vers l'interface connectée au réseau interne, et le reste du trafic vers l'interface externe. Les commandes de routage spécifiques dépendent des réseaux internes que vous utilisez. Voici un exemple de ce à quoi elles pourraient ressembler. Ces lignes sont bien sûr ajoutées à vos règles de routages habituelles pour vos réseaux locaux. Je doute que vous utilisiez les trois groupes d'adresses privées.

En supposant que 172.16.254.254 est notre passerelle interne:
# /sbin/route add -net 10.0.0.0 netmask 255.0.0.0 gw 172.16.254.254 dev eth1
# /sbin/route add -net 172.16.0.0 netmask 255.240.0.0 gw 172.16.254.254 dev eth1
# /sbin/route add -net 192.168.0.0 netmask 255.255.0.0 gw 172.16.254.254 dev eth1

Encore une chose sur le routage. Si vous utilisez du routage bidirectionnel, vous aurez alors besoin de réaliser une chose en plus. Il vous faudra mettre en place les routes revenant vers le client. La manière la plus simple de le faire est de lancer un cron chaque minute qui va assigner les valeurs des routes. Ce n'est pas très grave si le client n'est pas connecté, route va simplement cracher une erreur (que vous aurez judicieusement redirigé vers /dev/null).

Page suivante - Page précédente - Table des matières