Solution  de  filtrage  web  Libre  SQUID  

CheminadeJulien  

 

SQUID  –  SQUIDGUARD  –  CLAMAV    

2

Table of Contents

I)  Introduction  ..................................................................................................................................  3  Présentation  des  objectifs  du  projet  ..........................................................................................................  3  Solution  proposer  ..............................................................................................................................................  3  Annonce  du  plan  .................................................................................................................................................  3  Solution  de  filtrage  web  libre.  ..........................................................................................................  4  Configuration  du  serveur  ...............................................................................................................................  4  Configuration  matérielle  .................................................................................................................................  4  Configuration  logicielle  ...................................................................................................................................  4  Interfaces  réseau.  ...............................................................................................................................................  4  

Infrastructure  réseau.  ......................................................................................................................................  5  Installation  d’un  serveur  DHCP  ...................................................................................................................  5  Configuration  .......................................................................................................................................................  6  

Serveur  mandataire  libre  Squid3.  ...............................................................................................................  7  Définition  et  présentation  de  Squid3  .........................................................................................................  7  Installation  de  Squid3.  .....................................................................................................................................  7  Configuration  Squid  ..........................................................................................................................................  9  

Firewall  Iptables  ...............................................................................................................................................  13  SquidGuard  .........................................................................................................................................................  13  Base  de  Donnée  SquidGuard  .......................................................................................................................  14  Définition  des  groupes  ...................................................................................................................................  14  Définition  des  filtres  .......................................................................................................................................  15  Intégration  de  SquidGuard  à  Squid  .........................................................................................................  16  

ClamAV  .................................................................................................................................................................  17  Installation  .........................................................................................................................................................  17  SquidClamAV  .....................................................................................................................................................  18  

Test  .........................................................................................................................................................................  19  Conclusion  ...........................................................................................................................................................  20  

3

I) Introduction

Présentation des objectifs du projet

L’objectif du projet est l’utilisation d’un serveur mandataire (proxy) afin de filtrer tous les accès

sur les protocoles liés à l’utilisation d’internet, principalement HTTP et HTTPS puis le filtrage

des URL et des noms de domaines qui envoie de la publicité sur les pages web et ,faire une

analyse antivirale du flux web.

Solution proposer

Installation d’un serveur mandataire transparent pour le protocole HTTP / HTTPS et génération

automatique de certificat, avec filtrage de la publicité grâce à une analyse de SquidGuard sur

une liste noire est analyse antiviral grâce à ClamAV de tout le flux WEB.

Annonce du plan

Premièrement, je présenterai la configuration matérielle et logicielle du serveur et un plan de

l’infrastructure du réseau, puis nous enchainerons avec la présentation du serveur mandataire

(proxy) Squid dans sa version 3, et enfin je détaillerai sa configuration et son implication dans le

projet.

Deuxièmement, nous verrons le programme SquidGuard, ça configuration, sont intégration à

squid et la place qu’il a au sein de la solution proposée.

Ensuite je ferais la présentation de l’antivirus libre CLAMAV, sa configuration et son intégration

à squid grâce au plug-in SquidClamAV.

Enfin je terminerais cette présentation de projet avec une série de tests et une conclusion sur la

solution apportée.

4

Solution de filtrage web libre.

Configuration du serveur

Configuration matérielle

J’ai mis en application cette solution sur une machine physique, disposant d’un processeur Intel

64 bits, 1 GO de mémoire RAM, 2 interfaces réseau Ethernet et d’un disque dur de 500 GO.

Configuration logicielle

Le système d’exploitation sur lequel repose cette solution est un Linux Debian Wheezy 7.8

J’ai fait le choix de ne pas installer d’interface graphique, car je n’en ai pas besoin pour mettre

en place cette solution, ce qui permet d’économiser les ressources du système et de le rendre

plus performant.

Afin de pouvoir installer Debian, voici un lien qui vous sera utile :

• Pour système 32 bits : https://www.debian.org/releases/stable/i386/

• Pour système 64 bits : https://www.debian.org/releases/stable/amd64/

Une fois Debian installer il est très important d’aller éditer dans le fichier : /etc/sysctl.conf

à la ligne ou ce trouve #net.ipv4.ip_forward =0 il faut : enlever le caractère # en début de ligne

et passer la valeur de 0 à 1 pour obtenir le résultat suivant :

net.ipv4.ip_forward =1

Cette ligne permet de dire au système que l’on veut qu’il agisse comme un routeur au sein du

réseau en faisant de la redirection de paquets.

Figure 1 : configuration ip_forward

Interfaces réseau.

Le paramétrage des interfaces réseau du serveur est les suivantes :

• Eth0 : carte avec une interface paramétrée dynamiquement sur le pool d’adresse du

DHCP de l’entreprise.

5

• Eth1 : carte paramétrée avec une interface statique en 10.0.0.1/24, c’est cette carte qui

fait la liaison directe avec le réseau « LAN » de la solution.

Infrastructure réseau.

Figure 2 : schéma de l’infrastructure réseau

Installation d’un serveur DHCP

Dans un premier temps, après avoir installé et paramétré Debian puis configuré les interfaces

réseau nous allons procéder à la configuration d’un serveur DHCP afin de pouvoir administrer

dynamiquement des adresses IP aux ordinateurs présents sur notre réseau LAN.

Récupérer le paquet isc-dhcp-server grâce à la commande aptitude

Figure 3 : installation serveur DHCP

6

Configuration

La configuration du serveur DHCP me permet d’attribuer des adresses IP dynamiquement sur la

plage d’adresse 10.0.0.10/16 à 10.0.0.100/16. J’ai défini l’interface eth1 comme routeur. Le

serveur DNS est celui de la box internet.

Figure 4 : configuration isc-dhcp-server

Quelques petites précisions sur les paramètres présents dans la figure 4 :

• Default-lease-time : temps par défaut du renouvellement du bail.

• Max-lease-time : durée maximale du bail.

• Log-facility local7 ; enregistre les logs dans un fichier dédié dans /var/log/

• Subnet / netmask : précise sur quel réseau nous voulons appliquer le pool DHCP.

• Rang 10.0.0.10 10.0.0.100 : définit le rang d’adresse qui sont attribués

dynamiquement.

• Option subnet-mask : définis le masque réseau des adresses IP administrées

dynamiquement.

• Option broadcast-address : définis l’adresse de broadcaste pour les IP adressés

dynamiquement.

• Option routers : définis le routeur pour les adresses IP du rang.

Il y a un deuxième fichier de configuration dans le répertoire /etc/default.

Modifiez le fichier isc-dhcp-server.conf afin de préciser sur quelle interface écoute le serveur

DHCP, dans mon cas j’ai choisi l’interface eth1.

7

Relancez le service du server dhcp afin que ça configuration soit opérationnel :

/etc/init.d/isc-dhcp-server restart

Serveur mandataire libre Squid3.

Définition et présentation de Squid3

Squid3 est un serveur mandataire (proxy) et un mandataire inverse libre et très performant il est

capable d’utiliser les protocoles FTP, HTTP, Gopher, et HTTPS. Contrairement aux serveurs

proxy classique un serveur Squid gère toutes les requêtes en un seul processus d’entrée/sortie,

non bloquant.

Squid est généralement utilisé dans certaines entreprises et universités pour des fonctions de

filtrage d’URL en tant que tampon (les pages internet sont stockées localement ce qui évite

d’aller les recharger plusieurs fois et permet d’économiser la bande passante d’internet).

Installation de Squid3.

Afin de pouvoir appliquer un filtrage avec squid3 sur le protocole HTTPS, pour la réalisation de

cette solution nous ne pouvons pas l’installer par la forme classique d’un apt-get ou

d’APTITUDE. Il va falloir récupérer la source du paquet et de ses dépendances et compiler

squid avec l’option --enable-ssl.

Premièrement nous devons récupérer les sources du paquet squid3 et de ses dépendances ainsi

que les paquets qui nous seront nécessaires à la compilation :

Dans un premier temps, nous aurons besoin des paquets suivant afin de pouvoir compiler

Squid3 : build-essential fackroot devscripts gawk gcc-multilib dpatch

Figure 5 : source nécessaire a la compilation de squid3

Ensuite, il faut installe des dépendances liées a squid affin de préparer notre système a ça

compilation.

Figure 6 : récupération de la source de squid3

8

Répéter l’opération pour openssh et openssl qui sont nécessaire afin de compiler sans erreurs.

Figure 7 : récupération dépendances squid3 liées au filtrage HTTPS

Figure 8 : source nécessaire lors de la compilation de squid3

Une fois ces opérations effectuées il va falloir que nous téléchargions le paquet Squid3, mais

non compilé. Pour ce faire, un répertoire est prévu a cet effet dans Debian : /usr/src

J’ai choisi de baser la solution sur Squid3 dans ça version 3.1.20 qui est celle proposer lors d’un

aptitude install.

Afin de la récupérer, utilisez la commande suivante :

wget http://www.squid-cache.org/Versions/v3/3.1/squid-3.1.20.tar.gz

L’archive peut aussi être récupéré avec la commande :

aptitude source squid3

Une fois téléchargé, décompressez l’archive à l’aide de la commande tar

tar –xvfz squid-3.1.20.tar.gz

Figure 9 : extraction squid

Changer de répertoire : cd squid-3.1.20 puis éditez le fichier rules avec la commande :

nano /debian/rules affin d’y ajouter la ligne --enable-ssl \

Une fois cette option spécifier retournez à la racine du dossier de squid et, utiliser la commande

./configure afin d’appliquer les paramètres de configuration pour la compilation. (Cette

opération peut être longue)

Maintenant nous allons compiler le paquet afin de produire des fichiers installables sous format

.deb pour faire cette action nous allons utiliser la commande debuild

Figure 10 ; création de .deb pour squid et ces dépendances

9

Cette opération qui crée l’installateur de squid avec l’option que nous lui avons spécifié peut

être très longue. Lors de la réalisation de la solution, la durée de cette opération est d’au moins

20 minutes.

Si elle a était réalisée sans erreurs, le répertoire parent /usr/src, contient désormais plusieurs

fichiers .deb :

• Squid-cgi 3.1.20.deb

• Squid3-common 3.1.20.deb

• Squid3-dbg_3.1.20.deb

• Squid3_3.1.20.deb

• Squidclient_3.1.20.deb

Tous ces paquets sont nécessaires au fonctionnement de squid. Installez-les en utilisant la

commande dpkg –i comme présenté dans les captures qui vont suivre.

Figures 11, 12, 13, 14, 15 : installation des paquets compilés

Une fois les paquets installés, nous allons passer à la configuration de squid. Cette configuration

sera en fonction de l’architecture du réseau, il vous sera surement nécessaire de l’adapter à

votre environnement.

Configuration Squid

La configuration de Squid se fait toutes dans un seul fichier : le fichier squid.conf qui contient

des centaines de lignes. Ce fichier est présent dans le répertoire /etc/squid3, je présenterai les

parties les plus importantes de la configuration et celles qui sont nécessaires à la solution. Ces

paramètres seront à adapter selon votre réseau et les choix que vous feriez dans votre politique

de filtrage.

10

Les ACL

Les ACL sont des paramètres qui vous permettent de définir quelles adresses IP peuvent ou ne

peuvent pas accéder au serveur mandataire. Cela peut être une autorisation par rapport à une

adresse source qui est alors définie par le mot clé src ou une adresse IP de destination définit

par le mot clé dst.

La figure suivante montre les acl présents sur la configuration de mon serveur squid.

Figure 16 : ACL Squid

Figure 17 : ACL squid

Ici dans la figure 16 sont défini des acl pour des réseaux : par exemple notre réseau LAN

10.0.0.0/16 est décrit ici

Dans la deuxième partie de la configuration des ACL de squid sont défini, des ports dits

‘’surs’’ ses ACL nous serviront plus tard à définir des réglés d’accès à notre serveur mandataire

avec un filtrage plus fin

Configuration des ports de Squid

Cette partie du fichier de configuration concerne les ports sur lesquelles Squid écoute pour

recevoir le flux HTTP / HTTPS

Figure 18 ; Configuration ports Squid

11

En premier lieu j’ai attribué le port 3128 pour le protocole HTTP. Le paramètre intercept

permet de dire à Squid d’agir sur ce port de manière qu’il intercepte toutes les trames HTTP.

J’ai attribué le port 3129 au filtrage du protocole HTTPS , le paramètre ssl-bump permet

d’établir une connexion SSL entre le serveur proxy Squid et le site internet : google par exemple.

Ensuite, il utilise le certificat mis en paramètre afin d’établir la connexion entre le serveur proxy

et l’utilisateur.

Certificat SSL

Le certificat à était générer avec le paquet Openssl, je présenterai ça génération plus tard.

Pour l’instant, voici la partie de la configuration de Squid où sont définis les certificats SSL.

Figure 19 : définition du certificat ssl dans la configuration de squid

Règle d’accès

Les règles d’accès permettent, d’autoriser, de restreindre ou bloquer le flux HTTP des

utilisateurs, elles se présentent sous la forme suivante :

http_access allow reseau

Cette règle définit l’accès au protocole HTTP à l’acl réseau qui correspond à notre réseau LAN.

Figure 20 règles d’accès pour le flux http

12

Ici dans la figure 20 l’on peut observer deux mots clés après http_access, allow et deny.

Allow, permets de dire que l’acl qui se trouve après ce terme est autorisé à utiliser et recevoir le

flux HTTP.

Deny, quant à lui, refuse l’accès à l’acl qui le suit.

La ligne de configuration http_access deny !Safe_ports fait référence aux acl définit plus haut

dans la figure 17 elle permet de rajouter un peut de sécurité à notre serveur proxy en refusant

l’accès au flux HTTP à tous les ports qui sont différents de ceux définit comme étant des ports

dits « sur ».

SSL_Bump

SSL_bump est le paramètre qui va nous permettre d’établir une connexion SSL entre notre

serveur proxy et le site demander par le client, puis après grâce au certificat de connexion SSL

définit plus haut la connexion est établit entre le client et le serveur proxy. Ce qui nous permet

au final de pouvoir filtrer les trames HTTPS.

Figure 21 réglages SSL_bump

Le paramètre SSL_bump est considéré comme une règle d’accès qui peut être défini sur des

ACL. Ici, nous refusons l’accès aux sites qui n’ont pas de certificat vérifié par une autorité de

certification, sinon nous autorisons l’accès au flux HTTPS à toutes les connexions. Ses

paramètres peuvent être affinés selon les règles de filtrages que vous souhaitez appliquer.

Répertoire de cache

Le répertoire de cache correspond à l’espace que vous définissez dans la configuration de Squid

qui servira à la mise en cache des pages web, afin de les charger en local si elles sont

redemandées par les clients pour libérer la bande passante internet.

Figure 22 : Définition du répertoire de mise en cache

13

Une fois la configuration de Squid terminé, démarrer le service grâce à la commande suivante :

Figure 23 : démarrage du service squid

Firewall Iptables

Maintenant que notre serveur proxy est opérationnel, nous allons configurer Iptables afin de

définir des règles de redirection pour le bon fonctionnement de notre configuration

Premièrement, nous allons définir des règles de redirection dans la chaine PREROUTING de la

table NAT pour rediriger le trafique des ports 80 et 443 vers les ports définit dans la

configuration de Squid qui sont 3128 pour le 80 et 3129 pour le 443

Figure 24 : règles de redirection des ports 80 et 443.

Puis nous définirons une règle avec le mot clé MASQUERAD dans la chaine POSTROUTI NG

de la table NAT afin que toutes les connexions en sorties de notre serveur proxy aient toutes la

même adresse IP.

Figure 25 règle de post routage

SquidGuard

L’installation de SquidGuard se fait de façon traditionnelle grâce aux paquets apt-get ou bien

aptitude.

Une fois le paquet récupéré, la configuration de SquidGuard ce situe dans /etc/SquidGuard.

Elle est composée de 3 parties :

• La définition du répertoire qui contient les logs, et celui où est contenue la base de

données de SquidGuard.

• La définition de groupes de restriction par l’adresse IP

• la définition des restrictions à appliquer selon le filtrage du contenu voulu et

l’application de ces restrictions sur les ACL

14

Base de Donnée SquidGuard

La base de données de SquidGuard est essentiellement constituée de fichiers textes regroupent

les noms de domaines et les URL classées par catégories, elle peut être comparé avec une liste

de sites internet. Pour constituer la base de données de SquidGuard, j’ai utilisé une liste gratuite

éditée par l’Université de Toulouse Capitole.

Premièrement, nous allons récupérer cette liste grâce à wget.

Figure 26 : récupération de la basse de donnée squidguard

Puis nous la déplaçons dans un répertoire créé lors de l’installation de SquidGuard.

Figure 27 : déplacement de la base de donnée dans le répertoire crée lors de l’installation du paquet

Enfin, il faut extraire l’archive grâce à la commande tar –xvz.

Une fois ces opérations effectuer nous allons éditer la configuration de SquidGuard dans le

fichier /etc/SquidGuard/SquidGuard.conf.

La première partie du fichier concerne la base de données et les fichiers logs

Figure 28 : emplacement de la base de données squidguard et des fichiers de logs

Ensuite il faut définir les sources sur lesquelles nous allons appliquer le filtrage.

Définition des groupes

Figure 29 : création d’un groupe pour le filtrage du contenu basé sur le rang d’adresse IP du réseau LAN

15

Nous créons donc un groupe sur la plage IP que notre serveur DHCP applique qui correspond

au réseau LAN.

Ensuite nous allons établir les filtres que nous voulons appliquer selon les fichiers qui sont

disponibles dans notre base de données, ici je définis uniquement un filtre sur les publicités,

mais sachez que la liste de l’université de Toulouse est composée de plein d’autres catégories

couvrant un large panel de sites internet différents.

Définition des filtres

Figure 30 : définition des filtres basés sur l’arborescence de la base de données squidguard

Ici sont écrit les chemins ou ce situe les listes concernant les filtres présents dans la base de

données de SquidGuard.

Le mot clé ads défini les listes présentes dans le répertoire :

/var/lib/squidguard/db/blacklists/ads .

Cette partie de la configuration permet d’inclure les listes de nom de domaines ou les URL sur

laquelle nous voulons appliquer des filtres.

La lise white correspond quand a elle a une liste d’URL et de nom de domaine ayant un

contenu consultable par tous les utilisateurs.

Une fois les listes de filtrages établies la partie suivante de la configuration concerne

l’application de ces listes aux groupes définit plus haut.

Figure 31 : définition des filtres appliqués sur les groupes d’utilisateurs

16

Pour autoriser un contenu il suffit d’écrire le nom de la liste comme « white » or si vous

souhaiter le bloquer il faut l’écrire comme cela « !ads »

Ainsi pour le groupe localnetwork n’aura accès qu’aux contenus présents dans la

whitelist, tous les noms de domaines et URL de la liste ads seront bloqués, tout le reste du

contenu internet n’étant pas présent dans la whitelist sera bloqué.

Une fois le paramétrage de SquidGuard effectuer il faut mettre a jours la base de données grâce

a la commande : SquidGuard –C all –d

Figure 32 : détaille opération mise à jour base de données squidguard

Le bon déroulement de la mise à jour est terminé lors de l’apparition du message :

db update done

Intégration de SquidGuard à Squid

La dernière partie de la configuration est la liaison entre SquidGuard et Squid.

Afin que cette liaison soit effective, il faut écrire quelque ligne dans la configuration de Squid

qui est le fichier : /etc/squid/squid.conf

Figure 33 : intégration de SquidGuard dans la configuration de squid

Cette ligne permet de dire à Squid qu’il doit rediriger les URL vers le binaire SquidGuard en

précisant sont paramètre d’exécution et le fichier de configuration qui lui est associé.

17

ClamAV

Clam AntiVirus ou ClamAV est un anti virus GPL pour UNIX. Ici dans cette solution nous allons

nous intéresser a sont plug-in SquidClamav qui permet l’intégration de l’antivirus a notre serveur

proxy Squid.

Installation

Premièrement, il faut commencer par télécharger ClamAV ainsi que quelques dépendances :

Figure 34 : téléchargement clamav Nous allons préparer l’intégration de ClamAV en téléchargeant installant et compilant le paquet

SquidClamAV.

Figure 35 : téléchargement compilation installation squidclamav Une fois cette opération effectuer nous allons mettre a jour la base de données de ClamAV

grâce à la commande freshclam.

Figure 36 : mise à jour base de signatures de virus clamav s

Ensuit il faut télécharger compiler et installer le paquet c-icap qui nous permettra d’analyser le

flux web avec ClamAV.

Figure 37 : téléchargement compilation et installation serveur c-icap Après la compilation et l’installation du paquet, nous allons modifier quelques lignes dans les

fichiers de configuration de c-icap.

18

Premièrement, il faut ajouter la ligne : START=yes au fichier /etc/default/c-icap affin qu’il

démarre automatiquement

Ensuite dans le fichier /etc/c-icap/c-icap.conf entrer la ligne de configuration suivante :

Figure 38 : intégration de squidclamav dans la configuration de c-icap

Cette dernière permet d’inclure le service squidclamav à notre server c-icap.

La partie suivante de la configuration porte sur l’intégration de notre serveur c-icap à notre

proxy. Affin de rendre cette étape plus claire voici un résumé des lignes à modifié.

icap_enable on

icap_send_client_ip on

icap_send_client_username on

icap_client_username_header X-Authenticated-User

icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav

adaptation_access service_req allow all

icap_service service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav

adaptation_access service_resp allow all

La plupart de ces lignes sont déjà présentes dans le fichier /etc/squid/squid.conf avec quelques

exemples et les paramètres qui leur sont associés.

SquidClamAV

La configuration du plug-in SquidClamAV est placée dans le fichier

/etc/squidclamav/squidclamav.conf

Il faut la modifier afin de définir quel page web sera affiché lors d’une redirection si une analyse

clamav trouve un virus

Figure 39 : configuration plug-in squidclamav

Clamd_local fait référence au chemin ou est placé la base de donnée de clamav.

19

Une fois ces opérations effectuées notre solution de filtrage et sécurisation du flux web est

opérationnel.

Test

Premièrement nous pouvons tester si Squid fait bien sont travail de proxy en analysant les

fichiers logs contenus dans /var/log/squid/cache.log nous pouvons voir les requêtes HTTP

effectuées par les utilisateurs placés dans l’ACL réseau définit dans la configuration de squid.

Figure 40 : extrait des log de squid

Afin de tester l’efficacité de Squidguard, un procéder consiste à taper une adresse qui est censée être bloqué dans une des listes que vous avez définies dans la configuration si squidguard est opérationnel vous devrez tomber sur une page web semblable à celle-ci :

Figure 41 : blocage URL par SquidGuard Dernièrement, il faut vérifier si le plug-in SquidClamAV est opérationnel en essayant de télécharger un des fichiers suivant qui sont au format zip sur la page web http://securite-informatique.info/virus/eicar/ Si votre antivirus est actif, votre navigateur internet ne devrait pas pouvoir télécharger le fichier et vous redirigera sur cette page internet :

20

Figure 42 : Virus détecter par SquidClamAV

Conclusion La problématique de ce projet était d’installer un système de proxy filtrant le plus possible de

publicité afin de rendre plus agréable l’utilisation d’internet dans l’infrastructure, de pouvoir

gérer les requêtes HTTP et HTTPS de manière transparente, afin que l’utilisateur ne puisse

contourné le serveur mandataire et d’intégrer l’antivirus ClamAV à la solution afin de bloquer

les virus et autres malware pour rendre internet plus sur pour les utilisateurs.

La solution proposer répond à ces objectifs et, grâce à l’ambivalence de squid et des plug-ins

qui sont développés par la communauté qui l’entoure cette solution peut s’adapter sur de très

nombreuses infrastructures, pouvant répondre a de nombreux besoins.

Une fois de plus, l’utilisation d’application venant du monde libre permet le développement

d’une solution gratuite et très complète.

Ce projet a était très intéressant, car il ma permit d’apprendre et de comprendre le

fonctionnement et l’utilisation d’un serveur proxy ce qui est un réel plus pour ma formation, car

ce genre de solution est une obligation dans les lieux publics offrant un accès à internet ou au

sein d’une entreprise, d’une association ou d’un établissement scolaire.