La première heure : une surface d'attaque réduite.

Vérifiez et préservez l'accès

Confirmez l'identité du serveur via un canal de confiance et ajoutez votre clé publique SSH. Créez un utilisateur administratif nommé. Gardez la session d'origine ouverte pendant le test de la nouvelle et consignez la méthode de récupération avant de modifier l'authentification.

Corrigez et réduisez l'exposition

Installez les mises à jour de sécurité prises en charge et redémarrez si nécessaire. Examinez les services à l'écoute et n'autorisez que les ports nécessaires dans le pare-feu, y compris IPv6. Supprimez les démons inutilisés et évitez d'exposer publiquement une base de données simplement pour faciliter l'installation.

Séparer les utilisateurs et les secrets

Exécutez les applications sous leurs propres comptes. Placez la configuration privée hors du répertoire web public et excluez-la du contrôle de version. Utilisez des privilèges de base de données restreints et des identifiants distincts pour la production et les expérimentations.

Laissez un chemin de récupération fonctionnel

Configurez la rotation des journaux, les alertes disque et une sauvegarde distincte. Redémarrez une fois pour vérifier que l'application démarre correctement. Consignez les modifications afin de pouvoir reconstruire la configuration sur une image propre.

Vérifier avant de fermer la session

Ouvrez une seconde connexion avec le nouveau compte, vérifiez l'élévation administrative et testez le pare-feu depuis un autre client. Confirmez que le service répond après redémarrage. Documentez la voie de récupération du fournisseur afin qu'une règle réseau erronée n'impose pas une récupération improvisée.

Une liste de vérification pour le premier jour

Examinez les sockets ouverts, les événements d’authentification récents, l’état des mises à jour, l’âge des sauvegardes et l’utilisation du disque. Vérifiez que la configuration privée et les métadonnées de contrôle de version ne peuvent pas être récupérées via HTTP. Utilisez le plus petit ensemble d’outils installés qui prend en charge la charge de travail réelle.

ss -lntup
df -h
free -h
systemctl --failed

Effectuez les modifications d'accès dans un ordre réversible

Confirmez d'abord la console ou la voie de secours et vérifiez la clé d'hôte SSH via un canal fournisseur de confiance. Installez la clé publique pour un administrateur nommé, puis ouvrez une seconde connexion et testez l'élévation de privilèges. Validez la syntaxe de configuration SSH avant de recharger le service. N'appliquez les modifications de pare-feu qu'après avoir autorisé la route SSH prévue. Désactivez une ancienne méthode d'authentification une fois que le remplacement fonctionne depuis une nouvelle session, avec le flux de second facteur requis le cas échéant.

• Inspectez la configuration effective et les extraits inclus ; un réglage dans un fichier peut ne pas être la politique finale.
• Vérifiez à la fois l'authentification par mot de passe et la politique clavier-interactif lors de l'examen d'une conception de connexion par clé.
• Un port SSH non standard peut réduire le bruit de fond, mais ne remplace pas des clés vérifiées, des limites d'accès ni des mises à jour.
• Utilisez le nom du service et la procédure de rechargement propres à votre distribution. Gardez la session d'origine jusqu'à ce que la nouvelle politique soit éprouvée.

# Validate before applying a changed SSH configuration.
sudo /usr/sbin/sshd -t
# Read effective settings; adapt user, host and client address to the test.
sudo /usr/sbin/sshd -T -C user=admin,host=server.example,addr=198.51.100.10

Documentation officielle : OpenSSH : manuel de configuration du serveur

Prouvez le pare-feu depuis l'extérieur de l'hôte

Examinez le pare-feu réseau du fournisseur et le pare-feu de l'invité comme des contrôles distincts. Testez le service prévu sur IPv4 et IPv6 depuis une autre machine autorisée. Une connexion locale prouve seulement qu'un processus est à l'écoute. Ne refusez pas aveuglément tous les paquets ICMP : le fonctionnement normal du réseau nécessite aussi un trafic de contrôle approprié. Vérifiez les ports publiés par les conteneurs par rapport aux règles réelles, car l'exposition applicative peut ne pas correspondre à la politique que vous pensiez appliquée par une interface de pare-feu.

• Si SSH échoue, inspectez les restrictions d'adresse source, l'interface d'écoute et le pare-feu du fournisseur avant de changer les clés à répétition.
• Si HTTPS échoue, vérifiez DNS, l'écoute du processus puis le pare-feu local/proxy, dans cet ordre.
• Avant le premier jeu de données de production, vérifiez l'état des mises à jour, un redémarrage propre, les alertes disque et une sauvegarde restaurable de manière indépendante.
• Définissez un fuseau horaire documenté et vérifiez la synchronisation de l'heure. N'ajoutez pas de paramètres de swap ou de journalisation arbitraires sans vérifier les besoins en mémoire et en rétention de la charge de travail.

Documentation officielle : Serveur Ubuntu : administration du pare-feu