Bon, d'abord, voyons une tentative d'explication un peu plus détaillée du fonctionnement:
Un ver utilise le schéma suivant:
- Je m'installe
- Je tente de me propager sur d'autres machines
- Une fois propagé, je recommence
L'idée est de ralentir la phase de propagation.
Comment ?
D'habitude, quand un ver essaie de se propager, il tente d'initier une connexion TCP (souvent, entre autres parcequ'il y a beaucoup de services "courants" sur TCP) sur plein de machines, sur un port censé faire tourner un service qui a une faille.
Normalement:
- Soit il arrive à négocier une session TCP, car il y a bien un serveur qui ecoute, il tente d'exploiter la faille, ca marche ou pas, et il passe a une autre machine.
- Soit il n'y a pas de service qui écoute, et la pile TCP/IP de la machine cible renvoie un poli "il n'y a pas de service qui ecoute ici". La encore, on passe a une autre machine.
- Soit il y a un firewall qui filtre tout, et qui est pas poli du tout (normal, c'est un firewall :-). Le ver (enfin, la pile TCP/IP en dessous) va tenter 2-3 fois d'envoyer un paquet de début de connexion, et n'ayant pas de réponse, au bout de quelques secondes, va laisser tomber.
Ce que propose le TARPIT, c'est d'initier la session TCP, puis ensuite de la "régler" de facon à ce qu'elle soit inexploitable. Pourquoi ? Parceque dans ce cas la, c'est le timeout TCP qui va etre le "chrono" de fin de la connexion (donc du "je passe à une autre machine), et il est généralement *nettement* plus long que les quelques secondes de timeout de l'initiation de la connexion.
Donc, au lieu de "perdre" ~10 secondes maximum sur une IP non infectable, bah le ver peut eventuellement perdre plusieurs minutes (voire plusieurs heures ?).
Voila pour le principe, voyons sur les posts d'en dessous pourquoi j'y crois pas....
[^] # Re: Efficacité relative, les détails (1)
Posté par Vanhu . En réponse à la dépêche TARPITS : Ralentir la propagation des vers avec IPtables. Évalué à 10.
Bon, d'abord, voyons une tentative d'explication un peu plus détaillée du fonctionnement:
Un ver utilise le schéma suivant:
- Je m'installe
- Je tente de me propager sur d'autres machines
- Une fois propagé, je recommence
L'idée est de ralentir la phase de propagation.
Comment ?
D'habitude, quand un ver essaie de se propager, il tente d'initier une connexion TCP (souvent, entre autres parcequ'il y a beaucoup de services "courants" sur TCP) sur plein de machines, sur un port censé faire tourner un service qui a une faille.
Normalement:
- Soit il arrive à négocier une session TCP, car il y a bien un serveur qui ecoute, il tente d'exploiter la faille, ca marche ou pas, et il passe a une autre machine.
- Soit il n'y a pas de service qui écoute, et la pile TCP/IP de la machine cible renvoie un poli "il n'y a pas de service qui ecoute ici". La encore, on passe a une autre machine.
- Soit il y a un firewall qui filtre tout, et qui est pas poli du tout (normal, c'est un firewall :-). Le ver (enfin, la pile TCP/IP en dessous) va tenter 2-3 fois d'envoyer un paquet de début de connexion, et n'ayant pas de réponse, au bout de quelques secondes, va laisser tomber.
Ce que propose le TARPIT, c'est d'initier la session TCP, puis ensuite de la "régler" de facon à ce qu'elle soit inexploitable. Pourquoi ? Parceque dans ce cas la, c'est le timeout TCP qui va etre le "chrono" de fin de la connexion (donc du "je passe à une autre machine), et il est généralement *nettement* plus long que les quelques secondes de timeout de l'initiation de la connexion.
Donc, au lieu de "perdre" ~10 secondes maximum sur une IP non infectable, bah le ver peut eventuellement perdre plusieurs minutes (voire plusieurs heures ?).
Voila pour le principe, voyons sur les posts d'en dessous pourquoi j'y crois pas....