Aller au contenu

Audit infrastructure du serveur Feelbat au 7 juillet 2026

Date de l'audit : 2026-07-07

Statut : audit ponctuel clos

Périmètre : serveur de développement et de staging Feelbat

Objectif : documenter l'état observé du serveur à cette date, les risques identifiés et les recommandations associées.

Lecture du document

Ce fichier décrit une photographie de l'infrastructure au 7 juillet 2026. Il ne sert pas de registre de suivi. Les corrections réalisées après cette date doivent être documentées dans un nouvel audit, une page d'exploitation ou une décision d'architecture dédiée.

Résumé exécutif

Le serveur audité n'héberge pas la production Feelbat. Il supporte principalement les environnements de développement, de staging et quelques services historiques.

L'infrastructure repose sur des bases globalement saines : séparation des environnements, reverse proxy centralisé avec HAProxy, authentification SSH par clés publiques et isolation d'une partie des services via Docker.

Le principal risque identifié concerne l'absence de sauvegardes automatisées et de procédure de restauration testée. Les autres constats relèvent surtout de la dette technique : exposition directe de certains ports Docker, configuration HAProxy monolithique, services historiques encore présents et healthchecks obsolètes.

Synthèse des constats

Domaine État au 2026-07-07 Risque principal
Système Stable, mais très ancien uptime et mises à jour en attente. Correctifs système non appliqués.
Réseau Exposition globalement maîtrisée, mais plusieurs ports Docker sont publiés directement. Accès public à des services techniques.
Docker Architecture interne plutôt saine, avec des publications directes à revoir. Bases de données et outils techniques accessibles hors réseau privé.
HAProxy Reverse proxy fonctionnel, TLS moderne, configuration valide. Maintenabilité faible du fichier principal.
SSH Configuration robuste basée sur les clés publiques. Connexion directe root encore autorisée par clé.
Sauvegardes Aucun mécanisme automatisé identifié. Perte de données ou restauration impossible.
Monitoring Monitoring présent, mais certains healthchecks sont obsolètes. Signal de supervision peu fiable.

Priorités recommandées

  1. Mettre en place une stratégie de sauvegarde automatisée et tester une restauration.
  2. Appliquer les mises à jour système puis redémarrer le serveur pendant une fenêtre de maintenance.
  3. Archiver ou migrer les données Nextcloud avant tout décommissionnement.
  4. Réduire l'exposition directe des services techniques publiés par Docker.
  5. Réorganiser la configuration HAProxy pour améliorer sa maintenabilité.

1. État de l'hôte

Informations système

Élément État observé
Système Ubuntu 22.04.3 LTS
Uptime 1111 jours
RAM Environ 62 Gio
Stockage Aucune partition critique saturée

Constats

  • Le serveur n'a pas été redémarré depuis plus de trois ans.
  • Un redémarrage est requis pour appliquer des mises à jour système en attente.
  • Plus d'une centaine de mises à jour sont en attente, dont potentiellement des correctifs de sécurité.
  • Le noyau Linux observé est ancien.
  • Deux processus zombies sont présents.
  • Les ressources mémoire sont largement suffisantes.
  • L'espace disque ne présente pas de risque immédiat.

Analyse

L'état de l'hôte ne montre pas de saturation ou de défaillance immédiate. Le risque vient plutôt de l'accumulation de maintenance différée : noyau ancien, mises à jour non appliquées et absence de redémarrage depuis une longue période.

Un serveur de développement et de staging peut tolérer davantage de souplesse qu'un serveur de production, mais il reste un point d'appui important pour les équipes. Sa maintenance doit donc être planifiée et vérifiable.

Recommandations

  • Planifier une fenêtre de maintenance.
  • Appliquer les mises à jour système.
  • Redémarrer le serveur.
  • Vérifier l'origine des processus zombies après redémarrage.

2. Exposition réseau

Contexte

Le serveur audité héberge des environnements de développement et de staging. Aucun service de production n'a été identifié sur cet hôte.

Constats

  • Les services de production ne sont pas présents sur ce serveur.
  • PostgreSQL système écoute uniquement en local sur 127.0.0.1:5432.
  • Le résolveur DNS système est limité à localhost.
  • Plusieurs ports Docker sont publiés directement sur toutes les interfaces réseau avec un binding 0.0.0.0.
  • Le service FTP historique a été retiré de l'exposition réseau pendant l'audit.
  • Une instance Nextcloud reste déployée et exposée. Elle semble abandonnée côté utilisateurs, mais contient environ 303 Go de données historiques, principalement marketing.

Firewall et Docker

UFW est actif avec une politique par défaut restrictive : refus des connexions entrantes et autorisation des connexions sortantes.

Cette protection ne couvre pas automatiquement tous les ports publiés par Docker. Docker installe ses propres règles NAT pour exposer les conteneurs, et la chaîne DOCKER-USER renvoie actuellement le trafic sans filtrage spécifique.

Le résultat est important : un service publié par Docker sur 0.0.0.0 peut être accessible depuis Internet, même si la politique UFW paraît restrictive.

Analyse

L'exposition de certains services est normale pour des environnements de développement et de staging. Elle doit cependant être volontaire, documentée et limitée aux usages nécessaires.

Le point sensible n'est pas la présence de Docker, mais l'absence de justification explicite pour chaque port publié. Les bases de données, interfaces d'administration et outils techniques devraient être rendus privés dès que leur exposition publique n'est pas indispensable.

Recommandations

  • Cartographier chaque port publié par Docker et documenter son usage.
  • Limiter les publications aux services réellement nécessaires.
  • Utiliser un binding sur 127.0.0.1 lorsqu'un service est uniquement consommé par HAProxy, un tunnel SSH ou un composant local.
  • Ajouter des règles explicites dans DOCKER-USER si un filtrage hôte est nécessaire.
  • Traiter Nextcloud comme un sujet d'archivage de données avant de le traiter comme un simple service à supprimer.

3. Services Docker

Ports publiés

Service Port(s) publié(s) Observation
Gateway Dev 17500 Exposition volontaire pour les tests.
Dashboard Dev 17505 Exposition directe à documenter.
Web Connector Dev 17506 Exposition directe à justifier.
Mailcatcher Dev 17580, 1025 Interface Web et SMTP exposés publiquement.
PostgreSQL Dev 17601, 17603 Bases de données publiées directement.
Gateway Staging 18500 Exposition volontaire pour les validations.
Dashboard Staging 18505 Exposition directe.
PostgreSQL Staging 18601, 18603 Bases de données publiées directement.
InfluxDB Dev / Staging 8086, 8087 Exposition directe à confirmer selon les besoins.

Points positifs

  • Kafka et ZooKeeper ne sont pas exposés publiquement.
  • Les microservices internes ne publient généralement pas de ports directement.
  • L'architecture repose majoritairement sur des réseaux Docker dédiés par environnement.

Analyse

L'isolation interne des microservices est cohérente avec une infrastructure Docker multi-environnements. Le risque se situe surtout sur les ports explicitement publiés par les conteneurs.

Les bases de données, Mailcatcher et InfluxDB sont des services techniques. Leur exposition directe doit être exceptionnelle, justifiée et idéalement remplacée par un accès plus contrôlé.

Recommandations

  • Réduire le nombre de ports publiés.
  • Éviter de publier directement les bases de données et outils techniques.
  • Privilégier un VPN, un tunnel SSH, un reverse proxy authentifié ou un réseau privé pour les accès techniques.
  • Conserver uniquement les expositions nécessaires aux développeurs et aux validations de staging.

4. Reverse proxy HAProxy

Schéma d'exposition

flowchart TD
    internet((Internet))

    internet -->|80 / 443| haproxy[HAProxy]

    subgraph reverse_proxy[Reverse Proxy]
        haproxy
    end

    haproxy -->|dev.feelbat.tech| dev_gateway[Gateway Dev\nlocalhost:17500]
    haproxy -->|dev-dashboard.feelbat.tech| dev_dashboard[Dashboard Dev\nlocalhost:17505]
    haproxy -->|dev-manager.feelbat.tech| dev_manager[Manager Dev\nlocalhost:17501]
    haproxy -->|dev-sigfoxco.feelbat.tech| dev_connector[Connector Dev\nlocalhost:17506]
    haproxy -->|staging.feelbat.tech| staging_gateway[Gateway Staging\nlocalhost:18500]
    haproxy -->|staging-dashboard.feelbat.tech| staging_dashboard[Dashboard Staging\nlocalhost:18505]
    haproxy -->|staging-sigfoxco.feelbat.tech| staging_connector[Connector Staging\nlocalhost:18506]
    haproxy -->|admin-staging.feelbat.tech| admin_dashboard[Admin Dashboard\nlocalhost:18515]
    haproxy -->|staging-public-api.feelbat.tech| public_api[Public API Staging\nlocalhost:18508]
    haproxy -->|dev-influxdb.feelbat.tech| influxdb[InfluxDB Dev\nlocalhost:8086]
    haproxy -->|dev-kafkaui.feelbat.tech| kafka_ui[Kafka UI Dev\nlocalhost:17504]
    haproxy -->|kutt.feelbat.tech| kutt[Kutt\nlocalhost:17510]
    haproxy -.->|nextcloud.feelbat.tech\nà archiver ou migrer| nextcloud[Nextcloud\nlocalhost:11000]

    subgraph docker[Services Docker et locaux]
        dev_gateway
        dev_dashboard
        dev_manager
        dev_connector
        staging_gateway
        staging_dashboard
        staging_connector
        admin_dashboard
        public_api
        influxdb
        kafka_ui
        kutt
        nextcloud
    end

    ftp[FTP historique\n21 / 2121]
    haproxy -. retiré pendant l'audit .-> ftp

    classDef deprecated stroke-dasharray: 5 5
    class nextcloud,ftp deprecated

Constats

  • HAProxy centralise l'exposition HTTP et HTTPS des environnements de développement et de staging.
  • La configuration HAProxy est valide d'après haproxy -c.
  • Les connexions TLS sont limitées à TLS 1.2 et supérieur.
  • Les certificats Let's Encrypt sont correctement chargés et utilisés par le frontend HTTPS.
  • La configuration est regroupée dans un fichier unique de grande taille.
  • Ce fichier mélange routage, redirections SEO, certificats, ACL et backends.
  • Les blocs HAProxy liés au FTP ont été supprimés pendant l'audit.
  • Nextcloud reste référencé dans HAProxy.
  • HAProxy signale plusieurs avertissements liés à l'ordre des directives redirect et use_backend.

Analyse

HAProxy joue correctement son rôle de point d'entrée HTTP/HTTPS. La base technique est saine : configuration valide, TLS moderne et gestion centralisée des certificats.

Le risque principal est maintenant la maintenabilité. Le fichier de configuration principal concentre trop de responsabilités. Cette organisation augmente le risque d'erreur lors d'une modification future, notamment sur les redirections et les backends historiques.

Recommandations

  • Réorganiser la configuration HAProxy en fichiers thématiques : frontends, backends, redirections, services actifs et services historiques.
  • Corriger les avertissements redirect / use_backend afin que l'ordre d'exécution soit explicite.
  • Réaliser un inventaire régulier des domaines et certificats.
  • Ne retirer Nextcloud de HAProxy qu'après validation métier et archivage ou migration des données.

5. Services historiques

FTP

Le service FTP historique a été identifié comme obsolète pendant l'audit.

Les vérifications réalisées n'ont montré aucun usage légitime récent : aucun login réussi sur l'année écoulée, aucun utilisateur FTP métier identifié et aucun répertoire FTP utilisateur identifié. Les journaux observés contenaient uniquement des tentatives anonymes échouées, compatibles avec des scans automatisés.

Actions réalisées pendant l'audit :

  • arrêt du service vsftpd ;
  • vérification de l'absence d'écoute sur le port 21 ;
  • sauvegarde préalable de /etc/haproxy/haproxy.cfg ;
  • suppression des blocs HAProxy ftp_frontend et ftp_backend ;
  • validation de la configuration HAProxy avec haproxy -c ;
  • rechargement contrôlé de HAProxy ;
  • vérification de l'absence d'écoute sur le port 2121 ;
  • tests fonctionnels des domaines principaux après modification.

État observé après action :

  • le port FTP direct 21 n'est plus exposé par vsftpd ;
  • le port HAProxy 2121 n'est plus exposé ;
  • les routes HAProxy FTP sont supprimées ;
  • les services HTTP/HTTPS principaux sont restés opérationnels après rechargement de HAProxy.

Recommandations restantes :

  • purger définitivement le paquet vsftpd ;
  • supprimer les règles UFW liées au FTP, notamment 2121/tcp et la plage passive 40000:40100/tcp ;
  • vérifier qu'aucune entrée DNS historique liée au FTP ne subsiste.

Nextcloud

L'instance Nextcloud a été investiguée en vue d'un éventuel décommissionnement. L'analyse montre que l'application semble abandonnée côté utilisateurs, mais qu'elle contient encore un volume important de données historiques.

Constats :

  • Nextcloud AIO est encore déployé avec plusieurs conteneurs associés.
  • Le service reste exposé via HAProxy sur nextcloud.feelbat.tech.
  • Le backend Apache Nextcloud reste accessible localement.
  • Le conteneur master expose aussi le port 17400 sur toutes les interfaces.
  • Les données persistantes sont stockées dans /media/ncdata/nextcloud.
  • Le volume de données observé est d'environ 303 Go.
  • 27 utilisateurs Nextcloud sont configurés.
  • Les derniers logins humains identifiés datent de décembre 2024 et janvier 2025.
  • Des traces récentes compatibles avec des scans automatisés et quelques tentatives de synchronisation client ont été observées.
  • Le compte admin concentre environ 288 Go de données.
  • Le dossier /media/ncdata/nextcloud/admin/files/Marketing représente environ 285 Go.
  • Les fichiers observés suggèrent un usage de dépôt documentaire marketing ou commercial.

Analyse :

La suppression directe de Nextcloud présenterait un risque de perte de données métier. Le sujet doit donc être traité comme une migration ou un archivage documentaire avant tout décommissionnement technique.

Recommandations :

  • Identifier le propriétaire métier des données marketing stockées dans Nextcloud.
  • Valider officiellement que l'application Nextcloud n'est plus utilisée.
  • Choisir une destination d'archivage ou de migration adaptée : NAS, stockage objet, GED, SharePoint ou autre solution validée.
  • Réaliser une copie complète des données avant arrêt définitif.
  • Arrêter le service pendant une période d'observation avant suppression complète.
  • Supprimer ensuite les conteneurs, volumes, règles HAProxy, certificats et entrées DNS associés.

6. Sécurité des accès

SSH

Constats :

  • Le serveur utilise un port SSH dédié : 15320.
  • L'authentification par mot de passe est désactivée avec PasswordAuthentication no.
  • L'authentification interactive est désactivée avec KbdInteractiveAuthentication.
  • L'authentification par clé publique est activée avec PubkeyAuthentication yes.
  • Un compte dédié au déploiement, deploy, est utilisé à la place du compte root pour les opérations courantes.
  • Les connexions SSH du compte root restent autorisées via une authentification par clé avec PermitRootLogin without-password.
  • X11Forwarding est activé.

Analyse :

La configuration SSH est robuste. Elle repose sur les bonnes pratiques attendues : clés publiques, désactivation des mots de passe et usage d'un compte de déploiement dédié.

L'autorisation de connexions directes en tant que root par clé SSH n'est pas une vulnérabilité immédiate, mais elle n'apporte plus de bénéfice opérationnel significatif si les accès administratifs passent par des comptes nominatifs et sudo.

Recommandations :

  • Positionner PermitRootLogin no.
  • Désactiver X11Forwarding si cette fonctionnalité n'est pas utilisée.

Privilèges locaux

Constats :

  • Le nombre de comptes disposant des privilèges sudo est limité.
  • Le compte deploy ne dispose pas des droits sudo.
  • Le compte deploy est membre du groupe docker.

Analyse :

L'appartenance au groupe docker permet de contrôler le démon Docker. Elle doit être considérée comme un privilège élevé, potentiellement équivalent à un accès administrateur sur l'hôte.

Cette configuration est cohérente avec le rôle du compte deploy, mais elle doit rester limitée aux comptes ayant un besoin opérationnel clair.

Recommandations :

  • Vérifier régulièrement la liste des membres des groupes sudo et docker.
  • Limiter l'appartenance au groupe docker aux comptes de confiance.
  • Documenter explicitement pourquoi le compte deploy appartient au groupe docker.

7. Sauvegardes

Constats

  • Aucune stratégie de sauvegarde n'a été identifiée sur le serveur.
  • Aucun mécanisme de sauvegarde automatisée n'a été identifié.
  • Aucune procédure de restauration n'existe à ce jour.

Analyse

L'absence de sauvegardes constitue le risque le plus important de cet audit.

Même si le serveur n'héberge pas la production, une perte des bases de données, volumes Docker, configurations ou données historiques pourrait perturber fortement les développements et les validations.

Le risque ne concerne pas seulement la sauvegarde. Sans test de restauration, il n'existe aucune preuve que l'infrastructure puisse être reconstruite correctement après incident.

Recommandations

  • Sauvegarder les bases PostgreSQL.
  • Sauvegarder les données InfluxDB si elles doivent être conservées.
  • Sauvegarder les volumes Docker critiques.
  • Sauvegarder les fichiers de configuration nécessaires à la reconstruction du serveur.
  • Externaliser les sauvegardes sur un support distinct du serveur : NAS, stockage objet ou second serveur.
  • Définir une politique de rétention.
  • Documenter et tester une procédure complète de restauration.

8. Monitoring

Constats

Plusieurs conteneurs de staging apparaissent avec un état unhealthy.

Après vérification, ces états semblent dus à des healthchecks devenus obsolètes. Ils ne reflètent pas nécessairement un dysfonctionnement réel des services.

Analyse

Un healthcheck obsolète réduit la confiance dans le monitoring. Il peut masquer un incident réel ou habituer les équipes à ignorer des alertes.

Recommandation

Mettre à jour les healthchecks afin qu'ils représentent fidèlement l'état de santé réel des applications.

Conclusion

Au 7 juillet 2026, aucune vulnérabilité critique immédiatement exploitable n'a été identifiée dans le périmètre observé.

Le serveur présente toutefois une dette d'exploitation significative. Les points les plus importants sont l'absence de sauvegardes automatisées, la maintenance système différée, l'exposition directe de certains services Docker et la présence de services historiques à traiter proprement.

La priorité doit être donnée aux sujets qui réduisent le risque de perte de données et améliorent la capacité de reprise : sauvegardes, restauration, mises à jour système et clarification des services réellement exposés.