L'informatique est aujourd'hui devenue très ouverte au monde extérieur du

fait de la démocratisation de l'ordinateur personnel et l'avènement de

l'Internet. Ce dernier est un outil incontournable et il réunit plein
d'utilisateurs de part le monde. On compte environ 1,73 milliards
d'utilisateurs (septembre 2009) et d'après Netcraft, société anglaise
spécialisée dans la sécurité internet, il y aurait en janvier 2010 plus de 207
millions de sites web dans le monde. L'internet est alors de plus en plus
accessible, mais il recèle de nombreux dangers, souvent ignorés par
beaucoup d'utilisateurs d'où se pose un problème de sécurité.

Les réseaux locaux sont fréquemment reliés à Internet via des passerelles
ou routeurs, ils utilisent le plus souvent le protocole TCP/IP. Dans notre
étude, nous allons utiliser un proxy pour relier notre réseau local à l'Internet.
Tous nos utilisateurs vont alors passer par notre proxy pour l'obtention de
pages Web. Notre choix de proxy s'est porté sur SQUID qui, en plus d'1tre
libre, est très souple, léger et facile à mettre en place. Le rôle initial du
serveur proxy ou serveur mandataire est de relayer des requêtes HTTP
entre un poste client et un serveur. En plus de ce rôle, il peut jouer une
fonction de sécurité en constituant une barrière entre Internet et notre
réseau local. Notre serveur proxy SQUID va aussi être couplé à un
annuaire LDAP pour l'authentification des utilisateurs de notre réseau.
Nous allons y intégrer un antivirus et aussi sécuriser l'authentification des
utilisateurs avec SSL pour plus de sécurité.

Pour mener à bien ce travail, nous allons dans un premier temps faire une
présentation des deux grandes écoles l'ESP et l'ESMT, ensuite nous
présenterons les différentes technologies et outils nécessaires pour ce
travail et nous terminerons par la mise en place d'un proxy SQUID sécurisé
avec une authentification via LDAP.

CHAPITRE II : Présentation des outils nécessaires II.1. Le proxy

SQUID

II.1.1. Définition

Un serveur proxy aussi appelé serveur mandataire est à l'origine une

machine faisant fonction d'intermédiaire entre les ordinateurs d'un réseau
local et internet. La plupart du temps le serveur proxy est utilisé pour le
web, il s'agit alors d'un proxy HTTP. Il nous permettra ainsi de gérer l'accès
à internet aux utilisateurs de notre réseau local en fonction des heures
d'accès, des ports de destination d'un service, d'IP sources, etc. Il permet
aussi de mettre en cache les sites les plus visités afin d'accélérer le trafic.
Comme serveur proxy, nous allons utiliser le serveur SQUID qui est un
logiciel libre distribué selon les termes de la licence GNU GPL. Son rôle
initial est de relayer des requêtes HTTP entre un poste client de notre
réseau local et un serveur web se trouvant sur Internet. Il peut aussi
assurer d'autres fonctions essentielles.

II.1.2. Fonctionnement et Rôles

II.1.2.1. Fonctionnement

Le principe de fonctionnement basique d'un serveur proxy est assez simple

: il s'agit d'un serveur "mandaté" par une application pour effectuer une
requête sur Internet à sa place. Ainsi, lorsqu'un utilisateur se connecte à
internet à l'aide d'une application cliente configurée pour utiliser un serveur
proxy, celle-ci va se connecter en premier lieu au serveur proxy et lui
donner sa requête. Le serveur proxy va alors se connecter au serveur que
l'application cliente cherche à joindre et lui transmettre la requête. Le
serveur va ensuite donner sa réponse au proxy, qui va à son tour la
transmettre à l'application cliente. Les objets consultés par les clients sur
internet, sont stockés en cache disque par le serveur. À partir du deuxième
accès, la

lecture se fera en cache, au lieu d'être réalisée sur le serveur d'origine. De

ce fait il permet d'accélérer nos connexions à l'internet en plaçant en cache
les documents les plus consultés.

Figure 2: Principe de fonctionnement

II.1.2.2. Role

Le serveur proxy SQUID peut assurer plusieurs rôles parmi lesquels :

· Le role de cache : En jargon informatique, une mémoire cache sert à

conserver localement des informations qui ont une certaine probabilité de
servir à nouveau à court terme. Un serveur proxy stocke provisoirement les
pages web que les utilisateurs vont chercher sur Internet. Si un internaute
requiert une information qui se trouve déjà dans le cache, il sera servi plus
rapidement.

· Le rôle d'enregistrement : Comme tout serveur qui se respecte, un

proxy génère un fichier journal (log file). On y trouve la trace de toutes les
requêtes effectuées par tous les postes clients dépendant du serveur en
question.

· Le role de filtre : On peut configurer un serveur proxy de telle sorte qu'il

examine le contenu des paquets qu'il reçoit pour le compte des clients, et
qu'il refuse de transmettre ceux qui ne répondent pas à certains critères.

· Le role de sécurité : En y ajoutant certains logiciels de sécurité, le

serveur proxy assure ainsi des fonctions de sécurité pour le réseau local.

· L'authentification : SQUID permet d'authentifier les clients avant qu'ils

accèdent à la ressource qu'ils demandent. Nous utiliserons un serveur
LDAP pour authentifier nos utilisateurs.

II.2. L'annuaire LDAP II.2.1. Definition

Un annuaire est un recueil de données dont le but est de pouvoir retrouver

facilement des ressources (généralement des personnes ou des
organisations) à l'aide d'un nombre limité de critères. Cette série d'articles
s'intéresse tout particulièrement à un type spécifique d'annuaires: les
annuaires électroniques. L'implémentation d'un annuaire électronique peut
être totalement différente d'un serveur à un autre, c'est pourquoi il a été
nécessaire de définir une interface normalisée permettant d'accéder de
façon standard aux différents services de l'annuaire. C'est le rôle du
protocole LDAP (Lightweight Directory Access Protocol), dont le rôle est
uniquement de fournir un moyen unique (standard ouvert) d'effectuer des
requêtes sur un annuaire (compatible LDAP). LDAP est un protocole basé
sur TCP/IP qui permet de partager des bases de données sur un réseau
interne ou externe. Elles peuvent contenir tout type d'informations, des
informations sur les personnes, sur des ressources. Dans notre cas, nous
utilisons l'annuaire Open Source appelé OpenLDAP qui est développé sous
licence GNU GPL. Il nous est possible de faire des recherches dans la
base en employant plusieurs critères et aussi de faire des modifications et
suppressions. Mais contrairement à un SGBD, un annuaire est prévu pour
être plus sollicité en lecture qu'en écriture. Cela signifie qu'un annuaire est
conçu pour être plus souvent consulté que mis à jour. En effet, comme un
annuaire est beaucoup plus lu que modifier, il a été optimisé en lecture et
ne possède pas les mécanismes de transaction complexe que les SGBD
possèdent pour traiter de gros volumes de données.

II.2.2. Fonctions

Comme l'annuaire téléphonique, la première fonction de l'annuaire LDAP

est de retrouver facilement les coordonnées d'une personne : son adresse
électronique, son adresse professionnelle, son téléphone professionnel en
fonction de différents critères de recherche.

De nombreuses applications nécessitant une authentification sont

aujourd'hui capables d'interroger un annuaire LDAP pour vérifier l'identité
d'un utilisateur gr~ce à un couple login et mot de passe. C'est cette fonction
qui va le plus nous intéresser dans notre étude. Grâce à cet annuaire, notre
proxy SQUID va pouvoir authentifier ses utilisateurs.

II.2.3. Structure

Les données LDAP sont structurées dans une arborescence hiérarchique

qu'on peut comparer au système de fichier Unix. Chaque noeud de l'arbre
correspond à une entrée de l'annuaire ou Directory Service Entry (DSE) et
au sommet de cette arbre, appelé Directory Information Tree (DIT), se
trouve la racine ou suffixe. Ce modèle est en fait repris de X500, mais
contrairement à ce dernier, conçu pour rendre un service d'annuaire
mondial (ce que le DNS fait par exemple pour les noms de machines de
l'Internet), l'espace de nommage d'un annuaire LDAP n'est pas inscrit dans
un contexte global.

Les entrées correspondent à des objets abstraits ou issus du monde réel,

comme une personne, une imprimante, ou des paramètres de
configuration. Elles contiennent un certain nombre de champs appelés
attributs dans lesquelles sont stockées des valeurs. Chaque serveur
possède une entrée spéciale, appelée root Directory Specific Entry
(rootDSE) qui contient la description de l'arbre et de son contenu.

Un objet est constitué d'un ensemble de paires clés/valeurs appelées

attributs permettant de définir de façon unique les caractéristiques de l'objet
à stocker. Par analogie avec la terminologie objet on parle ainsi de classe
d'objet pour désigner la structure d'un objet, c'est-à-dire l'ensemble des
attributs qu'il doit comporter. De cette façon un objet est un ensemble
d'attributs avec des valeurs particulières.
LDAP utilise le format LDAP Data Interchange Format (LDIF) qui permet de
représenter les données LDAP sous format texte standardisé, il est utilisé
pour afficher ou modifier les données de la base.

ou=profs

dc=esp, dc=sn

ou=etudiants

cn=sall
uid=100

cn=ouya uid=101

cn=djiby
uid=200

cn=fatou uid=201

Dc : domain component Ou : organizational units Cn : common name

Uid : user identifier

Figure 3: Exemple de DIT

CHAPITRE III
Chapitre III : Mise en ° XIIE III.1. Mise en place du proxy SQUID

III.1.1. Configuration matérielle et logicielle

Avant d'installer et d'utiliser SQUID, il est recommandé de bien choisir son

matériel et le système d'exploitation du serveur. Durant son lancement,
SQUID a besoin de faire beaucoup d'actions, notamment en rapport avec
les caches, qui seront consommateurs de CPU. Ainsi, le matériel minimum
recommandé est un Pentium III 550MHz, la RAM est un composant vital
pour SQUID car il réside en mémoire RAM et y stocke ses composants et
les objets les plus demandés par les clients. Lorsque le cache est activé, il
faut compter 10Mb de RAM par GIGA de données en cache. On doit alors
prévoir de l'espace disque suffisante pour le stockage des données
manipulées par SQUID notamment le cache disque, les logs etc..

Il faut ainsi noter que le choix de la configuration matérielle du serveur est

important. Le choix d'une bonne carte réseau est nécessaire parce qu'une
carte réseau sous dimensionnée par rapport au réseau sur lequel est
branché le Proxy provoquerait très rapidement un engorgement important
et ralentira les demandes des clients. Il est donc conseillé d'utiliser au
minimum une carte réseau 100Mbps. Il faut aussi bien vérifier auparavant
que la machine redémarre bien toute seule s'il y a coupure d'électricité en
vérifiant dans le BIOS si il y a une option pour mettre en route la machine
au rétablissement du courant, si ce n'est pas le cas l'utilisation d'une telle
machine est à proscrire.

Concernant les systèmes d'exploitation, SQUID est disponible sur

beaucoup d'architectures et systèmes, en particulier les différentes
distributions Linux. Il est préférable d'utiliser une version de Linux récente et
stable. Dans notre étude, nous installerons SQUID sur la dernière version
de Ubuntu actuellement disponible qui est la 10.04. Notre réseau local est
le [Link] et notre proxy va s'appeler firewall_esp.

III.1.2. Installation

III.1.2.1. Installation manuelle

Avant de commencer, il faut au préalable télécharger la dernière version

stable de SQUID. On peut l'acquérir sur le site officiel de SQUID qui
est [Link] La dernière version actuelle stable est la
version 2.7.STABLE7. Une fois le logiciel au format [Link] (c'est à dire
compressé sous ce format) téléchargé, on pourra alors l'installer et on
suppose que le fichier décompressé sera placé dans le
répertoire /usr/local/src. On le décompresse via la commande :

#tar -zxvf [Link] --directory=/usr/local/src On doit

obtenir ce répertoire : /usr/local/src/squid-2.7.STABLE7.

Il convient maintenant de compiler SQUID. On se place dans le répertoire

de SQUID : #cd /usr/local/src/squid

On passe ensuite à la configuration des options de compilation. Squid sera

par défaut installé dans le répertoire /usr/local/squid mais on peut utiliser un
autre répertoire via l'option --prefix. Si on souhaite avoir les messages
d'erreurs en français, on ajoute l'option --enable-err-language=French mais
on peut aussi faire cela au niveau de la configuration de SQUID. La
commande pour la compilation est alors :

#./configure --prefix=/usr/local/squid --enable-errlanguage=French

Si tout c'est bien passé, il ne reste plus qu'à compiler avec la commande :
#make all

Puis procéder à l'installation avec la commande :

#make install

Le fichier INSTALL situé dans la racine du répertoire

/usr/local/src/squid2.7.STABLE7 reprend en partie ce qui vient d'être
expliqué.

A la fin de l'installation, les répertoires suivants seront créés :

/usr/local/squid : répertoire de base de SQUID

/usr/local/squid/etc : répertoire contenant la configuration de SQUID

/usr/local/squid/bin : répertoire contenant les binaires et les scripts
/usr/local/squid/logs : répertoire contenant les logs

III.1.2.2. Installation automatique

L'installation automatique de SQUID est relativement facile. Il suffit juste de
disposer d'une connexion internet, de se connecter en tant que root sur le
terminal de la machine et de taper la commande :

#apt-get install squid

De cette manière, c'est le système qui se charge de télécharger tous les

fichiers nécessaires c'est à dire la dernière version stable disponible dans
les dépôts et éventuellement les dépendances s'il y en a. L'installation
automatique est ainsi recommandée car cette dernière se charge d'acquérir
à notre place tous les fichiers nécessaires et aussi de les placer à l'endroit
qu'il faut. Le fichier de configuration de SQUID se trouvera dans le
répertoire /etc/squid et portera le nom de [Link]. Les logs se trouveront
dans le répertoire /var/log/squid et le démon dans le répertoire /etc/init.d/
sous le nom de squid.

III.1.3. Configuration

SQUID se configure via un unique fichier de configuration qui

/etc/squid/[Link]. Celui-ci est chargé au lancement de SQUID qui
s'efforcera alors de refléter ce dernier. Chaque ligne du fichier est de la
forme suivante :

option paramètre [paramètre ...I

Les lignes débutant par un '#' sont des commentaires. Les options non
définies auront toujours une valeur par défaut. Toutes les options de ce
fichier sont dispersées dans plusieurs parties distinctes. Nous détaillerons
les options les plus intéressantes de ces parties. Notons que le fichier de
base fourni avec les sources est très largement commenté et contient par
défaut 4963 lignes. Pour plus de renseignement et des paramètres plus
poussés, il est donc préférable de consulter la documentation officielle.

III.1.3.1. Configuration de la section réseau

Cette section concerne toutes les configurations réseau de SQUID ayant

trait aux adresses IP et ports de communication. Ces configurations réseau
concernent les communications entre SQUID et les serveurs distants, les
clients et les caches distants.

http_port : définit le port d'écoute de Squid pour les requêtes HTTP. Par
défaut, le port sera 3128. Pour plus de sécurité, nous changeons ce port
par défaut et nous prenons par exemple le port 8080.
http_port 8080

icp_port : définit le port d'émission et d'écoute des requêtes ICP. Par

défaut, le port est 3130. Ceci nous permet de communiquer avec des proxy
parents ou voisins. La valeur 0 permet de ne pas utiliser ce service

visible_hostname : Nous indiquons ici le nom de notre serveur proxy.

Nous l'appelons firewall_esp

error_directory : Nous indiquins via cette option le répertoire où se

trouvent les messages d'erreurs destinés à l'utilisateur. Par défaut, on a :
/usr/share/squid/errors/en et pour avoir ces messages en français, on met
le répertoire /usr/share/squid/errors/fr à la place. Les messages d'erreurs
qui apparaitront sur le navigateur du client seront ainsi en français.

III.1.3.2. Configuration de la taille du cache

cache_mem : correspond au cache mémoire, la valeur dépend de votre

système. Par défaut SQUID utilise 8 Mo. Cette taille doit être la plus grande
possible afin d'améliorer les performances. Nous décidons d'utiliser 100MB.

cache mem 100 MB _

maximum_object_size: permet de spécifier la taille maximale des objets

qui seront stockés dans le cache. La taille par défaut est de 20480 KB.

minimum_object_size: permet de spécifier la taille minimale des objets qui

seront WintA iEQADMIKI I7 MIENISEU iéIIXWINiil lM
%11FHIXLMJQIIIFD4Mj\ IaESIN ieE minimum pour les objets.

ipcache_size: permet de spécifier le nombre d'adresses IP qui seront

enregistrées. Sa valeur par défaut est de 1024

III.1.3.3. &KIPan /OP4s/EK1 facKatis/Oi/E4 8 '

Cache_dir Type RépertoireSource MOctets Level1 Level2 : permet de

définir un cache. il est possible de définir plusieurs fois cette option afin de
multiplier le nombre de cache. Détaillons les options de ce paramètre :

· Type : le type de stockage qui sera utilisé par Squid pour écrire ses
données. Ce paramètre modifie le comportement de SQUID lors de
l'écriture sur le disque, ses accès au disque, sa répartition de données sur
l'espace qui lui est consacrée, etc.. Une liste des types supportés est
détaillée dans le fichier de configuration de SQUID. Le type utilisé par
défaut est ufs
· RépertoireSource : le répertoire source de l'arborescence du cache. Le
cache de SQUID se présente sous forme d'une arborescence dans laquelle
les objets sont répartis

· MOctets : la taille en Mo à réserver sur le disque pour ce cache ;

· Level1 : le nombre de répertoire de niveau 1 dans l'arborescence du

cache.

· Level2 : le nombre de répertoire de niveau 2 dans l'arborescence du

cache.

Par défaut, on a un cache de 100 MB se trouvant dans le répertoire

/var/spool/squid. On peut ajouter si on veut un autre cache avec le
répertoire de son choix avec la taille que l'on veut.

cache_dir ufs /var/spool/squid2 1000 16 256

access_log DirectoryPath/filename : I'Hst le chemin vers le fichier de

[Link] qui contient tous les accès au cache. Par défaut c'est le fichier
/var/log/squid/[Link]

cache_log DirectoryPath/filename : idem que pour access_log avec le

fichier /var/log/squid/[Link] qui contient toutes les informations des
activités de SQUID.

cache_store_log DirectoryPath/filename : idem que pour access_log

avec le fichier /var/log/squid/[Link] qui contient toutes les entrées et
sorties des objets dans le cache

Pour ces trois options précédentes, si on ne souhaite pas avoir de log, on

met le paramètre none à la place du nom de fichier.

debug_options : c'est le niveau de debug. Indiquer 9 pour avoir toutes les

traces à la place de 1 utilisé par défaut. Attention cela donne de gros
fichiers.

III.1.3.4. Comportement avec les applications externes

Cette section définit certains paramètres qui modifieront le comportement

de SQUID envers les applications qui lui sont extérieurs comme les
serveurs distant ou ses applications déléguées.
ftp_user : permet de spécifier quel sera le nom d'utilisateur envoyé à un
serveur FTP par SQUID lors d'une connexion en anonymous

ftp_list_width : permet de définir la longueur maximale des noms de fichier

dans une liste. Une fois cette taille dépassée, le nom sera tronqué et des
points de suspensions ajoutés

ftp_passive on|off : permet de spécifier le mode de connexion FTP utilisé

dns_children : le nombre de processus de demande de DNS résidant en

mémoire. Plus le serveur sera sollicité, plus ce nombre devra être grand

dns_timeout : permet de spécifier un timeout à partir duquel SQUID

considèrera le serveur DNS distant comme étant indisponible

dns_nameservers : permet de définir une liste d'adresse IP de serveur

DNS qui remplacera celle lue par défaut dans le fichier de configuration
/etc/[Link] sous Linux

authenticate_program : permet de spécifier le chemin vers le programme

chargé de l'authentification des utilisateurs. En fonction du type
d'authentification, un chemin vers le fichier de profil peut être nécessaire en
deuxième option

authenticate_children : le nombre de processus d'authentification à

conserver en mémoire RAM.

III.1.3.5. I is !iP Ss 1PJ!!iQ!i

Cette section permet de configurer les différents timeouts de SQUID

connect_timeout : le temps d'attente d'une réponse du serveur distant

avant de retourner une page d'erreur de type "connection timeout" au client
;

request_timeout : le temps d'attente de Squid entre deux requêtes HTTP

avant de fermer la connexion ;

client_lifetime : le temps maximum qu'un client a le droit de rester

connecter à SQUID

pconn_timeout : le temps d'attente de SQUID avant de fermer une

connexion de type persistante ;
ident_timeout : le temps maximum d'attente d'une authentification.

III.1.4. Contrôle des accès

Il s'agit des options concernant les restrictions d'accès aux ressources.

Pour contrôler tout ce qui passe par votre serveur proxy, vous pouvez
utiliser ce que l'on appelle les ACL (Access Control List). Les ACL sont des
règles que le serveur applique. Cela permet par exemple d'autoriser ou
d'interdire certaines transactions. On peut autoriser ou interdire en

fonction du domaine, du protocole, de l'adresse IP, du numéro de port, d'un

mot et aussi limiter ll1FFqs sur des plages horaires. La syntaxe d'une ACL
est la suivante :

acl aclname acltype string[string2]

http_access allow|deny aclname

aclname : peut être n'importe quel nom attribué par l'utilisateur à un

élément ACL acltype peut prendre comme valeur :

· src (pour la source) : indication de l'adresse IP du client sous la forme

adresse/masque. On peut aussi donner une plage d'adresse sous la forme
aCrIMIA 3CIEXWECrIMIA 311n

· dst (pour la destination) : idem que pour src, mais on vise l'adresse IP de
l'ordinateur cible.

· srcdomain : Le domaine du client

· dstdomain : Le domaine de destination

· time : heure du jour et jour de la semaine

· url_regex : Une chaîne contenue dans l'URL

· urlpath_regex : Une chaîne comparée avec le chemin de l'URL

· proto : Pour le protocole

· proxy_auth : Procédé externe d'authentification d'un utilisateur

· maxconn : Nombre maximum de connexions pour une adresse IP cliente

string[string2]: paramètres CIBlll$ 8z/

Exemple 1: Interdire l'accès à un domaine : supposons que nous

souhaitions interdire l'accès à un domaine (par exemple le domaine
pas_beau.fr). On a donc

acl domaine_bloqué dstdomain pas_beau.fr http_access deny

domaine_bloqué

Exemple 2: interdire l'accès aux pages contenant le mot jeu. acl

bloqué_jeu url_regex jeu

http_access deny bloqué_jeu

Attention url_regex est sensible aux majuscules/minuscules. Pour interdire

JEU, il faut aussi ajouter JEU dans votre ACL. Il n'est pas besoin de
réécrire toute l'ACL. On peut ajouter JEU derrière jeu en laissant un blanc
comme séparation (cela correspondant à l'opérateur logique OU).

Exemple 3: Interdire les accès pendant les plages horaires 8h-12h et 14h-
18h en semaine.

«S Sunday M Monday T Tuesday W Wednesday H Thursday F Friday A

Saturday»

acl matin time MTWH 08:00-12:00 acl soir time MTWH 14:00-18:00
http_access deny matin reseau_esp http_access deny soir reseau_esp

III.1.5. Configuration manuelle des clients et test de fonctionnalité

Nous allons procéder à une configuration manuelle des clients c'est-à-dire

des utilisateurs de notre proxy. Pour ce faire, il faut indiquer au navigateur
du client de passer par notre proxy pour pouvoir accéder à l'internet. Nous
allons faire la configuration sur les deux navigateurs les plus utilisés au
monde qui sont Mozilla Firefox et Internet Explorer

· Mozilla Firefox

1. Au niveau du menu navigateur, allez dans Outils => Options

2. Cliquez sur l'onglet Avancé

3. Sélectionner le sous-onglet Réseau

4. Cliquer sur le bouton Paramètres

5. Et enfin sélectionner Configuration manuelle du proxy puis remplir les

champs en donnant l'adresse IP

du proxy et le port

· Internet Explorer

1. Au niveau du menu navigateur, allez dans Outils => Options Internet

2. Cliquez sur l'onglet Connexions

3. Cliquez sur Paramètres Réseau

4. Et enfin sélectionner Utilisez un serveur proxy... puis remplir les

champs en donnant l'adresse IP du proxy et le port

Figure 4: Configuration manuelle d'Internet Explorer

De cette manière, nos clients sont configurés pour passer par notre proxy
avant de pouvoir accéder à internet. Mais par défaut, SQUID bloque toute
les connexions vers internet et l'image ci-dessous nous le démontre.
 Figure 5: Accès à Internet interdit au client

Pour que nos clients puissent bénéficier d'une connexion à Internet, nous
devons éditer le fichier [Link] en déclarant notre réseau local et
permettre la connexion à internet. On y ajoute ces lignes :

acl reseau_esp src [Link]/[Link] http_access allow

reseau_esp

reseau_esp est le nom ACL et la ligne suivante est la règle qui s'applique.
[Link] désigne l'adresse réseau dont le masque correspond à
[Link]. La ligne suivante autorise l'accès à internet à l'acl du nom
de reseau_ esp c'est-à-dire la ligne précédente.

On quitte le fichier en enregistrant les modifications apportées puis on

redémarre le serveur via la commande :

#/etc/init.d/squid restart

Notre serveur est alors opérationnel pour notre réseau local et joue bien
son rôle. Pour en avoir la preuve, on décide de télécharger deux fois de
suite un même fichier sur le même site et aussi on supprime complètement
ce fichier de notre disque dur avant de le retélécharger.
 Figure 6: Premier téléchargement du fichier

Figure 7: Deuxième téléchargement du fichier

On remarque que le téléchargement du fichier de 18,5 Mo a duré pour la

première fois 3min43s et que la vitesse de téléchargement a été en
moyenne de 85,2 Ko/s. Pour le second téléchargement, ce temps a
beaucoup baissé et est de 1min2s avec une augmentation de la vitesse
moyenne de téléchargement qui est pour cette fois ci de 306 Ko/s.

On en déduit alors que notre proxy fonctionne bien et joue son rôle de
cache car pour le second téléchargement le temps a fortement diminué et
la vitesse moyenne qui est de 306 Ko/s nous montre que le téléchargement
s'est effectué depuis notre serveur proxy qui a mis en cache ce fichier lors
du 1er téléchargement.

III.1.6. Forcer le passage par SQUID : proxy transparent

Utiliser un proxy nécessite normalement qu'on configure manuellement les
navigateurs de tous nos utilisateurs de manière à ce qu'ils interrogent
toujours le proxy, quelle que soit la cible. Cette tiche s'avère alors difficile si
nous avons un très grand nombre d'utilisateurs et aussi nos utilisateurs ont
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 un moyen d'éviter ceci en rendant 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 les ports 80 et 43 vers le port proxy sur son

port 8080 et ceci se fait sans problèmes sur notre 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 notre passerelle, en admettant que notre réseau
est dans [Link] et que notre proxy possède l'adresse [Link].
Nous supposons que le proxy est installé sur la machine qui assure
également le rôle de passerelle :

#iptables -t nat -A PREROUTING -s [Link]/[Link] -p tcp -m

multiport --dport 80,43 -j REDIRECT --to-ports 8080

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 8080 transparent

III.2. Authentification avec LDAP

Dans la mise en oeuvre jusqu'ici, nous ne faisions pas de contrôle sur les
utilisateurs, seulement sur les IPs des machines clientes. Nous pouvons
identifier nos utilisateurs lorsqu'ils vont surfer sur le Net. Dans ce cas, il
nous faudra mettre en place un système d'identification. Il y a plusieurs
méthodes disponibles pour authentifier nos utilisateurs du proxy. Elles font
toutes appel à un programme extérieur, différent suivant le moyen choisi.
Nous allons utiliser l'annuaire LDAP pour cette authentification.

III.2.1. Installation de LDAP

Comme annuaire LDAP, nous allons utiliser le logiciel OpenLDAP qui est
un logiciel libre basé sous la licence GNU GPL. La dernière version actuelle
stable est le 2.4.23. Nous allons procéder à une installation automatique
afin d'obtenir toutes les dépendances nécessaires. L'installation se fait via
la commande :

#apt-get install slapd

Figure 8: Installation annuaire LDAP

On remarque ainsi que le paquet slapd est installé avec quatre autres
paquets supplémentaires qui participent au bon fonctionnement de
l'annuaire.

III.2.2. Configuration de LDAP

Il faut tout d'abord indiquer dans le fichier /etc/default/slapd la localisation

du fichier de configuration de OpenLdap qui est /etc/ldap/[Link]. Pour
le faire, on doit ajouter cette ligne dans ce fichier :

SLAPD_CONF="/etc/ldap/[Link]"

Il faut par la suite modifier le fichier /etc/ldap/[Link]. Il faut autoriser les

clients qui utilisent le protocole LDAPv2 (par défaut seuls ceux utilisant
LDAPv3 sont autorisés). En effet, SQUID peut utiliser LDAPv2, donc dans
ce cas il faut décommenter cette ligne qui devient indispensable :

allow bind_v2
On ajoute aussi ces lignes suivantes :

suffix "dc=esp,dc=sn"

rootdn "cn=admin,dc=esp,dc=sn"

directory "/var/lib/ldap"

rootpw secret

Pour la dernière ligne, il faut remplacer secret par un vrai mot de passe qui
apparait alors

en clair ce qui est déconseillé. On peut crypter ce mot de passe via la

commande : #slappasswd

Puis on copie le résultat de cette commande à la place de secret. On

modifie enfin le

fichier /etc/ldap/[Link] et on ajoute ces deux lignes : BASE

dc=esp,dc=sn

URI ldap://[Link]:389

Pour terminer, on redémarre le serveur :

/etc/init.d/slapd restart

III.2.3. Ajout d'entrées dans l'annuaire LDAP

Ensuite, on peut consulter l'annuaire, ajouter, modifier, ou retirer des

entrées au moyen des commandes ldapsearch, ldapadd, ldapmodify,
ldapdelete (fournis avec OpenLDAP ) et de fichiers LDIF (LDAP Data
Interchange Format) ou bien à l'aide d'outils graphiques comme l'interface
php phpLDAPadmin. 2 nNdiginiINSErN1T 13 Sl1 NlIEWEir1NIidessous
avec ce fichier ldif :
Figure 9: Fichier ldif des entrées

Puis on ajoute ces informations dans l'annuaire de la manière ci-dessous :

Figure 10: Ajout des entrées dans l'annuaire

On peut aussi ajouter d'autres utilisateurs grlce aux fichiers ldif ou bien à
l'aide d'outils graphiques tel que phpLDAPadmin.

III.2.4. Configuration de SQUID pour l'authentification

Pour la configuration de SQUID, on utilise l'option squid_ldap_auth qui est

ce qu'on appelle un « authentication helper », c'est-à-dire un petit
programme qui détermine si un couple login/pass est correct : dans ce cas-
ci, il communique avec un annuaire LDAP afin de voir s'il existe une entrée
dans l'annuaire ayant le login indiqué dans un champ uid (ou cn ou autre si
on le précise), et le pass correspondant dans un champ userPassword. Ce
programme doit renvoyer la chaîne de caractères "OK" en cas de succès et
"ERR" en cas d'échec. On ajoute dans [Link] les lignes suivantes :

auth_param basic program /usr/lib/squid/ldap_ auth -b

ou=profs,dc=esp,dc=sn -u cn -h [Link]

auth_param basic children 5

auth_param basic realm Identification requise par firewall_esp auth_param

basic credentialsttl 2 hours

Les paramètres utilisés pour squid_ldap_auth sont :

· -b ou=profs,dc=esp,dc=sn : indique la base de l'arborescence de

l'annuaire à partir de laquelle on recherche l'utilisateur qui essaie de
s'authentifier

· -u cn : indique le type du login que l'on tape pour s'authentifier (par

exemple cn, uid...)

· -h [Link] : adresse du serveur LDAP, il est ici sur la même machine

que le proxy

Les trois dernières lignes servent à :

· auth_param basic children 5 : le nombre de processus d'authentification

qui seront lancés en permanence sur le serveur, chacun ne pouvant servir
qu'une demande à la fois

· auth_param basic realm Identification requise par firewall_esp : la chaîne

de caractères qui suit realm sera affichée par le navigateur utilisé lors de la
demande d'authentification, elle permet donc d'indiquer à l'utilisateur que
c'est au proxy qu'il essaie de se connecter

· auth_param basic credentialsttl 2 hours : la durée au bout de laquelle

l'authentication helper sera relancé. Cela ne veut pas dire que la fenêtre
demandant le login/pass va se réafficher (cela ne dépend pas de SQUID,
mais du navigateur utilisé). Concrètement, au bout du temps indiqué, il y
aura de nouveau un

échange de paquets LDAP entre Squid et le serveur LDAP pour authentifier

l'utilisateur, et éventuellement lui interdire l'accès.
Pour terminer on ajoute ces deux règles acl et on redémarre le serveur :

acl password proxy_auth REQUIRED http_access allow password

Cette règle indique que tous les utilisateurs authentifiés auront un accès
http mais suivant sa position par rapport à d'autres règles d'accès, cet
accès sera peut-être restreint.

La capture ci-dessous illustre bien cette authentification.

Figure 11: Authentification requise par le proxy

III.3. SQUID avec SquidGuard

III.3.1. Définition

SquidGuard est un module pour le serveur proxy SQUID. Ce module ajoute

des fonctionnalités plus avancées en matière de filtrage basé sur une liste
noire de sites web à bloquer et une liste blanche de sites à ignorer.
SquidGuard est ainsi un programme redirecteur distribué sous licence GPL,
c'est-à-dire que toutes les trames HTTP seront redirigées vers SquidGuard
pour être analysées puis filtrées. Il est nécessaire pour cela d'indiquer à
Squid que les trames devront transitées par SquidGuard avant de passer
dans le cache du Proxy. La fonction de filtre de SQUID est alors optimisée
dans le programme SquidGuard ce qui lui permet d'analyser des listes
d'URLS en un temps record. Une fois lancé, SquidGuard apparaîtra comme
un processus fils de SQUID.

[Link] et Configuration

L'installation se fait de manière automatique et simple avec la commande :

#apt-get install squidguard

L'installation a créé un répertoire /var/lib/squidguard/db, mais il est vide. Il

est destiné à contenir nos listes noires et blanches et deux scripts cgi dont
nous verrons l'utilité plus tard. Elle crée aussi le fichier de configuration
/etc/squid/[Link].
Nous n'avons pas encore les moyens de travailler efficacement, nous
n'avons pas encore de base de données de destinations, mais nous
pouvons déjà écrire un fichier de configuration pour SquidGuard, pour nous
mettre un peu dans le bain.

Figure 12: Configuration minimum de SquidGuard

Les deux premières lignes indiquent à SquidGuard oil trouver la base de

données des listes (que nous n'avons pas encore) ainsi que l'endroit où l'on
désire récupérer les logs.

Les sources sont là pour définir des groupes de clients. On les emploie
avec des adresses IP de notre réseau et lorsque l'identification du client est
requise, on peut alors définir des noms d'utilisateurs dans les sources.

Enfin, les « acl » permettent de définir quelle source peut aller (ou ne pas
aller) vers quelle(s) destination(s). Dans cette configuration seule la
machine [Link] (le serveur) peut aller dans n'importe quel site alors
que les autres clients de notre réseau n'ont accès à aucuns sites comme le
montre la figure 13.

Il faut maintenant placer le script cgi sur notre serveur apache :

#gunzip /usr/share/doc/squidguard/examples/[Link] #mv

/usr/share/doc/squidguard/examples/[Link] /usr/lib/cgi-bin/

#chmod +x /usr/lib/cgi-bin/[Link]

Il faut enfin modifier le fichier de configuration de SQUID pour qu'il invoque

SquidGuard en ajoutant ces dans le fichier et redémarrer le serveur
url_rewrite_program /usr/bin/squidGuard -c /etc/squid/[Link]

url_rewrite_children 5

Figure 13: Blocage Internet des clients par SquidGuard

Nous allons après ceci configurer les destinations. Un ensemble de

destinations est activement maintenu à jour par le Centre de Ressources
Informatiques de l'Université de Toulouse que nous trouverons à la
wébographie n°10. Nous allons choisir l'archive qui les contient toutes qui
est l'archive [Link].

#cd /var/lib/squidguard/db/

#wget [Link] #tar -xzvf [Link]

#cd blacklists
 Figure14: Les listes de destination de SquidGuard

Nous avons toutes les destinations souhaitables qui sont organisées par
catégorie par exemple : audio-video, chat, child, drogue, forums, game,
hacking, manga, porn, publicite, radio, violence etc.. Avant d'oublier ce
détail majeur, tout le contenu de /var/lib/squidguard/db/blacklists doit être
accessible en lecture et en écriture par l'utilisateur sous l'identité duquel
SQUID tourne. Pour nous, c'est l'utilisateur « proxy » :

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

Nous allons par exemple bloquer une liste de destination. Notre fichier de
configuration de SquidGuard est ainsi structuré :
 Figure 15: Exemple de configuration de SquidGuard

Dans cette configuration, comme à la figure 12, nous avons la localisation

des blacklists et les logs et la source de l'admin. Nous avons à la suite
ajouté une source « users » qui indique les utilisateurs de notre réseau. On
a ajouté à la configuration la destination « video » en indiquant les fichiers
de la liste. Dans les « acl a~, l'administrateur a accès à tous les sites tandis
que les autres utilisateurs n'ont pas accès aux sites de type audio-vidéo qui
sont définis dans ces listes.

SquidGuard, pour pouvoir travailler rapidement, n'utilise pas les fichiers

texte, mais des bases de données. Nous devons alors construire ces bases
avant le démarrage de SQUID (et donc de squidGuard) par la commande
ci-dessous puis on redémarre le serveur.

#squidGuard -C all

Lorsqu'on teste en entrant par exemple le site de « youtube » (site de

partage de vidéo), nous nous rendons compte que l'accès à ce site est
bloqué. Tous les domaines ou URL de type audio-vidéo seront ainsi
bloqués.
SquidGuard offre ainsi un filtrage très poussé. SquidGuard permet un
filtrage par URL, par adresses IP, par authentification, par plage horaire
etc..

III.4. Sécurisation du proxy

III.4.1. Association avec SSL

Afin de sécuriser les échanges d'informations avec les différents serveurs

LDAP, on peut utiliser SSL (Secure Sockets Layer), qui est en fait une
couche se rajoutant dans les paquets transmis, et permettant de crypter les
données transmises. On va ainsi utiliser SSL avec OpenLDAP et SQUID.

III.4.1.1. SSL avec OpenLDAP

Pour pouvoir utiliser SSL avec OpenLDAP, il faut y intégrer le support

SSL/TLS (TLS : Transport Layer Security). Il faut aussi au préalable avoir
installé OpenSSL. Pour pouvoir utiliser SSL, il faut créer les certificats,
reconfigurer le serveur, et le relancer en lui indiquant d'utiliser SSL. Pour
créer les certificats, on crée d'abord un répertoire accessible par
OpenLDAP puis on les crée avec les commandes suivantes :

#openssl genrsa -out [Link] 1024

#openssl req -new -key [Link] -out [Link] #openssl genrsa

-out [Link] 1024

#openssl req -new -x509 -key [Link] -out [Link]

#openssl x509 -req -in [Link] -out [Link] -CA [Link] -

Cakey [Link] -CAcreateserial

De nouveaux fichiers seront ainsi créer. Pour vérifier leur validé, on utilise
la commande : #openssl verify -CAfile [Link] [Link]

Nous avons utilisé des clés de 1024 bits pour plus de sécurité. Une fois
qu'on a les certificats nécessaires, on configure le serveur OpenLDAP pour
qu'il utilise SSL. Pour le faire, on copie les fichiers qu'on à généré à la
création des certificats à un endroit accessible par OpenLDAP par exemple
/usr/local/etc/openldap puis on modifier le fichier [Link] en ajoutant à la
fin les lignes suivantes :

TLSCertificateFile /usr/local/etc/openldap/[Link]

TLSCertificateKeyFile /usr/local/etc/openldap/[Link]
TLSCACertificateFile /usr/local/etc/openldap/[Link]

Notre serveur OpenLDAP est ainsi correctement configuré pour gérer le

SSL. Nous modifions ensuite le fichier /et c/default/slapd en intégrant dans
les services le port sécurisé de LDAP

SLAPD_SERVICES="ldaps:[Link]:636"

Nous configurons aussi les clients afin de leur indiquer l'emplacement du

certificat. Il faut aussi dire aux clients d'utiliser le port sécurisé de LDAP qui
est le 636. Pour cela on modifie le fichier [Link].

ssl on

URI ldaps://[Link]:636

TLS_CACERT /usr/local/etc/openldap/[Link]

Dorénavant, lorsqu'on s'authentifie auprès du serveur LDAP, le mot de

passe ne circule plus en clair sur le réseau, et on ne peut plus l'intercepter
à l'aide d'un sniffer.

III.4.1.2. SSL avec SQUID

Maintenant que notre annuaire fonctionne correctement avec SSL, on peut

passer à la configuration de SQUID. A priori, la seule chose à faire pour
que SQUID utilise SSL pour

communiquer avec le serveur LDAP est de rajouter ldaps:// en tête de

l'adresse du serveur dans l'appel de squidldapauth.

auth_param basic program /usr/lib/squid/ldap_auth -b

ou=profs,dc=esp,dc=sn -u cn -h ldaps://[Link]:636

Il ne reste plus qu'à relancer le serveur SQUID, et maintenant

l'authentification s'effectue de manière cryptée par SSL/TLS et ainsi aucun
mot de passe ne circule plus en clair sur le réseau lors de la demande
d'authentification.

III.4.2. Association avec un antivirus

Il nous est possible d'intégrer un antivirus à notre proxy SQUID. Il nous faut
alors un antivirus fonctionnel sur notre système. Nous décidons d'utiliser
l'antivirus Clamav qui un antivirus libre OpenSource. Clamav est un
antivirus sous licence GPL, qui fonctionne sur le principe d'une base de
données de signatures, comme la plupart des antivirus commerciaux. Son
installation ne pose aucun problème particulier. Il faut juste installer les
paquets clamav et clamav-freshclam. Ce dernier s'occupe de la mis à jour
de la base de données de l'antivirus. Cette mis à jour est automatique.

Figure 16: Installation de Clamav

Une fois l'installation terminée, Clamav tourne par défaut sous le nom d'un
utilisateur fictif clamav, créé lors de l'installation du paquetage. Le
démarrage de l'antivirus est

automatique et juste après l'installation il commence déjà à jouer son rôle.

Pour une configuration plus approfondie, on peut se référer à la
documentation officielle.

Avec un antivirus installé sur la machine oil tourne notre serveur SQUID,
nos requêtes HTTP destinées à nos clients seront ainsi scannées. De cette
manière, nous nous assurons que notre proxy SQUID n'enverra pas de
virus à nos clients. Ceci n'exclut pas non plus que nos clients peuvent se
dispenser d'un antivirus installé sur leur poste. Une sécurité supplémentaire
est toujours la bienvenue.

CONCLUSION

Nous avons essayé dans ce document de mettre en place un proxy SQUID

sécurisé avec une authentification des utilisateurs via l'annuaire LDAP. De
nos jours l'Internet, qui est un réseau mondial public avec plusieurs
menaces, est très utilisé et tout le monde y a accès. Se trouvant dans un
réseau privé et sécurisé, nous devons ainsi mettre en place une passerelle
sécurisée entre notre réseau et Internet.

Notre choix de passerelle c'est ainsi porté sur le proxy SQUID. Nous avons
vu dans ce document que son rôle primordial est le cache c'est-à-dire
garder les pages HTTP en local et les restituer aux clients. Il joue aussi le
rôle de filtre et de sécurité. Nous avons vu que SQUID peut bloquer l'accès
à l'Internet à certains utilisateurs selon des critères bien définis ou mrme
bloquer l'accès à certains sites que l'on juge dangereux ou inutiles. Nous
avons aussi vu que SQUID pouvait être couplé à un annuaire LDAP de telle
sorte que seuls nos utilisateurs de notre réseau disposant d'un compte
dans l'annuaire avec login et mot de passe peuvent avoir l'Internet. Pour
plus de sécurité, on peut crypter ces échanges de login et mot de passe
avec SSL. Nous avons aussi installé l'antivirus clamav sur la machine
serveur

Néanmoins, nous tenons à rappeler qu'un proxy n'est pas une solution
absolue et complète de sécurité. Comme on l'a déjà dit, il joue
primordialement une fonction de cache et de filtre. Donc il n'assure pas
entièrement la sécurité de notre réseau. Il faut en plus trouver d'autres
moyens de sécurité en mettant par exemple en place un firewall
correctement configuré qui remplie entièrement un rôle de sécurité. Notons
aussi qu'en matière de sécurité informatique, il n'y a ni recette miracle, ni
solution définitive.

GLOSSAIRE

ACL: Access Control List

BIOS: Basic Input Output Unit

CPU: Central Processing Unit

DIT: Directory Information Tree

DNS: Domain Name System

DSE: Directory Service Entry

GNU GPL: GNU General Public License

HTTP: HyperText Transfer Protocol

LDAP: Lightweight Directory Access Protocol LDIF: LDAP Data

Interchange Format

RAM: Random Access Memory

SGBD: Système de Gestion de Base de Données TCP/IP: Transfer Control

Protocol / Internet Protocol

1.

WEBOGRAPHIE

[Link]

2. [Link]

3. [Link]

4. [Link]

5. [Link]

6. [Link]

7. [Link]

8. [Link]

9. [Link]

10. [Link]

11. [Link]
 Le serveur de cache proxy Squid est une excellente solution pour une variété de nécessités de cache et de proxy,
de l'échelle de la succursale aux réseaux d'entreprise, tout en offrant des mécanismes de contrôle d' accès
granulaires et complets, et une supervision de paramètres critiques via le protocole Simple Network Manager
Protocol (SNMP). Lors de la sélection d'un système informatique pour une utilisation de serveur proxy cache
Squid avec de nombreux utilisateurs, assurez vous de le configurer avec une large quantité de mémoire vive,
étant donné que Squid utilise un cache mémoire pour des performances optimales.
1. Installation
2. Configuration
3. Références

Installation
Pour installer le serveur Squid, utilisez la commande suivante dans un terminal :

sudo apt-get install squid3

Configuration
Squid est configuré en modifiant les directives contenues dans le fichier de
configuration /etc/squid3/[Link]. Les exemples qui suivent illustrent quelques unes de ces directives qui
doivent être modifiées pour changer le comportement du serveur Squid. Pour une configuration plus approfondie
de Squid, voyez les sections de référence.
Avant de modifier le fichier de configuration, vous devriez faire une copie du fichier original et le protéger en
écriture, vous aurez alors les paramètres par défaut en référence à utiliser si besoin. Faites cette copie et protégez
la de l'écriture en utilisant la commande suivante :

sudo cp /etc/squid3/[Link] /etc/squid3/[Link]

sudo chmod a-w /etc/squid3/[Link]
1. Pour que votre serveur Squid écoute sur le port TCP 8888 à la place du port par défaut 3128, modifiez la
directive http_port comme ceci :

2. http_port 8888

3. Pour donner un nom d'hôte spécifique à votre serveur Squid, changez la directive visible_hostname. Ce
nom d'hôte n'a pas forcément besoin d'être le même que le nom d'hôte de la machine. Dans cet exemple il
est défini comme étant weezie.
4. visible_hostname weezie

5. En utilisant le contrôle d'accès de Squid, vous pouvez configurer l'accès aux services Internet gérés par le
proxy Squid de telle sorte qu'ils ne soient disponibles que pour les utilisateurs ayant certaines adresses IP.
À titre d'exemple, nous allons détailler le cas d'un accès uniquement aux utilisateurs du sous-réseau
[Link]/24 :
Ajoutez ce qui suit à la fin de la section ACL de votre fichier /etc/squid3/[Link] :
acl fortytwo_network src [Link]/24

Ensuite, ajoutez ce qui suit au début de la section http_access de votre

fichier /etc/squid3/[Link] :
http_access allow fortytwo_network

6. En utilisant les excellentes fonctionnalités de contrôle d'accès de Squid, vous pouvez configurer
l'utilisation des services Internet par proxy Squid pour n'être disponibles que pendant les heures normales
 de bureau. Par exemple, nous allons illustrer l'accès par les employés d'une entreprise qui opère entre
09h00 et 17h00, du lundi au vendredi, et qui utilise le sous-réseau [Link]/24 :
Ajoutez ce qui suit à la fin de la section ACL de votre fichier /etc/squid3/[Link] :
acl biz_network src [Link]/24
acl biz_hours time M T W T F 9:00-17:00

Ensuite, ajoutez ce qui suit au début de la section http_access de votre

fichier /etc/squid3/[Link] :
http_access allow biz_network biz_hours

Après avoir fait les changements au fichier /etc/squid3/[Link], enregistrez le fichier et redémarrez
l'application serveur squid pour effectuer les changements en utilisant la ligne de commande suivante dans un
terminal :
sudo service squid3 restart

Références
Site web de Squid
La page du Wiki Ubuntu consacrée à Squid.