Squid et les exceptions pour les sites problématiques

Voici le troisième article sur le serveur proxy Squid, qui se concentre sur le peaufinage de l’installation et la résolution de problèmes, notamment le blocage de certains sites. Dans la configuration actuelle, Squid gère les connexions HTTP aussi bien que les connexions HTTPS, mais l’installation n’a pas encore d’utilité concrète.

Nous aborderons par la suite des configurations pratiques au quotidien comme la surveillance du trafic web du réseau local et le filtrage des sites web indésirables. Avant d’aller plus loin, il nous faut régler quelques points de détail.

• Les sites qui posent problème
• L’approche pragmatique
• Définir les exceptions au niveau de Squid
• Centraliser la liste des exceptions

Les sites qui posent problème

Dans l’ensemble, notre proxy transparent fonctionne très bien pour l’écrasante majorité des sites. L’ensemble du trafic web du réseau local est intercepté par le proxy et inscrit dans /var/log/squid/access.log. Or, vous aurez probablement remarqué des problèmes avec certains sites web. Ou plus généralement tout ce qui nécessite une connexion sur le port 443. Comme la synchronisation d’un dépôt Gitlab, par exemple.

$ git clone https://gitlab.com/kikinovak/opensuse
Cloning into 'opensuse'...
fatal: unable to access 'https://gitlab.com/kikinovak/opensuse/': 
SSL certificate problem: self signed certificate in certificate chain

De manière similaire, Thunderbird proteste au démarrage lorsqu’il essaie de synchroniser le carnet d’adresses avec OwnCloud.

L’approche pragmatique

Évidemment, on pourrait très bien ajouter notre certificat fait maison dans git et dans Thunderbird, mais ne perdons pas de vue le fait que nous cherchons uniquement à mettre en place une solution de journalisation et de filtrage du trafic web, et que cette façon de procéder nous ferait sauter à travers des cerceaux en feu pour pas grand-chose. Par ailleurs, certains sites de banques, de trading ou de monnaies virtuelles ne fonctionnent pas avec notre certificat auto-signé, et ce n’est pas plus mal.

La solution pragmatique consiste donc à créer des exceptions pour les quelques domaines qui posent problème, de manière à ce qu’ils passent à travers le serveur proxy.

Définir les exceptions au niveau de Squid

Après une première tentative quelque peu compliquée au niveau du pare-feu – et que je ne détaillerai pas ici – j’ai reçu un mail de Yuri Voinov qui est inscrit comme moi à la mailing list de Squid, et qui m’a fourni une solution simple, élégante et fonctionnelle pour définir des exceptions au niveau de la configuration de Squid. Je tiens à le remercier ici.

Dans le fichier /etc/squid/squid.conf, éditer les règles SSL comme ceci.

# Règles SSL
acl DiscoverSNIHost at_step SslBump1
acl NoSSLIntercept ssl::server_name_regex "/etc/squid/no-proxy.txt"
ssl_bump peek DiscoverSNIHost
ssl_bump splice NoSSLIntercept
ssl_bump bump all

Les URLs à exclure du traitement figurent dans le fichier /etc/squid/no-proxy.txt. Pour la syntaxe, on utilisera le cas échéant les expressions régulières POSIX classiques.

# Académie de Montpellier
ac\-montpellier\.fr
# Actalians
actalians\.fr
# AGI Lease 
agi\-lease\.fr
# Binance
binance\.com
# Bitfinex
bitfinex\.com
# BitMEX
bitmex\.com
# Cloud Microlinux
cloud\.microlinux\.fr
...

Cette solution présente une série d’avantages techniques, notamment le fait que les sites définis comme exception apparaissent quand-même dans les logs de Squid. On la préférera donc au traitement en amont dans le pare-feu.

Centraliser la liste des exceptions

Si l’on a plusieurs serveurs proxy transparents à gérer, ce n’est peut-être pas une mauvaise idée de centraliser ces informations. On partira du simple principe qu’un domaine qui pose problème dans le réseau d’un client particulier posera le même problème chez tous les autres. Pour éviter de se retrouver avec des fichiers no-proxy.txt vaguement redondants et qui fleurissent à droite et à gauche comme des mauvaises herbes, on peut ranger ce fichier dans un dépôt Gitlab. Voilà à quoi cela ressemble dans ma configuration.

$ cd /etc/squid/
$ sudo git clone https://gitlab.com/kikinovak/no-proxy.git
$ sudo chown -R squid:squid no-proxy/
$ ls no-proxy/
no-proxy.txt  README.md

À partir de là, il suffira d’ajuster le chemin vers le fichier no-proxy.txt dans la configuration de Squid.

# SSL-Bump
acl DiscoverSNIHost at_step SslBump1
acl NoSSLIntercept ssl::server_name_regex "/etc/squid/no-proxy/no-proxy.txt"
ssl_bump peek DiscoverSNIHost
ssl_bump splice NoSSLIntercept
ssl_bump bump all

La suite au prochain numéro, où nous utiliserons Squid pour surveiller le trafic web local.

La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.