quand tu offres un service tu mets son IP publique en direct sur Internet.
Je suis assez d'accord, mais c'est orthogonal avec le fait d'avoir un équipement qui fait du filtrage devant à mon sens.
1 - tu maitrises ton OS ton serveur est une brique au delà du port du service que tu souhaites offrir et n'a aucun risque y a rien qui écoute ur d'autres ports.
Defense in depth.
2 - si ton firewall ne vérifie pas que c'est bien du NTP dans le paquet entrant et du NTP/UDP propre il ne sert strictement à rien en se contentant de bêtement transmettre le paquet.
Si il applique une bête ACL qui autorise 123/udp à passer dedans, ca filtre tout le reste. Ce n'est pas inutile, même si ca n'inspecte pas ce qu'il y a dedans ?
La NAT est le degrés zéro de la sécu.
Entre un firewall qui fait default inbound drop et du NAT, pas de différence.
Le tracking c'est plutôt quand on doit aller dans le paquets et changer l'IP source pour des protocoles qui ne supporte pas la NAT (SIP, GRE,FTP...) et qu'on doit surveiller le paquet de réponse pour l'acheminer à la bonne machine source
Je suis d'accord qu'un routeur doit router et être aussi stateless que possible.
On peut ceci dit vouloir faire du conntrack pour autoriser les flux dans une direction et non dans l'autre, par exemple. Dans ce cas, avoir le contexte pour permettre au firewall de discerner les paquets entrants liés à une connexion initiée depuis l'intérieur de ceux qui n'ont pas été sollicités est utile.
Je mentionnais uniquement le tracking car c'est ce qui se passe par défaut avec nftables sous linux (ce n'était pas le cas avec iptables) : par défaut, il y a création d'un contexte pour chaque flux traversant le routeur, même si on ne fait pas de filtrage sur l'état du flux, donc il fait du conntrack dans tous les cas. Je ne sais pas ce qu'il fait des paquets si la table overflow.
Note que je ne parle aucunement de NAT ici. Le NAT est une construction qui vient au dessus de cette table de connection tracking.
Remplacer la LiveBox par un routeur