Sur un pare-feu, préféreriez-vous qu'un port soit filtré ou fermé ?

L'intuition que « fermé sonne plus sûr que filtré » est le piège. Les deux bloquent la connexion, donc les candidats supposent qu'ils sont équivalents, mais ils fuitent des quantités d'information très différentes.

Ce que chaque état révèle à un attaquant

• Fermé : l'hôte a reçu le SYN et a répondu par un RST TCP. Le service n'écoute pas, mais l'hôte est prouvé vivant et joignable. Le scanner obtient une réponse instantanée et définitive.
• Filtré : un pare-feu rejette silencieusement le paquet. Le scanner n'obtient rien en retour et doit attendre l'expiration d'un délai avant de réessayer, puis ne peut toujours pas dire si le port est fermé, l'hôte hors ligne, ou une règle qui bloque. Cette ambiguïté est exactement ce que vous voulez imposer à un attaquant.

Pourquoi filtré l'emporte

Deux raisons. D'abord, la privation d'information : un rejet refuse à l'attaquant la confirmation que quoi que ce soit existe, il ne peut donc pas cartographier proprement votre surface d'attaque. Ensuite, le coût du scan : les RST rendent les scans rapides et fiables, tandis que les rejets forcent le scanner dans de lents cycles de retransmission/expiration, prolongeant la reconnaissance et la rendant plus bruyante et plus facile à détecter. C'est pourquoi une politique de pare-feu en rejet par défaut est la recommandation de durcissement standard.

Le compromis honnête

Le rejet silencieux peut compliquer le dépannage légitime et ralentir vos propres diagnostics, puisque les échecs ressemblent à un hôte mort. C'est un prix qui vaut la peine d'être payé au périmètre.

Ce que recherchent les recruteurs

Le choix de filtré plus le raisonnement : RST = confirmation et rapidité pour l'attaquant, rejet = aucune information et scan lent et coûteux. Connaître la taxonomie ouvert/fermé/filtré de Nmap scelle l'affaire.