TARPITS : Ralentir la propagation des vers avec IPtables

Posté par Brunus le 22 août 2003 à 12:38. Modéré par Benoît Sibaud.

Étiquettes :

août

2003

Un article sur Securityfocus nous explique comment des tests sont réalisés grâce à IPtables, pour ralentir la propagation des vers.
Attention il s'agit d'une méthode expérimentale, à ne pas utiliser sur des systèmes en production.
Le principe est d'accepter les connexions TCP, sur les ports non utilisés (les cibles potentielles d'un vers), de les garder actives un certain temps, mais sans répondre. L'effet produit est que le ver doit attendre la fin de son délai d'attente de réponse (« connection timeout »), pour déconnecter.
Bien sûr entre temps, la machine ne répond pas à d'éventuelles demandes de déconnexion du ver.
L'article indique que le patch du noyau devrait être disponible par défaut dans la distribution Gentoo.

NdM: Le serveur de netfilter ne répond pas, auraient-ils par erreur fait un iptables -A INPUT -p tcp -m tcp --dport 80 -j TARPIT ? :-)

Aller plus loin

La dépêche sur securityfocus.com (31 clics)
Le patch sur Netfilter.org (16 clics)

# Re: TARPITS : Ralentir la propagation des vers avec IPtables

Posté par Ramso le 22 août 2003 à 12:40. Évalué à 0.

les liens ne sont pas vraiment en allemand

peut-être s'agit-il seulement du nom de certaines personnes ? :)
# Re: TARPITS : Ralentir la propagation des vers avec IPtables

Posté par Olivier Grisel (site web personnel) le 22 août 2003 à 12:41. Évalué à -1.

s/drapeaux_allemands/drapeaux_anglais/g
- [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
  
  Posté par Pascal Terjan (site web personnel) le 22 août 2003 à 13:01. Évalué à -1.
  
  J'ai du les laisser en allemand moins d'une minute et deja 2 commentaires pour le signaler :)
# Re: TARPITS : Ralentir la propagation des vers avec IPtables

Posté par Hobgoblins Master (Mastodon) le 22 août 2003 à 12:48. Évalué à 3.

Il n'y a pas moyen d'avoir le même comportement avec une gestion fine de established ?
- [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
  
  Posté par free2.org le 22 août 2003 à 13:10. Évalué à 6.
  
  pour obtenir le meme résultat sans ce patch, il faut que tu installes en + un serveur qui va accepter les connexions sur les ports en question (connexions qui seront considérées comme established et tu peux donc utiliser IPtables pour dropper les paquets reçus après cette connexion)
- [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
  
  Posté par Nicolas le 22 août 2003 à 22:53. Évalué à 4.
  Le principe du patch, c'est justement de ne pas faire de gestion, il va repondre de facon stateless aux packets TCP. Voici les reactions de TARPIT selon les flags TCP du packet:
```
SYN,!ACK,!RST,!FIN -> SYN-ACK, wsize=5
SYN,ACK,!RST,!FIN -> RST
!SYN,!RST,!FIN -> ACK, wsize=0
```
  J'ai travaille avec Tony Bautts sur ce projet et j'avais publie qqch en Juin dernier: http://cpc.freeshell.org/linux/kernel-tarpit.html(...)
# Re: TARPITS : Ralentir la propagation des vers avec IPtables

Posté par cedricv le 22 août 2003 à 13:34. Évalué à 6.

j'ai du mal à saisir l'interet... ralentir de quelques secondes (timeout) sur quelques machines (serveurs Linux hors production), le développement d'un vers qui se répand sur des millions de machines (Windows) surtout que le vers peut tres bien utiliser taper sur plusieurs IP à la fois en multithreadé.
- [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
  
  Posté par gege (site web personnel) le 22 août 2003 à 13:51. Évalué à 10.
  
  En fait ils parlent simplement de ne pas mettre ce système en place sur des serveur en production uniquement pour deux choses :
  * La pile réseau risque d'être stressée par de nombreuses connections (y a-t-il un pb sous linux ?)
  * Le patch netfilter n'est pas encore assez mur (il va surement se stabiliser)
  
  Il citent un autre avantage à TARPIT : l'utiliser sur tous les ports normalement fermés de la machine, ça perd nmap qui voit 2^16 ports ouverts et permet de rendre l'énumération des ports plus compliquée. Ca peut aussi servir sur un sous réseau d'une entreprise à ralentir tout le traffic ip vers des addresses qui ne sont pas utilisées (comme le LaBrea project http://www.hackbusters.net/LaBrea.html(...)).
  
  Donc effectivement les unix ne vont pas sauver (tout dessuite) les utilisateurs de windows des affreux vers qui les rongent, mais ces fonctionnalités peuvent quand même bien renforcer la sécurité d'un réseau ou d'un firewall...
  - [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
    
    Posté par Foxy (site web personnel) le 22 août 2003 à 14:03. Évalué à 4.
    
    * La pile réseau risque d'être stressée par de nombreuses connections (y a-t-il un pb sous linux ?)
    
    Par sur mes machines de tests en tout cas, j'ai déjà fait prendre 500000 connexions TCP simultanées à un noyau Linux et ils les tenaient bien (avec 512 Mo de RAM) et un outil de tests hardware spécifique.
    - [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
      
      Posté par Olivier le 22 août 2003 à 14:24. Évalué à 1.
      
      Heu ... comment tu fais tenir 500.000 connexions sur une seule machine où tu disposes de 2^16 ports (65536) par IP ?
      
      Tu ajoutes des IP virtuelles ? D'autres interfaces physiques dans ta machine ?
      - [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
        
        Posté par Foxy (site web personnel) le 22 août 2003 à 14:48. Évalué à 2.
        
        J'ai pas dit que je faisait 500000 à destination du Linux, je fais 500000 connexions "à travers" le Linux donc je peux jouer avec mon outils sur les IP source, destination et les ports comme je veux (l'outil est fait pour ça)
        
        [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
        
        Posté par ours Ours (site web personnel) le 22 août 2003 à 15:10. Évalué à 10.
        
        C'est d'autant plus possible que ce n'est pas un record
        Il y a 6 mois, un freebsd a réussi à tenir plus d'1,6 millions de connexions IP sans lacher.
        http://bsd.slashdot.org/bsd/03/01/30/1352202.shtml?tid=122(...)
        
        [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
        
        Posté par Foxy (site web personnel) le 22 août 2003 à 15:50. Évalué à 3.
        
        Ouais je sais bien qu'on peut faire mieux (ça dépend surtout de la RAM pour gérer une table de connexions actives TCP/IP).
        
        Dans mon cas, c'est mon outil hardware qui me limite à 500000 connexions simultanées : faut qu'on achète une carte génératrice de connexions TCP/IP supplémentaires.
        
        [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
        
        Posté par ours Ours (site web personnel) le 22 août 2003 à 16:48. Évalué à 5.
        
        Il avait quand même 4 Go de RAM sur son freeBSD :o)
        
        [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables (HS)
        
        Posté par un_brice (site web personnel) le 22 août 2003 à 19:04. Évalué à 1.
        
        Simple curiosité: est-ce que tu pourrais dire qui utilise ce genre d'outils, et dans quel buts?
        Parce qu'à priori, on sait ce que les systèmes tiennent sans avoir à les tester individuellement non? Et puis 500 000 conections simultanées, c'est vraiment beaucoup: j'aurais cru qu'on utilisait plutôt des trucs hardware pour router ce genre de flux (je pense pas que ce soit un serveur qui ait à soutenir ce débit).
        M'enfin c'est vrai que j'ai jamais vu une entreprise de l'interieur -_^.
        
        Et sinon, il se passe quoi quand le noyau manque de RAM? Il arrête d'écoutter? Freeze? Et y'a un moyen de limiter l'usage de la mèmoire par le noyau dans ce genre de circonstances ? (à part dropper les packets avec Iptable paske c'est crade quand même lol)
        
        [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables (HS)
        
        Posté par vjm le 22 août 2003 à 22:29. Évalué à 9.
        
        Aloooooooooooors.
        Pour la petite histoire, LaBrea, qui est à l'origine du concept et du nom tarpit, était aussi l'un des tous premiers outils à être considéré comme un honeypot. Or les honeypots c'est l'outil à la mode dans la sécurité (ça va par phase, les firewalls, les IDS, maintenant les honeypots...).
        
        Sinon, si tu regardes avec attention les conférences données ces derniers temps lors des meetings NANOG, on se rend compte que les tarpits sont utilisés à grande échelle chez des ISP de même que les blackholes comme moyens de défense, et les sinkholes comme outils d'analyse. En ajoutant un tarpit, je peux, en plus d'empêcher ou d'analyser la propagation d'un worm/scan/attaque, la ralentir. Dans le cas d'un scan ça permet également d'affoler des outils comme nmap donc de limiter le mapping. Il y a même une société (dont j'ai oublié le nom désolé) qui vend une blackbox qui fait du firewall et du so-called "system cloacking" en détectant les scans et en y répondant par un "tous les ports ouverts sur toutes les machines".
        
        D'autre part, un tarpit, comme tout système lié aux honeypots, peut se révéler un outil de détection redoutable si il est utilisé avec des adresses non-allouées ou type RFC 1918. Là, tu reçois que du trafic nécessairement illégitime, ce qui permet de mettre en place les réponses appropriées (valable aussi pour les sinkholes).
        
        Dernier point, 500k connexions simultanées c'est pas si inhabituel que cela sur de très gros réseaux. Et dire que ça devrait être géré par du hardware ça n'a aucun sens, y'a tjrs un peu de software derrière, pour du routage, du filtrage ou du service.
        Et quand il y a plus de RAM si tu gicles pas des connexions tu crashes, point barre. Il y a juste les syncookies qui sur Linux et BSD servent de système de secours, mais ce n'est valable que pour les end hosts.
        
        my 2 eurocents.
        
        [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables (HS)
        
        Posté par vjm le 22 août 2003 à 22:46. Évalué à 3.
        
        ah oui j'oubliais :
        l'idée n'est pas neuve, route l'avait déjà proposé dans une suite de proof of concept contre des faiblesses de TCP, et ce dans phrack 49 (soit 1996). Et comme c'est laissé entendre dans plusieurs commentaires, c'est basé sur le comportement de TCP face à une window size annoncée à zéro (entraînant 3 window probes avec des timers de malade).
        
        Autre chose, ça a l'avantage d'emmerder cordialement un worm qui n'aurait pas de timeout interne puisqu'il sera _obliger_ d'attendre que TCP lui rende la main au bout de 3 window probes...
        
        wéé, bientôt 10 eurocents...
        
        [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables (HS)
        
        Posté par vjm le 23 août 2003 à 05:14. Évalué à 2.
        
        ok, au temps pour moi, je me suis emmêler les pinceaux entre les différents timers TCP.
        
        si j'en crois les RFCs, il n'y a aucun limite _imposée_ pour le nombre de window probes, l'experimentation ayant montré que la majorité des implémentations s'arrêtaîent autour de 10/15 probes. Le persist timer pouvant aller jusqu'à 60 secondes (mais dépendant du retransmission timer avant cela), on peut donc ralentir un worm de 10 à 15 maximum.
        
        Plus amusant, il semble que des problèmes de deadlock existent pendant des window probes. Si celles-ci ne sont pas proprement notifiées auprès de l'application qui tente d'envoyer des données, la send window se remplit, entraînant un crash de la connexion.
        
        comme toujours, pour les détails, google est votre ami (ou richard stevens).
        
        [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables (HS)
        
        Posté par Foxy (site web personnel) le 23 août 2003 à 13:36. Évalué à 2.
        
        Dernier point, 500k connexions simultanées c'est pas si inhabituel que cela sur de très gros réseaux. Et dire que ça devrait être géré par du hardware ça n'a aucun sens, y'a tjrs un peu de software derrière, pour du routage, du filtrage ou du service.
        
        Oui tout à fait, ce genre de conf se trouve dans certains gros réseaux : c'est pour cela que je teste les produits de ma boite dans ces conditions --> vendre notre produit pour des "grosses" installations.
        
        Evidemment qu'il y a du software pour générer ces connexions sur mon outil de benchs. Ce que je veux dire par génération hardware, c'est que sur mon outil il y a des puces spécialisés chargés de générer le traffic TCP/IP : cela permet d'être sûr des capacités de génération (nb nouvelles cnx/s, throughput...). Pour ceux que ça intéresse, voir l'outil Smartbits de Spirent Telecom.
      - [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
        
        Posté par un_brice (site web personnel) le 22 août 2003 à 15:47. Évalué à 3.
        
        Tu peut établir plusieures connections à destination du même port (cf http:80), juste en forgeant des adresses sources (tu peut aussi ne rien forger, et faire 500 000 requêtes simultanées sur le même port avec la même adresse, mais là c'est plus des considéré comme des connections complètes).
    - [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
      
      Posté par Nap le 22 août 2003 à 14:28. Évalué à -2.
      
      j'ai déjà fait prendre 500000 connexions TCP simultanées à un noyau Linux et ils les tenaient bien
      
      c'était une SUSE ? :o)
      
      BLAM_o/*---------------------> []
  - [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
    
    Posté par Jonathan ILIAS-PILLET (site web personnel) le 25 août 2003 à 09:21. Évalué à 1.
    
    un autre avantage à TARPIT : l'utiliser sur tous les ports normalement fermés de la machine, ça perd nmap qui voit 2^16 ports ouverts
    
    La cible DROP est assez efficace pour faire cela. Non seulement cela permet une économie des ressources de la machine, mais aussi, cela me semble être une réaction moins "agressive" à quelque chose qui n'est pas forcément hostile.
    
    Parce que si le filtre est correctement écrit (correspond effectivement à un vers), le piège TARPITS est une bonne chose, sinon, je pense que ça pourrait-être assez nuisible (par exemple, ça ralentirait inutilement les scans pour le P2P).
    
    Au passage, je me pose une question, le timeout correspondant à la réponse après un SYN est moins long que celui d'un ACK lors d'une connexion établie ? Parce que si ce n'est pas le cas, je préfère DROP ;)
- [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
  
  Posté par Tripnotik le 22 août 2003 à 14:03. Évalué à 7.
  
  La réponse est dans la question ;o)
  Un vers qui se répand sur des millions de machines et qui est ralenti nous permet à nous utilisateurs de GNU/Linux de ne pas souffrir d'un réseau surchargé quand on fait un emerge ou apt-get, etc, ou lorsque l'on surfe sur DLFP ... ;o)
  
  Ce qui d'ailleur répond au post dessous (dans la conclusion du moins) parce que ce n'est pas forcément pour "sauver" les utilisateurs de windowsçapucpaslibre mais de tous nous aider à surfer normalement ...
  
  Cette solution ne sert pas à éradiquer mais seulement à ralentir la propagation d'un vers.
- [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
  
  Posté par Brunus le 22 août 2003 à 14:15. Évalué à 3.
  
  Il ne sagit pas de seulement de quelques secondes...la page netfilter.org est de nouveau joignable, il serait interessant d'aller y lire la description du patch IPT-TARPIT.
# Efficécité relative.....

Posté par Vanhu le 22 août 2003 à 13:38. Évalué à 10.

Franchement, se baser la dessus pour ralentir de facon significative la propagation de vers, ca me parait complètement illusoire:

1) Deja, faudrait que *plein* de monde utilise ce genre de "pièges" pour que ca ait la moindre chance d'etre vaguement efficace.

2) Pour les vers en VBasic, a la rigueur, mais le coup de ne pas répondre aux FIN (les paquets de demandes de fin de connexion) du ver, bah il "suffit" (ok, c'est pas a la portée du premier Jean Kevin venu) d'envoyer un RST et de dire "ok, il fait ce qu'il veut en face, j'ai prévenu, et de toutes facons je suis un méchant ver alors je m'en fous".

3) Depuis le temps qu'on recommande a "tout le monde" (sauf gros serveurs publics ou c'est tres discutable), et y compris aux particuliers (qui sont quand meme de belles cibles pour les worms) de faire *en plus* de l'obscurité (DROP au lieu de REJECT, quoi), bah la c'est rapé !
Et le patch nmap pour détecter des ports "TARPITed", m'est avis qu'il va pas mettre longtemps a sortir....

En gros, encore du temps perdu pour trouver des bricolages de contournement, au lieu de s'attaquer aux vrais problèmes !
- [^] # Re: Efficécité relative.....
  
  Posté par PloufPlouf (site web personnel) le 22 août 2003 à 16:59. Évalué à 1.
  
  ton commentaire semble assez interessant, mais aussi un peu trop technique... mets le à là porté de tout le monde si tu veux qu'on puisse apprécier la pertinence de ton analyse....
  - [^] # Re: Efficécité relative.....
    
    Posté par Vanhu le 22 août 2003 à 20:04. Évalué à 0.
    
    Y'avait qu'a demander :-)
- [^] # Re: Efficacité relative, les détails (1)
  
  Posté par Vanhu le 22 août 2003 à 19:41. Évalué à 10.
  
  Attention, explications simplifiées
  
  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: tout est relatif....
  
  Posté par Vanhu le 22 août 2003 à 19:46. Évalué à 8.
  
  Bien, sortez vos cahiez, vos crayons, calculatrice autorisée.
  
  "Soit un ver, capable de se propager d'une machine vers une autre machine infectable en quelques secondes"..... "en .... quelques .... secondes....."
  
  "Soit une quantité de machines infectables de l'ordre du ..... ouhla, beaucoup, on va dire du million en moyenne (meme si c'est parfois un peu moins, ca donne un ordre d'idée)".
  
  'Soit maintenant une certaine quantité de machines, qui, lorsque le ver tente de se propager dessus, lui font perdre... allez, je vais etre gentil, je vais dire 30 minutes".
  
  "Quelle est la proportion de ces machines "ralentisseuses" nécessaire pour avoir un effet quelconque ?"
  
  Question subsidiaire: soit maintenant une version threadée/etc... de ce ver, capable de tenter de se propager simultanément sur plusieurs machines, refaites le calcul.....
- [^] # Re: Efficécité relative: la session TCP
  
  Posté par Vanhu le 22 août 2003 à 19:53. Évalué à 8.
  
  Bien, comme nous avons vu au dessus, nous avons "plein" de machines "TARPITeuses", qui font la chose suivante:
  
  - j'autorise une session TCP vers un port "vulnérable", derriere lequel il n'y a en fait pas de serveur chez moi.
  
  - Je négocie les paramètres de la session pour que celle ci soit inutilisable en pratique
  
  - J'ignore les paquets FIN (demande polie de fin de session) pour faire durer ca le plus longtemps possible.
  
  Soit un ver "JeanKevin"(C)(R), ecrit en VBScript, Delphi, ADA, Java, Perl, (voire en C, hein, ca change pas grand chose, ceci n'est pas un appel a troll), en utilisant la couche réseau "classique".
  
  Bah effectivement, il va surement se faire couillonner.
  
  Maintenant, soit un ver fait par un gars pas couillon (on est d'accord, ca reste définitivement hors de portée de Jean Kevin, sauf si le gars pas couillon fait une belle librairie toute propre qu'il diffuse), dans un langage et avec des fonctions qui permettent de manipuler "plus bas niveau" les paquets.
  
  Bah il a plus qu'a detecter les "parametres louches", qui feront qu'une session sera peu/pas utilisable, et forcer une fin de connexion brutale par un RST (Reset: "on coupe tout cherche meme pas a me repondre a ca, je te previens par pure politesse, ca me perdra un jour").
  
  Et hop, au lieu de perdre 10 secondes, on en a perdu 30 a tout casser....
  Conclusion: efficacité très faible, meme avec "assez de machines TARPITeuses".
- [^] # Re: Efficacité relative..... et en plus faut se montrer !!!
  
  Posté par Vanhu le 22 août 2003 à 20:03. Évalué à 10.
  
  Donc vous n'avez pas écouté ce vieux fou qui vous dit que ca va pas marcher, et vous vous dites que "c'est toujours ca de gagné pour ralentir les vers, et puis ca coute rien, hein"......
  
  Bah si, ca coute: Je ne parlerai meme pas du coté "expérimental" du patch, ca, ca va s'améliorer, je suppose.
  
  Mais voyons les implications, meme avec un patch "release-top-mega-fiable":
  
  Actuellement, tout le monde recommande de se "planquer".
  
  Pourquoi ? parceque la sécurité par l'obscurité (oui, c'est comme ca que ca s'appelle) a beau etre une mauvaise base, c'est un bon complément.
  
  Ainsi, un attanquant potentiel, qui commencera probablement par faire un scan de ports sur votre machine (qui va essayer de voir quels sont les ports à l'écoute) sera probablement "bluffé" si vous n'avez aucun service, ou meme s'il n'a pas utilisé l'option -P0 de nmap (qui dit a nmap de ne pas se baser sur un bete ping pour savoir s'il y a quelqu'un).
  
  Et meme avec toutes ces options, comme expliqué plus haut ("le firewall pas poli"), c'est toujours ca de gagné comme temps pour le scan....
  
  La, vous allez répondre à toutes les demandes de connexion TCP.
  
  Quel est le problème ?
  
  D'abord, vous affirmez haut et fort au monde entier que vous etes la.
  Ensuite, vous donnez plein de paquets pour aider le scanner a déterminer votre OS.
  
  Oui, mais au moins, comme vous répondez à toutes les demandes de connexions, bah il va croire que tous vos ports sont ouverts, ca le brouille aussi, ca !!!
  
  Bah non: les ports TARPITés auront un comportement bien spécifique, puisqu'ils vont négocier une session TCP non utilisable.
  Et des outils comme nmap, bah ce genre de "singularités", leur faudra pas longtemps pour les détecter, et faire la différence entre un port OPEN et un port TARPIT.
  
  Et vous voulez savoir la meilleure ?
  Comme il y aura surement de subtiles différences d'implémentations, bah ca les aidera meme à identifier votre OS de facon plus fiable.....
  
  Alors faites comme vous le sentez, moi je reste en DROP !
  - [^] # Re: Efficacité relative..... et en plus faut se montrer !!!
    
    Posté par vjm le 22 août 2003 à 22:38. Évalué à 3.
    
    étant donné que l'implémenteur du tarpit sur netfilter a fait preuve d'un manque d'originalité stupéfiant (c'est _exactement_ la même technique que LaBrea), alors oui y'a un patch nmap qui doit déjà être en cours (65000 ports qui font du window advertisement à 0, en contradiction complète avec des mesures de connectivité d'hôte ou à l'exception de 3 ports qui fonctionnent impec', etc. c'est suspect).
    
    Par contre, vu que c'est basé sur des principes TCP ultra génériques, faut vraiment générer ses paquets n'importe comment pour créer des subtilités d'implémentations décelables.
    
    Mais bon, c'est une des variantes de mise en place d'un honeypot. Un honeyd couplé à un firewall pourrait faire la même chose, de même qu'un sinkhole qui annonce des bogons, etc. Ca reste intéressant si c'est un gros réseau qui le déploie largement et consciensieusement.
    
    ça va faire 4 eurocents.
    
    PS : c'est quoi ce flood de posts en 15 min ?
    - [^] # Re: Efficacité relative..... et en plus faut se montrer !!!
      
      Posté par Vanhu le 23 août 2003 à 17:19. Évalué à 2.
      
      Par contre, vu que c'est basé sur des principes TCP ultra génériques, faut vraiment générer ses paquets n'importe comment pour créer des subtilités d'implémentations décelables.
      
      En théorie oui, mais comme d'habitude, il suffira peut etre de faire un truc "pas courant" pour commencer à voir plein de différences selon les implémentations.....
      
      Et le simple fait de faire (ou pas) du TARPIT sera déjà un indice, de toutes facons...
      
      PS : c'est quoi ce flood de posts en 15 min ?
      
      Bah c'etait en "reponse" a la premiere reponse de mon premier post: "ca a l'air intéressant mais j'y comprends rien, tu pourrais expliquer" :-)
    - [^] # Re: Efficacité relative..... et en plus faut se montrer !!!
      
      Posté par Nicolas Antoniazzi (site web personnel) le 25 août 2003 à 22:37. Évalué à 1.
      
      Très interressant :)
      
      PS : c'est quoi ce flood de posts en 15 min ?
      
      C'est une super technique... plus tu mets de posts interressant, plus tu gagnes d'XP :) en plus d'avoir des connaissances réseau, le Vanhu est très futé :)
# Re: TARPITS : Ralentir la propagation des vers avec IPtables

Posté par Code34 (site web personnel) le 22 août 2003 à 13:48. Évalué à -2.

Trop mortel , la technique !

Un simple drop des paquets tcp entraine un timeout pas la peine d'ouvrir les ports tcp, c'est completement ridicule.
- [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
  
  Posté par Code34 (site web personnel) le 22 août 2003 à 13:50. Évalué à -2.
  
  Je voulais dire un drop des paquets syn provoque la meme chose, j'espere que tout le monde m'a compris.
- [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
  
  Posté par Foxy (site web personnel) le 22 août 2003 à 14:07. Évalué à 5.
  
  Non c'est pas la même chose, avec ta technique, la connexion TCP du vers attends juste le time-out dû au DROP.
  
  Avec TARPIT, la connexion TCP reste établie et bouffe plus de resources au vers.
  - [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
    
    Posté par Code34 (site web personnel) le 22 août 2003 à 16:11. Évalué à 4.
    
    Dropper les syn, c'est stoppé l'utilisation abusive de la bande passante, en jartant tout de suite les demandes de connexions.
    
    Tandis qu'ouvrir une connexion tcp c'est à la base admettre qu'il y aura plus de 3 paquets échangés + tout les paquets que le vers renverra pour controler l'état, ou faire son mic-mac.
    
    Ce qui ouvre la voix à des problemes de sécurité multiples:
    - possibilité d'utiliser un exploit sur les ports ouverts,
    - occuppation de tout les ports,
    - tenter des exploits sur le hashage des connexions dans la pile ip etc ...
    - [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
      
      Posté par Foxy (site web personnel) le 22 août 2003 à 16:23. Évalué à 1.
      
      Mais faut savoir ce que tu veux : si tu droppes les SYN, effectivement tu bouffes pas de resource sur ton FW.
      
      Si tu utilises TARPIT, tu emmerdes les vers mais tu bouffes aussi des ressources sur ton FW. Je suis bien d'accord avec ça...
      - [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
        
        Posté par Code34 (site web personnel) le 22 août 2003 à 16:29. Évalué à 9.
        
        Et puis, on peut aussi envisager un autre cas de figure des vers windows qui seraient spécialement conçu pour se reproduire et plomber les machines firewall ayant un comportement comme celui de Tarpit.
        
        Franchement, je pense que moins un firewall montre un comportement "spécial" face à une attaque, et moins il est vulnerable aux attaques. Il suffit de regarder les options de nmap pour se rendre compte que l'analyse du scanner tire des conclusions essentiellement de se genre de comportement.
        
        Maintenant, je me vois mal entrain de mettre en place un firewall qui ralentirait des vers spécialement pour sauver les machines windows.
        
        Alors que c'est à Microsoft de gerer le probleme à la base.
        
        [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
        
        Posté par Da Scritch (site web personnel, Mastodon) le 22 août 2003 à 21:46. Évalué à 8.
        
        Je propose un "ver gentil" qui corrige le problème pour toutes les machines windows : après sa propagation, il supprime définitivement la couche ip du système :
        C'est trop dangereux pour un windows, et cela évitera à l'avenir toute infection par le réseau de la machine. Comme ça, la machine restera systématiquement saine et n'auraplus besoin de patch et autres SP...
        Simple et efficace non ? non ?!? ok je ---->[]
        
        [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
        
        Posté par Gloo le 23 août 2003 à 13:18. Évalué à 3.
        
        "c'est à Microsoft de gerer le probleme à la base"
        
        Comme Microsoft fait la preuve jour après jour qu'il est incapable de gerer ce genre de problème, c'est au responsable NTIC de gerer le problème, par exemple, en supprimant de son parc le socle de toutes ces merdes: Windows.
        
        [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
        
        Posté par _ _ le 23 août 2003 à 14:28. Évalué à 1.
        
        comme je l'ai expliqué plus bas, les vers n'ont rien de spécifique à Windows, d'ailleurs il y'a des vers qui ciblent les machines sous Linux.
        
        Le seul truc c'est que la vitesse de propagation d'un ver sous Linux sera toujours bcp plus faible car il est plus difficile de trouver des machines à infecter.
        
        [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
        
        Posté par Gloo le 23 août 2003 à 14:42. Évalué à 1.
        
        "les vers n'ont rien de spécifique à Windows"
        
        Je n'ai pas dit le contraire. Le fait est qu'aujourd'hui ce sont bien les produits microsoft qui font des ravages. Ils sont nombreux sur le net, ET se sont des passoires.
        
        Comme je n'espère rien de microsoft, ni des "admins" de ce type de machine, ni de leurs utilisateurs (dont ce n'est pas le boulot), je propose une solution radicale.
        
        Perso, je trouve le projet TARPIT completement inutile, interessant certes, mais jouent sur le protocole reseau alors que c'est les applications (et les utilisateurs) qui posent problème.
        
        [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
        
        Posté par Nap le 24 août 2003 à 02:15. Évalué à 0.
        
        ouaaiiis !
        
        fUcK WiN$hIT KIPU !! Li|\|uX Ro><><or & FREE BSD RoULaiZz :o)
      - [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
        
        Posté par vjm le 23 août 2003 à 12:13. Évalué à 3.
        
        pas vraiment, ça n'entraîne aucune création de structure dans la mémoire type conn_track pour suivre les connexions sur ces ports. Les window probes peuvent être envoyés de manière totalement stateless et ne consomment que très peu de bande passante, cela même avec 65000 ports annoncés tarpited (soit 65000 fois un segment TCP sans payload toutes les 60 secondes, je suis nul en calcul :).
- [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
  
  Posté par Brunus le 22 août 2003 à 14:08. Évalué à 9.
  
  Je me suis posé la question aussi...mais ce qui est décrit sur la page Netfilter me semble plus efficace qu'un simple drop :
  
  Connections are accepted, but immediately switched to the persist state (0 byte window), in which the remote side stops sending data and asks to continue every 60-240 seconds.
  Attempts to close the connection are ignored, forcing the remote side to time out the connection in 12-24 minutes.
# Re: TARPITS : Ralentir la propagation des vers avec IPtables

Posté par Frédéric Desmoulins (site web personnel) le 22 août 2003 à 14:11. Évalué à 3.

Je confirme, le patch TARPIT est dors et déjà disponible (depuis 8 jours exactement) sur le dernier kernel Gentoo (gentoo-sources 2.4.20-r6).

A vos emerge !
# Re: TARPITS : Ralentir la propagation des vers avec IPtables

Posté par Encolpe DEGOUTE (site web personnel) le 22 août 2003 à 14:15. Évalué à 2.

NdM: Le serveur de netfilter ne repond pas, auraient ils par erreur fait un iptables -A INPUT -p tcp -m tcp --dport 80 -j TARPIT ? :-)

C'est le fameux effet DLFP? ;^)
D'où une question:
Que se passe-t-il lorsque l'on slashdote Slashdot?
Et lorsque l'on slashdote DLFP?
- [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
  
  Posté par Vigon Rene le 22 août 2003 à 15:07. Évalué à 5.
  
  Et lorsque l'on slashdote DLFP?
  
  Pas la peine, car avec Apache/php/templeet, DLFP se /. tout seul...
  
  Je vais trouver tout seul ----> [ /o\ ] ,
  Ceux qui ont sont déjà, pas taper...merci.
  - [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
    
    Posté par Ramso le 22 août 2003 à 17:10. Évalué à 6.
    
    rhoooo !
    
    c'est vilain de troller alors que des tests irréfutables ont montré que templeet/php/mysql/apache est plus rapide que apache tout seul !
    - [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
      
      Posté par Dugland Bob le 22 août 2003 à 21:57. Évalué à 3.
      
      le tout pour servir des pages de cache pas trop à jour.
# Re: TARPITS : Ralentir la propagation des vers avec IPtables

Posté par stéphane le 22 août 2003 à 14:37. Évalué à 4.

J'ai lu que certains vers utilisent le protocole UDP qui ne serait par nature pas affecté par ce type de parade, dont celui qui avait attaqué SQL server sur les machines Windows au début de l'année. Quelqu'un pourra peut etre nous en dire plus mais si c'est vrai la protection en question ne sera donc pas efficace ?
- [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
  
  Posté par neerd le 22 août 2003 à 15:07. Évalué à 4.
  
  Le protocole UDP fonctionnant par définition en mode non connecté, le vers n'attend pas de réponse, il envoit le paquet et s'en bat de ce qui en ai fait après ...
  
  Donc TARPITS en fonctionnera pas contre ce type de vers.
  - [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
    
    Posté par Frédéric Desmoulins (site web personnel) le 22 août 2003 à 23:39. Évalué à 2.
    
    " Le protocole UDP fonctionnant par définition en mode non connecté, le vers n'attend pas de réponse"
    
    Ta premiere affirmation est vraie, la seconde pas toujours vraie, donc fausse.
- [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
  
  Posté par fabien le 22 août 2003 à 15:25. Évalué à 2.
  
  oui d'autant plus que s'est quand même plus simple de faire de l'UDP, on s'en fou u peu de gerer une connexion, c'est qu'un ver quand même. moi si j'avais a faire un ver en VBA je me ferais ps chier avec du TCP.
  - [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
    
    Posté par Vanhu le 22 août 2003 à 21:20. Évalué à 2.
    
    TCP ou UDP, c'est pas selon l'humeur du développeur du ver: c'est en fonction du protocole utilisé par le service qui a une faille, et qu'on veut exploiter !!!
    
    Et puis les connexions TCP, quand tu utilises les sockets, ca se gere *presque* tout seul, alors....
    - [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
      
      Posté par mouledog le 23 août 2003 à 11:17. Évalué à 2.
      
      "Et puis les connexions TCP, quand tu utilises les sockets, ca se gere *presque* tout seul, alors.... "
      
      C'est sur que gérer `à la main' une connection TCP c'est tout de suite plus dur :)
# Chacun sa merde

Posté par KDO le 22 août 2003 à 15:45. Évalué à 0.

Franchement quel perte de temps et d'énergie pour essayer de voler au secours du système ennemi. Windows est pourri coté sécure ? C'est son problème, pas celui de Linux, ils n'ont qu'à se démerder tout seuls.
Quand aux hébergeurs de serveurs je me demande quelle serait leur attitude si tous ceux qui font héberger des serveurs Linux ou BSD les attaquaientt pour oser héberger aussi des serveurs sous Windaube causant régulièrement des pertes d'exploitation par baisse de la BP. A quand un label 'Hébergeur guarantit sans Winmerde' ?
Bref encore une connerie de plus dans notre camp des LL.

PS: Oui, je sais je vais me faire ultra-moinsser. bof.
- [^] # Re: Chacun sa merde
  
  Posté par Xavier Teyssier (site web personnel) le 22 août 2003 à 15:51. Évalué à 2.
  
  Franchement quel perte de temps et d'énergie pour essayer de voler au secours du système ennemi. Windows est pourri coté sécure ? C'est son problème, pas celui de Linux, ils n'ont qu'à se démerder tout seuls.
  
  Pas d'accord! Quand un réseau devient bien trop lent pour que je puisse surfer, c'est peut-être des Windows pourris qui en sont la cause, mais c'est moi (entre autre) qui en patis.
  Donc si, c'est _aussi_ notre problème !
  - [^] # Re: Chacun sa merde
    
    Posté par Sylvain Briole (site web personnel) le 22 août 2003 à 16:16. Évalué à 3.
    
    Donc si, c'est _aussi_ notre problème !
    
    C'est clair, le seul truc qui me dérange : je n'ai pas de données chiffrées en tête, mais quelle est la proportion de l'occupation du réseau par ce genre de vers par rapport à tous les spams et autres gags du genres?
    
    Personnellement, ce qui m'a longtemps ennuyé, ce sont les tentatives des réseaux Kazaa et assimilés sur le port 80 : là cela ralentissement fortement mon trafic, ma machine, sans compter mon FAI qui a été d'ailleurs obligé de "priotiriser" le trafic en conséquence.
- [^] # Re: Chacun sa merde
  
  Posté par Brunus le 22 août 2003 à 16:13. Évalué à 2.
  
  On en a déjà parlé en début de post...si tu relis les premiers commentaires tu auras déjà des éléments de réponse.
  
  Comme par exemple...nous aussi nous sommes emmerdés par les vers qui attaquent les systèmes Microsofts...parcequ'ils nous bouffent de la bande passante.
  
  Voir le commentaire de Tripnotik
  
  Dans la news sur security focus il est aussi bien expliqué que cette méthode est utilisable sur les serveurs *BSD et windows...donc ON ne vole pas au secour de qui que ce soit...on expérimente juste une méthode et par hasard, le premier système impliqué est Linux...
- [^] # Re: Chacun sa merde
  
  Posté par gnu_thomas le 22 août 2003 à 17:05. Évalué à -1.
  
  Ben si on est complètement concerné.
  
  Tout d'abord, il ne faut pas associer linux et netfilter. netfilter est un LL il peut être réutiliser dans de nombreux projets. Donc toutes études et expérimentations dessus est une bonne chose.
  
  Deuxièmement, je ne sais pas si ces vers ralentissent bcp internet ou pas mais ce qui est sûr, c'est qu'ils remplissent les logs de mon serveur apache (cmd.exe, default.ida, ...)
  - [^] # Re: Chacun sa merde
    
    Posté par Vanhu le 22 août 2003 à 21:25. Évalué à 4.
    
    Tout d'abord, il ne faut pas associer linux et netfilter
    
    Euh.... si, un peu quand meme: Netfilter est quand meme le système de filtrage du noyau Linux, et (apres une tres sommaire recherche, je veux bien le reconnaitre) je n'ai pas vu de traces d'un portage de Netfilter sur d'autres architectures.....
- [^] # Re: Chacun sa merde
  
  Posté par _ _ le 22 août 2003 à 23:03. Évalué à 5.
  
  Le coup des vers, ça n'a rien de spécifique à windows. D'ailleurs il y a deja eu des vers sous Linux, en plus la faille de sécurité du ver actuel MSBLASTER touche un service RPC de DCOM, ce qui est plus ou moins la même chose que le buffer overflow que tu trouve dans le démon rpc.statd installé par défaut sur Redhat 6.2.
  
  Non, la seule raison pour lesquels tous les vers connus sont sous windows, c'est parce que le succés d'un ver dépend de sa rapidité de propagation, donc il faut que la faille de sécurité soit répandue.
# Re: TARPITS : Ralentir la propagation des vers avec IPtables

Posté par yoho (site web personnel) le 22 août 2003 à 15:57. Évalué à 2.

Je croyais que Labrea avait été arrêté parceque l'auteur était menacé de poursuites (http://linuxfr.org/2003/04/22/12135.html(...)).

Ils ne craigne pas la même chose pour la target TARPIT ? (note : je remarque que labrea est toujours en ligne en ce moment)
# OpenBSD / PF vaincra

Posté par Foxy (site web personnel) le 22 août 2003 à 17:18. Évalué à 10.

De toute façon, ça n'arrive pas à la cheville du dernier commit CVS dans le code de PF (Packet Filter, équivalent de Netfilter) sur OpenBSD.

Maintenant on peut écrire des règles de firewalling avec comme cible l'OS client reconnu par passive fingerprinting du paquet SYN.

Ca permet d'ecrire des règles du genre :

block proto tcp from any os SCO
block proto tcp from any os Windows to any port smtp

Voir pour plus de détails :
- http://deadly.org/article.php3?sid=20030821153534(...)
- http://www.w4g.org/fingerprinting.html(...)
- [^] # Re: OpenBSD / PF vaincra
  
  Posté par pasPierre pasTramo le 22 août 2003 à 18:20. Évalué à 6.
  
  Reste a verifier la solidité de l'os fingerprinting , parcrque si c'est comme nmap ...
# Re: TARPITS : Ralentir la propagation des vers avec IPtables

Posté par Jerome Herman le 23 août 2003 à 13:44. Évalué à 7.

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.

Kha
- [^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
  
  Posté par elamapi le 25 août 2003 à 14:13. Évalué à 1.
  
  Heu ....
  si tous les FW (cas de ma boite) empechaient TOUT le monde de sortir de l'intranet, sauf HTTP en port 80,8080,81 et FTP en port 20,21 , voir ouvrir quelque autre port spécialisé pour l'activité de la société (conf assez simple a mettre en place avec n'importe quelle distrib linux).
  Les vers présents sur les PC de l'intranet qui essaient t'aller taper a l'exterieur sur autre chose que ces port se ferai jetter. Deja c'est pas mal et simple a faire. Et puis si vraiment on veut jouer on peut tout aussi simplement rajouter un pont + snort qui génère des regle iptables dynamique. Et la ca réduit encore plus les chance qu'un truc "pas bien" sorte attaquer l'extérieur. Ca reste tres simple a mettre en place.
  
  Et puis pour les malade du MSN ou peu ajouter un socks5 (dante) avec passwd. Ainsi on controle (mots de passe ) qui accede a koi et ou.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.