Vérifier les paramètres HTTP Proxy de Sophos Firewall

Les paramètres HTTP Proxy de Sophos Firewall contrôlent des propriétés globales de Web Proxy et, pour certaines, de Captive Portal. Ils couvrent les versions TLS minimales, les délais d’attente, les en-têtes Via, la protection contre les boucles proxy et la catégorisation des URL pendant la négociation TLS. Une modification peut donc toucher simultanément plusieurs règles, groupes d’utilisateurs et réseaux clients.

Le point de départ sûr est la commande de lecture show http_proxy dans la Device Console. set http_proxy ne doit modifier qu’un seul paramètre lorsqu’un problème reproductible le désigne clairement. La valeur actuelle, un test positif et négatif ciblé ainsi que la commande de retour arrière sont consignés avant la modification.

⚠️ La sortie de show http_proxy constitue un état initial, pas une liste d’optimisations. Il ne faut pas activer par précaution des versions TLS obsolètes, la désactivation de la catégorisation ou le relais de trafic non HTTP. Une valeur par défaut documentée par Sophos n’est pas automatiquement recommandée pour une nouvelle architecture de sécurité.

Configurer Direct Web Proxy avec un fichier PAC traite l’écouteur, Device Access, la règle de pare-feu et le fichier PAC. Cet article se limite aux paramètres CLI globaux sous-jacents.

Procédure courte et sûre

1. Reproduire le symptôme et noter le client, la destination, l’heure, le chemin proxy et la fonction concernée.
2. Exécuter show http_proxy dans la Device Console et conserver la sortie complète de manière protégée.
3. Documenter le paramètre visé, son effet actuel et la commande exacte de retour arrière.
4. Ne modifier que cette valeur et ouvrir une nouvelle connexion pour le test.
5. Tester Web Proxy et Captive Portal séparément si le paramètre agit sur les deux.
6. Restaurer immédiatement la valeur initiale si l’effet attendu n’apparaît pas ou si un effet secondaire survient.

Après une connexion SSH sécurisée, sélectionner 4. Device Console. Dépannage CLI de Sophos Firewall explique la vérification de la clé hôte, Device Access et la différence entre Device Console et Advanced Shell.

show http_proxy

Lire correctement les valeurs documentées

Sophos documente la sortie par défaut suivante pour SFOS 22. La valeur effectivement affichée sur le pare-feu reste la référence pour toute modification et tout retour arrière.

Le fait que TLS 1.1 soit documenté comme actif ne justifie pas son utilisation dans une nouvelle architecture. Sophos qualifie TLS 1.0 et TLS 1.1 de non sécurisés et les déconseille. L’état réel, la dépendance historique avérée et un test contrôlé du portail ou de la destination proxy concernée sont déterminants.

En-têtes Via et boucles proxy

Avec add_via_header on, le proxy ajoute un en-tête HTTP Via. Celui-ci rend les intermédiaires visibles, transmet des informations de protocole et aide à détecter les boucles. C’est la valeur documentée par défaut.

block_proxy_loop on abandonne les requêtes lorsque des valeurs Via dupliquées indiquent une boucle. Sophos documente cette protection sur off par défaut. Une boucle peut apparaître lorsqu’un proxy en amont renvoie la requête au même Sophos Firewall à cause du DNS, du fichier PAC ou du routage.

Avant toute modification, contrôler le fichier PAC, Upstream Proxy, la résolution DNS et le chemin de retour réel. Un commutateur ne remplace pas la correction de ce chemin.

set http_proxy block_proxy_loop on

Pour une trace limitée dans le temps, Sophos exige aussi le mode debug du service awarrenhttp. awarrenhttp.log peut alors afficher Duplicate Via header values, proxy loop. Le debug est désactivé par défaut et peut affecter les performances, le stockage et la confidentialité. Il ne reste actif que pendant un test reproductible. Services et fichiers journaux Sophos Firewall décrit l’analyse sûre.

TLS pour Web Proxy et Captive Portal

Traiter séparément les versions minimales

La Device Console peut contrôler TLS 1.0 et TLS 1.1 séparément pour Web Proxy et Captive Portal. Un test historique ciblé ne relâche donc pas automatiquement les deux fonctions. WebAdmin n’affiche ensuite que la version minimale du proxy et Sophos avertit lorsque les valeurs diffèrent.

Les quatre commutateurs sont :

set http_proxy captive_portal_tlsv1_0 off
set http_proxy captive_portal_tlsv1_1 off
set http_proxy proxy_tlsv1_0 off
set http_proxy proxy_tlsv1_1 off

Ces commandes montrent la cible sûre pour un environnement sans dépendance historique, pas une consigne générale de migration. Inventorier les connexions au portail, les clients Direct Proxy, les destinations HTTPS déchiffrées et les anciennes applications administrées avant la désactivation. Tester chaque fonction avec une nouvelle négociation client. Pour un changement plus large, suivre le déploiement progressif de TLS Inspection.

Si un ancien client ne prend réellement en charge que TLS 1.0 ou TLS 1.1, la version n’est pas réactivée globalement sans autre analyse. Vérifier d’abord une mise à jour, un remplacement ou un chemin séparé et restreint. Une exception temporaire inévitable nécessite un responsable, une date d’expiration, un risque documenté et un test prouvant laquelle des deux fonctions en dépend.

X-Frame-Options protège le portail

captive_portal_x_frame_options on protège Captive Portal contre son intégration dans un cadre tiers et donc contre le clickjacking. Cette valeur documentée reste active. La désactivation ne se justifie que pour une intégration contrôlée et démontrée, après évaluation distincte du risque.

Configurer et tester Captive Portal décrit l’ensemble avec Device Access, règle utilisateur, certificat et déconnexion.

La chaîne de chiffrement vaut pour les deux fonctions

tlsciphers_server définit ensemble les suites proposées par Web Proxy et Captive Portal. Une correction supposée du proxy peut donc modifier le portail, et inversement. Sophos documente cette valeur :

HIGH:!RC4:!MD5:!aNULL

Il ne faut pas copier une chaîne issue d’un blog ou d’une autre plateforme. Les suites prises en charge dépendent de la version SFOS, de TLS, du client et du serveur. Avant une modification, définir la sortie actuelle, la correspondance attendue et les tests des deux fonctions. En cas d’échec, séparer d’abord version TLS, chaîne de certificats, politique de déchiffrement et confiance du client.

Quatre délais aux effets différents

Selon Sophos, les quatre valeurs acceptent de 1 à 2147483647 secondes ou default. Une valeur extrême techniquement admise n’est pas forcément exploitable.

client_timeout concerne les clients proxy établis. connect_timeout limite la tentative de connexion. response_timeout fixe l’attente d’une réponse sur une nouvelle connexion. tunnel_timeout concerne l’établissement d’un tunnel HTTPS et vaut 300 secondes par défaut, contre 60 pour les trois autres.

set http_proxy client_timeout 60
set http_proxy connect_timeout 60
set http_proxy response_timeout 60
set http_proxy tunnel_timeout 300

Ces valeurs sont des valeurs documentées, pas une réparation automatique. Identifier d’abord la phase de l’interruption et vérifier si le client, le serveur cible, le proxy en amont, le chemin WAN ou l’application impose un délai plus court. Une augmentation n’aide que si Sophos Proxy ferme réellement la connexion. Surveiller aussi les connexions ouvertes et les ressources.

Pour le retour arrière, restaurer explicitement la valeur lue auparavant avec show http_proxy. Utiliser default uniquement pour revenir volontairement à la valeur documentée, jamais parce que l’ancienne valeur est inconnue.

Ne pas désactiver aveuglément la catégorisation TLS

disable_tls_url_categories on désactive la recherche de catégorie pour les règles SSL/TLS Inspection. Pendant la négociation TLS, le trafic devient non catégorisé. Seules les règles SSL/TLS Inspection avec Categories and websites: Any peuvent alors correspondre. La Web Policy peut aussi prendre une autre décision à ce stade.

Le paramètre ne change ni la catégorisation HTTP normale ni celle du contenu HTTPS déchiffré par la suite. Une page peut donc se charger tandis que le choix de règle et la protection ont déjà changé.

Avant son utilisation, examiner les règles SSL/TLS Inspection concernées, leurs catégories, les correspondances de sites et le traitement voulu du trafic non catégorisé. Puis vérifier qu’une destination autorisée, bloquée et non catégorisable utilise les règles attendues. Web Protection sur Sophos Firewall explique l’interaction entre catégories et actions.

Ne pas forcer le trafic non HTTP dans le proxy

relay_invalid_http_traffic on relaie le trafic non HTTP envoyé sur les ports habituels HTTP et HTTPS, 80 et 443. Cela peut sembler réparer un protocole historique, mais élargit le chemin proxy et complique l’évaluation de sécurité.

Sophos conseille plutôt un bypass proxy propre à l’application. Le limiter autant que possible par source, destination et service, puis le protéger par une règle de pare-feu et, le cas échéant, une règle SSL/TLS Inspection. Le commutateur global reste normalement off.

Core dump et debug uniquement pour le diagnostic

core_dump on crée un core dump si le processus proxy se bloque. Il peut aider Sophos Support sur une panne reproductible, mais ne constitue ni un Health Check ni une option de performance. Le fichier peut contenir des données sensibles et occuper du stockage.

N’utiliser la fonction que dans une fenêtre de support ou de diagnostic précise. Vérifier auparavant l’espace libre, la procédure de reproduction et le transfert sécurisé. Restaurer ensuite la valeur précédente et traiter les fichiers selon les instructions du support.

Valider et annuler une modification

Utiliser la même source, la même destination et une nouvelle connexion avant et après. Pour une modification globale de TLS ou des suites, tester au moins une requête Direct Proxy et une connexion Captive Portal. Pour un délai, valider la phase concernée ; pour une boucle, le message exact ; pour la catégorisation, la règle SSL/TLS Inspection réellement choisie.

Consigner l’heure, le client, la Web Policy et la Rule ID dans Log Viewer. Si le choix de règle reste incertain, Tester proprement une règle Sophos Firewall combine Policy Test, Log Viewer et Packet Capture.

Le retour arrière utilise la valeur enregistrée :

set http_proxy <parameter> <previous-value>
show http_proxy

Créer ensuite un nouveau flux de test. Le retour de l’ancienne valeur dans show http_proxy confirme seulement la configuration ; le test réel du proxy ou du portail confirme le fonctionnement.

Liste de contrôle d’exploitation

• Sortie complète de show http_proxy, build SFOS, heure et responsable consignés.
• Fonction concernée et un seul paramètre isolés.
• Effets sur Web Proxy, Captive Portal, TLS Inspection et Web Policy évalués.
• Ancienne valeur préparée sous forme de commande de retour arrière.
• Tests positif, négatif et témoin définis.
• Debug et core dump limités dans le temps.
• Nouvelle connexion testée après modification et après retour arrière.
• Exception historique temporaire associée à un responsable et une expiration.

FAQ