Règles d’accès Squid 6 pour une IP cliente

Limitez un proxy direct Squid 6.13 à un client connu, conservez les protections de destination et vérifiez l’ordre des règles avant déploiement.

Cette configuration cible Squid 6.13, y compris le paquet de Debian 13. Vérifiez la version installée avec squid -v : la référence des directives de Squid indique que http_access n’est pas disponible en version 8.

Choisir d’abord les adresses

Le service d’écoute a besoin d’une adresse affectée au serveur. La règle cliente nécessite l’adresse source observée par Squid, qui peut être la sortie publique d’un réseau NAT plutôt que l’adresse privée d’un portable.

Remplacez les adresses de documentation ci-dessous. La restriction cliente porte sur une seule adresse, exprimée en /32.

http_port 192.0.2.10:3128
acl proxy_client src 198.51.100.27/32
acl Safe_ports port 80 443
acl SSL_ports port 443
acl CONNECT method CONNECT

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny manager
http_access deny to_localhost
http_access deny to_linklocal
http_access allow proxy_client
http_access deny all

Remplacez le service d’écoute, les définitions ACL et les règles d’accès correspondants dans la configuration du paquet, tout en gardant ses réglages de journalisation et de système de fichiers. Ajouter ces règles sous une autorisation cliente antérieure peut contourner la restriction. Des définitions répétées d’une ACL de liste peuvent aussi ajouter des valeurs.

Comment les requêtes traversent les règles

Les refus initiaux rejettent les ports de destination indésirables, les requêtes d’administration et les destinations locales ou lien-local. Le client connu est autorisé après ces vérifications ; toutes les autres requêtes atteignent le refus final. Les protections de destination restent nécessaires, car une liste d’autorisation des sources ne limite pas à elle seule les destinations.

Limitez le pare-feu de l’hôte ou du réseau à la source prévue avant d’exposer le service. La liaison choisit où Squid accepte les connexions ; les règles d’accès déterminent les requêtes qu’il permet.

sudo squid -k parse -f /etc/squid/squid.conf

Corrigez les erreurs d’analyse avant de recharger le service géré. Testez depuis le client autorisé et une seconde source contrôlée qui devrait être refusée. Vérifiez que la cible ne reçoit que la requête autorisée : une connexion TCP seule ne prouve pas l’autorisation de transfert.

Articles similaires