Journaliser les rejets et nettoyer la configuration

Un port bloqué ne signifie pas toujours qu’un service est mal configuré : il peut s’agir d’une connexion non autorisée, d’une erreur de ciblage ou d’un contrôle automatisé sur Internet. Sans journal, vous manquez d’éléments pour différencier ces situations. Vous allez activer une journalisation mesurée, examiner les événements, puis retirer les règles qui ne correspondent plus aux besoins du serveur.

Activer une journalisation adaptée

UFW peut enregistrer les paquets bloqués dans les journaux système. Le niveau low fournit une journalisation limitée adaptée à un premier suivi ; les niveaux plus détaillés peuvent produire davantage d’événements. Commencez par ce niveau, puis consultez les journaux pour vérifier que le volume et les informations obtenues conviennent à votre serveur.

sudo ufw logging low
sudo ufw status verbose

Logging enabled

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)

Les règles affichées dépendent de la configuration réellement appliquée sur le serveur.

Lire les rejets sans les confondre avec une panne

Sur les systèmes qui utilisent journald, recherchez les messages UFW avec journalctl. Une ligne de rejet peut indiquer l’interface, les adresses source et destination, le protocole et les ports concernés. Sur les distributions qui consignent UFW dans /var/log/ufw.log, ce fichier constitue une autre source ; vérifiez les conventions de journalisation de votre système plutôt que de supposer qu’un emplacement est universel.

sudo journalctl -k --since "1 hour ago" --no-pager | grep 'UFW'

Exemple de ligne :
Mar 18 10:42:07 serveur kernel: [UFW BLOCK] IN=eth0 OUT= MAC=... SRC=203.0.113.25 DST=192.0.2.10 LEN=60 PROTO=TCP SPT=51842 DPT=8080 SYN

Dans cet exemple, DPT=8080 désigne le port de destination visé et SRC l’adresse de la source. Si ce port ne fait pas partie des accès prévus, le rejet est cohérent avec la politique du serveur ; s’il correspond à un service nécessaire, vérifiez d’abord le service, le port et la règle attendue avant d’ajouter une autorisation. Un rejet, à lui seul, ne prouve ni une attaque ni une panne : confrontez l’événement à vos tests et à l’inventaire des services.

Nettoyer et contrôler la configuration

Relisez la liste numérotée avant toute suppression. Une règle n’est à retirer que si vous avez confirmé qu’elle est inutile ou temporaire ; le numéro change après chaque suppression, donc réaffichez la liste avant d’en supprimer une autre. Gardez une autorisation distincte pour chaque intention, notamment SSH et les ports web réellement utilisés.

sudo ufw status numbered
# Remplacez N par le numéro confirmé de la règle inutile.
sudo ufw delete N
sudo ufw status verbose
sudo journalctl -k --since "1 hour ago" --no-pager | grep 'UFW'

Après suppression, ufw status verbose affiche les règles restantes et Logging: on (low). La dernière commande présente les événements UFW récents disponibles ; elle peut ne rien afficher si aucun événement n’a été enregistré pendant la période.

La commande de suppression est volontairement présentée avec un numéro à remplacer : ne l’exécutez pas avant d’avoir identifié la règle dans la sortie. Après le nettoyage, vérifiez de nouveau la règle SSH et la session en cours, puis testez depuis une autre machine les accès prévus. Ne laissez ni autorisation de diagnostic ni ouverture temporaire dans la configuration finale.

À retenir

• Activez un niveau de journalisation adapté et vérifiez qu’il est indiqué dans l’état détaillé d’UFW.
• Consultez les événements UFW récents avec l’outil de journalisation disponible sur votre distribution.
• Interprétez chaque rejet selon son port, son protocole et le besoin prévu ; un rejet isolé ne suffit pas à diagnostiquer une panne.
• Relisez les règles avant suppression, confirmez le numéro et contrôlez que SSH reste accessible.
• Terminez sans règle temporaire, puis vérifiez les règles et les accès depuis une autre machine.