Cet article explique la mise en place d'un relais inverse, à base d'un serveur Apache (1.3), pour protéger un serveur Web.

Peut-être vous demandez-vous à quoi sert un relais inverse ?

 Organisation du réseau

Le réseau cible est le suivant :

L'adresse IP officielle du relais inverse est 1.2.3.4. Deux ports sont ouverts, 80 (port par défaut pour HTTP) et 443 (HTTPS). Le relais inverse dispose de deux carte réseau, et est aussi connecté à un réseau privé (RFC 1918), avec l'adresse IP 192.168.100.1. Le serveur réel est connecté sur ce même réseau privé, avec l'adresse IP 192.168.100.100. Il dispose d'un seul port actif, 8080, pour HTTP (les échanges entre le relais et le serveur réel se feront en clair).

Constitution d'un relais inverse

La composition du relais inverse est la suivante :

• Une plate-forme Unix bien configurée.
• Un serveur Apache.
• Les modules strictement nécessaires au relayage :
  • http_core
  • mod_log_config
  • mod_proxy

• mod_access
• mod_mime
• mod_eaccess (hors livraison standard)
• mod_ssl (hors livraison standard)
  

mod_access n'est pas nécessaire, sauf si l'on veut restreindre certaines fonctionnalités du relais (et/ou du serveur réel) à certains utilisateurs. D'autres modules d'identification/authentification peuvent alors être nécessaires, selon les modes choisis. De même, mod_ssl n'est nécessaire que si l'on veut utiliser le protocole HTTPS. Enfin, mod_eaccess permet de mettre en place un filtrage des URLs demandées ainsi que des arguments transmis au serveur réel.

Relais simple

La configuration du serveur Apache est simple. Nous désactivons tous les modules (--disable-module=all) et n'activons de manière sélective que ceux qui nous intéressent :

$ ./configure --with-layout=Apache   \
                --prefix=/home/apache  \    # Installation
                --disable-module=all   \
                --enable-module=access \    # Optionnel
                --enable-module=proxy  \
                --enable-module=log_config
$ make

On peut vérifier la liste des modules compilés dans le serveur à l'aide de httpd -l :

$ src/httpd -l
  Compiled-in modules:
    http_core.c
    mod_log_config.c
    mod_access.c
    mod_proxy.c
$

Il suffit ensuite d'installer le serveur dans le répertoire de destination, par un make install. Le fichier de configuration (/home/apache/conf/httpd.conf) doit ensuite être modifié afin d'en retirer tout ce qui ne nous intéresse pas, c'est-à-dire presque tout. Voici un fichier minimal qui permet d'activer la fonction de relayage

##
## httpd.conf -- Apache HTTP server configuration file
##
## Fonctionnement de relais simple, sans aucune vérification d'URL
## Pas de SSL dans cette configuration.
##
  
ServerType standalone
ServerRoot "/home/apache"
PidFile /home/apache/logs/httpd.pid
ScoreBoardFile /home/apache/logs/httpd.scoreboard
  
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
  
MinSpareServers 5
MaxSpareServers 10
StartServers 5
MaxClients 150
MaxRequestsPerChild 0
  
#
# Configuration principale.
#
Port 80
  
User apache
Group nobody
ServerAdmin 
 Cet e-mail est protégé contre les robots collecteurs de mails, votre navigateur doit accepter le Javascript pour le voir
 
# ServerName www.ba-cst.com
  
<Directory />
  Options FollowSymLinks
  AllowOverride None
  Order allow,deny
  Deny from all
</Directory>
  
HostnameLookups Off
  
ErrorLog /home/apache/logs/error_log
LogLevel warn
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
CustomLog /home/apache/logs/access_log common
  
ServerSignature Off
  
<IfModule mod_proxy.c>
  ProxyRequests Off
  
  # Tout le reste est transmis au serveur réel.
  #
  ProxyPass        / http://192.168.100.100:8080/
  ProxyPassReverse / http://192.168.100.100:8080/
 
  # On ne cache rien en local.
  #
  NoCache *
 
  <Directory proxy:192.168.100.100>
    Order deny,allow
    Allow from all
  </Directory>
  
  ProxyVia Block
</IfModule>

Avec une telle configuration, le relais transmettra toutes les requêtes reçues au serveur réel. L'intérêt peut sembler faible, mais même ici il est déjà présent. Par exemple :

	Le serveur réel utilise des outils particuliers pour lesquels des montées de version ne sont pas toujours possibles rapidement. Le relais inverse, n'ayant aucune fonctionnalité applicative, peut suivre les versions pratiquement au jour le jour.
	Le serveur réel est considéré comme fragile, mais ne peut être remplacé car cela nécessiterait de réécrire l'application. Le relais inverse sert alors de bouclier pour une partie des risques (mais pas tous, il faut un relais inverse filtrant).
	Le relais inverse peut être configuré afin d'aiguiller vers différents serveurs réels, selon les requêtes. Il ne s'agit pas à proprement parler d'équilibrage de charge, mais de répartition des tâches (serveur d'images, de pages statiques, de pages dynamiques, etc.).

Relais filtrant

La configuration en relais simple permet uniquement d'interposer un système devant le serveur réel. Toutefois, si cela ferme certaines vulnérabilités au niveau des outils support, cela n'amène aucune sécurité supplémentaire au niveau applicatif. Ainsi, le relais inverse transmettra les requêtes/attaques reçues au travers du protocole HTTP ou HTTPS. Si l'application cible est vulnérable, le relais inverse n'apporte rien de plus.
Cependant, on peut étendre la fonction du relais inverse vers celle d'un relais filtrant, à l'aide d'un module comme mod_eaccess. Cela revient à mettre un place une forme de filtrage de contenu : seules les URLs considérées comme valides (applicativement parlant) seront transmises par le relais inverse. toutes les autres URLs seront bloquées. On évite ainsi une très grande partie des sondages de vulnérabilités.

Le relais filtrant peut en outre valider le contenu de certaines URLs, en examinant les paramètres transmis dans la requête. Il devient donc possible de dire

L'URL /titi/toto/tutu doit être impérativement appelée avec trois
paramètres, nommés :
   - a, qui est une chaîne de caractères en minuscules,
   - b, qui est un entier
   - c, qui doit exister mais dont le contenu est quelconque.  

Le relais inverse autorisera donc un

GET /titi/toto/tutu?a=ab&b=12&c=Il%20fait%20beau

mais bloquera

GET /titi/toto/tutu?a=ab
GET /titi/toto/tutu.