[{"data":1,"prerenderedAt":191},["ShallowReactive",2],{"seo-verification":3,"blog-linux-hardening-vps-checklist-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"id":7,"slug":8,"slugs":9,"title":13,"excerpt":14,"readTime":15,"views":16,"isPinned":17,"publishedAt":18,"category":19,"categories":25,"featuredImage":27,"bgImage":28,"posterImage":29,"relatedSolution":27,"intro":30,"sections":31,"ctaTitle":142,"ctaBody":143,"ctaButton":144,"ctaUrl":145,"relatedPosts":146},317,"linux-hardening-vps-checklist",{"fr":8,"en":10,"ar":11,"es":12},"linux-vps-hardening-checklist-for-agencies","قائمة-تصليب-خادم-لينكس-للوكالات-بعد-التسليم","hardening-linux-vps-checklist-para-agencias-tras-la-entrega","Durcissement Linux VPS : checklist agence après livraison","Checklist de durcissement Linux pour agences : auditd, sudo, SSH par clé, UFW, fail2ban et désactivation root — traçabilité et runbook par client.",11,0,false,"2026-08-30T00:00:00+00:00",{"id":20,"name":21,"slug":22,"color":23,"icon":24},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[26],{"id":20,"name":21,"slug":22,"color":23,"icon":24},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Flinux-hardening-vps-checklist-poster.svg","Votre agence livre un VPS et chaque technicien applique « à peu près la même chose » — sans runbook écrit, sans trace. Le jour d'un incident, vous ne pouvez pas prouver que la configuration de sécurité convenue a été posée. Ce guide part du point où le tutoriel individuel s'arrête : standardisation, délégation et traçabilité pour un parc de serveurs clients.",[32,36,46,49,59,68,77,83,89,98,101,133,136,139],{"type":33,"title":34,"body":35},"h2","Pourquoi un runbook formalisé change tout pour une agence","Un développeur isolé peut appliquer mentalement cinq commandes après chaque livraison. Une agence ne le peut pas : plusieurs techniciens, des dizaines de VPS clients, des nuits de garde tournantes. Quand un client signale un accès suspect six mois après la mise en production, la question n'est pas « est-ce que vous avez sécurisé le serveur ? » mais « pouvez-vous le prouver ? »\n\nLa traçabilité est devenue une exigence contractuelle et réglementaire. La directive **NIS2** (transposition en droit national en cours) et le **RGPD** imposent aux prestataires qui traitent des données de personnes physiques de documenter les mesures de sécurité mises en œuvre. Sans runbook versionné et sans journal `auditd`, votre agence ne dispose d'aucune pièce opposable.\n\nCe guide ne redécrit pas l'installation de fail2ban ou d'UFW — les articles \u003Ca href=\"\u002Fblog\u002Fproteger-vps-fail2ban\">Protéger un VPS avec fail2ban\u003C\u002Fa> et \u003Ca href=\"\u002Fblog\u002Fpare-feu-ufw-vps\">Pare-feu UFW sur VPS\u003C\u002Fa> le font en détail. Il part du niveau supérieur : comment standardiser, déléguer et tracer ces gestes à l'échelle d'un portefeuille clients.",{"type":37,"title":38,"items":39},"ul","Ce que ce runbook apporte à votre agence",[40,41,42,43,44,45],"**Reproductibilité** : chaque technicien exécute exactement les mêmes étapes, dans le même ordre, sur chaque nouveau VPS client.","**Traçabilité** : `auditd` enregistre qui a fait quoi, quand, sur quelle commande — preuve conservable en cas d'incident ou d'audit client.","**Délégation sans risque** : un junior peut livrer un serveur durci sans avoir à improviser, parce que le runbook contient les décisions à sa place.","**Défense contractuelle** : une clause de sécurité dans votre contrat de maintenance n'est défendable qu'avec un journal d'exécution daté.","**Réduction de la surface d'attaque** : la checklist élimine les oublis classiques — root SSH laissé ouvert, auditd non activé — qui sont les points d'entrée les plus exploités.","**Cohérence inter-clients** : même base sécurisée pour tous, différences uniquement là où le cahier des charges client l'exige.",{"type":33,"title":47,"body":48},"Prérequis et périmètre de la checklist","Cette checklist cible **Ubuntu 24.04 LTS** et **Debian 12** (Bookworm), les deux distributions les plus courantes sur VPS en 2026. Les commandes ont été vérifiées sur ces systèmes ; sur AlmaLinux ou Rocky Linux, les noms de paquets et les chemins de service diffèrent.\n\nPrérequis minimaux du VPS : 1 vCPU, 1 Go de RAM (2 Go recommandés si fail2ban et auditd tournent ensemble), 20 Go SSD. ServOrbit livre chaque VPS avec accès root SSH immédiat et console KVM incluse, ce qui permet d'appliquer ce runbook dès la première minute — sans passer par un ticket d'accès intermédiaire à l'hébergeur.\n\nLa checklist est organisée en **sept blocs**, dans l'ordre d'application. Elle s'arrête au périmètre système de base : la sécurisation des applications (backoffice exposé, surfaces d'attaque applicatives) est traitée séparément dans \u003Ca href=\"\u002Fblog\u002Fbackoffice-vps-surfaces-attaque-oubliees-2026\">Backoffice exposé : les surfaces d'attaque oubliées sur VPS\u003C\u002Fa>.",{"type":50,"title":51,"steps":52},"steps","Bloc 1 — Mises à jour et inventaire initial",[53,56],{"title":54,"body":55},"Mise à jour du système et inventaire","La première action après connexion root est d'amener le système à son niveau de correctifs courant.\n\n```bash\napt update && apt upgrade -y\napt install -y auditd audispd-plugins curl gnupg2 ufw fail2ban\n```\n\nNotez dans votre runbook : la date, la version du noyau (`uname -r`), et la liste des paquets installés (`dpkg -l > \u002Froot\u002Finventory-$(date +%F).txt`). Ce fichier d'inventaire constitue la **baseline** du serveur à la livraison — c'est la pièce que vous produirez si un client conteste l'état initial de sa machine.\n\n**Référence CIS Benchmark** : contrôle CIS 1.1 (Ubuntu Linux 24.04 LTS Benchmark, section « Initial Setup »).",{"title":57,"body":58},"Activer les mises à jour automatiques de sécurité","```bash\napt install -y unattended-upgrades\ndpkg-reconfigure --priority=low unattended-upgrades\n```\n\nVérifiez que la ligne `Unattended-Upgrade::Allowed-Origins` inclut bien `${distro_id}:${distro_codename}-security`. Pour un parc clients, activez les mises à jour automatiques et planifiez une revue mensuelle des mises à jour non-sécurité — elles demandent une validation humaine.\n\n**Référence CIS** : contrôle CIS 1.9 (Ensure updates, patches, and additional security software are installed).",{"type":50,"title":60,"steps":61},"Bloc 2 — Utilisateur sudo et verrouillage root",[62,65],{"title":63,"body":64},"Créer un utilisateur dédié à l'administration","Ne jamais utiliser `root` pour les tâches courantes. Créez un compte nominatif par technicien ou un compte de service agence :\n\n```bash\nuseradd -m -s \u002Fbin\u002Fbash adminagence\nusermod -aG sudo adminagence\npasswd adminagence\n```\n\n**Conseil agence** : utilisez un nom de compte identifiable dans les logs (`jean.dupont` ou `agency-admin`), pas un générique `admin`. Quand `auditd` trace une action, le compte exécutant est enregistré — un nom générique rend l'audit inutilisable.",{"title":66,"body":67},"Désactiver le login root par SSH","```bash\nsed -i 's\u002F^#\\?PermitRootLogin.*\u002FPermitRootLogin no\u002F' \u002Fetc\u002Fssh\u002Fsshd_config\ngrep PermitRootLogin \u002Fetc\u002Fssh\u002Fsshd_config\n```\n\nAttention : ne rechargez `sshd` qu'**après** avoir vérifié que votre utilisateur sudo peut se connecter et exécuter `sudo su`. Sinon vous vous bloquez hors du serveur.\n\n**Référence CIS** : contrôle CIS 5.2.8 (Ensure SSH root login is disabled).",{"type":50,"title":69,"steps":70},"Bloc 3 — Authentification par clé SSH",[71,74],{"title":72,"body":73},"Déployer la clé publique de l'agence","```bash\nmkdir -p \u002Fhome\u002Fadminagence\u002F.ssh\nchmod 700 \u002Fhome\u002Fadminagence\u002F.ssh\necho \"\u003CCLE_PUBLIQUE_AGENCE>\" >> \u002Fhome\u002Fadminagence\u002F.ssh\u002Fauthorized_keys\nchmod 600 \u002Fhome\u002Fadminagence\u002F.ssh\u002Fauthorized_keys\nchown -R adminagence:adminagence \u002Fhome\u002Fadminagence\u002F.ssh\n```\n\n**Conseil agence** : maintenez un dépôt de clés publiques versionné (un fichier par technicien, rotation annuelle). Toute clé déployée sur un VPS client doit être référencée dans ce dépôt — c'est ce qui vous permet de révoquer un accès quand un collaborateur quitte l'équipe.",{"title":75,"body":76},"Désactiver l'authentification par mot de passe","Une fois la clé vérifiée (testez depuis un autre terminal avant de valider) :\n\n```bash\nsed -i 's\u002F^#\\?PasswordAuthentication.*\u002FPasswordAuthentication no\u002F' \u002Fetc\u002Fssh\u002Fsshd_config\nsed -i 's\u002F^#\\?ChallengeResponseAuthentication.*\u002FChallengeResponseAuthentication no\u002F' \u002Fetc\u002Fssh\u002Fsshd_config\nsystemctl reload sshd\n```\n\n**Référence CIS** : contrôle CIS 5.2.11 (Ensure only approved MAC algorithms are used) et CIS 5.2.19 (Ensure SSH PasswordAuthentication is disabled).",{"type":50,"title":78,"steps":79},"Bloc 4 — Pare-feu UFW",[80],{"title":81,"body":82},"Configurer UFW avec une politique de refus par défaut","```bash\nufw default deny incoming\nufw default allow outgoing\nufw allow 22\u002Ftcp comment 'SSH agence'\nufw allow 80\u002Ftcp comment 'HTTP'\nufw allow 443\u002Ftcp comment 'HTTPS'\nufw --force enable\nufw status verbose\n```\n\nN'ouvrez que les ports réellement utilisés par le projet client. Si l'application du client n'utilise pas de port email direct, ne l'ouvrez pas.\n\nPour l'installation de fail2ban et les options avancées d'UFW, consultez les guides dédiés : \u003Ca href=\"\u002Fblog\u002Fproteger-vps-fail2ban\">Protéger un VPS avec fail2ban\u003C\u002Fa> et \u003Ca href=\"\u002Fblog\u002Fpare-feu-ufw-vps\">Pare-feu UFW sur VPS\u003C\u002Fa>.\n\n**Référence CIS** : contrôle CIS 3.5.1 (Ensure a firewall package is installed).",{"type":50,"title":84,"steps":85},"Bloc 5 — fail2ban",[86],{"title":87,"body":88},"Activer fail2ban avec la jail SSH","```bash\ncp \u002Fetc\u002Ffail2ban\u002Fjail.conf \u002Fetc\u002Ffail2ban\u002Fjail.local\n```\n\nÉditez `\u002Fetc\u002Ffail2ban\u002Fjail.local` et ajustez la section `[sshd]` :\n\n```bash\n[sshd]\nenabled = true\nmaxretry = 5\nfindtime = 600\nbantime = 3600\n```\n\n```bash\nsystemctl enable fail2ban\nsystemctl start fail2ban\nfail2ban-client status sshd\n```\n\nPour un parc clients, envisagez \u003Ca href=\"\u002Fblog\u002Fsecuriser-vps-crowdsec\">CrowdSec\u003C\u002Fa> en remplacement ou en complément : sa blocklist communautaire mutualise l'intelligence de milliers de serveurs.",{"type":50,"title":90,"steps":91},"Bloc 6 — auditd : le journal de traçabilité",[92,95],{"title":93,"body":94},"Activer auditd et configurer les règles minimales","`auditd` est le composant que les agences oublient le plus souvent — et pourtant c'est lui qui fournit la preuve opposable en cas d'incident.\n\n```bash\nsystemctl enable auditd\nsystemctl start auditd\n```\n\nCréez un fichier de règles agence dans `\u002Fetc\u002Faudit\u002Frules.d\u002Fagency.rules` :\n\n```bash\n# Tracer toutes les élévations de privilèges\n-w \u002Fetc\u002Fsudoers -p wa -k sudoers_changes\n-w \u002Fetc\u002Fsudoers.d\u002F -p wa -k sudoers_changes\n\n# Tracer les connexions SSH\n-w \u002Fvar\u002Flog\u002Fauth.log -p wa -k auth_log\n\n# Tracer les modifications de fichiers de configuration système\n-w \u002Fetc\u002Fssh\u002Fsshd_config -p wa -k sshd_config\n-w \u002Fetc\u002Fpasswd -p wa -k passwd_changes\n-w \u002Fetc\u002Fshadow -p wa -k shadow_changes\n\n# Tracer les commandes exécutées en root\n-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands\n```\n\n```bash\naugenrules --load\nauditctl -l\n```\n\n**Référence CIS** : contrôle CIS 4.1.1 (Ensure auditing is enabled) et CIS 4.1.3 (Ensure events that modify date and time information are collected).",{"title":96,"body":97},"Exporter et conserver les logs auditd","Les logs `auditd` doivent être conservés hors du serveur pour être opposables. Configurez un export vers votre système centralisé (rsyslog, Loki, ou un simple `rsync` quotidien vers un stockage agence) :\n\n```bash\n# Exemple : export rsyslog vers collecteur agence\necho ':programname, isequal, \"auditd\" @\u003CIP_COLLECTEUR_AGENCE>:514' \\\n  >> \u002Fetc\u002Frsyslog.d\u002F99-auditd-remote.conf\nsystemctl restart rsyslog\n```\n\nConservez au minimum 90 jours de logs. Le RGPD ne fixe pas de durée minimale pour les logs de sécurité, mais les référentiels comme le **CIS Controls v8** (contrôle 8.3) recommandent au moins 90 jours sur site et 1 an en archive froide.",{"type":33,"title":99,"body":100},"Bloc 7 — Vérification finale et fiche de livraison","Une fois les six blocs précédents exécutés, auditez l'état du serveur avant de remettre les accès au client :\n\n```bash\n# Vérifier les services actifs\nsystemctl is-active ufw fail2ban auditd sshd\n\n# Vérifier que root ne peut pas se connecter en SSH\ngrep PermitRootLogin \u002Fetc\u002Fssh\u002Fsshd_config\n\n# Vérifier les règles UFW\nufw status verbose\n\n# Vérifier les règles auditd chargées\nauditctl -l\n\n# Vérifier les dernières connexions\nlast -n 10\n```\n\nProduisez une **fiche de livraison** datée et signée (même par email) qui liste les mesures appliquées, les versions des paquets de sécurité installés, et l'emplacement du collecteur de logs. C'est ce document que votre client signe et qui constitue la preuve contractuelle de la configuration initiale.\n\nLa fiche de livraison n'est pas une formalité : un client victime d'une intrusion deux ans après la mise en production demandera à votre agence de justifier l'état du serveur à la livraison. Sans ce document, la charge de la preuve se retourne.",{"type":102,"title":103,"headers":104,"rows":108},"comparison","Runbook agence vs configuration au jugé : ce que ça change",[105,106,107],"Critère","Configuration au jugé","Runbook standardisé",[109,113,117,121,125,129],[110,111,112],"Reproductibilité","Dépend du technicien présent","Identique à chaque livraison",[114,115,116],"Traçabilité auditd","Rarement activée, config variable","Activée et configurée systématiquement",[118,119,120],"Preuve en cas d'incident","Aucune pièce opposable","Fiche de livraison datée + logs centralisés",[122,123,124],"Délégation à un junior","Risquée (oublis possibles)","Possible avec le runbook comme guide",[126,127,128],"Rotation de clé SSH","Manuelle et oubliée","Procédure écrite, dépôt versionné",[130,131,132],"Conformité NIS2 \u002F RGPD","Non documentée","Documentée et reproductible",{"type":134,"body":135},"tip","**Conseil d'audit mensuel.** Une fois par mois, rejouez les vérifications finales du Bloc 7 sur chaque VPS client actif et archivez la sortie. Un diff entre deux audits consécutifs révèle immédiatement une modification non autorisée : un port ouvert en plus, un service fail2ban stoppé, une règle auditd manquante. Cet audit prend moins de cinq minutes par serveur quand les commandes sont dans un script.",{"type":33,"title":137,"body":138},"Dépannage : erreurs fréquentes lors de l'application du runbook","**Erreur 1 — `sshd` refuse de démarrer après modification de `sshd_config`**\nMessage : `sshd: \u002Fetc\u002Fssh\u002Fsshd_config line 42: unsupported option`\nCause : une directive dépréciée ou mal syntaxée. Vérifiez avec `sshd -t` avant de recharger le service. Sur Ubuntu 24.04, `ChallengeResponseAuthentication` est remplacée par `KbdInteractiveAuthentication`.\n\n```bash\nsshd -t && systemctl reload sshd\n```\n\n**Erreur 2 — UFW bloque votre propre connexion SSH**\nMessage : la session SSH se fige après `ufw enable`.\nCause : la règle SSH n'a pas été ajoutée avant l'activation. Passez par la console KVM ServOrbit pour accéder au serveur sans SSH, puis exécutez `ufw allow 22\u002Ftcp` et `ufw reload`.\n\n**Erreur 3 — `auditd` démarre mais `auditctl -l` retourne une liste vide**\nMessage : `List of rules:` suivi de rien.\nCause : le fichier de règles n'est pas chargé. Vérifiez que votre fichier `.rules` est bien dans `\u002Fetc\u002Faudit\u002Frules.d\u002F` et exécutez `augenrules --load`.\n\n**Erreur 4 — fail2ban ne banne pas malgré plusieurs tentatives échouées**\nMessage : `fail2ban-client status sshd` montre `Currently banned: 0` après 10 tentatives.\nCause : le chemin du journal SSH a changé. Sur Debian 12 et Ubuntu 24.04 avec journald, le backend de fail2ban doit être `systemd` dans `jail.local` : `backend = systemd`.\n\n**Erreur 5 — `unattended-upgrades` redémarre des services en cours de production**\nCause : la configuration par défaut redémarre automatiquement les services après mise à jour. Pour un VPS client en production, désactivez le redémarrage automatique et planifiez une fenêtre de maintenance :\n\n```bash\n# Dans \u002Fetc\u002Fapt\u002Fapt.conf.d\u002F50unattended-upgrades\nUnattended-Upgrade::Automatic-Reboot \"false\";\n```",{"type":33,"title":140,"body":141},"Aller plus loin : bastionnage et surveillance continue","Cette checklist couvre le **niveau 1** du durcissement système. Pour un parc clients qui exige un niveau de sécurité supérieur :\n\n- **Bastion SSH** : centralisez tous les accès via un point d'entrée unique durci — voir \u003Ca href=\"\u002Fblog\u002Fheberger-bastion-host-vps\">Bastion Host sur VPS\u003C\u002Fa>.\n- **CrowdSec** : détection comportementale et blocklist communautaire en complément ou remplacement de fail2ban — voir \u003Ca href=\"\u002Fblog\u002Fsecuriser-vps-crowdsec\">Sécuriser votre VPS avec CrowdSec\u003C\u002Fa>.\n- **Sauvegardes** : la configuration de sécurité ne protège pas contre la perte de données — voir \u003Ca href=\"\u002Fblog\u002Fbackups-borgbackup-vps\">Sauvegardes avec BorgBackup sur VPS\u003C\u002Fa>.\n- **Correctifs applicatifs** : le durcissement système est inutile si les applications self-hosted ne sont pas maintenues — voir \u003Ca href=\"\u002Fblog\u002Froutine-correctifs-apps-self-hosted\">Routine de correctifs pour apps self-hosted\u003C\u002Fa>.\n- **Certificats SSL** : HTTPS est prérequis avant toute exposition publique — voir \u003Ca href=\"\u002Fblog\u002Fcertificats-ssl-lets-encrypt-vps\">Certificats SSL avec Let's Encrypt sur VPS\u003C\u002Fa>.","ServOrbit livre chaque VPS prêt pour ce runbook","Accès root SSH immédiat et console KVM incluse à la livraison : votre agence applique ce runbook dès la première connexion, pour chaque client, sans demander un accès intermédiaire à l'hébergeur. Gérez l'ensemble de votre portefeuille VPS clients depuis un espace agence centralisé.","ServOrbit livre chaque VPS","\u002Fsolutions\u002Fagences",[147,162,177],{"id":148,"slug":149,"slugs":150,"title":154,"excerpt":155,"readTime":156,"views":16,"isPinned":17,"publishedAt":157,"category":158,"categories":159,"featuredImage":27,"bgImage":28,"posterImage":161,"relatedSolution":27},116,"certificats-ssl-lets-encrypt-vps",{"fr":149,"en":151,"ar":152,"es":153},"free-ssl-certificates-with-lets-encrypt-on-a-vps","شهادات-ssl-مجانية-باستخدام-lets-encrypt-على-خادم-vps","certificados-ssl-gratis-con-lets-encrypt-en-un-vps","Certificats SSL gratuits avec Let's Encrypt sur VPS","Déployez Let's Encrypt sur votre VPS : HTTPS gratuit, renouvellement automatique, A+ SSL Labs avec Nginx, Caddy ou Traefik en Docker.",4,"2026-02-24T00:00:00+00:00",{"id":20,"name":21,"slug":22,"color":23,"icon":24},[160],{"id":20,"name":21,"slug":22,"color":23,"icon":24},"\u002Fblog\u002Fcovers\u002Fcertificats-ssl-lets-encrypt-vps-poster.svg",{"id":163,"slug":164,"slugs":165,"title":169,"excerpt":170,"readTime":171,"views":16,"isPinned":17,"publishedAt":172,"category":173,"categories":174,"featuredImage":27,"bgImage":28,"posterImage":176,"relatedSolution":27},278,"backoffice-vps-surfaces-attaque-oubliees-2026",{"fr":164,"en":166,"ar":167,"es":168},"exposed-backoffice-on-vps-the-overlooked-attack-surfaces","لوحة-إدارة-الخادم-الافتراضي-أسطح-الهجوم-المنسية","backoffice-expuesto-en-vps-superficies-de-ataque-olvidadas","Backoffice exposé : les surfaces d'attaque oubliées sur VPS","Quatre CVE d'août 2026 partagent le même schéma : backoffice exposé sur Internet, compte compromis. L'authentification applicative seule ne suffit pas.",12,"2026-08-17T00:00:00+00:00",{"id":20,"name":21,"slug":22,"color":23,"icon":24},[175],{"id":20,"name":21,"slug":22,"color":23,"icon":24},"\u002Fblog\u002Fcovers\u002Fbackoffice-vps-surfaces-attaque-oubliees-2026-poster.svg",{"id":178,"slug":179,"slugs":180,"title":184,"excerpt":185,"readTime":156,"views":16,"isPinned":17,"publishedAt":186,"category":187,"categories":188,"featuredImage":27,"bgImage":28,"posterImage":190,"relatedSolution":27},114,"backups-borgbackup-vps",{"fr":179,"en":181,"ar":182,"es":183},"encrypted-vps-backups-with-borgbackup","نسخ-خادم-vps-الاحتياطية-المشفرة-باستخدام-borgbackup","copias-de-seguridad-vps-con-borgbackup","Sauvegardes chiffrées de VPS avec BorgBackup","Sauvegardez votre VPS avec BorgBackup : déduplication puissante, chiffrement authentifié et compression. Guide complet et comparatif Restic.","2026-02-26T00:00:00+00:00",{"id":20,"name":21,"slug":22,"color":23,"icon":24},[189],{"id":20,"name":21,"slug":22,"color":23,"icon":24},"\u002Fblog\u002Fcovers\u002Fbackups-borgbackup-vps-poster.svg",1788099957999]