Reverse Proxy, Apache et sécurisation d`application

Transcription

RAHME.FR
Reverse Proxy, Apache et sécurisation d'application
Soumis par Johnny RAHME
Difficulté
(Admin Systèmes et Réseaux)
1. Introduction
Je traiterai dans cet article de la sécurisation d'accès externe vers des applications internes d'une entreprise, à l'aide d'un
Reverse Proxy implémenté avec Apache, sur plateforme Linux (GNU/Debian).
{mospagebreak title=2. Environnement}
2. Environnement
Voici la situation:
Je prendrai le cas d'une entreprise, car c'est le cas avec le plus de contraintes, mais rien n'empêche d'appliquer ce cas
aux particuliers (comme je l'ai également fait moi-même chez moi).
Une entreprise possède plusieurs site intranet, ou applications internes, qui doivent absolument être accessible depuis
l'extérieur de l'entreprise, à savoir depuis internet. Ceci pour divers raisons, entre autres, pour faciliter le travail des
commerciaux, des consultants travaillants à distance, des techniciens en intervention chez un client, etc ..
De plus, dans le cadre de cet article, considérons que les applications en question sont des boîtes noires, dont nous
ignorons le fonctionnement interne.
Prenons le cas d'une application interne, myApp, et deux de ses fonctionnalités, fonc1 et fonc2 qui doivent être
accédées depuis l'extérieur du réseau de la société.
{mospagebreak title=3. Le Reverse Proxy}
3. Le Reverse Proxy
Traitons le cas de l'application interne myApp, accessible en interne (depuis le réseau interne de l'entreprise) par l'url
http://myApp.domaine-interne.fr/.
Fonc1 est à l'adresse http://fonc1.myApp.domaine-interne.fr/, et fonc2 à http://fonc2.myApp.domaine-interne.fr/.
http://hercule.rahme.fr
Propulsé par Joomla!
Généré: 30 September, 2016, 11:18
RAHME.FR
Il est bien évidemment très dangereux, et fortement déconseillé de se contenter d'ouvrir un accès FireWall depuis
l'extérieur aux url susmentionnées, en guise d'accès externe à l'application, pour des raisons évidentes de sécurité,
d'autant plus que nous considérons que le fonctionnement interne de l'application ne nous est pas connu (et donc ni ses
bugs et failles..).
De plus, ce mode d'accès n'ajouterait aucune couche de séurisation, sinon le filtrage des adresses source IP, et quand
on sait la facilité avec laquelle on peut trafiquer une telle adresse, ..
Nous utiliserons donc l'architecture suivante:
Nous placerons, dans la DMZ de l'entreprise, en aval du FireWall d'entrée depuis internet (ou sur ce routeur, pour les
petits parcs), notre serveur Reverse Proxy (RP):
Internet ----------- ||| FireWall_ent || ---{DMZ} ----RP--- {DMZ}------ || FireWall_dmz-interne || ------{interne}---serveur
applicatif (http://myApp.domaine-interne.fr)------{interne}--
Notre application, accessible en interne par http://myApp.domaine-interne.fr/, le sera par l'exterieur, depuis internet, par
l'url https://myApp.domaine-entreprise-externe.fr/.
Ceci nous permettra donc de chiffrer les communications entre l'extérieur et le RP (https, ssl).
3.1. Configuration d'Apache2
Attaquons à présent la configuration de l'architecture.
Côté Apache, j'ai effectué mes tests sur Apache 2.0, et Apache 2.2, sans pour autant profiter des nouvelles
fonctionnalités de la version 2.2.
La plateforme est une Debian en version stable.
Les modules à activer sur Apache2, autre que ceux par défaut, sont les suivants:
mod_proxy, mod_ldap, mod_auth_ldap, mod_proxy_http, mod_ssl, mod_proxy_connect, mod_proxy_html,
mod_auth_basic.
RAHME.FR
Pour activer ces modules, on peut se servir de la commande a2enmod:
rahme.fr # a2enmod nom_du_module
Autrement, on peut également, pour Debian, créer manuellement un lien statique dans {répertoire_apache2}/modsenabled/ des modules présents dans {répertoire_apache2}/mods-available.
En se trouvant dans {répertoire_apache2}/sites-available:
rahme.fr # ln -s nom_du_module ../sites-enabled/
Personnellement, et dans l'optique de la modularité de la solution (plusieurs clients peuvent s'abonner au service, avec
plusieurs comptes distincts et plusieurs cibles différentes), je préfère ne pas concentrer la configuration dans le fichier
mods-enabled/proxy.conf.
En effet, dans ce fichier, je me contente d'interdire tout accès:
[..]
ProxyRequests Off
[..]
C'est tout ce que je modifie dans ce fichier. Cela inactive la fonction de proxy ouvert. Je ne toucherai plus à ce fichier, sauf
pour des tunings qui sortent du cadre de cet article.
A noter qu'il faut absolument positionner ce paramètre à off, si vous n'avez pas envie que votre machine serve de proxy
ouvert sur internet.
RAHME.FR
Côté SSL, il faut préciser les options de ssl (les niveaux acceptés ainsi que les fichiers de certificat et de clé) dans modsenabled/ssl.conf:
[..]
SSLEngine on
SSLCertificateFile /etc/apache2/cert/myCert.crt
SSLCertificateKeyFile /etc/apache2/cert/myKey.key
SSLCipherSuite HIGH:+MEDIUM
SSLProtocol all -SSLv2
[..]
Notre apache2 écoutera sur le port 443. Spécifions-le dans le fichier ports.conf ( {répertoire_apache2}/ports.conf ):
Listen 443
Passons aux hosts. C'est là que j'effectue le coeur de la configuration.
Reprenons l'exemple de myApp.
Rappelons, pour prendre encore une fois le cas le plus contraignant, que cette application présente 2 fonctionnalités
RAHME.FR
intéressantes, accessibles comme suit:
http://fonc1.myApp.domain-interne.fr/
http://fonc1.myApp.domain-interne.fr/
Ces 2 fonctionnalités doivent être, de plus, accédées depuis l'extérieur par 2 équipes de gens différentes !
Jetons un coup d'oeil sur la configuration du VirtualHost correspondant et commentons-la après coup:
NameVirtualHost 192.168.0.70
<VirtualHost myApp.domaine-entreprise-externe.fr>
ServerAdmin [email protected]
ServerName myApp.domaine-entreprise-externe.fr
ProxyPass /fonc1/ http://fonc1.myApp.domaine-interne.fr/
ProxyPassReverse /fonc1/ http://fonc1.myApp.domaine-interne.fr/
ProxyPass /fonc2/ http://fonc2.myApp.domaine-interne.fr/
ProxyPassReverse /fonc2/ http://fonc2.myApp.domaine-interne.fr/
ProxyPassReverseCookieDomain .domaine-interne.fr .domaine-entreprise-externe.fr
<Proxy http://fonc1.myApp.domaine-interne.fr/>
Order Deny,Allow
Deny From all
Allow from 10.118.0.10/26 172.24.0.30
AuthName "myApp - Fonctionnalite 1"
RAHME.FR
AuthType Basic
AuthLDAPURL ldaps://myLDAP/ou=People,dc=ReverseProxy,dc=domaine-interne,dc=fr?uid
require user myappUser1
</Proxy>
<Proxy http://fonc2.myApp.domaine-interne.fr/>
Order Deny,Allow
Deny From all
Allow from 10.118.1.10/26 172.24.0.30
AuthName "myApp - Fonctionnalite 2"
AuthType Basic
AuthLDAPURL ldaps://myLDAP/ou=People,dc=ReverseProxy,dc=domaine-interne,dc=fr?uid
require user myappUser2
</Proxy>
# SSL
# -SSLEngine on
SSLCertificateFile /etc/apache2/cert/myCert.crt
SSLCertificateKeyFile /etc/apache2/cert/myKey.key
SSLCipherSuite HIGH:+MEDIUM
SSLProtocol all -SSLv2
DocumentRoot /local/myApp/
<Directory />
Options FollowSymLinks
AllowOverride None
Order allow,deny
Deny from all
allow from 10.118.0.10/26 10.118.1.10/26 172.24.0.30
</Directory>
RAHME.FR
ErrorLog /var/log/apache2/myApp.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/myAppaccess.log combined
ServerSignature Off
</VirtualHost>
A noter que ce VHost est créé dans sites-available, et un lien symbolique doit en être créé dans sites-enabled/ pour
l'activer (ne pas oublier de reloader apache2 !).
Commentaires:
De prime abord, nous remarquons que l'adresse du serveur RP est 192.168.0.70, et qu'il a le nom DNS de
myApp.domaine-entreprise-externe.fr.
Bien évidemment, il faudra, à chaque nouveau VHost, et donc nouveau "client" accédant à une application différente,
créer dans le DNS un autre nom mappé sur cette adresse IP. Ceci pour bien cloisonner les différents clients de notre
RP.
Par exemple, on peut imaginer un autre VHost, pour une application mySecondApp, et donc création d'une nouvelle
entrée DNS de l'alias mySecondApp.domaine-entreprise-externe.fr à l'IP 192.168.0.70.
Les lignes ProxyPass et ProxyPassReverse font en sorte que tout accès vers https://myApp.domaine-entrepriseexterne.fr/fonc1/ soit redirigé vers http://fonc1.myApp.domaine-interne.fr/, et pareil pour fonc2.
ProxyPassReverseCookieDomain permet la réécriture d'éventuels Set-Cookie et Location dans les réponses de fonc1
et fonc2.
Les sections <proxy ..> .. </proxy> sont assez explicites.
En effet, on restreint l'accès IP aux seuls sous-réseaux spécifiés dans la directive Allow from.
RAHME.FR
De plus, on met en place une authentification par LDAP, en exigeant l'authentification uniquement par l'utilisateur
myappUser1 pour fonc1, et myappUser2 pour fonc2.
Evidemment, il y a encore beaucoup plus d'options avec l'authentification LDAP, que ne couvre pas cet article.
{mospagebreak title=4. Conclusion}
3. Conclusion
Nous avons dans cet article configuré un Reverse Proxy avec Apache 2.0 ou Apache 2.2, sur plateforme Debian.
L'article ne couvre pas toutes les possibilités, mais doit déjà vous permettre de configurer un accès externe assez
sécurisé.

Reverse Proxy, Apache et sécurisation d`application

Transcription

Documents pareils

Arbeitsrecht / Droits du travail

Bienvenue sur le site du Foyer Stéphanais !

Activités à St Germain en Laye

Anonymat internet

Exposition Brasserie des Danaides Marseille 2006

La Légende des 1001 Plumes - Lever de rideau

Carnaval de Limoux - Communauté de communes du Limouxin et

Automobile

SNLE NG Le Terrible - l`amicale des Oreilles d`Or.

PGO Bugrider 200 - Buggy de Poche à Fond

Programmation Web en JavaScript