ce que je peux te confirmer, c'est ce que j'ai déjà écrit en dessous: si il n'y a pas de process pour écouter sur le port, la connexion ne sera jamais établie et la requete jamais envoyée.
ensuite parlons des problèmes iptables:
1/ comme c'est dit au dessus, inspecter le contenu des paquets est très lourd, peut etre même trop lourd en mode kernel.
2/ il y a deux types de machines: celles qui n'ecoutent pas sur le port 80 (et ne recevront jamais la requete) et celles qui écoutent sur le port 80 (elles ont donc un process bien mieux qualifié que iptables pour filtrer les url).
3/ que se passe t'il en cas de paquets fragmentés au milieu d'une url ? ta règle impose t'elle à iptable de ré-assembler les paquets ?? si NON, elle est completement inéficace. si OUI, elle est encore plus couteuse.
Sinon, pour la théorie iptables, effectivement on peut limiter le nombre de règles à parcourir pour prendre la décision. c'est d'ailleur une TRES bonne pratique.
a/ mettre en premier les règles qui ont le plus de chances d'être acceptées directement. par exemple -state established,related, le plu sgrand nombre de paquets n'etant pas des demandes de connection.
b/ séparer les règles en sous groupes. Dans le cas présent, une première règle qui dirige les requetes sur le port 80 vers une chaine "WEB" avant la "-state established,related" permettra d'éviter de scanner les règles dédiées au WEB pour les paquets FTP ...
bref, iptables c'est comme le reste, on peut toujours améliorer les règles.
[^] # Re: Detection d'attaques de vers.
Posté par PLuG . En réponse à la dépêche Nouveau Vers: Code Red le retour. Évalué à 3.
ensuite parlons des problèmes iptables:
1/ comme c'est dit au dessus, inspecter le contenu des paquets est très lourd, peut etre même trop lourd en mode kernel.
2/ il y a deux types de machines: celles qui n'ecoutent pas sur le port 80 (et ne recevront jamais la requete) et celles qui écoutent sur le port 80 (elles ont donc un process bien mieux qualifié que iptables pour filtrer les url).
3/ que se passe t'il en cas de paquets fragmentés au milieu d'une url ? ta règle impose t'elle à iptable de ré-assembler les paquets ?? si NON, elle est completement inéficace. si OUI, elle est encore plus couteuse.
Sinon, pour la théorie iptables, effectivement on peut limiter le nombre de règles à parcourir pour prendre la décision. c'est d'ailleur une TRES bonne pratique.
a/ mettre en premier les règles qui ont le plus de chances d'être acceptées directement. par exemple -state established,related, le plu sgrand nombre de paquets n'etant pas des demandes de connection.
b/ séparer les règles en sous groupes. Dans le cas présent, une première règle qui dirige les requetes sur le port 80 vers une chaine "WEB" avant la "-state established,related" permettra d'éviter de scanner les règles dédiées au WEB pour les paquets FTP ...
bref, iptables c'est comme le reste, on peut toujours améliorer les règles.