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 . Évalué à 0.
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) . Évalué à -1.
[^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par Pascal Terjan (site web personnel) . Évalué à -1.
# Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par Hobgoblins Master (Mastodon) . Évalué à 3.
[^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par free2.org . Évalué à 6.
[^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par Nicolas . Évalué à 4.
# Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par cedricv . Évalué à 6.
[^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par gege (site web personnel) . Évalué à 10.
* 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) . Évalué à 4.
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 . Évalué à 1.
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) . Évalué à 2.
[^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par ours Ours (site web personnel) . Évalué à 10.
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) . Évalué à 3.
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) . Évalué à 5.
[^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables (HS)
Posté par un_brice (site web personnel) . Évalué à 1.
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 . Évalué à 9.
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 . Évalué à 3.
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 . Évalué à 2.
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) . Évalué à 2.
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) . Évalué à 3.
[^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par Nap . Évalué à -2.
c'était une SUSE ? :o)
BLAM_o/*---------------------> []
[^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par Jonathan ILIAS-PILLET (site web personnel) . Évalué à 1.
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 . Évalué à 7.
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 . Évalué à 3.
# Efficécité relative.....
Posté par Vanhu . Évalué à 10.
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) . Évalué à 1.
[^] # Re: Efficécité relative.....
Posté par Vanhu . Évalué à 0.
[^] # Re: Efficacité relative, les détails (1)
Posté par Vanhu . É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....
[^] # Re: Efficacité relative: tout est relatif....
Posté par Vanhu . Évalué à 8.
"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 . Évalué à 8.
- 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 . Évalué à 10.
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 . Évalué à 3.
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 . Évalué à 2.
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) . Évalué à 1.
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) . Évalué à -2.
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) . Évalué à -2.
[^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par Foxy (site web personnel) . Évalué à 5.
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) . Évalué à 4.
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) . Évalué à 1.
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) . Évalué à 9.
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) . Évalué à 8.
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 . Évalué à 3.
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.
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 . Évalué à 1.
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 . Évalué à 0.
fUcK WiN$hIT KIPU !! Li|\|uX Ro><><or & FREE BSD RoULaiZz :o)
[^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par vjm . Évalué à 3.
[^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par Brunus . Évalué à 9.
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) . Évalué à 3.
A vos emerge !
# Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par Encolpe DEGOUTE (site web personnel) . Évalué à 2.
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 . Évalué à 5.
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 . Évalué à 6.
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 . Évalué à 3.
# Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par stéphane . Évalué à 4.
[^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par neerd . Évalué à 4.
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) . Évalué à 2.
Ta premiere affirmation est vraie, la seconde pas toujours vraie, donc fausse.
[^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par fabien . Évalué à 2.
[^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par Vanhu . Évalué à 2.
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 . Évalué à 2.
C'est sur que gérer `à la main' une connection TCP c'est tout de suite plus dur :)
# Chacun sa merde
Posté par KDO . Évalué à 0.
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) . Évalué à 2.
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) . Évalué à 3.
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 . Évalué à 2.
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 . Évalué à -1.
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 . Évalué à 4.
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.
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) . Évalué à 2.
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) . Évalué à 10.
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 . Évalué à 6.
# Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par Jerome Herman . É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
[^] # Re: TARPITS : Ralentir la propagation des vers avec IPtables
Posté par elamapi . Évalué à 1.
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.