HSC
Cabinet de consultants en sécurité informatique depuis 1989 - Spécialisé sur Unix, Windows, TCP/IP et Internet
Mode texte : accès au contenu de la page
Hervé Schauer Consultants
Vous êtes ici : Accueil > Ressources > Brèves > Mise en oeuvre de filtrage avec mod_eaccess sur un relais HTTP inverse.
Accéder au : Site HSC des formations
Télécharger le catalogue des formations
Recherche :  
English version
   Services   
o Domaines de compétences
o Conseil & Expertise
o Prestations ISO 27001
o Audit & Évaluation
o Tests d'intrusion
o Tests de vulnérabilités (TSAR)
o Analyse Forensique
o Certification ARJEL
o Formations
o E-learning
   Conférences   
o Agenda
o Interventions passées
o Tutoriels
   Ressources   
o Index thématique
o Brèves
o Présentations
o Cours
o Articles
o Outils (téléchargement)
o Veille en vulnérabilité
   Société   
o Hervé Schauer
o Equipe
o Offres d'emploi
o Références
o Historique
o Partenariats
o Associations
   Presse et
 communication
 
 
o Newsletter HSC
o Bulletin juridique HSC
o Revue de presse
o Communiqués de presse
o Publications
   Contacts   
o Coordonnées
o Requêtes particulières
o Accès à nos locaux
o Hôtels proches de nos locaux
|>|Mise en oeuvre de filtrage avec mod_eaccess sur un relais HTTP inverse.  

par Christophe PREMEL (03/09/2001)




--[ But de ce document ]---------------------------------------------------

Le but de ce document est de vous montrer pourquoi effectuer du filtrage
d'url est important, et comment le mettre en place.


--[ Introduction ]---------------------------------------------------------

Tout d'abord, le filtrage d'url se fait de préférence sur un relais inverse
HTTP, par exemple Apache monté en relais inverse.
Il a pour but de protéger le véritable serveur web, disposant de scripts
ou autre outils d'interaction avec l'Internaute ou simplement de génération
de pages dynamiques.

Si un tel relais est mis en amont, lui seul sera visible pour l'Internaute.
Apache positionné sur une machine Unix, le tout étant considéré comme sûr,
évitera de voir des plates-formes directement visibles sur Internet n'étant
pas sûres.

Il est bien évident, que cet ensemble doit être sécurisé. A contrario, des
plates-formes propriétaires peuvent être sécurisées, mais dans une moindre
mesure. En effet, il y a plusieurs raisons à cela :
. le fait de ne pas avoir accès aux sources, rend le fonctionnement
  mystérieux
. Unix à une certaine ancienneté, et prêtant maintenant à la sagesse
. le fonctionnement des Unix, est connus des informaticiens, et donc de la
  personne mettant en place la plate-forme, contrairement aux logiciels
  propriétaires, se targuant de certifications ou les bonnes réponses font
  partie d'élans marketoïdes prononcés

Enfin, je pourrais débattre sur le logiciel libre, mais là n'est pas le
sujet.

--[ Principe ]-------------------------------------------------------------

Voici une architecture type de commerce électronique :

                        -------------- 
                      /    Internet    \
                     |                  |
                      \       @        /
                        --------------
                               |
                        +------------+
                        |   Routeur  |
        +------------+  |   d'accès  |    +----------+ +----------+
        | Serveur de |  +------------+    |  relais  | |  Serveur |
        | messagerie |         |          | inverse  | |    DNS   |
        +------------+  +------------+    +----------+ +----------+
         ______|________|   garde-   |__________|____________|_____
                        | barrière 1 |
                        +------------+
         +----------+          |          +----------+
         |  Serveur |          |          |  Serveur |
         |    SGBD  |          |          |   web    |
         +----------+   +------------+    +----------+
         ______|________|   garde-   |__________|_____________
                        | barrière 2 |
                        +------------+
                               |
       +----------+      ------------      +----------+
       |messagerie|    /    réseau    \    |    DNS   |
       |  interne |---|     interne    |---|  interne |
       +----------+    \ d'entreprise /    +----------+
                         ------------

Cette architecture est basique, mais a l'avantage de montrer le cheminement
d'une requête HTTP, lorsque l'accès au service web est cloisonné.

Le cloisonnement de réseau est _très_ important. Il permet, entre autre,
de séparer les services entre eux. Si un service est compromis, le 'pirate'
sera isolé sur son sous-réseau par les éléments de filtrage.

Pour la nécessité d'utiliser un relais inverse, sans filtrage, et
simplement pour protéger la pile IP du serveur web public. Ce qui est déjà
beaucoup pour certains types de plates-formes...

Maintenant, si vous me mettez pas de filtrage d'URL dessus, c'est un peu
gâché.
Pour le filtrage d'URL, il y a le mode rewrite d'Apache, décrit dans une
autre brève.

Le filtrage que j'utilise pour ma part, est celui apporté par le module
mod_eaccess.

C'est un excellent filtrage, mais il est assez fastidieux quant à la mise en
place des règles, surtout si le web est complexe, et très interactif.
En effet, il faudra renseigner toutes les url consultables sur votre serveur
web, afin d'éliminer celles incorrectes, que le serveur web final, ou les
scripts (application de commerce électronique par exemple) pourront mal
interpréter.


--[ Récupération du module eaccess ]---------------------------------------

Le module eaccess n'est plus maintenu depuis peu par Patrick ASTY. Ce
dernier créant une société afin de le commercialiser
(
http://www.denyall.com/index.php?option=displaypage&Itemid=149&op=page ).
La société HSC prend donc le relais, afin de maintenir ce dernier, et faire
vivre un produit de grande qualité. Il est bien évident que l'aspect libre
est gardé.

En attendant, ce module ainsi que sa documentation peuvent être trouvés à
l'URL http://www.flopgun.net/pub/mod_eaccess-2.3.3.9.tar.gz


--[ Installation de mod_eaccess ]------------------------------------------

Désarchivage d'Apache :
premel@mopette:~$ cd /usr/local/src
premel@mopette:/usr/local/src$ tar xvfz /home/ftp/pub/www/apache_1.3.19.tar.gz

Désarchivage de PHP si l'on en a besoin :
premel@mopette:/usr/local/src$ tar xvfz /home/ftp/pub/www/php-4.0.5.tar.gz

Désarchivage du module eaccess :
premel@mopette:/usr/local/src$ tar xvfz /home/ftp/pub/www/mod_eaccess-2.3.3.9.tar.gz

Désarchivage du module SSL (attention, ce module est exclusivement pour la
version 1.3.9 d'Apache) :
premel@mopette:/usr/local/src$ tar xvfz /home/ftp/pub/www/mod_ssl-2.8.3-1.3.19.tar.gz

Configuration du module SSL :
premel@mopette:/usr/local/src$ cd mod_ssl-2.8.3-1.3.19/
premel@mopette:/usr/local/src/mod_ssl-2.8.3-1.3.19$ ./configure \
 --with-apache=../apache_1.3.19/ \
 --prefix=/home/www/apache_1.3.19 \
 --prefix=/home/www

Configuration de Apache :
premel@mopette:/usr/local/src/mod_ssl-2.8.3-1.3.19$ cd ../apache_1.3.19/
premel@mopette:/usr/local/src/apache_1.3.19$ SSL_BASE=/usr/local/ssl ./configure \
 --prefix=/home/www

Configuration de PHP :
premel@mopette:/usr/local/src/apache_1.3.19$ cd ../php-4.0.5/
premel@mopette:/usr/local/src/php-4.0.5$ ./configure \
 --without-mysql \
 --with-pgsql \
 --with-apache=../apache_1.3.19 \
 --enable-track-vars
premel@mopette:/usr/local/src/php-4.0.5$ make
premel@mopette:/usr/local/src/php-4.0.5$ su -
root@mopette:/usr/local/src/php-4.0.5# make install
root@mopette:/usr/local/src/php-4.0.5# exit
premel@mopette:/usr/local/src/php-4.0.5$ cd ../apache_1.3.19/src/modules/php4/

Mon umask étant très restrictif, les fichiers appartiennent à root après le
make install, donc, si premel doit compiler apache avec ces modules, il doit
avoir les droits.
root@mopette:/usr/local/src/apache_1.3.19/src/modules/php4# chown -R premel:users *

Configuration du module SSL pour Apache :
premel@mopette:/usr/local/src/php-4.0.5$ cd ../mod_ssl-2.8.3-1.3.19 
premel@mopette:/usr/local/src/mod_ssl-2.8.3-1.3.19$ ./configure \
 --with-apache=../apache_1.3.19 \
 --prefix=/home/www

Re-configuration de Apache avec prise en compte de tous les modules :
premel@mopette:/usr/local/src/mod_ssl-2.8.3-1.3.19$ cd ../apache_1.3.19/
premel@mopette:/usr/local/src/apache_1.3.19$ SSL_BASE=/usr/local/ssl \
 ./configure --enable-module=ssl \
 --add-module=../mod_eaccess-2.3.3.9/mod_eaccess.c


--[ Configuration de mod_eaccess ]-----------------------------------------

Le module eaccess est développé par le français Patrick ASTY :
http://persoweb.francenet.fr/~pasty/eaccess/ maintenant plus accessible,
voyez plutôt sur :
http://www.flopgun.net/christophe/docs/security/eaccess-orig.php

Il s'agit d'un module chargeable dans Apache (http://httpd.apache.org/ ). Il
est positionné en relais inverse (reverse proxy) et permet de relayer les
requêtes HTTP vers le véritable serveur Web. Le seul serveur Web visible de
l'extérieur est donc le serveur Apache en relais inverse. Il agit en mode
transparent.

Le module eaccess est très intéressant pour filtrer les URL. Il peut s'agir
d'insérer les URL contenant des CGI avec ou sans leurs paramètres. Il est
ainsi possible de spécifier que tel script CGI est inaccessible depuis
l'extérieur et autorisé depuis le réseau interne.

Il est également possible d'indiquer que pour tel CGI, les paramètres (s'il
y en a), doivent être formulés de telle ou telle manière. Si le script
comporte entre 3 et 5 caractères de paramètre, une personne malintentionnée
pourra tenter d'envoyer en tant que paramètre, un buffer de 2000
caractères : cette requête sera bloquée par le serveur relais et ainsi
n'arrivera pas jusqu'au serveur Web réel.

Ainsi, si un script est mal écrit ou comporte éventuellement des failles, il
sera protégé.

La configuration de ce module est très simple et un exemple est donné
ci-après. Elle se situe dans le fichier httpd.conf d'Apache.

Il faut préalablement activer le module, en interdisant tout :
EAccessEnable on

Mettre ensuite de la journalisation :
EAccessLogLevel 1
Le paramètre 0 correspond à aucune journalisation.
Le paramètre 1 correspond à une journalisation normale.
Les paramètres supérieurs à 1 correspondent au mode debug.

Il est tout à fait possible de journaliser certaines choses (deny,
permit...) ou d'exécuter une action sur réception de tel type d'alerte.
EAccessLog | mail -s "Eaccess log" security@flopgun.net

Enfin, il faut mettre la directive EAccessRule permettant de laisser passer
certaines URL autorisées. Cette directive s'appuie sur la mise en place
d'expressions régulières : des exemples sont donnés ci-après.

Il ne faut pas oublier d'interdire tous les paramètres ou caractères
hexadécimaux. Par exemple :
Il faut savoir que les caractères hexadécimaux ci-dessous ont une double
signification :

         %00 ('\0') => "\0"
         %07 ('\a') => "\a"
         %08 ('\b') => "\b"
         %0A ('\n') => "\n"
         %0B ('\v') => "\v"
         %0C ('\f') => "\f"
         %0D ('\r') => "\r"
         %26 ('&') => "."
         %7C ('|') => "."

En supposant la dangereuse requête suivante :
EAccessRule permit "^GET /good.cgi%3Fparam=/%2E./bad.cgi"

Et sachant que les caractères suivants signifient :
%3F => ?
%2E => .

Alors, la requête sera interprétée comme :
EAccessRule permit "^GET /good.cgi?param=/../bad.cgi"

Donc, seront autorisées les requêtes sur le script good.cgi, ayant comme
paramètre un fichier bad.cgi positionné au-dessus du répertoire racine des
CGI.
Il faut donc interdire ce genre d'URL.

Pour ce faire, il faut absolument interdire toute chaîne de caractères
commençant par un % et ayant des chiffres et des lettres (majuscules et
minuscules de A à F) pour deux caractères, comme : %00, %ff, %FF, %fC, %7C,
etc.
EAccessRule deny "%[a-fA-F0-9]{2}"

La règle suivante permet d'accepter le CGI toto appelé par la méthode GET,
sans aucun arguments. Cette règle est vraiment restrictive.
EAccessRule permit "^GET /cgi-bin/toto$"

La règle suivante permet d'accepter le CGI tata appelé avec la méthode GET
et pouvant disposer de deux arguments. Chacun des arguments peut comprendre
de 0 à 32 caractères.
EAccessRule permit "^GET /cgi-bin/tata\?field1=.{0,32}&field2=.{0,32}$"

Nota : si vous souhaitez autoriser un script CGI appelé exclusivement par
la méthode GET et devant disposer de deux paramètres :

   * Le premier paramètre devra comporter seulement des chiffres (maximum 3)
     compris entre 0 et 4 (soit 1, 2 et 3).
   * Le second paramètre devra être des lettres en majuscules et au nombre
     de deux ou trois.
     EAccessRule permit "^GET \
     /cgi-bin/toto\?field1=.[1-3]{1,3}&field2=.[A-Z]{2,3}$"

--[ Exemple de configuration Apache ]--------------------------------------

##
## httpd.conf -- Apache HTTP server configuration file
##

# On interdit tout
EAccessEnable on

# On journalise les accept et les deny dans logs/eaccess_log
EAccessLogLevel 1

# On interdit tous les cgi
EAccessRule deny "^GET /cgi-bin/.*$"
EAccessRule deny "^GET /.*\.cgi.*$"

# On accepte toutes les requêtes GET
EAccessRule permit "^GET /.*$"

# On accepte les logins en lettres minuscules compris entre 5 et 9 caractères
# et le champ mot de passe acceptant tout sauf les caractères %, |, &, /
# et \ compris entre 5 et 15 caractères
EAccessRule permit "^GET /cgi-bin/login\?user=[a-z]{1,9}&password=[^|%&/\]{5,15}$"


--[ Aide ]-----------------------------------------------------------------

Je n'ai pas trouvé de documentation sur le Net parlant du module eaccess. Si
ce n'est la documentation d'origine faite par Patrick ASTY, disponible à :
http://www.flopgun.net/christophe/docs/security/eaccess-orig.php


--[ EOF ]------------------------------------------------------------------




Dernière modification le 19 juillet 2005 à 12:29:18 CET - webmaster@hsc.fr
Mentions légales - Informations sur ce serveur - © 1989-2013 Hervé Schauer Consultants