TARPITS : Ralentir la propagation des vers avec IPtables

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
0
22
août
2003
Sécurité
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

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

    Posté par  . É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  (site Web personnel) . Évalué à -1.

    s/drapeaux_allemands/drapeaux_anglais/g
  • # Re: TARPITS : Ralentir la propagation des vers avec IPtables

    Posté par  . É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  . É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  (site Web personnel) . É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  (site Web personnel) . É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  . É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  (site Web personnel) . É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  (site Web personnel) . É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 (HS)

              Posté par  (site Web personnel) . É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  . É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  . É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  . É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  (site Web personnel) . É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  (site Web personnel) . É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  . É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  (site Web personnel) . É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  . É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  . É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  . É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  (site Web personnel) . É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: Efficacité relative, les détails (1)

      Posté par  . É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  . É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  . É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  . É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  . É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  . É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  (site Web personnel) . É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  (site Web personnel) . É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  (site Web personnel) . É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  (site Web personnel) . É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  (site Web personnel) . É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  (site Web personnel) . É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  (site Web personnel) . É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  (site Web personnel) . É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  . É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  . É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  . É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  . É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  . É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  . É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  (site Web personnel) . É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  (site Web personnel) . É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  . É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 ?
  • # Chacun sa merde

    Posté par  . É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  (site Web personnel) . É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  (site Web personnel) . É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  . É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  . É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  . É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  . É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  (site Web personnel) . É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  (site Web personnel) . É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: TARPITS : Ralentir la propagation des vers avec IPtables

    Posté par  . É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  . É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 à ceux qui les ont postés. Nous n’en sommes pas responsables.