SLIS coté administrateur du domaine:
Ce qu'il faut mettre en oeuvre

Version du 26/10/2000
  1. Installation automatisée/Mise à jour automatisée:
     
    • Les disquettes setup (-->conf-xxx, slis.conf et setup.data).
      La conception d'un serveur SLIS revient à créer une disquette setup, donc, à modifier tous les fichiers de la disquette setup originale qui le nécessitent. Si vous créez votre premier SLIS, je vous conseille vivement de jetter un oeil dans tous les fichiers, à commencer par setup.data et slis.conf qui sont les fichiers de paramètres principaux.
      Vous devez partir de la disquette setup originale à jour se trouvant dans ftp://old.slis.fr/disk_setup/.
      Si vous avez plus d'une dizaine de SLIS à installer, il est conseillé de faire des scripts qui vont modifier automatiquement les fichiers de configuration pour créer les nouvelles disquettes setup à partir d'une base de donnée par exemple. On peut intégrer dans ces scripts des routines qui vont permettre de faciliter également le travail à faire sur les serveurs centraux dont il est question ci-dessous (DNS, sendmail, radius).
       
    • Scripts et fichiers de mise à jour (serveur rsync hébergeant les "updates SLIS").
      Lorsque vous prévoyez de déployer un réseau de serveur SLIS, il faut mettre en place un serveur central qui contiendra les mises à jour. Les SLIS iront chercher régulièrement des scripts de mise à jour depuis ce serveur. A l'origine, ce serveur était un serveur tftp. Depuis la version 2.0 et pour les autres versions depuis la mise à jour numéro 135, le protocole tftp a été abandonné au profit du protocol rsync. Celui-ci a l'avantage de fonctionner en TCP (contre UDP pour tftp) ce qui pose moins de problèmes sur des liens de mauvaise qualité. Mais surtout, rsync permet de ne télécharger que les parties modifiées d'un fichier, d'où un gain important sur le téléchargement des fichiers réguliers tels que les bases d'URLs interdites.
      La mise en place de rsync est très simple. Vous pouvez le télécharger à http://rsync.samba.org. Vous devez l'installer en tant que serveur:

       - Ajoutez la ligne suivante à votre inetd.conf
      rsync   stream  tcp     nowait   root    /usr/local/bin/rsync rsyncd --daemon
      - Voici un exemple du fichier /etc/rsyncd.conf.

      Le principe des MAJ SLIS:
      Vous trouverez dans ftp://old.slis.fr/updates_rsync les mises à jour actuelles. Elles consistent en au moins 3 scripts et des fichiers que les SLIS vont télécharger. Les scripts sont les suivants, dans l'ordre où les SLIS les téléchargent et les éxécutent:
      - slis_update.common: Ce script est le premier chargé. Il est sensé être commun à tous les SLIS de toutes les académies et de toutes les versions.
      - slis_update.<numero de version>: Ce script dépend de la version du SLIS. Il est commun à toutes les académies.
      - slis_update.academie: Ce script est vide par défaut sur le serveur ftp officiel SLIS. Il est à la disposition de l'académie ou de l'implémentation.
      Régulièrement, nous publions sur la liste de diffusion des développements, un récapitulatif des dernières mises à jour. Une mise à jour consiste en une partie d'un des 3 scripts dont il est question ci-dessus. Un numéro est affecté à chaque mise à jour. Pour en savoir plus, regardez le contenu d'un script de MAJ.

  2. Plan d'adressage - Comptes d'accès:
     
    • Adresses coté Intranet des SLIS
      Il est conseillé d'utiliser les mêmes adresses (RFC 1918 bien sûr) pour tous les établissements d'un même domaine équipés en SLIS, c'est un des avantages de l'architecture. Le support en est simplifié par la suite. Ca évite aussi d'avoir à gérer un plan d'adressage à grande echelle. N'oublions pas la philosophie de SLIS: on considère l'Intranet au niveau de l'établissement scolaire.
      Exemple de ce que nous avons choisi pour Grenoble.
       
       
    • Adresses coté Internet des SLIS
      Il faut prévoir quelques adresses IP officielles fixes pour mettre en place SLIS: au moins une par site, sinon 8 par sites dans le cas idéal (celui auquel nous avions pensé au démarrage du projet, toujours dans cette philosophie d'Intranet limité au réseau de l'établissement).
      - Premier cas: Vous avez par exemple une classe C d'adresses officielles que vous voulez partager sur 32 sites. Vous faites 32 sous-réseaux de masque /29 et le tour est joué. Voici un exemple.
      - Deuxième cas: Vous réalisez un réseau d'interconnexion en RFC 1918 et vous faites du NAT sur le routeur du point d'accès pour translater au moins l'adresse IP du SLIS vers une adresse officielle. Vous pouvez ensuite, au coup par coup, selon les besoins et sur demande des établissements, rajouter des adresses IP officielles. Exemple.

      A CONSULTER: Les schémas des stratégies d'adressage.

       Dans l'académie de Grenoble, nous avons en fait les 2 cas. Nous avons affecté d'office 8 adresses IP officielles selon le premier cas à certains établissements qui ont des projets importants par rapport à Internet (serveur web du CRDP, collèges faisant de la visio-conférence, etc...). Mais la plupart des établissements sont dans le 2ème cas.
       

    • VPN, alternative à l'adresse IP fixe?
      L'option VTUN

    • Routeur d'accès:
      • Authentification Radius
        Une fois votre plan d'adressage pensé, vous pouvez créer les comptes Radius (ou Tacacs, ou autre...) qui se traduisent souvent par: un login, un mot de passe et une route. Exemple de compte radius.
        Lorsque vous connectez un établissement par liaison Transfix ou autre LS, vous n'aurez bien sûr que la route à créer. Enfin, vous n'aurez rien à faire si vous installez un SLIS chez un fournisseur privé puisque c'est à lui de vous fournir les adresses IP.
      • Table NAT
        Dans le cas où vous affectez moins de 8 ip officielles par établissement, vous devrez faire du NAT au niveau du routeur du point d'accès. Voici l'exemple associé à l'exemple de compte radius ci-dessus, pour un Cisco AS5200 avec IOS 11.2.
         
  3. Proxy-cache parent


    Dans le fichier de configuration de SLIS, vous devez spécifier un proxy-cache parent qui doit etre situé sur le point d'accès. Si vous n'avez pas encore mis en oeuvre de proxy-cache, c'est peut-etre le moment. Je vous conseille Squid.
    Si vous n'avez pas de parent à spécifier, il faudra alors modifier en fonction le fichier squid.conf de la disquette setup de vos SLIS avant installation.
     

  4. DNS et Messagerie
     
    • DNS: les MX
      Pour chaque SLIS installé, il faut déclarer son adresse IP officielle dans votre DNS (dans le cas du NAT, il faut déclarer l'adresse officielle translatée). Ne pas oublier les déclarations en zone inverse. Ce dernier détail peut etre délicat si vous installez des SLIS chez un fournisseur d'accès externe car il devra déclarer les adresses inverses sur son serveur, mais dans votre domaine.
      Pour chaque déclaration, ajoutez un MX vers le serveur de messagerie que vous avez aussi spécifié dans les fichiers de configuration des SLIS (setup.data et slis.conf, variable SMART_HOST). Ainsi, les messages à destination des SLIS arriveront d'abord sur votre serveur central. Voici un exemple de déclaration DNS d'un SLIS dans ac-grenoble.fr.
       
    • mailertable,sendmail.cw (voir use_cw_file dans README cf sendmail)
      Votre serveur de messagerie doit etre configuré de manière à ce qu'il vous permette de spécifier des machines pour lesquelles il va recevoir le courrier et une table de routage. Pour sendmail, cela est relativement simple grace aux kits de configurations qui existent. Pour le kit de configuration fourni avec sendmail, il suffit d'utiliser les directives:

             FEATURE(`use_cw_file')
             FEATURE(`mailertable', `dbm /usr/lib/mailertable')

      Le fichier /etc/sendmail.cw va contenir tout simplement les noms des SLIS que vous aurez déclaré en DNS. Le fichier /etc/mailertable spécifiera, pour chaque SLIS, qu'on ne doit pas interroger le serveur DNS mais directement dialoguer avec nos propres machines (sinon, on aurait un bouclage à cause des MX.)
      Ne pas oublier de faire un "makedbm" après avoir modifié les fichiers textes.
       

    • queuewarn et queuereturn
      L'inconvénient dans l'utilisation de SMTP dans le cas de SLIS et de réseaux commutés, c'est que les "timeouts" sont les mêmes pour tout le monde. Il vaut mieux tout de même augmenter ceux-ci afin qu'ils correspondent à la durée maximale pendant laquelle un serveur SLIS risque de ne pas être joignable. Cette durée est de 24h puisque les SLIS forcent une connexion à votre serveur de messagerie au moins une fois par nuit pour vérifier s'ils ont du courrier.
      Dans le cas de sendmail, il faut changer les valeurs par défaut de queuewarn et de queuereturn. Mettez par exemple 24h et 5jours.
       
    • Déplacement des fichiers queues pendant les vacances d'été. (Voir O'Reilly sur sendmail)
      Je prévoi la réalisation d'un script à lancer par le cron du serveur de messagerie pendant les vacances d'été car les SLIS risquent d'être éteinds. Ce script déplacerai les queues à destination des SLIS et on les remettrait en place à la rentrée. A suivre...
       
    • Une alternative
      L'option FETCHMAIL
       
  5. Les filtres
     
      Il y a, à mon avis, un minimum de filtres à mettre en oeuvre sur le serveur d'accès:
    • Bloquer ICMP (plus précisément "ping") sur le routeur d'accès et le SLIS.
      Cela évitera une manière simple de maintenir la ligne ouverte en permanence...
    • port 25
      On peut empécher l'utilisation du port 25 des SLIS par d'autres machines que le SMART_HOST spécifié. Ca peut éviter des problèmes... Sur ac-grenoble, j'ai aussi limité l'utilisation du port 25 vis à vis de nos propres utilisateurs. Il ne faut pas oublier les SPAMs ou tentatives de piratage en provenance de chez nous.
    • telnet sur les routeurs des établissements
      Certains routeurs sont vulnérables sur leur port telnet. Il vaut mieux empécher les autres d'y accéder...
    • Autres.
      Il serait aussi prudent de protéger d'autres ports, vis à vis de l'extérieur, tels que 3128 (squid) par exemple, vu que ca serait inutile pour quelqu'un de l'extérieur. Bref, il faut protéger les SLIS comme n'importe lequel de vos serveurs.
    • Gros filtrage.
      Vous pouvez aussi choisir la rêgle "ce qui n'est pas autorisé est interdit". Ainsi, vous pouvez laisser passer le minimum autorisé vers les SLIS. Exemple d'ACL cisco:
      ! On autorise l'accès au web des SLIS
      access-list 125 permit tcp any 195.221.234.0 0.0.0.255 eq 80
      ! Attention au retour des paquets sur les ports source
      access-list 125 permit tcp any 195.221.234.0 0.0.0.255 gt 1023

      access-list 125 permit udp any eq 53 195.221.234.0 0.0.0.255 gt 1023
      ! Certains messages ICMP sont necessaires au bon fonctionnement d'IP
      access-list 125 permit icmp any any unreachable
      ! On autorise ident. Ceci evite au moins des logs penibles

      access-list 125 permit tcp any 195.221.234.0 0.0.0.255 eq ident
      ! Le reste est interdit
      access-list 125 deny   ip any 195.221.234.0 0.0.0.255 log
       
       
  6. Serveur web
     
    • Mirroring/réplication des sites
      C'est une fonction de SLIS qui n'est pas encore développée... à suivre
       
  7. Fournisseur d'accès externe
     
    • Fournisseur: adresses ip, login, passwd, numéro d'accès, proxy-cache, serveur dns
      En cours de rédaction...
    • Différences au niveau du SLIS: conf routeur, proxy-cache parent, conf DNS
      En cours de rédaction...
    • DNS : adresses inverses
      En cours de rédaction...

Bruno Bzeznik
Bruno@ac-grenoble.fr
Carmi-Internet