Le 23 juillet 2010 18:15, Pascal Hambourg <[email protected]> a écrit :
> Hugo Deprez a écrit : > > >> merci pour la réponse, j'ai une règle de type ACCEPT source any >> destination >> any. >> Elle semble fonctionnelle, et je pensais qu'elle prendrait le dessus sur >> les >> autres règles déjà présentes. Ce ne serait pas le cas ? >> >> voici ma table OUTPUT : >> > > Note : je trouve que le format de sortie d'iptables -L n'est pas très > lisible, je préfère celui d'iptables-save. > > LOGDROP tcp -- anywhere anywhere tcp >> flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG >> LOGDROP tcp -- anywhere anywhere tcp >> flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG >> > > Note : ces deux règles pourraient être fusionnées en > flags:FIN,SYN,RST,ACK,URG/FIN,SYN,RST,ACK,URG > > > LOGDROP tcp -- anywhere anywhere tcp >> flags:FIN,SYN,RST,PSH,ACK,URG/NONE >> > > C'est cette règle qui attrape le paquet TCP sans flag émis par hping3. Il > n'est donc pas bloqué sur son état de suivi de connexion comme je l'avais > d'abord pensé mais sur la valeur de ses flags TCP. > Effectivement. Si tu ne veux pas t'émbêter, il peut être judicieux de n'effectuer ce genre de filtrage qu'en entrée. Mais en cas de scan nmap par exemple, tu auras des retours dropés. > > Accessoirement, quel est le but d'envoyer un paquet TCP sans flag, qui sera > forcément écarté par le destinataire ? Ne faudrait-il pas fournir à hping3 > les options pour émettre un paquet valide ? > > Windows répond parfois à ce genre de paquets. Pour ce qui est des paquets invalides, voici un exemple: iptables -t filter -A INPUT -m state --state INVALID -j DROP
