Examination des méthodes de scan port - Analyse des Techniques d'Audit


document écrit par dethy@synnergy.net
traduit par toady@cell-security.com




Mise en situation

Je vais essayer d'énumérer les différentes façons de découvrir et de cartographier les réseaux internes/externes en utilisant les réponses de paquets basés sur des signatures et de connaître le protocole des réponses au moment du scan. Plus précisément, ce document présente toutes les techniques connues utilisées pour déterminer les ports ouverts/fermés sur un hôte et les manières dont un cracker peut identifier les services réseau exécutés sur des serveurs arbitraires.
 

1.1 Introduction

Ce document fournit une analyse en profondeur des méthodes de scan de ports connues, avec une information exhaustive pour chaque technique utilisée dans la jungle d'aujourd'hui pour cartographier et identifier les ports ouverts et fermés sur des serveurs variés.

Note: Ce document ne décrira ni les techniques pour récupérer la prise d'empreinte (fingerprint) des systèmes d'exploitation ni celles permettant d'identifier les versions des démons (banner scanning).

Avec les épidémies de scan port se déroulant tous les jours, il faut être en mesure de reconnaître les techniques qu'un cracker peut utiliser pour scanner les hôtes réseau en utilisant une variété de techniques pour éviter la détection de l'expéditeur source.
Comprendre les actions pour se défendre contre ces scans orientés réseau est primordial pour identifier et reconnaître les manières dont un scan peut se présenter, tel un traffic réseau d'apparence normale.

Le scan port est un des techniques les plus populaires utilisées pour découvrir et déterminer les services qui écoutent un port spécifié. En utilisant cette méthode,un cracker peut ensuite créer une liste des faiblesses et vulnérabilités suite au résultat obtenu puis exploiter et compromettre un hôte distant.

Une des premières étapes dans l'intrusion/audit d'un hôte distant est tout d'abord d'avoir un liste des ports ouverts, en utilisant une ou plusieurs des
techniques décrites ci-dessous. Une fois ceci établit, le résultat aidera le cracker pour identifier les services variés qui sont exécutés sur un port en
utilisant une correspondance avec les RFC, (/etc/services avec UNIX, la fonction getservbyport() en établit la liste automatiquement) permettant de compromettre d'avantage l'hôte distant après cette découverte initiale.

Les techniques de scan port prennent forme de trois manières différentes:
 


Chacune de ces techniques permettent une attaque pour localiser les ports ouverts/fermés sur un serveur, mais connaître l'utilisation du scan dans un
environnement donné dépend totalement du type de topologie réseau, IDS[1], caractéristique d'identification d'un hôte distant. Cependant les scans ouverts rallongent les logs, sont facilement détectables et produisent de nombreux résultats positifs sur les ports ouverts/fermés.

Autrement, utiliser la technique du scan furtif, peut éviter certains IDS et passer outre les règles du pare-feu. Mais le type de scan, tel que les drapeaux des paquets, utilisés pour identifier ces ports ouverts/fermés peuvent sans doute être diminués en déposant les paquets sur un réseau. Une discution de cette technique sera expliquée dans la section "FIN scan" de ce document.

Penchons nous plus directement sur chacune de ces techniques ci-dessus, ces méthodes peuvent être catégorisées plus loin en techniques de scan individuelles. Voyons un peu le model de scan de base qui inclue le balayage avec PING.

Diagramme: méthodes de scan connues

La première rangée indique le type de scan qui traverse de haut en bas la liste des scans individuels appartenant à cette classe.
 

1.2 méthodes de scan ouvert

Les techniques de scan ouvert sont trop facilement faciles à détecter et à filtrer. Ce type de méthode de scan implique l'ouverture d'une connection complète sur l'ordinateur distant utilisant un accord TCP/IP en trois étapes classiques [NdT : three way handshake]. Une transaction classique requière l'utilisation des drapeaux suivants pour créer et accepter une connection :
  

client  -> SYN
serveur -> SYN|ACK
client  -> ACK


L'exemple ci-dessus montre une réponse à notre requête sur le port connecté par le biais d'un SIN|ACK. Cette réponse signifie que le paquet sur le port était la cible dans l'état d'ECOUTE (ouvert). Une fois que cet accord complet a lieu, la connection sera terminée par le client permettant à une nouvelle d'être créee/appellée permettant au port suivant d'être verifié, jusqu'à ce que le port seuil soit atteint.

Inversement, regardez la réponse à partir d'un port fermé qui enverra les données suivantes:
  

client  -> SYN
serveur -> RST|ACK
client  -> RST


Les drapeaux RST|ACK retournés par le serveur est en train de dire au client de détruire la connection entreprise à partir du moment où le port n'est pas en état d'ECOUTE ainsi que fermé.

Cette méthode est crée à travers l'appel système connect(), permettant la plupart des identifications instantanées d'un port ouvert ou fermé. Si l'appel
de connect() retourne la valeur 1 [NdT : true], le port est ouvert, sinon le port est fermé

Puisque cette technique pose le problème de l'accord en trois étapes pour se connecter à un hôte arbitraire, une connection spoofée est impossible, ce qui signifie qu'un client ne peut pas truquer la véritable adresse IP, comme un connection spoofée essaye d'entrainer l'envoi d'une séquence de nombres aussi corrects que de paramétrer les drapeaux de retour pour situer la transaction des données.

Evidemment cette technique est facilement repérable par le rebond de traffic parce que cela ouvre une connection complète, ainsi que tous les IDS et pare-feux sont capables de détecter et de bloquer ces scans. Cependant, parce que la fonction connect() utilise l'accord en trois étapes, le résultat de ce scan est à peu près aussi précis que ce que vous pouvez obtenir en essayant de déterminer les ports qui sont ouverts/fermés.
 

Avantages : rapide, précis, ne requière pas de privilèges particuliers
Inconvénients : facilement détectable et enregistrable [NdT : logged]

 
1.2.1 - scan à identité inversée


Cette technique augmente la problématique de répondre pour le démon[2] ident/auth habituellement sur le port 113 pour intéroger le service pour le propriétaire du processus en train d'être exécuté. La principale raison à travers ceci est de trouver les démons exécutés en tant que root, ce qui évidement attire un pirate potentiel pour trouver un débordement vulnérable qui peut être à l'origine d'autres activités suspectes à travers ce port. Autrement, un démon exécuté en tant qu'utilisateur nobody (httpd) peut ne pas être aussi attractif qu'un utilisateur parce que les privilèges sont limités. La plupart des utilisateurs ne connaissent pas que identd peut libérer diverses informations privées telles que :
 


Bien que le protocole d'identification voudrait apparaître comme un méchanisme d'autentification, il n'a pas été conçu ou destiné à ce but. Selon la RFC, "Au mieux, il fournit quelques informations supplémentaires en respectant les connections TCP". Pas besoin de dire qu'il ne doit pas être utilisé en tant que service de contrôle d'accès ni en tant qu'authentification de l'hôte ou de l'utilisateur.

La syntaxe officielle prise de la RFC 1413 révèle l'EBNF suivant :
  

SYNTAXE OFFICIELLE
 ::=  
 ::=  "," 
 ::= "015 012" ; CR-LF Indicateur de Fin de Ligne, octal \r\n équivalents
 ::= 1*5 ; chiffres 1-5.


En utilisant cette grammaire appliquée aux données que nous envoyons à un hôte arbitraire encapsulé dans le port ident/auth qui révélera le processus du propriétaire exécuté sur un port donné, à travers lequel nous avons également initié la connection.
 

Avantages : rapide, ne requière pas de privilèges particuliers, retoune l'information nécessaire au service
Inconvénients: facilement détectable
 

1.3 - méthodes de scan demi-ouvert

Le terme 'demi-ouvert' est employé quand le client termine la connection avant que la fin des accords en trois étapes soit terminé. Ainsi, cette méthode de scan sera souvent indétectable par les IDS se basant sur la connection, et retournera des résultats plutot positifs (reconnaissant avec succès les ports ouverts/fermés).
 

1.3.1 - scan SYN


L'implémentation de cette méthode de scan est similaire à la connection complète d'accord TCP en trois étapes à l'exception que, au lieu d'envoyer des réponses ACK, nous désactivons la connection. Une demonstration de cette technique est nécessaire pour montrer une transaction demi-ouverte : 




client  -> SYN



serveur -> SYN|ACK



client  -> RST










Cet exemple à montré que le port cible était
ouvert, puisque le serveur a répondu par les drapeaux SYN|ACK. L'instruction
RST est orientée noyau, ainsi, le client n'a pas besoin d'envoyer
un autre paquet avec cette instruction, car le code de la pile TCP/IP du
kernel le fait automatiquement.

Inversement, un port fermé répondra avec RST|ACK.

 







client  -> SYN



serveur -> RST|ACK










Tel qu'affiché, cette combinaison de drapeaux indique un
port non-écoutant.

Bien que cette technique soit devenue plutôt facilement détectable
par de nombreux IDS, ce qui implique que quasiment tous les programmes
de Dénis de Service (DoS) basent leurs attaques en envoyant un excès
de paquets SYN. De la même manière, les systèmes de
détection d'intrusion courants sont sans aucun doute capables de
journaliser ces scans demi-ouverts: TCP wrappers, SNORT, prelude-ids, Courtney,
iplog, pour ne nommer qu'eux, ainsi, leur efficacité s'est dégradée
dans ces denières années.

Malencontreusement, la méthode SYN à été
la première à être utilisée pour passer outre
un IDS très utilisé, du nom de SATAN.

 

Avantages : rapide, fiable, évite les IDS primaires, évite
l'accord TCP en trois étapes

Inconvénients: requière le privilège root, règles
empêchant beaucoup d'essais de scan SYN

 

1.3.2 - Identifiant de l'en-tête
IP, aussi connu sous le nom de scan "muet"




Le scan par en-tête IP est méthode de scan plutôt
méconnue entrainant une utilisation particulière dans la
pile TCP/IP de la plupart des systèmes

d'exploitation. A l'origine, cette technique à été
découverte par antirez, qui décriva en détail les
détails techniques dans un port sur bugtraq. Evidemment, la base
de ce scan repose sur la réflexion de la méthode de scan
SYN, bien que cela entraîne l'implication d'un troisième hôte
en tant que fausse source.

Avant d'aller plus loin, il est important de reconnaître ce qu'est
un hôte appellé "muet". A l'inverse d'une machine bastion,
un hôte silencieux ou muet

est un serveur qui envoie et reçoit un traffic qui varie entre
faible et rien du tout, d'où le nom caractéristique dont
il est dotté. Localiser un de ces hôtes

requière plus d'effort et des hôtes se balayant, et c'est
probablement plus ennuyeux que ce qu'il en vaut vraiment. Néanmoins,
il s'agit d'un scan authentique et créatif, qui apporte un troisème
hôte complice dans le jeu de dissimulation des traces suspectes.

Ce scénario implique qu'il y a trois hôtes:

 





Examinons ce cycle.

 










60 bytes from BBB.BBB.BBB.BBB: seq=1 ttl=64 id=+1 win=0 time=96 ms



60 bytes from BBB.BBB.BBB.BBB: seq=2 ttl=64 id=+1 win=0 time=88 ms



60 bytes from BBB.BBB.BBB.BBB: seq=3 ttl=64 id=+1 win=0 time=92 ms












Maintenant, comment l'hôte A pourrait connaître les
drapeaux qui ont été envoyés à l'hôte
B ?

Eh bien, en supposant que le port était ouvert sur le serveur
cible, nos séries de PING parallèles que l'hôte A a
envoyé alors que les paquets SYN usurpés qui étaient
en cours d'envoi garderont nos réponses.

Analysons le champ ID de ces réponses PING, 1 signifie un ID
plus grand.

 







60 bytes from BBB.BBB.BBB.BBB: seq=25 ttl=64 id=+1 win=0 time=92 ms



60 bytes from BBB.BBB.BBB.BBB: seq=26 ttl=64 id=+3 win=0 time=80 ms



60 bytes from BBB.BBB.BBB.BBB: seq=27 ttl=64 id=+2 win=0 time=83 ms










Remarquez que les identifiants des paquets deux et trois affichent
une valeur supérieure à 1, d'où un port ouvert a été
localisé. A chaque fois, si la réponse est supérieure
à 1, cela indique un port ouvert, pendant cette période.

A l'origine, l'incrément était de 1, mais parce que l'hôte
A envoie un drapeau SYN spoofé sur un port ouvert, l'hôte
B doit renvoyer à l'hôte C un paquet SYN|ACK, ce qui incrémente
le champ ID.

Autrement, un port ayant pour état fermé sur l'hôte
C n'aurait pas besoin de l'hôte B pour envoyer quelque chose, donc
le champ ID dans une réponse PING ne serait pas incrémenté
du tout.

 







60 bytes from BBB.BBB.BBB.BBB: seq=30 ttl=64 id=+1 win=0 time=90 ms



60 bytes from BBB.BBB.BBB.BBB: seq=31 ttl=64 id=+1 win=0 time=88 ms



60 bytes from BBB.BBB.BBB.BBB: seq=32 ttl=64 id=+1 win=0 time=87 ms










Vous remarquez que le champ ID est encore limité par une
constante de 1.

Encore une fois, c'est pourquoi un hôte "muet" est requis, ainsi
le traffic entrant et sortant est capturé à une valeur minimum
afin de diminuer les

fausses alarmes[3].

En fait, une variété de méthodes de scan peuvent
être utilisées entraînant un hôte muet. Ce scan
n'est pas limité à la technique de scan SYN. Toute méthode
impliquant un hôte B à répondre au port d'un hôte
A pourrait être mise en pratique (allusion: techniques de cartographie
inversée).

 

1.4 - le scan furtif

La définition d'un scan "furtif" a varié à travers
les dernières années à partir de ce que Chris Klaus,
auteur d'un article intitulé "Stealth Scanning: Bypassing Firewalls/SATAN
Detectors" où il est décrit en détail. A l'origine,
ce terme était utilisé pour décrire une technique
qui évitait les IDS et les

enregistrements (logs), maintenant connu comme un scan "demi-ouvert".
Cependant, actuellement, le scan furtif est considéré comme
étant tout scan étant concerné par quelques une des
points suivants:

 





Toutes les techniques de scan décritent ci-dessous utilisent
la technique de cartographie inversée pour supposer de l'ouverture
des ports.

 

1.4.1 - le scan SYN|ACK




Cette technique a été mise de côté par
la plupart, si ce n'est pas tous, les scanners de ports à la mode.
Ironiquement, la théorie derrière cette méthode

n'est pas différente de la méthode SYN, nous retirons
la première étape dans notre configuration TCP/IP demi-ouverte.
Une réponse classique se déroulerait ainsi:

 







client -> SYN|ACK



serveur -> RST










Les drapeaux ci-dessus ont dénoté au client que le
port était à un état non-écoutant. Puisque
le protocole de contrôle des transmissions (TCP) comprend qu'aucun
SYN initial à été envoyé, une réponse
immédiate de terminaison à été envoyée
nulle part. En d'autre termes, le protocole pense qu'il y a eu une erreur
dans la transaction de connection sur ce port quand un SYN|ACK à
été reçu sans SYN, en tant que résultat, le
drapeau reset est renvoyé.

De l'autre côté, un port ECOUTANT ne répondra pas
à ces drapeaux.

 







client -> SYN|ACK



serveur -> -










Comme il a été vu, le serveur ignore le paquet SYN|ACK
envoyé à un port ouvert. Pas besoin de parler de l'absence
de la réponse du serveur, qui produira une fausse alarme. Imaginez
envoyer un paquet SYN|ACK et ne recevoir aucune réponse dû
aux majestueux filtres de paquets, pare-feux ou également les limites
de temps bloquant la transmission, ainsi le scanner voudra ensuite produire
une fausse alarme pour ce port. Naturellement ce scan n'est pas considéré
comme un scan TCP connect() sérieux à cause de cette raison.
Ce type de supposition tombe en-dessous de ce qui est connu sous le nom
de "cartographie inversée".

 

Avantages: rapide, évite les pare-feux/IDS basiques, évite
l'accord TCP en trois étapes

Inconvénients: moins solide (fausses alarmes)

 

1.4.2 - le scan FIN




La méthode du scan FIN utilise la cartographie inverse pour
découvrir les ports fermés. Malheureusement, cette technique
dépend d'un mauvais code de réseau BSD parmis lesquels la
plupart des systèmes d'exploitation ont basé leur pile TCP/IP
(les meilleurs pour scanner). Idéalement, un seul drapeau FIN est
envoyé, un port fermé sera renvoyé avec un bit RST.
Les ports ouverts, en revanche, ne renverront pas de paquet, par conséquent
tout ce qui ne renvoie pas de bit FIN est soupçonné d'être
un port ouvert à travers cette méthode de cartographie inverse.

Regardez la négociation qui se fait pour les ports ouverts/fermés
affiché ci-dessous.

 







client -> FIN



serveur -> -










Aucune réponse signalée par le serveur est signe d'un
port ouvert. Le système d'exploitation du serveur abandonne silencieusement
le paquet FIN qui arrive sur le service s'éxecutant sur ce port.
A l'opposé de ceci est le RST renvoyé par le serveur concernant
un port fermé qui aurait été atteint. Ainsi, aucun
service ne répond sur ce port, entraînant un FIN qui invoque
un reset (RST) comm réponse du serveur.

 







client -> FIN



server -> RST










On peut donc soutenir qu'il y a deux manières de tester un
port ouvert. La première est de recevoir une liste des ports fermés
et de soustraire ces

réponses à partir de la liste des ports testés
à l'origine. Par exemple, si l'on envoie 3 paquets sur les ports
1, 2, 3 d'un hôte distant.

Si la réponse retournée est un RST pour les ports 1 et
3, nous comparons ensuite la liste des ports originalle: 1, 2, 3 et pour
la liste des ports reçus: 1, 3 et nous pouvons donc déduire
que 2 est le port ouvert suite à la comparaison.

Le second test entraîne l'utilisation d'une limite de temps pour
la réponse du paquet envoyé. Si la limite de temps est atteinte
alors nous assumons que le port est ouvert.

Evidemment, cette méthode test des fausses alarmes et doit être
évitée tant que possible. Ces réponses de paquets
peuvent être obscurcies à cause des pare-feux, filtres, routeurs,
connections lentes, et traffic lourd, ainsi ce n'est pas un test solide
pour être utilisé en tant que règle minutieuse pour
le scan FIN furtif.

 

Avantages: évite beaucoup d'IDS, évite l'accord TCP en
trois étapes

Inconvénients: fausses alarmes

 

1.4.3 - le scan ACK




Cette technique à été décrite pour la
permière fois par Uriel Maimon dans Phrack 49, article 15. Par besoin
de dire que cette technique tourne autour d'un bug dans la couche IP de
quelques systèmes d'exploitation.

Dans le but de tester un port ouvert en utilisant cette méthode,
un paquet ACK initial est envoyé à l'hôte cible. Il
y a actuellement deux manières de

classifier la paquet réponse. La première implique une
évaluation du champ TTL, la seconde analyse le champ WINDOW. Les
deux champs doivent être obtenus avec le paquet de réponse
qui à le bit RST mis à 1.

La réponse doit être une connection remise à zéro,
à l'aide d'un paquet RST mis à 1. Accompagnant le drapeau
RST, une analyse de l'en-tête IP, pour quelques systèmes d'exploitation,
fournira une TTL qui est plus basse que celle des autres paquets reçus
d'un port fermé. Manifestement chaque TTL envoyé à
un port ouvert révèlera une TTL inférieure ou égale
à 64, si les port plus grands/plus petits ont une TTL plus grande.







client -> FIN



serveur -> RST -> (TTL <= 64)










Dans la vie courante la réponse est la suivante:

 







packet 1: host XXX.XXX.XXX.XXX port 20: F:RST -> ttl: 70 win: 0 => fermé



packet 2: host XXX.XXX.XXX.XXX port 21: F:RST -> ttl: 70 win: 0 => fermé



packet 3: host XXX.XXX.XXX.XXX port 22: F:RST -> ttl: 40 win: 0 => ouvert



packet 4: host XXX.XXX.XXX.XXX port 23: F:RST -> ttl: 70 win: 0 => fermé










Notez que la TTL des paquets séquentiels avant et après
le numéro 4 est plus élevée que 64. Comme le paquet
3 est reçu, on peut observer que la TTL pour le port 22 est moindre
que la limite de 64, indiquant un port ouvert.

En utilisant la techinque avec le champ WINDOW, chaque paquet non-nul
reçu du serveur est révélateur d'un port ouvert. Ceci
est vrai pour de nombreux récents BSD (FreeBSD, OpenBSD) et UNIX
(AIX, DGUX) mais à été patché/fixé dans
les plus récentes versions.

 







client -> FIN



serveur -> RST -> WINDOW (non-nul)










Dans la vie courante la réponse est la suivante:

 







packet 6: host XXX.XXX.XXX.XXX port 20: F:RST -> ttl: 64 win: 0 => fermé



packet 7: host XXX.XXX.XXX.XXX port 21: F:RST -> ttl: 64 win: 0 => fermé



packet 8: host XXX.XXX.XXX.XXX port 22: F:RST -> ttl: 64 win: 512 => ouvert



packet 9: host XXX.XXX.XXX.XXX port 23: F:RST -> ttl: 64 win: 0 => fermé










Notez que bien que la TTL est égale à 64, les paquets
autours on aussi cette même valeur. Ainsi la méthode avec
la TTL ne fonctionnera pas avec cet hôte, cependant la méthode
avec le champ WINDOW montre une valeur non-nulle indiquant un port ouvert.

 

Avantages : difficile à loger, évite la détection
des IDS

Inconvénients: dépend du bug de code réseau BSD,
incompatibilité entre les OS

 

1.4.4 - Le scan NULL




Bien qu'il soit dotté d'un nom, le scan NULL désactive
TOUS les drapeaux disponibles dans l'en-tête TCP. ACK, FIN, RST,
SYN, URG, PSH deviennent tous non définis. Les bits réservés
(RES1, RES2) n'ont actuellement aucun effet sur le résultat de n'importe
quel scan, qu'ils soient ou non définis clairement ne change rien.
Quand ce paquet arrive sur le serveur, le code réseau BSD informe
le noyau de déposer l'appel entrant si le port est ouvert.

 







client -> NULL (no flags)



serveur -> -










Alternativement, un paquet RST sera retourné si un port fermé
a été atteint

(oui encore un scan qui fait une cartographie inverse).

 







client -> NULL (pas de drapeaux)



serveur -> RST










En raison du fait que les RFC ne spécifient pas exactement
comment un hôte doit répondre à ces types de paquets,
beaucoup de code réseau pour la plupart des systèmes d'exploitation
différeront dans les réponses du paquet, cf. UNIX vs Microsoft.

 

Avantages : évite les IDS, évite l'accord TCP en trois
étapes

Inconvénients: seulement sur les UNIX, fausses alarmes

 

1.4.5 - le scan XMAS




A l'opposé, le scan dit XMAS est l'inverse de la méthode
du scan NULL. Tous les drapeaux disponibles dans l'en-tête TCP sont
définis (ACK, FIN, RST, SYN, URG, PSH). Le scan XMS ou "Arbre de
Noël" est nommé justement d'après l'effet décoratif
du scan avec l'implémentation des frapeaux. Les bits réservés
n'ont pas d'effet sur le résultat du scan, donc les définir
ou les désactiver n'a pas d'importance. Encore une fois, parce que
cette méthode est basée sur le code réseau de BSD,
la technique ce fonctionnera que contre les hôtes UNIX.

Le scan XMAS fonctionne en initialisant tous les flags et en transmettant
ce paquet à l'hôte distant. Le noyau déposera ce paquet
si un port ouvert est à la réception. Un drapeau RST retourné
indiquera un port fermé, NON-ECOUTANT. Encore un fois, il s'agit
là de scan inversé, ainsi les fausses alarmes sont tous ce
qu'un client doit détecter comme ports ouverts/fermés.

 







client -> XMAS (tous les drapeaux)



serveur -> -










Cette signature nous dit que le port est à un état
d'ECOUTE, ou que le paquet à été filtré par
un pare-feu/routeur. Alternativement, un port fermé produira la
réponse suivante:

 







client -> XMAS (all flags)



serveur -> RST










Le RST aurait été envoyé au client parce que
le serveur est truqué en pensant que le client a une connection
sur ce port sans négociation avec l'accord en trois étapes
classique. Puisque nous sommes dans un envorionnement TCP, le noyau renvoie
un bit de remise à zéro (RST) au client pour terminer la
transmission immédiatement.

 

Avantages : évite les IDS, évite l'accord TCP en trois
étapes

Inconvénients: seulement sur les UNIX, fausses alarmes

 

1.4.6 - Fragmentation TCP




La fragmentation TCP n'est pas une méthode de scan en tant
que tel, bien que cette technique emploie une méthode pour rendre
discrette l'implémentation d'un scan en partageant l'en-tête
TCP en petits fragments. Le réassemblage IP du côté
serveur fait souvent suivre des résultats non prévisibles
et anormaux (les en-têtes IP contenant des données peuvent
être fragmentées). Beaucoup d'hôtes sont incapables
d'analyser et de réassembler les mini paquets et ainsi peut causer
des crashs, redémarrages, ou encore des vidages mémoire des
périphériques réseau. Alternativement, ces mini paquets
peuvent être potentiellement bloqués par la fragmentation
IP, mis en attente dans le kernel ou pouvant être pris par

règle merveilleuse du pare-feu.

Depuis que la plupart des systèmes de détection d'intrusion
utilisent des méchanismes basés sur des signatures pour indiquer
tant bien que mal les scans basés sur IP et/ou l'en-tête TCP,
la fragmentation est souvent capable de gagner sur ce type de filtrage
et détection de paquets, et naturellement le scan ne sera pas découvert.

Une en-tête TCP qui est minimalement permis doit contenir un port
de destination et source pour le premier paquet (8 octets, 64 bits), usuellement
les drapeaux initialisés dans le suivant, permet à l'hôte
distant de réassembler le paquet au dessus du dernier. Le réassemblage
actuel est établit à travers un IPM (Internet Protocol Module,
Module IP) qui identifie les paquets fragmentés par le équivalent
aux valeurs de:

 




Avantages : évite les IDS, furtif

Inconvénients: peut causer des problèmes réseau
sur l'hôte distant

 

1.5 Divers

Cette catégorie représente les scans qui ne peuvent pas
être entièrement classifiés dans les catégories
ouvert/demi-ouvert/furtif. Ces scans ici sont

différents dans leur nature mais les techniques sont encore
utilisées dans le monde sauvage d'aujourd'hui.

 

1.5.1 - le scan UDP ICMP_PORT_UNREACHABLE
(port ICMP non accessible)




D'une autre manière que les méthodes de scan ci-dessus,
le protocole UDP est utilisé pour déterminer les ports ouvert/fermés
sur un hôte distant au lieu de TCP.

UDP est un protocole qui agit en mode non connecté qui envoie
des datagrammes qui ont la valeur de transmission de paquet. Au même
titre que le système de cartographie inverse, envoyer un paquet
UDP sur un port ouvert ne retournera pas de réponse du serveur.
Cependant, un port fermé répondra avec une erreur ICMP.

En utilisant un procédé d'extrapolation, il devient simple
d'identifier les ports ouverts des ports fermés. Le type de message,
ICMP_PORT_UNREACH (type 3,code 3), n'a pas techniquement besoin d'être
envoyé quand un port fermé reçoit un paquet UDP, d'où
la difficulté avec cette méthode de scan. En plus, UDP est
connu pour être un protocole non connecté, les paquets peuvent
se perdre pendant la transmission et doivent donc être retransmis,
impliquant les fausses alarmes qui seront déclenchées dans
le résultat du scan. Les noyaux Linux limitent le taux d'erreur
des messages ICMP, le message destination non-atteignable est défini
à 80 par 4 secondes avec 1/4 de seconde de pénalité
si ce taux est excédé ajouté à la technicité
du scan, comme Fyodor a pu en parler.

La signature d'un port ouvert ne doit pas renvoyer de réponse,
aussi un paquet est retransmis est envoyé pour réduire les
signaux d'alarmes:

 







client -> paquet udp



serveur -> -



client -> paquet udp



serveur -> -










Les ports fermé répondront avec une erreur ICMP.

 



client -> paquet udp



serveur -> UDP (ICMP_PORT_UNREACH)





Avantages : scan les ports non-TCP, évite les IDS TCP

Inconvénients: requière les privilèges root, paquets
facilement perdus, facilement détecté

 

1.5.2 Attaque par rebond de serveur
FTP




Cette méthode ingénieuse à été
décrite dans un article par "the hobbit". En utilisant la commande
FTP PORT pour mettre les clients en mode passif, un

hôte est capable de déterminer le statut d'un port en
montrant une IP et un port en tant que paramètres arbitraires pour
se connecter. Si une connection est établie cela signifiera que
le processus de transfert de donnée (DTP) est actif, le client sait
que le port est ouvert, avec les réponses 150 et 226 affichées
par le serveur. Si le transfert ne fonctionne pas l'erreur 425 sera générée
avec un message de constuction de données refusées.

De récentes versions de WU-FTPD (inférieures à
la 16) étaient vulnérables à ce type d'attaque, bien
sûr, la présence de ce bug à été patché
dans la plupart des serveurs FTP. D'autres versions vulérables sont:

Sun FTP server in SunOS 4.1.x/5.x, SCO OpenServer 5.0.4, SCO UnixWare
2.1, AIX

3.2/4.2/4.2./4.3, Caldera 1.2, RedHat 4.X, Slackware 3.1 - 3.3.

Une manière facile d'interdire ce type d'attaque est d'empêcher
la troisième partie des transferts à travers la modification
de la commande PORT et/ou

d'interdire la spécification des ports réservés,
exépté pour le port 20, le port standard de données
par défaut.

 

Avantages : outrepasse les pares-feu, permet l'accès aux réseaux
locaux, dur à tracer

Inconvénients : lent, la plupart des serveurs FTP ont été
patchés

 

1.6 Bloquer les anomalies sur les paquets

Isoler et filtrer tous les paquets utilisés dans tous les scan
ci-dessus est une étape suivante pour sécuriser tout vos
réseaux connectés. Toute application des règles suivantes
rapportera beaucoup de techniques de scan avec des informations de fausses
alarmes, surlignant l'objectif très connu "Sécurité
par obscurité".

 





Beaucoup de techniques de scan audibles existent pour rassembler
des informations sur les serves qui existent sur un hôte. Cependant,
aucun de ces techniques ne pourront échapper à un proxy bien
configuré de paire avec des systèmes d'analyse actifs pour
identifier les anormalités du traffic.

 

Notes de traduction

Le jargon a été traduit dans la mesure du possible dans
le sens où il s'agit d'une

traduction francaise.

[1] IDS = Intrusion Detection System, système
de détection d'intrusion.

[2] démon = traduction de daemon, processus qui
s'execute en arrière plan.

[3] fausse alarme = traduction de false positive, ceci
est problématique car elle

déclenche des alertes injustifiées, diminuant ainsi la
valeur

et l'urgence d'alertes réelles.

Comme ma traduction n'est pas parfaite, si il y a des ambiguïtés,
n'hésitez pas à me mailler.

J'espère que vous avez pris du plaisir à lire ce document,
au même titre que j'en ait pris pour le traduire.

Références

Art of portscanning by Fyodor - http://www.phrack.com

Networking Scanning by Ofir Afkin - http://www.sys-security.com

FTP bounce attack by hobbit - http://www.insecure.org/nmap/hobbit.ftpbounce.txt

-----------------------------------------------------------------------------------------

(C)opyright 2001 by dethy@synnergy.net
Synnergy Networks