But recherché

Cet article a pour but de vous aider dans la mise en place d’un serveur proxy cache avec authentification des utilisateurs (pour des contraintes légales notamment) ainsi que la mise en place d’un système de filtrage souple et facilement configurable.
Pour cet article, nous nous baserons sur une authentification réalisée au travers d’un serveur Samba. Notez toutefois que ce serveur servira uniquement à réaliser l’authentification des utilisateurs tentant d’accéder à l’internet.

Principe de fonctionnement du système

Le fonctionnement général se fera comme suit. Dans tout cet article, nous considérerons l’utilisateur Jean-Kevin, qui aura pour login ‘jean-kevin’ (oui, je fais dans l’originalité 😉
Jean-Kevin lance son navigateur favori pour aller regarder ses emails sur www.hotmail.com (bouh le vilain) Sa requête est transmise au serveur Squid qui effectue une première vérification :

  • la machine (envoyant la requête) fait-elle partie des sous réseaux autorisés ?
  • est-on dans la plage horaire autorisée ?

Si tout est correct, le serveur demande au navigateur de s’authentifier. Jean-Kevin est alors invité à entrer son login et son mot de passe dans la fenêtre de dialogue proposée. Les informations sont transmises au serveur qui les transmet au programme d’authentification (dans notre cas smb_auth, mais nous y reviendrons plus tard)
Deux cas sont possibles :

  • l’authentification échoue et Jean-Kevin (après moults essais infructueux) se voient redirigés vers une page lui indiquant qu’il doit s’authentifier pour accéder au net ;
  • l’authentification est un succès et la demande de Jean-Kevin passe désormais dans le filtre (squidGuard)
  • Là encore, diverses vérification sont effectuées :

    • plage horaire
    • adresse ip
    • login fourni

    Ensuite, on regarde les règles de filtrage mise en place pour savoir si la requête est autorisée ou non. Jean-Kevin se voit alors redirigé vers une page indiquant que la page demandée n’est pas accessible car interdite ou bien peut tranquillement surfer.
    Dans tous les cas, l’accès de Jean-Kevin aura été écrit dans les journaux du système.
    Installation
    Sur la plupart des distributions, il existe un paquet pour ces deux outils.
    Sous Ubuntu :

    	$ sudo apt-get install samba squid squidguard
    

    Sous Gentoo :

    	# emerge samba squid squidguard
    

    Configuration

    Samba

    Pour répondre à la question que certains se posent sans doute – pourquoi Samba et pas LDAP par exemple – j’ai choisi Samba car les postes clients sont tous sous Windows et qu’il n’est pas exclus un jour de mettre à disposition un espace de stockage sur le serveur (qui lui restera sous Linux) et que c’est la solution qui m’a paru la plus adaptée. C’est mon choix mais rien ne vous empêche de configurer un serveur LDAP si vous préférez cette méthode d’authentification (ou bien développez vous-même le programme d’authentification de votre choix 😉
    La première étape consiste à paramétrer le serveur samba pour permettre l’authentification des utilisateurs. Ci-dessous, un fichier de configuration minimale avec quelques commentaires :

    [global]
    	## le nom du groupe de travail
    	workgroup = MYDOMAIN
    	## le nom de votre serveur
    	server string = "SAMBA DOMAIN CONTROLER"
    	## nom des fichiers journaux, ici 'log.
    	log file = /var/log/samba/log.%m
    	## taille maximale des logs
    	max log size = 5000
    	## niveau d'information dans les journaux
    	log level = 3
    	## machines autorisées à se connecter au serveur samba
    	# seul le serveur peut se connecter réellement
    	hosts allow = 127.0.0.1 
    	security = user
    	## les mots de passe sont stockés en
    	crypté
    	encrypt passwords = yes
    	## indique si le serveur samba doit être considéré comme contrôleur
    	#  de domaine principal
    	#  (ici je considère que oui puisque le niveau maximum d'un "vrai" windows est de 32)
    	local master = yes
    	os level = 33
    	
    [NETLOGON]
    	comment = NETLOGON SHARE
    	## chemin vers le répertoire
    	partagé
    	path = /var/lib/samba/netlogon
    	## on interdit en écriture
    	writable = no
    	## on autorise le parcours du répertoire
    	browsable = yes
    	## on interdit l'accès anonyme (très important, sinon tout le monde peut
    	#  accéder au net)
    	guest ok = no
    

    Reste maintenant à créer le répertoire de partage NETLOGON. Cela va se faire très simplement :

    	# mkdir /var/lib/samba/netlogon
    	# chmod 755 /var/lib/samba/netlogon
    

    Nous allons maintenant créer un unique fichier dans ce répertoire. Ce fichier doit contenir uniquement la ligne ‘allow‘. Ce fichier doit impérativement s’appeler ‘proxyauth’ :

    	# echo allow > /var/lib/samba/netlogon/proxyauth
    	# chmod 644 /var/lib/samba/netlogon/proxyauth
    

    Lancez alors la commande magique :

    	# /etc/init.d/samba start
    

    Test d’authentification

    Nous allons à présent tester si l’authentification fonctionne. Pour cela, créons un compte pour notre ami Jean-Kevin (entrez le mot de passe de votre choix deux fois) :

    	# useradd -s /sbin/login jean-kevin
    	# smbpasswd -a jean-kevin
    	New SMB Password:
    	Retype new SMB password:
    	Added user jean-kevin
    

    Vérifions que le compte est bien créé :

    	# grep jean-kevin /etc/samba/smbpasswd
    	jean-kevin:6000:E4F30DF20DEAAD3B435B51404EE:5D220DB0B7F14AA12CC3E47F7CA7:[U          ]:LCT-90C6C926:
    

    C’est bon, le compte existe (si vous ne voyez pas une ligne telle que ci-dessus, il y a certainement eu une erreur ou alors votre fichier de mots de passe samba est ailleurs). Maintenant, testons si le programme smb_auth nous authentifie correctement :

    	# (echo jean-kevin <le mot de passe<) | /usr/lib/squid/smb_auth -U 127.0.0.1 -W MYDOMAIN
    	OK
    

    Si vous voyez ‘ERR’ et non ‘OK’, il y a un probl&egrav;me d’authentification. Vérifiez bien que vous avez correctement entré le mot de passe, au besoin le modifier avec la commande : smbpasswd jean-kevin.
    Pensez bien à mettre le nom du groupe que vous avez configuré dans le fichier smb.conf. Passons aux choses sérieuses et configurons notre serveur proxy !

    MySQL

    Ayant également à ma disposition une base de données MySQL sur laquelle sont stockées les informations des utilisateurs, j’ai également testé l’outil mysql_auth. Vous trouverez la dernière version de cet outil ici. Dans mon cas personnel, j’ai du modifier les sources afin de modifier la requête SQL qui réalise l’authentification, ainsi que le Makefile pour le répertoire d’installation. Mais voyons tout cela en détails.

    Compilation et installation

    Je me base sur la version 0.8 du projet. Placez-vous dans le répertoire de votre choix pour y décompacter l’archive que vous venez de télécharger. Nous allons dans un premier temps éditer le Makefile pour modifier le répertoire d’installation :

    	CC = gcc
    	CFLAGS = -I/usr/local/include -L/usr/local/lib
    	LDFLAGS = -lmysqlclient
    	SRC = src
    	OBJS = $(SRC)/mysql_auth.o $(SRC)/confparser.o $(SRC)/mypasswd.o
    	INSTALL = /usr/bin/install
    	CONF = $(SRC)/mysql_auth.conf
    	UID = proxy
    	GID = proxy
    	
    	all : mysql_auth mypasswd
    	
    	clean:
    		rm -rf src/*.o *.o mysql_auth mypasswd
    	
    	mysql_auth: $(OBJS)
    		$(CC) -o $@ $(SRC)/mysql_auth.c $(SRC)/confparser.c $(LDFLAGS) $(CFLAGS)
    	
    	mypasswd: $(OBJS)
    		$(CC) -o $@ $(SRC)/mypasswd.c $(SRC)/confparser.c $(LDFLAGS) $(CFLAGS)
    	
    	install:
    		$(INSTALL) -o ${UID} -g ${GID} -m 755 mysql_auth /usr/local/lib/squid/mysql_auth
    		$(INSTALL) -o ${UID} -g ${GID} -m 700 mypasswd /usr/local/lib/squid/mypasswd
    		$(INSTALL) -o ${UID} -g ${GID} -m 600 $(CONF) /usr/local/lib/squid/mysql_auth.conf
    

    Vous remarquerez l’utilisation de deux variables (UID et GID) pour la gestion des droits sur les fichiers installés (c’est plus pratique si vous avez besoin de le modifier) Le répertoire d’installation n’existe peut-être pas dans votre arborescence. Pensez à le créer :

    	$ sudo mkdir /usr/local/lib/squid
    

    Nous allons maintenant faire un petit tour dans le répertoire des sources. Tout d’abord, le programme utilise par défaut n’utilise pas le bon emplacement pour le fichier de configuration. Editez donc le fichier src/define.h comme suit :

    	/*
    	 * mysql_auth.conf - config file location and name
    	 * example: /usr/local/squid/etc/mysql_auth.conf
    	*/
    	#define CONFIG_FILE "/usr/local/lib/squid/mysql_auth.conf"
    	...
    

    Ensuite, vous pouvez suivre les instructions du site officiel pour installer la base de données d’authentification et configurer votre nouvel outil. Sinon, pour mon système, j’ai également du modifier le fichier mysql_auth.c de manière à modifier la requête d’authentification. La requête en question se trouve ligne 164. Il ne reste plus qu’à compilez :

    	$ make
    

    Avant de lancez l’installation (avec sudo make install), éditez le fichier de configuration.

    Configuration

    Tout d’abord, copiez le fichier de configuration original :

    	$ cp src/mysql_auth.conf src/mysql_auth.conf.default
    

    Le retour arrière sera ainsi plus facile. Vous aurez certainement à modifier les options :

    • user (nom d’utilisateur MySQL se connectant &agrav;e la base de données),
    • password (son mot de passe),
    • database (le nom de la base de données contenant les informations des comptes des utilisateurs),
    • mysqld_socket (la scoket d’&eacoute;coute pour la connexion à la base de données),
    • table, user_column et password_column (le nom de la table à interroger dans la base de données, la colonne contenant le login de l’utilisateur et la colonne contenant son mot de passe)

    Si vous utilisez la fonction password() de MySQL pour chiffrer les mots de passe contenu dans la base de données, positionnez également l’option encrypt_password_form à YES.

    Test d’authentification

    Il est maintenant temps de tester ! Ouvrez un shell et lancer la commande :

    	$ /usr/local/lib/squid/mysql_auth
    

    Si vous obtenez un message d’erreur ou bien si le programme termine avant que n’ayez pu taper quoique ce soit, jeter un oeil aux journaux système (dans /var/log/messages par défaut) pour connaître l’éventuelle erreur qui survient. Pour tester, entrez (sur la même ligne) un nom d’utilisateur et son mot de passe (non chiffré) et validez. Si tout fonctionne correctement, vous devez voir apparaître le mot OK sur la ligne suivante :

    	$ /usr/local/lib/squid/mysql_auth
    	jean-kevin monmotdepasseamoi
    	OK
    	toto mauvaismotdepasse
    	ERR
    

    Pour sortir du programme, utilisez CTRL-C.

    Squid

    Ci-dessous un exemple de fichier de configuration, avec les parties importantes commentées :

    	## debug très fournis... attention à surveiller la taille du fichier cache.log
    	## décommentez cette ligne pour activer ce mode
    	#debug_options ALL,1 28,9
    
    	## port d'écoute, vous pouvez le modifier si vous le souhaitez
    	http_port 3128
    
    	## on interdit tout de suite (= avant tout autre filtrage) les cgi-bin et les command.bat dans les url
    	hierarchy_stoplist cgi-bin ?
    	hierarchy_stoplist command.bat ?
    
    	acl QUERY urlpath_regex cgi-bin\?
    	no_cache deny QUERY
    	cache_mem 16 MB
    	dns_timeout 45 seconds
    
    	## obligation pour les utilisateurs de s'authentifier
    	# commande d'authentification
    	auth_param basic program /usr/lib/squid/smb_auth -U 127.0.0.1 -W MYDOMAIN
    	# utilisez celle-ci dessous, en la décommentant et en commentant celle ci-dessus,
    	# si vous souhaitez utiliser mysql_auth à la place de samba
    	#auth_param basic program /usr/lib/squid/mysql_auth
    	
    	auth_param basic realm "Entrez votre login et votre mot de passe"
    	# obligation des utilisateurs à s'authentifier
    	acl Users proxy_auth REQUIRED
    
    	refresh_pattern ^ftp:		1440	20%		10080
    	refresh_pattern ^gopher:	1440	0%		1440
    	refresh_pattern .			0		20%		4320
    
    	## règles d'accès ip
    	# un sous réseau
    	acl tartampion src 192.168.xxx.0/255.255.255.0
    	# une adresse particulière
    	acl trucmuche src 192.168.10.135
    	## laisser cette règle
    	acl all src 0.0.0.0/0.0.0.0
    
    	## règles d'accès horaire : ici, du lundi au vendredi de 8h à 20h
    	acl working_hours time MTWHF 08:00-20:00
    
    	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
    
    	## défintion des ports autorisés (attention à bien les laisser ouvert sur le firewall
    	#  en sortie également)
    	acl Safe_ports port 80		# pour naviguer sur le web
    	acl Safe_ports port 443		# idem, mais pour les sites utilisant SSL
    	acl Safe_ports port 21		# pour les accès ftp
    	acl Safe_ports port 20		# idem
    	acl Safe_ports port 873		# pour le protocole rsync
    	acl Safe_ports port 1025-65535	# ports dynamiques (penser à faire du filtrage avec état sur le firewall)
    
    	## acl administratives
    	acl purge method PURGE
    	acl CONNECT method CONNECT
    
    	## utile pour bloquer skype 🙂
    	acl numerals urlpath_regex ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+
    
    	## taille maximale des reponses : 15Mo
    	reply_body_max_size 15000KB allow tartampion trucmuche
    
    	## règles d'accès administratives
    	http_access allow manager localhost
    	http_access allow purge localhost
    	http_access allow localhost
    
    	## on boque en dehors des heures et les ports qui ne sont pas définis plus haut 
    	http_access deny !working_hours
    	http_access deny !Safe_ports
    	http_access deny CONNECT !Safe_ports
    
    	## accès administratif interdit sauf en local, comme indiqué par la règle précédente
    	http_access deny manager
    	http_access deny purge
    
    	## pour bloquer SKYPE... du moins pour le moment
    	http_access deny CONNECT numerals
    
    	## on autorise le sous réseau aux utilisateus authentifiés
    	http_access allow tartampion Users
    	## on autorise l'adresse ip aux utilisateurs authentifiés
    	http_access allow trucmuche Users
    	## on bloque tout le reste
    	http_access deny all
    	http_reply_access allow all
    	icp_access allow all
    
    	## filtrage des urls demandées
    	# programme de redirection
    	redirect_program /usr/bin/squidGuard -c /usr/local/lib/squidGuard/squidGuard.conf
    	# nombre de processus réalisant le filtrage
    	redirect_children 5
    

    Le paramètre ‘redirect_children‘ est important. En effet, toutes les requêtes passant par le squid seront redirigées (sauf blocage avant d’atteindre la règle) vers le programme squidguard. Ce paramètre indique le nombre de processus squidguard qui tourneront simultanément. Pensez donc à bien le choisir.

    • S’il est trop faible, il y aura un fort ralentissment du traffic.
    • S’il est trop élevé, la machine consommera beaucoup plus que nécessaire de ressources.

    Faites des tests pour déterminer le meilleur compromis !

    Filtrage avec squidGuard

    Bases de données

    SquidGuard est un outil vous permettant d’effectuer un filtrage des urls visitées par les utilisateurs. Vous pouvez filtrer sur un domaine, une url particulière ou bien sur une expression régulière. Le tout est organisé sous forme d’une « base de données » (à ne pas prendre au sens littéral du terme)
    Il existe des bases de données prêtes à l’emploi. Vous pouvez par exemple en télécharger ici (maintenue par l’université de Toulouse) ou ici (base mondiale)

    Configuration de base

    Vous pouvez placer le fichier de configuration où vous le souhaitez, pensez juste à modifier votre fichier ‘squid.conf‘ pour y indiquer le chemin correct vers le fichier. La structure générale du fichier est la suivante :

    • ensemble de sources (ip, utilisateurs, les deux combinés)
    • ensemble de destinations (les filtres)
    • règles d’accès (acl)
    • Voici un exemple de fichier simpliste :

      	## Repertoire accueillant les bases de donnees
      	dbhome /usr/local/lib/squidGuard/db
      
      	## Repertoire accueillant le fichier de log
      	logdir /var/log/squid
      	
      	## les sites à caractères pornographique
      	dest porn {
      		domainlist	base/porn/domains
      		urllist		base/porn/urls
      	}
      
      	## règles d'accès
      	acl {
      		default {
      			pass !porn all
      			redirect http://localhost/block.html
      		}
      	}
      

      Dans cette configuration on autorise l’accès à tous les sites sous ceux définis sous porn, depuis n’importe quel poste. Testons à présent que tout fonctionne. Lancez le service squid :

      	# /etc/init.d/squid start
      

      Si tout c’est bien passé, ouvrez votre navigateur favori et entrez les identifiants de Jean-Kevin. Vous devriez pouvoir surfer ! Sinon, regardez dans les journaux pour voir s’il n’y a pas d’erreur.
      Nous allons à présent détaillé un peu plus chacune des différentes sections que vous pourrez définit dans le fichier de configuration : source, dest, time et acl.

      Configuration avancée

      Source

      Règles sur les ip ou les domaines

      Les définitions de source permettent de définir des plages ou des listes d’adresse ip ainsi que des listes de logins. Cela vous permet de faire une gestion fine des filtres appliqués à chaque source définie. Voyons les différentes possibilités qui vous sont offertes.
      Jean-Kevin travaille sur les machines 10.0.0.1 et 10.0.0.2 et nous souhaitons donner l’accès au net depuis ces deux machines :

      	source jean-kevin {
      		ip	10.0.0.1 10.0.0.2
      	}
      

      Vous pouvez préciser plusieurs ip sur une même ligne ou bien écrire n lignes « ip <adresse ip>« .
      Jean-Kevin à des collègues et nous savons que leur machine sont dans le range d’ip 10.0.0.1 à 10.0.0.20 :

      	source range-jean-kevin {
      		ip	10.0.0.1-10.0.0.20
      	}
      

      Finalement, vous souhaitez donner l’accès à tous le sous réseau 10.0.0.0/24 :

      	source network-jean-kevin {
      		ip	10.0.0.0/24
      	}
      

      Vous pouvez également utiliser l’autre notation : 10.0.0.0/255.255.255.0.
      Si vous avez spécifié l’option ‘log_fqdn‘ dans votre fichier de configuration squid (‘squid.conf‘) et que le serveur DNS vous permet de faire une résolution inverse des adresses ip, vous pouvez également utilisez l’option domain :

      	source domain-jean-kevin {
      		domain	jean-kevin.com
      	}
      

      Toutes les machines qui sont sur ce domaine seront intégrées à cette source.
      Vous pouvez également déporter la définition des adresses ip dans un fichier dédié :

      	source jean-kevin-ip-adresses {
      		iplist	/usr/local/lib/squidGuard/config/jean-kevin.ips
      	}
      

      Le fichier ‘/usr/local/lib/squidGuard/config/jean-kevin.ips‘ contiendra alors toutes les définitions de réseau, plages d’adresses et machines. Indiquez soit le chemin absolu soit le chemin relatif depuis le répertoire défini par dbhome.
      Par exemple, pour définir les machines 10.0.0.1, 10.0.0.2 et la plage d’adresses 10.0.0.20-10.0.0.30, ce fichier contiendra les deux lignes suivantes :

      	10.0.0.1 10.0.0.2
      	10.0.0.20-10.0.0.30
      

      De même pour l’option ‘domain, il existe domainlist. Indiquez alors un domaine par ligne du fichier correspondant.
      N’oubliez pas de relancer le service squid à chaque modification de votre configuration :

      	# /etc/init.d/squid reload
      

      Règles sur les utilisateurs

      Vous pouvez créer des groupes d’utilisateurs plutôt que des groupes d’adresse ip. Par exemple, Jean-Kevin et Bob seront des utilisateurs privilégiés et ne subiront pas le même filtrage que les autres :

      	source privileged {
      		user jean-kevin bob
      	}
      

      Vous pouvez indiquer plusieurs logins par ligne ou bien faire n lignes ‘user <user>‘, à votre convenance. Vous pouvez également préférer la méthode décrite plus haut pour les ip :

      	source privileged {
      		userlist	/usr/local/lib/squidGuard/config/privileged.users
      	}
      

      ou le fichier ‘/usr/local/lib/squidGuard/config/privileged.users‘ contiendra les n logins, un par ligne :

      	$ cat /usr/local/lib/squidGuard/config/privileged.users
      	jean-kevin
      	bob
      

      Règles complexes

      Maintenant que nous avons vu les principales possibilités de ‘source’, imaginons le cas suivant. Jean-Kevin doit pouvoir accéder à certains sites sensibles sans que les autres utilisateurs en aient, eux, la possibilité. Là où les choses se compliquent, c’est que Jean-Kevin ne doit pouvoir accéder à ces sites que depuis le poste (filmé en permance) 10.0.0.200 :

      	source jean-kevin-delicate {
      		ip	10.0.0.200
      		user	jean-kevin
      	}
      

      Ainsi, nous avons défini un groupe qui pourra servir à autoriser (ou pas) Jean-Kevin à accéder à certains sites uniquement depuis la machine 10.0.0.200. Vous pouvez bien entendu utiliser plusieurs utilisateurs et ip pour la définition de vos groupes. Vous pouvez également utiliser les directives ‘iplist’, ‘userlist’ et ‘domainlist’. Bref, les possibilités sont presque sans limite (à part celle de votre imagination peut-être 😉

      Dest

      Il existe trois directives pour la création des groupes de destination. Ce sont ces groupes qui vont effectivement filtrer les url demandées par les utilisateurs.

      domainlist

      Vous spécifiez un fichier contenant la liste des domaines – un par ligne – contenus par cette destination. Par exemple, si vous avez un fichier contenant divers domaines pornographiques :

      	dest porn {
      		domainlist	porn.domains
      	}
      

      Le fichier ‘porn.domains‘ (dans notre configuration) doit se trouver dans le répertoire défini par ‘dbhome‘ donc dans (ici) ‘/usr/local/lib/squidGuard/db‘.

      urllist

      De la même manière que précédemment, vous pouvez spécifier une liste d’adresses contenues par une destination :

      	dest porn {
      		urllist	porn.urls
      	}
      

      Là aussi, une seule adresse par ligne. Attention cependant, si vous souhaitez que l’adresse www.google.fr soit dans cette destination, le fichier porn.urls devra contenir google.fr (si vous mettez www.google.fr, ce n’est pas pris en compte, surement un bug)

      expressionlist

      Dernière possibilité, l’utilisation d’expressions régulières. Pour ce faire :

      	dest porn {
      		expressionlist	porn.regexp
      	}
      

      Je ne vais pas faire ici un cours sur les expressions régulières, d’autres s’en sont déjà très bien chargés (tapez expressions régulières dans google 😉 Je vous donnerai seulement quelques expressions simples pour bloquer les téléchargements de fichiers potentiellement dangereux :

      fichiers exécutables *.\.exe$
      fichiers exécutables *.\.msi$
      fichiers exécutables *.\.bin$
      la plupart des sites de blog *.blog.*

      Vous pouvez bien entendu utiliser des règles bien plus complexes. N’oubliez pas de mettre une seule expression par ligne du fichier. Gardez toujours aussi en tête que les expressions régulières sont gourmandes en ressources au moment de la comparaison avec l’url demandée : utilisez les à on escient.

      Groupe global

      Vous pouvez utiliser une ou plusieurs de ces trois directives simultanément. Par exemple, si vous avez un fichier d’adresses, un fichier de domaines et un fichier d’expressions régulières :

      	dest porn {
      		expressionlist	porn.regexp
      		domainlist	porn.domains
      		urllist		porn.urls
      	}
      

      Votre groupe est constitué par l’ensembles des expressions du fichier ‘porn.regexp,’ des domaines du fichier ‘porn.domains’et des adresses du fichier ‘porn.urls’.

      Groupe de temps : time

      Vous avez également la possibilité de définir des plages horaires. Cela peut-être pratique si vous souhaitez donner accès à certains sites (ou autre) seulement le midi par exemple (consultation de messagerie personnelle, etc)
      Pour définir vos plages horaires, vous pouvez utilisez les directives weekly et date. Les jours de la semaine sont abrégés de la manière suivante (basées sur les noms anglais) :

      	s (Sunday) = dimanche, m (Monday) = lundi, t (Tuesday) = mardi, w (Wednesday) = mercredi,
      			      h (tHursday) = jeudi, f (Friday) = vendredi, a (sAturday) = samedi
      

      Définissons donc les plages horaires pendant lesquelles Jean-Kevin (encore lui 😉 est sensé travailler : 8h30 – 12h30 et 14h-18h, sauf le vendredi où il termine à 17h (et oui, il n’a pas le droit de travailler 40 heures dans la semaine 🙂

      	time jean-kevin-working-hours {
      		weekly m 08:30-12:30 14:00-18:00
      		weekly t 08:30-12:30 14:00-18:00
      		weekly w 08:30-12:30 14:00-18:00
      		weekly h 08:30-12:30 14:00-18:00
      		weekly f 08:30-12:30 14:00-17:00
      	}
      

      Jean-Kevin ne travaille pas le 1er mai ni à Noël, on va donc définir un groupe jours fériés :

      	time holidays {
      		date	*.05.01	# tous les 1er Mai de chaque année
      		date	*.25.12	# tous les 25 Décembre de chaque anné
      		date	*.01.01	# tous les 1er de l'An
      	}
      
      Règles de filtrage : acl

      Redirection

      Une acl est constituée d’une source et de règles à appliquer en fonction d’une ou plusieurs destination et d’une action de redirection. La redirection est généralement faite vers une page web accessible par le client sans passer par le proxy (pensez donc à bien configurer les navigateurs clients)
      Comme vous avez peut-être envie que vos utilisateurs aient un minimum d’informations à vous communiquer lorsqu’ils pensent détecter une erreur de filtrage, squidguard vous transmets diverses informations sur la requête qu’il est en train de traiter :

      • %a contient l’adresse ip du client
      • %i contient l’identifiant du client ou l’adresse ip si aucun login n’a été fourni
      • %n contient le domaine du client ou « unknown » s’il n’est pas disponible
      • %p contient toute la partie options d’une url (tout ce qui se trouve derrière le premier caractère ‘&’ rencontré)
      • %s contient l’identifiant du groupe ‘source’ auquel appartient le client, tel que défini dans le fichier de configuration
      • %t contient l’identifiant du premier groupe ‘dest’ pour lequel l’url demandée possède une correspondance
      • %u contient l’adresse demandée, sans ses éventuelles options (cf %p)

      Vous pouvez ainsi avoir écrit un script qui traitera ces données :

      	redirect	http://www.foo.bar/blocked.php?user=%i&&url=%u&target=%t
      

      Filtrage minimal requis

      Il est désormais temps de faire un tout de nos différentes petites parties ! Commençons par l’acl minimale autorisant tout traffic :

      	acl {
      		default {
      			pass	all
      		}
      	}
      

      Filtrage par source

      Nous avançons désormais : seul la source ‘tartampion’ peut accéder au net, toutes les autres sources sont bloquées et redirigées :

      	acl {
      		# on indique pour quelle source on va appliquer les règles
      		tartampion {
      			pass all
      		}
      		
      		default {
      			pass none
      			redirect http://www.foo.bar/blocked.php?user=%i&&url=%u&target=%t
      		}
      	}
      

      Compliquons encore un peu les choses. Nous souhaitons maintenant interdire les différents groupes ‘dest’ que nous avons créés pour le groupe source ‘tartampion’, rediriger les demandes interdites et rediriger tous les autres groupes :

      	acl {
      		tartampion {
      			pass	!porn all
      			redirect http://www.foo.bar/blocked.php?user=%i&&url=%u&target=%t
      		}
      		
      		default {
      			pass none
      			redirect http://www.foo.bar/blocked.php?user=%i&&url=%u&target=%t
      		}
      	}
      

      Ainsi, ‘tartampion’ a accès à tous les sites sauf ceux ayant une correspondance avec les définitions (domaines, urls, expressions régulières) du groupe ‘porn’. Le caractère ‘!’ placé devant le nom d’un groupe revient à dire « tout sauf ce qui a une correspondance avec ».
      Notez bien que l’ordre dans lequel vous indiquez les groupes est important. En effet, c’est la première correspondance qui prime. Si vous écrivez :

      	'pass    all !porn'
      

      toutes les requêtes seront en réalité satisfaites et le filtrage souhaité inexistant. N’oubliez donc pas de placer la règle ‘all’ en dernière position.

      Filtrage avec plage horaire

      Voici un exemple avec utilisation des plages horaires :

      	acl {
      		tartampion within jean-kevin-working-hours {
      			pass	!adv !tracker !porn all
      			redirect http://www.foo.bar/blocked.php?user=%i&&url=%u&target=%t
      		} else {
      			pass none
      			redirect http://www.foo.bar/nonworkinghours.html
      		}
      		
      		default {
      			pass	!porn all
      			redirect http://www.foo.bar/blocked.php?user=%i&&url=%u&target=%t
      		}
      	}
      

      Dans cette acl, nous indiquons que le groupe source ‘tartampion‘ peut accéder à tous les sites web, à l’exception de ceux correspondant aux groupes ‘adv‘, ‘tracker‘ et ‘porn‘, pendant les heures définies dans la règle ‘time jean-kevin-working-hours‘. Si le groupe ‘tartampion’ accède au net en dehors de ces heures, il est redirigé vers la page nonworkinghours.html. Tous les autres groupes ont accès au net, à l’exception des sites correspondant au groupe ‘porn’, avec redirection en cas d’adresse interdite.

      Exemple complet de fichier squidGuard.conf avec la base de donnees mondiale

      Notez bien que pour créer vos propres fichiers de domaines, d’urls ou d’expression régulières, la seule contrainte est que ces fichiers soient accessibles relativement au répertoire ‘dbhome’ ou bien que vous indiquiez leur chemin absolu.

      	# Répertoire accueillant les bases de données
      	dbhome /usr/local/lib/squidGuard/db
      	# Répertoire accueillant le fichier journal
      	logdir /var/log/squid
      
      	##########
      	### Définition des groupes
      	##########
      	# Administrateurs
      	source administrators {
      		# contient les logins des administrateurs
      		userlist	/usr/local/lib/squidGuard/config/administrators.users
      		# contient les ip des machines des administrateurs
      		iplist		/usr/local/lib/squidGuard/config/administrators.ips
      
      	}
      
      	# Les profs : pas d'ip, ils n'ont pas de postes attitrés
      	source teachers {
      		userlist	/usr/local/lib/squidGuard/config/teachers.users
      
      	}
      
      	# Les sous-réseaux pour gérer globalement les élèves
      	source students {
      		# contient les différents sous-réseaux
      		iplist		/usr/local/lib/squidGuard/config/students.ips
      	}
      	
      	###########
      	### Bases de données
      	########### 
      	# Base de données auto : fournies par le fichier téléchargés
      	dest ads {
      		domainlist	base/ads/domains
      		urllist		base/ads/urls
      
      	}
      	dest aggressive {
      		domainlist	base/aggressive/domains
      		urllist		base/aggressive/urls
      	}
      	dest audio-video {
      		domainlist	base/audio-video/domains
      		urllist		base/audio-video/urls
      	}
      	dest drugs {
      		domainlist	base/drugs/domains
      		urllist		base/drugs/urls
      	}
      	dest gambling {
      		domainlist	base/gambling/domains
      		urllist		base/gambling/urls
      	}
      	dest hacking {
      		domainlist	base/hacking/domains
      		urllist		base/hacking/urls
      	}
      	dest mail {
      		domainlist	base/mail/domains
      	}
      	dest porn {
      		domainlist	base/porn/domains
      		urllist		base/porn/urls
      	}
      	dest proxy {
      		domainlist	base/proxy/domains
      		urllist		base/proxy/urls
      	}
      	dest violence {
      		domainlist	base/violence/domains
      		urllist		base/violence/urls
      	}
      	dest warez {
      		domainlist	base/warez/domains
      		urllist		base/warez/urls
      	}
      
      	# Base de données manuelles
      	dest manual_blocked { ## blacklist manuelle
      		domainlist	manual/blocked.domains
      		urllist		manual/blocked.urls
      		expressionlist	manual/blocked.expressions
      	}
      	dest manual_auth { ## whitelist manuelle
      		domainlist	manual/auth.domains
      		urllist		manual/auth.urls
      		expressionlist	manual/auth.expressions
      	}
      
      	###########
      	# Règles d'accès
      	###########
      	acl {
      		# Regles pour l'administrateur
      		administrators {
      			pass all
      		}
      
      		# Regles pour les profs
      		teacher {
      			# ne passez pas à la ligne si vous faîtes un copier/coller
      			pass !ads !aggressive !audio-video !drugs !gambling !hacking !mail !porn
      									!proxy !violence !warez all
      			redirect http://<le serveur qui va bien>/blocked.php?user=%i&&url=%u&target=%t
      		}
      
      		# Regles pour les eleves
      		students {
      			# ne passez pas � la ligne si vous faîtes un copier/coller
      			pass manual_auth !manual_blocked !ads !aggressive !audio-video !drugs !gambling !hacking
      									!mail !porn !proxy !violence !warez all
      			redirect	http://<le serveur qui va bien>/blocked.php?user=%i&&url=%u&target=%t
      		}
      
      		# Regles par defaut
      		default {
      			pass none
      			redirect http://<le serveur qui va bien>/blocked.php?user=%i&&url=%u&target=%t
      		}
      	}
      

      Base de données «statiques»

      Il peut vous être utile de «compiler» vos différents fichiers constituant cette base de données. En effet, à chaque lancement de squid, les bases sont compilées sous forme de table de hachage. Si votre base est stable, il est intéressant de ne pas recompiler les bases à chaque lancement.
      Pour ce faire, lancer la commande suivante en tant qu’utilisateur root – ou d’un compte administratreur de la machine – (on suppose que l’utilsateur lançant squid est l’utilisateur proxy) :

      $ sudo -u proxy /usr/bin/squidGuard -d -c /usr/local/lib/squidGuard/squidGuard.conf -C all && /etc/init.d/squid reload
      

      Gestion des utilisateurs

      Il ne vous reste maintenant plus qu’à créer les différents utilisateurs de votre système et tester. Pour ma part, j’utilise une interface « web maison » qui permet la création, la suppression et le blocage des comptes samba des utilisateurs.
      N’hésitez pas à laisser vos commentaires : wblitz ‘at’ free ‘point’ fr.

      Liens

Leave a Reply