Présentation de Squid

Squid est un logiciel libre proxy serveur de cache de haute performance conçu pour fonctionner sur les systèmes Linux, Unix. Squid est utilisé chez de nombreux FAI et dans beaucoup d'entreprises dans le monde entier. 

Squid est un service qui permet généralement de sécuriser et contrôler l'accès à internet pour les utilisateurs d'un réseau local d'une entreprise, c'est la fonction de Proxy, mais il peut aussi être utilisé afin de sécuriser et contrôler l'accès des utilisateurs sur internet à 1 ou plusieurs serveurs web interne, c'est la fonction de reverse proxy ou proxy inverse, objet de cet article.

Squid peut fonctionner en tant que proxy cache de  trois façons principales sur un réseau: 

Standard Cache Proxy

Un proxy cache standard est utilisé pour mettre en cache les pages Web statiques (HTML et images) sur une machine du réseau local. Lorsque la page est demandée une seconde fois, le navigateur retourne les données du proxy local au lieu du serveur Web d'origine. Le navigateur internet est configuré de manière explicite pour envoyer toutes les requêtes HTTP vers le proxy cache, plutôt que sur le serveur Web cible. Le cache alors soit satisfait à la demande ou transmet la demande au serveur cible. 

Transparent Cache Proxy

Un cache transparent a le même but que le proxy standard, mais fonctionne de manière transparente dans le navigateur. Le navigateur n'a pas besoin d'être explicitement configuré pour accéder au proxy cache. Au lieu de cela, le cache transparent intercepte le trafic réseau, filtre le trafic HTTP (sur le port 80), et gère la demande si l'article est dans le cache. Si l'élément n'est pas dans le cache, les paquets sont transmis au serveur Web d'origine. Pour Linux, le cache transparent utilise iptables ou ipchains pour intercepter et filtrer le trafic réseau. Les serveur proxy cache transparents sont particulièrement utiles pour les FAI, car ils ne nécessitent aucune modification de configuration du navigateur. 

Reverse Proxy Cache

Un proxy cache inverse diffère d'un proxy cache transparent ou standard, en ce sens qu'il a pour rôle de réduire la charge sur le serveur Web d'origine, plutôt que de réduire la bande passante réseau en amont du côté client. Le Reverse Proxy reponds aux demandes des clients pour le contenu statique du serveur web, permettant d'absorber le surcroit de trafic et la surcharge du serveur d'origine. Le serveur proxy se trouve entre l'Internet et le site Web et gère tout le trafic avant de pouvoir atteindre le serveur Web. Un serveur proxy inverse intercepte les requêtes vers le serveur Web et répond plutôt à la demande en fournissant en priorité les pages mises en cache. Cette méthode améliore les performances en réduisant la quantité de pages effectivement générées par le serveur Web.

Objectifs de la mise en place d'un reverse proxy

Squid est un service qui permet généralement de sécuriser et contrôler l'accès à internet pour les utilisateurs d'un réseau local d'une entreprise, c'est la fonction de Proxy, mais il peut aussi être utilisé afin de sécuriser et contrôler l'accès des utilisateurs sur internet à 1 ou plusieurs serveurs web interne, c'est la fonction de reverse proxy ou proxy inverse, objet de cet article.

Le proxy inverse est placé entre l'Internet et le serveur web 

Lorsqu'un navigateur client effectue une requête HTTP, le serveur DNS va acheminer la demande à la machine reverse proxy, le serveur web n'est pas réelle. Le reverse proxy vérifie son cache pour voir si elle contient l'élément demandé, sinon, il se connecte au serveur web réel et télécharge le document demandé vers son cache. Le cache du serveur reverse proxy ne peut être utilisé que pour des URL pouvant être mises en cache (comme les pages HTML et les images). 

Le contenu dynamique, comme les scripts CGI et Active Server Pages ne peuvent pas être mis en cache. L'utilisation du cache proxy pour les pages statiques est basées sur les balises d'en-tête HTTP retournées à partir de la page Web.

Nous nous contenterons dans cet article de mettre en place un reverse proxy HTTP et HTTPS positionné en amont de 2 serveurs web dont 1 serveur Microsoft IIS/Exchange et 1 serveur web en local sur le serveur Squid.

Pour le serveur HTTPS, puisque c'est une question qui doit revenir relativement souvent, nous publierons un serveur Exchange avec la prise en compte de Outlook Web Access (OWA) et ActiveSync.

Installation du reverse proxy Squid 3.1.x

Cet article ne couvre que l'installation et la configuration du proxy / reverse proxy Squid sous Debian Lenny 5.x.

Bien sur, il est relativement facile d'installer le proxy / reverse proxy Squid sous Debian, on pourrait presque se contenter d'utiliser cette commande :

1

aptitude install squid3

Le seul petit soucis, c'est que l'installation du paquet fourni par Debian n'intègre pas la possibilité de faire du reverse proxy en HTTPS, il n'est de plus pas forcément très à jour, nous allons donc devoir créer notre propre paquet d'installation Debian de Squid3 dans une version plus récente et avec le support de HTTPS.

Pour ce faire nous allons commencer par ajouter une source d'installation de paquet à notre fichier /etc/apt/sources.list :

1
2

deb http://www.backports.org/debian lenny-backports main contrib non-free
deb-src http://www.backports.org/debian lenny-backports main contrib non-free

et importer le clef de Backports :

1

wget -O - http://backports.org/debian/archive.key | apt-key add -

Nous allons ensuite mettre à jour la liste de paquets disponibles et installer les outils nécessaire à la création du nouveau paquet d'installation Debian :

1
2

aptitude update
aptitude install devscripts build-essential fakeroot libssl-dev

Nous allons ensuite télécharger les sources de Squid 3.x et ses dépendances, à ce jour c'est la version 3.1.3 :

1
2
3
4
5

cd /usr/src
aptitude install apache2
apt-get source squid3
apt-get build-dep squid3
apt-get squid-langpack

Il nous reste à modifier le fichiers rules présent dans le repertoire /usr/src/squid3-3.1.3/debian afin d'y ajouter la prise en charge de ssl pour pouvoir utiliser notre reverse proxy en HTTPS (vous pouvez aussi y ajouter d'autres options à votre convenance) :

14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

DEB_CONFIGURE_EXTRA_FLAGS := --datadir=/usr/share/squid3 \
        --sysconfdir=/etc/squid3 \
        --mandir=/usr/share/man \
        --with-cppunit-basedir=/usr \
        --enable-inline \
        --enable-async-io=8 \
        --enable-storeio="ufs,aufs,diskd" \
        --enable-removal-policies="lru,heap" \
        --enable-delay-pools \
        --enable-cache-digests \
        --enable-underscores \
        --enable-icap-client \
        --enable-follow-x-forwarded-for \
        --enable-ssl \
        --enable-auth="basic,digest,ntlm,negotiate" \
    ...

Nous allons maintenant lancer la configuration et la création du package Debian (cela prends quelques minutes ...) :

1
2
3

./configure
debuild -us -uc -b
cd /usr/src

Vous devez maintenant avoir dans votre repertoire /usr/src, 4 nouveaux fichiers .deb (package d'installation Debian).

Pour finir, nous allons créer le package d'installation langpack de Squid3 :

1
2
3

cd squid-langpack-20090921
debuild -us -uc -b
cd /usr/src

Voila, nos packages sont prêts, nous allons maintenant pouvoir passer à l'installation de notre reverse proxy sous Squid3 :

1
2

dpkg -i squid-langpack_20090921-2~bpo50+1_all.deb squid3-common_3.1.3-2~bpo50+1_all.deb
dpkg -i squid3_3.1.3-2~bpo50+1_i386.deb

Notre reverse proxy sous Squid3 est maintenant installé et fonctionnel, il ne reste plus qu'a le configurer.

Modification de la configuration du serveur Apache local

Nous avons vu que nous allons publier un site sur le serveur Apache situé la même machine que notre reverse proxy, aussi notre reverse proxy écoutera sur les ports 80 (HTTP) et 443 (HTTPS), notre serveur Apache ne peut donc pas écouter sur les mêmes ports. Pour ce faire nous avons 2 solutions qui fonctionnent aussi bien et qui dépendent simplement de votre configuration.

La 1ère est de changer le port d'écoute du serveur Apache afin qu'il n'écoute plus sur le port 80 mais sur le port 81 (par exemple) en modifiant le fichier de configuration /etc/apache2/apache2.conf (ou httpd.conf) ou /etc/apache2/ports.conf :

1
2
3
4
5
6
7
8

NameVirtualHost *:81
Listen 81
 
<IfModule mod_ssl.c>
    # SSL name based virtual hosts are not yet supported, therefore no
    # NameVirtualHost statement here
    Listen 443
</IfModule>

La 2nd, notre préférée et que nous utiliserons dans notre configuration, est de changer l'adresse IP d'écoute du serveur Apache afin qu'il n'écoute que sur l'adresse de loopback 127.0.0.1 et que le reverse proxy n'écoute que sur l'adresse de l'interface réseau, pour ce faire, il faut modifier le fichier de configuration /etc/apache2/apache2.conf (ou httpd.conf) ou /etc/apache2/ports.conf :

1
2
3
4
5
6
7
8

NameVirtualHost *:80
Listen 127.0.0.1:80
 
<IfModule mod_ssl.c>
    # SSL name based virtual hosts are not yet supported, therefore no
    # NameVirtualHost statement here
    Listen 443
</IfModule>

ATTENTION : Si vous avez stipulé des ports ou des adresses IP d'écoutes dans vos fichiers de configuration de vos Virtual Hosts il faudra les modifier en conséquence. Généralement ces fichiers se trouvent a cet emplacement /etc/apache2/sites-enabled/.

Configuration du reverse proxy Squid 3.1.x

Le fichier de configuration par défaut de Squid est situé dans le repertoire /etc/squid3 et se nomme squid.conf (c'est original non !). Comme vous pouvez le constater il est relativement conséquent, aussi nous ne traiterons pas dans cet article de l'ensemble des configurations et paramètres possibles d'implémentation de Squid.

Pour commencer faites une sauvegarde de votre fichier squid.conf en le renommant squid.conf.bak par exemple, et recréez un nouveau fichier squid.conf complètement vierge.

Nous prenons par convention que les éléments en majuscule dans le fichier de configuration, type VOTRE_ADRESSE_IP (l'adresse IP du serveur Squid) ou SITE.PAR.DEFAUT (URL de votre site par défaut) sont a adapter à votre configuration.

Par défaut, Squid est configuré pour écouter sur le port TCP 3128, comme nous souhaitons utiliser Squid en tant que reverse proxy HTTP/HTTPS, nous allons modifier sa configuration pour que Squid écoute sur les port 80 et 443. Les premières lignes de notre nouveau squid.conf débute comme suit :

1
2
3

## Squid écoute sur l'interface ADRESSE_IP et les ports 80 et 443 en mode "accel vhost"
https_port VOTRE_ADRESSE_IP:443 cert=/CHEMIN/CERTIFICAT.cert key=/CHEMIN/CERTIFICAT.pem

 defaultsite=SITE.PAR.DEFAUT vhost
http_port VOTRE_ADRESSE_IP:80 defaultsite=SITE.PAR.DEFAUT accel vhost

Les lignes suivantes ne sont que la configuration par défaut de Squid :

4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

 
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl localhost src ::1/128
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
acl to_localhost dst ::1/128
acl all src
acl Safe_ports port 80 # http
acl SSL_ports port 443 # https
acl SSL_ports port 563 # snews
acl SSL_ports port 873 # rsync
acl Safe_ports port 81 # http
acl Safe_ports port 8080 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
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
acl CONNECT method CONNECT
 
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access allow all
icp_access deny all
htcp_access deny all
 
refresh_pattern ^ftp:        1440    20%    10080
refresh_pattern ^gopher:    1440    0%    1440
refresh_pattern -i (/cgi-bin/|\?) 0    0%    0
refresh_pattern .        0    20%    4320

Ensuite, nous devons préciser à Squid les domaines qui seront servi pour chaque serveur protégé par le reverse proxy en créant des groupes de destinations :

42
43
44
45
46

 
## On définit respectivement les domaines et sous domaines pour chacun des serveurs
acl dest_site_local dstdomain URL.SERVEUR.LOC ##ex : www.zentic.fr
acl dest_site_messagerie dstdomain URL.SERVEUR.EXCH
acl dest_site_web dstdomain URL.SERVEUR.WEB URL2.SERVEUR.WEB

Les lignes suivantes sont celles où l'on commence à configurer les serveurs distincts. Nous avons d'abord précisé les adresses IP des serveurs internes publiés ainsi que les ports concernés soit 80 (HTTP) et 443 (HTTPS). Puis nous ajoutons une directive pour chaque serveur afin de  spécifier à Squid l'adresse IP de chacun d'entre eux et les ACL (permissions) nécessaires  :

47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

 
## On définit les adresses internes de nos serveurs ...
acl dest_addr dst ADRESSE_IP1 ADRESSE_IP2
 
## ... ainsi que les ports de destination
acl dest_port port 80 443
 
## et on autorise le flux.
http_access allow dest_addr dest_port
 
## On définit local comme un "proxy" parent
cache_peer 127.0.0.1 parent 80 0 name=local no-query originserver login=PASS
## et on autorise seulement les sous domaines qui lui sont propres
cache_peer_access seo allow dest_site_local
 
## Idem pour le serveur messagerie
cache_peer ADRESSE_IP1 parent 443 0 name=messagerie no-query originserver default 
 login=PASS ssl sslflags=DONT_VERIFY_PEER sslcert=/CHEMIN/CERTIFICAT.crt
 sslkey=/CHEMIN/CERTIFICAT.key
## et on autorise seulement les sous domaines qui lui sont propres
cache_peer_access messagerie allow dest_site_messagerie
 
## Idem pour le serveur web
cache_peer ADRESSE_IP2 parent 80 0 name=web no-query originserver login=PASS
## et on autorise seulement les sous domaines qui lui sont propres
cache_peer_access web allow dest_site_web

Ensuite, vous n'avez probablement pas envie que les entêtes Via, X-Cache et X-Squid soient renvoyés aux clients, comme vous souhaitez que la présence de Squid soit (presque) invisible du monde extérieur :

73
74
75
76
77
78

 
## Supprime les entêtes squid vers le client
via off
reply_header_access X-Cache-Lookup deny
reply_header_access X-Squid-Error deny
reply_header_access X-Cache deny

Maintenant on rajoute les lignes permettant à Squid afin de transmettre l'adresse IP du client aux serveurs internes, tout en supprimant les précédentes entêtes X-Forward-For. Si la demande a déjà été faite par un proxy qui ajoute X-Forward-For dans l'entête de la requête avant d'arriver sur ce serveur Squid, cette instance Squid ajoutera sa propre adresse IP dans l'entête (par spécification), ce qui se traduira par une liste d'adresses IP au lieu d'une adresse IP unique.

79
80
81
82
83
84
85
86
87

 
## Supprime les entêtes X-Forward-For précédantes
header_replace X-Forwarded-For
 
## Utile pour transférer l'IP du client d'origine au serveur web interne
follow_x_forwarded_for allow all
forwarded_for on
 
hierarchy_stoplist cgi-bin ?

On passe à la configuration de la gestion du cache :

88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111

 
## On stipule le compte utilisateur du cache
cache_effective_user proxy
 
## Votre Email
cache_mgr NOM@DOMAINE.FR
 
## Squid va utiliser 1Go de RAM pour son cache
cache_mem 1024 MB
 
## Les éléments de plus de 2048Ko ne seront pas "caché" en RAM
maximum_object_size_in_memory 2048 KB
 
## Squid va utiliser jusqu'à 2Go dans /var/spool/squid3 pour le cache disque
cache_dir ufs /var/spool/squid3 2048 16 256
coredump_dir /var/spool/squid3
 
## tout les élément "cachables" seront mis en cache
minimum_object_size 0 KB
 
## Les éléments de plus de 64096Ko ne seront pas "caché"
maximum_object_size 64096 KB
 
cache_replacement_policy lru

On passe ensuite à la configuration des journaux de Squid3 :

112
113
114
115
116
117
118
119
120
121
122
123

 
## Renseignez le nom de votre serveur
visible_hostname NOM.DU.PROXY ## proxy.zentic.fr
 
## Configuration du format et emplacement des journaux Squid
logformat common %>a %ui %un [%tl] "%rm %ru HTTP/%rv" %>Hs %<st %Ss:%Sh
logformat combined %>a %ui %un [%tl] "%rm %ru HTTP/%rv" %>Hs %<st "%{Referer}>h"
 "%{User-Agent}>h" %Ss:%Sh
 
access_log /var/log/squid3/reverse-proxy_access.log squid
cache_log /var/log/squid3/reverse-proxy_cache.log
cache_store_log /var/log/squid3/reverse-proxy_store.log

Et pour finir quelques paramètres d'optimisation SSL et concernant l'accès à Exchange (OWA, Activsync, ...) :

124
125
126

 
ssl_unclean_shutdown on
extension_methods RPC_IN_DATA RPC_OUT_DATA

La configuration de notre reverse proxy Squid et terminée, vous n'avez plus qu'à redémarrer Squid.

/etc/init.d/squid3 restart

Configuration des journaux sur les serveurs web internes

Lorsque vous utilisez un proxy inverse vous pouvez remarquer que les journaux sur les serveurs se trouvant derrière le reverse proxy, indiqueront l'adresse IP comme venant du reverse proxy plutôt que du client, l'internaute. Il est une fonctionnalité de Squid comme on en a parlé plus tôt appelé forwarded_for qui permet de résoudre cela et qui permet de passer l'adresse IP des clients d'origine au serveur en back-end. Cependant, vous devez configurer un format de journal personnalisé sur les serveur back-end.

Pour Apache, nous devons éditer le fichier /etc/apache2/apache2.conf et a ajouter une nouvelle ligne dans la section de configuration de formats de journaux. Cette ligne telle qu'elle apparaît dans notre fichier de configuration ressemble à ceci :

LogFormat "%v:%p %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" proxied
SetEnvIf X-Forwarded-For "^.*\..*\..*\..*" is-forwarded
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

Il ne vous reste plus qu'à modifier les fichiers de configuration de vos virtual hosts afin de prendre en compte ces changements :

CustomLog /var/log/apache2/zentic-access.log proxied env=is-forwarded
CustomLog /var/log/apache2/zentic-access.log combined env=!is-forwarded

Ces modifications effectuées, redémarrez le serveur Apache.

/etc/init.d/apache2 restart