Qui utilise votre réseau ?

Sécuriser un réseau local (LAN, Local Area Network) signifie généralement créer des règles de pare-feu, des règles pour accéder à un hôte et une configuration appropriée des serveurs de courrier, DNS (Domain Name System, système de noms de domaine) et web. Toutes ces méthodes sont principalement fondées sur l'hypothèse que la menace pesant sur votre réseau provient du grand méchant Internet. Dans cet article, je partirai d'un point de vue inverse — selon lequel ce sont les utilisateurs du réseau local qui sont (probablement) les assaillants.

Une telle hypothèse peut être justifiée dans les contextes suivants :

Bien que j'aie employé le mot « utilisateurs » ci-dessus, les véritables acteurs dans un réseau informatique sont les ordinateurs. En émettant l'hypothèse (souvent fausse !) que chaque ordinateur fait exactement ce que son utilisateur veut qu'il fasse, je limiterai la question à celle-ci :

Comment l'ordinateur Abdul, qui souhaite dialoguer avec l'ordinateur Chin, peut-il être raisonnablement sûr que l'ordinateur Betaal n'est pas à même d'intercepter la conversation et/ou de se faire passer pour Chin ?

Afin de comprendre pourquoi une solution quelque peu sophistiquée est requise, il faut réaliser qu'un réseau local n'est pas comme un réseau téléphonique et qu'une adresse IP n'est pas une marque d'identification au même titre que l'est un numéro de téléphone.

Le lecteur plus expérimenté connaîtra les adresses « physiques » — également appelées adresses Ethernet ou MAC (Medium Access Card, contrôle d'accès à la carte) qui sont intégrées au matériel, contrairement aux adresses IP. Cependant, la description du réseau évoquée dans le paragraphe ci-dessous est également appropriée si vous remplacez « adresse IP » par « adresse MAC ».

Un réseau local typique est un réseau à base de paquets. Chaque ordinateur est toujours « connecté » à tous les autres. Les conversations reposent sur des paquets qui sont envoyés « via le câble » et sont « entendus » par tous les ordinateurs présents sur le réseau. Sur chaque paquet est enregistrée l'adresse IP du destinataire, de sorte que la partie concernée peut « l'écouter » (en d'autres termes, le copier dans sa mémoire). Le paquet contient également l'adresse IP de l'expéditeur, de sorte que le destinataire sait où envoyer des réponses.

L'ordinateur Betaal (en tant qu'« esprit » dans la machine) peut rassembler des (copies des) paquets prévus pour une destination quelconque et peut également injecter des paquets avec n'importe quelle étiquette souhaitée.

Ainsi, Abdul doit signer (numériquement) chaque paquet envoyé et le chiffrer, pour que seul Chin puisse le lire. Si Abdul se contentait de signer les paquets, alors Betaal pourrait (encore) les réunir. Puisqu'il faut beaucoup de paquets pour constituer une conversation, Betaal pourrait réexpédier les paquets plus tard dans un ordre plus profitable — menaçant ainsi Chin. Si Abdul chiffrait seulement les paquets, alors Betaal pourrait injecter ses propres paquets chiffrés en jargon (données illisibles/indéchiffrables) et perturber la conversation entre Abdul et Chin.

Permettez-moi de reformuler ceci en vocabulaire technique. « Dans un réseau à base de paquets, secret et authenticité vont de pair. »

Quand Tatu Ylonen a écrit à l'origine ssh, ce dernier a été considéré comme un substitut de telnet et de rsh, qui sont des programmes/protocoles pour se connecter à distance (pour un accès distant à un shell). Cependant, comme ssh est un protocole réseau, il peut être utilisé pour créer des conversations sécurisées entre ordinateurs.

Chaque serveur ssh possède une clé privée — habituellement située dans /etc/ssh/ssh_host_rsa_key. Souvent, il y a une seconde clé privée dans /etc/ssh/ssh_host_dsa_key. Le travail de l'administrateur réseau est de rassembler les clés publiques associées à chacune de ces clés privées (au même endroit, avec une extension .pub) et de les distribuer à tous les ordinateurs du réseau.

La manière la plus simple de le faire est d'aller sur chaque ordinateur et de copier ces fichiers dans une clé USB (Universal Serial Bus, bus série universel) :

cp /etc/ssh/ssh_host_rsa_key.pub /media/usb/<adresse_ip>.rsa.pub
cp /etc/ssh/ssh_host_dsa_key.pub /media/usb/<adresse_ip>.dsa.pub

L'administrateur crée alors un fichier known_hosts :

for type in rsa dsa 
   do
       for i in /media/usb/*.$type.pub
       do
         addr=$(basename $i .$type.pub)
         (echo -n "$addr "; cut -f1-2 -d' '< $i)>> known_hosts
       done
   done

Ce fichier known_hosts est ensuite copié dans /etc/ssh/ssh_known_hosts sur chaque ordinateur. Pour conclure, on définit les paramètres de configuration :

echo "StrictHostKeyChecking yes" >> /etc/ssh/ssh_config

sur chaque ordinateur. (Les utilisateurs de chaque ordinateur peuvent également avoir à modifier le fichier de configuration $HOME/.ssh/config s'il existe.)

Après cette procédure (certes) interminable (mais non difficile), Abdul et Chin possèdent chacun les clés publiques de l'autre. Ainsi, Abdul peut chiffrer des paquets que seul Chin peut lire, et Chin peut vérifier les signatures générées par Abdul. (Le véritable protocole ssh est plus complexe et ne nous concerne pas ici.)

Ainsi, à présent, sur Abdul, on peut exécuter ssh Chin et être certain que c'est Chin qui répond. Chin demandera toujours le mot de passe à moins que tous les serveurs exécutent HostBasedAuthentication dans /etc/ssh/sshd_config. Cette procédure pourrait être risquée pour Chin, à moins que l'utilisateur root sur Abdul soit considéré comme équivalent à l'utilisateur root sur Chin.

Qu'en est-il des types d'échanges de données autres (que ssh) ? Heureusement, on a pensé à ce problème également. Si à présent Abdul veut ouvrir le port TCP (Transmission Control Protocol, protocole de contrôle de transmissions) (admettons) 80 sur Chin, alors Abdul exécute :

ssh -q -f -N -L 8080:localhost:80 Chin

Maintenant, ouvrir http://localhost:8080 depuis Abdul donne accès au serveur web de Chin.

Comment sécuriser tous les échanges de données ? Ce point a été pris en compte également. En fait, ssh fournit au moins deux méthodes :

En dépit de ces efforts, SSH n'est pas toujours adéquat pour le problème que nous nous proposons de résoudre, pour les raisons suivantes :

On peut considérer qu'OpenVPN est semblable à SSH avec une solution pour les trois problèmes notés ci-dessus.

Une machine est configurée en tant que serveur openvpn et toutes les autres —en tant que clients. Le serveur attend passivement que le client prenne l'initiative d'une connexion. Dès lors que la connexion est établie, les rôles des deux ordinateurs dans la conversation sont complètement symétriques.

Le serveur (respectivement, le client) peut être configuré à l'aide du modèle de fichier server.conf (client.conf pour le client), qui fait partie du paquetage openvpn (les modèles de fichiers de configuration devraient se trouver dans /usr/share/doc/openvpn-<version>/sample-config-files, si vous employez une version auto-installable. Autrement, ils se trouvent dans le répertoire sample-config-files dans l'archive (tarball) du source. Dans le fichier de configuration du client, on ne doit modifier qu'une ligne commençant par remote et y insérer le serveur approprié pour se connecter. Dans le fichier de configuration du serveur, on peut modifier la ligne commençant par server pour y insérer un réseau aléatoire de la forme 10.a.b.0 (vous pourriez également utiliser 172.16-32.a.0 ou 192.168.a.0) au lieu du réseau par défaut. Comme nous voulons que les clients dialoguent entre eux, nous cocherons également l'option client-to-client dans le fichier de configuration du serveur. En outre, nous modifierons ces fichiers pour y insérer des noms appropriés, comme host.key et host.crt pour les fichiers certificat et de clé (voir ci-dessous).

Une fonctionnalité intéressante d'openvpn est qu'il peut utiliser des certificats. Cela simplifie considérablement la distribution des clés — il n'est plus nécessaire de distribuer la(clés) publique(s) d'un nouvel hôte à tous les autres hôtes. Cet avantage comporte l'« inconvénient » d'installer une Autorité de Certification.

Tout d'abord, nous devons installer une Autorité de Certification (AC — en anglais, CA, Certificate Authority) sur chaque ordinateur (la machine personnelle de l'administrateur réseau, par exemple). Il y a plusieurs manières de procéder.

Une méthode simple pour installer une AC est fournie avec Openvpn. Commençons par copier le répertoire Easy RSA 2.0 dans un endroit approprié.

mkdir /root/openvpn_CA
cd /root/openvpn_CA
cp -a /usr/share/doc/openvpn/examples/easy-rsa/2.0 .

Ensuite, nous devons modifier les dernières lignes du fichier vars dans ce répertoire pour refléter notre organisation. Voici les lignes pertinentes :

export KEY_SIZE=2048
export KEY_COUNTRY=
export KEY_PROVINCE=
export KEY_CITY=
export KEY_ORG=
export KEY_OU=
export KEY_EMAIL=

Puis nous générons la clé de l'Autorité de Certification :

. ./vars
./clean-all
./pkitool --initca

Une fois que toutes les requêtes relatives à la dernière commande ont été correctement renseignées, on a un groupe de fichiers dans le sous-répertoire keys.

Après avoir installé l'Autorité de Certification, il faut signer les clés de chaque hôte. D'abord, chaque hôte génère une demande de signature :

ln -s /etc/ssh/ssh_host_rsa_key.pub /etc/openvpn/host.key
cd /etc/openvpn
openssl req -new -extensions v3_req \
      -key host.key -out host.csr

Toutes les requêtes devront être renseignées avec soin. En particulier, il est judicieux d'employer le nom de domaine entièrement qualifié pour la ligne correspondant au nom commun (NC — en anglais, CN, Common Name). Ensuite, host.csr est copié dans le répertoire keys, où l'Autorité de Certification a été installée sous un nom comme <nom_hote>.csr. Puis l'AC vérifie et signe la clé avec les commandes suivantes :

. ./vars
./pkitool --interact --sign <nom_hote>

Ensuite, les fichiers ca.crt et <nom_hote>.crt appartenant au répertoire keys de l'AC sont copiés à nouveau dans le répertoire /etc/openvpn de l'hôte d'origine ; on renomme également (ou on crée un lien symbolique) <nom_hote>.crt en host.crt.

/etc/init.d/openvpn start <config>

La solution à ces deux problèmes a été pour l'essentiel décrite par René Pfeiffer dans son premier article et son second article sur IPsec. Nous nous écarterons de ces prescriptions à deux égards :

La première garantit que le routage est « automatique ». La seconde nous permet de migrer vers un réseau IPsec sans interrompre les connexions existantes. Une fois que toutes les machines qui doivent dialoguer entre elles en sûreté sont configurées, on peut passer au mode « require » pour s'assurer que toutes les conversations sont chiffrées.

Une différence entre IPsec et openvpn est que, dans IPsec, un démon séparé gère l'échange et l'authentification des clés. Sous GNU/Linux, il s'agit de racoon. On configure le fichier /etc/racoon/racoon.conf comme suit. Tout d'abord, on insère le chemin vers les certificats. Celui-ci peut être le même que les certificats générés pour OpenVPN. Ensuite, on configure l'authentification :

        
remote anonymous {
   exchange_mode main;
   certificate_type x509 "$HOST_CERT" "$HOST_KEY";
   verify_cert on;
   my_identifier asn1dn;
   proposal {
         encryption_algorithm aes;
         hash_algorithm sha1;
         authentication_method rsasig;
         dh_group modp1024;
   }
}

Ici, il faut remplacer $HOST_CERT et $HOST_KEY par les emplacements du certificat et de la clé, respectivement. La section suivante du fichier de configuration décrit le chiffrement employé après une authentification réussie.

sainfo anonymous {
        pfs_group modp768;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}

On ordonne ensuite au noyau d'utiliser IPsec autant que possible. Pour ce faire, on veille à ce que les directives suivantes soient chargées par la commande setkey. Effacez les associations de sécurité et les politiques de sécurité.

       
flush;
spdflush;

La politique consiste à utiliser le protocole ESP (Encapsulating Security Payload, charge d'encapsulation de sécurité) et le protocole AH (Authentication Header, en-tête d'authentification) pour tous les paquets entre cet hôte et n'importe quel autre hôte du réseau, si possible. Dans les commandes ci-dessous, il faut insérer les valeurs $IP_ADDR et $NETMASK correctes :

spdadd $IP_ADDR $NETMASK any -P out ipsec
   esp/transport//use
   ah/transport//use;

spdadd $NETMASK $IP_ADDR any -P in ipsec
   esp/transport//use
   ah/transport//use;

Cela signifie que tous les hôtes utiliseront un trafic chiffré et authentifié pour chaque hôte du réseau local qui prend en charge le trafic chiffré. Ceci nous permet d'activer cette configuration sur tous les hôtes du réseau local, un hôte à la fois, sans perturber le réseau existant pendant le processus. Une fois que tous les hôtes sont configurés pour IPsec, on peut remplacer les commandes précédentes par :

spdadd $IP_ADDR $NETMASK any -P out ipsec
   esp/transport//require
   ah/transport//require;

spdadd $NETMASK $IP_ADDR any -P in ipsec
   esp/transport//require
   ah/transport//require;

Maintenant, il est relativement facile de configurer des machines pour employer le chiffrement et l'authentification dans un réseau local. De nos jours, les ordinateurs et les réseaux étant assez rapides, les calculs et les paquets réseau supplémentaires qui sont exigés ne causent pas de retard notable. En outre, il est tout a fait simple de mettre en œuvre une telle solution sans arrêter l'ensemble du réseau jusqu'à ce que toutes les machines soient reconfigurées.

Il ne vous reste plus qu'à choisir une solution appropriée pour vos besoins et à la mettre en application !

Dans le réseau de l'IMSc (Institute of Mathematical Sciences), nous avons testé et mis en œuvre la solution openvpn. Un certain nombre de mes collègues m'y ont aidé à corriger divers aspects de cette application. Je les remercie tous pour leur aide. La documentation de ssh et d'openvpn est également de très bonne qualité. Il existe nombre de bons articles sur IPsec, dont ceux de la LG cités plus haut. Je remercie les auteurs de ces documents pour leur aide.