Le NAT fait-il office de pare-feu et sécurise-t-il votre réseau ?
Réponse courte
Non. Le NAT (et le PAT) associe des adresses privées à une IP publique et, par effet de bord, rejette les connexions entrantes non sollicitées car aucune correspondance n'existe pour elles. Ce n'est pas une politique de sécurité — pas d'inspection, pas de règles, pas de journalisation — et la traversée de NAT, le hole punching et le C2 initié en sortie passent sans problème. Le NAT est un outil d'adressage ; il vous faut un vrai pare-feu. « NAT = pare-feu » est l'idée fausse.
Parce qu'un routeur domestique derrière un NAT semble protégé — les scans entrants aléatoires n'atteignent pas votre ordinateur portable — beaucoup en concluent que le NAT est un pare-feu. Cette question vérifie si vous comprenez la différence entre un contrôle de sécurité et un effet de bord de l'adressage.
Ce que fait réellement le NAT
Le NAT (et sa forme à surcharge de ports, le PAT) résout la pénurie d'adresses : il associe de nombreuses adresses privées RFC 1918 à une seule IP publique, en réécrivant adresses et ports source à la sortie et en inversant la traduction sur les réponses. Pour cela, il tient une table de traduction des flux sortants actifs. Il n'y a aucun moteur de politique, aucun jeu de règles, aucune inspection, et généralement aucune journalisation.
Pourquoi l'entrant est rejeté (et pourquoi ce n'est pas de la sécurité)
Un paquet entrant non sollicité arrive sans entrée correspondante dans la table de traduction, donc l'équipement NAT ne sait pas à quel hôte interne l'envoyer et le rejette. Cela ressemble à un pare-feu qui bloque Internet — mais c'est un hasard du fonctionnement de la traduction, pas une politique appliquée. Il n'y a aucune notion de « refus », aucune journalisation de la tentative, et aucune inspection de ce qui est autorisé à passer.
Comment les attaquants passent au travers
La protection est unidirectionnelle et superficielle. Les connexions initiées en sortie créent des correspondances à la demande, donc un malware qui contacte un serveur de commande et contrôle passe directement — le schéma qu'utilise la plupart des malwares modernes. La traversée de NAT / le hole punching (STUN, le fonctionnement des applis P2P et VoIP) ouvre délibérément des chemins à travers le NAT.
Pourquoi les distracteurs sont tentants
« Le NAT est un pare-feu à états » confond l'état de la table de traduction avec l'application d'une politique. « Les IP internes sont cachées donc rien ne peut les router » confond le rejet de l'entrant avec l'inaccessibilité. L'option entièrement négative surcorrige : le NAT n'est pas un pare-feu, et l'IPv6 supprime même ce rejet fortuit.
Ce que recherchent les recruteurs
Un « non » ferme, la distinction effet de bord contre politique, et un exemple (C2 sortant ou hole punching) montrant que la protection est illusoire. La leçon : déployez un vrai pare-feu à états.
Questions de suivi probables
- Comment le C2 d'un malware initié en sortie contourne-t-il la « protection » que semble offrir le NAT ?
- Qu'est-ce que le hole punching NAT et pourquoi fonctionne-t-il ?
- Pourquoi l'IPv6 avec ses adresses globales rend-il dangereuse l'habitude du « NAT comme sécurité » ?