Blog

  • Infrastructures, Sécurité et Identités, SOA & Urbanisation

Sécuriser un proxy service, part 3 – Ajouter un reverse proxy Apache

Dans le deuxième article de cette série, nous vous avons présenté comment sécuriser une communication en utilisant le « two-ways SSL ».
Dans cette dernière partie, nous nous intéresseront toujours à la sécurisation de la couche transport en y ajoutant, en frontal du serveur Weblogic, un reverse proxy Apache. Nous conserverons le Two-ways SSL en amont et aval du reverse proxy, le tout en utilisant une seule clé d’authentification (mais plusieurs clés de cryptage).
Les étapes de configurations sont les suivantes :

  • Voir le post précédent pour la configuration de SOAP UI et Weblogic
  • Installation d’Apache Web Server (non décrit ici)
  • Création des certificats du Serveur Apache
  • Importation de la clé d’authentification
  • Configuration d’Apache en mode Reverse Proxy
  • (Optionnel) Configuration de « Virtual Hosts »  pour appliquer une configuration au cas par cas

Jetons un œil aux détails !

Création des certificats du Serveur Apache

Génération du certificat Apache avec « openssl » valide 10 ans :

[root@proxy.lille.easyteam.fr /]# cd /etc/pki/tls/
openssl req -x509 -new -out apache.crt -keyout apache.key -days 3650
Generating a 1024 bit RSA private key
...............................................................................++++++
..........................................++++++
writing new private key to 'apache.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:FR
State or Province Name (full name) [Berkshire]:France
Locality Name (eg, city) [Newbury]:Lille
Organization Name (eg, company) [My Company Ltd]:Easyteam
Organizational Unit Name (eg, section) []:UDP
Common Name (eg, your name or your server's hostname) []:proxy.lille.easyteam.fr
Email Address []:

Vérification de la génération des certificats (apache.crt, apache.key):

[root@proxy.lille.easyteam.fr tls]# ll
total 52
-rw-r--r-- 1 root root 1119 Mar 22 12:12 apache.crt
-rw-r--r-- 1 root root  963 Mar 22 12:12 apache.key
lrwxrwxrwx 1 root root   19 Feb 23 13:32 cert.pem -> certs/ca-bundle.crt
drwxr-xr-x 2 root root 4096 Mar  8 23:46 certs
drwxr-xr-x 2 root root 4096 Feb 23 13:32 misc
-rw-r--r-- 1 root root 9828 Mar 12  2010 openssl.cnf
drwxr-xr-x 2 root root 4096 Mar  8 23:20 private

Déplacement des certificats aux emplacements prévus :

[root@proxy.lille.easyteam.fr tls]# mv apache.crt certs/
[root@proxy.lille.easyteam.fr tls]# mv apache.key private/

Pour la configuration du two-ways SSL entre le proxy et le serveur OSB, il est nécessaire que la clé privée du serveur apache ne soit pas sécurisée par une passphrase. Cette fonctionnalité n’est pour l’instant pas supportée par la directive « SSLProxyMachineCertificateFile » de la configuration Apache. Cf. http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslproxymachinecertificatefile
Pour supprimer la passphrase, vous pouvez utiliser les commandes suivantes :

[root@proxy.lille.easyteam.fr private]# cp apache.key apache.key.secure.bak
[root@proxy.lille.easyteam.fr private]# openssl rsa -in apache.key.secure.bak -out apache.key
Enter pass phrase for apache.key.secure.bak:
writing RSA key

Importation de la clé d’authentification

Maintenant copier sur le serveur proxy le certificat issue du keystore PKCS12 (ici adrien.p12.cer utilisé par SOAP UI dans l’article précédent) de préférence dans le dossier « private ».
Le transformer en format PEM :

[root@proxy.lille.easyteam.fr private]# openssl x509 -inform der -in adrienpc.p12.cer -out adrienpc.p12.pem
Ce certificat sera utilisé pour authentifier le client et s’authentifier sur le serveur distant.

Pour sécuriser la connexion vers le serveur OSB il est nécessaire de regrouper les certificats utilisés (Clé RSA & Certificat x509) :

[root@proxy.lille.easyteam.fr private]# cat ../certs/apache.crt apache.key > apache.bundle.pem

On vérifie que les certificats restent accessibles dans le « bundle » ainsi créé. Vérification du certificat x509 :

[root@proxy.lille.easyteam.fr private]# openssl x509 -in apache.bundle.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
b1:82:10:0a:67:2c:d0:58
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=FR, ST=France, L=Lille, O=Easyteam, OU=UDP, CN=proxy.lille.easyteam.fr
Validity
Not Before: Mar 22 11:12:06 2011 GMT
Not After : Mar 19 11:12:06 2021 GMT
Subject: C=FR, ST=France, L=Lille, O=Easyteam, OU=UDP, CN=proxy.lille.easyteam.fr
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:a1:fb:9a:3c:bb:53:72:88:cb:d2:d5:e3:f4:8b:
…
de:33:88:1e:4a:4a:19:96:2b
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
EF:58:…:B7:D8:49
X509v3 Authority Key Identifier:
keyid:EF:58:EF:FF:F7:…:0B:A8:B7:D8:49
DirName:/C=FR/ST=France/L=Lille/O=Easyteam/OU=UDP/CN=proxy.lille.easyteam.fr
serial:B1:82:10:0A:67:2C:D0:58
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
07:ce:39:dc:3c:db:a0:af:97:9d:fb:a9:e6:fb:9c:81:56:9b:
…
99:6a:d4:ad:5c:15:33:1e:e2:88:41:71:a5:00:f1:6b:c8:c2:
45:a7

Vérification de la clé RSA :

[root@proxy.lille.easyteam.fr private]# openssl rsa -in apache.bundle.pem -check
Enter pass phrase for apache.bundle.pem:
RSA key ok
writing RSA key
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQCh+5o8u1NyiMvS1eP0i28uW35JSoeWjwJYzht9qNzTqq5z8zQz
…
mMeXC/A2QiB3vOhPUAUCQQCNWjXMrKp9psvVMQ6wJfTZZybtNit2Ao7h7DUrVKjg
bYBXqLlLg9pjMZbQxv+zsK+6Iw+rtCv9wVRc13DSBed6
-----END RSA PRIVATE KEY-----

Configuration d’Apache en mode Reverse Proxy

Utilisation d’un vhost (basé sur le port ou le nom DNS) par partenaire :
Exemple sur un vhost basé sur le port (ici exemple d’une configuration sur le port 4433 du partenaire easyteam_lyon), ce fichier est à placer dans le répertoire de configuration d’apache (ici /etc/httpd/conf.d) :

Listen 4433
NameVirtualHost *:4433
<VirtualHost *:4433>
ServerName localhost
ErrorLog /var/log/httpd/easyteam_lyon.error.log
LogFormat "%h %l %u %t "%r" %>s %b "%{SSL_CLIENT_I_DN}i" "%{SSL_SERVER_I_DN}i"" combined
CustomLog /var/log/httpd/easyteam_lyon.access.log combined
# activate SSL on client Connexion
SSLCertificateKeyFile /etc/pki/tls/private/apache.key
SSLCertificateFile    /etc/pki/tls/certs/apache.cert
SSLEngine On
# activate Two-ways SSL between client and proxy
SSLCACertificateFile /etc/pki/tls/private/adrienpc.p12.pem
SSLVerifyClient require
SSLVerifyDepth 2
# activate Two-ways SSL between proxy and remote server
SSLProxyEngine On
SSLProxyCACertificateFile /etc/pki/tls/private/adrienpc.p12.pem
SSLProxyMachineCertificateFile /etc/pki/tls/certs/apache.bundle.pem
ProxyRequests Off
<Proxy *>
AddDefaultCharset Off
Order deny,allow
Allow from all
</Proxy>
# Proxying Input request on port 4433 to secure OSB port
<Location />
ProxyPass          https://soa.lille.easyteam.fr:8002/SOAOrderBooking/
ProxyPassReverse   https://soa.lille.easyteam.fr:8002/SOAOrderBooking/
</Location>
</VirtualHost>

Avec cette configuration il est possible de mapper des services, des arborescences ou des projets OSB complets à chacun des partenaires indépendamment.
Pour accéder de l’extérieur au service situé au « endpoint » interne :
https://soa.lille.easyteam.fr:8002/SOAOrderBooking/ProxyServices/WS_Order
Il faudra utiliser le « endpoint » :
https://url_proxy_public:4433/ProxyServices/WS_Order

Sécurisation par partenaire

Pour plus de sécurité et afin de mieux contrôler les accés partenaires il est obligatoire que chacun d’entre eux utilise son propre certificat d’authentification et de chiffrement.
Cela implique une configuration « vhost » par partenaire qui pourra s’effectuer par Port ou par Nom d’hôtes
Exemple par port :
Pour le client 1 :

Listen 4431
NameVirtualHost *:4431
<VirtualHost *:4431>
ServerName localhost
…
</VirtualHost>

Le client se connectera avec comme base d’URL http://ip|host:4431/url_service
Pour le client 2 :

Listen 4432
NameVirtualHost *:4432
<VirtualHost *:4432>
ServerName localhost
…
</VirtualHost>

Le client se connectera avec comme base d’URL http://ip|host:4432/url_service
Exemple par nom d’hôte :
Pour le client 1 :

NameVirtualHost *:443
<VirtualHost *:443>
ServerName client1.bus.easyteam.fr
…
</VirtualHost>

Le client se connectera avec comme base d’URL http://client1.bus.easyteam.fr:443/url_service
Pour le client 2 :

NameVirtualHost *:443
<VirtualHost *:443>
ServerName client2.bus.easyteam.fr
…
</VirtualHost>

Le client se connectera avec comme base d’URL http://client2.bus.easyteam.fr:443/url_service

Conclusion

Grâce à l’ajout d’un Reverse Proxy, il est maintenant possible d’effectuer un rebond dans une DMZ ainsi que de configurer finement l’accès de chaque partenaire à la plateforme OSB. Voici donc un exemple de sécurisation de la couche transport. Si budget il y a, cette solution peut-être remplacée par une solution matérielle de type « Accélarateur SSL ».

Administrateur
Administrateur
Voir tous ses articles
Articles récents

Mentions légales & Politique de confidentialité