Mise en place d'un proxy Squid sécurisé avec authentification LDAP

ECOLE SUPERIEURE POLYTECHNIQUE

	ECOLE SUPERIEURE MULTINATIONALE
DEPARTEMENT GENIE INFORMATIQUE	DES TELECOMMUNICATIONS

MEMOIRE DE FIN DE CYCLE
Pour l'obtention du :
DIPLOME DE TECHNICIEN SUPERIEUR EN TELEINFORMATIQUE
(DTST)

Thème:

MISE EN PLACE D'UN PROXY SQUID SECURISE
AVEC AUTHENTIFICATION LDAP

Lieu de stage : Ecole Supérieure Polytechnique de Dakar

M. Abdoulaye Sall

Année universitaire : 2009 - 2010

Djiby Thiaw

Présenté par : Encadré par :

Table des matières

Table des matières 1

Table des figures 3

Avant-propos 4

Introduction 5

CHAPITRE I : PRESENTATION GENERALE 6

I.1. PRESENTATION DE L'ESP 6

I.1.1. HISTORIQUE 6

I.1.2. ORGANISATION 6

I.1.3. OBJECTIFS ET MISSIONS 8

I.2. PRESENTATION DE L'ESMT 9

I.2.1. Historique 9

I.2.2. Formations 9

I.2.3. Organigramme 10

CHAPITRE II : PRESENTATION DES OUTILS NECESSAIRES 11

II.1. LE PROXY SQUID 11

II.1.1. Définition 11

II.1.2. Fonctionnement et Rôles 11

II.1.2.1. Fonctionnement 11

II.1.2.2. Rôle 12

II.2. L'ANNUAIRE LDAP 13

II.2.1. Définition 13

II.2.2. Fonctions 13

II.2.3. Structure 14

CHAPITRE III : MISE EN OEUVRE 16

III.1. MISE EN PLACE DU PROXY SQUID 16

III.1.1. Configuration matérielle et logicielle 16

III.1.2. Installation 17

III.1.2.1. Installation manuelle 17

III.1.2.2. Installation automatique 18

III.1.3. Configuration 18

III.1.3.1. Configuration de la section réseau 19

III.1.3.2. Configuration de la taille du cache 19

III.1.3.3. Chemin d'acc~s aux fichiers de SQUID 20

III.1.3.4. Comportement avec les applications externes 21

III.1.3.5. Les temps d'attente . 22

III.1.4. Contrôle des accès 22

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

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

III.2. AUTHENTIFICATION AVEC LDAP 28

III.2.1. Installation de LDAP 29

III.2.2. Configuration de LDAP 29

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

III.2.4. Configuration de SQUID pour l'authentification 32

III.3. SQUID AVEC SQUIDGUARD 33

III.3.1. Définition 33

III.3.2. Installation et Configuration 34

III.4. SECURISATION DU PROXY 38

III.4.1. Association avec SSL 38

III.4.1.1. SSL avec OpenLDAP 38

III.4.1.2. SSL avec SQUID 39

III.4.2. Association avec un antivirus 40

Conclusion 42

Glossaire 43

Bibliographie / « Wébographie » 44

Table des figures

Figures :

Figure 1: Organigramme de l'ESMT 10

Figure 2: Principe de fonctionnement 12

Figure 3: Exemple de DIT 15

Figure 4: Configuration manuelle d'Internet Explorer 25

Figure 5: Accès à Internet interdit au client 25

Figure 6: Premier téléchargement du fichier 26

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

Figure 8: Installation annuaire LDAP 29

Figure 9: Fichier ldif des entrées 31

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

Figure 11: Authentification requise par le proxy 33

Figure 12: Configuration minimum de SquidGuard 34

Figure 13: Blocage Internet des clients par SquidGuard 35

Figure14: Les listes de destination de SquidGuard 36

Figure 15: Exemple de configuration de SquidGuard 37

Figure 16: Installation de Clamav 40

Avant-propos

L'école supérieure polytechnique (E.S.P) forme en deux années d'études des techniciens supérieurs, et en cinq ans des ingénieurs dans plusieurs spécialités.

Dans le cadre de leur formation les étudiants de fin de chaque cycle sont tenus d'effectuer un stage pratique au sein d'une entreprise ou d'un service informatique.

Ce stage est effectué dans le but :

· De fournir aux étudiants la possibilité de mettre en oeuvre les connaissances théoriques acquises tout au long de leur formation.

· D'initier les futurs techniciens supérieurs aux réalités du milieu professionnel et de leur permettre de se faire la main sur des projets d'envergures.

Au terme de ce stage un mémoire doit être rédigé sur un problème qui a été étudié durant ce stage.

INTRODUCTION

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 I

Chapitre I : Présentation générale

I.1. 3 011-1t0NRn d1- lk 63

I.1.1. Historique

L'Ecole Supérieure Polytechnique de Dakar (ESP) est un établissement public à caractère administratif doté de la personnalité juridique et de l'autonomie financière. L'École Supérieure Polytechnique fait partie intégrante de l'université Cheikh Anta DIOP de Dakar. Elle a été créée par la loi n° 94-78 du 24 novembre 1994. A l'origine, l'ESP regroupait en son sein :

· La division industrielle de l'Ecole Nationale Supérieure Universitaire de Technologie (ENSUT)

· L'Ecole Polytechnique de Thiès (EPT)

· La section technique industrielle de l'Ecole Normale Supérieure d'Enseignement Technique et Professionnel (ENSETP)

A la suite de diverses réformes intervenues, notamment la revitalisation de l'ENSETP, la création de l'Université de Thiès et le rattachement de l'Institut Supérieure de Gestion à l'ESP, l'Ecole Supérieure Polytechnique est seulement composée présentement de la division tertiaire de l'ex ENSUT.

I.1.2. Organisation

Etablissement public à vocation régionale, sous la tutelle du Ministère de l'Education, L'Ecole Supérieure Polytechnique est rattachée à l'Université Cheikh Anta DIOP de Dakar. Elle assure des formations dans six départements qui la composent. Ces formations se font en cours du soir comme en cours du jour, aussi bien en formation initiale qu'en formation continue pour le compte des entreprises, sociétés et particuliers. Ces six départements sont :

·

Le département Génie Informatique : Ce département forme des Techniciens supérieurs, Assistants ingénieurs, des Ingénieurs en Informatique, TéléInformatique et en Télécommunication. Les étudiants y mènent des activités de recherche dans les domaines mentionnés ci-dessous visant au perfectionnement permanent, à l'adaptation et à la participation à l'évolution scientifique et technologique. On y procède des expertises dans le cadre de la formation à l'intention des entreprises publiques et privées. Le département génie informatique offre les formations suivantes :

> DUT (Diplôme Universitaire de Technologie)

ü Informatique

ü Télécoms et réseaux

> DIC (Diplôme d'Ingénieur de Conception)

ü Informatique

> DST (Diplôme Supérieur de Technologie)

ü Informatique

ü Téléinformatique en partenariat avec l'École Supérieure Multinationale de Télécommunication (ESMT)

> DIT (Diplôme d'Ingénieur Technologue)

ü Informatique

> MP (Master Professionnel)

ü Téléinformatique (en partenariat avec l'ESMT)

> Formation à la carte

ü Logiciels libres

ü Génie logiciel

· Le département génie Mécanique Présenté et soutenu par Djiby Thiaw

· Le département Génie Civil

· Le département Génie Electrique

· Le département Génie Chimique et Biologie Appliquée

· Le département Gestion

I.1.3. Objectifs et missions

L'ESP a pour objectif et missions de :

· Former tant sur le plan théorique que pratique des :

ü Techniciens Supérieurs

ü Ingénieurs Technologues

ü Ingénieurs de Conception

· Managers en Gestion d'Entreprises

ü Docteurs

· Dispenser un enseignement supérieur en vue de préparer aux fonctions d'encadrement dans :

ü la Production

ü la Recherche Appliquée

ü les Services

· Organiser des enseignements et des activités de recherche visant :

ü au perfectionnement permanent

ü à l'adaptation et à la participation à

ü l'évolution scientifique et technologique

ü l'évolution économique et managériale

· Procéder à des expertises à l'intention des entreprises publiques et privées Pour plus de détails, on peut se référer au site officiel de l'ESP (wébographie n°1). Présenté et soutenu par Djiby Thiaw

8

I.2. 3 OTIVEaEiRn 1dI1Ar 607

I.2.1. Historique

L'Ecole Supérieure Multinationale des Télécommunications (ESMT) de Dakar a été créée en 1981 à l'initiative de 7 pays d'Afrique de l'Ouest qui sont le Bénin, le Burkina Faso, le Mali, la Mauritanie, le Niger, le Sénégal et le Togo avec le concours de la coopération internationale. Cette genèse s'est faite dans le cadre d'un projet de programmes des nations unies pour le développement (PNUD). Depuis 1986, l'école dispose d'un statut diplomatique. En 1998, la Guinée Conakry s'ajoutait comme pays fondateur.

I.2.2. Formations

L'ESMT dispose des cours en formation initiale ou continue. En formation initiale, nous avons plusieurs domaines d'études qui sont :

· Le Cycle Préparatoire Intégré (CPI)

· Le Diplôme de Technicien Supérieur (DTS) : avec quatre spécialisations qui sont : Technique Télécom, Technico-commercial, Réseau et Données, Téléinformatique ( en partenariat avec L'ESP)

· La Licence Professionnelle (LP) : avec deux spécialisations qui sont la Licence Professionnelle en TIC et la Licence Générale en Science de l'Ingénieur

· Le Diplôme d'Ingénieur : avec trois spécialisations : Ingénieur des Travaux Télécoms (IGTT), Ingénieur de Conception (INGC), Ingénieur en Téléinformatique (en partenariat avec l'ESP)

· Le Mastère Spécialisé : en Gestion des Télécoms, Réseaux Télécoms et Téléinformatique (en partenariat avec l'ESP)

· Le Mastère Professionnel : en Politique et Régulation des TIC et Réseaux et Services TIC

Présenté et soutenu par Djiby Thiaw

L'ESMT développe aussi des sessions de formation continue. Sous forme de séminaires et d'ateliers, elles participent au perfectionnement des techniciens, ingénieurs et cadres des entreprises et institutions africaines.

I.2.3. Organigramme

Le schéma ci-dessous, tiré du site officiel de L'ESMT (wébographie n°2), illustre l'organisation et la structure de L'ESMT.

Figure 1: Organigramme de l'ESMT

CHAPITRE II

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 192.168.2.0 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 http://www.squid-cache.org. La dernière version actuelle stable est la version 2.7.STABLE7. Une fois le logiciel au format tar.gz (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 squid-2.7.STABLE7.tar.gz --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 squid.conf. 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/squid.conf. 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 access.log qui contient tous les accès au cache. Par défaut c'est le fichier /var/log/squid/access.log

cache_log DirectoryPath/filename : idem que pour access_log avec le fichier /var/log/squid/cache.log 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/store.log 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/resolv.conf 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 squid.conf en déclarant notre réseau local et permettre la connexion à internet. On y ajoute ces lignes :

acl reseau_esp src 192.168.2.0/255.255.255.0 http_access allow reseau_esp

reseau_esp est le nom ACL et la ligne suivante est la règle qui s'applique. 192.168.2.0 désigne l'adresse réseau dont le masque correspond à 255.255.255.0. 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 1^er 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 192.168.2.0 et que notre proxy possède l'adresse 192.168.2.3. Nous supposons que le proxy est installé sur la machine qui assure également le rôle de passerelle :

#iptables -t nat -A PREROUTING -s 192.168.2.0/255.255.255.0 -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/slapd.conf. Pour le faire, on doit ajouter cette ligne dans ce fichier :

SLAPD_CONF="/etc/ldap/slapd.conf"

Il faut par la suite modifier le fichier /etc/ldap/slapd.conf. 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/ldap.conf et on ajoute ces deux lignes : BASE dc=esp,dc=sn

URI ldap://127.0.0.1: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 squid.conf les lignes suivantes :

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

ou=profs,dc=esp,dc=sn -u cn -h 127.0.0.1

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 127.0.0.1 : 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.

III.3.2.Installation 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/squidGuard.conf.

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 192.168.2.3 (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/squidGuard.cgi.gz #mv /usr/share/doc/squidguard/examples/squidGuard.cgi /usr/lib/cgi-bin/

#chmod +x /usr/lib/cgi-bin/squidGuard.cgi

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/squidGuard.conf

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 blacklists.tar.gz.

#cd /var/lib/squidguard/db/

#wget ftp://ftp.univ-tlse1.fr/blacklist/blacklists.tar.gz #tar -xzvf blacklists.tar.gz

#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 serverkey.pem 1024

#openssl req -new -key serverkey.pem -out servercert.req #openssl genrsa -out cakey.pem 1024

#openssl req -new -x509 -key cakey.pem -out cacert.pem

#openssl x509 -req -in servercert.req -out servercert.pem -CA cacert.pem -Cakey cakey.pem -CAcreateserial

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

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 slapd.conf en ajoutant à la fin les lignes suivantes :

TLSCertificateFile /usr/local/etc/openldap/servercert.pem

TLSCertificateKeyFile /usr/local/etc/openldap/serverkey.pem TLSCACertificateFile /usr/local/etc/openldap/cacert.pem

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:127.0.0.1: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 ldap.conf.

ssl on

URI ldaps://127.0.0.1:636

TLS_CACERT /usr/local/etc/openldap/cacert.pem

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://127.0.0.1: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

http://www.esp.sn

2. http://www.esmt.sn

3. http://www.monassistance.fr/CCM/lan/proxy.php

4. http://www.deckle.co.za/squid-users-guide/Main_Page

5. http://www-igm.univ-mlv.fr/~dr/XPOSE2003/Squid/ch01s02.html

6. http://www.locoche.net/proxy.php

7. http://fr.wikipedia.org/wiki/Ldap

8. http://www.espace-groupware.com/squid/authentification-ldap/doc.html

9. http://irp.nain-t.net/doku.php/220squid:start

10. ftp://ftp.univ-tlse1.fr/blacklist/

11. http://doc.ubuntu-fr.org/clamav