Le wiki de Silverlake

L'objectif ici est de décrire l'installation d'un proxy Squid sous Debian. La version de Debian est la 5.0, nom de code "Lenny". Cette version est officiellement sortie le 14 février 2009. Les exemples présentés ici sont compatibles avec la version 4.0 dite "Etch".

Le serveur utilisé est une machine très standard type, RAM 1Go et disque dur SATA de 72Go. Un proxy ne réclame pas beaucoup de ressource et si vous avez moins de 50 utilisateurs un PC déclassé avec 256Mo suffit, le disque doit toutefois être rapide et avec au moins 40Go de dispo.

Avant tout, ses qualités techniques : Debian est réputée pour sa stabilité, pour son très bon système d'installation de mise à jour des composants logiciels et pour sa rapidité à réparer les failles de sécurité. Debian est reconnu pour son sérieux et ses fortes prises de positions dans le monde libre. Debian garantit la liberté des logiciels qu'elle propose ! Debian est si attachée au logiciel libre que cet engagement est formalisé dans un document écrit : Le Contrat social. Pour plus d'information ne pas hésiter à consulter le site officiel http://www.debian.org

Beaucoup d'entreprises rechignent à utiliser Debian parce qu'il n'y a pas de structure commerciale et donc pas de maintenance. Ce qui est faux. Certes il n'y a pas de "société Debian", mais il existe moult prestataires informatiques, dont Hewlett-Packard, en France pouvant parfaitement accompagner les entreprises et offrir du support sur Debian.

L'installation de l'OS est souvent une tache négligée, pour aller vite, on installe tous les logiciels avec un partitionnement par défaut. Dans la mise en place d'un proxy, il est inutile d'installer des packages ne servant à rien. Il est important de bien maîtriser l'installation et de ne configurer que le strict minimum. A la fin d'installation l'unique service devant tourner est ssh.

Une installation Debian de base ne prend pas plus de 30 minutes.

Il est souvent fait reproche à Debian de ne pas disposer d'un installateur graphique et simple comme on en retrouve sous Ubuntu. Toutefois pour rester dans l'esprit du véritable "admin Linux", le mode caractère sera utilisé, ainsi que l'installation en mode expert afin de paramétrer correctement toutes les options. Il s'agit de mettre en place un service dédié, une installation rapide avec les options par défaut est inadaptée.

L'installation se fera via le CD netinstall, il s'agit d'un CD minimal qui charge les composants depuis l'Internet. L'image ISO de ce CD est disponible sur le site Debian ( http://cdimage.debian.org/debian-cd/5.0.2a/i386/iso-cd/debian-502a-i386-netinst.iso ). Une fois l'image ISO gravée, booter le serveur sur le CD afin d'afficher l'écran suivant et choisir l'option "Advanced options"

L'objectif ici n'est pas de détailler chaque étape de l'installation mais de donner des points de repère. Dans le menu "Advanced options", choisir "Expert install".

• Pour la sélection du codage des caractères choisir UTF-8, cela évite bien des surprises à postériori,
• Ne pas démarrer les services de cartes PC qui sont relatifs au PCMCIA,
• Accepter de configurer l'horloge via NTP, cette option n'existe pas sous Etch, c'est une nouveauté Lenny en installation,
• Configurer ensuite l'interface réseau, en principe un serveur est en IP fixe. Dans les exemples du livre, les IP seront du type : 192.168.1.x

Il s'agit d'un point crucial qu'il importe de paramétrer avec soin. Il est impératif de partitionner le disque supportant l'OS pour des raisons qui seront exposées plus loin. Comme il s'agit de la configuration d'un serveur proxy, le disque est important notamment sur la ou les partitions recevant les traces ( les logs ). Par défaut les logs sont sous /var/log, dans le cas de Squid il est intéressant de mettre les logs sur un voir des disques séparés.

Remarque : LVM n'est pas utilisé, cela reste bien sur possible. Les valeurs indiquées ci-dessus n'ont à ce jour posées aucun problème. La partition /var est réduite, car les logs proxy seront écrits sur la partition /home.

La partition /boot doit toujours être la première du disque. Il est d'usage de ne pas mettre cette partition sur un système de fichier journalisé.

Historiquement il était d'usage de calibrer la swap à 2 fois la RAM. Les serveurs étant dotés de RAM conséquentes ( 8Go est courant ), cette règle est obsolète, il convient d'appliquer maintenant le mode de calcul suivant :

• RAM jusqu'a 1Go → swap = 2 x RAM
• RAM de 1Go à 4Go → swap = RAM
• Au dela swap = 0.5 x RAM

Déjà pour éviter de bloquer le système par l'engorgement du disque. Le répertoire /var, comme son nom l'indique, est sujet à de grandes variations car il contient les fichiers traces, notamment le répertoire /var/log. Par sécurité ensuite, afin de ne pas bloquer un serveur par saturation d'espace disque ou encore d'interdire l'installation sauvage de logiciel. Le partitionnement permet de sécuriser simplement un serveur.

L'objectif ici n'est pas de décrire la sécurisation complète d'un serveur, pour cela consultez le manuel de sécurisation complet proposé sur le site Debian. Ci-dessous un extrait relatif aux partitions.

Un schéma de partitionnement dépend de l'utilisation de la machine. Une bonne règle est d'être assez large avec vos partitions et de faire attention aux facteurs suivants :

• Une arborescence de répertoires modifiables par un utilisateur, telles que /home, /tmp et /var, doit être sur une partition distincte. Cela réduit le risque qu'un déni de service provoqué par un utilisateur ne remplisse votre point de montage « / » rendant ainsi le système inutilisable (Note : ce n'est pas strictement vrai car il existe toujours un espace réservé à l'utilisateur root qu'un utilisateur normal ne pourra pas remplir) et cela empêche les attaques de « liens durs » . Il est également intéressant d'interdire de lancer des exécutables depuis ces répertoires en ajoutant la clause noexec. La partition /var contient les paquets téléchargés par aptitude install et sont stockés dans /var/cache/apt/archives. Il est d'ailleurs conseillé une fois l'installation faite de purger ce répertoire par la commande suivante : aptitude clean.

• Toute partition où vous voulez installer des logiciels ne faisant pas partie de la distribution devrait être sur une partition distincte. Selon le standard sur la hiérarchie des fichiers (FHS), c'est /opt ou /usr/local. Si ce sont des partitions distinctes, elles ne seront pas effacées si vous devez réinstaller Debian.

• D'un point de vue sécurité, il est bien d'essayer de mettre les données statiques sur une partition et de monter celle-ci en lecture seule. /usr, /usr/local et /opt sont directement concernées, ainsi il est impossible d'installer des logiciels sans déverouiller le mode read-only.

Dans le cas d'un serveur de courriers, il est important d'avoir une partition séparée pour le répertoire des courriers (spool). Les utilisateurs distants (soit consciemment, soit inconsciemment) peuvent remplir le répertoire des courriers (/var/mail ou /var/spool/mail). Si le répertoire est sur une partition séparée, cette situation ne rendra pas le système inutilisable. Sinon (si le répertoire est sur la même partition que /var), le système pourrait avoir d'importants problèmes : les entrées des journaux ne seront pas créées, aucun paquet ne pourra plus être installé et certains programmes pourraient même avoir des problèmes à être exécutés (s'ils utilisent /var/run).

Ces règles simples ne sont évidement pas la panacée, mais c'est un début. Ci dessous quelques options possibles pour le montage des partitions.

• nosuid - Impossibilité d'utiliser des programmes set SUID/SGID sur cette partition.
• nodev - Impossible de créer des device sur cette partition
• noexec - Interdire l'exécution de programme sur cette partition
• ro - Montage de la partition en mode lecture seule
• rw - Montage en lecture/écriture.
• quota - Mise en place de quota disque.

La clause defaults, qui est mise par défaut par l'installateur, correspond aux options suivantes : rw, suid, dev, exec, auto, nouser, et async.

Voici le contenu du fichier /etc/fstab une fois tous les packages mis en place. Mettre en place cette configuration une fois la machine en production uniquement.

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>             <dump>  <pass>
proc            /proc           proc    defaults                 0       0
/dev/hda3       /               ext3    errors=remount-ro        0       1
/dev/hda1       /boot           ext2    defaults                 0       2
/dev/hda10      /home           ext3    rw,nosuid,nodev,noexec   0       2
/dev/hda7       /opt            ext3    ro                       0       2
/dev/hda9       /tmp            ext3    rw,nosuid,nodev,noexec   0       2
/dev/hda5       /usr            ext3    ro                       0       2
/dev/hda6       /usr/local      ext3    ro                       0       2
/dev/hda8       /var            ext3    rw,nosuid,nodev,noexec   0       2
/dev/hda2       none            swap    sw                       0       0

Une fois le partitionnement effectué, choisir d'installer un noyau avec juste les pilotes utiles, la version du noyau livrée avec Lenny est la 2.6.26.

Doit-on ou non autoriser les connexions directes du root ? En principe non, il faut créer un utilisateur qui accèdera aux droits root via la commande sudo. Ce principe, populaire notamment sur Ubuntu est à privilégier sur un serveur. Cet ouvrage à fait le choix de systématiquement utiliser sudo. Il est toutefois possible de se mettre root et ainsi ne plus préfixer par sudo chaque commande en utilisant sudo -i

Il faut ensuite choisir un miroir sur le réseau pour l'installation des logiciels et éventuellement configurer le proxy si celui-ci est présent. Choisir ensuite de ne pas installer de logiciels non libres ou de la branche contrib. Le système demande alors les dépots de mise à jour, Lenny intègre par défaut les serveurs de la branche volatile qui servent pour les fonctions anti-spam et anti-virales principalement, ce dépot dans le cas d'un proxy dédié peut être retiré.

Lors de l'affichage de la sélection des logiciels, ne rien installer, décocher toutes les cases. Sur un serveur il ne faut installer que ce qui est utile et rien d'autre.

L'installation se termine alors et le système redémarre, il est impossible de se connecter à distance au serveur, pour cela il faut implanter le package ssh ( telnet est à proscrire ) par la commande aptitude.

sudo aptitude install ssh

Il importe de configurer correctement ssh en éditant le fichier /etc/ssh/sshd_config et en y placant l'adresse IP réelle du serveur dans la clause ListenAddress :

sudo vi /etc/ssh/sshd_config

# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
ListenAddress 192.168.1.100
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
...

Une fois le fichier sauvegardé, redemarrer ssh

sudo /etc/init.d/ssh restart

Le serveur est alors opérationnel.

Bien que pleinement fonctionnel, il est utile de mettre en place différents packages afin d'utiliser au mieux le serveur.

sudo aptitude install lshw vim postfix ntpdate

Par défaut Debian utilise le serveur de messagerie Exim, je lui préfère Postfix. Accepter les options par défaut demandées par debconf, l'objectif est uniquement d'avoir un serveur de messagerie local.

Le package vim permet d'obtenir toutes les fonctions de l'éditeur, en particulier la coloration syntaxique qui se paramètre dans le fichier /etc/vim/vimrc en decommantant la ligne suivante :

sudo vi /etc/vim/vimrc
   
...
" Vim5 and later versions support syntax highlighting. Uncommenting the next
" line enables syntax highlighting by default.
syntax on
...

Configurer vim comme éditeur par défaut.

Certaines commandes lancent automatiquement l'éditeur de texte, c'est le cas par exemple de visudo. Par contre par défaut ce n'est pas vim mais nano qui est utilisé. Personnellement, je trouve cela gênant. Tout ceci se paramètre via la commande update-alternatives. Afin donc de stipuler vim comme éditeur par défaut, utiliser les commandes suivantes :

sudo update-alternatives --config editor

Il y a 4 alternatives fournissant « editor ».

  
Sélection    Alternative
-----------------------------------------------
        1    /bin/ed
 *      2    /bin/nano
        3    /usr/bin/vim.tiny
        4    /usr/bin/vim.basic
 
Appuyez sur Entrée pour conserver la valeur par défaut[*] ou choisissez le numéro sélectionné :

Choisir 4 pour vim.

Le package lshw, permet d'obtenir une visualisation de la configuration matérielle du serveur.

  
erik@debian01:~$ sudo lshw -short

H/W path             Device      Class       Description
========================================================
                                 system      DIM4500
/0                               bus         D845EPT2
/0/1                             memory      64KiB BIOS
/0/5                             processor   Intel(R) Pentium(R) 4 CPU 2.00GHz
/0/5/6                           memory      8KiB L1 cache
/0/5/7                           memory      512KiB L2 cache
/0/1d                            memory      512MiB System Memory
/0/1d/0                          memory      DIMM DDR Synchronous 266 MHz (3.8 ns) [empty]
/0/1d/1                          memory      512MiB DIMM DDR Synchronous 266 MHz (3.8 ns)
/0/100                           bridge      82845 845 [Brookdale] Chipset Host Bridge
/0/100/1                         bridge      82845 845 [Brookdale] Chipset AGP Bridge
/0/100/1/0                       display     NV17 [GeForce4 MX 420]
/0/100/1d                        bus         82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1
/0/100/1d/1          usb1        bus         UHCI Host Controller
/0/100/1d.1                      bus         82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2
/0/100/1d.1/1        usb2        bus         UHCI Host Controller
/0/100/1d.1/1/1                  input       Basic Optical Mouse
/0/100/1d.1/1/2                  input       USB Multimedia Keyboard
/0/100/1d.2                      bus         82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3
/0/100/1d.2/1        usb3        bus         UHCI Host Controller
/0/100/1d.7                      bus         82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller
/0/100/1d.7/1        usb4        bus         EHCI Host Controller
/0/100/1e                        bridge      82801 PCI Bridge
/0/100/1e/0                      network     3Com Corporation
/0/100/1e/1          eth0        network     RTL-8139/8139C/8139C+
/0/100/1e/2                      network     88w8335 [Libertas] 802.11b/g Wireless
/0/100/1f                        bridge      82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge
/0/100/1f.1                      storage     82801DB (ICH4) IDE Controller
/0/100/1f.1/0        ide0        bus         IDE Channel 0
/0/100/1f.1/0/0      /dev/hda    disk        81GB Maxtor 6L080L0
/0/100/1f.1/0/0/1    /dev/hda1   volume      94MiB Linux filesystem partition
/0/100/1f.1/0/0/2    /dev/hda2   volume      972MiB Linux swap volume
/0/100/1f.1/0/0/3    /dev/hda3   volume      478MiB EXT3 volume
/0/100/1f.1/0/0/4    /dev/hda4   volume      74GiB Extended partition
/0/100/1f.1/0/0/4/5  /dev/hda5   volume      4769MiB Linux filesystem partition
/0/100/1f.1/0/0/4/6  /dev/hda6   volume      4769MiB Linux filesystem partition
/0/100/1f.1/0/0/4/7  /dev/hda7   volume      9538MiB Linux filesystem partition
/0/100/1f.1/0/0/4/8  /dev/hda8   volume      1906MiB Linux filesystem partition
/0/100/1f.1/0/0/4/9  /dev/hda9   volume      956MiB Linux filesystem partition
/0/100/1f.1/0/0/4/a  /dev/hda10  volume      53GiB Linux filesystem partition
/0/100/1f.1/1        ide1        bus         IDE Channel 1
/0/100/1f.1/1/1      /dev/hdd    disk        HL-DT-STDVD-ROM GDR8164B
/0/100/1f.3                      bus         82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller
/0/100/1f.5                      multimedia  82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller
erik@debian01:~$ 

Quand au package ntpdate, il permet une synchronisation horaire via le protocole ntp. Cette synchronisation est vitale sur un pproxy surtout si des plages horaires sont mises en place. Aussi il est bon de mettre dans le cron une ligne du type :

vi /etc/crontab

00 00 * * * root  ntpdate-debian

Chaque jour à minuit, le serveur sera synchronisé.

La commande aptitude est la commande à privilégier par rapport à apt-get, et ce depuis la version Sarge de Debian. Avec la sortie de Lenny, Debian déconseille apt-get. La syntaxe est identique entre les deux commandes pour les options communes. Aptitude gère de manière plus efficace les dépendances que apt-get, notamment en supprimant les paquets inutiles lors d'une désinstallation. Ne pas hésiter à consulter la page de référence aptitude sur le site Debian http://www.debian.org/doc/manuals/reference/ch-package.fr.html.

Il importe de rajouter un point crucial : Pour la version Lenny, la commande aptitude upgrade est obsolète et il faut maintenant utiliser : aptitude safe-upgrade.

Ci dessous un script standard de mise à jour de Debian.

#/bin/sh
aptitude update
aptitude safe-upgrade

Remarque : Il peut être tentant de mettre ce script dans le cron. A titre personnel je ne le fais plus, car j'aime contrôler les mises à jour. De plus la commande aptitude safe-upgrade demande parfois des réponses qui peuvent être automatiquement acceptées en passant l'option "-y". Cette pratique me semble dangereuse.

Pour plus d'information il est possible de consulter la page anglophone suivante : http://pthree.org/2007/08/12/aptitude-vs-apt-get/

Le Proxy Squid est un serveur mandataire qui sert, entre autres, à créer un cache d'URLs de façon à ce que celles les plus sollicitées par les navigateurs à l'intérieur du réseau local soient téléchargées une seule fois et réutilisées par les autres. Il permet aussi de définir des droit d'accès aux différents utilisateurs du réseau selon des règles définit dans des ACL (Access Control List). Les principaux fonctionnalités du proxy sont :

• La journalisation des requêtes (« logging »).
• Le cache.
• La sécurité du réseau local.
• Le filtrage et l'anonymat.

La mise en place d'un serveur proxy ou mandataire HTTP présente de nombreux avantages, aussi bien en termes de sécurité que de contrôle parental, surtout dans le cadre d'établissements qui offrent à des mineurs la possibilité d'accès à l'internet (écoles, collèges, lycées, associations diverses…).

Nous utiliserons Squid pour le proxy HTTP et SquidGuard pour l'élément de filtrage. Si une mise en place minimum de Squid ne présente guère de difficultés, l'insertion de SquidGuard reste tout de même plus délicate et mérite que l'on y passe un peu de temps.

Transparent ou pas ? Nous verrons les avantages et inconvénients de chacune des méthodes.

Identifier les utilisateurs ou se contenter de contrôler les accès de façon anonyme ? Nous envisagerons les deux possibilités.

Bien que Debian soit utilisée ici, rien n'interdit de le transposer à une autre distribution, sous réserve d'utiliser des paquetages de bases de données Berkeley compatibles avec le fonctionnement de SquidGuard.

Un petit rappel sur les modes d'inter-connexion réseaux est utile. La question de base est :

Comment permettre aux hôtes d'un réseau d'accéder aux hôtes d'un autre réseau ?

Au départ, nous disposons de deux réseaux physiques, construits avec des hubs. Il suffit de placer un câble, entre les deux. Cette solution simple inter-connecte au niveau le plus bas (couche physique), avec quelques contraintes et inconvénients :

• Les trames émises par les nœuds de chaque réseau initial sont propagées sur l'autre réseau (en fait, il n'y a plus qu'un seul réseau physique) et le risque est grand de voir s'écrouler rapidement les performances du réseau ;
• Du fait que nous sommes sur le même réseau physique, le réseau IP doit être également le même.

Cette solution revient en fait à ajouter de nouveaux hôtes sur un réseau déjà existant.

La même chose, mais avec un dispositif un peu plus intelligent qu'un simple bout de fil, puisque le pont évitera la propagation des trames qui ne concernent pas un hôte de l'autre réseau. L'interconnexion se fait ici au niveau 2. Au niveau IP, les contraintes restent les mêmes, nous sommes partout dans le même réseau IP.

Cette solution est aujourd'hui complètement généralisée, puisque les switches ne sont rien d'autre que des ponts multivoies et donc, tirer un bout de câble entre deux switches revient à la solution du pont.

Ici, nous inter-connectons au niveau 3 (IP). Les deux réseaux disposent chacun de leur propre plan d'adressage IP. Les possibilités de contrôle d'accès d'un réseau à l'autre sont bien plus fines (filtrage de paquets genre Netfilter/IPtables).

Nous travaillons ici au niveau du protocole d'application (HTTP pour ce qui nous concerne ici). Il existe deux types de serveurs mandataires :

• Le proxy normal, qui nécessite que l'application cliente sache que le proxy existe et sache aussi travailler avec. En effet, dans ce cas, le client envoie ses requêtes au serveur mandataire, à charge pour lui d'aller chercher plus loin l'information réclamée par le client et de la lui transmettre, une fois l'information obtenue. Les clients HTTP (navigateurs) modernes savent tous le faire. C'est en revanche très rarement le cas pour d'autres protocoles comme POP, FTP, …
• Le proxy transparent, qui agit dans la totale ignorance du client. Dans cette situation, le client croit s'adresser directement à la cible finale, mais la requête est interceptée et traitée par le mandataire. Cette solution, nécessaire le plus souvent pour des protocoles comme POP ou FTP où les clients ne savent pas utiliser de proxy, n'est pas obligatoire pour HTTP. Nous aurons l'occasion de rediscuter de ce choix.

Dans l'illustration, les hôtes du réseau de gauche accèderont aux informations fournies par les serveurs HTTP du réseau de droite via le serveur mandataire qui est dans leur réseau. Nous reviendrons plus loin sur cette architecture qui peut sembler peu évidente au premier regard.

Installer un système de proxy cache pour HTTP. Ce proxy-cache propose deux fonctions principales :

• L'optimisation de la bande passante sur le lien Internet, lorsque de nombreux clients sont connectés et qu'ils visitent plus ou moins les mêmes sites, à la condition, bien sûr, que ces sites ne soient pas trop dynamiques, ASP, JSP, PHP… ni chiffrés (HTTPS). Comme vous le constatez, la fonction cache présente de moins en moins d'intérêt. Il en reste un cependant, surtout pour les illustrations qui ne sont pas encore toutes en flash,
• Le contrôle et le filtrage de l'accès à la toile, en se servant des URI et, éventuellement, des noms d'utilisateurs, si l'on fait de l'authentification de ces derniers, autant de choses qu'il est difficile, voire impossible de faire avec du filtrage de paquets. En effet, en travaillant au niveau du protocole HTTP, il devient possible de mettre en place des filtres d'URI, des analyses de contenu dans les documents, alors qu'au niveau IP, nous ne pourrions filtrer que sur des adresses et des ports.

Tout responsable d'un réseau local à l'usage de mineurs et connecté à l'Internet se doit de mettre en place un tel système de filtrage de manière à éviter, autant que possible, l'accès à des sites que la morale réprouve, d'autant qu'il s'agit d'une obligation légale.

Direct
	Un navigateur HTTP interroge directement le serveur cible et il reçoit directement les réponses de ce dernier. Il n'y a pas de filtrage possible, autrement que sur les adresses IP des serveurs cible.
Normal
	Le client demande au proxy d'interroger le serveur cible. Ce dernier répond au proxy qui communique alors la réponse au client. Dans ce mode, le client est configuré pour utiliser un proxy et il modifie les requêtes http en fonction.
Transparent
	Le client ignore l'existence du proxy. Il croit envoyer ses requêtes directement au serveur cible, mais ses requêtes sont détournées vers le proxy par le routeur. Le serveur cible répond au proxy qui retransmet la réponse au client, mais ce dernier croit l'avoir reçue directement du serveur cible.

Nous discuterons plus loin dans ce document de l'intérêt comparé des deux façons d'utiliser notre proxy.

Squid, principal composant de ce système, assure les fonctions de :

• Cache, pour optimiser la bande passante,
• Identification des utilisateurs, nous en verrons une simpliste et une nettement plus complexe,
• Filtrage d'accès basique, mais déjà intéressant.

SquidGuard propose un filtrage très puissant d'accès au web, en fonction :

• De groupes d'utilisateurs, définis de diverses manières. Ici, nous nous baserons sur des IPs ou des groupes d'IPs, mais il est possible d'utiliser l'identification des utilisateurs mise en place sur Squid,
• De listes de domaines et d'URI qui serviront à définir soit des cibles autorisées, soit des cibles interdites (listes blanches, listes noires),
• De plages horaires pendant lesquelles l'accès sera autorisé ou interdit

Et bien d'autres choses encore, que nous ne verrons pas ici.

Squid tourne en tâche de fond (daemon). Il écoute sur un port spécifique (3128 par défaut, mais il est possible d'utiliser 8080, plus habituel pour un proxy HTTP). L'éventuel module d'identification vient se greffer dessus, ce qui fait apparaitre un certain nombre de processus fils (5 par défaut).

SquidGuard vient également se greffer dessus et apparait lui aussi sous la forme de processus fils (également 5 par défaut).

Au total, une fois Squid configuré, il n'y aura qu'à démarrer Squid et les processus d'identification et de filtrage avancé démarreront avec.

SquidGuard utilise le format de bases de données Berkeley pour travailler. Berkeley DB (BDB) est une base de données embarquée, ce qui rend son déploiement et son administration aisés. La base n'est composée que d'enregistrements dont le format est librement déterminé par le programme appelant. Il n'y a pas de notion de table, et la base n'est pas interrogeable via un langage de manipulation de données comme par exemple SQL. Chaque enregistrement est composé d'une paire clé / valeur, la clé n'étant pas unique.

Pour définir ces bases, l'administrateur a recours à des fichiers au format texte qui seront pré compilés en base de données ou compilés à la volée, suivant la façon de travailler.

Berkeley DB est utilisée aussi par le SMTP Postfix. Depuis 2006, ce produit est la propriété de Oracle.

Nous verrons que les « destination groups » constituent des bases pré compilées, alors que les « blacklists » sont compilées à la volée et résident uniquement en mémoire. Ce principe est a éviter autant que possible, dans la mesure où il consomme énormément de ressources au démarrage de chaque instance de SquidGuard.

Il n'existe pas vraiment d'interface graphique satisfaisante pour administrer Squid. Il faudra donc utiliser directement les fichiers de configuration. Il faut faire très attention à ce que l'on fait et vérifier chaque fois que nécessaire que le but recherché est atteint. SquidGuard réserve pas mal de mauvaises surprises à ce propos.

Dans le cas de SquidGuard principalement, une gestion fine des bases de données pour les groupes de destination et les blacklists ne pourra se faire qu'à partir de la ligne de commande. Nous ne ferons qu'effleurer le problème, si vous en arrivez là, c'est que vous êtes déjà assez pointus sur le sujet pour pouvoir vous débrouiller tout seul avec la documentation (pauvre et laconique, il faut bien le dire).

Cette question, qui semble venir comme un cheveu sur la soupe, est tout de même l'une des premières questions à se poser, lorsque l'on désire mettre en place un serveur proxy comme Squid :

• Sur https, les échanges sont chiffrés et ne peuvent être mis en cache. Utiliser Squid pour ses fonctions de cache n'offre ici aucun intérêt,
• https authentifie au moins le serveur interrogé, de manière à ce que le client soit « sûr » qu'il s'adresse au serveur réellement choisi. Qu'advient-t-il de cette certitude, si la connexion passe par un intermédiaire ?

Lorsque nous utilisons un serveur proxy de façon « volontaire » (par le paramétrage de notre navigateur), nous savons que ce paramétrage modifie le comportement dudit navigateur, qui va alors envoyer toutes ses requêtes sur le proxy (voir le chapitre sur HTTP). Dans une telle situation, si le client peut authentifier le serveur proxy, sa connexion https peut à la rigueur encore être considérée comme fiable. Dans ce cadre, Squid peut assumer cette fonction. Mais dans le cas du passage par un proxy « involontaire » (proxy transparent), le client ne sait pas qu'il passe par un tel dispositif, son navigateur n'est pas paramétré pour s'adresser à un serveur proxy, le trafic est dérouté de façon « transparente ». Dans une telle situation, la démarche deviendrait malhonnête, à supposer qu'il soit possible de le faire de façon fonctionnelle.

Nous partons d'une Debian Lenny de base, seul ssh est configuré. Au niveau du matériel, un PII 300 MHz, 256 Mo de RAM et 20 G0 de disque dur devraient largement suffire pour un réseau d'une centaine de postes.

L'installation proprement dite est des plus simple :

aptitude install squid3

Par défaut squid est lancé avec un user proxy dédié et écoute sur le port 3128.

adi153:~# netstat -ltaupen
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat        User       Inode       PID/Program name
tcp        0      0 91.121.7.88:22          0.0.0.0:*               LISTEN      0          8057        5261/sshd       
tcp        0      0 0.0.0.0:3128            0.0.0.0:*               LISTEN      0          10811403    609/(squid)     
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      0          8286        5342/master     
tcp        0     48 91.121.7.88:22          86.195.24.174:46317     ESTABLISHED 0          10805717    480/0           
udp        0      0 0.0.0.0:3130            0.0.0.0:*                           0          10811404    609/(squid)     
udp        0      0 0.0.0.0:48612           0.0.0.0:*                           13         10811387    609/(squid)     
adi153:~# ps aux|grep proxy
proxy      609  0.2  7.6  35508 18624 ?        S    18:00   0:00 (squid) -D -YC
proxy      612  0.0  0.3   2964   964 ?        Ss   18:00   0:00 (unlinkd)
root       778  0.0  0.3   3500   740 pts/0    R+   18:01   0:00 grep proxy
adi153:~# 

Les ACL (Access Control Lists) permettent de définir des conditions sur les IPs, les ports, le contenu de certains textes, … Si vous voulez tout savoir sur les diverses ACL de Squid, consultez la documentation officielle.

Le fichier de configuration est /etc/squid3/squid.conf. Il est copieusement commenté et je vous propose cette petite manipulation qui retire toutes les lignes blanches et les commentaires afin d'obtenir un vrai fichier de configuration :

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

Une fois épuré le fichier se présente ainsi :

acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443
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 CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny all
icp_access deny all
htcp_access deny all
http_port 3128
hierarchy_stoplist cgi-bin ?
access_log /var/log/squid3/access.log squid
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern (cgi-bin|\?)    0       0%      0
refresh_pattern .               0       20%     4320
icp_port 3130
coredump_dir /var/spool/squid3

Dans un premier temps, disons pour aller très vite au but, que :

• les « acl » (Access Control List) permettent de définir, par exemple, un plage d'adresses IP, celles qui constituent notre réseau local ;
• les « http_access » (restrictions) qui définissent l'autorisation ou l'interdit, pour une acl donnée.

Les restrictions indiquent quoi faire lorsque ces conditions sont vérifiées. On autorise ou on interdit en fonction d'une ACL ou d'un groupe d'ACLs, le sens de « restriction » est donc à prendre avec un peu de recul, une restriction pouvant être une autorisation. La première restriction vérifiée est la bonne, d'où l'importance de l'ordre dans lequel elles sont placées.

Sans faire une analyse détaillée, nous voyons que dans la configuration par défaut, seul « localhost » peut utiliser le proxy (Allow localhost). Si cette condition n'est pas respectée, la règle suivante étant deny all, personne ne passe. Il nous faut donc faire intervenir la notion de réseau local.

Bien entendu, l'idée de faire plutôt Allow all est une mauvaise idée. Si votre proxy a un pied dans l'Internet (s'il est installé sur la passerelle), vous risquez un proxy ouvert, avec tous les usages pervertis que l'on peut en faire. Modifions le fichier squid.conf de cette manière :

acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443
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 CONNECT method CONNECT
acl reseau_local src 192.168.0.0/24
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access allow reseau_local
http_access deny all
icp_access deny all
htcp_access deny all 
http_port 3128
hierarchy_stoplist cgi-bin ?
access_log /var/log/squid3/access.log squid
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern (cgi-bin|\?)    0       0%      0
refresh_pattern .               0       20%     4320
icp_port 3130
coredump_dir /var/spool/squid3

Nous avons créé une ACL nommée reseau_local représentant notre réseau local acl reseau_local src 192.168.0.0/24, et lui avons donné l'autorisation de passer le proxy http_access allow reseau_local. Nous relançons squid :

# /etc/init.d/squid3 reload
Reloading Squid HTTP Proxy 3.0 configuration files.
done.

Il s'agit de l'unique manipulation pour disposer d'un proxy cache en état de marche pour un réseau local.

• Mettre les postes autorisés en IP fixe, par exemple de 192.168.0.10 à 192.168.0.20.
• Puis déclarer l'acl ainsi : acl reseau_local src 192.168.0.10-192.168.0.20
• Mettre les autres postes en DHCP hors plage autorisée. Ainsi seules les IP fixes accèdent au web.

Il y a deux points importants, qu'il peut être utile d'étudier, et qui correspondent aux deux fonctions principales d'un proxy.

Attention. Vous aurez des ennuis pour identifier vos utilisateurs, si vous comptez rendre votre proxy transparent. Les deux fonctionnalités sont incompatibles.

Dans la configuration mise en œuvre jusqu'ici, nous ne faisions pas de contrôle sur les utilisateurs, seulement sur les IPs des machines clientes. Vous pouvez souhaiter identifier vos utilisateurs lorsqu'ils vont surfer sur le Net. Dans ce cas, il vous faudra mettre en place un système d'identification et renoncer au mode transparent.

Il y a plusieurs méthodes disponibles pour authentifier les utilisateurs du proxy. Elles font toutes appel à un programme extérieur, différent suivant le moyen choisi. Debian propose les modules suivants :

squid_ldap_auth, msnt_auth, ncsa_auth, pam_auth, sasl_auth, smb_auth, yp_auth, getpwname_auth, ntlm_auth, digest_ldap_auth, digest_pw_auth…

Nous verrons la méthode la plus simple via ncsa_auth qui permet d'identifier les utilisateurs à partir d'un fichier local de type htpasswd. Pour cela il est nécessaire d'implanter le package apache2.2-common afin d'obtenir la commande htpasswd.

aptitude install apache2.2-common

Nous allons créer un fichier /etc/squid/users

touch /etc/squid3/users

Nous le remplissons ensuite avec la commande htpasswd, normalement fournie dans le paquet apache-common.

htpasswd -b /etc/squid3/users <nom de l'utilisateur>  <mot de passe>

Dans l'exemple, nous allons créer 3 users/mot de passe ainsi

htpasswd -b /etc/squid3/users user1 azerty
Adding password for user user1
htpasswd -b /etc/squid3/users user2 uiopqs
Adding password for user user2
htpasswd -b /etc/squid3/users user3 dfghjk
Adding password for user user3

Le fichier se remplit comme suit :

cat /etc/squid3/users 
user1:bHKXpuog9KolY
user2:o5ThIE493nPco
user3:unLsXCc4AC.tc

Les mots de passe sont chiffrés. Vérifions le fonctionnement, en lançant à la main le module d'authentification /usr/lib/ncsa_auth. Nous entrerons alors dans une boucle où il faudra entrer sur une ligne un nom d'utilisateur et son mot de passe, séparés par une espace :

/usr/lib/squid3/ncsa_auth /etc/squid3/users
user1 azerty
OK
user2 azerty
ERR Wrong password
user2 uiopqs
OK
user3 dfghjk
OK
user4 lmwxcv
ERR No such user

Le système répond par OK ou par ERR suivant que l'authentification réussit ou non. Sortez de la boucle avec un ctrl-d.

Nous devons commencer par fournir quelques directives de type auth_param qui sont à rajouter au début du fichier /etc/squid3/squid.conf:

auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/users
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours

• program, indiquez le chemin du module ncsa_auth, suivi du chemin du fichier des utilisateurs, séparés par une espace.
• children, 5 est une valeur usuelle. Si vous avez de nombreux utilisateurs, il sera peut-être nécessaire d'augmenter ce nombre.
• realm, n'est rien d'autre qu'un texte qui apparaîtra dans la fenêtre de demande d'identification.
• credentialsttl, durée de vie de l'identification. A condition bien sûr que le navigateur ne soit pas fermé avant.

Il nous faut maintenant créer une “acl” supplémentaire, pour obliger l'identification,

acl users proxy_auth REQUIRED

Puis n'autoriser l'accès que si le client est dans notre réseau et que l'identification est réussie :

http_access allow reseau_local users

Ceci nous conduit à un fichier de configuration de la forme :

auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/users
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443
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 CONNECT method CONNECT
acl reseau_local src 192.168.0.0/24
acl users proxy_auth REQUIRED
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access allow reseau_local users
http_access deny all
icp_access allow all
http_port 3128
hierarchy_stoplist cgi-bin ?
access_log /var/log/squid3/access.log squid
acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY
refresh_pattern ^ftp:		1440	20%	10080
refresh_pattern ^gopher:	1440	0%	1440
refresh_pattern .		0	20%	4320
icp_port 3130
coredump_dir /var/spool/squid3

Application des changements, nous vérifions que maintenant le module d'authentification est bien chargé :

/etc/init.d/squid3 reload

ps aux|grep proxy
proxy      609  0.0  7.9  36320 19384 ?        R    18:00   0:00 (squid) -D -YC
proxy      612  0.0  0.3   2964   964 ?        Ss   18:00   0:00 (unlinkd)
proxy     2380  0.0  0.2   2172   532 ?        Ss   18:24   0:00 (ncsa_auth) /etc/squid3/users
proxy     2381  0.0  0.2   2172   532 ?        Ss   18:24   0:00 (ncsa_auth) /etc/squid3/users
proxy     2382  0.0  0.2   2172   528 ?        Ss   18:24   0:00 (ncsa_auth) /etc/squid3/users
proxy     2383  0.0  0.2   2172   532 ?        Ss   18:24   0:00 (ncsa_auth) /etc/squid3/users
proxy     2384  0.0  0.2   2172   528 ?        Ss   18:24   0:00 (ncsa_auth) /etc/squid3/users
root      2386  0.0  0.3   3500   740 pts/0    R+   18:24   0:00 grep proxy

Cette fois-ci, il y est. Ca devrait donc fonctionner.

Pour accéder au monde extérieur, Squid nécessite maintenant une identification. Si nous allons faire un petit tour dans les dernières lignes de /var/log/squid/access.log, nous constatons que le nom d'utilisateur figure pour chaque requête :

Un proxy sert à optimiser la bande passante utilisée sur le Net, en permettant de garder en cache les pages les plus souvent visitées. Si c'est une de vos principales préoccupations, il sera probablement nécessaire d'agir sur les diverses options du cache. Passez alors du temps à lire la documentation. Vous pourrez agir sur la taille du cache, sa répartition sur les divers disques durs…

Pour réaliser correctement une telle opération, il vous faudra installer d'abord des outils d'audit de performance dudit cache. Détailler ces opération ici nous mènerait trop loin.

Attention !!!

• Cette méthode est incompatible avec l'authentification des utilisateurs. Même si squid est configuré comme nous l'avons vu pour l'authentification ncsa, celle-ci ne fonctionnera plus.
• Cette méthode ne supporte que HTTP. FTP est impossible en mode transparent,
• Un seul port peut être redirigé de façon transparente, le 80, de préférence, puisque c'est le port habituel pour HTTP.

Utiliser un proxy nécessite normalement de configurer son navigateur de manière à ce qu'il interroge toujours le proxy, quelle que soit la cible.

Vos utilisateurs ont donc généralement la main sur ce paramétrage, et pourront probablement passer outre le proxy, s'ils le décident, contournant par le fait toutes vos stratégies. Il existe cependant deux moyens d'éviter ceci :

• Utilisez votre firewall pour bloquer pour vos postes clients l'accès direct à l'Internet par les ports http et https (80, 443, 563…). De cette manière, vos utilisateurs n'auront d'autre possibilité que de passer par le proxy (sauf pour des serveurs exotiques, qui utiliseraient un autre port), c'est la seule manière possible si vous souhaitez identifier vos utilisateurs ;
• Rendre le proxy transparent, ce qui veut dire que configurés ou non, les requêtes http passeront quand même par le proxy. Pour arriver à ce résultat, il faut réaliser deux opérations :
• Rediriger en PREROUTING le port 80 (vous devrez vous contenter d'un seul port transparent) vers le port proxy sur son port (3128 par défaut pour squid), ça se fait sans problèmes sur votre routeur NAT avec IPtables,
• Configurer correctement squid pour qu'il interprète convenablement les requêtes HTTP qu'il reçoit.

Voici la règle à ajouter sur votre passerelle, en admettant que votre réseau est dans 192.168.0.0 et que votre proxy possède l'adresse 192.168.0.252. Nous supposons que le proxy est installé sur la machine qui assure également le rôle de passerelle (commande à entrer sur une seule ligne, bien entendu) :

iptables -t nat -A PREROUTING -s 192.168.0.0/255.255.255.0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128

Avec un routeur à trois voies, par exemple deux réseaux IP (disons 192.168.0.0 et 192.168.1.0), et un accès Internet, si le LAN est sur 192.168.0.0, il faudra placer le proxy sur 192.168.1.0, disons 192.168.1.2. La règle IPtables s'écrira alors :

iptables -t nat -A PREROUTING -s 192.168.0.0/255.255.255.0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.2:3128

Bien entendu, il faudra que le routage se fasse entre les réseaux 192.168.0.0 et 192.168.1.0.

Comme nous l'avons vu dans le chapitre sur HTTP, Le client HTTP n'agit pas de la même manière suivant qu'il a affaire à un proxy ou non. Ici, le client ne sait pas qu'il y a un proxy, il agit donc comme s'il interrogeait directement le serveur cible, alors que ce n'est pas le cas. Ca ne fonctionnera bien entendu pas, si Squid n'est pas informé de cette situation.

Mais Squid sait contourner la difficulté, de façon très simple depuis la version 2.6 au moins, en ajoutant simplement le mot « transparent » sur la ligne de définition du port utilisé :

http_port 3128 transparent

Comme nous l'avons vu, la transparence du proxy entraîne de nombreuses restrictions. A moins que vous y teniez absolument, mieux vaut choisir une autre solution, principalement si vous voulez cacher le FTP et/ou faire passer le HTTPS par votre proxy (il n'y aura pas d'effet de cache, juste un transfert des données comme dans un tunnel) ou encore, si vous devez identifier vos utilisateurs.

Dans la suite de cet exposé, squid ne sera pas transparent.

Pour ce qui est du filtrage d'accès, il est possible de faire déjà des choses avec Squid tout seul, mais le « helper » SquidGuard que nous allons voir dans la suite rend inutiles les tentatives de filtrage avec les seuls moyens de Squid.

Il faut intégrer le serveur proxy dans un domaine AD, pour cela il faut donc disposer des utilitaires clients Kerberos 5, samba 3 et winbind. Installer les packages suivants :

aptitude install  krb5-user krb5-config samba-common samba winbind

Modifier le fichier /etc/krb5.conf

[libdefaults]
        default_realm = ADIMCOR.EU
        dns_lookup_realm = false
        dns_lookup_kdc = false

[realms]
ADIMCOR.EU = {
         kdc = 192.168.0.1
         kdc = 192.168.0.2
        admin_server = 192.168.0.1
        default_domain = ADIMCOR.EU
}

[domain_realm]
        .adimcor.eu = ADIMCOR.EU
        adimcor.eu = ADIMCOR.EU

[logging]
        default = FILE:/var/log/krb5.log
        kdc = FILE:/var/log/krb5kdc.log
        admin-server = FILE:/var/log/krb5adm.log

[appdefaults]
        pam = {
                debug = false
                ticket_lifetime = 36000
                renew_lifetime = 36000
                forwardable = true
                krb4_convert = false
        }

• les adresses IP indiquées par kdc dans le paragraphe [realms] correspondent aux contrôleurs de domaine Microsoft,
• l'adresse IP indiquée par admin_server correspond au contrôleur « Maître d'opérations » avec les 5 rôles « FSMO ».

La commande « kinit » va permettre de vérifier que l'on peut obtenir un ticket kerberos pour un utilisateur du domaine ActiveDirectory :

# kinit -V user1@ADIMCOR.EU
Password for user1@ADIMCOR.EU: 
Authenticated to Kerberos v5

La commande « klist » permet de lister les tickets obtenus :

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: user1@ADIMCOR.EU

Valid starting     Expires            Service principal
10/29/09 10:36:18  10/29/07 20:36:22  krbtgt/ADIMCOR.EU@ADIMCOR.EU
        renew until 10/29/09 20:36:18

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

user1@adimcor.eu a bien été authentifié et le ticket kerberos a bien été reçu.

Modifier le fichier /etc/samba/smb.conf

[global]
workgroup = ADIMCOR
realm = ADIMCOR.EU
security = ADS
password server = 192.168.0.1 192.168.0.2
client use spnego = yes 
client ntlmv2 auth = yes
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
announce version = 4
announce as = Poste XP
dns proxy = No
idmap uid = 167771-335549
idmap gid = 167771-335549
winbind use default domain = Yes
invalid users = root

• Le workgroup correspond au nom « plat » du domaine Microsoft,
• Le realm correspond au royaume Kerberos,
• La security = ADS (Active Directory Server) nécessite que la machine soit intégrée au domaine Microsoft et que le client kerberos soit installé et configuré, ce qui permettra d'utiliser ce protocole pour l'authentification des clients,
• Les password server sont bien entendu les contrôleurs de domaine Microsoft.

Voir la configuration Samba pour les autres paramètres.

Modifiez comme suit le fichier « /etc/nsswitch.conf » :

passwd:         compat winbind
group:          compat winbind
shadow:         compat
hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files

rpc:            db files

netgroup:       nis

Relancez winbind et samba:

# /etc/init.d/winbind restart
Stopping the Winbind daemon: winbind.
Starting the Winbind daemon: winbind.

# /etc/init.d/samba restart
Stopping Samba daemons: nmbd smbd.
Starting Samba daemons: nmbd smbd.

net ads join -U <un login d'Administrateur du domaine> -S <adresse d'un contrôleur de domaine>

En principe, un message doit vous annoncer que l'opération s'est bien déroulée et vous devriez retrouver votre proxy dans les « computers » dans votre mmc de gestion de « Active Directory Users and Computers »

Modifier le fichier /etc/squid3/squid.conf en remplacant les lignes auth basic par :

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 5
auth_param ntlm keep_alive on

Puis créer une acl

acl motdepasse proxy_auth REQUIRED

Et lui donner le droit d'accès

http_access allow motdepasse

Au final le fichier /etc/squid3/squid.conf doit être similaire au modèle ci-dessous.

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 5
auth_param ntlm keep_alive on
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443
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 CONNECT method CONNECT
acl reseau_local src 192.168.0.0/24
acl motdepasse proxy_auth REQUIRED
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access allow reseau_local 
http_access allow motdepasse
http_access deny all
icp_access allow all
http_port 3128
hierarchy_stoplist cgi-bin ?
access_log /var/log/squid3/access.log squid
acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY
refresh_pattern ^ftp:		1440	20%	10080
refresh_pattern ^gopher:	1440	0%	1440
refresh_pattern .		0	20%	4320
icp_port 3130
coredump_dir /var/spool/squid3

SquidGuard est un complément à Squid permettant de gérer finement des listes de contrôle d'accès selon différents critères ( URL, expressions clefs, plages horaires… )

Comme toujours sous Debian :

aptitude install squidguard

Attention squidguard positionne par défaut son fichier de configuration sous /etc/squid et non /etc/squid3. Ce n'est pas dans la suite une erreur de frappe. Ceci peut être modifié.

Seule la machine de l'admin pourra aller n'importe où, tous les autres hôtes du réseau resteront bloqués :

dbhome /var/lib/squidguard/db
logdir /var/log/squid3
  
src admin {
        ip              192.168.0.10
}

acl {
        admin {
                pass     any
        }

        default {
                pass      none
                redirect http://127.0.0.1/proxy.html
        }
}

La page web proxy.html est à créer afin d'afficher un avertissement.

Enfin, il faut configurer squid3 pour qu'il invoque squidGuard en ajoutant ces lignes à la fin de /etc/squid3/squid.conf :

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

Et demander à squid de recharger sa configuration :

/etc/init.d/squid3 reload

Un ensemble de destinations est activement maintenu par le Centre de Ressources Informatiques de l'Université de Toulouse. Le plus simple est de charger le fichier complet et de le mettre en place sous /var/lib/squidguard/db.

cd /var/lib/squidguard/db/
wget ftp://ftp.univ-tlse1.fr/blacklist/blacklists.tar.gz
tar xzf blacklists.tar.gz
cd blacklists

Affecter les bons droits au contenu de /var/lib/squidguard/db/blacklists qui doit être accessible en lecture et en écriture par l'utilisateur sous l'identité duquel squid tourne en l'occurrence proxy.

cd /var/lib/squidguard/db/
chown -R proxy:proxy blacklists

Nous devons maintenant créer un fichier de configuration pour squidGuard, qui tienne compte de quelques unes de ces destinations.

Dans squidGuard.conf, nous allons tenir compte du sous répertoire porn :

dest pornographie {
        urllist         porn/urls
        domainlist      porn/domains
}

Le fichier de configuration doit donc maintenant ressembler à ceci :

dbhome /var/lib/squidguard/db/blacklists
logdir /var/log/squid3
  
src admin {
        ip              192.168.0.10
}
src users {
        ip              192.168.0.0/24
}
dest pornographie {
        urllist         porn/urls
        domainlist      porn/domains
}

acl {
        admin {
                pass     any
        }
        users {
                pass !pornographie  any
                redirect http://127.0.0.1/proxy.html
        }
        default {
                pass      none
                redirect http://127.0.0.1/proxy.html
        }
}

La dernière étape consiste à compiler les bases de données blacklists au format Berkeley. Très important, cette compilation doit se fait sous l'identité du user squid en l'occurrence proxy.

su proxy
squidGuard -C all

Vérifier la compilation par la commande suivante :

tail -f /var/log/squid/squidGuard.log

En fin de fichier doit se trouver une ligne type :

...
2009-10-30 13:15:45 [6815] db update done
...

La phase logique qui suit l’authentification des utilisateurs reste celle de l’exploitation des logs générés par le serveur Squid. Vous pouvez, à tout instant, consulter manuellement ces derniers dans le fichier access.log qui se trouve habituellement dans le répertoire /var/log/squid3 (paramétrable dans le fichier squid.conf).

Vous noterez que, selon votre distribution Linux, vous utilisez peut-être sans le savoir le programme logrotate afin de purger vos fichiers de logs. Dans ce cas, vérifiez que le champ size du fichier /etc/logrotate.d/squid3 est suffisamment important pour ne pas perdre d’informations (adaptez-le à la fréquence d’analyse de vos logs).

Par contre, il semble plutôt impossible d’exploiter directement ce fichier tant le volume de données à traiter peut rapidement excéder celui de la capacité d’analyse normale d’un être humain.

Heureusement, plusieurs logiciels existent qui excellent dans ce travail de synthèse : Calamaris, Webalizer, Squid-Log-Analzer, SARG,…Nous allons, pour notre part, vous proposer d’utiliser le logiciel SARG.

L'installation sous Debian est simple :

aptitude install sarg

Vous devez ensuite configurer SARG en éditant le fichier /etc/squid/sarg.conf et en modifiant les deux premières directives.

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

Il vous sera alors possible de trier les accès selon les critères suivants :

• Liste des cent sites les plus visités avec la bande passante utilisée et le nombre d’accès ;
• Liste de tous les sites visités avec le nom des utilisateurs ;
• Liste des utilisateurs triés sur le critère de la bande passante utilisée ;

Par utilisateur :

• La liste des sites visités par ordre d’importance (nombre d’accès ainsi que la date et l’heure des visites) ;
• Un planning des connexions pour balayer d’un seul coup d’œil la charge par utilisateur ;
• Par site, la date et l’heure de tous les accès ;
• La liste des connexions échouées (utile pour localiser les logiciels espion).

Sauf besoin ponctuel, il est préférable d’automatiser la génération de ces informations en plaçant l’appel à la commande sarg dans la crontab du système. Exemple d’utilisation en ligne de commande :

/usr/bin/sarg -n -o /home/squid3/logs/ -i

Il suffit ensuite de configurer un serveur web pour utiliser ce résultat.