Ce document veut fournir une analyse en profondeur des méthodes de scan port
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. 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 daemons (banner scanning).
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 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 veut fournir une analyse en profondeur des méthodes de scan port
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 daemons (banner scanning).
Avec une épidémie 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 qu'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
* scan ouvert
* scan semi-ouvert
* scan furtif
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.
______________
| |
| type de scan |
|______________|
__________________________________|___________________________________
/ | | |
/ | | |
_____|_______ ______|______ _____|_____ _____|_____ ____|_____
| | | | | | | | | |
| scan ouvert | | demi-ouvert | | furtif | | balayages | | divers |
|_____________| |_____________| |__________| |___________| |__________|
| | | | |
______|_______ _____|____ _____|_____ ____|_____ ____|_____
| | | | | | | | | |
| connect. TCP | | SYN flag | | drap. FIN | | echo TCP | | erreurs |
|______________| |__________| |___________| |__________| | UDP/ICMP |
| | | | |__________|
_______|_________ _______|_______ _____|_____ ____|_____ |
| | | | | | | | _____|______
| ident. inversée | | en-tête IP ID | | drap. ACK | | echo UDP | | |
|_________________| | "scan muet" | |___________| |__________| | rebond FTP |
|_______________| | | |____________|
_____|______ ____|_____
| | | |
| drap. NULL | | TCP ACK |
|____________| |__________|
| |
_____|_____ ____|_____
| | | |
| drap. ALL | | TCP SYN |
| (XMAS) | |__________|
|___________| |
| ___|_______
_________|_________ | |
| | | ICMP echo |
| fragmentation tcp | |___________|
|___________________|
|
_______|_______
| |
| drap. SYN|ACK |
|_______________|
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 pour car rebond de traffic
parce que cela ouvre une connection complète, ainsi que tous les IDS et pare-feu
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 vuléné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 :
* information de l'utilisateur
* entité
* objets
* processus
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
é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 demin-ouvert
Le terme 'demi-ouvert' 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 [NdT: logs] ces scans demi-ouverts: TCP wrappers,
SNORT, 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:
* A -> hôte attaquant
* B -> hôte muet
* C -> hôte cible
Examinons ce cycle.
* L'hôte A envoie un serie analysant le champ identificateur du PING, englobé
dans l'en-tête IP de l'hôte B. Un hôte muet recevra une incrémentation de
l'identifiant(ID) de la réponse de 1 à chaque séquence PING.
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
* L'hôte A envoie un packet SYN usurpé à l'hôte C en utilisant l'adresse source
de l'hôte B. Le port distant peut être n'importe quel port arbitraire (1-65535)
que l'agresseur souhaite tester si les ports sont ouverts ou fermés:
-> La réponse SYN|ACK indique un port ouvert ECOUTANT. L'hôte B reverra ensuite
un bit RST intégré au paquet (automatisé par le noyau).
-> RST|ACK indiquera un port NON-ECOUTANT, (une méthode de renvoi de scan SYN
classique), et l'hôte B ignorera ce paquet et ne renverra pas de réponse.
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. Tout 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:
* paramétrant des drapeaux individuels (ACK, FIN, RST, .. )
* faisant intervenir des drapeaux NULL
* faisant intervenir tous les drapeaux
* passant à travers les filtres, pare-feux, routeurs
* apparaît comme du traffic réseau fortuit
* taux de paquets éparpillés varié
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
scaneurs de ports à la mode. Ironiquement, la théorie derière cette méthode
n'est 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 testr les fausses alarmes et doit être évitée tant
que possible. Ces réponses de paquets peuvent être obscurcies à cause des
pares-feu, 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èllera une TTL inférieure ou égale à 64, si les port plus grands/plus
petits ont une TTL plus grande.
client -> FIN
serveur -> RST -> (TTL 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
Contrastement, 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.
Un 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 (Int-
ernet Protocol Module, Module IP) qui identifie les paquets fragmentés par le
équivalent aux valeurs de:
* source
* destination
* protocole
* identification
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 limite
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é".
* bloquer le traffic des ports non-définis (services non rattachés à eux)
* contrôle de la couche application
* refuser le traffic passant à travers les règles
* contrôler les connections de la couche transport (contrôle de TCP, SYN,
RST, ACK)
* contrôler l'adresse source en correspondance avec les adresses connues
* filtrer le type 3 et 8 de l'ICMP
* contrôle réseau actif
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 échaper un un proxy bien configuré de pair 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
|
