Vanhu a écrit 447 commentaires

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.....

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....

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 !

Non, le evil bit des paquets entrants !!

Et encore, si le dangereux pirate informatique n'est pas up to date, et qu'il utilise des programmes obsoletes qui ne supportent pas la RFC3514, bah ca marche pas....

C'est LE defaut de cette RFC: elle n'est pas obligatoire pour de sombres raisons de compatibilité ascendante (alors que tous les développeurs d'OS et d'outils modernes ont sorti des patchs de conformité dans les quelques jours !!).

Si j'ai rien loupé:

17 mars 2003, une exploitation de ptrace circule sur le Net.

Une semaine plus tard: le patch kernel sort, et le site est patché.

A ce moment la, ils auraient du vérifier si leurs serveurs n'avaient pas été compromis pendant la semaine en question, alors que le site était vulnérable et qu'ils le savaient !!

Quand j'oublie de fermer la porte en partant de chez moi (rassurez vous, ca n'arrive jamais :-), et que je m'en rends compte en rentrant, bah j'attends pas 4 mois pour regarder si on m'a rien piqué/cassé/etc.... !!!!!

Ils ont rapidement appliqué le patch, ok, mais c'est quand meme affligeant s'ils n'ont meme pas vérifié que, pendant une semaine ou leurs serveurs étaient vulnérables, personne n'en a profité pour les compromettre !!

Et s'ils ont fait cette vérif, bah c'est a peine mieux puisqu'ils n'ont pas trouvé :-/

Ils ont de gros serveurs publics et bien visibles, ils savent qu'elles ont été vulnérables à un exploit pendant une semaine, et ils ont meme pas pensé à faire une vérification des machines après correction de la faille ????

T'as rien compris :-)

En fait, le poste client va emettre une requete DHCP "normale", qui va etre prise en compte par le serveur DHCP, qui va interroger le LDAP pour connaitre la conf a renvoyer, et va la renvoyer au client.

C'est donc Client DHCP <=> Serveur DHCP <=> Serveur LDAP.

je te plusserais bien si il me restait des votes mais j'ai tout utilisé aujourd'hui :)

Bah a demain, alors :-)


merci pour ton explication, le howto gardant son nez dans la ligne de commande, j'avais pas compris grand chose...

Bah c'est un peu ma faute, puisque je n'ai toujours pas remis le nez dans une grosse doc centralisant tout ce qui tourne autour de LDAP, et effectivement, Benj se sert a moitie de certains de ses articles sur Xenux comme "pense bete".

Mais on va y bosser, des que l'un de nous reveille l'autre :-)


je ne connais pas bien DHCP : ca permet aussi de gérer des machine dont on ne connait rien a priori non ?

Tout a fait. On peut reserver une conf a une machine dont on connait l'adresse MAC, par exemple, mais ca peut aussi servir a attribuer une configuration a des machines totalement "anonymes".


dans ce cas, il va utiliser quoi comme valeurs ? une ip n'existant pas dans une fiche ldap, et un nom d'hote au pif ? ou il va créer une fiche a ce moment la ?

Bah la j'ai créé une fiche correspondant a une machine, apres, pour ce que j'avais survolé de la conf DHCP en général, et de son report dans un LDAP, y'a moyen de créer des fiches "génériques", exactement de la meme facon qu'on crée des zones dans le dhcpd.conf.

Par contre, je ne comprend pas, tu dis que les infos de lease restent dans /var, mais tu les met aussi dans ta 'fiche machine'...

Euh, ouais, j'aurais du appeler ca DHCPMinLease, DHCPDefaultLease, etc...., mais comme je suis une grosse feignasse d'informaticien, j'ai fait rapide....


Je redis donc bien: on met dans le LDAP ce qui serait dans le dhcpd.conf sinon !

Monter un LDAP pour faire du dhcp ca fait un peu usine a gaz

Euh, oui, je trouve aussi, mais quand on a deja un LDAP qui centralise plein de choses, bah ca devient tout de suite plus intéressant !


Et puis si le leasing dhcp est un peu court, il va falloir souvent mettre jour les info dans l'annuaire

?????

C'est les infos de config du serveur DHCP qu'on stocke dans le LDAP, les infos "runtime" continuent a etre stockees en memoire/dans /var ou je sais pas ou ailleurs !


Je dit pas que c'est mal, mais bon, qu'est ce que ca apporte vraiment ? Ok, un ldap on peut l'interroger, struturer ces données, mais bon, ecrire un parser perl pour les logs du daemon dhcp c'est pas non plus trop dur.


Je crois que tu as pas bien compris ce qu'on met dans le LDAP...


On va avoir par exemple une fiche (euh, me souviens plus des noms d'attributs exacts, on va dire que c'est un schema "maison" :-):


dn: cn=PC1,ou=computers,o=worldcompany,dc=com
objectclass: top
objectclass: SMBHost
objectclass: DHCPHost
objectclass: DNSHost
SMBHostname: PC1
SMBDomain: WORLDCOMPANY
SMBDomainController: SERVER1
DHCPMACAddress: 00:aa:11:22:33:4a # vous embetez pas a verifier si c'est une MAC valide, hein :-)
DHCPLease: 3600 # value in seconds
DHCPIP: 192.168.2.1
DNSHostName: pc1.worldcompany.com

etc....

Une fiche sur le LDAP regroupe (toutes ?) les infos de conf de la machine.

Simple: la conf du DHCP est dans le LDAP.

Tu as donc, dans ton annuaire LDAP, des fiches pour les utilisateurs (qui regroupent eventuellement un inetorgperson, un posixaccount, un smbaccount, etc...), des fiches de machines (qui regroupent eventuellement les infos DHCP, les infos SMB, les infos DNS, et je sais pas quoi d'autre), etc.....

ma question est : peut-on réduire ce délai ? ou alors, peut-on définir la recherche ldap uniquement sur un périphérique réseau du genre eth0 et pas ppp0 ??

Dans le ldap.conf, pas a ma connaissance, mais indirectement, tu peux.

Le moyen le plus "simple" qui me vient a l'esprit (mais pas forcément le plus subtil :-) est de passer par des règles de filtrage: tu configure ton netfilter pour faire un REJECT (qui va donc poliment prévenir l'emetteur du SYN que la connexion est refusée) sur le port LDAP (389, ou 636 si c'est en LDAP/SSL) sur l'interface ppp0....

Normalement, le delai devrait passer a a peine quelques secondes....


Ou alors, tu mets en place un système de VPN entre ton portable et ton serveur, comme ca tu pourras carrément t'authentifier avec le compte LDAP dans ce cas de figure :-)

Bah tout est dans le nom: X500 est un DAP (Directory Access Protocol), et LDAP est un Lightweight Directory Access Protocol.....

Je suis aussi d'avis de dire qu'il a hérité de ce qui est bien en se débarassant de ce qui etait lourd (mais bon, je suis pas un dieu du X500 non plus....)

Oui et non.

La normalisation, c'est bien, mais ca retire de la souplesse.

Or, l'un des principaux avantages de LDAP, c'est justement d'etre souple, donc de pouvoir s'adapter aux besoins de chacun (et pas l'inverse).

Apres, il "suffit" que les programmes soient suffisamment configurables (ce qui n'a pas l'air d'etre le cas de ce demon DHCP pour l'instant) pour pouvoir parametrer le filtre de requete, et les attributs recuperes, et zou, on fait ce qu'on veut.

Donc oui a une normalisation des "bases" (ce qui est déjà fait, avec les Inetorgperson, Posixaccount, etc...), mais oui aussi a une certaine souplesse d'utilisation des annuaires !!!

Bah l'avantage d'OpenML, c'est justement d'etre soutenu et porté par un gros consortium d'industriels, ce qui est un atout de poids si on veut espérer des drivers/autres qui supportent ce standard.

Et c'est justement ca aussi qui fait que oui, il pourrait bien devenir un concurrent sérieux de DirectX un jour....

Et il en est fier, en plus :-)

Et qu'est ce qui t'a troublé comme ca pour que tu te trompes de facon aussi grossière ? :-)

L'est ou mon -1 ???

pour les BSD tu n'en as pas besoin

Euh, je suis pas convaincu, la: ce que reproche SCO, c'est d'avoir utilisé/diffusé "des trucs à eux" (je suis pas plus précis, forcément, eux non plus).

Demain, ils pourraient très bien proférer la même accusation (avec autant d'arguments irréfutables, n'en doutons pas ......) sur le noyau de FreeBSD (ou d'Open, ou de Net, je veux pas lancer de troll :-):

"Machin qui travaille chez truc a pris du code à nous, et l'a mis dans le noyau de XBSD, donc toute personne utilisant le noyau de XBSD doit nous acheter une licence".

Bon, j'en suis a la phase suivante, je crois donc etre bien placé pour te dire ce qui t'attend:

Ce que je fais:

1) Dev de Negas N&B chez moi (faut juste etre dans le noir absolu le temps de mettre les rouleaux dans la cuve, j'ai surement l'air con quand je m'enferme dans un placard, mais je fais ca quand il y a personne :-)

Cote prix, c'est un peu moins cher que le dev par un labo (surtout en N&B) une fois l'inverstissement initial (cuve, eprouvettes, etc...) fait, et surtout, on a un travail de qualité pour peu qu'on soigne bien le dev, et on fait ca chez soi, tranquillement.

2) Scan des négas en assez rapide, pour faire planche de lecture (la encore, l'avantage est de faire ca chez soi, et en plus ca ne necessite pas la préparation des chimies, l'utilisation de papier photo, etc....)

3) Agrandissement des épreuves intéressantes dans le labo de mon club photo, quand j'arrive a me motiver pour bloquer une demi journee, reserver le labo, etc......


Par contre, difficile d'exploiter les scans pour en ressortir quelquechose:

En N&B, j'obtiens souvent des gris sombres au lieu des noirs, et la sortie d'un N&B propre sur imprimante est tres dur.

En couleurs, Sane ne trouve JAMAIS les bons réglages de couleurs tout seul, il faut toujours ajuster et c'est delicat d'obtenir quelquechose de vraiment bien.

Il y a bien un programme fourni par Epson qui est censé utiliser le meme algo que la version Win du driver (ou a peu pres), mais j'ai jamais réussi a le faire fonctionner....

En ethernet, ca marche très bien avec Mpd, que ca soit en pptp ou en pppoe.

Apres, pour l'USB, il doit y avoir des portages des projets Linux, essentiellement, mais j'ai pas regarde de tres pres....

Pas moyen de retrouver la page qui explique ca, mais il me semble bien que le --state NEW est nécessaire sur une règle pour créer une entrée dans la table de connexion, donc pour pouvoir matcher les autres paquets de la connexion par un --state ESTABLISHED......

Des que j'ai 5 minutes de courage, je verifie par l'experimentation :-)

Du fait de son caractère orienté sur la sécurité, la commande "traceroute" ne peut s'exécuter qu'en temps que root.

Pas vraiment, c'est juste que /usr/sbin n'est normalement pas dans le PATH du simple user.



Euh, traceroute a besoin des droits de root pour fonctionner, puisqu'il travaille "bas niveau" sur l'interface réseau.

Donc pour qu'un utilisateur "normal" puisse exécuter traceroute, il faut aussi un suid root.

Personnellement je prefere ne pas utiliser du tout le "--state NEW" que je trouve étonament laxiste

Euh..... si tu utilises pas le --state NEW, ca ne crée pas les nouvelles entrées dans la table de connexion, donc tu peux pas non plus utiliser les --state ESTABLISHED, donc tu utilises pas le moteur stateful de Netfilter.

Ou j'ai loupé quelquechose ?


En fait, je dirais que l'ideal est d'utiliser des regles qui font --state NEW ET des tests sur les différents flags (TCP) des paquets.

Pas secure !

Par contre, le support de l'édition par ssh:/, la ouais, ca peut etre bien...

Emacs ?