Skip to content

1. Informations générales

  • Date de l’audit : 14 septembre 2025

  • Auditeur : Alex Balmes

  • Objectif : Vérifier la sécurité du VPS, identifier les vulnérabilités potentielles, documenter les contre-mesures.

  • Contexte technique :

  • OS : Ubuntu 24.04

  • Services exposés : Nginx-proxy, SSH

  • Ports ouverts : 80 , 443, port custom

2. Surface d’exposition

  • Domaines & sous-domaines :

alexbalmes.dev

www.alexbalmes.dev

portfolio.alexbalmes.dev

www.portfolio.alexbalmes.dev

dashboard.alexbalmes.dev

  • Services accessibles publiquement (Ports ouverts) : SSH (Port custom), Nginx reverse proxy (80, 443)

3. Authentification & accès

  • Accès SSH :

  • Méthode autorisée : uniquement par clé publique (✅ sécurisé, pas de brute force possible).

  • Authentification par mot de passe : désactivée (❌).

  • 2 Utilisateur :

User admin, accès privé pour développeur uniquement. Seul utilisateur au droit Sudo.

User ci/cd, clé pour Github Actions, Accès uniquement à un dossier pour la déploiment CI/CD des sites.

  • Port par défaut désactivé.

  • Alerte de connexion et monitorage en direct du nombres de session ouverte.

  • Accès sudo/root :

  • Accès root :❌ désactivé ( aucune connexion SSH root possible).

  • Sudo : ✅ Autorisé uniquement a l'user admin.

  • Journalisation: ✅ automatique dans /var/log/auth.log. et monitoré via auditd dans Grafana.

4. Conteneurs & services

  • 4.1 Isolation :

  • Les conteneurs sont exécutés avec leurs UID par défaut définis dans les images, garantissant qu’ils ne tournent pas en root inutilement.

  • Seule exception : nginx-proxy, exécuté en UID 0 (root) afin d’écouter sur les ports 80/443 (nécessaire).

  • Les services sont cloisonnés dans des réseaux Docker dédiés (nginx-proxy, website_monitoring) pour limiter la surface d’exposition.

  • Un reverse proxy Nginx centralise l’accès externe et gère le chiffrement TLS (v1.3).

  • 4.2 Images Docker :

  • Utilisation exclusive d’images officielles et maintenues (nginx, nginx-proxy, prometheus, grafana).

  • Toutes les images sont figées sur des versions précises (voir tableau ci-dessous), ce qui garantit la stabilité et évite les mises à jour non contrôlées via latest.

| Image | Version figée | Date de vérification |

|---------------------------------|-------------------|----------------------|

| nginx:1.29.1-alpine | 1.29.1 | 14/09/2025 |

| nginxproxy/nginx-proxy:1.8.0-alpine | nginx 1.29.1 (interne) | 14/09/2025 |

| nginxproxy/acme-companion:2.6.1 v,;| basé sur certbot | 14/09/2025 |

| prom/prometheus:v3.5.0 | 3.5.0 | 14/09/2025 |

| prom/blackbox-exporter:v0.27.0| 0.27.0 | 14/09/2025 |

| grafana/loki:3.5.5 | 3.5.5 | 14/09/2025 |

| grafana/promtail:3.5.5 | 3.5.5 | 14/09/2025 |

| grafana/grafana:12.1.1 | 12.1.1 | 14/09/2025 |

  • 4.3 Logs & monitoring :

  • Écoute des logs ubuntu et auditd.

  • On suis les connexion SSH et les commande sudo utilisées.

  • Récupération des logs avec promtail, envoyé a loki pour servir de data source a grafana

  • Dashboard Grafana personnalisé.

  • Et mise en place d'alerte de connexion via webhook discord (serveur dédié au VPS).

5. Réseau & pare-feu

  • Pare-feu activé :

  • Pare-feu système (UFW/iptables) désactivé.

  • Filtrage réseau assuré par le pare-feu de l’hébergeur du VPS.

  • Règles :

  • Ports autorisés :

  • TCP 80 (HTTP)

  • TCP 443 (HTTPS)

  • TCP * (SSH, port custom)

  • Protocole ICMP : activé (permet le ping et diagnostic réseau).

  • Tous les autres ports/protocoles sont fermés.

  • Fail2Ban / CrowdSec / WAF :

  • Pas de Fail2Ban ni CrowdSec, car SSH est protégé uniquement par clé publique (immunisé contre le brute force).

  • Pas de WAF, les flux HTTP(S) étant gérés uniquement par Nginx reverse proxy.

  • Sécurité TLS :

  • HTTPS activé sur l’ensemble des domaines et sous-domaines.

  • Certificats Let’s Encrypt générés et renouvelés automatiquement via acme-companion.

  • TLS 1.3 activé par défaut (chiffrement moderne et sécurisé).

6. Mises à jour & maintenance

Le serveur venant d’être récemment mis en place, l’OS (Ubuntu 24.04), Docker Engine, ainsi que l’ensemble des images Docker sont actuellement sur leurs dernières versions stables.

Toutes les images Docker sont figées sur des versions précises afin d’assurer la continuité de service et d’éviter les risques liés aux mises à jour non contrôlées. Cela garantit une reproductibilité des déploiements et une meilleure maîtrise de l’environnement.

Il n’existe pour l’instant pas d’automatisation pour la gestion des mises à jour disponibles (OS, Docker, images). Les mises à jour sont appliquées manuellement au besoin, ce qui permet un contrôle complet mais nécessite une vigilance régulière de l’administrateur.

7. Sauvegardes & résilience

  • ✅ Sauvegardes manuelles effectuées au moment de l’audit pour l’ensemble des conteneurs et données associées (volumes Docker : Prometheus, Grafana, Loki, etc.).

  • ❌ Pas encore de système de sauvegarde automatique planifié (cron, script, ou solution de backup externe).

  • ⚠️ Actuellement, la résilience dépend uniquement des snapshots ponctuels.

  • 🔄 Plan de restauration : redéploiement des conteneurs via docker compose + restauration des volumes sauvegardés.

8. Points d’amélioration

  • Pare-feu système : mettre en place un firewall local (UFW/nftables) en complément de celui de l’hébergeur pour ajouter une défense en profondeur.

  • WAF : envisager l’ajout d’un Web Application Firewall (ex : modsecurity avec Nginx ou CrowdSec) pour filtrer les requêtes HTTP malveillantes.

  • Automatisation des mises à jour : planifier des vérifications automatiques (cron, GitHub Actions) pour être notifié des nouvelles versions d’OS, de Docker et des images.

  • Sauvegardes automatiques : mettre en place un système de backup récurrent (script + stockage externe type S3/Backblaze) et tester régulièrement les restaurations.

  • Durcissement Docker : ajouter des limites de ressources (--memory, --cpus), désactiver les capacités Linux non nécessaires (cap_drop), et éviter l’utilisation de root dans les conteneurs quand c’est possible.

  • Audit régulier : programmer un nouvel audit complet tous les 6 mois pour suivre l’évolution de la sécurité.

Évaluation globale

La sécurité initiale du VPS est évaluée à Très prometteuse.

Le serveur bénéficie déjà d’une configuration solide : SSH sécurisé, gestion stricte des droits sudo, images Docker officielles et figées, TLS 1.3 activé, monitoring avancé via Grafana.

Les axes d’amélioration portent principalement sur l’automatisation des sauvegardes, la mise en place d’un firewall local en complément de celui de l’hébergeur, et l’ajout éventuel d’un WAF pour renforcer la protection HTTP(S).

Historique des audits

1er audit fait le 14/09/2025