Mise en place de services web sécurisés

Projet en bref

Contexte

Ce projet consistait à construire un prototype d’hébergement web dans un environnement virtualisé. Deux sites devaient être publiés sur le même serveur tout en respectant des niveaux d’exposition différents : un extranet accessible depuis un réseau simulé public et une interface d’administration réservée au réseau privé.

Les équipes techniques devaient également pouvoir transférer des fichiers de manière chiffrée, avec des droits adaptés à leurs fonctions. L’ensemble devait être protégé par un filtrage réseau restrictif et un mécanisme de bannissement automatique.

Objectifs techniques

• Automatiser la création d’un environnement de test reproductible ;
• publier deux services web sur des interfaces et ports distincts ;
• chiffrer les communications web et les transferts de fichiers ;
• cloisonner les accès selon le réseau et le profil utilisateur ;
• détecter et bloquer les tentatives de connexion ou requêtes abusives.

Architecture retenue

Le laboratoire comprend trois machines virtuelles Ubuntu :

flowchart LR
    Public["Client réseau exposé<br/>150.10.0.11"]
    Private["Client réseau privé<br/>192.168.10.11"]

    subgraph Server["Serveur Ubuntu à double interface"]
        direction TB
        PublicFilter["Filtrage réseau exposé<br/>iptables + Fail2Ban"]
        PrivateFilter["Filtrage réseau privé<br/>iptables + Fail2Ban"]
        Extranet["Extranet<br/>150.10.0.10<br/>HTTP 80 / HTTPS 443"]
        Admin["Administration<br/>192.168.10.10<br/>HTTP 5501 / HTTPS 5502"]
        FTPS["Service FTPS<br/>Port 21 + ports passifs"]
    end

    Public -->|"HTTPS 443"| PublicFilter
    PublicFilter --> Extranet
    Private -->|"HTTPS 5502"| PrivateFilter
    Private -->|"FTPS"| PrivateFilter
    PrivateFilter --> Admin
    PrivateFilter --> FTPS

    style Public fill:#e8f4ff,stroke:#2563eb
    style Private fill:#ecfdf5,stroke:#059669
    style PublicFilter fill:#fff7ed,stroke:#ea580c
    style PrivateFilter fill:#fff7ed,stroke:#ea580c
    style Extranet fill:#f8fafc,stroke:#475569
    style Admin fill:#f8fafc,stroke:#475569
    style FTPS fill:#f8fafc,stroke:#475569

Le serveur possède une interface sur chaque réseau. Le filtrage Netfilter détermine les services accessibles en fonction de l’adresse source :

• l’extranet utilise les ports 80 et 443 sur le réseau exposé ;
• l’administration utilise les ports 5501 et 5502 sur le réseau privé ;
• le FTPS utilise le port 21 et une plage de ports passifs sur le réseau privé ;
• SSH reste limité au réseau d’administration et à l’accès technique de Vagrant.

Travaux réalisés

Infrastructure

• Définition des trois machines virtuelles avec Vagrant ;
• création de deux réseaux isolés avec des adresses IP fixes ;
• configuration d’un serveur à double interface et de deux clients de test.

Services web

• Configuration d’Apache et création d’une variante NGINX ;
• création de deux hôtes virtuels indépendants avec journaux séparés ;
• redirection des connexions HTTP vers HTTPS ;
• désactivation de l’indexation des répertoires.

Chiffrement

• Génération automatisée d’une clé privée, d’une demande de signature et d’un certificat autosigné de type wildcard ;
• utilisation du certificat par les services web et FTPS.

Gestion des transferts et des droits

• Configuration de vsftpd avec TLS et désactivation des connexions anonymes ;
• confinement des utilisateurs dans des espaces dédiés ;
• séparation des profils développeur et designer avec des groupes, des permissions Unix et des montages BIND.

Sécurité

• Application d’une politique iptables restrictive selon le réseau source ;
• persistance des règles après redémarrage ;
• activation de quatre jails Fail2Ban pour SSH, FTP et les deux services web.

Difficultés et choix techniques

Maintenir l’accès Vagrant avec une politique restrictive

Problème — Accès d’administration bloqué

Une politique DROP trop stricte pouvait bloquer la connexion utilisée par Vagrant.

Solution et résultat : une règle SSH dédiée à l’interface Vagrant maintient l’administration du serveur sans élargir les autres autorisations.

Partager les contenus sans exposer toute l’arborescence

Problème — Droits différents sur des contenus communs

Les développeurs et les designers devaient intervenir sur les mêmes sites sans disposer du même périmètre d’écriture.

Solution et résultat : des chroots distincts, des montages BIND et des groupes Unix donnent à chaque profil un accès direct aux seuls contenus autorisés.

Faire cohabiter plusieurs services sur un serveur

Problème — Séparer deux sites sur un même serveur

L’extranet public et l’administration privée partageaient la même machine sans devoir partager la même exposition.

Solution et résultat : chaque service est associé à une interface, à des ports et à un hôte virtuel précis, puis filtré selon son réseau source.

Résultats

Les communications web et FTP sont chiffrées, les accès sont filtrés selon leur zone réseau et les configurations sont regroupées dans des scripts de provisionnement.

Compétences démontrées

• Administration d’Ubuntu Server ;
• automatisation d’un laboratoire avec Vagrant ;
• configuration d’Apache et de NGINX ;
• installation et sécurisation d’un service FTPS ;
• création et utilisation de certificats TLS ;
• configuration d’un pare-feu avec iptables ;
• protection de services avec Fail2Ban ;
• gestion des comptes, groupes et permissions Linux ;
• segmentation réseau et diagnostic des flux ;
• rédaction de scripts Bash et de documentation technique.

Retour d’expérience

Ce projet m’a permis de comprendre qu’un service sécurisé repose sur plusieurs couches complémentaires. Le chiffrement protège les échanges, mais il doit être associé à un filtrage réseau précis, à des permissions minimales et à une surveillance des comportements anormaux.

La mise en place des deux réseaux a également montré l’importance de tester chaque flux depuis le bon point d’origine. Une règle correcte sur le papier peut empêcher l’administration du serveur ou autoriser un accès inattendu si elle n’est pas validée dans les conditions réelles du laboratoire.