Proxy, filtrage web et inspection TLS

Un proxy web est un serveur intermédiaire par lequel passent les connexions des postes vers les sites Internet : il peut authentifier l'utilisateur, filtrer les sites par catégorie ou par réputation, analyser les fichiers téléchargés et journaliser chaque accès. L'inspection TLS va plus loin en déchiffrant temporairement le trafic HTTPS pour l'analyser. Ce chapitre présente le proxy explicite et le proxy transparent, le filtrage DNS, le fonctionnement de l'inspection TLS et ses limites techniques et légales, et le proxy inverse qui protège un site publié.

Pourquoi filtrer la navigation

La navigation web est la première porte d'entrée et de sortie des attaques : téléchargement d'un logiciel malveillant, page d'hameçonnage qui imite la messagerie de l'entreprise, logiciel malveillant qui contacte son serveur de commande, copie de données vers un service de stockage en ligne. Le filtrage web sert à :

• bloquer les sites malveillants connus, les catégories à risque (sites de téléchargement illégal, domaines créés il y a quelques heures) et, si la charte le prévoit, les catégories sans rapport avec le travail ;
• analyser les fichiers téléchargés avec un antivirus ;
• tracer les accès, utilisateur par utilisateur, pour enquêter après un incident ;
• appliquer la charte informatique de l'organisation.

Proxy explicite, proxy transparent

Squid est le proxy libre historique : cache, listes de contrôle d'accès, authentification, journaux détaillés. Il reste utilisé sur des serveurs Linux dédiés, mais ses paquets pour pfSense sont dépréciés (chapitre 4). En 2026, le filtrage web d'une PME passe plutôt par le pare-feu nouvelle génération (Stormshield, Fortinet, Sophos, UniFi), qui intègre filtrage par catégories d'URL, antivirus et inspection TLS, ou par un service de filtrage en nuage (Secure Web Gateway), qui suit aussi les portables en déplacement.

Le filtrage DNS

Avant toute connexion, un poste résout le nom du site. Le filtrage DNS refuse de résoudre les domaines malveillants ou interdits : le résolveur répond par une adresse de blocage ou par « domaine inexistant ». C'est simple, peu coûteux et efficace contre une grande partie des menaces :

• sur pfSense, le paquet pfBlockerNG (module DNSBL) ajoute des listes de blocage au résolveur Unbound ; OPNsense le fait nativement dans les réglages d'Unbound ;
• des résolveurs publics filtrants existent, et les pare-feu commerciaux proposent leurs propres listes, mises à jour en continu.

Le filtrage DNS a un point faible : il ne sert à rien si le poste interroge un autre résolveur. Il faut donc :

• bloquer sur le pare-feu le port 53 sortant pour tous, sauf pour le résolveur interne ;
• maîtriser le DNS chiffré (DNS over HTTPS, DoH), que les navigateurs peuvent utiliser pour contourner le résolveur de l'entreprise : on désactive DoH par stratégie de groupe dans Chrome, Edge et Firefox (Firefox le désactive aussi de lui-même quand le résolveur de l'entreprise répond « domaine inexistant » pour le domaine témoin use-application-dns.net) et on bloque les résolveurs DoH publics connus.

L'inspection TLS

Plus de 90 % des pages web sont aujourd'hui chargées en HTTPS. Un proxy ou un pare-feu qui ne déchiffre pas ne voit que le nom du site (dans le SNI ou la requête CONNECT) : il peut bloquer un domaine, mais pas un fichier malveillant téléchargé depuis un site légitime, ni une fuite de données vers un service autorisé. L'inspection TLS (ou déchiffrement SSL) permet cette analyse.

Comment elle fonctionne. Le proxy se place volontairement au milieu de la connexion :

1. le poste demande https://exemple.fr ; le proxy intercepte la connexion ;
2. le proxy ouvre lui-même une connexion TLS vers le vrai site, et vérifie son certificat comme le ferait un navigateur ;
3. le proxy fabrique à la volée un certificat pour exemple.fr, signé par une AC interne de l'entreprise, et le présente au poste ;
4. le poste accepte ce certificat parce que l'AC interne est installée dans son magasin de confiance (déployée par stratégie de groupe) ;
5. le proxy déchiffre ce qui vient du poste, l'analyse (antivirus, filtrage, prévention des fuites), le rechiffre vers le site, et inversement.

Ce qu'il faut prévoir.

• L'AC d'inspection est dédiée, sa clé privée est protégée : qui la détient peut intercepter tout le trafic des postes. Les appareils qui n'ont pas cette AC (téléphones personnels, invités) obtiennent des erreurs de certificat : on n'inspecte pas leur trafic.
• Les exemptions : les sites bancaires, de santé, et les services dont les applications vérifient un certificat précis (épinglage de certificat : certaines applications de mise à jour, de visioconférence ou de banque) ne sont pas déchiffrés.
• HTTP/3 (QUIC) circule sur UDP 443, que la plupart des proxys n'inspectent pas : on le bloque sur le pare-feu pour que les navigateurs reviennent à HTTPS sur TCP.
• Le chiffrement du SNI (Encrypted Client Hello, ECH), en cours de déploiement, masque le nom du site dans la négociation TLS et limitera le filtrage sans déchiffrement.
• La performance : déchiffrer et rechiffrer demande de la puissance ; un pare-feu sous-dimensionné ralentit toute la navigation.

Le cadre légal de l'inspection

Déchiffrer le trafic des salariés, c'est pouvoir lire des informations personnelles. L'inspection est légitime pour la sécurité, à condition d'être encadrée. L'ANSSI a publié des recommandations sur l'analyse des flux HTTPS, et la CNIL rappelle les principes à respecter :

• informer préalablement les salariés (charte informatique, note d'information) : aucun dispositif de contrôle ne peut être mis en place à leur insu (article L1222-4 du Code du travail) ;
• consulter le comité social et économique (CSE) sur la mise en place de moyens de contrôle de l'activité des salariés, dans les entreprises qui en ont un ;
• proportionnalité : déchiffrer pour la sécurité (analyse antivirus, détection de fuites), pas pour lire les échanges privés ; exclure les catégories sensibles (banque, santé, messageries personnelles) ;
• protéger et limiter les journaux du proxy : ils révèlent la vie de chacun ; accès restreint aux administrateurs habilités, durée de conservation limitée (de l'ordre de six mois à un an pour des journaux de sécurité, selon les recommandations de la CNIL), et inscription du traitement au registre RGPD.

Le proxy inverse

Le proxy « classique » (forward proxy) protège les postes qui sortent vers Internet. Le proxy inverse (reverse proxy) protège un serveur qui reçoit des connexions d'Internet : il se place en DMZ devant le serveur web, reçoit les connexions HTTPS des clients, termine TLS et transmet les requêtes au serveur réel.

• Le serveur réel n'est jamais exposé directement, et peut rester dans une zone plus protégée.
• Un seul point gère les certificats (renouvellement ACME) et la configuration TLS.
• On peut y ajouter un pare-feu applicatif web (WAF, comme ModSecurity avec les règles OWASP CRS) qui bloque les injections et les requêtes anormales, et une limitation du nombre de requêtes par adresse.

nginx, HAProxy ou Traefik jouent ce rôle ; HAProxy existe aussi en paquet sur pfSense et OPNsense. Les attaques applicatives elles-mêmes, et la façon de les corriger dans le code, sont l'objet du cours Sécurité des applications.

Exercices

Exercice 1 sur 5 Explicite ou transparent ? Réussi À revoir

Sorbier hésite entre un proxy explicite, déployé par stratégie de groupe, et un proxy transparent. La direction veut des journaux qui indiquent quel utilisateur a consulté quel site, et qu'aucun poste ne puisse contourner le filtrage. Que recommandes-tu, et quelles règles de pare-feu ajoutes-tu ?

Voir la réponseMasquer la réponse de l'exercice 1

Un proxy explicite avec authentification Kerberos : sur un domaine, les postes s'authentifient de façon transparente, et chaque ligne de journal porte le nom de l'utilisateur, ce qu'un proxy transparent ne fournit pas facilement. Pour empêcher le contournement, le pare-feu bloque HTTP et HTTPS sortants (TCP 80 et 443, UDP 443) pour tous les réseaux, sauf pour l'adresse du proxy, et bloque le DNS sortant sauf pour le résolveur interne. Un poste mal configuré n'a alors aucun moyen de sortir sans passer par le proxy.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 5 Contourner le filtrage DNS Réussi À revoir

Le filtrage DNS de Sorbier bloque les domaines malveillants sur le résolveur interne 192.168.10.177. Un technicien constate qu'un poste atteint quand même un domaine bloqué. Donne deux explications possibles et la parade de chacune.

Voir la réponseMasquer la réponse de l'exercice 2

• Le poste interroge un autre résolveur (un DNS public configuré à la main) : bloquer sur le pare-feu le port 53 (UDP et TCP) sortant pour toutes les machines sauf 192.168.10.177, et le port 853 (DNS over TLS).
• Le navigateur utilise DNS over HTTPS vers un résolveur public : désactiver DoH par stratégie de groupe dans les navigateurs, faire répondre « domaine inexistant » au domaine témoin use-application-dns.net pour Firefox, et bloquer les adresses des résolveurs DoH publics connus.
• (Autre possibilité : le poste utilise une entrée locale dans son fichier hosts, ou une adresse IP directe. Le filtrage par catégories du proxy et le blocage des adresses de réputation malveillante complètent alors le filtrage DNS.)

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 5 Comprendre l'inspection TLS Réussi À revoir

Après l'activation de l'inspection TLS sur le pare-feu, les postes du domaine naviguent normalement, mais le téléphone personnel d'un salarié, connecté au Wi-Fi des salariés, affiche « Votre connexion n'est pas privée » sur tous les sites.

1. Explique pourquoi.
2. Que faut-il faire : installer l'AC d'inspection sur le téléphone, ou autre chose ?

Voir la réponseMasquer la réponse de l'exercice 3

1. Le pare-feu présente pour chaque site un certificat qu'il a fabriqué, signé par l'AC interne d'inspection. Les postes du domaine ont cette AC dans leur magasin de confiance (déployée par stratégie de groupe), donc ils l'acceptent. Le téléphone personnel ne la connaît pas : pour lui, le certificat est signé par une autorité inconnue, ce qui ressemble à une attaque de l'homme du milieu, et il affiche l'avertissement à juste titre.
2. Ne pas installer l'AC d'inspection sur des appareils personnels : l'entreprise pourrait alors déchiffrer tout le trafic privé du téléphone, ce qui est disproportionné, et l'AC sortirait du parc maîtrisé. Il faut plutôt que le téléphone personnel n'ait pas accès au Wi-Fi des salariés (802.1X avec certificat machine, réservé aux postes du parc) et utilise le Wi-Fi invité, dont le trafic n'est pas déchiffré.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 5 Les conditions légales Réussi À revoir

Le directeur de Sorbier veut activer l'inspection TLS « dès demain, pour voir ce que font les salariés ». Rédige en quelques lignes ta réponse : ce qui est possible, à quelles conditions, et ce qui ne l'est pas.

Voir la réponseMasquer la réponse de l'exercice 4

L'inspection TLS est possible pour un objectif de sécurité : analyser les fichiers téléchargés, bloquer les sites malveillants, détecter les fuites de données. Elle ne peut pas servir à surveiller en détail l'activité des salariés « pour voir ce qu'ils font » : ce serait disproportionné. Conditions : informer les salariés avant la mise en service (charte, note) ; consulter le CSE s'il existe ; limiter le déchiffrement au nécessaire en exemptant les catégories sensibles (banque, santé, messageries personnelles) ; protéger les journaux (accès réservé, durée de conservation limitée) et inscrire le traitement au registre RGPD. Donc pas « dès demain » : après information et consultation.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 5 sur 5 Lire un journal de proxy Réussi À revoir

Voici un extrait des journaux du proxy, pour le poste 192.168.10.83 (utilisatrice m.durand) :

Heure	Utilisateur	Domaine	Catégorie	Action	Octets envoyés
09:02:11	m.durand	intranet.sorbier.lan	Interne	Autorisé	1 240
09:15:00	m.durand	cdn-maj-7f3a.xyz	Non classée	Autorisé	312
09:20:00	m.durand	cdn-maj-7f3a.xyz	Non classée	Autorisé	318
09:25:00	m.durand	cdn-maj-7f3a.xyz	Non classée	Autorisé	309
12:41:37	m.durand	stockage-fichiers.example	Stockage en ligne	Autorisé	2 147 483 648

1. Qu'a de suspect la série de 09:15 à 09:25 ?
2. Et la ligne de 12:41 ?
3. Quelles mesures proposes-tu ?

Voir la réponseMasquer la réponse de l'exercice 5

1. Un domaine inconnu, non classé, au nom qui imite un service de mise à jour, contacté toutes les cinq minutes exactement avec de petites requêtes de taille presque identique : c'est le comportement d'un logiciel malveillant qui interroge régulièrement son serveur de commande (beaconing). Un humain ne navigue pas à intervalles aussi réguliers.
2. 2 147 483 648 octets envoyés, soit 2 Gio (environ 2,1 Go), vers un service de stockage en ligne : une possible exfiltration de données, peut-être réalisée par l'attaquant qui contrôle le poste, ou un usage non autorisé.
3. Isoler le poste du réseau et lancer la procédure d'incident (chapitre 14) ; bloquer le domaine sur le proxy et le résolveur DNS ; rechercher d'autres postes qui contactent ce domaine ; bloquer la catégorie « non classée » et les domaines récents ; limiter les services de stockage en ligne à celui de l'entreprise ; créer une alerte de SIEM sur les envois volumineux et les connexions périodiques.

Tu avais trouvé ?

Oui, j'avais bonPas encore