Exercices corrigés de services Linux type E6 et E7 SISR

1. Les faiblesses.

2. Le server block corrigé, avec l'application déplacée pour que seul public/ soit servi, la configuration et le dépôt Git hors de la racine, un pool dédié et HTTPS :

server {
    listen 80;
    listen [::]:80;
    server_name suivi.sorbier-logistique.fr;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name suivi.sorbier-logistique.fr;

    ssl_certificate     /etc/letsencrypt/live/suivi.sorbier-logistique.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/suivi.sorbier-logistique.fr/privkey.pem;
    add_header Strict-Transport-Security "max-age=31536000" always;

    root /var/www/suivi/public;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.4-fpm-suivi.sock;
    }
    location ~ /\. {
        deny all;
    }
}

Et hors de Nginx : fichiers propriété de root, lisibles seulement par le compte du pool pour config.php (placé dans /var/www/suivi, au-dessus de public) ; display_errors = Off et journal des erreurs ; dépôt Git déployé ailleurs ou supprimé du serveur ; clé d'API renouvelée, puisqu'elle a pu être lue (chapitres 2, 4 et 6).

1. Les VLAN 10, 30 et 99 sont d'autres réseaux que le VLAN 20 de srv-glpi : ces trois flux traversent pfSense, qui doit les autoriser (règles sur les interfaces des VLAN 10, 30 et 99). srv-journaux est dans le même VLAN 20 : son flux ne traverse pas pfSense, seul le pare-feu local le filtre. Le script de sauvegarde ne quitte pas la machine.

2.

chain entree {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    ct state invalid drop
    iif "lo" accept
    icmp type echo-request accept
    icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-advert } accept
    ip saddr { 192.168.10.64/26, 192.168.10.128/27, 192.168.10.208/28 } tcp dport { 80, 443 } accept
    ip saddr 192.168.10.208/28 tcp dport 22 accept
    ip saddr 192.168.10.180 tcp dport 3306 accept
    limit rate 10/minute log prefix "nft-refus: "
}

Un ensemble écrit entre accolades directement dans la règle (ensemble anonyme) peut contenir des réseaux : nftables le gère sans déclaration préalable. Un ensemble nommé, comme @admin au chapitre 13, devient utile dès qu'il sert dans plusieurs règles.

3.

CREATE USER 'grafana_lecture'@'192.168.10.180' IDENTIFIED BY '…' REQUIRE SSL;
GRANT SELECT ON glpi.glpi_tickets TO 'grafana_lecture'@'192.168.10.180';
GRANT SELECT ON glpi.glpi_itilcategories TO 'grafana_lecture'@'192.168.10.180';

Le script de sauvegarde n'a pas besoin de compte : lancé en root sur le serveur, il se connecte au compte root@localhost de MariaDB par le socket Unix, sans mot de passe stocké nulle part (sudo mariadb-dump --single-transaction glpi). Côté serveur MariaDB : bind-address = 192.168.10.184 et require_secure_transport = ON pour que Grafana puisse se connecter en TLS (chapitre 5).

1. Les trois activités.

• 01:02 : un balayage automatisé (reconnaissance) : un robot teste en rafale des chemins connus d'applications vulnérables (WordPress, phpMyAdmin, fichiers .env).
• 02:15–02:58 : une attaque sur les mots de passe du formulaire de connexion, distribuée sur 214 adresses : force brute, ou bourrage d'identifiants (credential stuffing, essai de couples identifiant-mot de passe volés ailleurs).
• 03:20 : une tentative d'injection SQL : la valeur du paramètre colis contient de la syntaxe SQL, et l'application la recopie dans sa requête, puisque la base renvoie une erreur de syntaxe.

2. Réussite et vérifications.

• Balayage : réponses 404 et 403, rien de trouvé. Rien à faire, sinon vérifier qu'aucune requête de la série n'a reçu 200.
• Mots de passe : les réponses 200 ne disent pas si la connexion a réussi (la page de connexion répond 200 même en cas d'échec). Il faut lire les journaux de l'application : y a-t-il eu des connexions réussies pendant la fenêtre, et depuis quelles adresses ? Si oui, réinitialiser les mots de passe concernés et prévenir les clients.
• Injection : l'erreur 500 et l'exception PDO prouvent que la requête est construite par concaténation : la faille existe, même si cette tentative a échoué. Chercher dans les journaux d'autres requêtes de la même adresse ou du même type ayant reçu 200 (une injection réussie ne produit pas d'erreur), et vérifier dans la base les droits du compte de l'application et les données lisibles par lui.

3. Contre-mesures.

1. Architecture (dans le VLAN 21 APPLIS 192.168.21.0/24, passerelle 192.168.21.254) :

Le VLAN 20 192.168.10.176/28 n'a plus qu'une adresse libre, .187 : .182 à .186 sont pris par srv-collecte, le NAS, srv-glpi, srv-partages et le serveur de déploiement, .188 et .189 par les deux pare-feu en cluster (Pare-feu pfSense). Les quatre adresses vont donc dans le VLAN 21 APPLIS, ouvert pour les applications internes ; le pare-feu filtre les flux des postes vers ce VLAN comme vers le VLAN 20.

Pour limiter le nombre de machines, répartiteur et serveur web sont réunis sur chaque machine : HAProxy écoute en HTTPS sur l'adresse virtuelle et répartit vers les deux Nginx, qui écoutent sur un autre port (8080). L'authentification passe par l'annuaire en LDAPS ; le certificat vient de Sorbier-AC ; les journaux partent vers srv-journaux (rsyslog et agent Wazuh). La base reste un point unique de panne, à signaler comme limite (une réplication MariaDB la supprimerait, cours Haute disponibilité).

2. Rattachement à l'environnement exigé (liste complète) : service d'authentification (annuaire en LDAPS) ; SGBD (MariaDB) ; service rendu à l'utilisateur avec contraintes de sécurité et de haute disponibilité (l'intranet) ; accès sécurisé à un service interne (reverse proxy HTTPS) ; tolérance de panne (deux serveurs, adresse virtuelle VRRP) ; répartition de charge (HAProxy) ; supervision avec remontée d'alertes (Wazuh, et la supervision de l'adresse virtuelle) ; solution de sauvegarde (sauvegarde de la base) ; deux serveurs sur des systèmes différents, dont un libre (Debian ici, Windows Server pour l'annuaire).

3. Recette.

Chaque test est accompagné d'une capture ou d'une sortie de commande dans le dossier : c'est ce qui prouve, pendant l'entretien, que la solution fonctionne.

Étapes.

1. Créer la racine et une page : sudo mkdir -p /var/www/www/public puis une page index.html (fichiers propriété de root).
2. Écrire /etc/nginx/sites-available/www : un server block sur le port 80 avec server_name www.sorbier-logistique.fr;, root /var/www/www/public;, des journaux www.access.log et www.error.log, et le refus des fichiers cachés (chapitre 2).
3. Activer : sudo ln -s /etc/nginx/sites-available/www /etc/nginx/sites-enabled/, sudo nginx -t, sudo systemctl reload nginx.
4. Obtenir le certificat et passer en HTTPS : sudo certbot --nginx -d www.sorbier-logistique.fr, qui ajoute HTTPS et la redirection ; ajouter ensuite HSTS avec une durée courte pendant la recette.
5. Vérifier que les nouveaux journaux sont transmis : avec le motif /var/log/nginx/*.access.log de la configuration rsyslog (chapitre 12), rien à modifier ; ajouter le fichier au bloc localfile de l'agent Wazuh s'il est déclaré fichier par fichier, puis redémarrer l'agent.
6. Mettre à jour la documentation : fichier de site, certificat, date d'expiration supervisée.

Vérifications montrées.

• curl -sI http://www.sorbier-logistique.fr : 301 vers HTTPS.
• curl -sI https://www.sorbier-logistique.fr : 200, en-tête Strict-Transport-Security.
• openssl s_client -connect www.sorbier-logistique.fr:443 -servername www.sorbier-logistique.fr </dev/null | openssl x509 -noout -subject -issuer -dates : certificat Let's Encrypt pour ce nom, dates valides.
• sudo certbot renew --dry-run : renouvellement simulé réussi.
• curl -sI https://suivi.sorbier-logistique.fr : le site existant fonctionne toujours (on n'a rien cassé).
• Une requête sur le nouveau site, puis sa ligne retrouvée sur srv-journaux.

Ce que la commission observe aussi : nginx -t avant chaque rechargement, une sauvegarde de la configuration avant modification, et la capacité à expliquer chaque directive.