AvertissementDepuis quelque temps, j’ai mis en place un serveur proxy cache transparent dans mon entreprise et auprès de quelques-uns de mes clients. Dans la configuration actuelle, Squid gère les connexions HTTP aussi bien que les connexions HTTPS. Le but de l’opération, c’est d’une part de surveiller le trafic web du réseau local, et d’autre part de filtrer le trafic indésirable, ce qui fera l’objet d’un article à venir.

Les sites qui posent problème

Dans l’ensemble, cette solution de monitoring et de filtrage fonctionne très bien pour l’écrasante majorité des sites visités. L’article du jour traite donc de la poignée de sites restants qui peuvent poser problème. Ce ne sont pas forcément des sites web d’ailleurs, mais tout ce qui nécessite une connexion sur le port 443. Comme la synchronisation d’un dépôt Github, par exemple.

$ git clone https://github.com/kikinovak/opensuse
Clonage dans 'opensuse'...
fatal: unable to access 'https://github.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.

Squid 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 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
# DDEX
ddex\.io
# Dropbox
dropbox\.com
# DWService
dwservice\.net
# Github
github\.com
# HitBTC
hitbtc\.com
# IDEX
idex\.market
# NBB Lease
nbb\-lease\.fr
# TradingView
tradingview\.com
# YoBit
yobit\.net

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 Github, créer un lien symbolique vers le fichier et faire pointer la configuration locale vers ce lien. Voilà à quoi cela ressemble sur le serveur dans mon bureau.

$ cd /etc/squid/
$ sudo ln -s /home/microlinux/centos/el7/config/squid/no-proxy.txt .

Comme il faut s’y attendre, ce genre de bidouille crée un problème d’accès avec SELinux en mode renforcé. Voici ce qu’on peut faire pour rectifier le tir.

$ sudo ausearch -c 'squid' --raw | audit2allow -M my-squid
$ sudo semodule -i my-squid.pp

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.

 


1 commentaire

Squid et les exceptions pour les sites problématiques - My Tiny Tools · 12 février 2019 à 19 h 11 min

[…] (Source: Journal du hacker) […]

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.