Serge Cavailles a écrit :
La notion de "connexion" de Netfilter est élargie à tout flux IP bidirectionnel reconnaissable par ses adresses source et destination, protocole, ports source et destination (si applicables)... Exemples en dehors de TCP : - ICMP echo request et l'echo reply correspondant - requête DNS en UDP et la réponse correspondante - tunnel GRE, IPIP ou autreAh! J'ai toujours cru que le conntrack ne pouvait s'appliquer qu'à des connections au sens TCP.
Et non, pas seulement. Note toutefois que le suivi de connexion de Netfilter a ses limites, sauf aide d'un module "helper" pour certains protocoles particuliers. Par exemple il ne sait pas reconnaître les réponses à un paquet émis en broadcast (ICMP ping broadcast, annonce Netbios UDP) car l'adresse source unicast des paquets de réponse est différente de l'adresse broadcast du paquet initial : comme le suivi de connexion ne sait rien de l'organisation des sous-réseaux, il ne fait pas le lien entre les deux. Autre exemple, il ne sait pas reconnaître tout seul la réponse à une requête TFTP (en UDP) car le port source dans le paquet de réponse du serveur est différent du port destination dans le paquet de requête du client. Pour des protocoles aussi courants que Netbios et TFTP, il existe des modules "helpers" ([ip|nf]_conntrack_netbios_nf et [ip|nf]_conntrack_tftp) qui permettre de reconnaître ces réponses comme ESTABLISHED ou RELATED, mais rien n'est prévu pour le cas général.
Je vais donc pouvoir simplifier mes règles.
Probablement. En première approximation, dans une chaîne on peut se contenter de :
# accepte tout ce qui appartient ou est lié à une "connexion" existante -A -m state --state ESTABLISHED,RELATED -j ACCEPT # accepte au cas par cas les nouvelles "connexions" -A -m state --state NEW <critères : interface, proto, adresse, port...>\ -j ACCEPT [...] Et on jette le reste plus ou moins élégamment avec DROP ou REJECT.