# Une base de durcissement Linux VPS que vous pouvez maintenir | SwissOctet Insights https://swissoctet.com/fr/insights/linux-vps-hardening-baseline/ SwissOctet / Analyses / Opérations du deuxième jour Opérations du deuxième jour Appliqué · 6 min de lecture Une base de durcissement Linux VPS que vous pouvez maintenir Sécurisez l'administration, n'exposez que les services requis et établissez les mises à jour et la récupération sans vous verrouiller dehors. Par SwissOctet Editorial Enregistrer le guide Copier le lien SUR CETTE PAGE 01 Établissez un point de départ fiable 02 Rendez l'accès à SSH délibéré 03 Exposez l'application, pas la machine entière 04 Planifiez les mises à jour comme un processus d'exploitation 05 Restreignez l'accès aux applications et protégez la récupération 06 Une séquence de premier déploiement qui reste vérifiable Votre liste de contrôle pratique Sources et lectures complémentaires Retour à la bibliothèque LA RÉPONSE DIRECTE Commencez par un accès vérifié et une voie de récupération, puis configurez une administration individuelle, des clés SSH testées, un pare-feu restrictif, des logiciels maintenus et des sauvegardes indépendantes. Appliquez les changements progressivement et vérifiez une nouvelle session avant de fermer l'ancienne. 01 Établissez un point de départ fiable Avant de modifier la machine, confirmez le système d'exploitation attendu, la méthode d'accès et la voie de récupération. Vérifiez l'identité de l'hôte SSH à l'aide des informations approuvées par l'opérateur plutôt que d'accepter une clé inattendue sans enquête. Gardez les identifiants temporaires privés et remplacez-les selon le processus prévu. Notez quelle personne est responsable de la maintenance et quelles options de récupération sont réellement disponibles pour ce service. Gardez une session d'administration fonctionnelle ouverte pendant les modifications d'accès. Une recette de durcissement copiée peut supprimer le seul identifiant utilisable lorsqu'elle suppose une distribution ou une organisation de comptes différente. Effectuez un changement à la fois, vérifiez son résultat effectif et conservez une voie de retour. L'objectif est un système que vous pouvez maintenir en toute sécurité, et non une configuration qui semble stricte mais ne peut pas être administrée. 02 Rendez l'accès à SSH délibéré Créez un accès administratif individuel avec les privilèges appropriés plutôt que de partager un identifiant root permanent. Installez et testez la clé publique prévue, en conservant la clé privée sur le point de terminaison autorisé. La documentation OpenSSH de Ubuntu explique la configuration du serveur et les choix d'authentification. Lisez la configuration effective de votre distribution, y compris les fichiers inclus, avant de supposer que la modification d'un paramètre a changé l'ensemble du service. Testez l'accès par clé via une seconde session avant de modifier l'authentification par mot de passe ou les règles de connexion privilégiée. Assurez-vous que le nouveau compte peut effectuer l'administration nécessaire. Examinez toute automatisation qui dépend de la méthode précédente et remplacez son accès de manière délibérée. Une clé est un identifiant d'accès : utilisez un emplacement de stockage privé et un processus de rotation plutôt que de laisser des copies dans les répertoires d'application. 03 Exposez l'application, pas la machine entière Inventoriez les services en écoute et identifiez ceux qui doivent être publics. Une application web peut avoir besoin de HTTP et HTTPS, tandis que sa base de données peut rester accessible uniquement via le chemin interne prévu. Ubuntu documente UFW comme outil de configuration de pare-feu, mais la politique utile est indépendante de l'outil : autorisez le trafic requis et restreignez l'administration aux sources approuvées lorsque c'est possible. Vérifiez les contrôles au niveau de l'hôte et du fournisseur si le service les inclut. Avant d'activer un ensemble de règles restrictives, autorisez le chemin d'administration testé et vérifiez l'accès depuis une autre session. Ne supposez pas que le déplacement de SSH vers un autre port remplace l'authentification ou les correctifs. Gardez les règles de pare-feu compréhensibles afin que le dépannage futur ne conduise pas à ouvrir tous les ports comme solution de contournement. Changement Vérifier avant d'appliquer Vérifier après Nouvelle clé SSH Compte et clé publique corrects La seconde session authentifiée par clé fonctionne Pare-feu restrictif Chemins de service et de récupération requis L'application publique fonctionne ; les ports non prévus sont fermés Mise à jour logicielle Implications pour la sauvegarde et le redémarrage Les services redémarrent et les tests d'application réussissent Modification des permissions de service Chemins de lecture et d'écriture requis L'application fonctionne sans accès système élargi 04 Planifiez les mises à jour comme un processus d'exploitation Maintenez le système et les dépendances applicatives. Les recommandations de mise à jour automatique de Ubuntu décrivent les mises à niveau sans intervention, les origines autorisées et le comportement de redémarrage. Un dépôt tiers n'est pas automatiquement couvert du seul fait qu'il a été ajouté à la machine. Examinez ce que le processus de mise à jour configuré inclut réellement, et donnez aux applications installées séparément leur propre voie de maintenance. Décidez comment les redémarrages de service et les redémarrages système seront gérés. L'application d'une mise à jour de paquet ne signifie pas toujours que chaque processus en cours utilise le nouveau code. Utilisez une fenêtre de maintenance lorsque la charge de travail l'exige, et effectuez une vérification simple de l'application ensuite. Si un paquet nécessite des étapes de migration manuelles, documentez-les au lieu de désactiver toutes les mises à jour indéfiniment et d'oublier l'exposition qui en résulte. 05 Restreignez l'accès aux applications et protégez la récupération Exécutez les services avec les permissions dont ils ont besoin, et séparez le contenu public des secrets et des métadonnées de déploiement. Un processus web ne doit pas pouvoir réécrire tous les paramètres système. Gardez les secrets d'environnement en dehors des répertoires servis publiquement et évitez de les inclure dans les journaux, les exports de support ou les sauvegardes générales sans politique de protection intentionnelle. Supprimez les paquets et services inutilisés lorsqu'ils n'ont aucune utilité opérationnelle. Maintenez une sauvegarde indépendante et testez la restauration de l'application dans un environnement isolé. Restreignez les identifiants de sauvegarde afin qu'une application compromise ne puisse pas supprimer automatiquement toutes les copies de récupération. Surveillez la capacité disque, l'âge des sauvegardes et les défaillances de service. La journalisation doit répondre à des questions opérationnelles définies, avec un accès et une rétention contrôlés ; elle ne doit pas devenir une copie illimitée de requêtes sensibles. 06 Une séquence de premier déploiement qui reste vérifiable Pour un nouveau VPS, vérifiez d'abord l'accès et la récupération, puis établissez le compte administratif et la clé testée. Configurez le pare-feu, appliquez les mises à jour et déployez l'application sous son compte de service prévu. Confirmez le comportement public depuis un autre environnement, vérifiez que les fichiers privés ne peuvent pas être récupérés et effectuez une restauration de sauvegarde. Consignez chaque décision et la voie de retour pour annuler une modification d'accès. Vector VPS, Pulse NVMe et certains plans dédiés sélectionnés présentent des choix Linux dans le catalogue SwissOctet. Confirmez l'image choisie et la répartition des tâches de maintenance avant de commander. Aucun nom d'image Linux ne prouve que le durcissement, les mises à jour ou les sauvegardes sont déjà gérés. La base de référence est l'ensemble des contrôles que vous configurez, vérifiez et continuez à maintenir à mesure que le projet évolue. PASSEZ À L'ACTION Votre liste de contrôle pratique. ✓ Vérifiez l'identité de l'hôte SSH et la voie de récupération. ✓ Testez l'accès par clé individuelle dans une seconde session. ✓ Restreignez les services en écoute et les règles de pare-feu. ✓ Examinez la couverture des mises à jour et le comportement de redémarrage. ✓ Séparez les secrets des fichiers publics et des permissions de service. ✓ Testez une copie de récupération indépendante. Télécharger la liste de contrôle QUESTIONS FRÉQUENTES Les détails qui comptent. Dois-je désactiver immédiatement la connexion par mot de passe ? + Établissez et testez d'abord l'accès par clé de remplacement et la voie de récupération. Modifiez ensuite l'authentification selon votre configuration prise en charge. Un changement de port SSH remplace-t-il le durcissement ? + Non. Il ne remplace pas une authentification forte, un accès restreint, les mises à jour ou des privilèges de compte appropriés. Les mises à jour automatiques suffisent-elles pour chaque application ? + Non. Vérifiez les dépôts autorisés, les exigences de redémarrage et les logiciels installés en dehors du processus de mise à jour du système. RÉFÉRENCES PRINCIPALES Allez à la source. Ces références soutiennent les concepts techniques de ce guide. Suivez la documentation actuelle avant de modifier un système de production. Serveur Ubuntu : serveur OpenSSH ubuntu.com Serveur Ubuntu : pare-feu ubuntu.com Serveur Ubuntu : mises à jour automatiques ubuntu.com Conseils éditoriaux par SwissOctet. Les exemples sont illustratifs. Les spécifications de service, les options disponibles et les conditions contractuelles doivent être vérifiées séparément. CONNECTEZ LES CONNAISSANCES Infrastructure associée. Vector VPS Suisse Pulse NVMe Suisse Metal EPYC Suisse GARDEZ LE FIL Vos prochaines notes de terrain. Explorez tous les guides NOTE DE TERRAIN / 01 + Opérations du deuxième jour Appliqué Construisez une sauvegarde que vous pouvez réellement restaurer Choisissez un objectif de récupération, protégez une copie indépendante et entraînez-vous à la restauration avant qu'un incident ne force la décision. 4 min de lecture Lire le guide NOTE DE TERRAIN / 02 + Opérations du deuxième jour Appliqué Un modèle de menace pratique pour votre projet hébergé Cartographiez les actifs et les frontières de confiance, choisissez quelques scénarios de défaillance réalistes et transformez-les en contrôles que vous pouvez tester. 6 min de lecture Lire le guide NOTE DE TERRAIN / 03 + Opérations du deuxième jour Appliqué Administration sécurisée de Windows RDP sans perdre l'accès Séparez l'accessibilité réseau, l'authentification et les privilèges, puis vérifiez une voie de récupération avant de restreindre l'accès distant. 6 min de lecture Lire le guide