Le danger des serveurs de relayage dédiés au trafic web
Date : 06 Juillet 2005
La méthode "CONNECT" du protocole HTTP permet de créer un tunnel HTTP (ou HTTPS) de bout en bout et intervient dans le fonctionnement des serveurs de relayage (relais ou "proxy") (Cf RFC 2817).
Ainsi, le client qui se connecte au proxy demande via la méthode CONNECT de se connecter au serveur web désiré.
CONNECT server.exemple.com:80 HTTP/1.1
Host: server.exemple.com:80
Cette méthode est surtout très utilisée au niveau des connexions chiffrées de type SSL (Secure Socket Layer).
Cependant, l'utilisation de cette méthode sur les proxies HTTP (comme SQUID voire même celui du garde-barrière Firewall-1) peut avoir des effets pervers.
Ainsi, un utilisateur malveillant, en se connectant au relais http, peut initier une session vers un serveur interne via la méthode "CONNECT".
Exemple :
Le proxy HTTP a pour adresse IP : 1.2.3.4
Le serveur de messagerie interne a pour adresse IP : 6.7.8.9
L'utilisateur malveillant peut se connecter au serveur proxy sur le port 80 [telnet 1.2.2.4 80] et ensuite envoyer une requête sur le méthode CONNECT [CONNECT 6.7.8.9:25 / HTTP/1.0]. Dès lors cet utilisateur contourne les éventuels filtres et a accès à la bannière du serveur de messagerie qu'il peut utiliser à des fins de SPAM.
Ce problème est connu et des considérations en terme de sécurité sont suggérées dans la RFC 2817 (8.2 Security Considerations for CONNECT).
Vous trouverez ci-dessous des recommandations concernant ce problème pour 3 relais HTTP :
- Squid,
- Module "mod_proxy" d'Apache,
- Le relais HTTP de Firewall-1.
Squid :
Squid est sensible à ce type d'attaque. Pour y faire face, la documentation de Squid préconise d'interdire l'accès aux "ports" sensibles par deux approches :
- interdire tout ce qui n'est pas autorisé
acl Safe_ports port 80 21 443 563 70 210 1025-65535
http_access deny !Safe_ports
- ou autoriser tout ce qui n'est pas interdit
acl Dangerous_ports 7 9 19 22 23 25 53 109 110 119
http_access deny Dangerous_ports
La première méthode est cependant préférable.
Documentation de Squid (#1): http://www.squid-cache.org/Doc/FAQ/FAQ-10.html#ss10.14
Documentation de Squid (#2) : http://www.squid-cache.org/Doc/FAQ/FAQ-1.html
Module "mod_proxy" d'Apache :
Le module "mod_proxy" (utilisé pour configurer un serveur Apache comme relais HTTP) du serveur Apache ne permet par défaut que des connexions sur les ports 443 (SSL) et 563 (SNEWS) via la méthode "CONNECT". Sauf dans le cas d'une configuration spécifique, il n'est donc pas sensible par défaut à ce type d'attaque.
Documentation Apache : http://httpd.apache.org/docs/mod/mod_proxy.html
Relais HTTP de Firewall-1 (http security server) :
Le relais HTTP de Firewall-1 est également sensible à ce problème. Cependant, cette technique ne peut être exploitée sur Firewall-1 que si des règles de type HTTP utilisant le relais HTTP permettent d'atteindre les machines visées.
Quelques recommandations peuvent être appliqués pour pallier à ce problème :
- désactiver le "tunnelling" http (*),
- désactiver l'utilisation de la méthode CONNECT dans le relais http (*),
- désactiver les accès depuis la machine hébergeant Firewall-1 vers le réseau local (Cf. les propriétés du module FW-1).
(*) : Cependant, ces méthodes tendent à rendre la consultation HTTPS (SSL) impossible.
Pour les autres relais HTTP et dans tous les cas, il est recommandé de filtrer le trafic illicite provenant du relais vers les autres machines du réseau, et d'empêcher les connexions sur le port 80 du relais depuis le réseau externe (Internet).
Pour plus d'information :
- Archive de SecurityFocus : http://online.securityfocus.com/bid/4131
- Liste des relais HTTP gérant la méthode "CONNECT" : http://www.monkeys.com/security/proxies/
