Passerelle Internet Linux

Un article de WikisAdmins.




Sommaire

Introduction

Ce tutoriel a pour objectif d'expliquer comment monter une passerelle Internet rapidement avec Linux pour un LAN de petite taille (une vingtaine de stations de travail maximum). Toutefois, il donne les liens vers des outils et d'autres tutoriels plus détaillés permettant la mise en place de passerelles pour des réseaux de plus grande ampleur.

Bien que nous travaillerons ici avec Debian, cette installation de passerelle Internet peut s'appliquer sur n'importe quelle distribution GNU/Linux. Si besoins, les différences seront signalées.

La mise en place d'une passerelle __ surtout d'une passerelle Internet __ ne consiste pas uniquement à relier deux réseaux différents ; elle joue aussi un rôle de sécurisation et de tampon entre ces deux réseaux.

A la translation d'adresse (NAT), nous allons donc ajouter :

C'est tout d'abord l'outil Netfilter qui vas permettre à la fois la communication du réseaux privé avec l'internet et sa protection vis à vis de ce dernier.Un autre tutoriel traite de l'utilisation de Netfilter de façon plus détaillé.

Ensuite, Dnsmasq vas distribuer les adresses IP ainsi que d'autres informations et permettre la résolution des noms de domaines demandé par les clients. Dnsmasq évite ainsi les requêtes aux serveur de noms du FAI redondantes et accélère sensiblement le temps d'accès aux pages Web. Au delà d'une vingtaine de stations environ, Dnsmasq ne sera plus suffisant et il faudra alors utiliser le couple Bind + dhcpd.

Afin d'économiser la bande passante, nous allons profiter de notre passerelle pour y installer un cache ou tampon... Un logiciel qui vas servir de mandataire. Ainsi les clients ne font pas de requête Web directe auprès de l'internet mais passe par l'intermédiaire de Squid.

Enfin, un service d'authentification NCSA s'ajoutera à Squid pour ne pas laisser n'importe qui utiliser notre service mandataire et dans le but d'avoir un suivi de l'usage du Web.

Netfilter : Translation d'adresse réseau et protection du réseau privé

Article détaillé : Netfilter

Installation Iptables

Le firewall Netfilter est intégré au noyau Linux depuis la version 2.4.

Iptables est l'interface en ligne de commande permettant de donner des règles à Netfilter. Cet outil est généralement installé par défaut sur les distributions GNU/Linux mais si ce n'est pas le cas, vous pouvez utiliser votre gestionnaire de paquet habituel. Par exemple, pour Debian :

       aptitude install iptables

Configuration d'un script de firewall

Pour effectuer nos tests, nous pourrions directement modifier les tables de Netfilter à partir de la commande iptables en l'utilisant dans un shell. Mais, pour des soucis d'élégance et de praticité, nous créerons un script qui se lancera automatiquement à chaque démarrage de la machine-passerelle.

Tous d'abord, nous allons donc créer le fichier exécutable qui vas nous permettre d'expérimenter notre script. Lorsque nous serons enfin satisfait de celui-ci, nous pourrons l'intégrer au répertoire /etc/init.d/ qui gère les services lancés dès le démarrage du système.

Dans notre répertoire personnel et avec notre éditeur de texte préféré (Vim en ce qui me concerne ;-) ), nous créons un fichier exécutable :

       # touch firewall.sh
       # chmod +x firewall.sh
       # vim firewall.sh

Dans un premier temps, nous allons y mettre les règles minimales permettant un bon fonctionnement de filtrage et de translation de la passerelle.

Dans un second temps, nous y ajouterons les lignes de commandes permettant de personnaliser votre firewall en fonction des besoins de votre réseau.

Enfin, dans un troisième temps, nous verrons comment supprimer une règle plutôt que de relancer le script à chaque fois si cela vous paraît plus pratique.

Explication des règles minimales

Je vous invite à consulter le manuel d'Iptables pour comprendre les options proposées :

       man iptables

Comme pour configurer de nombreux firewalls, nous allons tout d'abord bloquer la communication avant d'ouvrir uniquement ce qui nous ai nécessaire :

  • On vide les anciennes règles et on verrouille toutes les interfaces :
       /sbin/iptables -F
       /sbin/iptables -X
       /sbin/iptables -Z
       /sbin/iptables -P INPUT DROP
       /sbin/iptables -P OUTPUT DROP
       /sbin/iptables -P FORWARD DROP
  • Nous autorisons les communications sur l'interface de la boucle locale (lo : 127.0.0.1) de la passerelle que certaines applications utilisent :
       /sbin/iptables -A INPUT -i lo -j ACCEPT
       /sbin/iptables -A OUTPUT -o lo -j ACCEPT
  • Dans une approche dite de confiance, si nous pouvons considérer que le danger ne peux venir du réseaux privé, nous autorisons toutes les communications sur l'interface du réseau privé (eth0) :
       /sbin/iptables -A INPUT -i eth0 -j ACCEPT
       /sbin/iptables -A OUTPUT -o eth0 -j ACCEPT
  • Nous autorisons la sortie vers l'internet par l'interface publique (eth1 si la connexion vous est fournie par un routeur ou ppp0 si c'est directement par le 'boitier' ADSL). Les paquets peuvent alors sortir mais ne peuvent toujours pas entrer.
       /sbin/iptables -A OUTPUT -o ppp0 -j ACCEPT
  • Nous acceptons le flux entrant sur l'interface publique uniquement si la communication a été initialisée (ESTABLISHED) par le réseau privé ou relative (RELATED : comme dans le cas du connexion FTP) à celui-ci :
       /sbin/iptables -A INPUT -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT
  • On autorise enfin la translation d'adresse réseau :
       /bin/echo "1" > /proc/sys/net/ipv4/ip_forward
       /sbin/iptables -A FORWARD -i eth0 -j ACCEPT
       /sbin/iptables -A FORWARD -o eth0 -j ACCEPT
  • Puis le masquage d'adresses car les adresses privées ne peuvent circuler sur le réseaux public et doivent donc prendre l'adresse publique de la passerelle :
       /sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

A partir de maintenant, le script est prêt pour donner à Netfilter son rôle de passerelle et de protection du réseau local.

Nous pouvons dors et déjà rendre le firewall chargeable automatiquement dès le démarrage du système de la passerelle :

  • En ce qui concerne la plus part des distribution basé sur Debian, voici la procédure :
       # cp firewall.sh /etc/init.d
       # chmod 744 /etc/init.d/firewall.sh
       # update-rc.d firewall.sh start 20 3 5 . stop 80 0 1 2 4 6 .
       # /etc/init.d/firewall.sh start
  • Et pour ce qui est de la plupart des distributions basées sur Redhat :
       # cp firewall.sh /etc/init.d
       # chmod 744 /etc/init.d/firewall.sh
       # chkconfig --add firewall.sh
       # chkconfig --list firewall.sh
       firewall.sh 0:off 1:off 2:off 3:on 4:off 5:on 6:off
       # /etc/init.d/pfirewall.sh start

Ajout de règles personnalisées

Vous aurez sans doute des besoins spécifiques à votre réseau local :

  • Autoriser une entrée exceptionnelle de paquets destinés à la passerelle (INPUT)
  • Rediriger les paquets (FORWARD)
  • Autoriser une sortie de paquets destinés à l'internet (OUTPUT)

Par exemples :

  • Permettre une connexion sur le service Open SSH afin de configurer la passerelle et rendre accessible votre service DNS sur l'internet :
       /sbin/iptables -A INPUT -i ppp0 -p tcp -m state --state NEW -m multiport --destination-port 22,53 -j ACCEPT
  • Permettre à un internaute l'accès au service Web d'une machine derrière la passerelle
       /sbin/iptables -t nat -A PREROUTING -p tcp -i ppp0 --dport 80 -j DNAT --to-destination [192.168.x.x]:80
  • Permettre à la passerelle l'usage du ping sur l'internet et autorisé sa réponse
       /sbin/iptables -t filter -A OUTPUT  -m state --state NEW,RELATED,ESTABLISHED -p icmp -j ACCEPT

Mais attention : à chaque fois que vous ouvrez un port de plus sur votre passerelle ou vers une machine de votre réseau, vous affaiblissez la sécurité de votre LAN. Il faudra donc mettre en place des contre-mesures. Vous aurez plus d'informations à ce sujet dans la section Sécurité mais sachez déjà qu'il faudra sans doute modifier la configuration des services que vous rendez accessibles sur le réseau public.

Suppression d'une règle

Avant de créer votre script définitif, vous aurez sans doute de nombreux tests à effectuer pour vérifier son bon fonctionnement et donc des règles à ajouter, modifier et supprimer.

Pour supprimer une règle dans une table défini, il faudra d'abord lister les règles avec un numéro désignant chaque règle :

       /sbin/iptables -L --line-numbers

Lorsque vous avez le numéro de votre règle à suprimé ainsi que la table qui la contient vous pourrez faire alors :

       /sbin/iptables -D <chaine> <numéro_de_ligne>

Dnsmasq : Résolution des noms et adressage IP dynamique

Vous pouvez utiliser votre passerelle dès maintenant...

... mais ce serait dommage de ne pas en profiter pour lui apporter quelques améliorations.

Par exemple, il va falloir donner aux clients l'adresse de la passerelle et les serveurs DNS à consulter pour la résolution de noms. Bien sûr, vous pouvez simplement consulter le fichier /etc/resolv.conf qui sera rempli par votre FAI de ses adresses IP de serveurs DNS puis configurer manuellement chacun des postes clients. Ce n'est pas ce qui a de plus interessant à faire sur un réseau : répétitif, long, fastidieux...

De plus, chacun des clients du réseaux vas faire des requêtes de résolutions de noms. Bien souvent, c'est requêtes seront redondantes. Au lieu de multiplier des requêtes qui consommerons de la bande passantes et qui seront sans doute pas très réactives, vous pouvez profiter de votre propre passerelle pour y installer un service de noms qui fera les requêtes pour vos clients. Non seulement vous ne gaspillerais pas un peu de votre bande passante inutilement mais surtout les réponses de résolutions de noms seront instantanées. ce qui rendra notamment l'usage du Web bien plus confortable.

Comme tout bon informaticiens qui se respecte, nous allons donc installer un logiciel qui vas nous automatiser tout cela. Deux logiciels bien connu et utilisé sur de nombreuses passerelles Linux sont dhcpd3 et Bind. Mais ce sont des logiciels complexes et pas forcement nécessaires pour un LAN de taille relativement classique pour un réseau familial ou de petite entreprise. Pour tout dire, c'est un couple qui n'est nécessaire que lorsque l'on veut gérer une zone sur l'internet, pouvoir faire de la redondance de serveurs DNS et supporter la charge de réseaux particulièrement grand ainsi que rendre les enregistrements des machines dynamique. Nous allons donc nous 'contenter' de Dnsmasq, un logiciel beaucoup plus simple qui remplira efficacement sont rôle pour ce dont nous avons besoin.

Installation de Dnsmasq

L'installation de Dnsmasq se fait comme pour iptables, avec le gestionnaire de paquets de votre distribution :

       aptitude install dnsmasq

Si le paquet dnsmasq pour votre distribution n'existe pas, il vous faudra télécharger les sources de la dernière version sur le site de son auteur : http://www.thekelleys.org.uk/dnsmasq/

Les lignes de commandes suivantes devrait suffirent :

       wget http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.55.tar.gz
       tar -xvzf dnsmasq-2.55.tar.gz
       cd dnsmasq-2.55/
       make ; make install

Configuration de Dnsmasq

Dans un premier temps, nous allons configurer Dnsmasq pour son rôle de service de résolution de noms. Ensuite, nous configurerons son option de service dhcp.

Résolution de noms

Dnsmasq se configure par son fichier /etc/dnsmasq.conf. Voici une configuration minimale de fonctionnement :

       domain-needed
       expand-hosts
       bogus-priv
       interface=eth1
       domain=lox.lan
       cache-size=512

Description des options :

  • domain-needed : Indique à Dnsmasq de ne jamais transmettre en amont de requêtes pour des noms simples, ne comprenant donc ni points ni nom de domaine. Si un nom n'est pas dans /etc/hosts ou dans la liste des baux DHCP, alors une réponse de type "non trouvé" est renvoyée.
  • expand-hosts : Ajoute le nom de domaine aux noms simples (ne contenant pas de point dans le nom) contenus dans le fichier /etc/hosts, de la même façon que pour le service DHCP.
  • bogus-priv : Fausse résolution inverse pour les réseaux privés. Toutes les requêtes DNS inverses pour des adresses IP privées (ie 192.168.x.x, etc...) qui ne sont pas trouvées dans /etc/hosts ou dans le fichier de baux DHCP se voient retournées une réponse "pas de tel domaine" ("no such domain") au lieu d'être transmises aux serveurs de nom amont ("upstream server").
  • interface=ethx : N'écouter que sur l'interface réseau spécifiée. Dnsmasq aujoute automatiquement l'interface locale ("loopback") à la liste des interfaces lorsque l'option --interface est utilisée. Si aucune option --interface ou --listen-address n'est donnée, Dnsmasq écoutera sur toutes les interfaces disponibles sauf celle(s) spécifiée(s) par l'option --except-interface. Les alias d'interfaces IP (e-g "eth1:0") ne peuvent être utilisés ni avec --interface ni --except-interface. Utiliser l'option --listen-address à la place.
  • domain=xxxxx.zzz : Spécifie le domaine du serveur DHCP. Le domaine peut être donné de manière inconditionnelle (sans spécifier de gamme d'adresses IP) ou pour des gammes d'adresses IP limitées. Cela a deux effets; tout d'abord, le serveur DHCP retourne le domaine à tous les hôtes le demandant, deuxièmement, cela spécifie le domaine valide pour les hôtes DHCP configurés. Le but de cela est de contraindre les noms d'hôte afin qu'aucun hôte sur le LAN ne puisse fournir via DHCP un nom tel que par exemple "microsoft.com" et capturer du trafic de manière illégitime. Si aucun nom de domaine n'est spécifié, alors les noms d'hôtes avec un nom de domaine (c-à-d un point dans le nom) seront interdits et enregistrés dans le journal (logs). Si un suffixe est fourni, alors les noms d'hôtes possédant un domaine sont autorisés, pour peu que le nom de domaine coïncide avec le nom fourni. De plus, si un suffixe est fourni, alors les noms d'hôtes ne possédant pas de nom de domain se voient rajouter le suffixe fourni dans l'option --domain. Ainsi, sur mon réseau, je peux configurer --domain=thekelleys.org.uk et avoir une machine dont le nom DHCP serait "laptop". L'adresse IP de cette machine sera disponible à la fois pour "laptop" et "laptop.thekelleys.org.uk". Si la valeur fournie pour <domaine> est "#", alors le nom de domaine est positionné à la première valeur de la directive "search" du fichier /etc/resolv.conf (ou équivalent). La gamme d'adresses peut être de la forme <adresse ip>,<adresse ip> ou <adresse ip>/<masque de réseau> voire une simple <adresse ip>. Voir --dhcp-fqdn qui peut changer le comportement de dnsmasq relatif aux domaines.
  • cache-size=512 : Définit la taille du cache de Dnsmasq. La valeur par défaut est de 150 noms. Définir une valeur de zéro désactive le cache.

Pour une configuration plus pointu, je vous invite à vous référer à la page man[1] de cet outil.

Adressage IP dynamique

Pour configurer l'option d'adressage IP dynamique de Dnsmasq, il faudra ajouter les lignes suivantes au fichier /etc/dnsmasq.conf :


       # Plage DHCP et durée du bail
       dhcp-range=192.168.1.10,192.168.100.110,24h
       # Netmask (option 1)
       dhcp-option=1,255.255.255.0
       # Route par défaut (option 3)
       dhcp-option=3,192.168.1.254
       # DNS (option 6)
       dhcp-option=6,192.168.1.1,212.27.40.240,212.27.40.241
       # adresse IP fixe pour machinefixe
       dhcp-host=00:00:00:00:00:00,machinefixe,192.168.1.10

Il me semble que les commentaires se suffisent à eux-mêmes mais si vous éprouvez le besoin d'en savoir plus je vous recommande de nouveau de vous référer à la page man de dnsmasq[1].

Squid : Mise en cache du Web

Nous avons maintenant une passerelle vraiment fonctionnelle mais nous pouvons encore lui ajouter une ou deux nouvelles capacités qui apporteront au réseau un peu plus de sécurité et de confort ainsi qu'une meilleure gestion de la bande passante.

Comme Dnsmasq, Squid vas aussi nous permettre de rendre l'accès au Web encore un peu plus réactifs en gardant les pages les plus souvent visitées en mémoire cache. Ainsi, si plusieurs clients demande un même site, une seule requête sera faite sur le Web et disponible pour chacun des clients à partir de la passerelle. De plus, les machines clientes cachées derrière ce mandataire seront inexistante pour quiconque espionne votre adresse IP publique, donc inaccessible par la personne mal intentionnée.

Nous allons ensuite ajouter un greffons à Squid qui s'appelle SquidGuard et permet de filtrer les sites Web afin d'éviter principalement qu'un enfant tombe sur un site qui ne doit pas être visible à son age.

Enfin, nous allons installer une authentification qui nous permettra de contrôler qui à accès au Web sur le réseau dont on à la responsabilité.

Installation de Squid

Nous allons de nouveau faire appel à notre gestionnaire de paquets favori. Pour une Debian ce sera encore :

       aptitude install squid

Si votre distribution ne possède pas de paquets Squid, vous pouvez télécharger les sources sur le site officiel [2] ou le serveur ftp de l'université de Toulouse 1[3] ou l'université de Rennes 1[4].

Selon la page Squid de UT1[5], il est interessant de compiler Squid ainsi :

       ./configure --enable-snmp --enable-err-language=French --enable-cache-digests --enable-icmp --enable-async-io=64 --enable-heap-replacement --enable-auth-modules="LDAP,PAM,NCSA"
       make
       make install
       make install-pinger

Les options de compilation choisies permettent :

  • de faire une surveillance snmp,
  • d'avoir des messages d'erreurs en français,
  • de dialoguer entre nos 2 caches plus efficacement qu'avec ICP,
  • de bénéficier d'un "calcul de distance" entre le serveur et le cache,
  • de faire des écritures asynchrones (plus performantes),
  • de pouvoir modifier la politique d'élimination des anciens objets cachés,
  • de choisir une éventuelle politique d'identification.

Configuration de Squid

L'objectif de ce tutoriel étant toujours de mettre en place une passerelle Internet rapidement, nous allons voir un fichier de configuration minimal. Libre à vous de consulter la documentation de Squid [6] pour rendre son fonctionnement plus en adéquation avec ce que vous en attendez.

Pour plus de clarté, il peut être intéressant de sauvegarder le fichier de configuration d'origine et d'utilisé une expression régulière [7] afin de garder seulement les lignes non-commentées.

       # cd /etc/squid/
       # mv squid.conf squid.conf.origin 
       # cat squid.conf.origin | egrep -v -e '^[:blank:]*#|^$' > squid.conf 

Voici donc le fichier sans les commentaires d'origines mais avec quelques remarques pour avoir une explication globale de la configuration de Squid. Il sera toujours possible d'affiner la configuration en se tournant vers la documentation du fichier squid.conf.origin en cas de besoin.


Les ACL (Access Control Lists) vont définir les conditions attribuées aux plages d'adresses IP, aux ports, à des chaînes de caractères, des fichiers,...

       acl all src all
       acl manager proto cache_object
       acl localhost src 127.0.0.1/32
       acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
       acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
       acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
       acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
       acl SSL_ports port 443          # https
       acl SSL_ports port 563          # snews
       acl SSL_ports port 873          # rsync
       acl Safe_ports port 80          # http
       acl Safe_ports port 21          # ftp
       acl Safe_ports port 443         # https
       acl Safe_ports port 70          # gopher
       acl Safe_ports port 210         # wais
       acl Safe_ports port 1025-65535  # unregistered ports
       acl Safe_ports port 280         # http-mgmt
       acl Safe_ports port 488         # gss-http
       acl Safe_ports port 591         # filemaker
       acl Safe_ports port 777         # multiling http
       acl Safe_ports port 631         # cups
       acl Safe_ports port 873         # rsync
       acl Safe_ports port 901         # SWAT
       acl purge method PURGE
       acl CONNECT method CONNECT

Les restrictions vont autoriser ou interdire une ACL définie ci-dessus. Elles sont classé de la plus fine à la plus globale et de l'autorisation avant l’interdiction.

       http_access allow manager localhost
       http_access deny manager
       http_access allow purge localhost
       http_access deny purge
       http_access deny !Safe_ports
       http_access deny CONNECT !SSL_ports
       http_access allow localhost
       http_access deny all
       icp_access allow localnet
       icp_access deny all

Désignation de la variable du port de connexion

       http_port 3128

Interdit les requêtes vers d'autres éventuels proxy

       hierarchy_stoplist cgi-bin ?

access_log désigne le fichier de journalisation de Squid.

       access_log /var/log/squid/access.log squid

La directive refresh_pattern permet un contrôle fin de la validité des objets cachés.

       refresh_pattern ^ftp:           1440    20%     10080
       refresh_pattern ^gopher:        1440    0%      1440
       refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
       refresh_pattern (Release|Packages(.gz)*)$       0       20%     2880
       refresh_pattern .               0       20%     4320
       acl shoutcast rep_header X-HTTP09-First-Line ^ICY.[0-9]
       upgrade_http0.9 deny shoutcast
       acl apache rep_header Server ^Apache
       broken_vary_encoding allow apache
       extension_methods REPORT MERGE MKACTIVITY CHECKOUT
       hosts_file /etc/hosts
       coredump_dir /var/spool/squid

Sécuriser Squid

Avec le fichier de configuration par défaut, l'accès web est tellement bien sécurisé qu'il ne laisse rien passer sur les clients du réseaux mis à part lui-même. Vous vous en rendrez rapidement compte en configurant la connexion de l'un des navigateurs d'un de vos clients vers votre serveur proxy fraîchement mis en place. Pour permettre à vos client un accès web, il vous faudra faire les modifications suivantes :

  • restreindre les plages d'adresses IP en fonction du nombre de clients sur votre réseau

Il faut pour cela suprimer (ou commenter) les lignes :

       acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
       acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
       acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

pour les remplacer par exemple, par :

       acl localnet src 192.168.1.0/24

pour autoriser la totalité du réseaux, ou encore :

       acl serveurs src 192.168.1.10 192.168.1.50
       acl borne src 192.168.1.100

pour autoriser uniquement quelques machines de votre réseau.

  • puis autoriser ce réseau ou ces machines en ajoutant la ou les lignes suivantes :
       http_access allow localnet
       http_access allow serveurs
       http_access allow borne

juste avant la ligne :

       http_access deny all
  • De plus, par défaut, Squid écoute sur toutes les interfaces. Pour éviter qu'il offre aussi ses services sur l'interface publique, on doit lui spécifier l'adresse IP de l'interface privé sur la même ligne sur laquelle on a défini le port :
       http_port 192.168.1.1:3128

Après avoir recharger la configuration du service squid par un

       # /etc/init.d/squid reload

Le rafraichissement de la page du navigateur clients configurer sur votre proxy doit vous afficher votre site web.

Si ce n'est pas le cas, vérifier les fichiers de journalisation de Squid ainsi que la syntaxe des lignes ajoutées.

  • Il est ensuite possible de restreindre les horaires d'accès web autorisés :

Ligne modèle :

       acl [mot_clef] time [liste_jours] [heure:minute-heure:minute]

Exemple :

       acl calendrier time MTWHF 12:00-14:00
       ...
       http_access allow allowed_hosts calendrier

Ici, l'acl calendrier désigne des périodes de temps : du lundi au vendredi et de 12h à 14h qui sont autorisées par la ligne http_access.

Les jours en anglais sont symbolisé ainsi :

  • M : Lundi (Monday),
  • T : Mardi (Tuesday),
  • W : Mercredi (Wednesday),
  • H : Jeudi (tHursday),
  • F : Vendredi (Friday),
  • A : Samedi (sAturday),
  • S : Dimanche (Sunday).


  • Ou encore, d'interdire certains sites considéré comme douteux voire dangereux pour les clients de votre réseau :
       acl liste_noire url_regex „/etc/blacklist.txt“
       ...
       http_access deny liste_noire

Les sites web listé dans le fichier /etc/blacklist.txt seront interdit d'accès. Pour une configuration plus fine et plus efficace, il faudra utiliser SquidGuard.


Suite à ces modifications dans le fichier de configuration, il vous faut redémarrer le service squid :

      # /etc/init.d/squid restart

En cas de problème, il vous faudra surveiller le fichier de journalisation /var/log/messages ainsi que ceux de Squid pour en connaître la cause.

Configuration des clients ou proxy transparent

Il vous reste maintenant à configurer chacun des navigateurs des clients de vos réseaux afin de leur signaler de passer par le proxy pour les accès http et ftp. Une opération qui peut être longue et fastidieuse en fonction du nombre de machines connectées à votre réseau. Il y a plusieurs façons de se facilité la tache mais nous allons voir pour le moment, la plus simple et la plus rapide : rendre le cache transparent pour les utilisateurs du réseau.

Pour cela, il suffit d'ajouter le mot 'transparent' à la désignation du port utilisé par Squid dans son fichier de configuration squid.conf :

       http_port 192.168.1.1:3128 transparent

Ainsi que modifier le script firewall.sh en ajoutant ces lignes :

       iptables -t nat -F PREROUTING
       iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

Les requêtes des clients sur le port 80 seront systématiquement redirigé vers le port 3128 du proxy.

Par contre, seule les requêtes http seront mise à cache. Les requêtes ftp se faisant sur un autre port ne pourront pas passer par le proxy.

SquidGuard : Filtre des sites Web

Comme nous l'avons vu, Squid est très limité pour ce qui est de maintenir une restriction des accès web. En effet, lorsque vous êtes responsable d'un réseau sur lequel il y aura des enfants qui pourraient tomber sur des sites douteux voire dangereux pour eux, il est de votre devoir de les en protéger. Et selon le cas, vous pouvez d'ailleurs encourir de sévère sanction devant la loi si vous ne le faite pas [8].

Dans le cas d'une école, d'une bibliothèque ou chez vous pour la sécurité des enfants, vous aurez besoin de mettre en place un système de filtrage bien plus efficace s'appuyant sur Squid qui est SquidGuard.

Voici les principales fonctionalitées de ce redirecteur :

  • Filtration par liste blanche (seul les sites web de la liste sont autorisé) ;
  • Filtration par liste noire (tout le web est autorisé sauf les sites de la liste) ;
  • Filtration par mots clefs (les sites présentant dans leurs URL les mots clefs contenu dans la liste sont interdit) ;
  • Filtration des sites disponible uniquement en adresse IP ;
  • Redirection des utilisateurs vers une page d’information lorsqu’un site est interdit ;
  • Redirection des bannières de pub vers une image vide locale ;
  • Gérer des règles d’accès selon les jours et les heures ;
  • Maintenance des listes noires.

Installation de SquidGuard

Comme d'habitude sous Debian...

       # aptitude install squidguard
       # cd /var/lib/

Vous trouverez les sources sur le site officiel [9]. La compilation se fera par un simple :

       # tar -xvzf squidGuard-current.tar.gz
       # cd squidGuard-current
       # ./configure
       # make install

SquidGuard sera alors installé dans /usr/local

       # cd /usr/local/

Il vous faudra alors décompresser les listes dans le répertoire squidguard/db/ qui a été laissé vide lors de l'installation ( /var/lib/squidguard/db/ pour le paquet debian ou /usr/local/squidguard/db/ pour la compilation des sources). Vous pouvez les trouvez sur le site officiel [10] mais celle qui intéresse plus particulièrement les francophones est maintenue par Fabrice Prigent de l'UT1 [11] téléchargeable ici : blacklists.tar.gz.

       # cp /chemin/de/votre/blacklists.tar.gz squidGuard/db
       # cd squidGuard/db
       # gzip -d blacklists.tar.gz
       # tar -xvzf blacklists.tar

Il est possible de mettre à jour automatiquement ces listes une fois par semaine, grâce à un script lancé par cron à mettre dans le répertoire /etc/cron.weekly/maj_squidguard_blacklists :

       # vim /etc/cron.weekly/maj_squidguard_blacklists

Le script récupéré sur le site de documentation francophone d'Ubuntu [12] :

       #!/bin/sh
       #
       # Fichier /etc/cron.weekly/squidguard_blacklists
       #
       # Télécharge chaque semaine les listes noires pour SquidGuard
       # et met à jour les bases de ce dernier.
       
       if [ -d /var/lib/squidguard ]; then
               wget ftp://ftp.univ-tlse1.fr/pub/reseau/cache/squidguard_contrib/blacklists.tar.gz -O /var/lib/squidguard/blacklists.tar.gz
               tar zxvf /var/lib/squidguard/blacklists.tar.gz -C /var/lib/squidguard/
               rm -rf /var/lib/squidguard/db
               mkdir /var/lib/squidguard/db || true
               mv -f /var/lib/squidguard/blacklists/* /var/lib/squidguard/db/
               chmod 2770 /var/lib/squidguard/db
               rm -rf /var/lib/squidguard/blacklists /var/lib/squidguard/blacklists.tar.gz
               /usr/bin/squidGuard -C all
               chown -R squid:squid /etc/squid /var/log/squid /var/spool/squid /usr/lib/squid /usr/sbin/squid /var/lib/squidguard
               /etc/init.d/squid restart
       fi

SquidGuard et les blacklists installés, il nous faut alors signaler à Squid le redirecteur SquidGuard.

Un redirecteur est un programme qui "s'attache" à Squid et qui permet une réécriture des URLs avant de les passer au cache proprement dit. Cela permet de modifier les Urls pour restreindre les accès (Urls à caractère pornographique, ludique, etc...), faire disparaître les publicités (et donc accélérer considérablement le trafic, les bandeaux étant généralement régénérés à chaque appel) ou diriger l'utilisateur vers un miroir local (par exemple les téléchargements de Netscape Navigator).

Pour les mettre en place, il faut ajouter dans le fichier de configuration de Squid squid.conf la ligne désignant le redirecteur :

       url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

Et définir le nombre de fils redirecteur :

       url_rewrite_children 5

La valeur choisie dépendra du nombre de client sur votre réseau et de la quantité de mémoire vive à la disposition du service. Il faut une valeur suffisamment élevée pour que le processus principal ne soit pas bloqué en attente d'un process redirecteur libre mais pas trop pour éviter de surcharger la mémoire. Les redirecteurs font quasiment tous, au départ, de 800 Ko à 1600 Ko. De toute manière Squid en limite le nombre à 32.

IMPORTANT : Après avoir ajouter ces deux lignes au fichier de configuration de Squid, ne redémarrez pas le service avant d'avoir fini de configurer SquidGuard ou commentez les en attendant.

Dans la majorité des cas, vous aurez besoin d'un serveur http pour orienter les redirections vers une page publier de ce service sauf si vous effectuez vos redirection vers un site web quelconque. Il existe de nombreux service http mais Apache est sans aucun doute le plus documenté et le mieux intégré aux distributions Linux. Il s'impose donc pour notre passerelle.

Pour installer Apache :

       # aptitude install apache2

En lançant votre navigateur avec l'adresse IP de votre serveur, vous devriez tomber sur ce message :

 It works!
 
 This is the default web page for this server.
 
 The web server software is running but no content has been added, yet.

Pour la compilation d'Apache veuillez vous tourner vers la documentation officielle[13].

Il faut maintenant rendre le script cgi fourni par le paquet de SquidGuard, disponible par Apache :

       # cp /usr/share/doc/squidguard/examples/squidGuard.cgi.gz /usr/lib/cgi-bin/
       # gunzip /usr/lib/cgi-bin/squidGuard.cgi.gz
       # chmod +x /usr/lib/cgi-bin/squidGuard.cgi

Configuration de SquidGuard

Nous sommes maintenant prêt à la configuration de SquidGuard proprement dite avec le fichier /etc/squid/squidGuard.conf.

Présentation du fichier

  • Configuration générale
       #
       # CONFIG FILE FOR SQUIDGUARD
       #
       
       dbhome /var/lib/squidguard/db
       logdir /var/log/squid

C'est deux lignes indiquent à SquidGuard le chemin pour trouver les blacklists ainsi que pour placer les fichiers de journalisation.

  • Configuration des règles d'accès au web

Permet de régler plus finement l'accès aux web que ne le fait déjà Squid.

       #
       # TIME RULES:
       # abbrev for weekdays:
       # s = sun, m = mon, t =tue, w = wed, h = thu, f = fri, a = sat
       
       time workhours {
               weekly mtwhf 08:00 - 16:30
               date *-*-01  08:00 - 16:30
       }

Il est possible de définir différentes périodes d'utilisation auxquelles on pourra attribuer des règles d'accès différentes et à des personnes ou groupes de personnes différents.

  • Réécritures des Urls à la volée
       #
       # REWRITE RULES:
       #
       
       #rew dmz {
       #       s@://admin/@://admin.foo.bar.de/@i
       #       s@://foo.bar.de/@://www.foo.bar.de/@i
       #}
  • Définition des adresses source
       #
       # SOURCE ADDRESSES:
       #
       
       #src admin {
       #       ip              1.2.3.4 1.2.3.5
       #       user            root foo bar
       #       within          workhours
       #}
       
       #src foo-clients {
       #       ip              172.16.2.32-172.16.2.100 172.16.2.100 172.16.2.200
       #}
       
       #src bar-clients {
       #       ip              172.16.4.0/26
       #}

Ici, les sources définissent des groupes de clients par adresses IP ou plages d'adresses IP. Mais si une authentification à été configurer pour l'accès web par le proxy, il est alors possible d'utiliser des sources pour définir des utilisateurs.

  • Définition des classes de destinations
       #
       # DESTINATION CLASSES:
       #
       
       dest good {
       }
        nom
       dest local {
       }
       
       #dest adult {
       #       domainlist      adult/domains
       #       urllist cas, fa adult/urls
       #       expressionlist  adult/expressions
       #       redirect        http://admin.foo.bar.de/cgi-bin/squidGuard.cgi?clientaddr=%a+clientname=%n+clientident=%i+srcclass=%s+targetclass=%t+url=%u
       #})

Mis à part quelques exceptions, il y a généralement une classe de destination par liste noire.

  • Les ACLs

Les ACLs définissent si la source peut ou non aller vers une destination. Le point d'exclamation signifiant la négation.

       acl {
       #       admin {
       #               pass     any
       #       }
       
       #       foo-clients within workhours {
       #               pass     good !in-addr !adult any
       #       } else {
       #               pass any
       #       }
       
       #       bar-clients {
       #               pass    local none
       #       }
       
               default {
                       pass     local none
       #               rewrite  dmz
       #               redirect http://admin.foo.bar.de/cgi-bin/squidGuard.cgi?clientaddr=%a+clientname=%n+clientident=%i+srcclass=%s+targetclass=%t+url=%u
               }
       }

A chaque groupe d'utilisateurs ou utilisateur authentifié (adresses source) correspond une ACL qui vas définir :

  • sa période d'accès,
  • les sites web défini dans les listes noire qui lui sont interdits,
  • une éventuelle réécriture de certaines adresse ou non et
  • une redirection vers un script CGI qui explique la raison de l'interdiction d'accès en cas d'urls non autorisées. Cette page pourra vous donner des informations utiles si l'utilisateur considère que le site qui lui est interdit ne le devrait pas.

Fichier minimal

Un fichier minimum pourrait fonctionner sans les classes de destination avec une seule source d'adresse et une seule acl. Si la machine possède l'adresse IP définie dans la source d'adresse, elle aura accès à tout le web, sinon elle n'y aura pas accès et en cas de tentative, sera redirigé.

       dbhome /var/lib/squidguard/db
       logdir /var/log/squid
       
       src admin {
               ip              192.168.1.20
       }
       
       acl {
               admin {
                       pass     any
               }
       
               default {
                       pass      none
                       redirect http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a+clientname=%n+clientident=%i+srcclass=%s+targetclass=%t+url=%u
               }
       }

Ce fichier autorisera uniquement la machine avec l'adresse IP de l'administrateur à avoir accès au web (cette adresse IP pourra être attribuer en adresse IP fixe par le serveur DHCP). Toutes les machines connectées au réseaux local avec une autre adresse seront redirigées vers le script cgi squidGuard.cgi lorsque l'utilisateur tentera un accès web.

A ce fichier, vous pourrez ajouter les périodes autorisées, définir de nouveaux groupes de clients (comme 'adultes' et 'enfants' par exemple)ou des clients authentifiés, des réécritures d'urls, et bien sûr, des classes de destination utilisée ou non en fonction du groupe de client visé grâce aux acls.

Exemple de fichier de configuration

Prenons le cas d'un cahier des charges totalement fictif pour une structure imaginaire avec deux salles d'ordinateurs : l'une pour les enfants, l'autre pour les adultes. A la salle 'enfants', les adresses IP sont attribuées de 192.168.1.30/24 à 192.168.1.40/24 tandis que pour la salle 'adultes' les adresses IP sont sur le réseau 192.168.2.0/24

La salle d'ordinateur 'enfants' n'est réservées que le mercredi après-midi. Le reste du temps, elle est ouvertes aux adultes. Pour faire respecter les horaires de fermeture plus facilement, il a été décidé de bloquer la connexion web cinq minutes après l'horaire de fermeture afin de laisser le temps aux utilisateurs de finir 'proprement' leur recherche. La structure étant ouverte au public du lundi au vendredi de 9h à 17h. Pour simplifier le cahier des charges, les adultes auront accès au sites référencées dans la listes noire 'adults' mais pas les enfants. De plus, les publicités seront retirées pour ne pas surcharger la bande passante et les urls en adresse IP seront refusées pour des question de sécurité (!in-addr).

Voici à quoi devra ressembler le fichier :

       #
       # CONFIG FILE FOR SQUIDGUARD
       #
       
       dbhome /var/lib/squidguard/db
       logdir /var/log/squid
       # Définitions des périodes de temps
       # TIME RULES:
       # abbrev for weekdays:
       # s = sun, m = mon, t =tue, w = wed, h = thu, f = fri, a = sat
       
       time horaires_ouverture {
               weekly mtwhf 09:00 - 17:05
               date *-*-01  09:00 - 17:05
       }
       
       time mercredi_apres_midi {
               weekly w     13:00 - 17:05
               date *-*-01  09:00 - 17:05
       }
       #
       # REWRITE RULES:
       #
       
       #rew dmz {
       #       s@://admin/@://admin.foo.bar.de/@i
       #       s@://foo.bar.de/@://www.foo.bar.de/@i
       #}
       # Définition des types d'utilisateurs
       # SOURCE ADDRESSES:
       #
       
       # L'administrateur
       #src admin {
       #       ip              192.168.1.20
       #       user            root foo bar
       #       within          workhours
       #}
       
       # Les enfants
       #src enfants {
       #       ip              192.168.1.30-192.168.1.40
       #}
       
       # Les adultes
       #src adultes {
       #       ip              192.168.2.0/24
       #}
       # Définitions des classes de destination devant être utilisées pour chacun des groupes
       # DESTINATION CLASSES:
       #
       
       dest good {
       }
       #  nom
       dest local {
       }
       
       dest adult {
              domainlist      adult/domains
              urllist cas, fa adult/urls
              expressionlist  adult/expressions
              redirect        http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a+clientname=%n+clientident=%i+srcclass=%s+targetclass=%t+url=%u
       })
       
       dest publicite {
              domainlist      publicite/domains
              urllist cas, fa publicite/urls
              expressionlist  publicite/expressions
              redirect        http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a+clientname=%n+clientident=%i+srcclass=%s+targetclass=%t+url=%u
       })
       #
       # Définition des règles d'utilisation du web en fonction des groupes définies
       #
       
       acl {
              admin {
                      pass     any
              }
       
              adultes within horaires_ouverture {
                      pass     good !in-addr !publicite any
              } else {
                      pass any
              }
       
              enfants within mercredi_apres_midi {
                      pass     good !in-addr !adult !publicite any
              } else {
                      pass none
              }
       
               default {
                       pass     local none
       #               rewrite  dmz
                       redirect http://127.0.0.1/cgi-bin/squidGuard.cgi?clientaddr=%a+clientname=%n+clientident=%i+srcclass=%s+targetclass=%t+url=%u
               }
       }

A vous d'adapter au mieux en fonction des utilisateurs de vos réseaux.

Il faut maintenant rendre exploitable les listes noires en construisant les bases de données :

       # su squid
       # squidGuard -C all
       # exit

Et ensuite, redémarrer Squid pour prendre en considération le redirecteur SquidGuard (n'oubliez pas de décommenter les deux lignes concernant squidGuard dans le fichier squid.conf si vous les aviez commentées) :

       # /etc/init.d/squid reload

En cas de problème de fonctionnement, n'oubliez pas de consulter les fichiers de journalisation. Le fichier squidGuard.conf n'est pas permissif. La moindre faute est sanctionné par un filtrage non opérationnel : SquidGuard laissera tout passer par défaut. De plus, faites attention à la mise en place des lignes de redirection. Si squidGuard ne sait pas où renvoyer l'utilisateur, il laisse le site accessible.

NCSA : Authentification des clients

Il peut arriver que l'on ait besoin d'une authentification des clients pour le suivie des connexions des utilisateurs en cas de problème avec la justice par exemple ou tout simplement limiter l'autorisation d'accès au web à certaines personnes.

Il existe de nombreux systèmes d'identification des utilisateurs du proxy : ldap, samba, active directory, ncsa,...

  • LDAP : L’authentification se base sur un annuaire présent sur le réseau. Intéressant si le réseau est particulièrement grand.
  • SMB/MSNT : Fonctionne avec une connexion sur un serveur Windows ou SAMBA pour gérer l’authentification. Peut être intéressant avec un réseau homogène sous Windows.
  • GETPWAM : Cette solution permet d'utiliser directement le fichier de mot de passe /etc/passwords de la machine Linux hébergeant Squid. Il faut alors créer un compte pour chaque utilisateurs.
  • NCSA : On utilise un fichier comportant des noms d’utilisateurs et des mots de passe, le tout au format NCSA. L’authentification NCSA est généralement plutôt utilisée dans la restriction d’accès aux pages publiées par un serveur Apache à l'aide du fichier .htaccess.

NCSA est le mieux adapté pour un réseau local hétérogène de petite taille. Il est rapide à mettre en place.

Configuration NCSA

NCSA utilise des outils fourni par le paquet apache2. Si vous ne l'avait pas déjà installer pour SquidGuard, je vous invite à le faire maintenant.

Vous aller devoir créer un répertoire qui contiendra le fichier qui vas recevoir les identifications :

       # mkdir -p /usr/etc/squid
       # cd /usr/etc/squid

L'outil apache htpassword vas créer le fichier et y ajouter un compte utilisateur.

       # htpasswd -c passwd [nom d’utilisateur]

Entrez deux fois le mot de passe, le compte est créer.

Pour ajouter un utilisateur ou modifier son mot de passe, il faudra refaire la même commande mais sans l'option -c.

Renouvelez l'opération autant de fois que nécessaire.

Il faut maintenant configurer Squid pour qu'il prenne en compte l'authentification par ce fichier en ajoutant ces quelques lignes dans /etc/squid/squid.conf :

       acl authentification proxy_auth REQUIRED
       http_access allow authentification
       authenticate_program /usr/sbin/ncsa_auth /usr/etc/squid/passwd
       authenticate_children 5
       authenticate_ttl 1 hour
       authenticate_ip_ttl 60 seconds

Le chemin du module ncsa_auth peut être différent selon les distributions.

  • authenticate_children définie le nombre de processus d'authentification lancé. Plus le réseau est lent plus il faudra de processus.
  • authenticate_ttl permet de définir la période durant laquelle l'utilisateur n'aura pas a renouveler son authentification.
  • authenticate_ip_ttl permet de définir la période durant laquelle Squid mémorise l'association entre l'utilisateur et l'adresse IP de la machine qu'il utilise.

Gestion des utilisateurs

Au delà de trois clients, la gestion des utilisateurs et le renouvellement de leur mot de passe risque d'être assez contraignant... Les utilisateurs étant sans cesse obliger de faire appel à vous ne serait-ce que pour un oublie de mot de passe.

Une interface web serait l'outil idéal pour laisser les utilisateurs changer eux-même leur mot de passe ou vous permettre de créer des comptes plus confortablement.

Deux outils vont vous facilité la tâche :

Installation admuser et chpasswd

Il n'existe pas (encore ?) de paquets pour ces deux outils. Vous devrez en télécharger les sources et les compiler.

  • Pour admuser :
       # wget http://sarg.sourceforge.net/admuser-2.3.2.tar.gz
       # tar xzvf admuser-2.3.2.tar.gz
       # cd admuser-2.3.2/
       # ./configure --prefix=/usr/etc --enable-language=French -–enable-cgidir=/usr/lib/cgi-bin
       # make
       # make install

Pour administrer vos utilisateurs, il vous faudra simplement pointer sur l’URL http://localhost/cgi-bin/admuser.cgi

  • Pour chpasswd, l'installation se fait de le même façon.
       # wget http://prdownloads.sourceforge.net/orsochpasswd/chpasswd-2.2.4.tar.gz
       # tar xzvf chpasswd-2.2.4.tar.gz
       # cd chpasswd-2.2.4/
       # ./configure --prefix=/usr/etc --enable-language=French -–enable-cgidir=/usr/lib/cgi-bin
       # make
       # make install

La configuration de chpasswd se fait grâce au fichier /usr/etc/chpasswd.conf qui doit contenir au moins ces lignes :

       password_file /usr/etc/passwd
       enable_log /usr/etc/chpasswd.log
       alert_mail_user root
       alert_mail_subject „CHPASSWD EVENT“

Vos utilisateurs pourront avoir accès à cette interface à travers l’URL http://localhost/cgi-bin/chpasswd.cgi

Pour éviter que les utilisateurs puissent avoir accès à la gestion des comptes et créer eux même un utilisateur, il faudra créer deux répertoires cgi-bin différents avec une demande d'authentification NCSA sur celui de admuser (cgi-bin-sec par exemple) grâce à un fichier .htaccess :

       AuthUserFile /usr/etc/.htpasswd
       AuthName admin
       AuthType basic
       <Limit GET>
               require valid-user
       </Limit>

Ainsi qu'un fichier .htpasswd créer avec l'outil htpasswd comme vu plus haut.

Pour activer le support des fichiers .htpasswd pour ce répertoire, il vous faut utiliser la directive "AllowOverride All".

A la fin du fichier /etc/apache2/sites-enabled/default, ajoutez ces lignes :

       <Directory „/usr/lib/cgi-bin-sec“>
               AllowOverride All
               Options None
               Order allow,deny
               Allow from all
       </Directory>

Traçabilité des accès

La suite logique de l'authentification est la traçabilité des accès. Vous pouvez ouvrir pour cela les fichiers log contenu dans le répertoire /var/log/squid/ et notamment, le fichier access.log mais sa lecture directe n'est pas évidente pour un humain. Des outils permettent de rendre lisible ces données.

Il existe de nombreux outils de surveillances permettant d'exploiter les fichiers de journalisation de Squid [16]. Puisque nous avons utilisé deux logiciels d'authentification SARG [17], nous allons utiliser l'outil d'analyse du même auteur qui est tout simplement Sarg[18].

Installation de l'outil d'analyse SARG

Un paquet Debian est rendu disponible par Luigi Gangitano, l'auteur de cet outils dans les backports [19].

Pour pouvoir installer ce paquet, il vous faudra ajouter la ligne suivante dans le fichier /etc/apt/sources.list :

       deb http://www.backports.org/debian/ squeeze-backports main contrib non-free

Et ensuite lancé les deux commandes qui vont mettre à jour la liste des paquets backports et enfin installer le paquet sarg :

       # apt-get update
       # apt-get install sarg

Pour l'installation des sources après téléchargement de l'archive :

       # tar xzvf sarg-2.3.1.tar.gz
       # cd sarg-2.3.1
       # ./configure --enable-sysconfdir=/usr/etc/squid/
       # make
       # make install

Configuration de l'outil d'analyse SARG

La configuration se limite à ajouter ses deux ligne dans le fichier /usr/etc/squid/sarg.conf pour indiquer à Sarg le chemin vers le fichier de log et le langage d'affichage du rapport d'analyse :

       language French
       access_log /var/log/squid/access.log

Il sera intéressant d'ajouter une ligne de ce type dans un fichier d'un des répertoires crontab pour avoir une mise à jour régulière du rapport d'analyse :

       /usr/bin/sarg -n -o /home/maison/public_html/logs/ -i

Conclusion

Dans un premier temps, cette passerelle fera très bien son office.

Mais si vous avez sur votre réseau une majorité de clients sous Windows, il pourrait être intéressant d'ajouter entre cette passerelle et votre réseau un second serveur mis dos à dos (mode bastion) équipé d'un système Windows Server, d'ISA (firewall Microsoft) et d'Active Directory afin d'avoir une protection plus grande et une gestion encore plus fine de l'usage de la bande passante.

Références

Cette page à été largement inspiré, mis à jour et complété de la page UnixGarden : Mise en oeuvre d'une passerelle sous Linux (de Lionel Tricon dans le Linux Magazine Hors série 21)

Voir aussi

Liens internes

Liens externes

  1. 1,0 1,1 Page en français man (8) dnsmasq
  2. Page en anglais Page de téléchargement du site officiel de Squid
  3. Page en français Serveur FTP de l'université de Toulouse 1 proposant le téléchargement de Squid
  4. Page en français Serveur FTP de l'université de Rennes 1
  5. Page en français Page Squid de l'UT1
  6. Page en anglaisDocumentation officielle de Squid
  7. Page en françaisExpression régulière fournie par Christian Caleca ici : http://irp.nain-t.net/doku.php/220squid:020_squid#configuration_minimale
  8. Page en françaisArticle 227-24 du Code Pénal Il suffit d'un seul mineur dans votre établissement.
  9. Page en anglaisDernière version de SquidGuard
  10. Page en anglaisDifférentes blacklists proposées par le site officiel
  11. Page en françaisBlacklists proposées par Fabrice Prigent de l'UT1
  12. Page en françaisTutoriel "Comment mettre en place un contrôle parental"
  13. Page en françaisCompilation et installation d'Apache version 2.2
  14. Page en anglaisSARG : admuser
  15. Page en anglaisSARG : chpasswd
  16. Page en anglaisSquid: Logfile Analysis
  17. Page en anglaisSARG
  18. Page en anglaisSARG : Squid Analysis Report Generator
  19. Page en françaisPaquet Debian de Sarg