Vérifier que votre proxy n’est pas ouvert à tous
Vérifiez écoute, ordre des règles, identifiants et transfert réel depuis des sources autorisées et refusées avant d’exposer un proxy direct.
Testez la frontière d’accès avant de rendre un nouveau proxy direct accessible depuis d’autres réseaux. Une requête réussie depuis le serveur lui-même dit très peu sur ce qu’un client extérieur peut faire. Utilisez une destination contrôlée pour savoir si une requête refusée a réellement été transférée.
Vérifier l’écoute et la politique effectives
Inspectez le processus et les adresses d’écoute, y compris IPv6 si activé. Supprimez les points d’écoute supplémentaires involontaires et anciennes instances du service. Limitez le pare-feu réseau aux sources devant atteindre le service.
Inspectez ensuite la configuration réellement chargée, fichiers inclus compris. Avec Squid 6, une autorisation antérieure peut annuler une restriction ultérieure. Avec Tinyproxy 1.11.2, supprimer toutes les lignes Allow et Deny autorise tous les clients. Dante possède des règles client et SOCKS distinctes ; accepter la connexion TCP n’est donc pas toute la politique.
Consultez la documentation de la version installée. Les changements de directives de Squid 8 justifient de vérifier la version, pas de supposer qu’une configuration familière a été acceptée avec le même sens.
Tester les cas autorisés et refusés
Pour un proxy devant exiger à la fois une source approuvée et une connexion authentifiée, exécutez cette matrice avec vos propres systèmes contrôlés :
| Source | Identifiants | Résultat exigé |
|---|---|---|
| Autorisée | Valides | La destination prévue reçoit la requête. |
| Autorisée | Absents ou erronés | La destination n’est pas atteinte. |
| Non autorisée | Valides ou absents | La destination n’est pas atteinte. |
Deux appareils derrière un même NAT peuvent apparaître comme une seule source. Choisissez des lieux de test ayant des adresses source différentes au proxy, et confirmez-les dans ses journaux. N’utilisez pas de machines tierces sans rapport et ne scannez pas les services d’autrui.
Un refus du pare-feu peut ne produire aucune réponse HTTP ; un refus de l’application peut renvoyer une erreur. Dans les deux cas, vérifiez que la cible contrôlée n’a pas reçu la requête interdite : une simple page d’erreur pourrait sinon être prise pour une réponse de destination.
Exercer les modes de transfert à autoriser
Pour un proxy web, testez séparément une requête HTTP ordinaire et le chemin HTTPS CONNECT autorisé. Si la politique restreint les destinations, testez une destination permise et une cible contrôlée devant être refusée. Ne retirez pas les contrôles pour faire réussir tous les tests.
Retestez après modification des plages source, identifiants, adresses d’écoute, fichiers inclus ou versions du service. Conservez ensemble heure du test, version de configuration et résultats pour comparer une modification ultérieure à la même frontière.
Il s’agit d’une procédure de réception, pas d’affirmer qu’un analyseur de configuration ou une seule requête prouve la fermeture de tous les chemins réseau.