+ sur squid

Il y a deux points importants, qu'il peut être utile d'étudier, et qui correspondent aux deux fonctions principales d'un proxy.

Attention. Vous aurez des ennuis pour identifier vos utilisateurs, si vous comptez rendre votre proxy transparent. Les deux fonctionnalités sont incompatibles.

Dans la configuration mise en œuvre jusqu'ici, nous ne faisions pas de contrôle sur les utilisateurs, seulement sur les IPs des machines clientes. Vous pouvez souhaiter identifier vos utilisateurs lorsqu'ils vont surfer sur le Net. Dans ce cas, il vous faudra mettre en place un système d'identification (et renoncer au mode transparent).

Il y a plusieurs méthodes disponibles pour authentifier les utilisateurs du proxy. Elles font toutes appel à un programme extérieur, différent suivant le moyen choisi. Debian propose les modules suivants :

squid_ldap_auth, msnt_auth, ncsa_auth, pam_auth, sasl_auth, smb_auth, yp_auth, getpwname_auth, ntlm_auth, digest_ldap_auth, digest_pw_auth…

Je ne les ai pas tous essayés, dans une autre vie peut-être ? Nous verrons un peu :

• ncsa_auth qui permet d'identifier les utilisateurs à partir d'un fichier local de type « htpasswd » ;
• ntlm_auth qui permet d'identifier les utilisateurs à partir d'un annuaire Active Directory dans un domaine Microsoft.

Nous allons dans un premier temps essayer ncsa_auth, ce ne sera peut-être pas le plus utile, surtout si le réseau local est un domaine Microsoft Windows, mais c'est le plus simple à mettre en œuvre.

Nous allons créer un fichier  /etc/squid/users

# touch /etc/squid3/users

Nous le remplissons ensuite avec la commande htpasswd, normalement fournie dans le paquet apache-common.

# htpasswd -b /etc/squid3/users <nom de l'utilisateur>  <mot de passe>

A répéter autant de fois que nécessaire avec des vrais noms d'utilisateurs et des vrais mots de passe…

Le fichier se remplit comme suit :

# cat /etc/squid3/users
user1:ZNlvws1XtZpQE
user2:F2UUyQD41v.zw
user3:zpJXchoMHUpv2

Notez que les mots de passe sont chiffrés.

Vérifions que çeci fonctionne, en lançant « à la main » le module d'authentification /usr/lib/ncsa_auth. Nous entrerons alors dans une boucle où il faudra entrer sur une ligne un nom d'utilisateur et son mot de passe, séparés par une espace :

# /usr/lib/squid3/ncsa_auth /etc/squid3/users
user1 password1
OK
user2 password2
OK
user3 password3
OK
machin chose
ERR No such user

Le système répond par OK ou par ERR suivant que l'authentification réussit ou non.

Sortez de la boucle avec un ctrl-d.

Si l'authentification fonctionne comme ceci, c'est déjà bon signe.

Nous devons commencer par fournir quelques directives de type auth_param :

auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/users
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours

program, indiquez le chemin du module ncsa_auth, suivi du chemin du fichier des utilisateurs, séparés par une espace.

children, 5 est une valeur usuelle. Si vous avez de nombreux utilisateurs, il sera peut-être nécessaire d'augmenter ce nombre.

realm, n'est rien d'autre qu'un texte qui apparaîtra dans la fenêtre de demande d'identification.

credentialsttl, durée de vie de l'identification. A condition bien sûr que le navigateur ne soit pas fermé avant.

Il nous faut maintenant créer une “acl” supplémentaire, pour obliger l'identification,

acl Users proxy_auth REQUIRED

Puis n'autoriser l'accès que si le client est dans notre réseau et que l'identification est réussie :

http_access allow LocalNet Users

Ceci nous conduit à un fichier de configuration de la forme :

auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/users
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443
acl Safe_ports port 80		# 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 CONNECT method CONNECT
acl LocalNet src 192.168.0.0/24
acl Users proxy_auth REQUIRED
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access allow LocalNet Users
http_access deny all
icp_access allow all
http_port 3128
hierarchy_stoplist cgi-bin ?
access_log /var/log/squid3/access.log squid
acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY
refresh_pattern ^ftp:		1440	20%	10080
refresh_pattern ^gopher:	1440	0%	1440
refresh_pattern .		0	20%	4320
icp_port 3130
coredump_dir /var/spool/squid3

Application des changements, nous vérifions que maintenant le module d'authentification est bien chargé :

# ps aux | grep [s]quid
root 1536 0.0 1.1 3824 1124 ? S 14:22 0:00 /usr/sbin/squid3 -D -sYC
proxy 1538 0.0 7.0 9616 6712 ? S 14:22 0:04 (squid) -D -sYC
proxy 2178 0.0 0.4 1712 388 ? S 16:30 0:00 (ncsa_auth) /etc/squid/users
proxy 2179 0.0 0.4 1712 388 ? S 16:30 0:00 (ncsa_auth) /etc/squid/users
proxy 2180 0.0 0.4 1712 388 ? S 16:30 0:00 (ncsa_auth) /etc/squid/users
proxy 2181 0.0 0.4 1712 388 ? S 16:30 0:00 (ncsa_auth) /etc/squid/users
proxy 2182 0.0 0.4 1712 388 ? S 16:30 0:00 (ncsa_auth) /etc/squid/users

Cette fois-ci, il y est. Ca devrait donc fonctionner :

Et voilà. Pour accéder au monde extérieur, Squid nécessite maintenant une identification.

Si nous allons faire un petit tour dans les dernières lignes de /var/log/squid/access.log, nous constatons que le nom d'utilisateur figure pour chaque requête :

1180428383.041 0 192.168.0.15 TCP_MEM_HIT/200 632 GET http://pages-perso.esil.univ-mrs.fr/index.html 
                              user1 NONE/- text/html

La procédure qui permet d'identifier les utilisateurs à partir d'Active Directory est nettement plus complexe. Elle est détaillée à la page suivante.

Un proxy sert à optimiser la bande passante utilisée sur le Net, en permettant de garder en cache les pages les plus souvent visitées. Si c'est une de vos principales préoccupations, il sera probablement nécessaire d'agir sur les diverses options du cache. Passez alors du temps à lire la documentation. Vous pourrez agir sur la taille du cache, sa répartition sur les divers disques durs…

Pour réaliser correctement une telle opération, il vous faudra installer d'abord des outils d'audit de performance dudit cache. Détailler ces opération ici nous mènerait trop loin. (Il y a une doc assez complète avec Squid )

Attention…

• Cette méthode est incompatible avec l'authentification des utilisateurs. Même si squid est configuré comme nous l'avons vu pour l'authentification ncsa, celle-ci ne fonctionnera plus.

• cette méthode ne supporte que HTTP. FTP est impossible en mode transparent,

• un seul port peut être redirigé de façon transparente, le 80, de préférence, puisque c'est le port habituel pour HTTP.

Utiliser un proxy nécessite normalement de configurer son « butineur » de manière à ce qu'il interroge toujours le proxy, quelle que soit la cible.

Vos utilisateurs ont donc généralement 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 deux moyens d'éviter ceci :

• utilisez votre firewall pour bloquer pour vos postes clients l'accès direct à l'Internet par les ports http et https (80, 443, 563…). De cette manière, vos utilisateurs n'auront d'autre possibilité que de passer par le proxy (sauf pour des serveurs exotiques, qui utiliseraient un autre port), c'est la seule manière possible si vous souhaitez identifier vos utilisateurs ;

• rendre 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 le port 80 (vous devrez vous contenter d'un seul port transparent) vers le port proxy sur son port (3128 par défaut pour squid), ça se fait sans problèmes sur votre 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 votre passerelle, en admettant que votre réseau est dans 192.168.0.0 et que votre proxy possède l'adresse 192.168.0.252. Nous supposons que le proxy est installé sur la machine qui assure également le rôle de passerelle  (commande à entrer sur une seule ligne, bien entendu) :

iptables -t nat -A PREROUTING -s 192.168.0.0/255.255.255.0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128

De multiples solutions sont possibles pour placer un proxy transparent ailleurs que sur la passerelle. Elles sont plus ou moins compliquées à gérer au niveau du routage. Si la question vous intéresse, voyez :

• Le routage, compléments ;
• Le routage sélectif.

Avec un routeur à trois voies, par exemple deux réseaux IP (disons 192.168.0.0 et 192.168.1.0), et un accès Internet, si le LAN est sur 192.168.0.0, il faudra placer le proxy sur 192.168.1.0, disons 192.168.1.2. La règle IPtables s'écrira alors :

iptables -t nat -A PREROUTING -s 192.168.0.0/255.255.255.0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.2:3128

Bien entendu, il faudra que le routage se fasse entre les réseaux 192.168.0.0 et 192.168.1.0.

Comme nous l'avons vu dans le chapitre sur HTTP, 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 3128 transparent

Comme nous l'avons vu, la transparence du proxy entraîne de nombreuses restrictions. A moins que vous y teniez absolument, mieux vaut choisir une autre solution, principalement si vous voulez cacher le FTP et/ou faire passer le HTTPS par votre proxy (il n'y aura pas d'effet de cache, juste un transfert des données comme dans un tunnel) ou encore, si vous devez identifier vos utilisateurs.

Dans la suite de cet exposé, squid ne sera pas transparent.

Pour ce qui est du filtrage d'accès, il est possible de faire déjà des choses avec Squid tout seul, mais le « helper » SquidGuard que nous allons voir dans la suite rend inutiles les tentatives de filtrage avec les seuls moyens de Squid.