Le serveur mandataire SOCKS est disponible sur : http://www.socks.nec.com/.
Décompressez et "dé-tarez" les fichiers dans un répertoire de votre système, et suivez les instructions pour le confectionner. J'ai eu quelques problèmes pour le réaliser. Vérifiez que vos Makefiles soient corrects.
Une chose importante est que le serveur mandataire doit être ajouté dans /etc/inetd.conf. Vous devez ajouter une ligne :
socks stream tcp nowait nobody /usr/local/etc/sockd sockd
pour indiquer au serveur de s'exécuter sur demande.
Le programme de connexion nécessite deux fichiers de configuration distincts : l'un pour indiquer les accès autorisés, l'autre pour rediriger les requêtes vers le serveur mandataire approprié. Le fichier d'autorisations d'accès doit se trouver sur le serveur. Le fichier de routage peut être placé sur n'importe quelle machine Unix. Les ordinateurs DOS et, je pense, les Macintosh font leur propre routage.
Avec socks4.2 bêta, le fichier d'accès s'appelle "sockd.conf". Il doit contenir deux lignes : une ligne d'autorisations et une ligne d'interdictions. Chaque ligne présente trois champs :
L'identificateur est soit permit, soit deny. Vous devez avoir aussi bien une ligne permit qu'une ligne deny.
L'adresse IP contient une adresse à quatre octets en notation classique IP, soit, par exemple, 192.168.2.0.
Le masque de modification d'adresse est aussi une adresse à quatre octets en notation classique IP, et fonctionne comme un masque réseau. Représentez-vous ce nombre sur 32 bits. Si un bit est à 1, le bit correspondant de l'adresse qu'il contrôle doit concorder avec le bit correspondant du champ de l'adresse IP.
Par exemple, une ligne :
permit 192.168.2.23 255.255.255.255
autorisera seulement l'adresse dont chaque bit correspond à 192.168.2.23, donc seulement 192.168.2.23.
Tandis que la ligne :
permit 192.168.2.0 255.255.255.0
autorisera toute adresse du groupe 192.168.2.0 à 192.168.2.255, soit tout le domaine de la classe C.
Il ne faut pas spécifier la ligne :
permit 192.168.2.0 0.0.0.0
qui autoriserait toute adresse, sans distinction.
Aisni, autorisez toute adresse que vous souhaitez, puis interdisez le reste. Pour autoriser quiconque dans le domaine 192.168.2.xxx, les lignes :
permit 192.168.2.0 255.255.255.0 deny 0.0.0.0 0.0.0.0
fonctionneront très bien. Notez le premier "0.0.0.0" dans la ligne "deny". Avec un modificateur de 0.0.0.0, le champ adresse IP n'a aucune importance. Tous les champs à 0 représentent la norme, car c'est facile à écrire.
On peut utiliser plusieurs lignes de chaque type.
Des utilisateurs spécifiques peuvent aussi se voir accorder ou refuser l'accès. Cela est réalisé par l'authentification d'identité. Tous les systèmes ne supportent pas le système ident, y compris Trumpet Winsock, donc nous n'irons pas plus loin en ce qui concerne cela. La documentation de socks est tout à fait adéquate sur ce sujet.
Le fichier de routage de socks est bêtement nommé "socks.conf". Je dis "bêtement", car il est si proche du nom du fichier d'accès qu'il est aisé de les confondre.
Le fichier de routage sert à indiquer aux clients de socks quand il est nécessaire de l'utiliser et quand ce n'est pas le cas. Par exemple, dans notre réseau, 192.168.2.3 ne nécessite pas l'usage de socks pour communiquer avec le pare-feu 192.168.2.1. Il a une connection directe Ethernet. Il définit 127.0.0.1, le port de bouclage, automatiquement. Evidemment, il n'est pas nécessaire d'utiliser socks pour vous parler à vous-même.
Il y a trois entrées :
L'entrée "deny" indique à socks quand rejeter une requête. Cette entrée a les trois mêmes champs que ceux de sockd.conf : identificateur, adresse et modificateur. Généralement, puisqu'il est aussi manipulé par sockd.file, le fichier d'accès, le champ modificateur est positionné à 0.0.0.0. Si vous voulez vous interdire tout appel vers l'extérieur, vous pouvez le réaliser ici.
L'entrée "direct" indique pour quelles adresses ne pas utiliser socks. Il s'agit des adresses pouvant être atteintes sans le serveur mandataire. A nouveau, nous avons les trois champs identificateur, adresse et modificateur.
Dans notre exemple, nous aurions :
direct 192.168.2.0 255.255.255.0
donnant ainsi l'accès direct pour toute machine de notre réseau protégé.
L'entrée "sockd" indique à l'ordinateur l'emplacement du démon serveur de socks.
La syntaxe est la suivante :
sockd @=<liste de serveurs> <adresse IP> <modificateur>
Notez l'entrée @=. Elle vous permet de configurer les adresses IP de plusieurs serveurs mandataires. Dans notre exemple, nous utilisons un seul serveur mandataire, mais vous pouvez en avoir plusieurs pour permettre un plus grand trafic et pour assurer une tolérance aux pannes.
Les champs adresse IP et modificateur fonctionnent exactement comme dans les autres exemples. Vous spécifiez ainsi où va quelle adresse.
Configurer un service de noms de domaines depuis l'arrière d'un pare-feu est une tâche relativement simple. En gros, il vous faut configurer le DNS sur la machine pare-feu. Ensuite, indiquez à chaque machine derière le pare-feu d'utiliser celui-ci.
Pour faire fonctionner vos applications avec un serveur mandataire, celles-ci doivent être "SOCK-ifiées". Il vous faudra deux telnet différents : un pour la communication directe, et un autre pour celle avec le serveur mandataire. Le paquetage socks contient des indications pour SOCK-ifier un programme, ainsi qu'un certain nombre de programmes pré-SOCK-ifiés. Si vous utilisez la version SOCK-ifiée pour aller à un emplacement direct, socks basculera automatiquement sur la version directe pour vous. Pour cette raison, il nous faut renommer tous les programmes sur notre réseau protégé et les remplacer par leur version SOCK-ifiée. "finger" devient "finger.orig", "telnet" devient "telnet.orig", etc. Vous devez indiquer chacun d'eux à socks à l'aide du fichier include/socks.
Certains programmes traitent le routage et la SOCK-ification eux-mêmes. Netscape est l'un d'entre eux. Vous pouvez utiliser un serveur mandataire sous Netscape en donnant l'adresse du serveur (192.168.2.1 dans le cas qui nous intéresse) dans le champ SOCKs sous Proxies. Chaque application nécessite au moins un petit coup d'oeil, quelle que soit son attitude vis-à-vis d'un serveur mandataire.
Trumpet Winsock contient des fonctionnalités de serveur mandataire incluses. Dans le menu "setup", donnez l'adresse IP du serveur, ainsi que celles de tous les ordinateurs directement accessibles. Trumpet se débrouillera alors avec tous les paquets sortants. NdT : Trumpet Winsock est une couche IP destinée à MS-Windows 3. Depuis la version 3.11 de Windows, Microsoft fournit une couche IP dont les fonctionnalités sont très différentes.
Le paquetage SOCKS fonctionne seulement avec les paquets TCP, pas avec les UDP. Cela le rend quelque peu moins utile. De nombreux programmes très utiles, comme talk et Archie, utilisent UDP. Il existe un paquetage prévu pour être utilisé comme serveur mandataire pour les paquets UDP appelé UDPrelay, de Tom Fitzgerald fitz@wang.com. Malheureusement, à l'heure où ces lignes sont écrites, il n'est pas compatible avec Linux.
Le serveur mandataire est, avant tout, un système de sécurité.
Son utilisation pour augmenter le nombre d'accès Internet avec un nombre
limité d'adresses aura de nombreux inconvénients.
Un serveur mandataire autorisera un plus grand accès de l'intérieur du réseau
protégé vers l'extérieur, mais laissera l'intérieur totalement inaccessible
de l'extérieur.
Ce qui implique aucun serveur, aucune connexion talk ni Archie, ni courriel
direct vers les ordinateurs de l'intérieur.
Ces inconvénients peuvent sembler légers, mais regardez-les sous l'angle
suivant :
FTP cause un autre problème avec les serveurs mandataire : Lorsque FTP récupère une liste de fichiers, le serveur ouvre une socket sur la machine client pour lui envoyer les informations. Un serveur mandataire ne permettra pas cela, donc FTP en particulier ne fonctionne pas.
De plus, les serveurs mandataires sont lents. A cause de la dégradation du rapport information/protocole, n'importe quel autre moyen d'obtenir cet accès sera plus rapide.
En résumé, si vous avez les adresses IP nécessaires, et que la sécurité ne soit pas un impératif pour vous, n'utilisez ni un pare-feu ni un serveur mandataire. Si vous n'avez pas suffisamment d'adresses IP, mais que, de même, la sécurité n'est pas fondamentale, vous pouvez jeter un coup d'oeil aux émulateurs IP, comme Term, Slirp ou TIA. Term est disponible sur ftp://sunsite.unc.edu, Slirp est disponible sur ftp://blitzen.canberra.edu.au/pub/slirp et TIA est disponible sur marketplace.com. Ces paquetages iront plus vite, permettront de meilleures connexions, et fourniront un accès supérieur à l'intérieur du réseau depuis InterNet. Les serveurs mandataires sont utiles pour ce genre de réseaux qui comportent de nombreuses machines qui se connectent au vol à InterNet, avec une configuration et peu de travail ensuite.