Chargement du Portfolio...
Portfolio Romain Begot

Missions de Stage

Présentation détaillée des missions techniques réalisées durant mes stages, axées sur la configuration serveur, la sécurisation et l'infrastructure réseau.

Passage en HTTPS avec Apache en redirection

Contexte de la mission

L'objectif de cette mission était de sécuriser l'accès à une application CRM (HubSpot) en configurant le serveur web Apache existant pour utiliser le protocole HTTPS. L'application, nommée "Mage", était déployée via Docker sur un serveur Linux virtuel (SrvV19) et était initialement accessible via HTTP sur le port 8081 (http://exemple.com:8081). L'utilisation d'un certificat SSL wildcard existant pour le domaine exemple.com a été confirmée comme possible.

La tâche impliquait donc d'installer les modules Apache nécessaires, de configurer un Virtual Host pour gérer le trafic HTTPS sur le port 443, d'appliquer le certificat SSL, de mettre en place un reverse proxy vers l'application Docker, et enfin de rediriger tout le trafic HTTP (port 80) vers HTTPS.

Étapes techniques réalisées

Les outils principaux utilisés pour cette intervention ont été Putty pour l'exécution des commandes en SSH sur le serveur, et WinSCP pour une navigation et une édition facilitées des fichiers de configuration.

  1. Étape 1 : Installation des modules Apache nécessaires

    Avant toute configuration, il est essentiel de s'assurer que le serveur Apache dispose des modules requis pour la gestion du SSL/TLS et d'autres outils utiles. Ces commandes ont été exécutées avec les droits superutilisateur.

    sudo yum install mod_ssl -y

    Explication de la commande :

    sudo : Exécute la commande suivante avec les privilèges de superutilisateur (root), nécessaires pour installer des logiciels.

    yum install : Utilise YUM (Yellowdog Updater, Modified), le gestionnaire de paquets pour les distributions Linux basées sur RPM (comme AlmaLinux, CentOS), pour installer un nouveau paquet.

    mod_ssl : C'est le module pour le serveur HTTP Apache qui fournit une cryptographie forte en utilisant les protocoles SSL (Secure Sockets Layer) et TLS (Transport Layer Security). Il est indispensable pour activer HTTPS.

    -y : Option qui répond automatiquement "oui" (yes) à toutes les questions de confirmation que YUM pourrait poser durant le processus d'installation, rendant l'installation non interactive.

    sudo yum install httpd-tools -y

    Explication de la commande :

    httpd-tools : Ce paquetage contient divers outils pour le serveur HTTP Apache. Bien que non strictement nécessaire pour SSL en soi, il inclut des utilitaires comme htpasswd (pour la gestion des fichiers d'authentification basique), ab (Apache Benchmarking, pour tester les performances), etc., qui peuvent être utiles dans la gestion globale d'un serveur Apache.

  2. Étape 2 : Création du fichier Virtual Host pour HTTPS (Proxy Inverse)

    La configuration d'Apache se fait majoritairement via des fichiers de configuration. Pour cette mission, nous devons définir comment Apache va gérer les requêtes HTTPS pour le domaine exemple.com. Cela se fait via un "Virtual Host".

    Déplacement vers le répertoire des configurations spécifiques d'Apache :

    cd /etc/httpd/conf.d

    Pourquoi créer un fichier Virtual Host (ssl_proxy.conf) ?

    Un Virtual Host permet à Apache de gérer plusieurs sites web ou configurations distinctes sur un même serveur. Dans ce cas précis, nous créons un Virtual Host pour le port 443 (HTTPS) afin de :

    • Spécifier le nom de domaine concerné (exemple.com).
    • Activer le moteur SSL/TLS (SSLEngine on).
    • Indiquer les chemins vers les fichiers du certificat SSL et de la clé privée.
    • Mettre en place un reverse proxy pour rediriger les requêtes HTTPS reçues par Apache vers l'application CRM tournant sur Docker (port 8081).

    Isoler cette configuration dans un fichier dédié (ssl_proxy.conf) dans /etc/httpd/conf.d/ est une bonne pratique pour la clarté et la maintenance.

    Création et édition du fichier de configuration pour SSL et le proxy :

    nano ssl_proxy.conf

    Explication de la commande :

    nano : Lance l'éditeur de texte en ligne de commande Nano, simple d'utilisation pour modifier des fichiers de configuration directement sur le serveur.

    ssl_proxy.conf : Nom donné au fichier de configuration. Il est courant de nommer les fichiers de configuration de manière descriptive. Ce fichier contiendra les directives pour le Virtual Host SSL et la configuration du proxy.

    Le contenu suivant a été inséré dans le fichier ssl_proxy.conf :

    <VirtualHost *:443>
    ServerName exemple.com
    SSLEngine on
    SSLCertificateFile /etc/pki/tls/certs/exemple.crt
    SSLCertificateKeyFile /etc/pki/tls/private/exemple.key

    ProxyPreserveHost On
    ProxyPass / http://exemple.com:8081/
    ProxyPassReverse / http://exemple.com:8081/
</VirtualHost>

    Explication du code de ssl_proxy.conf :

    <VirtualHost *:443> : Définit un bloc de configuration pour un hôte virtuel. *:443 signifie que cette configuration s'applique à toutes les adresses IP du serveur (*) pour les connexions entrantes sur le port 443 (port standard pour HTTPS).

    ServerName exemple.com : Spécifie le nom de domaine pour lequel ce Virtual Host est actif.

    SSLEngine on : Active le moteur SSL/TLS pour ce Virtual Host, ce qui est nécessaire pour le HTTPS.

    SSLCertificateFile /etc/pki/tls/certs/exemple.crt : Indique le chemin vers le fichier du certificat SSL public pour le domaine exemple.com.

    SSLCertificateKeyFile /etc/pki/tls/private/exemple.key : Indique le chemin vers le fichier de la clé privée correspondant au certificat SSL. Ce fichier doit être sécurisé et non accessible publiquement.

    ProxyPreserveHost On : Lorsque Apache agit comme un reverse proxy, cette directive s'assure que l'en-tête Host original envoyé par le client est transmis au serveur backend (l'application Docker). C'est important pour que l'application backend sache quel domaine a été demandé.

    ProxyPass / http://exemple.com:8081/ : C'est la directive principale du reverse proxy. Elle indique que toutes les requêtes reçues par ce Virtual Host (/ signifie la racine et tout ce qui suit) doivent être transmises (proxifiées) au serveur applicatif situé à l'adresse http://exemple.com:8081/.

    ProxyPassReverse / http://exemple:8081/ : Cette directive est complémentaire à ProxyPass. Elle réécrit les en-têtes HTTP comme Location, Content-Location et URI dans les réponses du serveur backend pour qu'ils correspondent à l'URL du proxy (Apache) et non à l'URL interne du serveur backend. Cela évite des problèmes de redirection incorrecte.

  3. Étape 3 : Création du fichier de redirection HTTP vers HTTPS

    Pour s'assurer que tous les utilisateurs accèdent au site de manière sécurisée, il est important de rediriger automatiquement ceux qui tenteraient de se connecter en HTTP (port 80) vers la version HTTPS.

    Pourquoi créer un fichier de redirection (redirect-cr.conf) ?

    Ce fichier de configuration est dédié à la gestion du trafic arrivant sur le port 80 (HTTP). Son unique rôle est de :

    • Capturer toutes les requêtes pour exemple.com sur le port 80.
    • Effectuer une redirection permanente (code HTTP 301) vers l'URL HTTPS correspondante (https://exemple.com:8081/).

    Cela garantit que même si un utilisateur tape http://exemple.com ou suit un ancien lien HTTP, il sera automatiquement dirigé vers la version sécurisée, forçant ainsi l'utilisation du HTTPS.

    Création et édition du fichier de redirection :

    nano redirect-cr.conf

    Explication de la commande :

    nano redirect-cr.conf : Ouvre (ou crée s'il n'existe pas) le fichier redirect-cr.conf avec l'éditeur Nano. Ce fichier contiendra la configuration du Virtual Host pour le port 80, responsable de la redirection.

    Le contenu suivant a été inséré dans le fichier redirect-cr.conf :

    <VirtualHost *:80>
    ServerName exemple.com
    Redirect permanent / https://exemple.com:8081/
</VirtualHost>

    Explication du code de redirect-cr.conf :

    <VirtualHost *:80> : Définit un bloc de configuration pour un hôte virtuel écoutant sur toutes les adresses IP (*) pour les connexions entrantes sur le port 80 (HTTP).

    ServerName exemple.com : Spécifie que cette configuration s'applique aux requêtes pour le domaine exemple.com.

    Redirect permanent / https://exemple.com:8081/ : C'est la directive clé pour la redirection.

    Redirect permanent : Indique à Apache d'effectuer une redirection permanente (avec un code de statut HTTP 301). Cela signifie pour le navigateur et les moteurs de recherche que l'adresse a définitivement changé.

    / : S'applique à toutes les requêtes reçues sur la racine du site et tout ce qui suit.

    https://exemple.com:8081/ : L'URL de destination vers laquelle les utilisateurs seront redirigés. Elle spécifie le protocole HTTPS et le port 8081, conformément à la configuration de l'application CRM.

  4. Dernière Étape : Configuration SELinux et redémarrage d'Apache

    SELinux (Security-Enhanced Linux) est un module de sécurité du noyau Linux qui peut, par défaut, empêcher Apache d'établir des connexions réseau sortantes, ce qui est nécessaire pour que le reverse proxy fonctionne (Apache doit se connecter à l'application sur le port 8081).

    setsebool -P httpd_can_network_connect 1

    Explication de la commande setsebool -P httpd_can_network_connect 1 :

    setsebool : C'est la commande utilisée pour modifier les valeurs des booléens SELinux. Les booléens SELinux sont des interrupteurs qui activent ou désactivent certaines règles de la politique de sécurité.

    -P : Cette option rend le changement permanent. Sans cette option, la modification du booléen serait perdue au prochain redémarrage du système. Avec -P, la configuration est écrite sur le disque.

    httpd_can_network_connect : C'est le nom du booléen SELinux spécifique qui contrôle si le processus du serveur HTTP Apache (httpd) est autorisé à initier des connexions réseau vers d'autres services/ports. Pour un reverse proxy, Apache a besoin de cette permission pour se connecter au serveur backend (l'application Docker sur le port 8081).

    1 : C'est la valeur pour activer (ou mettre à "vrai") le booléen. Mettre ce booléen à 1 autorise donc Apache à établir des connexions réseau sortantes.

    Après toutes ces configurations, il est impératif de redémarrer le service Apache pour qu'il prenne en compte les nouveaux fichiers de configuration et les modifications des modules.

    systemctl restart httpd

    Explication de la commande :

    systemctl : C'est l'outil de contrôle principal pour systemd, le gestionnaire de système et de services utilisé par de nombreuses distributions Linux modernes (y compris AlmaLinux). Il permet de gérer les services (démarrer, arrêter, redémarrer, vérifier l'état, etc.).

    restart httpd : Cette commande demande à systemd de redémarrer le service httpd (le service Apache). Un redémarrage arrête le service s'il est en cours d'exécution, puis le redémarre, rechargeant ainsi sa configuration.