Proxy HTTP : SQUID

8 février 2007

Télécharger en PDF


Table des matières

I.Définitions 2

1.Cache Web 2

2.Serveur mandataire ou Proxy 2

3.Les implémentations de serveurs proxy modernes 2

II.Installation de base de SQUID 3

1.Installation 3

2.Configuration de Squid 4

3.Lancement 5

4.Autre personnalisations nécessaires 5

a)Langage des messages d'erreur 5

b)Port d'écoute du proxy 5

c)Les logs 5

d)Message personnalisé additionnel pour les messages d'erreur 5

III.Configuration avancée de Squid 6

1.Liste de contrôles d'accés 6

a)Définition des contrôles d'accés 6

i.Contrôle de l'adresse ip source 6

ii.Contrôle de l'adresse ip destination 7

iii.Contrôle du domain source ou destination 7

iv.Contrôle de l'heure de connexion 7

v.Contrôle d'expressions dans l'URL 8

vi.Contrôle du nombre maximum de connexions par IP cliente 8

b)Mise en oeuvre de la liste des contrôles d'accés 8

2.Allez plus loin dans le filtrage : installation de SquidGuard 9

3.Validité et rafraîchissement des objets 9

IV.Rendre Squid transparent pour les utilisateurs 9

1.Mise en place du proxy dans le réseau 10

2.Règles de routage du mandataire 10

3.Activation de la transparence 11

V.Informations diverses et configuration encore plus avancée 11

1.Comprendre les logs 11

2.Caches hiérarchiques 13

3.Répartition de charge entre plusieurs caches. 14

4.Méthodes d'authentification 14

a)Méthode générale 14

b)ncsa_auth : l'authentification avec une base htpasswd 15

c)pam_auth : l'authentification avec PAM 15

VI.Exemple de fichier /etc/squid/squid.conf commenté 16

VII.Bibliographie 19


I.Définitions

1.Cache Web

Un cache Web est un logiciel qui se charge d'enregistrer une page Web et les éventuels contenus attachés (images, son...) localement afin que si l'utilisateur redemande la même page, elle lui sera renvoyée depuis la copie local ce qui permet d'accélerer la réponse.




Tous les navigateurs modernes disposent d'un système de cache afin de ne solliciter un serveur que pour des pages susceptibles d'avoir changées. Cela permet d'accélerer la navigation et la durée de stockage et donc de rafraichissement du cache est paramétrable.

Les logiciels de mise en cache permettent également souvent de gérer les versions d'un document, ainsi que l'aspiration du contenu de tout un site.

2.Serveur mandataire ou Proxy


Un serveur mandataire, dans sa définition originelle, attend les requêtes des clients et les transmet aux serveurs auxquels le client voulait accéder. Il reçoit la réponse des serveurs et la renvoie aux clients concernés. Il se comporte donc comme un serveur pour le client, et comme un client pour le serveur que le client veut joindre :



3.Les implémentations de serveurs proxy modernes

Les serveurs proxy modernes implémentent à la fois le principe de cache, de mandataire et de filtrage de contenu. Un requête client se passe comme suit :




II.Installation de base de SQUID

1.Installation

Sous Debian, en tant que root, la commande apt-get install squid installera le paquetage de squid.

La configuration automatique réalisée par les scripts de post-installation crée l'arborescence de répertoires dans laquelle seront enregistrés les documents cachés :

Creating squid spool directory structure
2006/09/14 12:34:56| Creating Swap Directories

Soit 256 sous-répetoires nommés de 00 à FF et dans chacun d'eux 16 répertoires nommés de 00 à 0F du répertoire parent /var/spool/squid.

2.Configuration de Squid

Tout d'abord, pour obtenir des informations plus complètes sur la configuration de Squid, ouvrez le fichier /usr/doc/squid-num-version/FAQ.html à l'aide de votre navigateur Web ou sur le site Web de Squid à l'adresse http://squid.nlanr.net/.

La configuration par défaut de Squid permet de lancer un proxy/cache HTTP et FTP non filtrant tout de suite sans grande modification. Nous reviendrons au filtrage dans la configuration avancée.

Cependant, pour commencer à utiliser le serveur proxy de mise en cache Squid, commencez par le fichier QUICKSTART qui doit se trouver dans /usr/doc/squid-num-version/.

Si vous voulez que Squid se lance automatiquement au démarrage, par exemple, sous Debian :

[root]# update-rc.d squid defauts

Pour exécuter Squid, vous devez cependant, éditer certains paramètres dans son fichier de configuration, /etc/squid/squid.conf.

# définit que le manager peut accéder au cache par le protocole cache_object

# normalement, on trouvera aussi les règles permettant

# de limiter le manager à la boucle locale

# http_access deny manager !localhost

# http_access allow all

acl manager proto cache_object

# définit localhost comme adresse source 127.0.0.1

acl localhost src 127.0.0.1/255.255.255.255

# définit all comme toutes les adresses IP possibles

acl all src 0.0.0.0/0.0.0.0



3.Lancement

Pour lancer Squid, exécuter /etc/init.d/squid start.


La première fois que vous lancer Squid (et si ce n'est pas déjà fait), il va créer les répertoires du cache.


Squid devrait à présent scruter le port 3128 de votre serveur Web. Vous pouvez maintenant configurer sur votre navigateur préférer l'adresse de votre serveur squid et le port 3128 comme serveur proxy pour la connexion à Internet.

4.Autre personnalisations nécessaires

a)Langage des messages d'erreur

Il va surement arriver qu'un utilisateur tape un nom de site ou une URL qui n'existe pas. Il est ainsi préférable que la page d'erreur soit en français. On veillera donc à changer la directive error_directory comme suit :

error_directory /usr/share/squid/errors/French

b)Port d'écoute du proxy

Il est possible de régler le numéro de port sur lequel le mandataire attend les requêtes des clients, et ce à l'aide de la directive http_port. Par défaut, la valeur est 3128, mais il est commun d'utiliser 8080.

c)Les logs

Il existe plusieurs fichiers journaux “utiles” dans le répertoire /var/log/squid :

De plus, il existe un log de tous les enregistrements et effacements d'objets dans le cache, ce qui ne possède pas un grand intérêt. On mettra donc la directive cache_store_log none.

d)Message personnalisé additionnel pour les messages d'erreur

La directive err_html_txt permet de définir un texte type qui pourra être automatiquement ajouté aux messages d'erreur. Le texte %L placé dans un message d'erreur incrustera le texte défini par cette directive.

III.Configuration avancée de Squid

Jusqu'à présent nous ne nous sommes pas occupé de ce qui peut ou pas être en cache et de comment le rafraichissement du cache est effectué.

La configuration avancée du service Squid permet principalement la gestion des droits de consultation de pages web en termes de serveur destination, d'horaires, d'utilisateur.

On pourra aussi vouloir réaliser l'un des aspects suivants :

Et enfin, tout ce que l'on peut trouver dans les commentaires de squid.conf.

Dans tous les cas, le filtrage passe par les listes de contrôle d'accès ou plus simplement ACL.

1.Liste de contrôles d'accés

a)Définition des contrôles d'accés

Une liste de contrôle d'accès définie par la directive acl, se compose de :

On peut, par exemple, filtrer par IP source ou plage horaire ce qui n'est déjà pas si mal.


Chaque ACL est une liste de valeurs. Pendant la vérification, les valeurs multiples utilisent un OU logique. Autrement dit un élément ACL correspond si l'une des valeurs est reconnue.

i.Contrôle de l'adresse ip source

Un filtre par IP source peut se mettre en place par :

acl <nom filtre> src <adresse_ip>/<masque_sous-réseau>
ce qui a pour effet de définir un filtre <nom filtre> pour filtrer les requêtes ayant pour source le sous réseau <adresse_ip> avec un masque de <masque_sous-réseau>.
On peut aussi donner la forme suivante pour inclure seulement une plage d'IP :
acl <nom filtre> src <adresse_ip début>-<adresse_ip fin>

ii.Contrôle de l'adresse ip destination

Un filtre par IP destination peut se mettre en place par :

acl <nom filtre> dst <adresse_ip>/<masque_sous-réseau>
ce qui a pour effet de définir un filtre <nom filtre> pour filtrer les requêtes ayant pour destination le sous réseau <adresse_ip> avec un masque de <masque_sous-réseau>.
On peut aussi donner la forme suivante pour inclure seulement une plage d'IP :
acl <nom filtre> dst <adresse_ip début>-<adresse_ip fin>

iii.Contrôle du domain source ou destination

Un filtre par nom de domaine peut se réaliser par :

acl <nom filtre> srcdomain <nom domaine> [<nom domaine> ...]

acl <nom filtre> dstdomain <nom domaine> [<nom domaine> ...]

iv.Contrôle de l'heure de connexion

Un filtre par date et heure peut se définir ainsi :

acl <nom_filtre> time <jour> <h1:m1-h2:m2>
Il est à noter que l'on peut chainer les paramètres de time, comme ceci :

acl <nom_filtre> time <jour> <h1:m1-h2:m2> \

<jour> <h1:m1-h2:m2> \

...

<jour> <h1:m1-h2:m2>


<jour> peut être choisi parmi :


v.Contrôle d'expressions dans l'URL

Un filtre par regexp d'URL peut se définir de plusieurs manières :

acl <nom filtre> url_regexp <regexp>

On peut mettre plusieurs <regexp> en les séparant par des espaces pour faire un OU logique entre les regexp c'est à dire que l'acl est validé si une des expressions regexp correspond.

Une autre solution est de référencer un nom de fichier qui contiendra une expression regexp par ligne afin de tester la correspondance de chaque ligne avec l'URL demandée. La forme est la suivante :
acl <nom filtre> url_regexp “/chemin/nom_de_fichier

Il existe aussi urlpath_regex qui permet de faire une correspondance avec une expression régulière décrivant un ensemble d'URL sans le protocole ni le nom d'hôte.

vi.Contrôle du nombre maximum de connexions par IP cliente

Un filtre par nombre de connexions cliente peut se définir comme suit :

acl <nom filtre> maxconn <nombre max connexion par client>


b)Mise en oeuvre de la liste des contrôles d'accés

Les directives vues précédemment permettent de définir des filtres. Cependant ceux ne sont que des définitions, des listes qu'il faut appliquer et associer à une action.

On aura principalement trois type d'action pour le procotole HTTP :

Il est à noter que l'on peut mettre plusieurs noms de filtres à la suite pour faire un ET logique entre les conditions des filtres.

<action> sera à choisir parmi allow pour autoriser explicitement la correspondance à un filtre ou deny pour le contraire.

Si une requête ne correspond à aucune des listes d'accés passées aux directives http_access, le sort de celle-ci sera opposé au sort défini dans la dernière directive. La requête sera acceptée si aucune directive http_access n'est définie. On conviendra donc de mettre soit un http_access all deny ou un http_access all allow.

2.Allez plus loin dans le filtrage : installation de SquidGuard

Paquets à installer :

apt-get install squidguard chastity-list

Et répondre Oui ou OK à toutes les questions que va vous posez le script de post-installation.

Ajouter les deux lignes suivantes dans /etc/squid/squid.conf

redirect_program /usr/bin/squidGuard
redirect_children 4

Modifier les lignes suivantes de /etc/squid/squidGuard.conf pour indiquer le bon chemin de la base de données des URL interdites et le chemin des logs :

dbhome /var/lib/chastity
logdir /var/log/squid

Redémarrer le serveur pour prendre en compte les modifications :

/etc/init.d/squid restart

3.Validité et rafraîchissement des objets

Deux directives permettent d'influencer le comportement du proxy quant à la façon dont il jugera utile de recharger la page demandée depuis le Web plutôt que de la fournir directement au client.

La directive reload_into_ims permet, lorsque sa valeur on de passer directement la page à un client sans la recharger même si celui-ci le demande explicitement, à la condition toutefois que la page dans le cache soit à jour. Le proxy vérifie la validité de cette condition en passant une requête au serveur distant avec l'argument if-modified-since. L'utilisation de cette fonctionnalité constitue une violation du protocole http.

La directive refresh_pattern permet un contrôle beaucoup plus fin de la validité des objets cachés.Pour plus d'informations sur cette directive voir le fonctionnement du cache et la documentation de Squid.

IV.Rendre Squid transparent pour les utilisateurs

Pour que le cache se remplisse et que son utilisation soit optimal, il faut qu'un maximum de clients.

Deux solutions sont possibles :

1.Mise en place du proxy dans le réseau

Obliger les clients utilisateurs à passer par le proxy peut se faire de deux manière :







2.Règles de routage du mandataire

Pour rediriger le port 80 vers le port de Squid (3128 ou 8080), on devra se servir d'iptables. Ainsi, on mettra, par exemple, à la fin du script de démarrage du réseau /etc/init.d/networking, ou lancées manuellement :

echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -I PREROUTING -p TCP --dport 80 -j REDIRECT --to-port 3128

La première ligne active le routage dans le noyau. La seconde redirige le port de telle sorte que le client croira se connecter directement au serveur visé par la requête HTTP alors qu'il sera connecté au serveur proxy Squid.

Un problème demeure en l'état actuel de notre serveur proxy : le client envoie une requête HTTP directe et non adaptée à l'utilisation d'un proxy. En effet, avec une requête HTTP classique, on envoie un GET et une entête Host: pour préciser le nom du serveur alors qu'avec une connexion par proxy, on doit utiliser CONNECT et HOST.

3.Activation de la transparence

Les directives relatives à l'accélération d'un serveur Web, doivent utilisées, de la façon suivante afin que le proxy fonctionne de façon transparente :

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy  on
httpd_accel_uses_host_header on

La première ligne indique que l'on doit pouvoir mettre en cache tous les sites webs (autorisés) demandés par les clients et pas simplement un seul fixé.

La deuxième ligne indique que l'on se connecte toujours sur le port 80 quelque soit le port de la requête cliente.

La troisième ligne indique que l'on continue à reconnaitre les requêtes HTTP pour proxy en plus des requêtes transparentes, c'est à dire que l'on accepte à la fois les clients qui ne sont pas au courant qu'ils utilisent un proxy et ceux qui en ont connaissance.

Enfin la quatrième ligne active l'envoi et le log du champs d'entête HTTP Host: afin que les virtual hosts puissent fonctionner correctement. Cette option peut poser un problème du fait que la traduction de la requête entrante vers la requete sortante se fait APRES vérification des ACLs. C'est à dire que la destination au moment de la correspondance aux ACLs n'est pas encore celle de l'entête Host:. Ceci fait que l'on pourrait passer outre certaines ACLs.

V.Informations diverses et configuration encore plus avancée

1.Comprendre les logs

On peut surveiller les logs à l'aide de la commande tail -f access.log (les logs de Squid se trouvant dans le répertoire /var/log/squid ou /usr/local/squid/log.

Squid possède plusieurs fichiers de logs :

Voici les valeurs que vous pouvez voir dans le fichier access.log. Les codes commençant par TCP_  sont les requêtes sur le port 8080 ou 3128 :

TCP_HIT

Une copie valide se trouve dans le cache

TCP_MISS

Pas dans le cache

TCP_REFRESH_HIT

Objet dans le cache, mais périmé. Squid demande au serveur d'origine si une nouvelle version est disponible, la réponse étant pas de nouvelle version

TCP_REF_FAIL_HIT

Objet dans le cache, mais périmé. Squid demande une mise à jour, mais n'obtient pas de réponse du serveur. Il renvoie alors l'ancienne version.

TCP_REFRESH_MISS

Objet dans le cache, mais périmé. Squid demande une mise à jour qu'il reçoit

TCP_CLIENT_REFRESH

Le client envoie une requête avec une demande de ne pas utiliser le cache. Squid forward la requête.

TCP_IMS_HIT

Le client demande une mise à jour, et l'objet est dans le cache et est récent. Squid ne forward pas la requête.

TCP_IMS_MISS

Le client demande une mise à jour. Squid forward la requête.

TCP_SWAPFAIL

Problème de swap. L'objet semble être dans le cache mais n'est pas accessible. La requête est forwardée.

TCP_DENIED

Accès refusé.



UDP_ sont des codes sur le port ICP:

UDP_HIT

Une copie récente de la copie est dans le cache

UDP_HIT_OBJET

Idem que UDP_HIT, mais l'objet est envoyé dans un paquet UDP 

UDP_MISS

Objet pas dans le cache ou périmé

UDP_DENIED

Accès interdit pour cette requête

UDP_INVALID

Requête invalide

UDP_MISS_NOFETCH

La requête n'a pas était faite à temps (arrêt ou démarrage du serveur)



ERR_  sont des codes d'erreurs. Ils sont trop nombreux pour être traités ici.

Codes Hiérarchiques

DIRECT

Squid forward directement la requête au serveur d'origine

FIREWALL_IP_DIRECT

Squid forward la requête directement au serveur d'origine, parce que le serveur d'origine est derrière un Firewall

FIRST_UP_PARENT

Squid forward la requête au premier parent disponible de la liste

LOCAL_IP_DIRECT

Squid forward directement la requête au serveur d'origine car l'adresse correspond à une adresse locale

SIBLING_HIT

Squid forward la requête à un cache sibling qui a envoyé un UDP_HIT

NO_DIRECT_FAIL

Squid ne peut pas forwarder la requête parce qu'un firewall l'interdit ou il n'y a pas de cache parent.

PARENT_HIT

Squid forward la requête à un cache parent qui a envoyé un UDP_HIT

SINGLE_PARENT

La requête est forwardée à un cache parent approprié pour cette requête. Il faut que le single_parent_bypass soit actif.

SOURCE_FASTEST

Squid forward la requête au serveur d'origine car la requête à ce serveur source_ping arrive plus vite.

PARENT_UDP_HIT_OBJ

Squid reçoit la réponse dans un UDP_HIT_OBJ du cache parent.

SIBLING_UDP_HIT_OBJ

Squid reçoit la réponse dans un UDP_HIT_OBJ du cache sibling.

DEFAULT_PARENT

Squid forward la requête à un cache parent par défaut sans envoyer une requête ICP avant.

ROUNDROBIN_PARENT

Squid forward la requête à un cache parent round-robin, sans envoyer de requête ICP avant

CLOSEST_PARENT_MISS

Squid forward la requête à un cache parent
Cela existe que si vous avez déclaré query_icmp dans le fichier de configuration.

NONE

Squid ne forwarde aucune requête



2.Caches hiérarchiques

Squid est capable de "discuter" avec d'autres proxy cache, à l'aide de ICP (Internet Cache Protocol) sur un port particulier (3130 par défaut). On peut ainsi cascader un certain nombre de caches.
Il faut pour cela dans le fichier de configuration de Squid valider la ligne
cache_peer type http_port icp_port options

Pour le type on a comme possibilité :

Pour http_port et icp_port utiliser 8080 et 3130 respectivement, mais cela n'est pas obligatoire.

Pour les options on dispose des options suivantes :


Il existe une autre option de caches hiérarchiques qui est : cache_digests. Pour pouvoir l'utiliser il faut avoir compilé squid avec l'option ./configure --enable-cache-digests. Cette solution est plus intéressante que ICP, car le trafic entre les caches est plus réduit.
Il faut alors mettre la ligne suivante :
cache_peer <IP cache parent> sibling 8080 3130 no-query proxy-only

3.Répartition de charge entre plusieurs caches.

Il existe plusieurs solutions pour cela :

4.Méthodes d'authentification

La configuration par défaut de Squid ne demande aucune identification des utilisateurs. Pour authentifier ces derniers, c-à-d. pour n'autoriser que des utilisateurs connus à accéder à Internet, Squid s'appuiera sur un programme externe, qui nécessitera un nom d'utilisateur et un mot de passe. Cetee demande de mot de passe est obtenu par proxy_auth et authenticate_program qui forcent un utilisateur à donner un nom et un mot de passe avant d'autoriser l'accès.

Ces programmes sont nombreux :

  1. LDAP : se base sur le protocole LDAP (Lightweight Directory Access Protocol) et permet par exemple de s'interfacer avec OpenLDAP ou Active Directory.

  2. NCSA : utilise un fichier de noms d'utilisateur et de mots de passe de style NCSA

  3. SMB : utilise un serveur SMB comme SAMBA ou Windows NT/2K/XP/2K3...

  4. MSNT : utilise l'authentification de domaine Windows NT

  5. PAM : utilise les modules Linux "Pluggable Authentication Modules"

  6. getpwam : utilise le fichier passwd de Linux.

a)Méthode générale

Il est d'abord nécessaire d'installer et de configurer le programme d'authentification externe. Un tel programme lit en boucle sans fin sur son entrée standard une ligne composée comme ceci “username cleartextpassword” et renvoie une ligne contenant “OK” ou “ERR” sur sa sortie standard suivant le résultat de l'authentification.

Dans le fichier squid.conf, on devra ajouter la directive authenticate_program suivie du chemin et du nom du programme d'authentification ainsi qu'une ACL demandant son utilisaton :

authenticate_program /path/to/program

acl <nom_filtre_auth> proxy_auth REQUIRED
#autres ACL comme la limitations par IP source

http_access allow <nom_filtre_auth>
http_access deny all

Un programme d'authentification est utilisé et chaque utilisateur doit s'authentifier avant d'accéder à Internet.

Des options comme authenticate_ttl <durée_en_seconde> et authenticate_ip_ttl <durée_en_seconde> permettent aussi de modifier le comportement du processus d'authentification :

b)ncsa_auth : l'authentification avec une base htpasswd

Un programme d'authentification courant sur les serveurs Web est ncsa_auth, et il permet de gérer les logins/mots de passe dans un fichier htpasswd style NCSA comme pour Apache. Usage:

        /usr/lib/squid/ncsa_auth /path/to/passwd_file

passwd_file est un fichier type NCSA/Apache contenant les logins/mots de passe pour authentification sur proxy. Chaque ligne contient une combinaison user:password, avec le mot de passe au format standard crypt(). Ce fichier doit appartenir à l'utilisateur sous lequel tourne ncsa_auth.

Pour l'utiliser, il suffit d'ajouter au fichier squid.conf et de placer l'acl/accès appropriée comme précédemment :

authenticate_program /usr/lib/squid/ncsa_auth /path/to/passwd_file

c)pam_auth : l'authentification avec PAM

Un programme d'authentification courant sous Linux est PAM, et permet de configurer la source des logins/mots de passe dans un fichier séparé (/etc/passwd, mysql, ldap...). Usage:

        /usr/lib/squid/pam_auth

Ce programme nécessite que le service PAM soit configuré dans /etc/pam.conf ou /etc/pam.d/<servicename>. Le nom de service par défaut est "squid", et ce programme utilise les groupes 'auth' et 'account' pour vérifier le mot de passe et la validité du compte. Pour plus d'infos sur comment configurer PAM, voir le tutoriel consacré à PAM.

Il est à noter que si vous utilisez la base système /etc/passwd, il sera nécessaire de changer le propriétaire de pam_auth en root et de placer le bit setuid sur celui-ci. De plus, il est préférable, dans ce cas, de mettre pam_auth dans un dossier inaccessible à part pour root, sans quoi n'importe quel utilisateur pourrait faire du brute-force sur la base système.

Pour l'utiliser, il suffit d'ajouter au fichier squid.conf et de placer l'acl/accès appropriée comme précédemment :

authenticate_program /usr/lib/squid/pam_auth



VI.Exemple de fichier /etc/squid/squid.conf commenté

##### /etc/squid/squid.conf #####

# comme Squid est lancé par un utilisateur différent de root

# alors http_port ne peut être inférieur à 1024

http_port 192.168.0.1:3128


#ne pas mettre en cache les formulaires (cgi-bin et le page dont l'url contient un ?)

acl QUERY urlpath_regex cgi-bin \?

no_cache deny QUERY


#10 Mo pour le cache en mémoire

cache_mem 10 MB


#définit un cache disque de 100Mo avec 16 dossiers de 256 dossiers chacuns

cache_dir ufs /var/spool/squid 100 16 256


#fichier de log des accès cache

cache_access_log /var/log/squid/access.log


#fichier de log du démarrage/arrêt de Squid

cache_log /var/log/squid/cache.log


#fichier de log des objets résidants dans le cache

cache_store_log none


#fichier contenant le PID de squid

pid_filename /var/run/squid.pid


# Pour que le proxy soit serveur DNS :

# dns_nameservers dns_fai ou/et dns_passerelle


#utilisation de squidGuard

# redirect_program /usr/bin/squidGuard -c etc/squid/squidGuard.conf


#indique les délais de rafraichissement des objets du cache (détails dans la doc)

refresh_pattern ^ftp: 1440 20% 10080

refresh_pattern ^gopher: 1440 0% 1440

refresh_pattern . 0 20% 4320


# ACL : les acl permettent de spécifier les autorisations

# d'accès sur certains ports, et pour les ip des stations

# Attention l'ordre donné ici est important !


#toutes les machines

acl all src 0.0.0.0/0.0.0.0

#localhost : boucle locale

acl localhost src 127.0.0.1/255.255.255.255

#protocole de gestion du cache

acl manager proto cache_object


#l'IP du serveur

acl serveur src <IP>


#une IP

acl poste src <IP>

#une plage d'IP

acl multipostes src <IP début>-<IP fin>


#ports utilisés par SSL (HTTPS et NNTPS)

acl SSL_ports port 443 563


#port que l'on peut rediriger sans crainte de sécurité

acl Safe_ports port 80 # http

acl Safe_ports port 20 # ftp-data

acl Safe_ports port 21 # ftp

acl Safe_ports port 443 563 # ssl

acl Safe_ports port 70 # gopher

acl Safe_ports port 210 # wais

acl Safe_ports port 1025-65535 # unregistered ports

acl Safe_ports port 280 # http-mgmt

acl Safe_ports port 488 # gss-http

acl Safe_ports port 591 # filemaker

acl Safe_ports port 777 # multiling http

acl Safe_ports port 631 # cups

acl Safe_ports port 873 # rsync

acl Safe_ports port 901 # SWAT


#méthode de purge du cache

acl purge method PURGE


#autoriser les requêtes HTTP proxy

acl CONNECT method CONNECT


# On accepte tout ce qui vient du serveur

http_access allow serveur

#les requêtes de manipulation de cache local seulement depuis la boucle locale

http_access allow manager localhost

#mais pas d'ailleurs

http_access deny manager

#les requêtes de vidage du cache uniquement en local

http_access allow purge localhost

http_access deny purge


# On rejette tous les ports différents de ceux déclarer dans les acl

#en direct

http_access deny !Safe_ports

#ou en proxy

http_access deny CONNECT !SSL_ports


# On accepte les requetes des stations suivantes sur le proxy : poste et multipostes

http_access allow poste

http_access allow multipostes




# On accepte le local

http_access allow localhost


# On rejette tout le reste

http_access deny all


#réponse positive ou négative pour tout le monde

http_reply_access allow all


#on accepte du traffic entre cache (interrogation) de partout

icp_access allow all


# On renseigne l'utilisateur et le groupe qui initialise Squid :

cache_effective_user proxy

cache_effective_group proxy


# On renseigner le nom de machine qui fait office de serveur

visible_hostname serveur


#autorise le proxy à être utilisé comme passage obligatoire en mode transparent pour HTTP

#pour toutes les requêtes

httpd_accel_host virtual

#faire des requêtes sur 80

httpd_accel_port 80

#faire quand même du cache

httpd_accel_with_proxy on

#et regarder l'entête Host

httpd_accel_uses_host_header on


#### END /etc/squid/squid.conf ####


VII.Bibliographie

Squid Web Proxy Cache

IRP : Squid et SquidGuard

Squid - Wikipédia

Squid


http://www.squid-cache.org/Doc/FAQ/


Partage de connexion : proxy Squid


Squid ACL Proxy Authentication with External Programs


Squidguard

sharevb