Les tests d'intrusion

Abstract

Une fois le réseau installé et configuré, celui-ci ne va cesser d'évoluer. De nouveaux systèmes viennent s'y ajouter, de vieilles et fidèles machines disparaissent, bref, tout change tout le temps. Les utilisateurs peuvent également agir dans le dos de l'administrateur et apporter leurs propres modifications au réseau.

Pour vérifier l'état de son réseau, un administrateur doit se comporter comme un pirate et tenter de pénétrer ses propres défenses. Cet article présente la démarche à suivre.

Introduction

Il est important de tester la sécurité de son propre réseau en se mettant à la place du pirate pour découvrir d'éventuelles failles. Ces tests se décomposent en plusieurs étapes :
  1. phase d'approche : récupération d'informations sur le réseau cible ;
  2. phase d'analyse : détermination, à l'aide des résultats obtenus à l'étape précédente, des vulnérabilités potentielles et des outils nécessaires à leur exploitation ;
  3. phase d'attaques : passage à l'acte.
Avant d'entreprendre la dernière étape, l'administrateur du réseau doit impérativement vous avoir donné son consentement, et pas uniquement oral. Le chapitre III du code pénal traite des atteintes aux systèmes de traitement automatisé de données. On y trouve 7 articles, dont voici les trois premiers : Le 323-1 concerne l'intrusion en elle-même. Lorsque que, de plus, elle induit des altérations des données du système, la peine est majorée. Le 323-2 porte sur des nuisances faites au réseau (virus, mail bombing, DoS, ...). Enfin, le 323-3 punit les modifications faites volontairement aux données présentes sur le réseaux (comprendre par "données" aussi bien les meilleurs scores à xbill que les fichiers de configuration du réseau).

Mettre à l'épreuve la sécurité d'un réseau signifie en général "résistance aux menaces externes". Cependant, de nombreuses opérations malveillantes sont facilement menées depuis une machine du réseau lui-même (virus, backdoor, sniffer...). Ces sources de danger sont rarement prises en considération lors de l'évaluation du réseau. De même, la plupart des attaques présentées dans l'article d'Éric Detoisien doivent également être évaluées (spoofing, (D)Dos...).

Des scénarii variés sont envisageables en guise de tests d'intrusion :

Les résultats obtenus doivent permettre de mieux cerner, afin de les corriger, les problèmes potentiels ou existants sur le réseau cible. Par exemple, il faut évaluer le comportement de l'administrateur face aux tentatives d'intrusion ou à l'intrusion elle-même si elle réussit (sera-t-elle détectée ? Au bout de combien de temps ? ...)

La guerre de l'information

Nous nous plaçons donc dans la peau d'une personne qui cherche à récolter un maximum de renseignements sur un réseau cible. Cette collecte se divise en deux étapes. Dans un premier temps, nous allons récupérer toutes les informations disponibles sans accéder directement aux ressources de la cible. Ensuite, lorsque nous commencerons à avoir une idée plus précise de ce dont il retourne, nous accéderons directement aux moyens fournis par la cible.

Les requêtes indirectes

Dans cette catégorie, nous plaçons tous les moyens qui permettent d'en apprendre plus sur la cible, mais sans la contacter directement. Ces informations sont disponibles, il suffit de savoir où chercher.

Interrogation des bases whois

Les serveurs whois, aussi appelés nicname (port 43), permettent d'accéder à la base de données des renseignements fournis lors de l'enregistrement d'un nom de domaine : Cette base de données, autrefois gérée par InterNIC et maintenant par Network Solutions, reste simplement accessible à tous car elle permet de vérifier si un nom de domaine existe déjà.

Les sociétés qui enregistrent les noms de domaine offrent généralement un service d'interrogation en ligne (voir le tableau 1). Sous Unix, il existe également la commande whois.
 

Tab. 1 : bases whois
AFNIC Association Française pour le Nommage Internet en Coopération www.nic.fr/cgi-bin/whois tous les ".fr"
RIPE Réseau IP Européen www.ripe.net/cgi-bin/whois couvre l'Europe, le Moyen-Orient et quelques pays d'Asie et d'Afrique 
InterNIC Pris sur leur page web : "InterNIC is a registered service mark of the U.S. Department of Commerce. This site is being hosted by ICANN on behalf of the U.S. Department of Commerce". www.internic.net/whois.html les ".com", ".net", ".edu" et autres ".org"

Pour vous montrer la richesses des inforamtions contenues dans ce type de base, rien de tel qu'un petit exemple sur un nom de domaine (fictif pour des raisons de confidentialité) : 

[root@testeur -> ~]$ whois pigeons.fr@whois.nic.fr
[whois.nic.fr]

Tous droits reserves par copyright.
Voir http://www.nic.fr/outils/dbcopyright.html
Rights restricted by copyright.
See http://www.nic.fr/outils/dbcopyright.html

domain:      pigeons.fr
descr:       PIGEON ET CIE
descr:       10 RUE DE PARIS
descr:       75001 Paris 
admin-c:     BPxxx-FRNIC
tech-c:      LPxxx-FRNIC
zone-c:      CPxxx-FRNIC

nserver:     ns1.pigeons.fr
nserver:     ns2.pigeons.fr
nserver:     ns.heberge.fr

mnt-by:      FR-NIC-MNT
mnt-lower:   FR-NIC-MNT
changed:     frnic-dbm-updates@nic.fr 20001229
source:      FRNIC

role:        HEBERGE Hostmaster
address:     Heberge Telecom
address:     10 rue de Gennevilliers
address:     92230 Gennevilliers
phone:       +33 1 41 00 00 00
fax-no:      +33 1 41 00 00 01
e-mail:      hostmaster@heberge.fr
admin-c:     AAxxx-FRNIC
tech-c:      BBxxx-FRNIC
nic-hdl:     CCxxx-FRNIC
notify:      hm-dbm-msgs@ripe.net
mnt-by:      HEBERGE-NOC
changed:     hostmaster@heberge.fr 20000814
changed:     migration-dbm@nic.fr 20001015
source:      FRNIC

person:      Bernard Pigeon
address:     PIGEON ET CIE
address:     10 RUE DE PARIS
address:     75001 Paris
address:     France
phone:       +33 1 53 00 00 00
fax-no:      +33 1 53 00 00 01
e-mail:      bernard.pigeon@pigeons.fr
nic-hdl:     BPxxxx-FRNIC
notify:      bernard.pigeon@pigeons.fr
mnt-by:      HEBERGE-NOC
changed:     bernard.pigeon@pigeons.fr 20001228
source:      FRNIC

person:      Luc Pigeon
address:     PIGEON ET CIE
address:     10 RUE DE PARIS
address:     75001 Paris
address:     France
phone:       +33 1 53 00 00 00
fax-no:      +33 1 53 00 00 01
e-mail:      luc.pigeon@pigeons.fr
nic-hdl:     LPxxx-FRNIC
mnt-by:      HEBERGE-NOC
changed:     aaa@heberge.fr 20001228
source:      FRNIC
Nous apprenons que la société Pigeon et Cie est en fait hébergée par Heberge Telecom. Les adresses emails correspondent sans doute à des alias, mais elles nous fournissent également une piste sur l'existence de comptes sur des machines : si les mots de passe correspondant sont faibles (comme les prénoms, dates de naissance...), cette information peut se révéler utile.

Toujours via les bases whois des recherches plus poussées à partir d'une adresse IP appartenant à la société Pigeon et Cie nous amènent à découvrir les classes d'adresses IP qui lui ont été allouées. Pour cela, nous utilisons la base whois de RIPE qui se révèle être la plus pertinente  : 

[root@testeur -> ~]$ whois 10.51.23.246@whois.ripe.net

% This is the RIPE Whois server.
% The objects are in RPSL format.
% Please visit http://www.ripe.net/rpsl for more information.
% Rights restricted by copyright.
% See http://www.ripe.net/ripencc/pub-services/db/copyright.html

inetnum:      10.51.23..0 - 10.51.23.255
netname:      PIGEON-CIE
descr:        Pigeon et Cie
country:      FR
admin-c:      OMxxxx-RIPE
tech-c:       OMxxxx-RIPE
status:       ASSIGNED PA
notify:       admin@pigeons.fr
mnt-by:       PC-XXX
changed:      admin@pigeons.fr 20000223
source:       RIPE
En outre, des recherches croisées sur les noms récupérés peuvent nous donner des informations supplémentaires sur la cible (découvrir de nouvelles adresses IP ou de nouveaux serveurs DNS).

Le bilan des recherches via les bases whois est très concluant puisque nous avons récupéré :

  1. les serveurs DNS ayant autorité sur le domaine pigeons.fr ;
  2. les coordonnées des contacts administratifs et techniques liés à Pigeon et Cie  ;
  3. les classes d'adresses IP alloués à la société Pigeon et Cie.
Nous pouvons tout de même continuer à glaner des informations sur Internet.

News Group

Souvent les administrateurs ou les développeurs se retrouvent face à des problèmes. Pour les résoudre, ils utilisent les NewsGroup pour poser des questions. Malheureusement, ils donnent souvent beaucoup trop d'informations sur leur système d'information (technologie, version des applications utilisées, fragment de code...). Pour faire des recherches, nous pouvons demander à groups.google.com avec comme critère de recherche @pigeons.fr par exemple. Ce moteur, très performant, remonte alors tous les messages postés par des personnes de la société Pigeon et Cie. Outre les informations techniques, nous pouvons obtenir des renseignements sur les goûts personnels de certaines personnes de la société. Ces indications servirons lors de recherche de mots de passe ou pour améliorer une éventuelle tentative Social Engineering (expliqué ultérieurement).

Moteur de recherche

Même principe que pour les NewsGroup, nous essayons de récupérer d'autres données sur le système d'information cible en utilisant un moteur de recherche. Dès lors, les mots clés employer ne seront limités que par notre imagination. Là encore, www.google.com est très performant surtout grâce à son cache. Néanmoins, des méta-moteurs comme www.dogpile.com donnent des résultats pertinents en multipliant les recherches sur plusieurs moteurs.

Social Engineering

Nous sortons un peu des requêtes indirectes puisque cette technique implique un contact direct avec la cible. Néanmoins, cette démarche n'est toujours pas technique c'est pourquoi elle ne fait pas partie des requêtes directes. Le social engineering se pratique pour obtenir des informations confidentielles (mot de passe, renseignements techniques, numéro de téléphone, adresse IP...) des utilisateurs du système d'information cible. Tous les moyens possibles et imaginables sont à disposition (téléphone, mail, fax...). Avec une usurpation d'identité et une exploitation habile des informations récoltées au préalable sur les personnes et la société, la crédibilité est au rendez-vous ainsi que de précieuses données.

Divers

Les requêtes indirectes sont quasiment illimités, un pirate a le temps pour lui, il ira jetter un oeil sur le site de la société ou de ces filiales. D'autres données sur les sociétés et sur les marques se retrouvent sur des sites comme www.societe.com ou celui des pages jaunes (les numéros de téléphone ou des noms de personnes). Les résultats dépendent evidemment de l'inventivité du pirate.

Les requêtes directes

Les informations récupérées jusqu'ici ne proviennent pas directement de la cible. Nous allons maintenant lancer quelques sondes dans sa direction et voir tout ce que nous pouvons récupérer.

Du point de vue de la cible, nous verrons également comment déjouer certaine interrogation. A la différence des étapes précédentes, la cible contrôle maintenant les données que le testeur recherche. C'est donc à elle de faire en sorte de les limiter au minimum.

Interrogation des DNS

La requête whois nous montre les DNSs utilisés. Que peuvent nous révéler ces derniers ?
Pour obtenir des informations de ces serveurs, il suffit de les interroger dans un langage qu'ils comprennent à savoir le protocole DNS. Plusieurs requêtes sont à notre disposition : Désormais nous avons toutes les informations que nous pouvions recupérer facilement et à tous les coups. Explorons plus avant le domaine pigeons.fr en recherchant des informations sur les machines présentes sur le réseau :

Utilisation de ping

Les requêtes indirectes (whois) et l'interrogation des DNS nous ont permis de récupérer des adresses IP et des classes d'adresses IP appartenant à la cible. En effectuant, un ping sur chacune de ces adresses IP, nous allons savoir lesquelles sont accessibles. Il faut néanmoins prendre en compte le fait que la présence d'un firewall peut empécher la machine de répondre au ping. Le scan de port solutionnera se problème en détectant la présence de la machine dans le cas où elle a un port ouvert. Nmap effectue très bien cette tâche : 
[root@testeur -> ~]$ nmap -sP 10.51.23.* -n

Starting nmap V. 2.54BETA25 ( www.insecure.org/nmap/ )
Host  (10.51.23.226) appears to be up.
Host  (10.51.23.227) appears to be up.
Host  (10.51.23.228) appears to be up.
Host  (10.51.23.229) appears to be up.
Host  (10.51.23.230) appears to be up.
Host  (10.51.23.237) appears to be up.
Host  (10.51.23.238) appears to be up.
Host  (10.51.23.246) appears to be up.
Host  (10.51.23.247) appears to be up.
Host  (10.51.23.249) appears to be up.
Host  (10.51.23.251) appears to be up.
        
Nmap run completed -- 256 IP addresses (11 hosts up) scanned in 2 seconds

Utilisation de traceroute

Le but du jeu est d'obtenir l'adresse IP d'un routeur d'accès aux machines cibles. Pour cela, il suffit de faire un traceroute en direction d'une machine du réseau cible : 
[root@testeur -> ~]$ traceroute 10.51.23.251

traceroute 10.101.154.70

 1  10.0.0.1        1.612 ms  1.443 ms  1.532 ms
 2  10.18.23.5      5.790 ms  5.454 ms  5.536 ms
 3  10.20.20.1      5.605 ms  5.453 ms  5.338 ms
 4  10.51.15.1      6.805 ms  6.437 ms  6.552 ms
 5  10.51.192.7     7.783 ms  7.246 ms  7.329 ms
 6  10.51.173.65    7.402 ms  7.246 ms  7.732 ms
 7  10.51.159.33    7.582 ms  7.844 ms  7.935 ms
 8  10.51.23.1      8.202 ms  7.639 ms  7.909 ms
 9  10.51.23.251    7.807 ms  7.633 ms  7.733 ms
La machine juste avant la destination est un routeur.

Port Scan

Il existe une grande variétés de méthodes pour scanner, dont la description dépasse largement le cadre de cet article. Le principe général de toute méthode de scan est d'envoyer un paquet (TCP, UDP, ICMP...) sur la machine cible et de voir ce qui se passe. Selon la méthode employées, le testeur détermine l'état du port (ouvert, fermé, filtré).

Le but du scan est similaire à celui de l'éclaireur. Le testeur (ou le pirate) détermine ainsi le rôle des machines, les services accessibles, les protocoles supportés... A la fin de l'opération, les informations suivantes sont obtenues :

Pour un administrateur, cette étape dévoile les accès à ses machines. Il doit également installer des outils lui permettant de détecter les scans qu'il n'a pas lui-même dilligentés (iplog ou portsentry par exemple).

Il existe différentes solutions pour échapper à ce genre de détecteurs, en spoofant des adresses IP ou en distribuant le scan depuis plusieurs machines.

Par exemple, lorsque l'adresse source du paquet est spoofée, la machine de test reste inconnue de la machine cible, bien que celle-ci sache alors qu'elle a été scannée :

Pour détecter si un port TCP laisse passer les paquets, kelly envoie régulièrement des paquets à bosley. Si bosley génère peu de trafic sur le réseau, le champs id de ses paquets varie peu. Dans le même temps, kelly envoie à charly des paquets TCP avec le drapeau SYN activé (comme pour une demande de connexion normale), mais en mettant comme adresse source celle de bosley. Ainsi, charly répond à bosley avec des paquets SYN-ACK si le port est ouvert. bosley, qui n'a rien demandé, envoie un paquet RST à charly pour couper la connexion. Du coup, le champs id augmente puisque deux paquets sont émis (le RST et la réponse à kelly : 
[root@kelly intrusion]$ hping -r bosley
46 bytes from 192.168.1.2: flags=RA seq=1 ttl=255 id=+1 win=0 rtt=0.3 ms
46 bytes from 192.168.1.2: flags=RA seq=2 ttl=255 id=+1 win=0 rtt=0.3 ms
46 bytes from 192.168.1.2: flags=RA seq=3 ttl=255 id=+1 win=0 rtt=0.4 ms
46 bytes from 192.168.1.2: flags=RA seq=4 ttl=255 id=+1 win=0 rtt=0.3 ms

46 bytes from 192.168.1.2: flags=RA seq=5 ttl=255 id=+2 win=0 rtt=0.4 ms
46 bytes from 192.168.1.2: flags=RA seq=6 ttl=255 id=+2 win=0 rtt=0.4 ms
46 bytes from 192.168.1.2: flags=RA seq=7 ttl=255 id=+3 win=0 rtt=0.3 ms
46 bytes from 192.168.1.2: flags=RA seq=8 ttl=255 id=+2 win=0 rtt=0.4 ms
46 bytes from 192.168.1.2: flags=RA seq=9 ttl=255 id=+2 win=0 rtt=0.3 ms

46 bytes from 192.168.1.2: flags=RA seq=10 ttl=255 id=+1 win=0 rtt=0.4 ms
46 bytes from 192.168.1.2: flags=RA seq=11 ttl=255 id=+1 win=0 rtt=0.4 ms
Simultanément depuis un autre terminal : 
[root@kelly intrusion]$ hping -a bosley -p 22 -S charly
eth0 default routing interface selected (according to /proc)
HPING charly (eth0 192.168.1.1): S set, 40 headers + 0 data bytes

--- charly hping statistic ---
6 packets tramitted, 0 packets received, 100% packet loss
Il est normal que kelly ne recoive aucune réponse de charly puisqu'elles sont envoyées à bosley.

Au contraire, lorsque le port cible n'est pas ouvert, charly n'émet aucun paquet. Le champs id ne varie alors pas : 

[root@kelly intrusion]$ hping -r bosley
..
46 bytes from 192.168.1.2: flags=RA seq=61 ttl=255 id=+1 win=0 rtt=0.3 ms
46 bytes from 192.168.1.2: flags=RA seq=62 ttl=255 id=+1 win=0 rtt=0.3 ms
46 bytes from 192.168.1.2: flags=RA seq=63 ttl=255 id=+1 win=0 rtt=0.4 ms
46 bytes from 192.168.1.2: flags=RA seq=64 ttl=255 id=+1 win=0 rtt=0.3 ms
..
Le port cible (hping -a bosley -p 80 -S charly) est donc fermé. Les logs de charly contiennent une tentative de connexion provenant de bosley.

Pour induire un scan en erreur, il est également possible de laisser tourner un pot de miel (honney pot). Ceci ressemble à un serveur, a le goût d'un serveur, mais ce n'est pas un vrai serveur : 

/* fake.c : just a socket bound to a port */
#include <stdlib.h>
#include <netinet/in.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <stdio.h>
#include <unistd.h>

main(int argc,char *argv[]) {

  int port;                 //port number
  struct sockaddr_in sock;  //the socket for the server
  int sd;                   //socket descriptor

  if (argc!=2) exit(EXIT_FAILURE);
  port = htons(atoi(argv[1]));

  if ( (sd = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
    perror("No socket");
    exit(EXIT_FAILURE);
  }

  sock.sin_family = AF_INET;
  sock.sin_port = port;
 
  sock.sin_addr.s_addr = INADDR_ANY;
  if (bind(sd, (struct sockaddr*)&sock, sizeof(struct sockaddr)) == -1) {
    perror("can't bind");
    exit(EXIT_FAILURE);
  }

  /* Let's go for LISTEN mode */
  if (listen(sd, 2) == -1) {
    perror("Bad listen");
    exit(EXIT_FAILURE);
  }

  while(1) sleep(1);
}
Il suffit alors de le mettre sur le port de son choix : 
[root@charly fake]$ gcc -o fake fake.c
[root@charly fake]$ ./fake 21 &
[2] 3373
[root@charly fake]$ lsof -ni | grep fake
fake    3373   root    3u  IPv4 201230       TCP *:ftp (LISTEN)
[root@charly fake]$ nmap charly          

Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ )
Interesting ports on charly (192.168.1.1):
(The 1538 ports scanned but not shown below are in state: closed)
Port       State       Service
21/tcp     open        ftp                     
22/tcp     open        ssh                     
6000/tcp   open        X11
Nous lançons notre serveur fake sur le port 21 (ftp). lsof nous révèle bien qu'un serveur écoute sur ce port 21. Toutefois, nmap (scanner de port) se laisse abuser car il tente juste d'ouvrir une connexion sur le port 21. Comme il réussit, il croit que c'est bien un serveur ftp. L'illusion fonctionne avec ce type de scanners réseau car ils ne cherchent pas réellement à se connecter. Toute connexion plus approfondie révélera la supercherie, à moins d'affiner le faux serveur (par exemple en ajoutant les bannières pour simuler le service désiré). Signalons enfin que la commande nc (netcat) produit un résultat similaire (nc -l -p 21 pour écouter sur le port 21).

Ce genre de défense s'appelle pot de miel. Les projets honeynets et honneypots mettent en place des réseaux, ou des machines, destinés à attirer les pirates pour apprendre leurs techniques.

Scanner une machine se résumé toujours à envoyer un paquet de la machine de tests à la machine cible, indépendamment de la méthode employée. Selon les moyens de la machine cible (i.e. la sécurité attendue sur celle-ci), une tentative avec 2 paquets par jour suffit pour détecter le scan. Il faut alors de gros disques et enregistrer tous les paquets qui arrivent sur la machine pour analyser ces données sur plusieurs jours afin de reconstituer le scan.

OS Fingerprinting

Grâce au scan du réseau cible, nous connaissons maintenant les machines actives. Nous affinons notre connaissance en déterminant leur système d'exploitation. Cette connaissance nous permettra, lorsque nous aurons également déterminé la version des daemons qui attendent sur les ports de la machine cible, de rechercher les exploits nécessaires à nos tests d'intrusion.

Chaque OS possède sa propre conception de la gestion des protocoles réseaux. D'une part, certains champs sont laissés à la charge de l'OS (TTL, ToS, Win, DF...). D'autre part, même si les RFC définissent l'essentiel, elles ne sont pas toujours scrupuleusement respectées. De plus, si elles interdisent bien certaines configurations de paquets, elles ne précisent toutefois pas comment y répondre. Par exemple, que faire d'un paquet qui contient le flag 64, non défini ? Chacun a sa solution.

valeurs par défaut dans les paquets
En récupérant des paquets émis par la cible, nous découvrons la valeur de paramètres : Selon les OS, tous ces paramètres changent. Une base de données contenant leur valeur par défaut facilite alors l'identification. Il suffit ainsi d'envoyer des paquets différents pour tester les réponses puis de comparer ces dernières à une base de signatures pour identifier l'OS.

Par exemple, le champs id permet de distinguer facilement les linux 2.2.x des 2.4.x (la commande hping -1 -c 3 émet 3 paquets de type 1 i.e. ICMP) : 

[root@charly intrusion]$ uname -a
Linux charly 2.4.4 #4 Wed May 23 10:18:08 CEST 2001 i686 unknown
[root@charly intrusion]$ hping -1 -c 3 charly
28 bytes from 192.168.1.1: icmp_seq=0 ttl=255 id=0 rtt=0.4 ms
28 bytes from 192.168.1.1: icmp_seq=1 ttl=255 id=0 rt
t=0.3 ms
28 bytes from 192.168.1.1: icmp_seq=2 ttl=255 id=0 rtt=0.3 ms

...

[root@kelly intrusion]$ uname -a
Linux kelly 2.2.19ow1 #2 Mon May 21 12:29:48 CEST 2001 i686 unknown
[root@kelly intrusion]$ hping -1 -c 3 kelly
28 bytes from 128.93.24.10: icmp_seq=0 ttl=255 id=4901 rtt=0.3 ms
28 bytes from 128.93.24.10: icmp_seq=1 ttl=255 id=4903 rtt=0.2 ms
28 bytes from 128.93.24.10: icmp_seq=2 ttl=255 id=4906 rtt=0.2 ms
La pile TCP/IP
Cependant, cette méthode n'est pas très fiable car les OS permettent souvent de modifier certaines de ces valeurs (avec sysctl sous Linux ou dans la base de registres pour Windows).

Une méthode plus performante consiste à analyser les réponses de l'OS cible face à certains paquets : le testeur connaît alors le comportement de la pile TCP/IP de la cible, ce qui est suffisant pour identifier l'OS si les t ests sont bien choisis.

nmap (encore et toujours ;) utilise exactement cette démarche lorsque l'option -O (OS identification) est activée. Une base de données contient les réponses types selon les OS. Ainsi, l'empreinte des noyaux Linux 2.4.0 - 2.4.5 correspond à  : 

# Contributed by  root@dexter.dynu.com
Fingerprint Linux Kernel 2.4.0 - 2.4.5 (X86)
TSeq(Class=RI%gcd=<6%SI=<2983C7E&>3DAF6%IPID=Z%TS=100HZ)
T1(DF=Y%W=16A0|7FFF%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=16A0|7FFF%ACK=S++%Flags=AS%Ops=MNNTNW)
T4(DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(DF=Y|N%TOS=C0|0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E|F%ULEN=134%DAT=E)
Les tests en eux-mêmes sont décrits par les lignes Ti. La lecture de l'article de Fyodor paru dans phrack vous les détaillera (phrack 54, fichier 9/12). Toutefois, dévoilons succinctement la signification de chacun : S'il est souvent possible de modifier les valeurs de certains paramètres, modifier le comportement complet de la pile est autrement difficile, voire impossible avec certains OS dont les sources ne sont pas disponibles.

Bannières

L'objectif est simple : connaître la version de l'application utilisé pour un service spécifique. La plupart du temps, un simple telnet sur le port désiré nous donne le renseignement. Signalons les quelques services qui ne délivrent pas cette information : finger (port 79), exec (port 512), login (port 513), printer (port 515).

Informations relatives à des protocoles spécifiques

Nous savons maintenant ce qui tourne précisément sur chacun des systèmes (OS, serveurs, version des serveurs...). Nous continuons notre quête de renseignements car de nombreux serveurs en dévoilent encore beaucoup sur le réseau et ses utilisateurs :