Au risque de sembler desagreable envers des gens que je ne connais pas leur truc ca n'a rien de nouveau.
A la grande epoque de la lutte contre le SPAM par des bidouilleurs (faire une recherche sur "church of the sub genius" dans Google) une technique dite de cripple avait ete mise au point. Elle se basait sur le meme principe, mais avec un certains nombres de jouyeusetes supplementaires.
1) Le serveur repondait a la demande, mais annoncait un tot de perte de paquet monstrueux (de l'ordre de 80%) et forcait ainsi l'emmetteur a reemettre en boucle des paquets sans jamais reussir au final a envoyer quoique ce soit. Cela bloque l'emetteur beaucoup plus longtemps car le fatidique "connection timeout" n'arrive jamais
2) Le serveur repond tres lentement (5 a 10 secondes de latence) , et fait parfois des reponses incoherentes qui vont etre interpretees comme des "collide" par l'emetteur. Une fois de plus l'emetteur se retrouve bloque et l'admin a interet a etre vraiment balaise pour comprendre ce qui se passe (on parle de mesure anti spam ici). Ce type de replique peut assez facilement etre applique aux vers qui n'ont pas materiellement la complexite suffisante pour s'adapter a des reponses saugrenues.
3) Le serveur emet parfois des packets avec "saut de port" ce qui pousse l'emetteur a croire qu'il a manque un paquet et donc a redemander le paquet manquant. Occasion reve pour fragmenter un paquet et le renvoyer morceau par morceau (toujours avec 5 a 10 sec de latence.) Ce qui engorge la pile et peux provoquer un crash de l'appli. Cette derniere technique fortement denoncee lors de son utilisation contre la spam (le risque de planter un serveur mail honnete etant trop grand) perd pas mal de son cote dangereux si elle est mise en place contre des vers repertories (par contre la mettre en place sur tous les ports non utilises seraient une betise pour des raisons evidentes).
A noter que ce systeme mise en place et intensivement teste sur usenet n'a pas vraiment eu une efficacite redoutable.
# Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par Jerome Herman . En réponse à la dépêche TARPITS : Ralentir la propagation des vers avec IPtables. Évalué à 7.
A la grande epoque de la lutte contre le SPAM par des bidouilleurs (faire une recherche sur "church of the sub genius" dans Google) une technique dite de cripple avait ete mise au point. Elle se basait sur le meme principe, mais avec un certains nombres de jouyeusetes supplementaires.
1) Le serveur repondait a la demande, mais annoncait un tot de perte de paquet monstrueux (de l'ordre de 80%) et forcait ainsi l'emmetteur a reemettre en boucle des paquets sans jamais reussir au final a envoyer quoique ce soit. Cela bloque l'emetteur beaucoup plus longtemps car le fatidique "connection timeout" n'arrive jamais
2) Le serveur repond tres lentement (5 a 10 secondes de latence) , et fait parfois des reponses incoherentes qui vont etre interpretees comme des "collide" par l'emetteur. Une fois de plus l'emetteur se retrouve bloque et l'admin a interet a etre vraiment balaise pour comprendre ce qui se passe (on parle de mesure anti spam ici). Ce type de replique peut assez facilement etre applique aux vers qui n'ont pas materiellement la complexite suffisante pour s'adapter a des reponses saugrenues.
3) Le serveur emet parfois des packets avec "saut de port" ce qui pousse l'emetteur a croire qu'il a manque un paquet et donc a redemander le paquet manquant. Occasion reve pour fragmenter un paquet et le renvoyer morceau par morceau (toujours avec 5 a 10 sec de latence.) Ce qui engorge la pile et peux provoquer un crash de l'appli. Cette derniere technique fortement denoncee lors de son utilisation contre la spam (le risque de planter un serveur mail honnete etant trop grand) perd pas mal de son cote dangereux si elle est mise en place contre des vers repertories (par contre la mettre en place sur tous les ports non utilises seraient une betise pour des raisons evidentes).
A noter que ce systeme mise en place et intensivement teste sur usenet n'a pas vraiment eu une efficacite redoutable.
Kha