+ sur squid
[ Accueil ] [ Fonctionnement ] [ Squid ] [ + sur squid ] [ SquidGuard ] [ + sur SquidGuard ]
Affiner la configuration.
Il y a deux points importants, qu'il peut être utile d'étudier, et qui correspondent aux deux fonctions principales d'un proxy.
Identifier les utilisateurs.
Attention.
Vous aurez des ennuis pour authentifier vos utilisateurs, si vous comptez rendre votre proxy transparent. Les deux fonctionnalités sont incompatibles.
Dans la configuration mise en oeuvre ici, nous ne faisons 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'authentification.
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 :
ncsa_auth, smb_auth, getpwnam_auth, ldap_auth, pam_auth
Les plus intéressants sont probablement :
- ldap_auth, qui permet d'authentifier les utilisateurs depuis un annuaire LDAP (si vous maîtrisez déjà LDAP),
- smb_auth, qui permet d'utiliser un contrôleur de domaine Windows NT.
- ncsa_auth, qui utilise un fichier d'utilisateurs local.
Nous allons mettre en oeuvre ncsa_auth, c'est le plus simple, ce ne sera peut-être pas le plus utile, surtout si le réseau local est un domaine Microsoft Windows.
Construire un fichier d'utilisateurs.
Nous allons créer un fichier /etc/squid/users
# touch /etc/squid/users
Nous le remplissons ensuite avec la commande htpasswd, normalement fournie dans le paquet apache-common (normalement vous l'avez puisque Debian utilise par défaut Apache pour faire tourner Webmin):
# htpasswd -b /etc/squid/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 :
chris:bnIuGLzE0Gpcg daniel:SBURpBvExhYPQ michele:6hDQXgAjRdfXg
Notez que les mots de passe sont chiffrés. Il aurait été possible d'utiliser le fichier passwd des utilisateurs Linux, mais ce n'est pas forcément une très bonne idée...
Vérifions que ça 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 un espace :
# /usr/lib/squid/ncsa_auth /etc/squid/users chris ******* OK chose truc ERR
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 ça fonctionne comme ça, c'est déjà bon signe.
Configurer squid pour réclamer l'authentification de vos utilisateurs.
On peut le faire avec Webmin, faisons-le donc.
Pour Authentification program, indiquez le chemin du module ncsa_auth, suivi du chemin du fichier des utilisateurs, séparés par un espace.
Pour Number of authentication programs:
"Defaults to 5 if an authenticator has been enabled."
Lorsqu'un programme d'authentification a été choisi, le nombre d'instances de ce programme est par défaut de 5. Si vous avez de nombreux utilisateurs, il sera peut-être nécessaire d'augmenter ce nombre.
Time to cache passwords for:
"How long Squid will cache a successful login for before querying the authentication program again."
Combien de temps Squid va se souvenir d'une authentification réussie, avant de demander une nouvelle authentification.
Time to bind user to an IP address for:
"If the same user tries to login twice from two different IP addresses during this period, he will benied. This can be used to prevent the sharing of proxy passwords between multiple users."
Si le même utilisateur essaye de s'authentifier depuis deux machines différentes dans un laps de temps trop court, il sera refusé. Ceci peut être utilisé pour empêcher le partage d'un droit d'accès entre plusieurs utilisateurs.
Cette dernière option est tout à fait digne d'intérêt...
On "save", on "apply les changes" et on croit que c'est fini, mais non... Sans ACL pour utiliser l'authentification, squid ne demandera rien à vos utilisateurs.
Vérifions tout de même qu'après rechargement de squid le module d'authentification est bien présent :
gw2:/usr/lib/squid# ps aux | grep [s]quid root 1536 0.0 1.1 3824 1124 ? S 14:22 0:00 /usr/sbin/squid -D -sYC proxy 1538 0.0 7.0 9616 6712 ? S 14:22 0:04 (squid) -D -sYC
Non, il n'y est pas.
 |
Passons donc aux ACLs. On a déjà vu comment s'y prendre, nous créons une nouvelle ACL de type "External auth" : (save) |
 |
Nous plaçons une nouvelle ligne dans les restrictions, en interdisant (deny) à tous ceux qui ne satisfont pas (Don't match ACLs) à l'ACL Users.
(save) |
 |
Enfin, nous remontons cette restriction juste au dessus de allow LocalNet |
Application des changements, nous vérifions que maintenant le module d'authentification est bien chargé :
gw2:/usr/lib/squid# ps aux | grep [s]quid root 1536 0.0 1.1 3824 1124 ? S 14:22 0:00 /usr/sbin/squid -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 authentification.
Comme nous l'avons paramétré, cette authentification restera valide 30 minutes (si le navigateur n'est pas refermé entre temps), et pendant ces 30 minutes, plus aucun autre utilisateur ne pourra utiliser ce login sur toute autre machine de votre LAN. |
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 :
1053787250.063 7 pchris.maison.ms TCP_HIT/200 892
GET http://www.free.fr/img/picto_assunet.gif chris NONE/ -image/gif
1053787250.067 8 pchris.maison.ms TCP_HIT/200 401
GET http://www.free.fr/im/blank_F5F5F5.gif chris NONE/ -image/gif
1053787266.004 25 pchris.maison.ms TCP_HIT/200 9332
GET http://www.free.fr/promos/Egg-senior-234x75-c.gif chris NONE/- image/gif
1053787274.083 43 pchris.maison.ms TCP_HIT/200 7789
GET http://www.free.fr/im/banniere-autopromo-edengo.gif chris NONE/- image/gif
Big Brother se fait de plus en plus présent...
Votre fichier squid.conf ressemble maintenant à ceci :
hierarchy_stoplist cgi-bin ? acl QUERY urlpath_regex cgi-bin \? no_cache deny QUERY acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl SSL_ports port 443 563 10000 acl Safe_ports port 80 acl Safe_ports port 21 acl Safe_ports port 443 563 acl Safe_ports port 70 acl Safe_ports port 210 acl Safe_ports port 1025-65535 acl Safe_ports port 280 acl Safe_ports port 488 acl Safe_ports port 591 acl Safe_ports port 777 acl Safe_ports port 901 acl purge method PURGE acl CONNECT method CONNECT acl LocalNet src 192.168.0.0/255.255.255.0 acl Users proxy_auth REQUIRED http_access allow manager localhost http_access deny manager http_access allow purge localhost http_access deny purge http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost http_access deny !Users http_access allow LocalNet http_access deny all icp_access allow all log_fqdn on authenticate_program /usr/lib/squid/ncsa_auth /etc/squid/users authenticate_ttl 30 minute authenticate_ip_ttl 30 minute
Notez que vous pouvez aussi gérer la liste des utilisateurs avec la fonction "Proxy Authentication" du module Squid de Webmin, sans manipuler htpasswd, à condition que :
- vous ayez créé le fichier des utilisateurs, même vide,
- vous ayez configuré Squid pour utiliser ncsa_auth
A ce moment, l'option "Proxy Authentication" fonctionnera aussi bien que "htpasswd".
Si pour vous l'authentification est une chose primordiale, et que vous disposez déjà d'une source d'authentification sur votre LAN, intéressez-vous peut-être à l'existence d'un module d'authentification qui vous permettrait de n'employer qu'une seule base d'utilisateurs...
J'ai pu effectuer quelques tests avec le module d'authentification qui s'appuie sur SMB (smb_auth), autrement dit, qui permet d'authentifier les utilisateurs à partir d'un contrôleur de domaine Microsoft, ça fonctionne, mais SAMBA doit être installé sur le proxy, même s'il ne tourne pas. Suivant l'exposition de votre proxy par rapport au lien Internet, ça peut présenter quelques risques.
Sa mise en place ne pose pas de problèmes particuliers, la documentation est suffisamment claire : http://www.hacom.nl/~richard/software/smb_auth.html
Optimiser le cache.
Un proxy sert a 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 ;-))
Rendre le proxy transparent.
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 cela :
- 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),
- 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.
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.
La règle de redirection.
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-port 3128
Il est possible de rediriger de façon transparente sur un proxy installé sur une autre machine que la passerelle, à la condition que cette dernière soit placée dans un autre réseau IP que le LAN, faute de quoi, la translation de port ne fonctionnera pas correctement.
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. Dans la pratique, vous devrez donc disposer de trois interfaces réseau sur votre routeur NAT.
Paramétrage de Squid.
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é, voyons comment.
Allons, avec Webmin, dans l'option "Miscellaneous options" :
Je vous le donne comme une recette. En principe, je n'aime pas trop ça, mais pour comprendre ici ce que l'on fait, il faudrait étudier dans le détail le fonctionnement du proxy, ce qui nous conduirait à écrire non plus un chapitre, mais un livre entier...
Ca nous donne dans squid.conf :
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563 10000
acl Safe_ports port 80
acl Safe_ports port 21
acl Safe_ports port 443 563
acl Safe_ports port 70
acl Safe_ports port 210
acl Safe_ports port 1025-65535
acl Safe_ports port 280
acl Safe_ports port 488
acl Safe_ports port 591
acl Safe_ports port 777
acl Safe_ports port 901
acl purge method PURGE
acl CONNECT method CONNECT
acl LocalNet src 192.168.0.0/255.255.255.0
acl Users proxy_auth REQUIRED
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny !Users
http_access allow LocalNet
http_access deny all
icp_access allow all
log_fqdn on
authenticate_program /usr/lib/squid/ncsa_auth /etc/squid/users
authenticate_ttl 30 minute
authenticate_ip_ttl 30 minute
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
httpd_accel_host virtual
httpd_accel_port 80
Conclusions.
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 le HTTPS ou si vous devez authentifier vos utilisateurs.Beaucoup d'autres choses sont possibles, je ne les pas encore essayées, je vous laisse faire.
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.