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 > Pourquoi un relais 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
|>|Pourquoi un relais inverse  

par Denis Ducamp (13/02/2001)



Cet article va tenter de montrer l'utilité d'un relais inverse pour protéger
un serveur web et pourquoi il est bon de séparer dans des DMZ différentes
les différents services nécessaires à une application web.

Dans le cas d'un relais inverse, l'intérêt du filtrage applicatif est la
description des URL autorisées :

. les répertoires autorisés : empêche l'accès aux répertoires de scripts de
  démonstrations (plus ignobles les uns que les autres)

. les extensions autorisées : empêche l'accès aux types mime exotiques
  (alias backdoors ;-)

. les fichiers accessibles pour certains répertoires sensibles : empêche
  l'accès aux "sous-scripts" non accédés normalement et donc plus sensibles
  car non audités (par manque de temps ?).

. les paramètres et leurs types pour les scripts sensibles : devrait
  empêcher pas mal de débordements de buffers et d'autres types d'attaques
  telles que l'encapsulation de commandes SQL

Les cookies peuvent aussi être sujet à toute votre attention si
l'application en utilise.

Sans filtrage applicatif, le relais n'a d'autre fonctionnalité que celle
d'un relais générique sauf qu'il ne laisse passer que des requêtes HTTP. Le
filtrage d'URL peut être mis en place dans un serveur apache configuré en
relais inverse (reverse proxy ;-) avec mod_rewrite, voir
http://httpd.apache.org/docs/mod/mod_rewrite.html .

Les serveurs protégés pouvant se trouver en adressage privé, seuls les
relais étant publics, il est ainsi possible de changer d'architecture en
minimisant les perturbations. Lorsque la nouvelle architecture est prête
il suffit alors de changer la configuration du relais pour que les requêtes
suivantes soient immédiatement redirigées.

Il est également possible d'ajouter l'authentification des utilisateurs et
le chiffrement des sessions sur le relais même si ceci n'est pas possible
sur le serveur sensible. Ceci peut permettre de décharger le serveur web
d'une charge potentiellement importante, charge qui pourra même être
supportée par plusieurs relais.

La centralisation de l'authentification sur le relais inverse peut permettre
d'utiliser une technologie incompatible avec certains des serveurs protégés
et de centraliser celle-ci qui pourra alors être gérée par un service
spécialisé.

Une dernière raison, et la plus importante selon moi, est de pouvoir
sécuriser le dernier serveur qui vient de vous être livré suite à la
commande de la dernière application web décidée par des commerciaux et pour
laquelle le support n'accepte de vous donner que le conseil suivant :

	"si vous changez quoi que ce soit à la configuration par défaut du
	serveur HTTP installé de façon complète avec tous les exemples
	vulnérables alors vous perdrez toute assistance de notre part"

Oups... quand vous avez garanti que l'application allait tourner 23h55 par
jour alors vous acceptez de prendre ce risque et de coller des
administrateurs d'astreinte 365 jours par an.

Même ainsi protégé par le relais, le serveur web doit se trouver dans une
autre DMZ et non pas en interne. "Ne jamais permettre à un serveur
contactable de l'extérieur à se connecter directement en interne" est à mon
avis une bonne règle pour dormir plutôt tranquille ;-)

Un relais inverse n'est pas un simple relais HTTP. Un relais inverse se
comporte comme un serveur HTTP côté client et comme un client HTTP côté
serveur. La technologie libre permet cela et apache est un choix de qualité
pour mettre cela en oeuvre. Vous pouvez voir sur
http://www.hsc.fr/tips/ , deux articles sont déjà disponibles, le
premier sur la configuration de base d'un serveur apache en relais inverse
avec chiffrement et authentification par mots de passe et le second pour
chrooter ce serveur.

Je me permets de me répéter : un relais inverse n'est utile que s'il apporte
des fonctionnalités (authentification par mots de passe ou forte par
certificats, chiffrement, filtrage applicatif). Pour protéger des cgi
vulnérables, il faut que le relais inverse soit capable de filtrer les
données envoyées par l'utilisateur : URL (chemin, fichiers, listes et types
des paramètres...), cookies, ... Dans apache il faut utiliser mod_rewrite
(URL Rewriting Engine) et un peu d'huile de coude.


Comment séparer les services d'une application web ?
----------------------------------------------------

Séparer les services d'une application web (serveur HTTP et serveurs de
bases de données front et back office) et insérer un relais inverse dans une
architecture est important pour obtenir un plus haut niveau de sécurité.

Le relais inverse dans la DMZ A s'adresse au serveur web dans la DMZ B qui
lui s'adresse alors au serveur de bases de données dans la DMZ C. Les
administrateurs et développeurs sont autorisés depuis l'interne à se
connecter aux serveurs web et SQL pour mettre à jour les données,
éventuellement c'est le serveur SQL interne qui met à jour le serveur SQL
dans la DMZ C.

Savoir qu'aucun serveur dans une DMZ ne peut se connecter en interne permet
quand même de mieux dormir la nuit car si l'un d'eux est compromis alors la
compromission est restreinte à la DMZ en question.

Maintenant dans ce schéma, nous pouvons accepter que le serveur web
interroge le serveur SQL interne à la seule condition que les deux
recommandations suivantes soient toutes les deux appliquées :

. les scripts cgi sensibles ont été audités et durcis

. du filtrage applicatif fort (URL *et* paramètres) a été mis en place sur
  le relais inverse pour limiter les attaques possibles.

Mais personnellement pour mieux dormir la nuit je préfère installer le
serveur SQL dans une DMZ et que le serveur SQL interne fasse des copies de
la base vers le serveur "public" : si un pirate modifie la base, ce n'est
pas la base de travail, mais une copie qui est modifiée. Ainsi les pirates
n'ont accès qu'à des copies, facilement et rapidement restaurables.


Pourquoi la séparation des services dans différentes DMZ est elle
préférables ?
-----------------------------------------------------------------

Imaginons que dans votre unique DMZ vous n'ayez qu'un serveur avec le
serveur web, vos applications cgi et votre base de données et que le
firewall ne permette que de se connecter depuis Internet vers ce serveur sur
le port 80.

Si vous avez un script cgi vulnérable permettant d'exécuter du code sur
votre serveur (même en perl sous NT ceci est possible, par exemple s'il fait
un system("commande " . "donnée de l'utilisateur"); sans vérifier
suffisamment les données de l'utilisateur) alors le pirate se retrouve avec
un "shell" utilisateur (nobody ou iusr_machin voire system). Une fois avec
un shell, ce n'est effectivement (en théorie) qu'une question de temps pour
que le pirate devienne administrateur, d'où l'utilité de "chrooter" les
applications dans des cages vides.

À l'heure qu'il est le pirate est déjà administrateur sur votre serveur car
celui-ci étant complexe il nécessite de nombreux programmes et donc
l'escalade des privilèges est aisée. Le pirate peut donc non seulement
modifier le serveur web, mais aussi les scripts cgi et les bases de données.
Comme dans notre cas (le pire) cette base de données était la base de
travail de l'entreprise et abritait tout le savoir de l'entreprise, sa
destruction (avec au pire son transfert chez le concurrent) ne provoquera
qu'un dépôt de bilan et la mise au chômage de quelques dizaines d'employés.

Le scénario reste sensiblement le même si les services sont séparés sur deux
machines positionnées dans la même DMZ sans filtrage IP entre les deux :
depuis le serveur web, le pirate utilisera un service réseau vulnérable de
la seconde machine pour y accéder puis une vulnérabilité locale pour obtenir
les droits d'administration.

En positionnant du filtrage IP entre ces deux machines, le cas général étant
de les placer dans deux DMZ différentes, alors après compromission de la
première machine via les scripts cgi le pirate ne pourra s'attaquer à la
seconde machine que sur le port de la base de données. Cette dernière ayant
été configurée pour n'accepter que des demandes de lectures depuis la
première DMZ, il sera donc nécessaire qu'il existe une vulnérabilité
exploitable sur ce service pour obtenir un shell dans la seconde DMZ.

Pour se prémunir des dégâts à longs termes en cas de vulnérabilité de la
base de données, les données présentes ne seront qu'une copie de la base de
travail, de plus la quantité de données sera limitée au stricte nécessaire.
Un problème est alors de synchroniser les données entre l'interne et
l'externe...

Dans le cas où Internet n'a pas de raison de mettre à jour les données,
c'est à dire que les scripts ne font que de la lecture, alors seul le
serveur interne est autorisé à se connecter au serveur de la DMZ. En fait,
même dans le cas où les internautes peuvent envoyer des données alors il est
possible de faire en sorte que seul le serveur interne se connecte au
serveur de la DMZ. Dans ce cas les connexions doivent se faire régulièrement
(toutes les 5 minutes par exemple) et les données téléchargées doivent se
retrouver dans une base tampon d'où elles ne sortiront qu'après avoir montré
"pattes blanches".

Dans ce scénario, le point faible est le serveur web et les scripts qu'il
héberge. Pour améliorer la situation, la meilleure solution est l'audit des
scripts et leurs durcissements. Malheureusement entre le début de l'audit et
la fin du durcissement se seront passés beaucoup de temps et auront été
dépensés beaucoup d'argent... La meilleure chose est alors de rajouter un
filtrage applicatif avant l'accès aux scripts.

Une solutions possible est un serveur apache en relais inverse (reverse
proxy) sur lequel la configuration permette de n'autoriser l'accès qu'aux
cgi normalement accédés pour l'application (bye bye les exemples inutiles et
vulnérables et les fonctionnalités superflues) et filtrer les paramètres
suivant leurs types. Ainsi le nombre de poches de fraises flagada (par
exemple) commandées ne pourra plus être une chaîne interminable de
caractères se terminant par du code assembleur contenant quelques appels
systèmes bien choisis.

Bien sûr si l'attaquant arrive à faire exécuter du code au serveur web alors
il pourra toujours attaquer le port de la base de données, mais la
probabilité qu'il parvienne à obtenir un shell a été tellement diminuée
(comment placer du code exécutable dans un buffer trop petit ?) qu'il mérite
bien de l'avoir ce shell ;-) .



Ainsi dans le cas d'une unique DMZ, le pirate a accès à tout un tas de
services et c'est bien le plus faible qui sera exploité. Au contraire dans
le cas de multiples DMZ, le pirate n'a plus aucun choix possible et à chaque
étape il doit forcément exploiter le seul et unique service auquel il a
accès pour avancer. De plus le nombre des services clés étant alors limités,
il m'est possible de me concentrer sur ceux-ci et garder un haut niveau de
sécurité devient alors possible.


Mais un pirate aura tout son temps pour vous attaquer !
-------------------------------------------------------

Il est vrai qu'un pirate aura tout son temps pour vous attaquer, il ne se
lassera pas et pire que tout, il peut être payé pour vous attaquer vous...

Imaginons que votre architecture soit une chaîne que le pirate doive casser.
Dans le cas où le pirate a accès à plusieurs maillons simultanément alors la
force de la chaîne est celle du maillon le plus faible car il peut accéder
simultanément à tous les maillons de la chaîne.

Dans le cas où vous ne pouvez accéder qu'à un seul maillon alors il faut le
casser avant d'accéder au maillon suivant qu'il faut également casser avant
d'accéder au maillon suivant... On se trouve dans le cas de "bretelle +
ceinture", je préfère dire dans le cas où "je dors sur mes deux oreilles".

Ceci peut être illustré par quelques petites statistiques...

1) une machine avec 2 services a et b avec des probabilités respectives p1
et p2 d'être vulnérables.

Pour avoir un shell sur cette machine et pouvoir accéder derrière alors il
faut exploiter au moins une des deux vulnérabilités :
p = p1(1-p2) + p2(1-p1) + p1xp2
si p1 = p2 = 0.1 alors p = 0.09 + 0.09 + 0.01 = 0.19

2) deux machines en série, la première avec le service a et la seconde le
service b avec des probabilités respectives p1 et p2 d'être vulnérables.

Pour avoir un shell sur la seconde machine et pouvoir accéder derrière alors
il faut exploiter la première vulnérabilité puis exploiter la seconde
(j'imagine que ces probabilités sont indépendantes et que donc p2\p1 (lire
p2 si p1) est égal à p2) :
p = p1 x p2\p1 = p1 x p2
si p1 = p2 = 0.1 alors p = 0.1 x 0.1 = 0.01

On voit bien que dans le cas des services séparés sur plusieurs machines
protégées l'une de l'autre par du filtrage IP, la probabilité (virtuelle) de
piratage fort est bien moins important que dans l'autre cas où dès que le
premier maillon cède la plate-forme est quasi immédiatement sous le contrôle
total du pirate.



Dernière modification le 12 novembre 2003 à 13:55:00 CET - webmaster@hsc.fr
Mentions légales - Informations sur ce serveur - © 1989-2013 Hervé Schauer Consultants