Effectivement, c'est ce que je viens de voir avec les liens que tu as envoyé. Le patch "tcp-nopickup" résout réellement ce problème ?
je suppose oui mais je ne les ai pas essayé... et dans la doc ils previennent qu ele résultat est déroutant (coupure des connections a chaque relance du script netfilter -- ce qui est logique)
D'ailleur dans le cadre d'un doc visant les débutants je te déconseilles de commencer par leur demander de patcher le noyau :-))
Pour corriger ce probleme, il suffit de ne pas utiliser --state NEW puisqu'il ne fait pas ce que l'on veut/pense. De plus je trouve criticable ta facon d'utiliser --state NEW sans le dire. Le jour ou les developeurs de netfilter ajoutent un etat de plus dans la liste des etats connus pour une connection, tu va la matcher par defaut egalement ... il vaudrait mieux explicitement choisir les etats qui t'interessent.
Honnetement je ne voit pas l'interet d'un etat --state NEW :
si tu as des règles dans cet ordre:
1/ rejet des etat non voulus (invalid)
2/ accept des etats souhaitables (connected)
3/ accept un a un des protocoles connus et voulus quel que soit l'etat
normalement le filtrage est ok et sans utiliser --state NEW. [jusqu'a preuve du contraire]. le --state NEW de netfilter est mal-nommé amha, il devrait s'appeler --state OPTIMISTICALNEW ou quelque chose du genre :-))
dans le <3> si on est un peu plus parano on peut preciser les flags souhaitables (SYN ...). Mais pour ma par, je pense que le role du firewall netfilter c'est de laisser passer ces paquets. Si mon serveur web tourne sur le port 80, je peux accepter any:any -> serveur:80. C'est a apache et son OS hote d'etre resistant (pile tcp et serveur applicatif).
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. Évalué à 2.
je suppose oui mais je ne les ai pas essayé... et dans la doc ils previennent qu ele résultat est déroutant (coupure des connections a chaque relance du script netfilter -- ce qui est logique)
D'ailleur dans le cadre d'un doc visant les débutants je te déconseilles de commencer par leur demander de patcher le noyau :-))
Pour corriger ce probleme, il suffit de ne pas utiliser --state NEW puisqu'il ne fait pas ce que l'on veut/pense. De plus je trouve criticable ta facon d'utiliser --state NEW sans le dire. Le jour ou les developeurs de netfilter ajoutent un etat de plus dans la liste des etats connus pour une connection, tu va la matcher par defaut egalement ... il vaudrait mieux explicitement choisir les etats qui t'interessent.
Honnetement je ne voit pas l'interet d'un etat --state NEW :
si tu as des règles dans cet ordre:
1/ rejet des etat non voulus (invalid)
2/ accept des etats souhaitables (connected)
3/ accept un a un des protocoles connus et voulus quel que soit l'etat
normalement le filtrage est ok et sans utiliser --state NEW. [jusqu'a preuve du contraire]. le --state NEW de netfilter est mal-nommé amha, il devrait s'appeler --state OPTIMISTICALNEW ou quelque chose du genre :-))
dans le <3> si on est un peu plus parano on peut preciser les flags souhaitables (SYN ...). Mais pour ma par, je pense que le role du firewall netfilter c'est de laisser passer ces paquets. Si mon serveur web tourne sur le port 80, je peux accepter any:any -> serveur:80. C'est a apache et son OS hote d'etre resistant (pile tcp et serveur applicatif).