07/03/2014 SECURISATION DMZ

07/03/2014 SECURISATION DMZ Anthony MANDRON SDIS 21

Table des matières Introduction :... 2 Contexte :... 2 Les solutions possibles :... 2 Le proxy inverse :... 2 Démonstration de la nouvelle solution :... 2 Test de fonctionnement :... 5 Configuration du mandataire inverse pour le webmail roundcube présent sur le serveur mail :... 7 Intégration du serveur mail au sein de la DMZ :... 9 Démonstration de la solution :... 9 ANTHONY MANDRON 1

Introduction : Dans le cadre du stage au sein du SDIS, il est convenu de proposer des solutions permettant de garantir la sécurité au sein de la DMZ. Ces solutions seront proposés sous forme d'un dossier expliquant les pratiques à mettre en œuvre. Ce dossier mettra en avant aussi la mise en application de ces pratiques afin de prouver leur efficacité. Contexte : Le SDIS possède actuellement une DMZ configuré actuellement avec la solution pare-feu NETASQ. Ils voudraient alors améliorer la sécurité de cette DMZ. Il souhaiterait aussi l'intégrer dans leur DMZ leur serveur mail. Les solutions possibles : Le proxy inverse : Actuellement le pare-feu effectue des mécanismes de filtrage et de NAT afin de garantir la sécurité de la DMZ. De plus, un VPN SSL permet de garantir la sécurité des transactions entre la DMZ et l'extérieur du pare-feu. Il est souhaité en plus de garantir la confidentialité des adresses IP des serveurs présents dans la DMZ. Le proxy inverse est un mécanisme permettant de pouvoir répondre à ce besoin. La réalisation du proxy inverse s'effectue par le passage obligé sur celui-ci afin de pouvoir accéder aux serveurs de la DMZ. Il va masquer l'adresse réel du serveur proxy interne, seul l'adresse du proxy inverse sera renvoyé. Le serveur est capable aussi de renvoyer l'adresse du visiteur au lieu de l'adresse du serveur reverse proxy. L'utilisation du proxy inverse peut se faire sur différents protocoles comme le HTTP, HTTPS et le SMTP. Une couche SSL supplémentaire peut alors s'effectuer. Démonstration de la nouvelle solution : Installation de nginx : aptitude install nginx ANTHONY MANDRON 2

Modifier le fichier de configuration de Nginx : vim /etc/nginx/nginx.conf user www-data; worker_processes 2; # Nombre de processus error_log /var/log/nginx/error.log; pid /var/run/nginx.pid; events { worker_connections 512; #Nombre de connexions simultanées par processus } http { include /etc/nginx/mime.types; default_type application/octet-stream; access_log /var/log/nginx/access.log; server_names_hash_bucket_size 64; sendfile on; tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; tcp_nodelay on; gzip on; gzip_comp_level 5; gzip_http_version 1.0; gzip_min_length 0; gzip_types text/plain text/html text/css image/x-icon application/x-javascript; gzip_vary on; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; } On va ensuite créer le fichier proxy.conf dans le dossier conf.d pour permettre à Nginx de se comporter comme un proxy : vim /etc/nginx/conf.d/proxy.conf ANTHONY MANDRON 3

proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 10m; client_body_buffer_size 128k; client_header_buffer_size 64k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 16k; proxy_buffers 32 16k; proxy_busy_buffers_size 64k; Configuration ensuite du site par défaut de Nginx : vim /etc/nginx/sites-enabled/default server { listen 80; server_name website.sdis.lan; access_log /var/log/web.access.log; error_log /var/log/web.nginx_error.log debug; location / { proxy_pass http://10.0.0.2:8080/; } } Configuration d apache sur le serveur web : On va donc ensuite modifier le port d'écoute sur le nouveau port 8080 : vim /etc/apache2/ports.conf NameVirtualHost *:8080 Listen 10.0.0.2:8080 Il faut penser aussi à changer nos hôtes virtuels sur le port 8080. On peut ensuite installer un module apache pour permettre de connaître les adresses IP effectuant des requêtes sur le site web. ANTHONY MANDRON 4

Il faut d'abord installer le module : aptitude install libapache2-mod-rpaf Il faut ensuite redémarrer apache2 et nginx Il faudra créer un alias sur le serveur DNS pointant sur le serveur de mandataire inverse. Test de fonctionnement : Logs : tail -f /var/log/web.access.log ANTHONY MANDRON 5

De plus, Nginx protège le serveur web des attaques déni de service. La saturation du serveur web entraînant l'indisponibilité du site peut être stoppée par Nginx en autorisant un seul maximum de connexions simultanées sur un processus. La commande suivante va nous permettre de tester la robustesse de notre serveur web. ab -k -n 10000 -c 1000 http://website.sdis.lan/ Étant donné qu'on un seul processus pour 512 connexions simultanées et que on lui demande 1000 requêtes web pour 1000 connexions simultanées, il va couper la connexion lors de l'atteinte de la limite autorisée. ANTHONY MANDRON 6

Configuration du mandataire inverse pour le webmail roundcube présent sur le serveur mail : On configure le fichier de Nginx : vim /etc/nginx/sites-enabled/default server { listen 80; server_name srvmail.sdis.lan; access_log /var/log/mail.access.log; error_log /var/log/mail.nginx_error.log debug; location / { proxy_pass http://10.0.0.4:8081/; } } On va donc ensuite modifier le port d'écoute sur le nouveau port 8081: vim /etc/apache2/ports.conf NameVirtualHost *:8081 Listen 10.0.0.2:8081 Il faut penser aussi à changer nos hôtes virtuels sur le port 8081. On peut ensuite installer un module apache pour permettre de connaître les adresses IP effectuant des requêtes sur le site web. Il faut d'abord installer le module : aptitude install libapache2-mod-rpaf Il faut ensuite redémarrer apache2 et nginx. Il faudra créer un alias sur le serveur DNS pointant sur le serveur de mandataire inverse. ANTHONY MANDRON 7

Logs : tail -f /var/log/mail.access.log ANTHONY MANDRON 8

Intégration du serveur mail au sein de la DMZ : Le serveur mail actuel peut aussi demander l'utilisation d'un relais SMTP afin de garantir la confidentialité de l'adresse IP du serveur et des transactions SMTP. La préconisation d'un relais SMTP peut sembler une bonne solution afin de lutter contre les menaces de sécurité, notamment le spam et le phishing. Ce relais constitue une première barrière pouvant contenir des solutions de sécurité pointues afin de lutter contre la détection d'intrusions, le spam, les menaces liées à l échange de messages électroniques. De plus, l'établissement d'une liste noire contenant les adresses mail à ne pas autoriser à communiquer avec le serveur mail. Une fois, les contrôles effectués par le relais, les emails seront alors transmis au serveur mail interne. Ce mécanisme permet à la fois de se prémunir des risques de sécurité et de garantir la sécurité et l'intégrité de notre serveur mail. Démonstration de la solution : On va créer ensuite le fichier permettant le relais des mails : vim /etc/postfix/transport sdis.lan smtp:mail.sdis.lan Il faut ensuite rajouter la donnée "smtp.sdis.lan" dans le relayhost du main.cf du postfix du serveur de messagerie interne. De plus, il faut ajouter un alias sur smtp.sdis.lan pointant sur le relais SMTP. Une fois, les modifications effectuées, redémarré les services postfix sur les deux serveurs. On teste le fonctionnement à travers les logs montrant les transactions se faisant bien par le serveur relais et non pas par le serveur de messagerie interne. ANTHONY MANDRON 9

Logs du serveur interne : ANTHONY MANDRON 10

Logs du serveur relais : Conclusion : La sécurité est devenue un enjeu important pour les organisations afin de protéger leur patrimoine informationnel. La DMZ est une zone totalement indépendante et contenant des données critiques, il est donc nécessaire de garantir sa sécurité. ANTHONY MANDRON 11