Travail de longue préparation

L’adoption de la sécurité est essentiellement une question de culture d’entreprise. Les milieux financiers, l’industrie pharmaceutique ou aérienne n’ont pas attendu l’ère «e-commerce» pour se doter des protections adéquates, sans pour autant disposer de la pléthore d’outils aujourd’hui disponibles. Et bien que la sécurité soit plus que jamais nécessaire dans un monde où l’interconnection des systèmes devient de plus en plus importante, elle reste aujourd’hui une affaire de spécialistes. Sa mise en œuvre rprèssente un coût non négligeable encore perçu comme une dépense importante dans beaucoup de milieux, surtout celui des PME. Le défi des années à venir est donc entre les mains de «l’industrie de la sécurité» qui doit démocratiser son coût et faciliter son déploiement pour favoriser son adoption. La technologie «Internet» atteint aujourd’hui un plus grand niveau de maturité et aussi une plus grande complexité. Ceci s’applique aussi bien à l’infrastructure qu’au framework applicatif. La stratégie de la sécurité doit venir s’intégrer à ces deux niveaux. Maîtriser valablement ces domaines d’expertise requiert une spécialisation suffisante et pour qu’une entreprise puisse s’en doter, il faut atteindre une masse critique importante et compter un nombre d’experts suffisants. Il va de soi qu’il est important d’affecter à la réalisation de ces missions des personnes dont l’état d’esprit soit compatible avec des missions de sécurité, c’est-à-dire qui en perçoivent l’enjeu et les réalisent avec rigueur.

Table des matières

Préface 3

Table des matières 4

Introduction 6

1. Cadre de ce document 6

2. A qui s'adresse ce document ? 6

3. Statut de ce Document 7

1) Introduction aux réseaux 8

1.Le modèle OSI 8

2.Ethernet 9

3.ARP (Address Resolution Protocol) 10

4.IP (Internet Protocol) 10

Format d'un paquet IP 11
Adresse IP 12
Fragmentation d'IP 13
Routage IP 13

5.TCP (Transfert Control Protocol) 15

Caractéristiques du service TCP 15
Format d'un datagramme TCP 15
Méthode d'acquittement 16
Méthode de connection 16

6.UDP (User Datagram Protocol) 17

7.ICMP (Internet Control Message Protocol) 18

8.Notion de Client/Serveur 18

2) Principes fondamentaux de sécurité 20

Services à assurer 20
Notions à protéger 20
Types d'agressions 20
Types d'agresseurs 20
Trois notions fondamentales 21

3)Atteinte à la sécurité du réseau 22

1.Méthode générale d'un piratage 22

A)La prise d'informations 22

Informations concernant l'identité. 22
Informations techniques 23

B)La prise de contrôle 25

L'agresseur vient de l'extérieur 25

Le Social Engeenering 25
Techniques de pénétration n°1, le Buffer Overflow 26
Techniques de pénétrations n°2, les failles CGI 26

L'agresseur vient de l'intérieur 27

Technique d'agression passive, l'interception de paquets 27
Technique d'agression active, le détournement de session 28
Spoofing en réseau switché, ARP Cache Poisoning et Man in the Middle 29

C)L'infiltration 30

Trojan/Backdoor 30
Modification du système 31

2.Le Déni de Service 32

A) Principe d'un DoS 32

B)Exemple d'un DoS: le Smurf 32

C)DoS distribué (DDoS) 33

3.Virus 33

4)Sécurisation d'un réseau 36

1.Politique de sécurité 36

2.Architecture de Sécurité, la DMZ 36

3.Mesure de sécurité préventive 38

A)Les Mots de Passe 38

B)Le Cryptage 38

C)Les Sauvegardes 39

D)L'administration du réseau 39

Le travail quotidien de l'administrateur 39
Les outils d'administration 40

Nmap : http://www.insecure.org/nmap 40
tcpdump : http://www.tcpdump.org/ 40
Snort : http://www.snort.org 40
Network Promiscuous Card Detector : http://public.grima.cjb.net/ 40

4.Intervention d'une société de service 41

A)Audit de sécurité 42

B)Test d'intrusion 42

C)Après une intrusion 42

Conclusion 43

Bibliographie 44

1.Liens 44

2.Livres 44

3.Remerciements 45

Annexes 46

Annexe I GNU Free Documentation Licence 47

Annexe II Détail des différentes catégories de messages ICMP 51

Annexe III Lise des ports et leurs attributions courantes 52

Annexe IV The Art of Port Scanning 54

Annexe V Détection d'OS distante par prise d'empreinte de la pile TCP/IP 57

Annexe VI Introduction aux débordements de tampon 59

Annexe VII IP Spoofing Appliqué 63

Lexique 67

Aujourd'hui, l'élèctronique, permettant la collecte de l'information, et l'informatique, permettant son traitement ont bel et bien envahit chaque composante de la société humaine. Il n'est pas un domaine scientifique, technique ou industriel qui n'ait pas profité des progrès réalisés dans ces domaines au cours de la seconde moité du 20^ème siécle. En ce début de 21^èmesiécle, chacun de ces pôles d'information, à l'image de ce qui existe déjà dans les grand réseaux universitaires ou sur Internet, vont se retrouver interconnectés par différentes technologies. Cela passe du frigo intelligent qui fait automatiquement les courses sur Internet, jusqu'à la voiture automatique, capable de se diriger sans danger dans n'importe quel endroit tout en évitant les embouteillages. Chaque objet de la vie courante, depuis la moindre cafetière vas se retrouver connecté avec d'autres pour former un immense réseau. Si les promesses de la technologie provoquent de grands espoirs, elles amènent aussi leus lot de questions. Les machines sont-elles fiables ? Peuvent-elles vraiment remplacer un opérateur humain ? Est-il possible qu'elle ne remplisse pas leur rôle ? Ou qu'on ne les détourne de ce rôle ? Ces questions sont légitimes, et la motivation de ce document sera de répondre à quelques unes des questions concernant justement ces interconnexions que sont les réseaux informatiques.

Un réseau informatique se forme dès que deux ou plusieurs ordinateurs communiquent entre eux à distance. De par le monde il existe une multitude de type de réseaux informatiques, autant que de réseaux pourrait t'on même dire. Il n'est bien évidemment pas possible de s'intéresser a tous les types de résaux, c'est pour cela que ce document va essentiellement se focaliser sur la sécurité des réseaux utilisant le protocole IP et les protocoles reposant sur lui, TCP et UDP. Ce choix est motivé par le fait que TCP/IP s'érige aujourd'hui en standard par son utilisation généralisée sur l'Internet, et son support quasi généralisé sur toutes les plateformes informatiques existantes. Bien sûr considérer la question de la sécurité uniquement depuis ce point de vue est (volontairement) réducteur, et le lecteur devra garder a l'esprit que pour une vue d'ensemble plus correcte il devra prendre en compte de nombreux autres aspects (comme les protocoles de configuration des routeurs, etc.) qui malheureusement sortent du cadre de ce document. Notons également que ce document se bornera aux réseaux de types Ethernet, qui non seulement, encore une fois, représente un standard de facto, mais de plus est le seul type de réseau qui m'est accessible (tant à l'école qu'à la maison).

Ce document se veut à la fois technique et assez généraliste que pour être compris par une personne ayant des connaissances de base en informatique. Pour ce faire, le corps du document commence par un résumé des principales notions essentielles concernant les réseaux et leur organisation. Vous trouverez également un lexique à la fin de ce document vous permettant d'aborder facilement ces notions qui par leur extréme technicité sont, il faut l'avouer, assez ardues. Au delà de l'aspect purement pratique, les personnes visées par ce document peuvent aller du simple étudiant en informatique, à l'administrateur réseau (ou toute autre personne) désirant acquérir des notions de base concernant la sécurité des réseaux. Mais bien plus qu'une simple connaissance technique, la sécurité informatique est une façon de penser, une manière de concevoir applications et infrastructures matérielles qui ne devrait jamais quitter l'esprit de toute personne développant un système informatique. Ce document peut donc s'adresser en général a toute personne touchant de près ou de loin à l'informatique (et même en temps qu'utilisateur).

Ce document dans son entier et sous quelque forme que ce soit est distribué sous la GNU Free Documentation licence (GNU FDL) v1.1 telle qu'elle a été définie par la Free Software Fundation³. Vous pourez trouver un exemplaire de cette licence en annexe n°I. Ce document a entiérement été composé avec l'aide d'outils Libres et Open Source. Ce document a été composé a l'aide de OpenOffice sous unsystèmee GNU/Linux, dans le but de promouvoir l'utilisation à grande échelle des outils libres.

Nous ne reprendrons ici que les notions de base de l'architecture d'un réseau indispensables pour la suite. Si nécessaire, de bien plus amples informations vous seront fournies au travers des différents liens notés dans la bibliographie.

Le modèle OSI (pour Open System Interconnection) a été défini par l'International Standardization Organisation (ISO). Ce modèle se décompose en 7 couches. Les services de chaque couche peuvent interagir uniquement avec les services des couches contigües. Chaque couche définit un protocole et échange des unités de donnée spécifiques à ce niveau. Chaque unité de donnée d'une couche est encapsulée dans une unité de donnée du niveau inéfieur.

	Nom des couches	Nom des Unité de donnée
1	Application	/
2	Préprès	/
3	Session	/
4	Transport	Datagrame
5	Réseau	Paquet
6	Liaison de Données	Trame
7	Physique	Bit

Quand deux hôtes veulent communiquer, les données du premier passent par les couches sucessives de sa pile réseau où elles seront au fur et à mesure encapsulées. Ensuite, la transmission effective se fera sur la dernière couche (la liaison physique). Le deuxiéme hôte recevra les données et les fera repasser par les différentes couches de sa pile réseau dans l'ordre inverse pour au final récupérer les données de départ. Ainsi chaque couche du modèle a l'impression de ne parler qu'avec la couche équivalente sur l'hôte distant, et ignore tout du type de données présentes tant au niveau supérieur qu inférieur (voir illustration).

Ethernet est une technologie destinée aux réseaux à commutation par paquets, inventée par Xerox PARC (1970). Normalisée en 1978 par Xerox, Intel et Digital Equipment.

Tous les équipements Ethernet disposent d'une adresse unique et universelle, représentée sur 48 bits. L'adresse se compose d'un numéro constructeur, de 24 bits, et d'un numéro attribué par le constructeur, de 24 bits également. La notation d'une adresse Ethernet consiste en 6 octets, en notation hexadécimale, séparés par le caractère ":". (exemple 08:00:20:0C:F3:4C caractérise un matériel de la firme Sun).

L'adresse notée FF:FF:FF:FF:FF:FF est l'adresse de diffusion (broadcast). Elle permet d'envoyer un message à toutes les machines du réseau. L'adresse 0:0:0:0:0:0 est réservée.

Description: La trame Ethernet débute par sept octets contenant la valeur 0xAA et un octet contenant la valeur 0xAB. Cet en-tête permet au matériel de se resynchroniser. La synchronisation est réalisée si les deux derniers octets sont décodés correctement. La taille de la trame (moins les 8 octets de préambule) doit être comprise entre 64 et 1518 octets, ce qui laisse de 46 à 1500 octets "utiles". Un contenu plus court que 46 octets est complété par des caractères aléatoires de remplissage. Le CRC est calculé à la volée, il permet de garantir que les informations ont bien été transmises correctement.

Le Champ Protocole reçoit 8 bits identifiant de manière unique le protocole utilisé au niveau supérieur. Ce numéro d'identification est attribué par l'ISO. Il vaut 0x0800 (notation hexadécimale) pour IP et 0x0806 pour ARP (il en existe de nombreux autres mais qui sortent du cadre de ce document).

Bytes: 4	8	12	16
A	A	A	A	A	A	A	B
Adresse de Destination (6 bytes)	Adresse Source (6 bytes)	Protocole	Données...
Données...
CRC (32 bits)

Remarque: Lorsque nous utilisons Ethernet à l'échelle logicielle, l'en tête et le CRC (en bleu dans le schéma) ne seront jamais utilisés, il sont automatiquement ajoutés et vérifiés par la carte réseau et dépendent donc uniquement de l'interface physique (nous les ignorerons donc dans le futur).

Le but de l'ARP⁴ est de trouver l'adresse ethernet (couche transport) d'une machine distante dont on ne connait que l'adresse de la couche réseau (ex: l'adresse IP).

Bytes: 4	8	12	16
			Hardware
Protocole	T1	T2	Code	Adr. physique source	Adr. logicelle source
Adr. physique destination	Adr. logicielle dest.	<Remplissage éventuel>

Description: Le champ Hardware reçoit un identificateur unique définisant le type d'adresse physique que nous voulons résoudre (pour Ethernet il s'agit de 0x0001). Le Champ protocole reçoit un identificateur unique identifiant le protocole des adresses logicielles utilisées pour la résolution (pour IP 0x0800). Le Champ T1 reçoit la valeur de la longueur en octet des adresses physiques (6 octets pour Ethernet) et T2 reçoit la valeur de la longueur en octet des adresses logicielles (4 octets pour IP). Le champ code, quant à lui, reçoit une valeur identifiant l'opération que le paquet accompli. Il peut prendre la valeur 0x0001 pour une requête ARP ou 0x0002 s'il s'agit d'une réponse à une requête. Les quatres derniers champs contiennent les adresses connues de l'hôte qui envoie le paquet, donc dans une requête le champ Adresse Physique Destination reste vide et dans une réponses les 4 champs sont remplis.

Fonctionnement: La machine qui veut contacter un hôte mais qui ne connaît pas son adresse ethernet va envoyer une requête ARP avec l'adresse IP de la machine à contacter et l'adresse de Broadcast comme adresse de destination du packet Ethernet. Toute machine qui reçoit une requête ARP va comparer l'adresse IP du paquet avec sa propre adresse IP et si elle correspondent, va envoyer une réponse ARP à la première machine contenant l'adresse physique demandée. La première machine, recevant cette réponse la stockera dans une mémoire cache interne et connaîtra dorénavant l'adresse matérielle de l'hôte correspondant.

IP⁵ est la base de presque tous les réseaux actuels, c'est lui qui permet à différents ordinateurs de communiquer sur de grandes distances, en passant par de multiples sous-réseaux. IP est la base de l'Internet actuel. Il assure sans connexion un service non fiable de délivrance de paquets IP. Le service est dit non fiable car il n'existe aucune garantie pour que les paquets IP arrivent à destination. Certains peuvent être perdus, dupliqués, retardés, altérés ou remis dans le désordre. Ni l'émetteur ni le récepteur ne sont informés directement par IP des problèmes rencontrés. La transmission est dite non connectée car IP traite chaque paquet indépendament de ceux qui le précèdent et le suivent. Ainsi deux pacquets IP issus de la même machine et ayant la même destination peuvent ne pas suivre obligatoirement le même chemin. Chaque interface connectée au réseau possède une adresse IP unique, cette adresse est représentée par un entier de 32 bits⁶.

Description: Un paquet IP comporte un en-tête, qui décrit ses caractéristiques et permet son acheminement, et un corps, qui contient les données à transmettre. Le champ version (4 bits) contient le numéro de version du protocole IP utilisé (la version courante est la 4, d'où son nom d'IPv4). Le champ longueur (4 bits) contient la taille de l'en-tête du paquet (donc sans les données), en nombre de mots de 32 bits. Ce champ est nécessaire car une en-tête peut avoir une taille supérieure à 20 octets (taille de l'en-tête classique) à cause des options que l'on peut y ajouter. Le TOS (8 bits), indique la manière dont doit être géré le paquet et se décompose en six sous-champs comme suit:

bits	0	1	2	3	4	5	6	7
champs	priorité	D	T	R	C	/

Le champ priorité varie de 0 (priorité normale, valeur par défaut) à 7 (priorité maximale pour la supervision du réseau) et permet d'indiquer l'importance de chaque paquet. Les 4 bits D, T, R et C permettent de spécifier ce que l'on veut privilégier pour la transmission de ce paquet. D est mis à 1 pour essayer de minimiser le délai d'acheminement (par exemple choisir un câble sous-marin plutôt qu'une liaison satellite), T est mis à 1 pour maximiser le débit de transmission, R est mis à 1 pour assurer une plus grande fiabilité et C est mis à 1 pour minimiser les coûts de transmission. Si les quatre bits sont à 1, alors c'est la sécurité de la transmission qui doit être maximisée. Ces 4 bits servent à améliorer la qualité du routage et ne sont pas obligatoires. Simplement, si un routeur connaît plusieurs voies de sortie pour une même destination il pourra choisir celle qui correspond le mieux à la demande. Le champ longueur totale (16 bits) contient la taille totale en octets du paquet (données comprises), et comme ce champ est de 2 octets on en déduit que la taille complète d'un paquet ne peut dépasser 65535 octets (valeur maximale stockée sur 2 octets, 0xFFFF). Utilisée avec la longueur de l'en-tête elle permet de déterminer où commencent exactement les données transportées. Les champs identification, flags et Offset interviennent dans le processus de fragmentation des paquets IP qui sera décrit plus loin dans ce point. Le champ TTL indique le nombre maximal de routeurs que peut traverser le paquet. Elle est initialisée à N (souvent 32 ou 64) par l'émetteur et décrémenté de 1 par chaque routeur qui le reçoit et le réexpédie. Lorsqu'un routeur reçoit un paquet dont la durée de vie est nulle, il le détruit et envoie à l'expéditeur un message ICMP (voir 1.7). Ainsi, il est impossible qu'un datagramme «tourne» indéfiniment dans Internet. Le champ protocole permet d'identifier quel protocole de plus haut niveau est acheminé par le paquet IP (exemple: 6 pour TCP). Le champ checksum est calculé par un algorythme simple à partir de l'en-tête du paquet pour en assurer l'intégrité. L'intégrité des données transportées est elle assurée par les protocoles supérieur (ex: ICMP, IGMP, TCP, UDP). Les champs adresses IP source et adresse IP destination contiennent (32 bits chacun) les adresses de la machine émettrice et destinataire du paquet. Le champ options est une liste de longueur variable, mais toujours complétée par des bits de remplissage pour atteindre une taille multiple de 32 bits pour être en conformité avec le champ longueur. Ces options sont très peu utilisées car peu de machines sont aptes à les gérer. Parmi elles, on trouve des options de sécurité et de gestion, d'enregistrement de la route, d'estampille horaire, routage strict, etc...

Chaque "machine" (carte réseau) du réseau Internet a une adresse unique. Cette adresse est codée sur 4 octets (32 bits). Elle est représentée, en général, par 4 entiers séparés par des '.'. Exemple : « 193.55.44.84 ». Cette adresse contient en fait 2 adresses, les bits de poidd les plus forts (le nombre dépend de la classe, voir plus loin) représentent l'adresse du réseau et le reste l'adresse de la machine dans le réseau. Les adresses réseau se séparent en trois classes : A , B et C. Le nombre d'adresses disponibles dans le réseau diminue de la classe A vers la classe C. Il existe une classe D dédiée au multicast (nous n'en parlerons pas) et une classe E pour les expérimentations. Les 4 premiers bits d'une adresse permettent de trouver la classe du réseau.

Dans notre exemple précédent, 193 = 11000001=128+64+1, l'adresse fait partie d'un réseau de classe C. A chaque classe de réseau correspond un certain nombre de bits pour coder l'adresse du réseau. Les bits restants servent à coder l'adresse de la machine dans le réseau.

C -> 3 premiers octets -3 bits, adresses de réseau de 192.0.1.0 à 223.255.255.0

Exemple : Dans un réseau de classe C, 255 adresses sont disponibles. Certaines adresses IP sont dites reservées il est interdit de s'en servir pour un usage courant. L'adresse du réseau : adresse réseau + 0 partout ailleurs. Cette adresse sert uniquement pour le routage, elle ne peut pas être utilisée en adressage direct. L'adresse de broadcast pour le réseau local est 255.255.255.255. L'adresse de broadcast dirigé pour un réseau est : adresse réseau + 255 partout ailleurs. Ce type de broadcast est souvent interdit. L'adresse 0.0.0.0 représente la machine locale. Cette adresse est uniquement utilisée au boot de machine sans disque. L'adresse réseau 0, suivie d'une adresse machine, représente la machine du réseau local qui a ce numéro. L'adresse de loopback fait référence à la machine locale, mais elle n'est jamais propagée sur le réseau. L'adresse réseau 127.0.0.0 est réservée à cet usage. En général, l'adresse de loopback utilisée est 127.0.0.1.

La notion de classe n'est plus adaptée aux demandes actuelles en matière de réseau. En effet, il n'existe plus de réseau de classe C disponible. Deux notions ont été introduites, le subnetting qui permet de décomposer un grand réseau en plusieurs sous-réseaux et le supernetting qui permet d'agglomérer plusieurs petits réseaux en un grand réseau. Ces deux techniques s'appuyent sur la notion de masque. Un masque permet de déterminer les parties réseau et machine d'une adresse sans s'appuyer sur la notion de classe. Il existe deux façons de représenter les masques. La première consiste à donner le nombre de bits de poids fort (dans les faits) qui constituent l'adresse réseau. La seconde consiste à représenter cette information sous forme de 4 entiers, où les bits à 1 représentent les bits de l'adresse qui participe à l'adresse réseau. Exemple : masque 23 ou 255.255.254.0: adresse sous-réseau codée sur 23 bits.

L'affectation des adresses réseau est géree de façon centrale par l'Internet Assigned Number Authority (IANA)⁷ afin d'assurer l'unicitée de celles-ci. Elle délègue, au niveau régional, ses fonctions à un organisme d'enregistrement qui gère une certaine plage d'adresses. Pour l'europe, l'afrique et une partie de l'europe de l'est, cet organisme a pour nom Réseau IP Européens (RIPE NCC)⁸. Ces organismes s'assurent également que certaines plages d'adresses ne sont jamais affectées:

Ces adresses pourront ainsi toujours être utilisées pour une utilisation privée (par exemple dans un réseau local).

Le nombre maximal d'adresse IP pouvant exister sur 32 bits étant de 2^32 = 4.294.967.296 adresses, laisse penser qu'il y aura toujours un nombre suffisant d'adresses disponibles. Malheureusement, les grosses entreprises achetent des séries entiéres d'adresse (même si une partie ne sont pas utilisées), et l'IANA est d'ores et déjà en pénurie... C'est pour cela que l'IEETF (Internet Engeneering Task Force)⁹ a décidé d'introduire la version 6 d'IP qui note les adresses sur 128 bits soit plus de 3.4e38 adresses (plus que le nombre d'électrons dans l'univers) ce qui devrait résoudre définitivement ce problême de pénurie.

Au cours de sa route, un paquet peut traverser différents réseaux physiques dont les trames n'ont pas nécessairement la même taille maximale ou Maximum Transfert Unit (MTU) (pour ethernet 1500 octets). Il est donc parfois nécessaire de les découper en plusieurs fragments dont la taille est adaptée à la MTU du réseau traversé. L'en-tête du protocole IP contient trois champs réservés à la fragmentation, identificateur, flags et offset pour. Chaque fragment d'un paquet a pratiquement la même en-tête IP que le paquet original. En particulier, ils ont le même identificateur, un entier différent pour chaque paquet émis, ce qui permet de reconnaître les fragments. En outre de la taille totale et du checksum qui sont nécessairement recalculées, l'offset et les bits de flags sont différents. L'offset correspond à la position en multiple de 8 octets du début du fragment dans le paquet original (le premier fragment a l'offset 0). La taille maximale de l'en-tête étant de60 octets, ceci implique que tout routeur IP ne doit pas fragmenter au dessous de 68 octets. Le premier bit des flags est réservé et doit être positionné à 0. Le second, DF (Don't Fragment bit), indique s'il est à 1 que le paquet doit être éliminé plutôt que d'être fragmenté. Le dernier, MF (More Fragments bit), indique s'il est à 1 que le paquet est fragmenté et que les autres fragments suivent (seul le dernier fragment ou un paquet non fragmenté a le flag MF à 0). Le réassemblage¹⁰ des fragments se fait à l'arrivée sur la machine destinatrice. Pour connaître la taille du paquet original la machine destination doit recevoir le dernier fragment, celui dont le MF bit est à 0. Grâce à son offset et sa taille totale, il peut calculer la taille totale du paquet original.

Le routage est effectué de proche en proche en fonction de l'adresse IP du destinataire et des tables de routage des différentes machines rencontrées. Pour la machine source l'algorithme d'envoi dans les cas simples est le suivant :

TCP¹¹ est l'autre protocole associé avec IP sur qui l'architecture actuelle d'Internet repose. Si IP permet l'envoi et la réception de données entre deux machines, c'est gràce à TCP qu'un dialogue peut se créer entre elle.

L'en-tête, sans option, d'un segment TCP a une taille totale de 20 octets et se compose des champs suivants: Le port source et le port destination identifient les applications émettrice et réceptrice. Le numéro de séquence donne la position du datagramme dans le flux de données envoyées par l'émetteur. Ce numéro est incrémenté de 1 à chaque datagramme envoyé. Le numéro d'acquittement contient en fait le numéro de séquence suivant que le récepteur s'attend à recevoir; c'est-à-dire le numéro de séquence du dernier datagramme reçu plus 1. Le champ Longueur (4 bits) contient la taille de l'en-tête TCP, y compris les options présentes, codées en multiple de 4 octets. Ainsi une en-tête peut avoir une taille variant de 20 octets (aucune option) à 60 octets (maximum d'options). Le champ Réservé (6 bits) est réservé à un usage ultérieur du protocole, il n'est donc pas utilisé. Le champ Flag est décomposé en 6 bits de code qui permettent de spécifier le rôle et le contenu du datagramme TCP.

Le champ window (16 bits) sert au contrôle de flux. Il indique le nombre d'octets (moins de 65535) que le récepteur est prêt à accepter. Ainsi l'émetteur augmente ou diminue son flux de données en fonction de la valeur de cette fenêtre qu'il reçoit. Le checksum est une somme de contrôle sur 16 bits utilisée pour vérifier la validité de l'en-tête et des données transmises. Il est obligatoirement calculé par l'émetteur et vérifié par le récepteur. Le pointeur d'urgence est un offset qui, ajouté au numéro de séquence du datagramme, indique le numéro du dernier octet de donnée urgente. Il faut également que le bit URG soit positionné à 1 pour indiquer des données urgentes que le récepteur TCP doit passer le plus rapidement possible à l'application associée à la connexion (nous ne parlerons pas plus de données urgentes). Le champ options (bien que facultatif) permet, entre autre, de négocier la taille des segments envoyés, en fonction de la capacité mémoire de la machine réceptrice et éventuellement de la MTU des réseaux traversés. Le champ remplissage comme pour IP sera rempli en fonction des options de telle façon que le header soit un multiple de 32 bits.

Pour assurer la sécurité des données, quand une machine reçoit un datagramme TCP, elle renvoie à l'émetteur un datagramme d'acquittement, avec le flag ACK mis à 1. L'émetteur sait ainsi que les données on bien été reçues et peut continuer la transmission ou si après un laps de temps il ne reçoit pas de ACK il peut réemettre le datagramme. La machine réceptrice qui va émettre le ACK va aussi pouvoir remplir le champ window avec la taille disponible dans son tampon, ainsi l'émetteur n'enverra pas plus que ce que le récepteur peut recevoir et ne devra pas réemettre les données.

Pour couper la connection, on procéde exactement de la même manière sauf que le flag SYN est remplacé par un FIN et que l'on prendra les valeurs de SEQ/ACK en cours de la connection.

Le protocole UDP¹² n'ajoute pas de service particulier par rapport à IP, il permet seulement le multiplexage/démultiplexage des communications entre applications grâce à la notion de port.

Description: Les numéros de port (chacun sur 16 bits) identifient les processus émetteur et récepteur. Le champ longueur contient sur 2 octets la taille de l'en-tête et des données transmises. Puisqu'un datagramme UDP peut ne transmettre aucune donnée la valeur minimale de la longueur est 8. Le checksum est une somme de contrôle qui n'est pas indispensable lorsque UDP est utilisé sur un réseau très fiable. S'il est fixé à 0 c'est qu'en fait il n'a pas été calculé.

Le protocole UDP utilise IP pour acheminer, d'un ordinateur à un autre, en mode non fiable des datagrammes qui lui sont transmis par une application. UDP n'utilise pas d'accusé de réception et ne peut donc pas garantir que les données ont bien été reçues. Il ne réordonne pas les messages si ceux-ci n'arrivent pas dans l'ordre dans lequel ils ont été émis et il n'assure pas non plus de contrôle de flux. Il se peut donc que le récepteur ne soit pas apte à faire face au flux de datagrammes qui arrivent. C'est donc à l'application qui utilise UDP de gérer les problèmes de perte de messages, duplications, retards,déséquencement, ... Si une erreur de transmission est détectée, le datagramme UDP est détruit «en silence» (sans message d'erreur, voir 1.7). Sinon, UDP oriente les données du datagramme vers la file d'attente associée au numéro de port destination pour que l'application associée puisse les y lire.

Le protocole ICMP¹³ permet aux routeurs d'envoyer des messages d'erreur à d'autres ordinateurs ou routeurs. Le but d'ICMP n'est pas de fiabiliser le protocole IP, mais de fournir à une autre couche IP, ou à une couche supérieure de protocole (TCP ou UDP), le compte-rendu d'une erreur détectée dans un routeur. Un message ICMP étant acheminé à l'intérieur d'un datagramme IP, il est susceptible, lui aussi, de souffrir d'erreurs de transmission. Mais la règle est qu'aucun message ICMP ne doit être délivré pour signaler une erreur relative à un autre message ICMP. On évite ainsi une avalanche de messages d'erreur quand le fonctionnement d'un réseau se détériore.

Description: Le champ type peut prendre 15 valeurs différentes spécifiant de quelle nature est le message envoyé. Pour certains types, le champ code sert à préciser encore plus le contexte d'émission du message. Le checksum est une somme de contrôle de tout le message ICMP calculée comme dans le cas de l'en-tête d'un paquet IP. Le détail des différentes catégories de messages est donné en Annexe II pour éviter d'encombrer de détails techniques ce document. Nous encouragons vivement, malgré tout, le lecteur à aller la consulter.

De nombreuses applications fonctionnent selon un environnement client/serveur, cela signifie que des machines clientes (des machines faisant partie du réseau) contactent un serveur, une machine généralement plus puissante en terme de capacité d'entrée-sortie, qui leur fournit des services. Ces services sont des programmes fournissant des données telles que des fichiers, une connexion, ...

Les services sont exploités par des programmes, appelés programmes clients, s'exécutant sur les machines clientes. On parle ainsi de client FTP, client de messagerie, ..., lorsque l'on désigne un programme, tournant sur une machine cliente, capable de traiter des informations qu'il récupère auprès du serveur (dans le cas du client FTP il s'agit de fichiers, tandis que pour le client messagerie il s'agit de courrier électronique).

Dans un environnement purement Client/serveur, les ordinateurs du réseau (les clients) ne peuvent voir que le serveur, c'est un des principaux atouts de ce modèle.

Comme nous venons de le voir dans le point 1, les différents protocoles qui assurent le fonctionnement d'un réseau utilisent des systèmes automatisants la sécurité de transmission et l'intégrité des données qui traverse le réseau. Les dangers potentiels pour la sécurité ne se trouveront donc pas dans la transmission physique des données, ni dans leur traitement par les systèmes informatiques. La sécurité de l'information et des systèmes chargés de la traiter ne pourra dont être compromise que par une utilisation abusive, qu'elle soit volontaire ou non, externe ou interne.

Pour pouvoir assurer la sécurité d'un réseaux, il importe donc de définir avant tout l'ensemble de ce que la sécurité devra prendre en charge et protéger. Tout d'abord, nous pouvons définir les trois services de base que la sécurité devra assurer:

De la même manière, nous pouvons définir les trois notions fondamentales que les dispositifs de sécurité d'un réseau devront protéger:

Avec ces notions en tête, nous pouvons définir facilement les trois types d'intrusions auxquelles la sécurité devra faire face:

Il est évident qu'il existe de nombreuses formes d'agressions pouvant se classer dans ces catégories (nous parlerons d'ailleurs en détail de plusieurs d'entre elles dans les points suivants), mais la technique étant une chose, il importe aussi de se préoccuper des personnes qui compromettent la sécurité du réseau, les agresseurs. Il y a plusieurs types d'agresseurs. Il est très important d'estimer le type d'agresseur en cas d'incident pour évaluer la gravité potentielle du sinistre et surtout prendre les mesures qui conviennent. Parmi eux, on peut citer notemment:

Finalement, lorsque vous devez concevoir et mettre en place des procédures de sécurité pour votre réseau, il existe trois principes à toujours garder à l'esprit:

C'est en partant de ce constat et de ces régles que nous allons aborder le point suivant, qui visera à expliquer quelles sont les techniques utilisées par un pirate. Nous pourrons ainsi prévoir et installer des procédures de sécurité sur le réseau qui feront échouer la plupart des attaques.

Dans ce chapitre nous allons décrire les quelques étapes générales qui vont permettre à un pirate de compromettre l'intégrité et la confidentialité des données qui traversent votre réseau. Il pourra par la même occasion mettre en danger votre réputation, puisqu'il pourra altérer des données dont vous êtes la source authentifiée. Comme nous l'avons vu dans le point précédent, nous allons raisonner comme un pirate et analyser les techniques qu'il employera pour pouvoir, par après, mettre en place des procédures de sécurité fiable.

Généralement, une attaque va se faire en trois étapes principales. La première va être la prise d'informations : le pirate va essayer d'obtenir un maximum d'informations sur sa cible. La deuxiéme sera l'attaque proprement dite, c'est à dire la pénétration du réseau et du système. La troisiéme quant à elle consistera en une infiltration discrète, soit pour attaquer d'autres réseaux/systèmes, soit pour camoufler les traces du pirate sur le système compromis et lui garantir un accèss illégitime futur. Nous allons détailler les techniques relatives aux réseaux qui permettent de remplir ces trois étapes.

Il existe deux types d'informations qui vont principalement intéresser nos pirates, les premières sont de types identitaires, c'est à dire les noms, adresses, noms/prénoms des femmes et enfants des responsables de la sécurité informatique, du patron et/ou des employés qui sont en contact direct avec la cible (souvent le réseau d'une entreprise). Ces informations peuvent facilement être obtenues anonymement sur Internet en utilisant des moteurs de recherches, les pages blanches, etc. Citons tout de même l'outils WHOIS qui permet d'afficher de nombreuses informations souvent privées sur un nom de domaine. Voici un exemple de l'utilisation de cet outil sur le nom de domaine du site du gouvernement belge, http://www.fgov.be:

Comme on peut le voir l'outil WHOIS peut renvoyer très facilement un nombre non négligeable d'informations utiles pour un pirate. Toutes ces informations identitaires seront principalement utilisées dans une attaque de type Social Engeenering (SE ou «manipulation sociale») (voir le point B du présent chapître).

L'autre type d'informations recherchées par un pirate va principalement être des détails techniques concernant l'architecture et les services ouverts de la cible. Pour ce faire, il existe de nombreuses techniques mais la plus connue et universellement utilisée aussi bien par les pirates que par les administrateurs réseaux est celle du Scan TCP.

Le scan TCP est très simple, on utilise un programme qui va tenter de se connecter sur tous les ports de la machine distante (rappel: un port dans le protocole TCP est noté sur 16 bits, soit 65536 ports possibles) n'affichant que ceux qui sont ouverts, donc ceux pour lesquels la machine attend une connection eventuelle, soit ceux pour lesquells il existe un service associé (80 pour le serveur http, 21 pour le ftp etc.) (Une liste des ports courants associés avec leurs services peut être trouvé en annexe III).

Bien entendu ce scan ne passera pas inaperçu auprès de l'administrateur réseau un tant soit peu attentif, c'est pour cela qu'il existe de nombreuses variantes techniquements plus poussées permettant de camoufler le scan¹⁵. Le plus connu et le plus abouti des programmes implémentant ces techniques se nomme nmap (http://www.insecure.org/nmap), chaque administrateur réseau devrait l'utiliser de temps en temps, pour se rendre compte de ce que son réseau laisse transparaître comme informations.

Citons parmi ces techniques celle dites du SYN Scan qui va commencer une connection TCP en envoyant un datagramme avec le flag SYN, et qui renverra un paquet RST en réponse à un SYN/ACK du serveur (si le port n'est pas ouvert le serveur renvoie un RST, il est donc inutile de répondre) (cfr pt 3.1.e tiret 4, le protocle TCP, méthode de connection). Ainsi on ne crée jamais de connection complète tout en sachant quels sont les ports ouverts sur la machine. Cette méthode présente le double avantage immédiat qu'elle est plus rapide (envoi d'un paquet au lieu d'un three way handshake classique), et beaucoup plus discrète (le serveur n'enregistrant pas les tentatives de connection abortées).

Une fois que le pirate sera informé des services tournant sur la machine, il va tenter de se connecter à ceux-ci pour déterminer le logiciel et la version de celui-ci sur la machine. Ensuite il pourra utiliser des bases de données tel que celle de http://www.securityfocus.com (qui héberge le fameux bugtraq) et http://www.packetstormsecurity.com pour vérifier si la version installée présente une faille connue qu'il pourra exploiter.

Mais il existe une autre information capitale que voudra absolument récupérer tout agresseur, il s'agit de l'OS sur lequel fonctionne le système ciblé. En effet, l'OS va conditionner toute la stratégie qu'un pirate adoptera. De plus une faille sur un Microsoft Windows NT^® ne fonctionnera pas de la même façon que sur Sun Solaris^® ou sur un système GNU/Linux. Il existe pour cela une méthode très efficace, nommée IP Stack Fingerpting (Prise d'empreinte de la pile TCP/IP). Elle se base sur le fait que les différents OS n'implémentent pas de la même manière les protocoles IP et TCP. La plupart des OS répondront différement si on leur envoie des paquets anormaux ou bizzares (par exemple avec tous les flags mis à 1, ou les flag SYN et FIN ensembles), il est donc facile de construire une base de données des réponses de la pile TSP/IP en fonction de l'OS et de deviner quel OS est installé sur une machine cible (Voir l'Annexe V pour le document de référence concernant cette technique).

Démonstration sur mon résau local d'une prise d'empreinte de pile doublé d'un SYN Scan TCP avec le logiciel nmap:

On voit clairement que nmap a correctement identifié les ordinateurs du réseau local (ED: Linux 2.4.16 et ROUTEUR: Linux 2.2.19) ainsi que les ports ouverts avec leurs services associés. Il existe des techniques permettant de tromper les outils comme Nmap, par exemple en modifiant manuellement la pile réseau de la machine (souvent utilisé par les IDS).

Une fois la cible étudiée sous toutes ses coutures, notre pirate potentiel passera à l'attaque proprement dite, c'est à dire la pénétration du réseau et d'un ou des systèmes qui le composent. On ne peut malheureusement pas généraliser cette étape car elle ne se produit jamais deux fois de la même façon. Mais, assez souvent, on peut déduire deux tendances:

Si le pirate tente une attaque de l'extérieur, peu de choix s'offrent à lui. A moins d'une politique de sécurité à ce point excécrable qu'elle mettrait en danger la survie même d'un service informatique quelconque, un agresseur ne pourra compter que sur ce que nous décidons de lui fournir, c'est à dire les services que nous laissons accessibles à l'extérieur du réseau (souvent des services que nous laissons accessibles pour Internet, ex: un serveur Web, un serveur FTP, un serveur de messagerie, etc.).

Malheureusement, la plupart des programmes que nous utiliserons légitimement pour assurer un service sur un système peuvent facilement se retourner contre nous. En effet, ces logiciels, même s'il sont utilisés à grande échelle, ne sont pas exempts de bogues. Et ces bogues, peuvent parfois permettre à l'attaquant de compromettre le système visé dans son entier.

Nous allons voir deux exemples de techniques qui permettent de rentrer sur un système informatique illégitimement, en abusant des services que celui-ci fournit. Rapellons tout de même qu'il ne s'agit ici que de 'proof of concept' (littéralement, preuve de concept, voir lexique), et qu'il est bien entendu illégal de faire ce qui suit sur un système qui ne dépendrait pas de vous (il peut même s'agir d'une motivation de renvoi si vous testez ceci dans votre entreprise sans la permission expresse de l'administrateur).

Dans tout système informatisé, la première faille est toujours la composante humaine. Il est tellement plus facile de tromper un homme qu'une machine correctement sécurisée que c'est même la faille la plus dangereuse pour votre réseau. Un simple coup de fil ou email provenant d'une personne réputée sûre (l'administrateur réseau, le patron de la société, le technicien en charge de la maintenance) permet souvent de récupérer des passwords vitaux pour le réseau.

Cette méthode s'apparente à de la manipulation, un pirate se faisant passer pour quelqu'un d'autre prendra un ton généralement ascendant sur son correspondant, l'inondant de termes techniques et lui promettant les pires problêmes s'il n'accède pas à sa requête.

Au delà de l'anectode, cette méthode a fait ses preuves de nombreuses fois, il est donc indispensable de sensibiliser les gens qui accédent à un système informatique dont vous êtes responsable afin qu'il ne fasse pas confiance à n'importe quel quidam même s'il se présente comme étant quelqu'un d'important, et vous même devez être très attentif quand quelqu'un demande des informations qui ont un caractère confidentiel.

On comprend ici tout l'intérêt que peuvent prendre les informations de type identitaires qu'un pirate aurait récolté au point 3.1.A tiret 1.

L'exemple le plus connu de ce genre de problême est le débordement de tampon (Buffer Overflow ou BO). Ce bugs se présente lorsqu'un programme n'alloue pas assez de mémoire pour stocker une donnée en mémoire, et lorsqu'il écrit trop de données sur cet emplacement trop petit. Il va alors écrire sur des zones de la mémoire occupées par d'autres données. Jusque là rien de bien dramatique du point de vue de la sécurité, juste un beau plantage en prévision. Seulement voilà, si les données que le programme écrit sur les zones mémoires non allouées à cet effet sont envoyées par un pirate, il peut inclure dans celle-ci un code malicieux, qui, dans certaines conditions, sera exécuté par la machine. Ainsi donc, notre pirate pourra exécuter n'importe quel code sur la machine (le plus souvent ce code lui donnera accès à un terminal, ou shell). Vous pouvez trouver en Annexe VI un document plus complet et relatif au BO.

Pratiquement, il suffira à notre pirate, qui aura identifié dans la phase A du présent chapître un programme vulnérable à un tel problême, de trouver et d'exécuter un bout de code lui donnant l'accès complet au système. Cette technique est assez simple à mettre en oeuvre, et n'importe quel débutant pourra utiliser les codes faits par d'autres, trouvés sur des sites de sécurité.

La plupart du temps, le point vulnérable d'un réseau est le serveur Web lui même, car:

Il existe des outils simples, gratuits et légaux, utilisables par le premier quidam venu pour scanner un serveur Web à la recherche de CGI vulnérable à des bogues connus. Voici la démonstration d'un de ces scanner de CGI sur un site (exemple réel):

On peut voir directement les fichiers préssents, connus pour présenter des failles. Prenons par exemple le cas du fichier «/_vti_pvt/service.pwd», il s'agit en fait des passwords (cryptés) des utilisateurs frontpage¹⁶ du site. Il suffit de passer ce fichier dans un décrypteur de password (tel que John The Ripper¹⁷) pour assez rapidement se retrouver avec les passwords qui permettront à n'importe quel pirate d'accéder au système illégitimement:

Bien évidemment l'exemple donné ici relève de la blague, ce serveur, bien que réel, a été configuré exprès pour laisser apparaître de soi-disant failles. Mais il existe encore beaucoup de serveurs prèsentant des failles similaires, bien réelles celles-là.

Comme nous venons de le voir, il existe de nombreuse failles que peut exploiter un pirate pour s'immiscer dans un réseau externe. Mais il arrive fréquement que l'agresseur vienne du réseau interne lui même, qu'il s'agisse d'un pirate infiltré sur une des machines, d'un veilleur de nuit un rien trop conscencieux, ou d'un employé désirant se venger de son patron. Tout cela nous oblige à considérer les faits d'un autre oeil, car les possibilités qui s'ouvrent alors deviennent beaucoup plus importantes.

Si nous considérons que l'agresseur à un accès physique au réseau (que ce soit les cables ou les machines), les possibilités qui s'ouvrent à lui sont bien plus importantes. En effet, il ne devra plus se contenter d'essayer de trouver un service exploitable sur la machine mais pourra prendre l'initiative, qu'il agisse de manière active ou passive.

Si notre pirate a un accès physique à un système présent sur le réseau, ou même s'il peut se connecter sur les cables de celui-ci, il pourra assez facilement pratiquer le Sniffing, c'est à dire l'interception systèmatique des paquets Ethernet passant a sa portée.

En effet, sur un réseau local de type Ethernet, comme nous l'avons vu, chaque paquet possède l'adresse MAC de la machine destinataire. Les interfaces réseaux recevront tous les paquets, mais ne passeront que ceux qui les concernent à la couche supérieure de la pile réseau (la plupart du temps la pile IP du système d'exploitation). Oui, mais seulement voilà, ce comportement peut facilement être changé. Il est très facile de configurer sa carte réseau pour qu'elle passe TOUS les paquets à la couche supérieure de la pile, même si ceux-ci ne lui sont pas du tout destinés.

On voit tout de suite le problème de sécurité que cela pose, en effet une machine réseau peut intercepter tout le trafic passant sur celui-ci (données, mot de passe, etc.) sans que cela ne soit remarquable pour les autres machines du résau. C'est pour cela que cette méthode est dite passive.

Il existe de nombreux outils permettant de sniffer son réseau, et en coder un soi même n'est pas très dur. Voici un exemple d'utilisation avec un programme que j'ai fais moi même, très simple d'utilisation (mais sans aucune option intéressante je le crains), il se contente d'afficher les paquets traversant le réseau en forme hexadécimal et sous forme de chaîne de caractères:

Le paquet ici affiché est celui que mon sniffer à intercepté quand j'ai tenté d'aller lire ma boîte e-mail (j'ai, bien entendu, modifié manuellement le password ici, mais le reste du paquet est authentique). Comme on peut le voir, le password transite en clair sur le réseau, et n'importe qui peut l'intercepter pour autant qu'il sache quoi chercher.

Les passwords email ne sont pas les seules données importantes qui transitent sur le réseau, on peut aussi citer tous les password d'administration a distance, de compte FTP, etc. Et bien entendu les données brutes comme par exemple les emails eux-même...

Nous venons de voir les dangers que pouvait présenter une agression passive du réseau local, mais bien souvent le but d'un agresseur quel qu'il soit sera de mener une action bien concrète, après avoir compromis la sécurité du réseau, il va sûrement tenter une attaque active, en devenant lui même un acteur, c'est ce dont nous allons parler maintenant.

La technique dite du détournement de session (ou Spoofing) va permettre à un agresseur de se faire passer pour quelqu'un d'autre sur le réseau dans le but de gagner des priviléges auxquels le système informatique ne lui donnerait pas accès autrement.

Comment cela fonctionne t'il ? De la même manière que nous pouvons facilement faire passer notre interface réseau dans un mode de réception des paquets qui ne lui sont pas destinés (voir le point précédent), nous pouvons faire envoyer des paquets à notre interface réseau qui ne proviennent pas de nous.

Rappellez-vous que ce qui identifie l'émetteur d'un paquet c'est l'adresse IP contenue dans le champ Source (et aussi l'adresse MAC du paquet ethernet mais nous ne parlerons ici que de spoofing IP, pour un exemple de spoofing Ethernet, reportez vous au point suivant) de ce paquet. Or, il est très facile de créer soi-même des paquets et de changer l'adresse IP source, ainsi toutes les autres machines du réseau croiront à un paquet légitime venant de la personne dont nous volons l'identité.

Notons au passage qu'il n'est pas obligatoire que l'identité que nous volions soit réelle, ou que le système qui la possède soit actuellement opérationel. Au contraire, il est préférable (toujours du point de vue de notre pirate bien sûr) que la machine à qui il vole son adresse IP ne soit pas active, sinon elle risquerait d'annuler les transmissions avec des paquets TCP/RST intempestifs, voire même cela pourrait mettre la puce à l'oreille de l'administrateur réseau. Il existe des techniques qui permettent de désactiver temporairement un hôte sur le réseaux, nous en parlerons dans le point 3.2.

Les avantages que pourrait en retirer un pirate sont de deux ordres. Premièrement il pourra sans doute passer sans trop de difficulté certaines des protections mises en place par l'administrateur réseau; deuxièmement, il pourra accéder à un terminal à distance sur une des machines grâce au protocole rlogin¹⁸.

Pratiquement, cette technique devra être combinée avec celle du sniffing, puisque, rappelez-vous le principe du TCP une connection ne pourra se faire que si l'agresseur recoit la réponse du serveur puisque celle-ci contiendra les numéros SEQ (l'ISN) nécessaires pour renvoyer le prochain paquet. Si on envoie une fausse adresse IP, nous ne recevrons bien entendu pas la réponse, puisqu'elle ne nous sera pas destinée. Par contre en sniffant le réseau, il sera possible d'intercepter la réponse et d'envoyer le paquet suivant, toujours en modifiant l'adresse IP source, comme si de rien n'était.

Notons également que cette technique est utilisable même quand on ne se trouve pas dans le réseau local, mais par exemple sur l'Internet. Mais elle se décline sous une forme différente. En effet sur Internet, nous ne pourrons récupérer les paquets réponses du serveur qui ne nous sont pas destinés en les sniffant, vu qu'ils seront automatiquement routés par le protocole IP vers leur destination normale. Le principe, nommé Blind Spoofing (détournement de session en aveugle), se base sur le fait qu'il est (parfois) possible de deviner les numéro d'ISN que va générer le serveur que nous essayons de tromper. Ainsi si on devine ce numéro, on peut quand même assurer une connection et envoyer des commandes à un terminal même si nous ne recevons jamais les réponses. Noter qu'en Annexe VII se trouve un excellent document sur le sujet, faisant une analyse statistique et résumant très clairement cette technique.

Un problème évident apparait avec les méthodes précédentes dès qu'on essaye de l'appliquer dans le cadre d'un réseau switché (et la plupart des réseaux de taille moyenne le sont). En effet, le switch ne va pas renvoyer les paquets qui ne nous sont pas destinés puisqu'il pensera qu'ils sont destinés à quelqu'un d'autre. Nous ne pouront donc pas les sniffer puisqu'ils ne passeront pas sur notre branche du réseau local.

Il existe une technique permettant de résoudre ce problème (toujours du point de vue de l'agresseur bien entendu), il s'agit de l'ARP Cache Poisoning (infiltration du cache ARP). Cette technique se base sur le fait que les switchs pour décider de la route que doit emprunter un paquet vont consulter une table de routage, régulièrement mise à jour, située dans leur mémoire interne. L'idée de l'attaque est donc d'inscrire de fausses informations pour que le switch pense que l'adresse IP que nous tentons de spoofer se trouve bel et bien sur le même brin local que la machine attaquante.

Pour ce faire, le pirate va envoyer des requêtes ARP complètement spoofées, aussi bien au niveau des adresses MAC sources, que des adresses IP. Le switch, transférant ces requêtes ne manquera pas de mettre à jour sa table de routage avec ces nouvelles (mais fausses) informations. Ainsi lorsque notre pirate tentera son détournement de session IP, le switch lui renverra les paquets qu'il pourra tranquillement intercepter.

Cette technique en amène une autre, l'attaque du Man In the Middle (MiM). Celle-ci à lieu, lorsque, combinant toutes les techniques que nous venons de voir (interception de paquet, détournement de session et ARP Cache Poisoning), un attaquant va s'infiltrer entre un client et un serveur.

Imaginons un client A, un serveur B, et un pirate X. Lorsque A va vouloir communiquer avec B (par exemple pour récupérer ses emails ou une page web), X va intercepter la connection, et s'assurer que B ne recoive jamais la demande. X va alors engager une connection avec B et une fois celle-ci établie, renvoyer à A une fausse connection (en la spoofant). Dès que A ou B veulent s'envoyer des informations, X les intercepte, les analyse (et en garde ce que bon lui semble), les modifie éventuellement, puis les renvoie à l'autre qui n'y voit que du feu. A et B sont persuadés de communiquer directement l'un avec l'autre, pourtant toutes les données transitent par X, qui peut les modifier à loisir !

Toutes ces techniques internes à un réseau (puisque reposant sur Ethernet) combinées avec les techniques externes (qui restent bien entendu exploitables depuis l'intérieur d'un réseau) vont assez facilement permettre à un agresseur quelconque de récupérer des accès non autorisés sur des systèmes importants du réseau (souvent les serveurs web, mail, ftp, etc.).

Une fois son forfait accompli, le pirate va bien entendu tenter de se camoufler et de garder ces accès privilégiés (sauf si son action n'est que purement destructive, et dans ce cas il ne prendra aucune peine à se cacher). Ce sont d'ailleurs les techniques les plus vicieuses, car elle ne ménent pas au changement pendant quelques heures d'une page web, ou au vol de quelques informations, mais en s'infiltrant, le pirate va compromettre systématiquement toutes les données de votre réseau (et donc toute l'utilité que vous pouvez en avoir). C'est le sujet dont nous traiterons dans le point suivant.

Autant le dire tout de suite, ces techniques sont généralement de très haut niveau technique, je m'abstiendrai donc d'en montrer les détails de fonctionnement, préférant les exemples et en satisfaisant à une explication toute théorique (mais malheureusement surfaite). Le fait est que si un pirate est réellement infiltré sur votre réseau, vous ne pourrez plus croire quoi que ce soit sur vos systèmes. Les données sur le réseau peuvent être modifiées à la volée, votre système peut vous cacher des informations et vous mentir délibérement. En fait il n'existe pas vraiment de limite à ce qu'un pirate est capable de modifier, sinon le temps qu'il y consacrera.

Les chevaux de Troies (ou backdoor) sont simples. Il s'agit de programmes piégés (d'ou la référence au fameux piège de l'antiquité qui fit tomber la fière ville de Troie) laissés par l'agresseur après son départ. Leur exécution à distance va garantir au pirate de pouvoir réaccéder au système, ou de pouvoir le contrôler à distance. Souvent ces programmes sont identifiés comme des virus par les logiciels d'Anti-Virus, il s'agit d'une erreur commune. Certains de ces programmes sont devenus très connus, et sont passé dans le domaine commercial pour devenir de grands programmes d'administration à distance.

Notons tout de même que ces programmes sont très peu discrets, facilement détectables et il est facile de s'en débarrasser. Il n'empèche qu'ils restent très utilisés, sûrement pour le coté ludique de la chose (plop j'ouvre ton lecteur cd-rom...).

Un véritable hackers qui pénêtrerait votre réseau et votre système emploierait des méthodes beaucoup plus discrètes, il modifierait directement votre système d'exploitation. Il est en effet possible (bien que techniquement difficile) de modifier les fichiers qui font la base du système d'exploitation, et cela aussi bien sous des systèmes propriétaires (Microsoft Windows toutes version, Sun Solaris, Unix System V, ...) qu'Open Source (GNU\Linux, *BSD, ...), que vous fonctionniez en plateforme IBM PC Compatible (architecture Intel) ou sous des architectures comme Sparc.

La diversité des systèmes d'exploitation et des architectures qui existent interdisent toute tentative de généralisation en la matière. Pourtant nous pouvons quand même dire qu'il s'agit généralement d'un module chargé dans le noyau du système d'exploitation, laissant au hacker toute liberté, il peut au choix cacher des programmes, des fichiers, des ressources de son choix au regard de l'administrateur. De la même manière il peut s'assurer un accès total et complet au système depuis l'extérieur en implémentant des backdoors directement dans la couche réseau du système. En fait il n'existe que la limite de ce qui est possible avec un ordinateur.

Notons également l'arrivée récente de pack complet permettant au premier venu d'installer ce genre de modification. Ces packs, dénommés rootkits permettent d'installer très facilement des backdoors hier encore réservés à une certaine élite de pirate. Heureusment pour nous, ces rootkits sont facilement identifiables, et la plupart des gens les utilisant n'ont pas les compétences requises pour les modifier, vous n'aurez donc pas trop de mal en temps qu'administrateur à les repérer et les éliminer.

Si vous désirez approfondir le sujet, voici une liste de liens que vous pourrez consulter à toutes fins utiles:

Le deni de service (ou Denial of Service soit DoS) est une attaque de type paralysante, elle va compromettre la disponibilité de votre réseau ainsi que mettre en danger les ressources de vos systèmes (temps CPU, utilisation de la bande passante, l'espace disque, etc.).

La technique du Denial of Service, apparue en 1987, consiste à envoyer des requêtes à un serveur afin de l'immobiliser et de le rendre inactif. L'attaque se faisant sur des services déterminés elle visera donc des ports précis.

Pour cela, l'attaquant va envoyer (via des logiciels appropriés) d'énormes flots de données, des requêtes (valides ou invalides) sur le port ciblé. Le serveur va tenter de traiter ou d'interpréter ce flux, ce qui va provoquer une forte consommation de ses ressources.

Le résultat peut aller d'une consommation importante des ressources CPU jusqu'à un blocage total du serveur. Il n'est plus alors en mesure de répondre à toutes les requêtes, et les services qu'il fournit normalement ne sont donc plus visibles par les clients. Il est en général nécessaire de relancer le serveur pour rétablir une utilisation normale.

Le résultat sera différent selon l'attaque utilisée. De nombreux types d'attaques DoS existent, cela va du simple flood (envoi massif de données) jusqu'à des techniques extrêmement pointues (modification des tables de routages, attaque via un IP spoofé, ...).

Un exemple de technique dévastatrice est l'envoi d'une requête ICMP Echo (un ping) à plusieurs serveurs Broadcast en spoofant l'adresse IP de la victime ciblée. Ces serveurs de broadcast ont la particularité de re-router la requête à tous les ordinateurs de leur classe réseau, qui eux-mêmes vont chacun répondre à la requête par un ICMP (mais vers l'adresse IP que nous avons spoofée, donc la cible).

Ainsi en envoyant quelques simples paquets aux serveurs de broadcast, la victime va recevoir plusieurs dizaines de milliers de réponses, les effets allant d'un ralentissement de la connexion jusqu'au blocage pur et simple. Cette attaque porte le nom de smurf.

Avec ce schéma (simpliste) on constate que pour 2 paquets envoyés par l'attaquant, la victime en recevra 15000. Ainsi, avec 1000 pings envoyés la cible en recevra 7.500.000. De quoi saturez trés facilement n'importe quel serveur.

Le déni de service distribué ou "Distributed Denial of Service" (DDoS) est un phénomène apparu à grande échelle en 1999. Cette technique est bien connue pour avoir été utilisée contre les sites d'Amazon.com, de Yahoo, de CNN, d'eBay et le site du Washington Post, les paralysant pendant plusieurs heures (ce qui pour un site commercial ne reprèsente pas un grand danger en lui même, mais imaginez que l'attaque se soit portée sur les serveurs des gestionnaires du trafic aérien ou d'un hopital...).

Le principe de l'attaque repose sur quatre acteurs (qui sont des programmes informatiques):

Chaque agent réalise une partie de l'attaque, mais si un agent est "découvert" et bloqué par la victime, un autre peut prendre la rélève. Quant à la technique d'attaque finale, elle est configurable : smurf, flood, ...

Généralement les agents sont des backdoors sur des systèmes piratés au préalable et qui ne s'activeront que quand l'attaque aura été lancée.

Notons que cette attaque même si elle ne fait pas de dégât en elle même (paralyse juste l'infrastructure informatique) (bien qu'encore une fois cela dépend de la cible) est assez dangereuse, car elle ne peut être prévenue d'aucune façon. En fait il n'existe pas de réel moyen de s'en protéger, même une fois celle-ci commencée, excepté par des actions judiciaires¹⁹ qui sont évidemment d'une lenteur inimaginable par rapport à la réalité des réseaux informatiques.

La confidentialité, l'intégrité et la disponibilité, peuvent, comme nous venons de le voir, être compromis par une attaque délibérée d'une personne quelle qu'elle soit. Mais il existe un autre type de risque, autrement plus discret et perfide. Une attaque peut provenir d'une source non humaine, ou autrement dit d'un programme informatique. Nous arrivons sur le terrain surmédiatisé des virus informatiques.

La plupart d'entre nous sont familiers avec le terme virus informatique. Même ceux qui ne savent pas utiliser un ordinateur ont entendu parler de virus à travers les films hollywoodiens tels que Independence Day ou Hackers (bien que la description d'Hollywood soit généralement très inexacte). Des magazines et des journaux internationaux ont régulièrement parlé des menaces de virus à la Une. Il n'y a aucun doute que notre culture est fascinée par le danger potentiel de ces virus.

Malgré notre conscience des virus informatiques, combien d'entre nous peuvent définir ce qu'est un virus informatique ou comment il infecte les ordinateurs ? Commencons donc par quelques explications pour démystifier toute la démagogie qui a été faite sur le sujet.

Un virus est un petit programme situé dans le corps d'un autre, qui, lorsqu'on l'exécute, se charge en mémoire et exécute les instructions que son auteur a programmé. La définition d'un virus pourrait être la suivante: "tout programme d'ordinateur capable d'infecter un autre programme d'ordinateur en le modifiant de façon à ce qu'il puisse à son tour se reproduire".

Les virus vont de la simple balle de ping-pong qui traverse l'écran, au virus destructeur de données. Ce dernier étant la forme de virus la plus virulente. Ainsi, étant donné qu'il existe une vaste gamme de virus ayant des actions aussi diverses que variées, les virus ne sont pas classés selon leurs dégâts mais selon leur mode de propagation et d'infection (et certains virus appartiennent donc à plusieurs catégories).

Ils s'attachent à des programmes. Lorsqu'un utilisateur lance un programme qui a un virus parasite, le virus est discrètement exécuté en premier. Pour masquer sa présence à l'utilisateur, le virus déclenche alors l'ouverture du programme original (ex: CIH, Anthrax).

Ce sont des macros qui se répliquent toutes seules. Si l'utilisateur accède à un document contenant une macro virale et qu'il l'exécute inconsciemment, le virus peut alors se copier tout seul dans les fichiers de démarrage de l'application. N'importe quel document sur cette machine utilisant la même application pourra alors devenir infecté. Si l'ordinateur infecté est sur un réseau, l'infection est susceptible de se propager rapidement sur les autres machines du réseau.

Le virus macro est le type le plus courant de virus. La plupart des applications modernes permettent d'écrire des macros donc des virus, même avec peu de connaissances spécialisées. La raison principale de leur 'succès' est l'échange beaucoup plus fréquent des documents que celui des exécutables, un résultat direct de la popularité du courrier électronique et de l'utilisation du Web. Notons que les fameux virus « I Love You » et « Melissa » sont des macro virus utilisant les applications de Microsoft (Outlook particulièrement), et que malgré la publicité qui en a été faite ils étaient assez innofensifs (du moins les premières versions).

Un virus de secteur de démarrage infecte les ordinateurs en modifiant le contenu du programme du secteur de démarrage. Il remplace le contenu légitime par sa propre version infectée. Un virus de secteur de démarrage peut uniquement infecter une machine s'il est utilisé pour démarrer la machine, exemple : si vous démarrez votre ordinateur en utilisant une disquette avec un secteur de démarrage infecté, votre ordinateur est susceptible d'être infecté.

D'après les éditeurs d'antivirus il existerait environ 15000 à 20000 virus, dont à peine une centaine seraient réellement actifs

Depuis quelques années un autre phénomène est apparu, il s'agit des canulars (en anglais hoax), c'est-à-dire des annonces reçues par mail (par exemple l'annonce de l'apparition d'un nouveau virus destructeur) accompagnées d'une note précisant de faire suivre la nouvelle à tous ses proches. Ce procédé a pour but l'engorgement des réseaux ainsi que la dèsinformation (probablement orchestrée par les entreprises d'anti-virus qui tirent un grand profit de la panique que créent les virus).

Comme nous le voyons, il existe toute une panoplie de virus, mais ils sont loin de créer beaucoup de dégâts. Le risque principal des virus vient de l'utilisation massive par les entreprises et les particuliers d'outils bien connus et mal sécurisés (et nous ne citerons pas de nom).

Après avoir parlé de ce qui pouvait potentiellement mettre en danger un réseau, nous allons maintenant nous attacher à définir des procédures qui pourront garantir la sécurité d'un réseau.

Lorsque la question de sécuriser un réseau se pose, la meilleure façon de recourir est encore de prendre une feuille de papier et, avec les utilisateurs le réseau, définir ensemble une politique de sécurité. Cette politique est un ensemble de règles qui définissent ce qui est autorisé, selon les besoins, et ce qui est interdit (en principe tout le reste). Elle doit également définir qui est responsable de quoi et qui doit agir en cas de problèmes (technique ou administratif). Les outils mis en place par la suite respecteront cette politique de sécurité, et devront même la refléter.

Une politique de sécurité doit se faire avec les utilisateurs, ils doivent comprendre cette politique et respecter un certain nombre de règles en relation avec celle-ci. Par exemple, il paraît évident qu'ils ne doivent communiquer leur login et mot de passe à personne, pas même à leurs collègues. De même, il est bien connu qu'il ne faut pas ouvrir les fichiers attachés au email venant de personnes inconnues où dont le contenu est suspect. Des notes d'informations devront sensibiliser les utilisateurs. Ces règles doivent s'appliquer à tous, y compris à l'administrateur du réseau...

Par la sensibilisation et le respect des règles par tous, la majorité des problèmes seront évités et toutes les attaques de type Social Engeenering échoueront. C'est donc un point à ne jamais négliger.

Une autre donnée à garder en mémoire lors de la définition de la politique de sécurité, est que plus la politique sera restrictive et plus il sera difficile d'utiliser le réseau et les systèmes informatiques associés. Une bonne politique doit donc toujours être un compromis entre sûreté et facilité d'utilisation du réseau.

L'implentation des systèmes, la typologie du réseau et les connections vont fortement dépendre de la politique que nous aurons définie. Pour implémenter pratiquement cette politique, la meilleure solution consiste à adopter une architecture basée autour d'une zone tampon nommée Zone Démilitarisée ou DMZ.

Cette zone servira de tampon entre le réseau local et les réseaux externes (Extranet ou Internet). Elle contiendra également les serveurs (comme les serveurs web, de messagerie, etc.). Tous ce qui transitera comme information dans cette zone devra être considéré comme non sûr, ce qui explique comme vous pouvez le voir sur l'illustration, que l'entrée et la sortie sont bloquées par un firewall qui va filtrer les requêtes en accord avec la politique définie pour le réseau.

Imaginons que ce schéma représente l'architecture réseau d'une entreprise moyenne, une politique de sécurité acceptable pourrait être:

Avec une telle politique, Internet et l'Intranet sont complèteement isolés l'un de l'autre, aussi bien dans un sens que dans l'autre, gage d'une sécurité accrue. Tous les services passent par la DMZ, qui est filtrée et auditée en permanence. Avec une telle stratégie on peut éviter 95% des piratages. En effet, même si un hypothétique pirate parvenait à accéder à une machine de la DMZ, il ne pourrait accéder au réseau interne puisqu'il serait bloqué par le deuxiéme firewall. De plus son activité serait rapidement remarquée et identifiée par l'IDS ce qui permettrait de prendre les mesures adéquates.

On remarque tout de suite que la sécurisation du réseau va principalement dépendre de la configuration des firewalls. D'ou l'importance que l'administrateur doit accorder à cette tâche. Un firewall correctement configuré empêchera la majorité des attaques de type DoS, ainsi que les attaques directes contre vos serveurs.

Malgré une architecture très poussée, et une politique de sécurité sévère, le risque zéro n'existe pas. En effet l'utilisation même d'un service induit toujours un risque quant à son détournement.

Ce qui authentifie un utilisateur auprès d'un système informatique c'est la combinaison de son login (nom d'utilisateur) et de son password. Ces données sont des plus confidentielles, car si quelqu'un s'approprie le password d'un autre utilisateur, il devient cet utilisateur, il jouit des mêmes droits et accéde aux mêmes ressources.

C'est pour cela qu'il faut toujours sensibiliser les utilisateurs sur le choix d'un mot de passe. En fait, un bon mot de passe a deux caractéristiques contradictoires :

Un utilisateur ne peut se créer que deux ou trois mots de passe qui conjuguent ces deux qualités. Au delà du troisième, ses mots de passe sont soit pas assez mnémoniques (la condition 1 n'est pas remplie), soit trop évidents (la condition 2 n'est pas remplie). Il vaut donc mieux ne pas imposer un changement de password trop régulier.

Ne pas imposer un changement de password impose que celui-ci soit particulièrementt bien choisi et difficile à trouver. Pour le vérifier, la meilleure méthode est encore d'utiliser John The Ripper²⁰, un excellent programme qui va tenter de deviner les mots de passe. Si le programme découvre un de vos mots de passe, vous savez qu'il est grand temps d'en changer.

Pratiquement, un bon mot de passe ne fera jamais moins de 6 caractères (8 si possible) et comprendra des lettres en majuscules ET minuscules avec des caractères alphanumériques (des chiffres ou des symboles), ce qui le rendra pratiquement impossible à deviner.

Dans notre exemple précédent, un risque potentiel reste par exemple le serveur de mail. Comme nous l'avons déjà dit, les données transitant par la DMZ doivent être considérées comme non sûres, imaginons le cas où un pirate prendrait le contrôle d'une machine de la DMZ (par exemple le serveur web via une faille CGI), il pourra installer un sniffer sur cette machine et intercepter l'ensemble des données transitant sur celle-ci, et donc par exemple le contenu des emails (puisqu'il s'agit dans notre exemple du seul service que nous avons autorisé avec le proxy).

Il existe une méthode infaillible qui peut protéger vos données en général et vos email en particulier, la cryptographie. Aujourd'hui de nombreux logiciels intégrent des solutions pour faciliter l'envoi et la réception de messages chiffrés, il est donc tout à l'avantage de chacun de les utiliser. En effet un message crypté garanti que les informations ne peuvent ni être interceptées ni modifiées.

Le crypatge peut être appliqué a énormément de choses, par exemple pour l'administration distante d'un système, l'administrateur veillera à toujours utiliser un protocole tel que SSH, qui crypte les communications plutôt qu'un protocole tel que Telnet où les données (et particulièrement les passwords) passent en clair sur le réseau.

En utilisant de tels outils on empéche un pirate d'utiliser chacune des techniques que nous avons passé en revue, en effet il lui est impossible d'intercepter les données (ou du moins de les comprendre) ni de tenter une attaque Man in the Middle car il ne pourra répéter la signature cryptée unique du serveur qui permet de l'authentifier.

Une autre mesure de sécurité de base qui s'impose quels que soient vos choix en matière d'architecture pour votre réseau est de faire des sauvegardes ponctuelles et régulières de vos données. Cela peut sembler idiot de rappeler un principe aussi primaire, mais nombre d'administrateur réseau ne le font tout simplement pas (ou pas assez souvent) jusqu'au jour de la catastrophe...

Une sauvegarde régulière sur un support non volatil et réputé sûr (disque CD-Rom, archive ZIP, etc.) permettra sûrement de restaurer facilement les précieuses données en cas de sinistre (piratage, inondation, feu...). Elle s'avére INDISPENSABLE (et j'insiste) pour préserver un bien aussi précieux et volatil que des données informatiques.

L'administrateur d'un réseau est une personne avec beaucoup de responsabilité. Il est chargé d'assurer la fiabilité technique du réseau et de l'infrastructure qui tourne autour. En plus de cela, il est dans la très grande majorité des cas responsable de la sécurité du réseau, tâche qui pourtant (sur un réseau d'entreprise de taille moyenne) nécessite qu'une personne y soit entiérement dévouée.

L'administrateur va donc devoir, et ce quotidiennement, s'astreindre à certaines tâches ingrates mais qui garantiront la sécurité et la pérénité du réseau. Parmi ces tâches, on compte l'analyse régulière des logs (fichier ou un programme enregistre les évenements qui le concerne, dans ce cas-ci les connections, etc.) des serveurs, la mise à jour des anti-virus, etc...

Heureusement il existe des programmes qui se chargeront de ces tâches automatiquement, et qui fourniront un résumé journalier de leurs activités qu'il suffira de parcourir. Mais il existe encore d'autres tâches ou l'administrateurs devra toujours s'investir personellement, comme par exemple rester informé des dernières évolutions en matière de sécurité informatique (via des sites spécialisés comme le CERT²¹ et BugTraq²² ou par des newsgroups). Il devra également s'assurer que les logiciels utilisés par les systèmes qu'il administre sont à jour et ne possèdent pas de failles connues.

Un administrateur aura toujours besoin d'outils perfectionnés et puissants pour pouvoir surveiller son réseau. Un gros avantage est qu'il pourra toujours utiliser les même outils que les pirates pour vérifier sa propre sécurité (et donc ceux dont nous avons déjà parlé précédemment dans ce document). Voici ici une liste détaillée et non exhaustive d'outils qu'un administrateur réseau devrait souvent (voire toujours) utiliser:

Nmap comme nous l'avons déjà vu est un outil permettant de scanner un réseau et d'afficher les services ouverts et les OS utilisés par les machines qui le composent. Il sera d'une grande utilité pour contrôler les système à administrer

Tcpdump est assez unanimement considéré comme un des meilleurs programmes de sniff. Extrêmement configurable il sera utile non seulement pour réaliser un audit interne de sécurité mais aussi pour régler des problêmes techniques rencontrés lors de la maintenance du réseau.

Snort est un IDS, un programme qui va analyser le trafic réseau et les statistiques du système sur lequel il est installé pour tenter de déceler une utilisation abusive et anormales. Un IDS est une pièce majeure dans la politique de sécurité, mais sa configuration reste toujours une phase compliquée.

Il existe plusieurs outils permettant de détecter si une machine de votre réseau intercepte les paquets illégitimement (malgré le fait que cette technique soit entiérement passive). L'outil proposé ici, dont je suis l'auteur, permet de tester tout un réseau ou une machine particulière. Voici un exemple d'utilisation (le mode promiscuous signfie qu'une interface est en train d'intercepter les paquets), et comme nous pouvons le voir, le programme permet de scanner un réseau entier et affiche les adresses IP et MAC des machines qu'il soupçonne d'intercepter les paquets (ici une machine de mon réseau délibérément placée dans cet état):

Un tel programme arrive à remplir sa tâche en envoyant des requêtes ARP incorrectes auxquelles seule une machine en train de sniffer répondra (il s'agit d'un bug dans l'implémentation d'ARP prèsent aussi bien sur des OS Microsoft Windows toutes versions que GNU/Linux et BSD).

Un outil tel que celui-ci permettra non seulement de voir si personne à l'intérieur du réseau ne tente de détourner un système de son utilisation, qu'il soit interne ou externe (un pirate qui se serait infiltré). Son exécution depuis une machine sûre permet de vérifier facilement si votre réseau n'a pas été infiltré.

Tous ces outils et leurs utilisations régulières, une configuration bien pensée et un suivi journalier permettront ainsi à un administrateur réseau (même s'il n'est pas expert en matière de sécurité) de garantir à 99% (le risque zéro n'existe jamais) l'intégrité et la sécurité de son architecture informatique.

Pourtant, dans les cas d'un service informatique vital (qu'il soit privé ou de service public), tel qu'un service bancaire, hospitalier, de gestion aérienne, etc. il est indispensable que des personnes correctement formées soient chargées à plein temps de la sécurité. Et même lorsque cela s'avise nécessaire et possible il est souvent utile de faire appel à une société externe, ce dont nous parlerons dans le point suivant.

L'intervention d'une entreprise externe (marché qui est d'ailleurs en pleine expansion) est souvent utilisée par des grosses et moyennes entreprises qui n'ont pas les moyens de former et entretenir une équipe complète d'experts en sécurité. L'appel à une telle société spécialisée permet de mettre en place ou de vérifier la fiabilité d'une politique de sécurité et du choix d'une architecture réseau. Pour cela, une telle entreprise va généralement procéder en trois étapes.

L'entreprise externe va procéder à une analyse technique (les points d'entrée sur le réseau, les équipements de sécurité, les protocoles mis en oeuvre, etc.) et organisationnelle (étude de la politique de sécurité, des procédures de définition, de mise en place et de suivi de la politique de sécurité), complèter des solutions que vous avez mises en places, et le cas échéant corriger des erreurs d'implémentation.

En réalisant des tests d'intrusion, une entreprise externe va mettre à l'épreuve l'infrastructure de sécurité en reproduisant tous les comportements malicieux employés par les pirates. Une liste de failles sera ainsi généralement dressée à partir d'une base de données de vulnérabilités. A l'issue de cette prestation, l'entreprise spécialisée pourra mettre en évidence les vulnérabilités spécifiques qui vont compromettre votre infrastructure réseau. Ainsi après un tel test vous pourrez apprendre des informations importantes pour la gestion futures de votre réseau tel que:

La réalisation d'un audit par une entreprise externe peut rendre bien des services

Si vous constatez une intrusion sur votre réseau, en plus d'entamer d'éventuelles poursuites judiciaires, l'appel à une société spécialisée permettra une analyse correcte de ce qui a été compromis et de ce qui a permis aux pirates de pénétrer votre système. Une telle analyse complémentaire, externe et objective est souvent nécessaire pour non seulement remettre en question la politique de sécurité actuelle qui n'a pas rempli son rôle mais aussi pour garantir la sécurité future de l'infrastructure informatique.

Dans la jungle d'informations (et de désinformations) qui circulent sur le sujet, ce document a pu (j'ose l'espérer) apporter un brin de dédramatisation à la quasi hystérie qui régne dès qu'on aborde des thêmes aussi sensibles que le piratage et la sécurité informatique en général.

Comme nous venons de le voir, la sécurité en matière de réseau informatique n'est pas seulement une affaire de spécialiste, elle nécesite la sensibilisation et la participation active aux politiques de sécurités de l'ensemble des utilisateurs. Leur faire comprendre que si la sécurité est parfois un obstacle (parce qu'elle impose des contraintes à leur utilisation), elle est là pour eux, pour les protéger et assurer la pérénité de l'utilisation. Un réseau sécurisé est donc avant tout un réseau où l'utilisateur est remis au centre des préocupations.

Mais si la sécurité est l'affaire de tous, elle est aussi, on ne peut le nier, affaire de spécialiste. C'est pour cela qu'un tel document, ou une des nombreuses autres documentations sérieuses circulant sur Internet, devrait toujours être consulté par un "apprenti" administrateur réseau, personne qui devrait (même s'il n'en est pas responsable) être au fait d'une base en matière de sécurisation d'un réseau. Si une spécialisation est bien nécessaire, il faut aussi savoir se méfier des personnes et entreprises qui s'érigent à grand renfort de publicité en spécialistes, qui la plupart du temps ne sont pas plus au fait de ces techniques que vous et moi (après lecture de ce document). Pourtant, l'avis d'un expert reconnu sera en général plus que bénéfique.

Malheureusement, beaucoup d'entreprises négligent, par manque de moyen, ou par simple inconscience, de penser à une sécurisation de leurs systèmes informatiques. D'autres encore préfèrent ne pas en parler et confier la tâche à des personnes internes trop souvent sous-qualifiées. La puissance d'outils comme Nmap, gratuit, libre et facilement accessible montre immédiatement la futilité de vouloir cacher sa politique de sécurité dans le cadre d'un réseau informatique. Au contraire, une politique claire et explicite permet de renforcer la sécurité au profit de tous.

Oui la menace existe et est constante sur un réseau informatique, et non, être paranoïaque n'implique pas que l'ennemi soit imaginaire. Mais loin des grandes annonces bien souvent trop émotionnelles, la sécurité informatique doit s'envisager sous un angle technique et au regard de ces quatre points : ouverture, spécialisation, sensibilisation et participation.

Je tiens particulièrementt à remercier les personnes suivantes qui m'ont aidé et supporté lors de la réalisation de ce travail:

Les annexes sont organisées comme suit: sur cette page vous trouverez un index, puis sur chaque page suivante (ou le nombre de pages associées à chaque annexe) se trouveront les différentes annexes. Pour un index par page, reportez-vous à la table des matièrees.

Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PREAMBULE

The purpose of this License is to make a manual, textbook, or other written document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this licence principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you".

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five).

C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.
H. Include an unaltered copy of this License.
I. Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
K. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.
M. Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version.
N. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this licence give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections entitled "History" in the various original documents, forming one section entitled "History"; likewise combine any sections entitled "Acknowledgements", and any sections entitled "Dedications". You must delete all sections entitled "Endorsements."

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an "aggregate", and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

Détail des différentes catégories de messages ICMP donnés dans la liste ci-dessous où chaque alinéa commence par le couple (type,code) de la catégorie décrite.

(0,0) ou (8,0) Demande (type 8) ou réponse (type 0) d'écho dans le cadre de la commande ping.

(3,0-13) Compte-rendu de destination inaccessible délivré quand un routeur ne peut délivrer un datagramme. Le routeur génère et envoie ce message ICMP à l'expéditeur de ce datagramme. Il obtient l'adresse de cet expéditeur en l'extrayant de l'en-tête du datagramme, il insère dans les données du message ICMP toute l'en-tête ainsi que les 8 premiers octets du datagramme en cause. Une liste non exhaustive des différents codes d'erreurs possibles est :

(4,0) Demande de limitation de production pour éviter la congestion du routeur qui envoie ce message.

(5,0-3) Demande de modification de route expédiée lorsqu'un routeur détecte qu'un ordinateur utilise une route non optimale, ce qui peut arriver lorsqu'un ordinateur est ajouté au réseau avec une table de routage minimale. Le message ICMP généré contient l'adresse IP du routeur à rajouter dans la table de routage de l'ordinateur. Les différents codes possibles ci-après expliquent le type de redirection à opérer par l'ordinateur.

(10,0) Sollicitation de routeur diffusé par une machine pour initialiser sa table de routage.

(11,0) TTL détecté à 0 pendant le transit du datagramme IP, lorsqu'il y a une route circulaire ou lors de l'utilisation de la commande traceroute.

Cette annexe présente le début (jusque 80) de la liste des ports TCP tel qu'assignés par l'IANA. La liste complète officielle et mise à jour peut être trouvée sur: http://www.iana.org/assignments/port-numbers

Cet article a été traduit de l'anglais par OUAH, http://www.ouah.org. La version originale est de Fyodor (fyodor@dhp.com) et peut être obtenue à http://www.insecure.org/. La publication initiale a été faite dans Phrack 51, article 11 (http://www.phrack.org)

Cet article énumère plusieurs des techniques employées pour déterminer quels ports (ou toute similaire abstraction de protocole) d'un hôte sont en attente de connexion. Ces ports représentent des voies de transmissions potentielles.Tracer leur existence facilite l'échange d'information avec l'hôte et c'est ainsi assez utile pour n'importe qui, dont les hackers, souhaitant explorer l'environnement du réseau. En dépit de ce que vous avez entendu des médias, Internet ce n'est PAS tout ce qui a trait au port TCP 80. N'importe qui comptant uniquement sur le WWW pour rassembler des informations obtiendra les mêmes résultats que les mêmes moyens d'AOL qui font la même chose. Ce article est également sensé servir d'introduction à une documentation auxiliaire d'un projet de code sur lequel j'ai travaillé. C'est un portscanner robuste et complet qui (je l'espère) devrait résoudre certains des problèmes que j'ai rencontré en utilisant d'autres scanners et en faisant des scans sur d'énormes réseaux. Le programme, nmap, peut faire les choses suivantes:

- Vanilla TCP connect() scanning,
- TCP SYN (half open) scanning,
- TCP FIN (stealth) scanning,
- TCP ftp proxy (bounce attack) scanning,
- SYN/FIN scanning using IP fragments (bypasses packet filters),
- UDP recvfrom() scanning,
- UDP raw ICMP port unreachable scanning,
- ICMP scanning (ping-sweep), et
- Reverse-ident scanning.

les sources librement distribuables du code sont disponibles à http://www.insecure.org/nmap/

Le scanning en tant que méthode pour découvrir des voies de communications exploitables date de longtemps. L'idée est de sonder autant de voies que possible et de garder celles qui sont récéptives ou particulièrement utiles. Plusieurs champs de la publicité sont basés sur ce concept et forcer les gens à la voir en distribuant en bloc des mails est un parallèle presque parfait à ce dont nous discuterons. Envoyez un message seulement dans chaque mailbox et attendez les réponses pour tendre vos filets.

Le scanning est entré dans l'histoire déjà avec les systèmes téléphoniques. Nous avons là ce réseau global énorme de télécommunication, dont tous les hôtes sont accessibles avec des codes sur notre téléphone. Des millions de numéros sont accessibles localement, pourtant nous allons seulement nous intéresser à 0.5% de ceux-ci, peut-être ceux avec un répondeur au bout du fil.

La solution logique pour trouver ces numéros qui nous intéressent est de tous les essayer. C'est comme ça que le "wardialing" a surgi. D'excellents programmes comme Toneloc ont été développés pour faciliter le test d'échanges complets et plus encore. L'idée de base est simple. Si vous composez un numéro et que votre modem vous sort un CONNECT, vous le gardez. Sinon l'ordinateur raccroche et compose inlassablement les prochains.

Bien que le wardialing soit encore utile, nous constatons maintenant que plusieurs ordinateurs avec lesquels nous voulons communiquer sont reliés par des réseaux plutôt comme Internet que comme les téléphones analogiques. Scanner ces machines implique la même technique de brute forcing. Nous envoyons une rafale de paquets pour différents protocoles et nous déduisons des réponses reçues (ou pas reçues) quels services sont en train d'écouter.

Avec le temps, un certain nombre de techniques ont été développées pour examiner les protocoles et les ports sur lesquels une machine cible écoute. Elles offrent toutes différents avantages et problèmes. Voici une énumération des plus connues:

- TCP connect() scanning: c'est le scanning TCP le plus courant. L'appel système connect() fourni par votre os est utilisé pour ouvrir une connexion sur tous les ports intéressants de la machine. Si le port est en train d'écouter, connect() sera réussi, autrement le port n'est pas accessible. Un grand avantage de cette technique c'est que vous n'avez besoin d'auncun privilège spécial. N'importe quel utilisateur d'un ordinateur UNIX est libre d'utiliser cet appel. Un autre avantage est sa vitesse. Tandis que faire en série un appel connect() séparé pour chaque port cible prendrait beaucoup de temps avec une connexion lente, vous pouvez accélérer le scan en utilisant plusieurs sockets en parallèle. Utiliser un système I/O non-blocking vous permet de définir un bas time-out et d'observer toutes les sockets immédiatement. Le grand désavantage est que ce genre de scan est facilement détectable et filtrable. Les logs de l'hôte cible montreront une masse de connexions et de messages d'erreur pour les services qui ont capturé les connexions et les ont ensuite immédiatement fermées.

- TCP SYN scanning: Cette technique est souvent mentionnée comme scanning "demi-ouvert" parce que vous n'ouvrez pas une connexion TCP complète. Vous envoyez un paquet SYN comme si vous alliez ouvrir une vraie connexion et attendre une réponse. Un SYN|ACK indique que le port écoute. Un RST indique que le port n'écoute pas. Si vous recevez SYN|ACK, vous lui enverrez immédiatement un RST pour interrompre la connexion (en fait le kernel le fait pour nous). Le grand avantage de cette technique de scan est que moins de cibles la loggeront. Malheureusement il vous faut avoir les privilèges root pour construire ces paquets standarts SYN. Le scanning SYN se fait avec l'option -s de nmap.

- TCP FIN scanning: il arrive des fois que même le scanning SYN n'est pas assez clandestin. Certains firewall et filteur de paquets écoutent les SYNs sur des ports critiques et des programmes comme synlogger et Courtney sont disponibles pour détecter ces scans. Les paquets FIN d'autre part peuvent être capables de passer tranquillement. Cette technique de scan a été décrite en détail par Ureil Maimon dans le Phrack 49, article 15. L'idée est que les ports fermés tentent de répondre à votre paquet FIN avec un RST propre. Les ports ouverts d'autre part tentent d'ignorer le paquet en question. Comme Alan Cox l'avait précisé c'est un comportement exigé de TCP/IP. Toutefois quelques systèmes (notamment les systèmes Mirco$oft) sont intouchables dans ce sens. Ils envoyent des RST indépendamment de l'état du port et ils ne sont ainsi pas vulnérables à ce type de scan. Cela marche bien sur la plupart des autres systèmes que j'ai essayés. En fait, cela est souvent utile afin de distinguer un système *NIX d'un NT, et on peut l'utiliser pour ça. Le scannning FIN se fait avec l'option -U (Uriel) de nmap.

- Fragmentation scanning: Ce n'est pas une méthode nouvelle et indépendante de scanning mais une variation d'autres techniques. Au lien de seulement envoyer le paquet espion, vous le diviser en plusieurs petits fragments IP. Vous fractionnez l'en-tête TCP sur plusieurs paquets pour rendre la chose plus difficile aux filtreurs de paquets et ainsi détecter ce que vous en êtes en train de faire. Fais attention avec cela! Certains programmes ont de la peine à manipuler d'aussi petits paquets. Mon sniffer préféré me fait un segmentation fault directement après la réception du premier fragment de 36-bytes. Ensuite un de 24 bytes arrive! Alors que cette méthode ne marche pas avec les filtreurs de paquets et les firewalls qui mettent en file d'attente tous les fragments IP (comme l'option Linux CONFIG_IP_ALWAYS_DEFRAG), beaucoup de réseaux n'ont pas les capacités de résoudre ce problème. Cette possibilité est assez unique dans un scanner (en tout cas je n'en ai vu aucun le faire). Merci à daemon9 de m'en avoir donné l'idée. L'option -f dit au scan SYN ou FIN spécifié d'utiliser de petits paquets fragmentés.

- TCP reverse ident scanning: Comme l'a remarqué Dave Goldsmith dans un envoi de 1996 à Bugtraq, le protocole ident (rfc 1413) permet de révéler le nom de l'utilisateur propriétaire de n'importe quel processus relié par TCP, même si ce processus n'as pas initié de connexion. Ainsi vous pouvez par exemple vous connecter au port http et ensuite utiliser identd pour savoir si le serveur est exécuté par root. Cela peut seulement être fait par une connexion complète au port cible (càd l'option -t). L'option -i de nmap demande à identd le propriétaire de chaque port écouté par listen().

- FTP bounce attack: Une possibilité intéressante du protocole ftp (RFC 959) est qu'il supporte des connexions ftp par "proxy". En d'autres mots, je devrais pouvoir me connecter de evil.com au serveur PI (protocol interpreter) ftp de target.com pour établir une connexion. Ensuite je serais capable de demander que le serveur PI lance un serveur DTP (data transfer process) actif pour envoyer un fichier N'IMPORTE Où sur le net! Vraisemblablement à un User DTP, bien que la RFC dit spécifiquement que demander à un serveur d'envoyer un fichier à un autre est permis. Bon cela a pu bien marcher en 1985 quand la RFC venait d'être écrite. Mais de nos jours il ne peut y avoir des gens qui hijackent des serveurs ftp et demandent que les données soient renvoyeés vers n'importe quels points du net. Comme *Hobbit* l'avait écrit en 1995, ce défaut du protocole "peut être utilisé pour poster des mails et des news pratiquement non retraçables, attaquer des serveurs depuis différents endroits, remplir des diques durs, traverser des firewalls et généralement être ennuyant et difficile à retrouver en même temps". Ce que nous ferons pour cela (surprise surprise) c'est de scaner des ports TCP d'un serveur ftp "proxy". Ainsi vous pourriez vous connecter à un serveur ftp derrière un firewall et puis scanner ceux qui sont le plus probablement bloqués (le port 139 est un bon exemple). Si le serveur ftp permet de lire et d'écrire sur un répertoire (comme /incoming), vous pouvez envoyer n'importe quelles données sur les ports que vous trouvez ouverts.

Notre technique pour le scan de port est d'utiliser la commande PORT pour dire que notre "User-DTP" passif écoute le système cible sur un certain numéro de port. Ensuite nous allons essayer de LIST le répertoire actuel et le résultat est envoyé par le serveur DTP. Si notre hôte cible écoute sur le port spécifié, le transfert sera couronné de succès (en générant un réponse 150 ou 226). Autrement nous obtiendront "425 Can't build data connection: Connection refused." Ensuite nous envoyons une autre commande PORT pour essayer avec un prochain port de l'autre cible. Les avantages de cette méthode sont évidents (plus difficile à tracer, possibilité de contourner des firewalls). Les principaux désavantages sont la lenteur et le fait que certains serveurs FTP l'ont finalement remarquée et ont désactivé cette possibilité de "proxy". Pour montrer que cela en vaut la peine voici une liste de bannières d'endroits où cela a marché/pas marché:

220 xxxxxxx.com FTP server (Version wu-2.4(3) Wed Dec 14 ...) ready.
220 xxx.xxx.xxx.edu FTP server ready.
220 xx.Telcom.xxxx.EDU FTP server (Version wu-2.4(3) Tue Jun 11 ...) ready.
220 lem FTP server (SunOS 4.1) ready.
220 xxx.xxx.es FTP server (Version wu-2.4(11) Sat Apr 27 ...) ready.
220 elios FTP server (SunOS 4.1) ready

220 wcarchive.cdrom.com FTP server (Version DG-2.0.39 Sun May 4 ...) ready.
220 xxx.xx.xxxxx.EDU Version wu-2.4.2-academ[BETA-12](1) Fri Feb 7
220 ftp Microsoft FTP Service (Version 3.0).
220 xxx FTP server (Version wu-2.4.2-academ[BETA-11](1) Tue Sep 3 ...) ready.
220 xxx.unc.edu FTP server (Version wu-2.4.2-academ[BETA-13](6) ...) ready.

Les 'x' sont là d'une part pour protéger ceux responsables d'exécuter un serveur défectueux mais surtout pour adapter les lignes aux 80 colonnes. De même pour les points de suspension. L'attaque bounce se fait avec l'option -b de nmap. proxy_server peut-être donné dans le format URL standart, username:password@server:port avec tout mais le serveur qui est optionnel.

- UDP ICMP port unreachable scanning: Cette méthode de scan diffère de ce qu'il y a au-desssus parce qu'ici nous utilisons le protocole UDP au lieu de TCP. Alors que ce protocole est plus simple, le scanning est réellement sensiblement plus difficile. Ceci parce ce que les ports ouverts ne sont pas obligés d'envoyer un acknowlegment en réponse à une demande et les ports fermés ne doivent même pas renvoyer de paquet d'erreur. Heureusement, la plupart des hôtes renvoient une erreur ICMP_PORT_UNREACH quand vous envoyez un paquet à un port UDP fermé. Ainsi vous pouvez savoir si un port N'est PAS ouvert donc par exclusion déterminer quels ports sont ouverts. Comme il n'est garanti ni que les paquets UDP, ni que les erreurs ICMP arrivent, les scanners UDP de ce genre doivent aussi implémenter une retransmission des paquets qui pourraient être perdus (sinon vous obtiendrez un groupe faussement positif). En outre cette technique est lente en raison des machines qui appliquent la RFC 1812 section 4.3.2.8 pour découragez et limitez le taux d'erreurs ICMP. Par exemple, le kernel Linux (dans net/ipv4/icmp.h) limite la production de message de destination innaccessible à 80 chaque 4 secondes avec une pénalité de 1/4 de secondes en cas de dépassement. Dans quelque temps j'ajouterai un meilleur algorithme à nmap pour détecter cela. De plus vous devez être root pour accéder au raw ICMP socket nécessaire pour la lecture du port inaccessible. L'option -u (UDP) de nmap incorpore cette méthode de scannings pour les utilisateurs root.

Certaines personnes pensent que le scanning UPD est lent et inutile. Je leur rappelle généralement le récent bug rcpbind de Solaris. Rcpbind peut se cacher sur un port UDP non documenté quelque part au-dessus de 32770. Ainsi on s'en fout que le port 111 soit bloqué par un firewall. Mais pouvez-vous trouver sur lequel des 30'000 ports plus hauts il écoute? Avec un scanner UDP vous pouvez!

- UDP recvfrom() and write() scanning: Alors que les utilisateurs qui ne sont pas root ne peuvent pas lire les erreurs de ports innacessibles directement, Linux est assez sympa pour informer l'utilisateur indirectement quand elles ont été reçues. Par exemple un deuxième appel write() à un port fermé échouera normalement. Cela arrive à beaucoup de scanners comme netcat et pscan.c de Pluvius. J'ai aussi remarqué que recvfrom() sur des non-blocking sockets UDP retourne EAGAIN ("Try Again", errno 13) si l'erreur ICMP n'a pas été reçue et ECONNREFUSED ("Connection refused", errno 111) si elle a été reçue. C'est la technique utilisée pour déterminer les ports ouverts quand les utilisateurs qui ne sont pas root utilise l'option -u (UDP). Les utilisateurs root peuvent aussi utiliser l'option -l (lamer UDP scan) pour forcer que cela se passe mais c'est une idée vraiment bête.

- ICMP echo scanning: ce n'est pas vraiment du portscanning vu que ICMP n'a pas de port abstraction. Mais il est parfois utile de savoir quels hôtes dans un réseau sont up en les pingant tous. l'option -P le fait. Le scan ICMP se fait maintenant en parallèle il peut être ainsi assez rapide. Pour encore plus accélérer les choses vous pouvez augmenter le nombre de ping en parallèle avec l'option '-L'. Il peut être aussi utile de modifier la valeur du ping timeout avec l'option '-T'. nmap supporte une notation en hôte / masque de bits pour faciliter ce genre de chose. Par exemple 'nmap -P cert.org/24 152.148.0.0/16' scannera le réseau du CERT de classe C et toutes les entitée de class B rprèssentées par 152.148.* . Hôte/26 est intéressant pour les sous-réseaux de 6-bits dans une organisation. Nmap permet maintenant aussi une syntaxe plus puissante. Vous pouvez maintenant manipulez des addresses comme '150.12,17,71-79.7.*' et nmap en fera ce que vous voulez. Pour chacune des quatre valeurs vous pouvez soit mettre un simple nombre, soit un intervalle (avec '-'), une liste d'intervalles et de nombres séparés par des virgules, ou un '*' qui est synonyme de 0-255. Par défaut, les adresses de broadcast d'un réseau comme .0 et .255 ne sont pas scannées mais l'option '-A' vous permet d'y remédier si vous le souhaiter.

(...) La fin du document ne concernant que nmap et ne concernant plus la technique du port scan a été supprimée, vous pouvez la retrouver aux adresses données au début de ce document.

Je pense que l'utilité de déterminer l'OS qui tourne sur un système est assez évidente, c'est pourquoi je ne m'étendrai pas sur ce point. Un des exemples les plus forts de cette utilité, est que beaucoup de failles de sécurité sont dépendantes d'une version d'OS. Supposons que vous faites un test de pénétration et que vous trouvez le port 53 ouvert. Si c'est une version vulnérable de bind, vous avez une seule chance de l'exploiter car un essai infructueux crashera le démon. Avec un bon "identificateur TCP/IP", vous trouverez rapidement que cette machine fait tourner 'Solaris 2.51' ou 'Linux 2.0.35' et vous pourrez ajuster votre scriptshell en conséquence. (...)

Il y a de nombreuses techniques qui peuvent être utilisées pour prendre une empreinte des piles réseau. A la base, on cherche juste des choses qui diffèrent parmi les OS et on écrit un test pour déterminer la différence. Si vous combinez assez de ces techniques, vous pouvez déduire les OS d'une manière très fine. Par exemple nmap peut distinguer d'une manière fiable Solaris 2.4 par opposition a Solaris 2.5-2.51 ou Solaris 2.6. Il peut aussi dire Linux kernel 2.0.30 plutôt que 2.0.31-34 ou 2.0.35. Voici quelques techniques:

- Le test FIN -- La nous envoyons un paquet FIN (ou n'importe quel paquet sans flag ACK ou SYN) a un port ouvert et attendons la réponse. Le comportement conforme à la RFC793 est de ne PAS répondre, mais beaucoup d'implémentations incorrectes comme MS Windows, BSDI, CISCO, HP/UX, MVS et IRIX répondent par un RST. La plupart des outils courants utilisent cette technique.

- Le teste du flag BUG -- L'idée est de positionner un flag "TCP" indéfini (64 ou 128) dans l'en-tête TCP d'un paquet SYN. Les systèmes Linux antérieur au 2.0.35 conservent ce flag positionné dans leur réponse. Je n'ai trouve aucun autre OS ayant ce bug. Cependant, certains systèmes semblent reseter la connexion quand ils reçoivent un paquet SYN+BUG. Ce comportement pourrait être utile pour les identifier.

- Echantillonnage TCP ISN -- L'idée est ici de trouver les types de nombres de séquence initial (ISN) choisis par les implémentations TCP quand ils répondent à une demande de connexion. Ils peuvent être ranges dans plusieurs groupes comme le traditionnel 64K(beaucoup de vieux Unix), incréments aléatoires (dernier Solaris, IRIX, FreeBSD, Digital UNIX, Cray, et beaucoup d'autres), vraiment aléatoires (Linux 2.0.*, OpenVMS, derniers AIX, etc.). Les systèmes Windows (et quelques autres) utilisent un modèle "dépendant du temps" ou l'ISN est incrémenté d'un petit montant d'une manière périodique. (...)

- Bit "ne pas fragmenter" -- Beaucoup de systèmes d'exploitation commencent par positionner le flag IP "Ne pas fragmenter" sur certains des paquet qu'ils envoient. Cela permet des gains de performance. Tous les OS ne le font pas et certains le font dans d'autres situations, on peut donc en prêtant attention a ce bit glaner encore plus d'information sur l'OS cible.

- Fenêtre initiale TCP -- Il s'agit juste de vérifier la taille de la fenêtre sur les paquets retournes. Ce test donne actuellement beaucoup d'informations, car certains OS peuvent être identifies par cette fenêtre seulement (par exemple, AIX est le seul OS de ma connaissance utilisant 0x3F25). Dans leur pile TCP/IP "complètement réécrite" pour NT5, Microsoft utilise 0x402E. Il est intéressant de noter que c'est le même nombre que celui utilise par OpenBSD et FreeBSD.

- Valeur ACK -- Bien que vous puissiez penser que c'est complètement standard, les implémentations diffèrent par la valeur utilisée pour le champ ACK dans certains cas. Par exemple, supposons que vous envoyez un FIN|PSH|URG a un port TCP ferme. La plupart des implémentations affecteront au champ ACK la même valeur que votre ISN, cependant, Windows et quelques imprimantes stupides reverront seq+1. Si vous envoyez FIN|PSH|URG a un port ouvert, Windows est très inconstant. Il renvoi parfois seq d'autres fois il renvoi S++, et d'autres fois il renvoi une valeur visiblement aléatoire.

- Extinction des messages erreurs ICMP -- Certains OS (astucieux) suivent la suggestion de la RFC 1812 limitant la vitesse a laquelle divers messages erreurs sont envoyés. Par exemple, le noyau Linux (dans net/ipv4/icmp.h) limite la génération des messages destination inaccessible a 80 par 4 secondes, avec 1/4 de seconde de pénalité en cas de dépassement. Un moyen de tester ceci est envoyer un lot de paquet a un port haut UDP (choisi aléatoirement) et de compter le nombre de "destination inaccessible" reçus.

- Citation de message ICMP -- Les RFC spécifient qu'un message d'erreur ICMP cite une partie du message ayant cause les erreurs. Pour un message port inaccessible, presque toutes les implémentations renvoient seulement l'en-tête IP + 8 octets. Cependant, Solaris renvoi un peu plus et Linux encore un peu plus. La beauté de la chose est que ca autorise Nmap a reconnaître Linux et Solaris même s'ils n'ont pas de ports à l'écoute.

- Intégrité des messages d'erreur ICMP émis -- Comme il a été dit précédemment, les machines doivent renvoyer une partie du message original avec un message port inaccessible. Actuellement certaines machines utilisent les en-têtes comme espace de travail pendant le traitement initial, et ces en-têtes sont donc un peu altérés quand ils les renvoient.
Par exemple AIX et BSDI renvoient un champ IP 'taille totale' trop grand de 20 octets. Certains BSDI, FreeBSD, OpenBSD, ULTRIX et VAX bousillent l'ID IP qu'on leur envoie. Alors que la somme de contrôle va changer a cause de la modification du champ TTL (**NDT : Champ Time To Live), il y a certaines machines (AIX, FreeBSD, etc.) qui renvoient une somme de contrôle inconsistante ou nulle. On constate la même chose avec les sommes de contrôles UDP. L'un dans l'autre, Nmap fait 9 tests différents sur les erreurs ICMP pour détecter les subtiles différences de ce type.

- Type de service -- Pour les messages ICMP port inaccessible j'ai regarde la valeur du Type de service (TOS) du paquet retourne. Presque toutes les implémentations utilisent 0 pour les erreurs ICMP cependant Linux utilise 0xC0. Cela n'indique pas une des valeurs standards du TOS, mais est plutôt une partie du champ deprèsséance inutilisé (pour autant que je sache). Je ne sais pas pourquoi il est positionne, mais s'il change cette valeur en 0, nous serons capable d'identifier les vieilles versions ET nous serons capable de distinguer entre l'ancienne et la nouvelle.

- Gestion de la fragmentation -- Elle prend avantage du fait que différentes implémentations gèrent souvent différemment les fragments IP se recouvrant. Certains recouvrent la vieille partie avec la nouvelle dans d'autres cas c'est la vieille partie qui prédomine. Il y a beaucoup de tests différents qu'on peut utiliser pour déterminer comment le paquet a été réassemblé. Pour plus d'information sur les fragments se recouvrant, vous pouvez lire leur article (www.secnet.com).

- Options TCP -- Elles sont vraiment une mine d'or en terme de source d'information:
1) Elles sont en général optionnelles: ce qui fait que toutes les machines ne les implémentent pas.
2) On sait si une machine les implémente en envoyant une demande avec une option positionnée. La cible montre généralement qu'elle supporte l'option en la positionnant dans sa réponse.
3) On peut positionner tout un tas d'options dans un paquet pour tout tester en une seule fois.
Nmap envoi ces options avec quasiment tous les paquets de test: Window Scale=10; NOP; Max Segment Size = 265; Timestamp; End of Ops. Quand on obtient une réponse, on regarde quelles options sont retournées et donc supportées. Certains OS comme les machines BSD récentes supportent toutes celles positionnées plus haut, alors que d'autres comme Linux 2.0.x en supportent très peu. Les derniers noyaux Linux 2.1.x supportent tous ceux définis plus haut. Même si plusieurs OS supportent le même ensemble d'options, on peut parfois les distinguer par la VALEUR de ces options. Par exemple, si on envoi une petite valeur MSS a une machine Linux, elle répondra généralement par cette même valeur. d'autres machines retourneront des valeurs différentes. Et même si on obtient le même ensemble d'options supportées ET les mêmes valeurs, on peut encore faire une différence via l'ORDRE dans lequel les options sont données. Par exemple Solaris retourne 'NNTNWME', quand à Linux 2.1.122, il retourne 'MENNTNW'. Même options, même valeurs mais un ordre diffèrent !

- Chronologie des exploits -- Même avec tous les testsvus plus haut, nmap est incapable de distinguer les piles TCP de Win95, WinNT ou Win98. C'est plutôt surprenant, particulièrement quand on sait que Win98 est sorti 4 ans après Win95. On pourrait penser qu'il se serait soucie d'améliorer un peu leur pile (comme par exemple en supportant plus d'options TCP) et cela nous aurais permis de détecter les changements et donc distinguer les OS. Malheureusement ce n'est pas le cas. La pile NT est apparemment la vieille pile merdique qu'ils ont mis dans '95'. Et ils ne sont pas embeter a l'améliorer pour '98'.

(...) La fin de cet article ne concernant que l'utilisation de nmap a été coupée. Pour une versioncomplètee, dirigez vous sur le lien au début de cet article.

Voici quelques notes qui introduisent et essayent d'expliquer le problème des débordements de buffer (tampon en français). Pour comprendre les débordements de buffer il faut avoir quelques bases sur le fonctionnement d'un microprocesseur, de l'assembleur, des systèmes d'exploitations, des compilateurs et la programmation. Pour comprendre vraiment les débordements de buffer il faut en faire. Tout ce qui est écrit dans ce document est testé sur Linux (Slackware 7). Certaines choses sont testées sur *BSD, et j'essaierai autant que possible de faire un parallèle avec Solaris (euh Sparc) et même Windows NT (non non pas sur Sparc ;-)

Si pour vous une pile est le petit cylindre qui fait marcher plus longtemps les petits lapins roses, vous allez devoir vous accrocher ;-)

Sinon vous vous souvenez certainement qu'une pile est une structure mémoire (aisément modélisable en lamda-calcul) qui possède une base et un sommet. En assembleur le sommet est stocké dans un registre, ESP pour intel ou SP pour Sparc. On ne peut ajouter et supprimer des informations qu'au sommet d'une pile.

Sur Unix (sur pc), un programme est exécuté dans un certain environnement. La gestion paginée de la mémoire fait que le code à exécuter est chargé en mémoire à une adresse virtuelle qui est toujours la même (souvent) sur un même système.

Avant l'exécution du programme, pour que tout fonctionne, le système réserve de la mémoire. Ce programme a besoin de sa propre pile et d'espace pour allouer de la mémoire (avec par exemple la fonction malloc). Ainsi, on se retrouve systématiquement dans la configuration suivante :

IP (instruction pointer, eip chez Intel) contient l'adresse de la prochaine instruction à exécuter. SP contient l'adresse du prochain octet libre dans la pile.

La pile allouée à un programme permet principalement l'appel de fonctions en permettant de sauvegarder des variables (registres) qui pourront ainsi être modifiées dans la fonction et restaurées à la sortie de la fonction mais elle sert aussi à passer les paramètres aux fonctions et à allouer les variables locales. Ces variables locales sont ainsi "protégées" même lors de fonctions récursives.

Les principales fonctions assembleur pour utiliser la pile sont (chez Intel) push et pop (respectivement pushl et popl) pour empiler et dépiler un entier long dans la pile. Il faut aussi bien comprendre que le sommet de pile est stocké dans un registre (ex: %esp) et qu'en modifiant ce registre on modifie l'état de la pile.

Ainsi, l'instruction : "subl $1024, %esp" permet d'allouer 1024 octets dans la pile en augmentant la taille de la pile de 1024 octets. Pour augmenter la taille de la pile il faut bien diminuer la valeur du registre SP car la pile est tête-bêche (la tête en bas).

Si on regarde le code asm généré par GCC lors de l'appel de fonctions et l'allocation de variables locales avec "gcc simple.c -S" il est relativement simple de comprendre la gestion de la pile.

main : push %ebp permet de sauvegarder %ebp car la ligne suivante écrase %ebp (Base Pointer)

main+8 : call va dérouter le processeur à l'adresse de Func en ayant préalablement empiler l'adresse de la prochaine instruction à exécuter après la fonction, ici : 0x80483b1

Pour la suite il faudra connaître l'adresse du sommet de la pile même approximativement. Quand on exécute un programme localement il est simple même en C d'obtenir le Stack Pointer :

Remarque : tout le monde a bien compris comment fonctionne la fonction get_esp. Pas la peine de rappeler que la variable renvoyée par une fonction est stockée dans le registre AX (heuu %eax c'est plus du 8086 depuis longtemps ;-)). Donc il suffit de copier SP dans AX et de retourner au programme principal.

Si on exécute ce programme sur d'autre systèmes on obtient des valeurs différentes.

Il y a problème lorsqu'il y a débordement. Il y a débordement lorsque le code est mal écrit. Ce qui permet d'écrire : Il y a problème lorsque le code est mal écrit !

Le problème se situe plus précisément dans la pile lors, pour un exemple simple, de l'affectation d'une variable locale. Cette variable locale, comme nous l'avons vu, est allouée dans la pile.

Lors de l'exécution du programme la place de 16 caractères (consécutifs) sera réservée dans la pile pour la variable nommée tmp. Si dans cette même fonction une suite d'instructions vient remplir cette variable avec plus de 16 caractères (octets), l'emplacement réservé à la variable tmp va être écrasé mais aussi les octets suivants dans la pile.

Les octets tout de suite écrasés sont le base pointer puis l'adresse de retour qui sera dépilée lorsque la fonction se terminera. A cet instant, le programme va exécuter l'instruction qui se trouve à l'adresse de retour. Qui était je le rappelle l'adresse de l'instruction suivant l'appel de cette fonction (la prochaine instruction à exécuter).

Si l'adresse de retour est écrasée, par exemple, par des caractères 'A' l'adresse de la prochaine instruction à exécuter est 0x41414141 (non valide), on peut dire qu'aucune instruction n'estprèssente à cette adresse, donc le programme arrête de fonctionner et plante. Le résultat obtenu est alors nommé : déni de service.

Si l'adresse de retour (pour faire simple, c'est pas tout à fait comme ça mais bon ...) est l'adresse de tmp et qu'à cet endroit on trouve des instructions que le processeur est en mesure d'exécuter alors à la sortie de la fonction le programme exécute des instructions non prévues par les programmeurs mais fournies par un utilisateur.

Si cet utilisateur est à l'autre bout d'Internet, il peut alors faire exécuter du code à distance sur le serveur et c'est ce qui s'appelle exploiter un débordement de buffer à distance. Les octets qui sont utilisés pour écraser la pile (ceux qui contiennent des instructions) sont appelés le shellcode (car ces premiers shellcode permettaient de lancer /bin/sh et d'avoir un shell interactif à distance).

L'Ip spoofing est une attaque bien connue dans son principe de nos jours, c'est pourquoi je ne reviendrai pas sur une explication qui a déja été faite de nombreuses fois. Je m'attarderai ici dans une explication plus applicative en m'appuyant sur mes recherches personnelles dans ce domaine. La première partie de cette attaque consiste en une étude de la génération des ISN de différents systèmes d'exploitations. Dans un premier temps j'ai réalisé un utililitaire destiné à étudier la génération d'ISN par différents systèmes d'exploitation. A partir des résultats obtenus j'ai pu juger de la difficulté de l'attaque suivant les systèmes d'exploitation et ainsi pouvoir déterminer une méthode grossière de prédiction des ISNs qui m'a permis de réussir l'attaque sur des systèmes d'exploitation de type Win98. Enfin, j'ai amélioré ce code en utilisant une méthode mathématique beaucoups plus évoluée qui m'a permis d'attaquer d'autres systèmes d'exploitation.

A l'époque de la parution de l'article "IP Spoofing Demystified" [1] les générateurs d'ISN des systèmes d'exploitation étaient dépendants de seulement deux variables qui sont le temps et le nombre de connexion. Ceci permettait de prévoir trés facilement par un simple calcul mathématique la valeur d'un ISN à partir de celle d'un ISN précédemment acquis. L'ISN augmentait de 128000 chaque seconde et de 64000 à chaque nouvelle connexion. En réalisant l'attaque rapidement on pouvait considérer qu'aucune connexion ne serai établie et cela rendait donc la prédiction d'ISN assez triviale. Une première phase d'étude consistait donc a étudier la génération d'ISN de plusieurs systèmes d'exploitation de manière à établir des corrélation entre le temps et l'évolution des ISN. Pour cela j'ai dévellopé un utilitaire nommé Analysor [2] dont un des modes de fonctionnement permet de créer des listes de valeurs d'ISNs en fonction du temps. Dans l'état actuel Analysor possède 3 modes de fonctionnement symbolisés par les options -j, -k et -m. La première des options à avoir été implémentée est l'option -j qui permet d'obtenir 2 colonnes de nombres qui rprèssentent d'une part le temps écoulé depuis le début de l'expérience, et d'autre part la valeur de l'ISN de la cible. Ce formatage permet de tracer des graphiques a l'aide de l'utilitaire Gnuplot. Le schéma de fonctionnement de l'option -j est le suivant:

Le fonctionnement est donc assez simple: on envoie un Syn, le serveur nous Ack/Syn en nous donnant une valeur d'ISN puis notre Kernel émet tout seul un Rst car il n'a pas été averti de l'ouverture d'une connexion et il pense donc que ce Ack/Syn n'a pas à être recu. Le fait que le Kernel envoye tout seul ce Rst est assez pratique car il permet de fermer automatiquement la demande de connexion engendrée pas le Syn. Si ce Rst ne partait pas, la connexion se retrouverai dans un état 'semi-établi', ce qui entrainerai en cas de nombreuses réitération du schéma précedent une forte consommation des resources du côté de l'host B.

J'ai testé Analysor sur les différents systèmes d'exploitation que j'avais sous la main de manière à déterminer le plus vulnérable à l'Ip Spoofing. Le test consiste en l'envoie de 1000 paquets à intervalles réguliers de 20000 µs. A l'aide de ces 1000 ISNs récoltés pour chaque système d'exploitation il est possible de tracer des graphiques donnant une allure générale de l'évolution des ISNs en fonction de temps.

A l'aide de l'utilitaire Gnuplot il est possible de se donner une rprèssentation plus explicite des résultats obtenus à l'aide de Analysor. On trace tout d'abord des graphiques distincts pour chaque système d'exploitation de manière à se donner une idée générale de l'évolution des ISNs sur ces systèmes d'exploitation. Enfin, on représente toutes les courbes sur un même graphique ce qui nous permet de constater les lacunes et les aventages qu'ont chaque système d'exploitation par rapport aux autres. Les tests on été réalisés sur un réseau ethernet 100 Mb/s avec 2 machines reliées par cable RJ45 croisé.

Cette valeur de l'amplitude représente la moitié de la plage dans laquelle peut se situer un ISN. Le générateur aléatoire d'OpenBSD 2.9 utilise donc assez bien les 32 bits attribués à un ISN. Les ISNs sont stoqués sur 32 bits et sont des nombres non signés, un calcul rapide nous donne la valeur maximale que peut avoir un ISN: 2^32 = 42949667296. OpenBSD 2.9 génère donc des valeurs d'ISN qui atteignent le maximum. On vois que la valeur des ISNs passe d'une valeur minimale a une valeur maximale très rapidement. L'évolution générale n'étant pas monotone cette dernière remarque assure avec les deux précédentes une robustesse assez acrue pour le générateur aléatoire d'OpenBSD 2.9.

Commetaire: OpenBSD 2.9 démontre ici toutes sa puissance dans le domaine de la sécurité. Ce système puise sa robustesse à l'aide de l'audit du code source, mais aussi à l'aide d'une très bonne gestion de la cryptographie [4]. Les algorithmes cryptographiques nécessitent des nombres aléatoires, on ne s'étonne donc pas de voir que le générateur aléatoire d'OpenBSD 2.9 soit trés fiable. Ce dernier utilise plusieurs sources d'entropie :

Les ISNs évoluent rapidement sur une plage de 15 millions de valeurs ce qui reste tout à fait acceptable. De plus cette évolution pas à pas n'est pas monotone: la valeur augmente puis elle décroit. L'allure générale de l'évolution de la génération d'ISN est ici monotone croissante ce qui permet de renforcer (très légèrement) la robustesse du générateur aléatoire de Linux.

Commetaire: Linux possède un générateur de nombre pseudo aléatoires de bonne qualité. Bien qu'il n'atteigne pas le niveau de celui d'OpenBSD 2.9, il permet de rendre trés difficile, voir presque impraticable les attaques de type Blind Ip Spoofing.

Les ISNs évoluent linéairement (et lentement) avec le temps. De plus, les valeurs d'ISNs sont peu élevées

Commentaire: Le générateur n'est pas aléatoire, il dépend implicitement du temps et évolue lentement avec ce dernier. Ceci engendre la possibilité d'une attaque de Blind Spoofing. Comme chacun sait, les sources de Windows ne sont pas libres, mais à la vue de cette courbe on imagine facilement l'allure de la fonction et surtout l'incompétence des développeurs qui l'ont codé.

Ce dernier graphique permet de comparer les différents générateurs de nombres pseudo-aléatoire entre eux. On vois bien qu'OpenBSD possède le plus robuste. Linux bien que possédant un bon générateur aléatoire lui permettant de se mettre a l'abris de la plupart des attaques est quand même bien loin d'OpenBSD. Enfin, Windows 98 est ridicule avec un générateur qui ne décolle même pas et dont on a du mal à différencier la courbe avec l'axe des absices.

(..) Le reste de l'article n'étant que d'un application limitée a Windows 98 nous laissons au lecteur le soin (tout en l'encourageant vivement) d'aller consulter l'article en ligne à l'adresse http://www.projet7.org.

C'est l'unité binaire de quantité d'information qui peut représenter deux valeurs distinctes : 0 ou 1.

Une mémoire utilisée pour conserver temporairement les données pendant leur transmission.

Systéme d'exploitation OpenSource fortement apparenté aux systéme de type GNU/Linux.

(Anglais : Common Gateway Interface). Une interface d'exécution des programmes sur un serveur.

La science du code. Elle protége des regards indiscrets votre correspondance sur le réseau (messages, fichiers). Seul un mot de passe, une clé numérique, permet d'y accéder.

Le microprocesseur. Ses caractéristiques les plus importantes sont sa fréquence de fonctionnement et le nombre de bits qu'il adresse simultanément. Les PENTIUM sont des processeurs 32 bits à des fréquences entre 60 et 1,5 GHZ. Ces informations ne sont pas suffisantes pour comparer deux processeurs de famille différente. Leur rapidité dépend du nombre de cycles d'horloge que chaque instruction et de leur architecture CISC, RISC etc...

Principe consistant à enfermer les données et les algorithmes des objets en ne laissant visibles que les interfaces

Un type de réseau local rapide et très répandu conçu à l'origine par Xerox, Intel et Digital en 1976. La vitesse de transmission est de 10 Mbps et la limite de chaque section est de 2.5 km. Une nouvelle version d'ethernet appelée 100-Base-T offre une vitesse de transmission de 100 Mbps.

Réseau de télécommunication et de téléinformatique constitué d'un intranet étendu pour permettre la communication avec certains organismes extérieurs, par exemple des clients ou des fournisseurs.

Dispositif matériel ou plus souvent logiciel destiné à filtrer les informations transmisses sur un réseau.

(Anglais : Gnus Not Unix). Association de programmeurs pour l'écriture et la diffusion de logiciels libres (pour Linux par exemple). Ce sont eux qui distribuent l'éditeur de texte Emacs. Leur projet GUILE met en avant le langage Scheme comme langage embarqué universel pour les applications

Linux est une version d'UNIX gratuite et librement diffusable crée par Linus Torvalds. Linux prend de plus en plus d'importance. Le kernel (noyau) a pu se développer par l'intermédiaire d'Internet et des passionnés de programmation. L'avantage de Linux est qu'on peut trouver des mises à jour très rapidement. En réseau Linux prends une ampleur certaine et est vraiment incomparable à certains autres systèmes : passerelles, serveurs ftp, dns, Web etc... Une nouvelle étape a été franchie l'arrivée du noyeau 2.2.0 qui a en effet quelques merveilles le tout livré avec les sources et librement téléchargeables et diffusables. C'est-à-dire que si vous avez une distribution de Linux sur cd rom et que vous voulez en faire une copie la GPL (Gnu Public License) vous en donne le droit et tout ceci gratuitement.

Un système numérique de base (ou radical) 16. Les symboles utilisés dans ce système sont les chiffres de 0 à 9 et six chiffres supplémentaires généralement représentés par les lettres A, B, C, D, E et F.

Dispositif matériel ou plus souvent logiciel permettant de monitorer l'activité sur un réseau et d'y détecter des actions inhabituelles. Un IDS permet de détecter l'infiltration du réseau par un pirate grâce à l'activité qu'il y provoque.

Une voie d'échange d'informations qui permet à un ordinateur ou plusieurs ordinateurs ou des équipements extérieurs (imprimantes, moniteurs ou modems) ou deux ou plusieurs ordinateurs de communiquer.

Réseau local et privé (entreprise) qui utilise les technologies de l'Internet : Web, e-mail, etc., mais ne s'ouvre pas aux connexions publiques. Contrairement à Internet, nom propre, on écrira intranet, comme internaute.

Une série de commandes qui s'exécute automatiquement pour accomplir une tâche répétitive.

Programme assurant la gestion de l'ordinateur et de ses composants. Exemples : Linux, Windows, Unix, MacOS ou encore BeOS.

Ordinateur qui s'intercale entre un réseau privé et l'Internet. Pour faire office de firewall ou de cache. Dans ce dernier cas, il enregistre les pages Web transférées par les utilisateurs pour les délivrer sans qu'il soit nécessaire de se connecter sur le serveur initial.

Exploit ou technique décrits uniquement dans un but d'application d'une théorie pour prouver sa validité pratique.

Dans une typologie de réseau en étoile, chaque interface réseau est connectée via un câble à un répartiteur central. Ce répartiteur se décline généralement en deux types, soit un HUB, qui va répéter chaque paquet à toutes les machines connectées, ou soit un switch qui ne va renvoyer le paquet qu'à la machine concernée par un système de mémoire cache.

(Anglais : router). Outil logiciel ou matériel pour diriger les données à travers un réseau. Il s'agit souvent d'une passerelle entre plusieurs serveurs pour que les utilisateurs accédent facilement à toutes les ressources proposées sur le réseau. Le routeur désigne également une interface entre deux réseaux utilisant des protocoles différents.

(Anglais : synchronization) Technique qui permet d'établir et de maintenir des signaux en synchronisme dans un réseau.

Bits: 8		16	24		32
Version	Longueur	Type de Service (TOS)	Longueur totale
Identification			Flags	Offset
Time to Live (TTL)		Protocole	Checksum
Adresse IP Source
Adresse IP Destination
Options (éventuelles)					Remplissage
c-Données...

Bits: 8		16	24	32
Port Source			Port Destination
Numéro de séquence (SEQ)
Numéro d'acquittement (ACK)
Longueur	Reservé	Flags	Window
Checksum			Pointeur Urgent
Options				Remplissage
Données...

Bits: 8	16	24	32
Port Source		Port Destination
Taille		Checksum
Données...

Bits: 8	16	24	32
Type	Code	Checksum
Contenu variable en fonction du type