N’ouvrez que les chemins dont vous avez besoin

Enregistrez le port d’administration, l’écouteur web, l’emplacement de la base de données et toute exigence UDP/TCP propre au produit. Une base de données utilisée uniquement sur la même machine ne devrait pas nécessiter de règle publique. Tenez compte à la fois des règles de l’invité et du pare-feu amont d’un opérateur en direct.

Gardez une session fonctionnelle et une console de récupération vérifiée. Avant d'activer un pare-feu restrictif, autorisez le port SSH réel et la plage source requise. L'exemple ci-dessous suppose que SSH est actuellement sur le port 22 ; modifiez-le pour correspondre au service en cours d'exécution.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp

Pour un serveur web public, autorisez TCP 80 et 443. Cela n'active pas le service web lui-même, et les ports UDP/jeu/courrier nécessitent leurs propres choix explicites. Évitez une large plage de ports comme raccourci pour diagnostiquer une application.

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Ouvrez une autre connexion d’administration et testez l’application depuis l’extérieur. Lisez les règles UFW effectives et le paramètre IPv6 de la distribution. Une règle IPv4 uniquement ou un filtre en amont ne doivent pas être supposés protéger un listener IPv6.

Une sortie numérotée aide à localiser une règle obsolète. Les numéros changent après les suppressions, alors listez-les à nouveau avant un autre changement. Sur les systèmes utilisant firewalld ou nftables, suivez la configuration native de cet outil plutôt que de combiner des gestionnaires concurrents.

sudo ufw status numbered
# Remove only a rule you have identified, then list again:
# sudo ufw delete <rule-number>