The
Hping2 idle Host Scan
Erik J. Karmeling
February 26, 2001
Traduit de l’anglais par dzeta (dzeta@netcourrier.com)
NdT : Ce
texte demande pour pouvoir être compris clairement et sans amalgame, une bonne
connaissance de l’IP spoofing et plus particulièrement du blind-spoofing
(aucune de ces techniques ne sont décrites dans ce texte et si vous ne les
connaissez vous risquez de vous mélanger) et également des connaissances
basiques de la suite de protocole TCP/IP. Certains mots n’ont volontairement
pas été traduits ainsi que les titres. Pour toute question, que ce soit pour
des mots anglais que vous ne comprenez pas, ou sur le texte en général, n’hésitez
pas à m’envoyer un mail.
Introduction
J’ai lu récemment un article scientifique américain
au sujet de la recherche sur les nouvelles planètes. Il résumait la difficulté
des astronomes a déterminer si une étoile avait des planètes en orbites. Ces
difficultés résultaient des longues distances, des limitations technologiques,
et du fait que les planètes émettent très peu de lumières. Inévitablement,
les scientifiques ont réalisé qu’ils avaient besoin d’une nouvelle méthode
pour détecter la présence de planètes à l’extérieur de notre propre système
solaire.
La détection de planète Doppler est la méthode qui
fût élaborée. En utilisant cette méthode, les astronomes analyse les
variations dans la lumière étant émis par une étoile. Si la lumière semble
se déplacer du bleu vers la section rouge du spectre, il y a possibilité
qu’un corps planétaire soit en orbite autour de l’étoile. Une planète va
exercer une certaine influence gravitationnelle sur une étoile, ce qui fait que
l’étoile, et la lumière qu’elle émet, vont faire des va-et-vient ainsi
qu’un fort tremblement. C’est une méthode de détection assez ingénieuse,
et à prouvé son importance dans l’astronomie moderne.
La chose qui m’intéresse réellement au sujet de
cet article était le fait que les scientifiques pouvait déterminer les caractéristiques
d’une planète avec une large certitude, sans avoir réellement pu voir la
planète elle même. La masse d’un corps en orbite et sa distance par rapport
au soleil, peut être déterminée en analysant l’impact qu’elle a sur l’étoile,
laquelle est en orbite. J’ai trouvé ce type d’analyse assez intéressant,
et était surpris de trouver qu’il y avait une méthode d’analyse théoriquement
équivalente dans la communauté des pirates informatiques. Il y a une méthode
de détermination des caractéristiques d’un ordinateur cible, en analysant le
comportement d’une troisième partie, et l’effet que la cible a dessus.
C’est ce que l’on appelle l’idle host scanning. Bien que beaucoup plus
simple à comprendre que la détection de planète Doppler, en son sein, cette méthode
est en effet très similaire.
Overview of Idle Host Scanning
Laissez-moi commencer par vous donner une brève
explication de l’idle host scanning. 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, dans une manière efficace d’opérer un sondage anonyme sur des
services. Ceci est similaire en plusieurs points à la méthode scientifique décrite
plus haut, et est encore mieux décrit en construisant une comparaison directe
entre les astronomes, et ceux qui voudraient utiliser un idle host scan :
l’objet désiré des astronomes est la découverte d’une planète invisible,
celui du pirate, la découverte d’un hôte connecté. Le scientifique va opérer
une analyse directe des propriétés de la lumière de l’étoile dans le but
de glaner des informations sur les planètes en orbites. Un pirate va analyser
le comportement de l’idle host dans le but de trouver des informations sur la
cible. Les deux méthodes, à cause de la nature indirecte des informations
techniques assemblées, vont main dans la main.
Comme avec tout type de scan, la partie attaquante à
le désir de 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 offre, 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 ou d’une attaque
totale. 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 a tracer. En effet, retrouver l’attaquant pour
l’administrateur réseau relève du haut vol : non seulement il aura besoin de
contacter l’innocente troisième partie, mais les logs devront être aussi
comparés, dans l’espoir que la véritable origine du scan puisse être révélé.
Vous pouvez juste espérez que l’adresse d’origine n’était pas celle
d’un système compromis, que le pirate ai utilisé comme plate-forme de
lancement. Ce type de scan pose une menace définitive pour les réseaux et
ordinateurs reliés au net, et offre une prometteuse méthode de rassemblement
d’information de façon anonyme pour les pirates.
Breakdown of the scan
Un petit réseau témoin à été employé pour
recueillir des informations pour cet article. Ce qui suit est l’information
sur les hôtes impliqués, et l’ordre par lequel l’attaque d’échantillon
à eu lieu. Cette information sont le cassage du concept d’idle host scan et
n’inclut pas les détails spécifiques. La partie de ce document traite a
l’aide d’Hping ce type de scan a un niveau beaucoup plus élevé.
| Serveur pirate | Idle serveur | Serveur cible | |
| OS | Red hat linux 6.2 | Windows NT 4 SP | Windows 98 |
| IP adresse | 192.168.0.4 | 192.168.0.5 | 192.168.0.6 |
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
Etape
2. La deuxième
phase dans cette attaque se produit quand 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 3. Dans
la troisième partie de l’attaque, l’attaquant envoie des paquets SYN spoofés
à la cible, avec l’adresse original spécifiquement ouvrée comme Idle host.
Attacker
>>>> SYN (spoofed as
192.168.0.5) >>>> cible
192.168.0.4
192.168.0.6
Etape 4. Une
fois que la cible à répondus aux paquets spoofés, et envoyés la réponse à
l’idle host, la quatrième phase est complète.
Idle
host <<<<
ACK <<<<
cible
192.168.0.5
192.168.0.6
Etape 5. La
cinquième étape dans ce scan est la plus complexe. 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 (NdT :il n’y a
pas d’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 a
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
Attaquant
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é.
En 1989, Steven Bellovin a tracé les grandes lignes
du danger des numéros de séquence prévisible, dans son article « Security
problems in the TCP/IP protocole suite ». Etant donné le temps qui a passé
depuis la parution de cette article, il est intéressant de noter qu’il existe
toujours des systèmes d’exploitation qui montrent ce comportement.
J’aimerais préciser que cette importante faille de sécurité, qui dépendait
de cette caractéristique, se sont produits dans le passé. L’attaque
de Kevin Mitnick-Tsutomu Shimomura en reste le meilleur exemple.
Enter Hping
Hping est une application développé 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 . Cette découverte à été
retracée dans un post fait sur bugtrap le 18 décembre 1998. 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 rules 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, ce texte
traitera uniquement d’Hping sur le protocole TCP. 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 inclue dans le package.
Ce document n’est pas une analyse d’Hping, mais
plutôt de regarder la manière dont un Idle host scan peut être accompli avec
Hping. Ce n’est pas seulement un outil d’Idle host scanning, mais aussi un
outil très utile à l’administration de réseau. Pour ceux qui sont
intéressés par la grande variété de fonctions que Hping supporte vous êtes
encouragés à lire la documentation qui vient avec le code source.
Bien que mon expérience avec Hping soit assez limitées
aux scan test suivant, je suis convaincu de sa souplesse comme outil
d’administrateur réseau. Quelques exemples seraient le test des rules d’un
firewall, évaluation de vulnérabilité, et d’autres tâches de sécurité
associé au réseau. Hping a transformé sa
voie dans la collection des ports FreeBSD, ce qui indiqueraient qu’un certain
nombre de gens l’utilise a des fins administratives. 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.
The Hping Idle Host Scan
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. Un
texte complet des options Hping est disponible avec la documentation de Hping.
Une autre chose a noter est que ce type de balayage
est plus facilement accompli avec X-Windows, ou 2 sessions Hping peuvent être
lancé sur le même bureau. 2 sessions Hping peuvent être lancés simultanément
: ceci est due au fait que dans la même tranche de temps, le pirate peut
utiliser Hping pour surveiller un hôte, alors qu’il envoie des paquets spoofés
a 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.
usage:
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 partent de la perspective d’
une partie attaquante dans un 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.
Ci-dessous est présenté la première étape dans
l’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
Comme on peut l’observer, 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’a l’attaquant, la difference qu’il y a dans le
champ id. Ainsi, par opposition a
la visualisation de la totalité du scan, parfois dur pour contrôler la valeur
d’identification, Hping nous montre seulement la différence dans ce champ.
Il y a deux points importants a mentionner ici. Le
premier étant, celui du début du processus de détermination d’un hote 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 au-dessus, nous montre toutefois que nous avons un hôte véritablement
inactif. Ceci nous fait un candidat principal comme tiers dans ce balayage.
S’il vous plait, gardez a l’esprit que n’importe quel dispositif relié a
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 paquets envoyés. Selon la
documentation Hping, Ceci est un indicateur d’un hôte windows. Hping s’est
déjà prouvé comme un outil de rassemblement d’information valable, 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é but de compenser le comportement +256 de windows. Remarquez
la différence dans les output suivant, 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. En conséquence,
le pirate serait capable de tirer la conclusion depuis les données ci-dessus,
que cette hôte idle. Supposant que l’attaquant a déjà obtenu l’adresse IP
de la cible destinée, il peut procéder ainsi a l’idle host scan.
Ce qui suit est l’output d’un pirate envoyant des
paquets SYN spoofés a un hôte cible. L’adresse originelle spoofées est
celle de l’idle Windows NT hôte comme définit plus tôt. La cible est un hôte
windows 98 qui n’offre aucun service sauf http¨sur le port 80. Gardez a l
‘esprit que l’attaquant ne connaît pas ceci 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
Vous aurez remarqué que 100% des paquets sont perdus
ici, la troisième étape dans l’attaque. La raison de ceci est évidente.
Quand la partie effectuant le scan envoie des paquets spoofés avec l’adresse
originelle a 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 a 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.
Ici donc, nous sommes en présence d’un 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,
a 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. Si il y avait un changement marqué dans les
valeurs id, l’attaquant supposerai 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
Veuillez noter que 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.
·
La cible aurait du recevoir les paquets SYN spoofés.
·
Il aurait ainsi répondu aux paquets avec une limite SYN/ACK
pour le NT idle host.
·
L’hôte windows NT aurait ainsi reçu des paquets SYN|ACK, et répond
convenablement avec un RST, car il n’a pas fait de demande FTP.
Si ceci était le cas, la génération des paquets
RST auraient changées 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 host-based firewall disponible gratuitement, pour
windows. Souvenez-vous, le seul service qu’une machine Windows 98 offre, est
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,destination,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èle 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, avec confiance,
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 a noter au sujet des données
ci-dessus, est le changement dans le champ id de l’idle host. Armés des
informations ci-dessus, le pirate peut supposer que les 7 paquets SYN spoofés
qui ont été envoyés a la cible, ont été reconnus avec 7 paquets ACK. Les
paquets ACK ont été envoyés a 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 etant
approximativement de 7, les données sont fortement révélatrice 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 a scanné 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 sequence id de l’idle host devrait
indiqué l’absence de service. Le service peut etre 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 profiler des réseaux entier en cataloguant ce qui
n’est pas disponible, que ce soit des hôtes, ou des services.
Hping advancement, and others tools.
Actuellement, la plus récente version d’Hping,
Hping2-beta54, a atteint la fin de sa vie. Salvatore SanFilippo, et d’autres
volontaires, recodent Hping du tout ou tout. Selon son site Web, Hping3 sera
nettement supérieur a l’actuel version. Il y aura des améliorations
d’installation, des outputs plus lisibles, et sera scriptable. Le statut
actuel du projet peut être suivi a : <http://www.kyuzz.org/antirez/hping3.html>
Hping n’est pas le seul outil qui peut exécuter un
idle host scan. « Idlescan » est un outil, qui à été élaboré sur le
concept d’un Hping idle host scan. Il a simplifié le concept de
l’utilisation d’idle host sur Internet, pour scanner des services. Il ne
comporte pas toutefois la large variété d’options qu’Hping possède, mais
pour les attaquants qui sont seulement intéressés dans l’exécution de ce
type de scan, cela fait un outil de scan tout prêt très tentant. Celui-ci est
aussi un programme disponible gratuitement, et l’url ou il peut être obtenu
est dans la section reference de ce document.
Common defense
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 pour
une telle attaque devrait être cassé en 2 catégories différentes. La première
catégorie consiste aux niveaux des mécanismes de défense du serveur. La
seconde est au niveau de la défense du réseau. Le renforcement de la sécurité
au niveau serveur s’assurera qu’une machine sous votre extension
administrative ne puisse pas être utilisées comme une tierce partie dans ce
type de scan. Au niveau du réseau, vous vous assurez que l’idle host scanning
ne provient pas de votre réseau. En outre, des signatures de ce type de scan
peuvent être alertées au bon moment, et les traiter convenablement.
Defense Section 1 - Host level
La prédiction de la génération des numéros de
sequences 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
devraient être une défense appropriées. Selon l’article précédemment référence
de Steven Bellovin’s, utilisant la cryptographie dans la génération des numéros
de sequence est une manière efficace de s’assurer que les numéros de séquence
sont véritablement aléatoires et non prévisible. Le meilleur exemple est que
ceci à déjà été implémenté 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.
OpenBSD se tient seulement comme exemple de la
plupart des OS d’aujourd’hui, qui emploie aussi la génération
cryptographique des numéros de sequence, ou peut être patché pour fonctionner
ainsi. Avec les conditions ci-dessus, un serveur basé sur la sécurité,
gestion des logs, et un host-based firewall sont nécessaire dans le but de
s’assurer qu’un hôte n’est pas utilisé dans ce type de scan. Cela nous
amène a l’étape suivante dans la défense des systèmes contre ce type de
scan, l’implémentation de la sécurité network-based appropriée.
Defense Section 2 - Network Level
Puisque l’ip spoofing est une partie intégral de
l’idle host scan, suivre les contre-mesures a l’IP spoofing selon le CERT
advisory CA-1995-01, est hautement conseillé. Ce qui est énoncé :
« 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 a votre
interface externe ( connu comme l’ input filter) en refusant un paquet si il a
une adresse source de votre réseau interne. En outre, vous devriez 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. »
Les informations ci-dessus fournit clairement les
directives pour empêcher un idle scan extérieur depuis votre réseau, qui
pourtant semble faire défaut a fournir une explication sur la façon de
repousser les paquets spoofés entrants pour ce type de scan. Il est probable
que les paquets spoofés dans un scan de ce type proviennent de l’Internet, et
non pas de votre propre réseau. L’implémentation de filtres entrant le fais
toutefois ; combat de façon convaincante tout autres types d’IP spoofing
attaques. Quoiqu’il ne puisse durcir votre système contre un Idle host scan,
c’est une bonne idée d’utiliser cette contre-mesure.
Ceci nous amène a la section suivante du conseil,
qui tente une approche de solution, qui pourtant ne le définit toujours pas
complètement.
« Nous proposons que vous employez TCP wrappers pour autoriser l’accès
depuis seulement quelques machines sélectionnées. Bien que ce ne soit pas une
solution complète, cela réduit votre susceptibilité aux attaques.
Alternativement, changez la configuration de votre gateway Internet afin que
rlogin et rsh depuis l’Internet vers l’ (les) hôte(s) soient bloquées. Si
ceci n’est pas possible, désactivez les services rlogin et rsh sur tout vos hôtes.
»
L’utilisation de TCP wrappers, et d’autres tiers
outils, peuvent être une solution très compréhensible pour se défendre
contre beaucoup de types de scan et d’attaques Je crois qu’une combinaison
des pratiques fournira une solution acceptable pour la défense network-based
dans ce scénario. La défense numéro 1 est le zèle de la part de
l’administrateur. Ceci inclus la lecture des logs, et la réponse aux scan et
attaques avec les procédures ultérieures appropriées. En somme, s’assurer
que les systèmes sont a jour avec des patches et hotfixes, est impératif.
L’implémentation d’un IDS (intrusion detection
system) au niveau du réseau a aussi son importance. Il y en pas mal de
commercial, et d’autres gratuits. Leurs capacités s’étendent de
l’analyse passive du traffic, a toutes les défenses actives possibles. Ceci
sera laissé comme un exercice pour le lecteur, pour décider quel IDS devrait
fournir une solution approprié pour votre environnement. Un bon point de départ
pour ceci : <http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.ht>
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.
Conclusion
Certains défendent le fait que le scan de réseau ne
fait peu, voir aucun mal. En effet, d’un point de vue scientifique, les
astronomes utilisent des informations rassemblant différents techniques, dans
le but de rechercher des données d’une planète très éloignée. Les pirates
utilisent simplement des méthodes et procédures alternatives pour rassembler
des informations sur des ordinateurs, ceux qui les intéressent. Bien sur, la
différence primaire entre ces deux méthodes, est qu’une planète étant étudiées
depuis la terre, n’est pas sous la menace d’une attaque. Ce qui serait le
cas, si quelqu’un utilisant la procédure décrite ci-dessus devait scanner
votre réseau.
Dans les jours d’aujourd’hui ou le constant
changement des réseaux interconnectés, il est de plus en plus difficile de
maintenir la confidentialité, la disponibilité, et l’intégrité de nos
ressources informatiques. Ceci est particulièrement vrai dans un monde ou les
pirates trouvent constamment de nouveaux moyens de recueillir de
l’information, sonder, et attaquer nos réseaux. L’idle host scan, utilisant
Hping, comme défini dans ce document, n’est pas en soi une attaque active.
C’est une information, recueillant les techniques qui sont probablement utilisées
comme une manière anonyme de scanner nos réseaux, et dresser son intelligence
pour un assaut imminent.
References
[1] Marcy,
Jeffrey. Butler, Paul. "Giant Planets Orbiting Faraway Stars."
Scientific American, Volume 9, Number 1, 1998. March 1998.
URL: <http://www.sciam.com/1998/0398cosmos/0398marcy.html> (February 12, 2001)
[2] CERT
Advisory CA-1995-01. "IP Spoofing Attacks and Hijacked Terminal
Connections." September 23, 1997.
URL: <http://www.cert.org/advisories/CA-1995-01.html> (January 21, 2001)
[3] CERT
Advisory CA-1996-21. "TCP SYN Flooding and IP Spoofing Attacks."
November 29, 2000.
URL: <http://www.cert.org/advisories/CA-1996-21.html> (January 21, 2001)
4] Securiteam. "A New
Stealth Port Scanning Method." December 23, 1998.
URL: <http://www.securiteam.com/securitynews/A_new_stealth_port_scanning_method.html>
(February 12, 2001)
5] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol
Suite." Computer Communications Review, 2:19, pp. 32-48, April 1989.
URL: <http://www.research.att.com/~smb/papers/ipext.ps>
(February 19, 2001)
6]
de Raadt, Theo. Hallqvist, Niklas. Grabowski, Artur. Keromytis, Angelos D.. Provos, Niels.
"Cryptography in OpenBSD: An Overview." Usenix 1999.
URL: <http://www.openbsd.org/papers/crypt-paper.ps>
(February 19, 2001)
[7] SanFilippo,
Salvatore. "Original Bugtaq Posting." December 18, 1998.
URL: <http://www.kyuzz.org/antirez/papers/dumbscan.html> (February 25, 2001)
[8] SanFilippo,
Salvatore. "HPING2-HOWTO.txt." August 10, 1999.
[9] SANS Institute. "Intrusion Detection FAQ." Version
1.42.
URL: <http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.htm> (February 25, 2001)
Links to
Downloadable Source Code
Hping2-Beta54 Source Code - <http://www.kyuzz.org/antirez/hping-src/>
Idlescan-v0.1 Source Code - <http://www.hackers-pt.org/ptstuff/>
TCP Wrapper
Source Code - <ftp://ftp.porcupine.org/pub/security/index.html>