Cette technique passe par l’utilisation de l’IP spoofing. Elle permet d’éviter de laisser son IP dans les fichiers log, tout en scannant les ports du serveur. C’est une intelligente combinaison de différentes techniques d’informations assemblées, qui sont en gros utilisés sur l’Internet aujourd’hui. Cela combine l’IP spoofing et réseau, ou host scanning, et une manière efficace d’opérer un sondage anonyme sur des services. Un pirate va analyser le comportement de l’idle host dans le but de trouver des informations sur la cible. Comme avec tout type de scan, la partie attaquante veut rassembler des informations sur les caractéristiques du réseau, ou sur des ordinateurs connectés à internet. L’information peut être ce que les services de l’hôte offrent, sur quels ports ces services tournent, ou encore le système d’exploitation de la cible. Typiquement, de tels scans sont précurseurs d’autres sondages beaucoup plus conséquent, voire d’une réelle attaque. L’attrait d’un idle host scan pour le pirate, est qu’un scan de ce type peut être accompli de façon anonyme. Ceci nous amène à la véritable nature insidieuse de cette méthode de scan. Avec le relatif anonymat qui peut être maintenu pendant l’utilisation de cette méthode, à travers l’utilisation d’un troisième ordinateur ne se doutant de rien, ce type de sondage de réseau est très difficile à tracer. En effet, retrouver l’attaquant pour l’administrateur réseau est presque une mission impossible : non seulement il aura besoin d’identifier et de contacter l’innocente tierce personne, mais les logs devront être aussi comparés, dans l’espoir que la véritable origine du scan puisse être révélé. Nous pouvons juste espérez que l’adresse d’origine n’était pas celle d’un système compromis, que le pirate a utilisé comme plate-forme de lancement. Ce type de scan est une menace réelle pour les réseaux et ordinateurs reliés au web, et se révèle une efficace méthode de rassemblement d’information de façon anonyme pour les pirates.
Exemple type :
Etape 1. La première étape pour le pirate est d’envoyer à l’idle host des paquets avec aucun flag de configuré, au port 0. Typiquement, ce type de paquet va nous mettre dans l’attente d’un RST de la part de l’idle host. Attaquant >>>> packet >>>> Idle host 192.168.0.4 192.168.0.5 L’Idle host reconnaît les paquets avec un RST attaché pour l’attaquant. Attaquant <<<< RST <<<< Idle host 192.168.0.4 192.168.0.5 Etape 2. L’attaquant envoie alors des paquets SYN spoofés à la cible, avec l’adresse originale spécifiquement ouvrée comme Idle host. Attaquant >>>> SYN (spoofed as 192.168.0.5) >>>> cible 192.168.0.4 192.168.0.6 La cible à répondus aux paquets spoofés, et envoyés la réponse à l’idle host. Idle host <<<< ACK <<<< cible 192.168.0.5 192.168.0.6 Etape 3. Avec la session continuant de tourner de l’attaquant vers l’idle host, l’attaquant espère voir le reflet des ISN ( initial sequence number) dans les paquets RST que l’idle host renvoie. Ceci impliquerait que l’idle host envoie des paquets RST à la cible pour un ACK inattendu (il n’y a pas de ACK dans des paquets RST). Ces paquets RST vont augmenter leurs ISN, donc augmenter les ISN dans les paquets RST que l’idle host envoie à l’attaquant. Idle host >>> RST (séq de num est effectuée) >>> cible 192.168.0.5 192.168.0.6 V V RST(évidence d’activité par des ISN artificiellement gonflés) V V V 192.168.0.4 Du point de vue de l’attaquant, cet exemple de scan est hautement réussi. On le reflète dans le fait que la génération d’ISN de l’idle host a l’attaquant a été affecté. L’attaquant saurait à ce moment, que la cible répondait à des paquets SYN spoofés, envoyés à un port particulier. Ceci signifierait que la cible offre un service sur ce port. Cette méthode de scan dépend lourdement d’une des caractéristiques de l’idle host. Cette caractéristique étant, une prédiction du schéma des numéros de séquence générés. IHS (idle host scanning) dépend de l’analyse de l’activité à un niveau du paquet, et utilises le numéro de sequence IP comme référence. Il serait pratiquement impossible de mesurer le niveau d’activité d’un serveur si il produisait de véritable numéro de séquence randomizés, indépendamment du niveau d’activité.
Hping est une application développée par Salvatore SanFilippo, un programmeur italien. Il est aussi connu sous le nom Antirez. Mr SanFilippo est accrédité de la découverte et du développement de cette méthode de scan. Une copie de l’ensemble du document est disponible à http://www.kyuzz.org/antirez/papers/dumbscan.html Comme son nom l’indique, Hping est un programme pour exécuter un type de ping. D’après les propres mots de Salvatore SanFilippo, Hping est un logiciel pour l’audition de pile TCP/IP, découvrir les règles d’un firewall, scanner le port TCP dans de nombreux modes, transférés des fichiers à travers un firewall et beaucoup d’autres choses. Bien que Hping ait la capacité d’utiliser le protocole ICMP comme pour un ping conventionnel, Hping à la capacité de délivrer un paquet, ou des paquets, sur les protocoles les plus communément utilisés aujourd’hui. Hping est un soft GPL qui tourne sous GNU/linux, FreeBSD, and OpenBSD, aussi bien que sur d’autres systèmes d’exploitation. L’url pour Hping est http://www.kyuzz.org/antirez/hping. Le code source de cette application est inclu dans le package. Hping n’est pas seulement un outil d’Idle host scanning, mais aussi un outil très utile à l’administration de réseau. Malheureusement, l’état de la question dans la sécurité de l’information aujourd’hui, est que les outils les plus puissants disponible gratuitement sont utilisés aussi bien a but légitime qu’a but malfaisant. Inutile de dire qu’Hping est un puissant outil d’attaque.
Les informations suivantes sont une copie directe d’un Hping idle host scan, réalisée sur un réseau d’essai. Dans le but de fournir une meilleure compréhension aux données qui suivent, j’ai inclus la définition des switchs utilisés par Hping dans ce type de scan particulier. Pour en savoir encore plus, un texte complet des options Hping est disponible avec la documentation de Hping. Une autre chose à noter est que ce type de balayage est plus facilement accompli avec X-Windows, sous lequel 2 sessions Hping peuvent être lancées sur le même bureau. Ceci est du au fait que dans la même période de temps, le pirate peut utiliser Hping pour surveiller un hôte, alors qu’il envoie des paquets spoofés à un autre. Ces informations sont directement copiées depuis le répertoire d’aide d’Hping. N’importe quelle information de la documentation, ou n’importe quel output directe d’Hping lui-même est intentionnellement laissé dans sa forme originale. Utilisation et paramètres de Hping: hping host [options] -r –rel relativize id field (to estimate host traffic) -W –winid use win* id byte ordering -a –spoof spoof source address -S –syn set SYN flag -p –destport [+][+] destination port(default 0) ctrl+z inc/dec Les données suivantes représentent une simulation d’attaque de type idle host scanning. Cela montrera non seulement le point de vue du pirate dans cette attaque, mais aussi de quelle manière cette attaque apparaît sur la machine cible. Il faut noter que la cible est protégée par un host-based firewall. Première étape d’une attaque : l’initiation d’une session Hping avec l’idle host. [root@test sbin]# ./hping 192.168.0.5 -r eth0 default routing interface selected (according to /proc) HPING 192.168.0.5 (eth0 192.168.0.5): NO FLAGS are set, 40 headers + 0 data bytes 46 bytes from 192.168.0.5: flags=RA seq=0 ttl=128 id=6416 win=0 rtt=0.3 ms 46 bytes from 192.168.0.5: flags=RA seq=1 ttl=128 id=+256 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=2 ttl=128 id=+256 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=3 ttl=128 id=+256 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=4 ttl=128 id=+256 win=0 rtt=0.3 ms — 192.168.0.5 hping statistic — 5 packets tramitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.2/0.2/0.3 ms L’output depuis la plus simple commande Hping est très similaire aux output ICMP conventionnel. Le commutateur -r est utilisé dans cette connexion initiale, qui dialogue avec Hping pour ne montrer qu’à l’attaquant, la différence qu’il y a dans le champ ID. Ainsi, par opposition a la visualisation de la totalité du scan, parfois difficile pour contrôler la valeur d’identification, Hping nous montre seulement la différence dans ce champ. Il y a encore deux points importants à souligner. Le premier étant, celui du début du processus de détermination d’un hôte idle, ou actif. En analysant le champ ID, l’attaquant peut dire si l’hôte envoie des paquets vers et depuis internet. Si la valeur du champ ID change fréquemment, et non d’une façon prévisible, l’attaquant supposera que l’hôte en question effectue des échanges de paquets. Si la génération d’ID de l’hôte est très active, l’hôte devrait être inapproprié pour ce type de scan. L’output ci-dessus, nous montre toutefois que nous avons un hôte véritablement inactif. Ceci nous fait un candidat principal comme tiers dans ce balayage. Attention : il faut garder à l’esprit que n’importe quel dispositif relié à l’Internet avec une pile TCP/IP peut être utilisé de cette manière Ceci inclut les stations de travail, imprimantes et les routeurs, pour n’en nommer que quelques uns. Le second point est que la valeur dans le champ ID, augmente d’un standard + 256 pour chaque paquet envoyé. Ceci est un indicateur d’un hôte Windows. Hping est donc un excellent outil de rassemblement d’information, puisque l’attaquant a déjà déterminé que l’idle host utilisait un système d’exploitation Microsoft. Les output ci-dessous, sont exactement les mêmes que la session Hping, mais avec le switch -W utilisé dans le but de compenser le comportement +256 de windows. Voyons la différence avec les output suivants, causés par l’option -W. [root@test sbin]# ./hping 192.168.0.5 -r -W eth0 default routing interface selected (according to /proc) HPING 192.168.0.5 (eth0 192.168.0.5): NO FLAGS are set, 40 headers + 0 data bytes 46 bytes from 192.168.0.5: flags=RA seq=0 ttl=128 id=4126 win=0 rtt=0.4 ms 46 bytes from 192.168.0.5: flags=RA seq=1 ttl=128 id=+1 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=2 ttl=128 id=+1 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=3 ttl=128 id=+1 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=4 ttl=128 id=+1 win=0 rtt=0.3 ms 46 bytes from 192.168.0.5: flags=RA seq=5 ttl=128 id=+1 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=6 ttl=128 id=+1 win=0 rtt=0.2 ms — 192.168.0.5 hping statistic — 7 packets tramitted, 7 packets received, 0% packet loss round-trip min/avg/max = 0.2/0.3/0.4 ms Il est plus facile de manipuler les données ci-dessus que les précédentes, parce que le champ ID a été maintenant normalisé avec la compensation pour les comportements MS-windows +256. En observant les champs ID, l’attaquant peut déterminer si l’hôte est en train d’envoyer des paquets. Ce qui suit est l’output d’un pirate envoyant des paquets SYN spoofés à un hôte cible. L’adresse originale spoofée est celle de l’idle Windows NT hôte comme définit plus tôt. La cible est un hôte Win 98 qui n’offre aucun service sauf HTTP¨sur le port 80. Bien sûr, l’attaquant n’en sait rien et enverra premièrement des paquets FTP sur le port 21. [root@test sbin]# ./hping -a 192.168.0.5 -S -p 21 192.168.0.6 eth0 default routing interface selected (according to /proc) HPING 192.168.0.6 (eth0 192.168.0.6): S set, 40 headers + 0 data bytes — 192.168.0.6 hping statistic — 8 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms Résultat : 100% des paquets sont perdus dans la troisième étape dans l’attaque. La raison de ceci est que la partie effectuant le scan envoie des paquets spoofés avec l’adresse originale à la station Windows NT, la réponse de la machine Windows 98 sera pour l’idle host. Ceci causerait la perte totale des paquets, du coté de l’attaquant. Cependant, en mettant à jour sa session de surveillance initiale avec l’hôte Windows NT, il n’a pas perdu la capacité de voir l’impact des ses paquets SYN spoofés. A ce moment là, nous sommes au tournant dans un idle host scanning. Si l’attaquant a une session Hping continue avec l’idle host, l’attaquant devrait être capable de déterminer si la cible a envoyé des paquets comme réponse à l’idle host, en surveillant les valeurs dans le champ ID de l’output Hping. Ci-dessous est décrit l’output depuis une session idle host avec la station de travail Windows NT. S’il y avait un changement marqué dans les valeurs ID, l’attaquant supposerait que le service FTP est disponible. [root@test sbin]# ./hping 192.168.0.5 -r -W eth0 default routing interface selected (according to /proc) HPING 192.168.0.5 (eth0 192.168.0.5): NO FLAGS are set, 40 headers + 0 data bytes 46 bytes from 192.168.0.5: flags=RA seq=0 ttl=128 id=4141 win=0 rtt=0.4 ms 46 bytes from 192.168.0.5: flags=RA seq=1 ttl=128 id=+1 win=0 rtt=0.3 ms 46 bytes from 192.168.0.5: flags=RA seq=2 ttl=128 id=+1 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=3 ttl=128 id=+1 win=0 rtt=0.3 ms 46 bytes from 192.168.0.5: flags=RA seq=4 ttl=128 id=+1 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=5 ttl=128 id=+1 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=6 ttl=128 id=+1 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=7 ttl=128 id=+1 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=8 ttl=128 id=+1 win=0 rtt=0.2 ms — 192.168.0.5 hping statistic — 9 packets tramitted, 9 packets received, 0% packet loss round-trip min/avg/max = 0.2/0.3/0.4 ms La valeur ID ne change pas dans cette session Hping avec l’idle host. Considérant que les valeurs sont restées uniformes pour la tranche de temps données que les paquets spoofés ont été envoyés, on pourrait supposer que l’hôte windows 98 n’offre pas de services FTP. Si l’hote cible offre des services FTP sur le port 21, la transaction se serait déroulait comme suit :
Si ceci était le cas, la génération des paquets RST aurait changée les valeurs dans le schéma de numérotation ID de l’hote. Puisque ce n’était pas le cas selon les données précédentes, le pirate peut supposer que le service FTP n’est pas disponible sur la cible Windows 98. Afin de fournir des informations détaillées sur ce qu’un scan Hping spoofés sur un service indisponible ressemble depuis le point de vue de la cible, regardez les informations suivantes. Ce log a été obtenu par ZoneAlarm, un des host-based firewall gratuit, pour windows. En admettant que le seul service qu’une machine Windows 98 offre, soit HTTP sur le port 80, le firewall est configuré pour stopper les requêtes, pour tous les ports autres que le 80. Ceci devrait être reflété dans l’output log suivant, qui montre le traffic refusé sur la cible. ZoneAlarm Basic Logging Client v2.1.44 Windows 98-4.10.2222- A -SP type, date, time, source:port, destination:port,transport FWIN,2001/01/30,14:12:10 -5:00 GMT,192.168.0.5:3014,192.168.0.6:21,TCP FWIN,2001/01/30,14:12:12 -5:00 GMT,192.168.0.5:3015,192.168.0.6:21,TCP FWIN,2001/01/30,14:12:12 -5:00 GMT,192.168.0.5:3016,192.168.0.6:21,TCP FWIN,2001/01/30,14:12:14 -5:00 GMT,192.168.0.5:3017,192.168.0.6:21,TCP FWIN,2001/01/30,14:12:14 -5:00 GMT,192.168.0.5:3018,192.168.0.6:21,TCP FWIN,2001/01/30,14:12:16 -5:00 GMT,192.168.0.5:3019,192.168.0.6:21,TCP FWIN,2001/01/30,14:12:16 -5:00 GMT,192.168.0.5:3020,192.168.0.6:21,TCP FWIN,2001/01/30,14:12:18 -5:00 GMT,192.168.0.5:3021,192.168.0.6:21,TCP Ces informations expliquent pourquoi il n’y avait aucun changement marqué de valeur ID, de la part de la station de travail Windows NT. Le firewall sur cet ordinateur refuse le trafic d’arrivée sur le service FTP. Or l’intérêt est que l’adresse originale pour la requête FTP est révèlée dans le log ci-dessus, comme l’adresse de l’idle host, et non de la partie attaquante. En faisant confiance aveuglément aux logs de cette machine, l’administrateur de cet ordinateur peut potentiellement accusé une mauvaise personne de scanner leur FTP. L’output suivant va refléter un Hping idle host scan, qui est réussi dans le sens ou la cible montre qu’elle a un service disponible en répondant a l’idle host. Le pirate peut raisonnablement supposer que la cible offre un service sur le port 80, si il a obtenu cet output. L’attaquant envoie des paquets SYN spoofés au port 80 de la cible. [root@test sbin]# ./hping -a 192.168.0.5 -S -p 80 192.168.0.6 eth0 default routing interface selected (according to /proc) HPING 192.168.0.6 (eth0 192.168.0.6): S set, 40 headers + 0 data bytes — 192.168.0.6 hping statistic — 7 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms En attendant, l’attaquant avait surveillé l’idle host avec une autre session Hping. root@test sbin]# ./hping 192.168.0.5 -r -W eth0 default routing interface selected (according to /proc) HPING 192.168.0.5 (eth0 192.168.0.5): NO FLAGS are set, 40 headers + 0 data bytes 46 bytes from 192.168.0.5: flags=RA seq=0 ttl=128 id=4170 win=0 rtt=0.3 ms 46 bytes from 192.168.0.5: flags=RA seq=1 ttl=128 id=+1 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=2 ttl=128 id=+1 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=3 ttl=128 id=+1 win=0 rtt=0.3 ms 46 bytes from 192.168.0.5: flags=RA seq=4 ttl=128 id=+2 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=5 ttl=128 id=+2 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=6 ttl=128 id=+2 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=7 ttl=128 id=+2 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=8 ttl=128 id=+2 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=9 ttl=128 id=+2 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=10 ttl=128 id=+2 win=0 rtt=0.3 ms 46 bytes from 192.168.0.5: flags=RA seq=11 ttl=128 id=+1 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=12 ttl=128 id=+1 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=13 ttl=128 id=+1 win=0 rtt=0.2 ms 46 bytes from 192.168.0.5: flags=RA seq=14 ttl=128 id=+1 win=0 rtt=0.2 ms — 192.168.0.5 hping statistic — 15 packets tramitted, 15 packets received, 0% packet loss round-trip min/avg/max = 0.2/0.2/0.3 ms La chose la plus importante à noter au sujet des données ci-dessus, est le changement dans le champ ID de l’idle host. Avec ces informations, le pirate peut supposer que les 7 paquets SYN spoofés qui ont été envoyés à la cible, ont été reconnus avec 7 paquets ACK. Les paquets ACK ont été envoyés à l’idle host, qui en retour a envoyé 7 paquets RST. Ces 7 paquets RST ont occupé les nombres ID qui ont été reflété dans l’output de la session de surveillance. Avec 7 paquets spoofés envoyés, et l’impact sur les valeurs ID de l’idle host étant approximativement de 7, les données sont fortement révélatrices d’un service offert sur la cible. Le fait le plus intéressant, est que le pirate, originairement 192.168.0.4, a simplement réussi à scanner la cible 192.168.0.6, anonymement tel que 192.168.0.5. Comme toute méthode ou outil pour le scan d’hôte ou de réseau, ceci peut être utilisé comme un outil de réseau de mapping. Evidemment le manque de réaction dans les séquences ID de l’idle host devrait indiqué l’absence de service. Le service peut être firewalled, non disponible, ou configuré avec n’importe quel outil de la troisième partie pour limiter sa connectivité. Ces données sont valables pour un pirate, du fait qu’elles peuvent révéler des réseaux entier en cataloguant ce qui n’est pas disponible, que ce soit des hôtes, ou des services.
Puisque l’idle host scanning est une combinaison d’information rassemblant des techniques et méthodes de piratage, défendre des réseaux de tels scans nécessite une approche multiple. La défense contre une telle attaque doit être classée en 2 catégories distinctes.
Le renforcement de la sécurité au niveau serveur s’assurera qu’une machine sous notre extension administrative ne puisse pas être utilisées comme une tierce partie dans ce type de scan. Au niveau du réseau, nous nous assurerons que l’idle host scanning ne provient pas de notre propre réseau. En outre, des signatures de ce type de scan doivent être alertées au bon moment, de manière à les traiter convenablement. Défense de niveau 1 – Host level La prédiction de la génération des numéros de séquences pour la part de l’Idle host est l’une des premières variables dans ce type d’attaque. Par conséquent, la randomization de ces numéros est une défense appropriée à ne pas négliger. L’utilisation de la cryptographie dans la génération des numéros de séquence est une manière efficace de s’assurer que les numéros de séquence sont véritablement aléatoires et non prévisible. La meilleure preuve de l’efficacité de ceci est que cette technologie a déjà été implémentée dans OpenBSD, qui utilise un algorithme pour modifier ses ISN quand il communique. En raison de ce perfectionnement de sécurité, un ordinateur faisant tourner OpenBSD fait un idle host peu attractif. Défense de niveau 2 – Network Level L’IP spoofing est une partie intégral de l’idle host scan. Et la meilleure méthode pour empêcher le problème de l’IP spoofing est d’installer un routeur filtrant, qui restreint l’entrée à l’interface externe en refusant un paquet s’il a une adresse source de votre réseau interne. En outre, il faut filtrer les paquets sortant qui ont une adresse source différente de votre réseau interne dans le but d’empêcher une attaque d’IP source spoofing provenant de votre site. L’utilisation d’outils TCP wrappers est recommandée afin d’autoriser l’accès depuis seulement quelques machines sélectionnées. Bien que ce ne soit pas une solution complète, cela réduit la vulnérabilité aux attaques. L’alternative à cela est le fait de changer la configuration de la passerelle Internet afin que rlogin et rsh depuis l’Internet vers l’(les) hôte(s) soit bloqués. Si ceci n’est pas possible, il reste possible de désactivez les services rlogin et rsh sur tous les hôtes. Petit bémol : la défense numéro 1 est tributaire du zèle de l’administrateur. Ceci inclu la lecture des logs, et la réponse aux scan et attaques avec les procédures appropriées. En somme, il doit s’assurer que les systèmes sont à jour avec des patches et hotfixes adaptés. L’implémentation d’un IDS (Intrusion Detection System) au niveau du réseau a aussi son importance. Certains sont commerciaux, d’autres gratuits. Leurs capacités s’étendent de l’analyse passive du trafic, a toutes les défenses actives possibles. Exemple d’IDS gratuit : Eagle X chez www.packx.net
Puisque l’idle host scanning est une combinaison de plusieurs différentes attaques, défendre un système contre un tel type de scan peut être approché de multiples point de vue différent. Dans une tentative de durcissement contre l’idle host scanning, les systèmes et les administrateurs réseaux doivent être dynamique dans leurs choix et implémentation de mesures défensives. Certes, l’idle host scan utilisant Hping, n’est pas en soi une attaque active. Mais ceci ne diminue en rien son potentiel de dangerosité, car c’est avant tout une prise d’information recueillant les données techniques qui seront probablement utilisées pour un assaut imminent. |
06 13 32 04 91
