HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Tips > filtrer des URLs dans un relais inverse
Go to: HSC Trainings
Télécharger le catalogue des formations
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Bulletin juridique HSC
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|filtrer des URLs dans un relais inverse  

by Denis Ducamp (05/05/2001)



Cet article montre comment configurer du filtrage d'URL de base dans apache
installé en relais inverse.

Pour configurer apache comme un simple relais inverse, les lignes suivantes
peuvent être utilisées :

httpd.conf
------------
<IfModule mod_proxy.c>
    ProxyRequests Off
    ProxyPass / http://192.168.66.66:80/
    ProxyPassReverse / http://192.168.66.66:80/
<Directory proxy:*>
#Order deny,allow
#Deny from all
#Allow from .mon_domain_a.moi
</Directory>
...
</IfModule>
------------



Ici toutes les requêtes vers le relais sont passées de façon transparente
vers le serveur interne. L'intérêt ici est de donner accès à une machine non
accessible et/ou de construire des serveurs virtuels en donnant accès à des
arborescences différentes de différents serveurs. Pour les détails de cette
configuration et d'autres informations complémentaires, voyez la brève
intitulée "apache en relais inverse".

Mis à part n'accepter sur le relais que des connexions chiffrées en ssl avec
authentification des utilisateurs, éventuellement avec des certificats
clients, d'un point de vue sécurité il n'y a aucun intérêt à cette solution.
Pour faire de la sécurité, il est nécessaire de filtrer les URL demandées
par le client. Pour cela, le module mod_rewrite est la solution classique.



Les paragraphes suivants montrent comment ajouter du filtrage d'URL de base
avec le module mod_rewrite.

Pour avoir le support de mod_rewrite dans apache, il est nécessaire de le
demander lors de la compilation avec l'option --enable-module-rewrite du
script ./configure

Il est alors nécessaire d'activer le module mod_rewrite et de le configurer
avec des commandes RewriteRule. Par défaut il faut désactiver les commandes
ProxyPass et ProxyPassReverse qui s'exécuteraient avant les commandes
RewriteRule en court-circuitant le filtrage. La configuration précédente
devient alors :

httpd.conf
------------
<IfModule mod_proxy.c>
    ProxyRequests Off
#    ProxyPass / http://192.168.66.66:80/
#    ProxyPassReverse / http://192.168.66.66:80/
<Directory proxy:*>
#Order deny,allow
#Deny from all
#Allow from .mon_domaine_a.moi
</Directory>
...
</IfModule>
------------



Le principe est basé sur des expressions rationnelles (regular expressions)
afin de filtrer l'URL reçue, chaque commande RewriteRule en possédant deux.
Lorsqu'une URL correspond à la première expression alors elle est modifiée
en une autre URL grâce à la seconde expression et une décision est prise sur
le devenir de l'URL ainsi obtenue.

Afin de restreindre les accès à un serveur sensible, deux types de décisions
sont nécessaires : P (proxy = relayé) et F (forbidden = interdit).

Les commandes RewriteRule peuvent être classées en trois catégories
successives :
 . interdire tout ce qui est connu comme étant potentiellement dangereux.
 . accepter les arborescences et fichiers autorisés.
 . refuser tout le reste par défaut.

Dans la première partie les règles permettent de détecter des scans et des
attaques caractérisées, comme par exemple msadcs.dll contre les serveurs IIS
ou etc/passwd contre les serveurs Unix.

Dans la deuxième partie, il est possible de simplifier le filtrage en
acceptant toutes les arborescences qui ne comportent que des fichiers
statiques. Par contre dans les répertoires avec des CGI il est nécessaire de
spécifier exhaustivement tous les scripts autorisés depuis Internet; cette
contrainte permet aux développeurs de devoir identifier exhaustivement les
scripts appelés depuis Internet et de pouvoir ensuite se focaliser sur
ceux-ci lors d'un audit de sources.



Prenons par exemple le cas de la protection d'un serveur IIS, soyons fous et
inspirons nous carrément de quelques URL trouvées sur celui de MicroSoft ;-)
En imaginant que sur ce site il n'y ait que quelques scripts asp, un script
dll et quelques images gif, l'application des règles ci-dessus pourrait
donner quelque chose comme ce qui suit :

httpd.conf
------------
# Activation du module de réécriture et de sa journalisation
RewriteEngine On
RewriteLog logs/rewrite.log
RewriteLogLevel 9

# Interdiction de tout ce qui est louche... m'enfin, quelques trucs courants
# il n'y a pas de script htr ou idc
RewriteRule \.htr($|.*) / [F]
RewriteRule \.idc($|.*) / [F]
# il n'y a pas de fichiers de mots de passe Unix
RewriteRule etc/passwd / [F]
RewriteRule etc/shadow / [F]
# autres... voir dans snort les fichiers webiis-lib et webfp-lib entre autres
# pour d'autres exemples de signatures d'événements suspects
RewriteRule /./ / [F]
RewriteRule /../ / [F]
RewriteRule (administrators.pwd)|(authors.pwd)|(users.pwd)|(service.pwd) / [F]
RewriteRule msadcs.dll / [F]

# Acceptation de ce qui est connu et référencé officiellement
# la racine
RewriteRule ^/$ http://192.168.66.66:80/ [P]
# les images gif dans le répertoire /library/homepage/images/
RewriteRule ^/library/homepage/images/(.*).gif$ http://192.168.66.66:80/library/homepage/images/$1.gif [P]
# quelques scripts asp dans différents répertoires
# penser à recopier les paramètres des scripts utilisés par le méthode get ;-)
RewriteRule ^/usa/events/default.asp$ http://192.168.66.66:80/usa/events/default.asp [P]
RewriteRule ^/isapi/redir.dll?(.*)$ http://192.168.66.66:80/isapi/redir.dll?$1 [P]
RewriteRule ^/isapi/events/usa/enu/(search_results|event_detail).asp?(.*)$ http://192.168.66.66:80/isapi/events/usa/enu/$1.asp?$2 [P]

# Interdiction par défaut de ce qui n'est pas connu
RewriteRule .* / [F]
------------



Et voilà comment avec quelques lignes de configuration et un peu d'huile de
coude il est possible de limiter fortement l'accès à un serveur web et donc
de limiter les accès non voulus à des scripts vulnérables qui auraient été
installés à l'insu de votre plein gré ;-)

Bien sûr, ceci ne vous protège pas des vulnérabilités des scripts autorisés
pour lesquels la meilleure solution est l'audit de code des parties
utilisant du code reçu des utilisateurs depuis Internet.



Last modified on 12 November 2003 at 13:55:00 CET - webmaster@hsc.fr
Mentions légales - Information on this server - © 1989-2013 Hervé Schauer Consultants