laisser un délai - considéré raisonnable - aux éditeurs pour corriger les vulnérabilités avant de les divulguer. Ainsi la société TippingPoint laisse un délai de 6 mois avant de divulguer les détails d'une vulnérabilité¹.

## Date et source de publication

La date de publication est la première date à laquelle une vulnérabilité est décrite sur un média. L'information révélée suit les conditions suivantes :

- l'information est disponible librement et publiquement ;

- l'information sur la vulnérabilité est publiée par une source indépendante et de confiance ;

- la vulnérabilité a fait l'objet d'analyse par des experts, notamment sur l'estimation du risque de la révélation.

D'un point de vue sécurité, seule une publication libre d'accès et complète peut assurer que toutes les parties intéressées obtiennent l'information appropriée. La sécurité par l'obscurité est un concept qui n'a jamais fonctionné.

La source de la publication doit être indépendante d'un éditeur, d'un vendeur, ou d'un gouvernement. Elle doit être impartiale pour permettre une diffusion de l'information juste et critique. Un média est considéré comme « de confiance » lorsqu'il est une source de la sécurité des systèmes d'information largement acceptée dans l'industrie (par exemple : CERT, CESTI, Securityfocus, Secunia).

L'analyse et l'estimation du risque assurent la qualité de l'information révélée. Une unique discussion sur une faille potentielle dans une liste de diffusion ou une vague information d'un vendeur ne permettent donc pas de qualifier une vulnérabilité. L'analyse doit inclure assez de détails pour permettre à un utilisateur concerné d'évaluer lui-même son risque individuel, ou de prendre une mesure immédiate pour se protéger.

## Référence

Lorsqu'une vulnérabilité a été publiée, le MITRE lui attribue un identifiant CVE. Cet identifiant permet de faire des recherches croisées entre plusieurs sources d'information.
## II.2.4 Identification et correction des vulnérabilités

Il existe de nombreux outils qui peuvent faciliter la découverte de vulnérabilités sur un système information, certains permettant leur suppression. Mais, bien que ces outils puissent fournir à un auditeur une bonne vision d'ensemble des vulnérabilités potentiellement présentes, ils ne peuvent pas remplacer le jugement humain. Se reposer uniquement sur des scanners automatiques de vulnérabilité rapportera de nombreux faux positifs et une vue limitée des problèmes présents dans le système.

Des vulnérabilités ont été trouvées dans tous les principaux systèmes d'exploitation, en premier lieu sur Windows, mais aussi sur Mac OS, différentes versions d'Unix et Linux, OpenVMS, et d'autres. La seule manière de réduire la probabilité qu'une vulnérabilité puisse être exploitée est de rester constamment vigilant, en développant la maintenance système (par exemple en appliquant les patchs de sécurité), de déployer une architecture sécurisée (par exemple en plaçant judicieusement des pare-feu), de contrôler les accès, et de mettre en place des audits de sécurité (à la fois pendant le développement et pendant le cycle de vie).

## II.2.5 Exploitation malveillante

Les failles de sécurité deviennent particulièrement intéressantes lorsqu'un programme contenant une de ces vulnérabilités est lancé avec des privilèges spéciaux, qu'il permet une authentification sur un système, ou bien encore lorsqu'il fournit un accès à des données sensibles.

Les Crackers et non « hackers », grâce à leur connaissance et à des outils appropriés, peuvent prendre le contrôle de machines vulnérables. Les failles de sécurité découvertes sont généralement colmatées au plus vite à l'aide d'un patch, afin d'empêcher des prises de contrôles intempestives ; cependant dans bien des cas, des machines restent vulnérables à des failles anciennes, les différents correctifs n'ayant pas été appliqués.

Certains logiciels malveillants utilisent des vulnérabilités pour infecter un système, se propager sur un réseau, etc.

L'exploitation d'une faille peut provoquer un déni de service du système (programme informatique, noyau du système d'exploitation, etc.), un accès à un système ou à des informations sensibles, voire une élévation des privilèges d'un utilisateur.
On parle de **faille distante** lorsque la vulnérabilité se situe dans un logiciel constituant un service réseau (par exemple un serveur Web) et qu'elle peut être exploitée par un attaquant distant, qui ne dispose pas d'un compte local. Les vulnérabilités locales peuvent être utilisées par un utilisateur malintentionné, qui possède un compte, pour effectuer une élévation des privilèges, ou bien par un attaquant distant pour augmenter ses privilèges, après l'exploitation d'une vulnérabilité distante. On parle de **faille locale** lorsque la vulnérabilité n'est exploitable que par un utilisateur disposant d'un compte local. Les vulnérabilités distantes peuvent être utilisées par des attaquants pour obtenir un accès sur un système.

## II.2.6 Exemples de vulnérabilités

Les vulnérabilités ci-dessous font partie des plus connues :

* dépassement de tampon ;

* injection SQL ;

* cross site scripting.
## II.3 JOURNAUX DES EVENEMENTS (FICHIERS LOGS) ET SYSLOG

### II.3.1 JOURNAUX DES EVENEMENTS (FICHIERS LOGS)

<figure><img src="image_22.png" /></figure>

#### Structure de journal informatique "circulaire"

En informatique, le concept **d'historique des événements** ou de **journalisation** désigne l'enregistrement séquentiel dans un fichier ou une base de données de tous les événements affectant un processus particulier (application, activité d'un réseau informatique...). Le **journal** (en anglais *log file* ou plus simplement *log*), désigne alors le fichier contenant ces enregistrements. Généralement datés et classés par ordre chronologique, ces derniers permettent d'analyser pas à pas l'activité interne du processus et ses interactions avec son environnement.

#### Un fichier texte peut être la structure sous-jacente d'un fichier journal

En français, le *journal* est le livre où sont inscrits des événements. Il s'applique initialement dans le domaine des organisations (journal de bord), puis à partir du XIXe siècle dans le domaine littéraire (journal intime) et dans le domaine de la presse d'information (journal d'information)². Le journal est aussi le terme utilisé en comptabilité d'entreprise et a diffusé dans les systèmes informatiques bancaires pour la traçabilité des transactions et des erreurs, puis dans le domaine des télécommunications, enfin en informatique générale². Le terme se différencie des registres et main courante par son séquencement temporel².

En anglais et en argot franglais, le terme *log file* est la traduction de *journal* ou de *main-courante*, tandis que le terme *inscription* est traduit en anglais par *log*.

#### Fonctionnalités offertes

L'enregistrement d'un historique permet de mettre en œuvre des fonctionnalités telles que les « derniers fichiers ouverts », les « dernières commandes tapées » ou les « dernières pages web consultées ».

#### Applications

La journalisation est une technique importante, utilisée entre autres en sécurité informatique et dans les systèmes de comptabilité et paiement.
Dans le cadre de la sécurité, les événements enregistrés seront les accès au système, les modifications de fichiers, etc. On consacre typiquement une ligne par événement, en commençant par le moment exact (date, heure, minute, seconde) où il a eu lieu.

La journalisation permet d'effectuer des analyses diverses, généralement statistiques ; de faire des hypothèses sur les dysfonctionnements ou les pertes de performance d'un système.

L'accès aux journaux peut contrevenir à certaines exigences de confidentialité, voire de sécurité.

La journalisation permet aussi d'enregistrer les événements dans deux places différentes.

Les enregistrements d'événements peuvent également avoir une importance légale. Par exemple un fournisseur d'accès à Internet est tenu de fournir un historique des connexions de ses clients (Loi du 15 novembre 2001 "LSQ", Loi du 21 juin 2004 "LCEN").

## Journalisation applicative

La journalisation applicative désigne l'enregistrement chronologique des opérations de la logique métier pendant le fonctionnement de l'application. Un journal applicatif est lui-même une exigence du métier. Il est donc défini comme une fonctionnalité faisant partie de la logique applicative. Par conséquent, il ne devrait pas être arrêté pendant le fonctionnement de l'application.

## Journalisation système

La journalisation système désigne l'enregistrement chronologique des événements survenant au niveau des composants du système. Le niveau de cette journalisation peut être paramétré, afin de filtrer les différents événements selon leur catégorie de gravité. Les catégories généralement utilisées sont, par ordre croissant de gravité : information, débogage, avertissement, erreur.

Pour exemple, les systèmes Unix mettent en œuvre cette journalisation système à l'aide du protocole Syslog.
### Syslog

<table><tr><td>Fonction</td><td>Transmission de journaux</td></tr><tr><td>Port</td><td>UDP 514</td></tr><tr><td>RFC</td><td>RFC 3164<sup>1</sup></td></tr><tr><td>RFC</td><td>RFC 3195<sup>2</sup></td></tr><tr><td>RFC</td><td>RFC 5424<sup>3</sup></td></tr><tr><td>RFC</td><td>RFC 5426<sup>4</sup></td></tr></table>

modifier

Syslog est un protocole définissant un service de journaux d'événements d'un système informatique. C'est aussi le nom du format qui permet ces échanges.

### Historique

Syslog a été développé dans les années 1980 par Eric Allman dans le cadre du projet Sendmail⁵, et n'était initialement prévue que pour Sendmail. Il s'est avéré si utile que d'autres applications ont commencé à l'utiliser. Syslog est depuis devenu la solution de journalisation standard sur les systèmes Unix et Linux⁶, il y a également une variété d'implémentations syslog sur d'autres systèmes d'exploitation (Windows notamment⁷) et est généralement trouvé dans les périphériques réseau tels que les commutateurs ou routeurs.

### Le protocole Syslog

#### Présentation générale

En tant que protocole, Syslog se compose d'une partie cliente et d'une partie serveur. La partie cliente émet les informations sur le réseau, via le port UDP 514. Les serveurs collectent l'information et se chargent de créer les journaux.

L'intérêt de Syslog est donc de centraliser les journaux d'événements, permettant de repérer plus rapidement et efficacement les défaillances d'ordinateurs présents sur un réseau.

Il existe aussi un logiciel appelé Syslog, qui est responsable de la prise en charge des fichiers de journalisation du système. Ceci inclut aussi le démon klogd, responsable des messages émis par le noyau Linux.

#### Positionnement système[modifier | modifier le code]

Le protocole syslog utilise un socket afin de transmettre ses messages. Suivant les systèmes, celui-ci est différent:
<table><thead><tr><td>Plate-forme</td><td>Méthode</td></tr></thead><tbody><tr><td>Linux</td><td>Un SOCK_STREAM unix nommé /dev/log; certaines distributions utilisent SOCK_DGRAM</td></tr><tr><td>BSD</td><td>Un SOCK_DGRAM unix appelé /var/run/log.</td></tr><tr><td>Solaris (2.5 et inférieurs)</td><td>Un flux SVR4 appelé /dev/log.</td></tr><tr><td>Solaris (2.6 et supérieurs)</td><td>En plus du flux habituel, une porte multithreaded appelée /etc/.syslogesis est utilisée.</td></tr><tr><td>HP-UX 11 et supérieur</td><td>HP-UX utilise le Tube Unix nommé /dev/log de taille 2048 bytes</td></tr><tr><td>AIX 5.2 and 5.3</td><td>Un SOCK_STREAM ou un SOCK_DGRAM unix appelé /dev/log.</td></tr></tbody></table>

Une problématique nait de ce choix architectural, l'utilisation d'un point d'entrée unique crée des saturations système qui ont incité nombre de logiciels à utiliser leur propre système d'enregistrement.

## Le format Syslog

Un journal au format syslog comporte dans l'ordre les informations suivantes : la date à laquelle a été émis le log, le nom de l'équipement ayant généré le log (hostname), une information sur le processus qui a déclenché cette émission, le niveau de priorité du log, un identifiant du processus ayant généré le log et enfin un corps de message.

Certaines de ces informations sont optionnelles.

exemple :

Sep 14 14:09:09 machine_de_test dhcp service[warning] 110 corps du message

## Niveau de priorité

La priorité du message permet de déterminer la catégorie et la gravité du journal, elle est entre chevrons dans le journal syslog⁶ : priorité = (catégorie × 8) + gravité.

Cette indication est particulièrement importante car elle normalise de fait la représentation de la catégorie et de la gravité d'un log, ce qui rend par exemple
possible l'interopérabilitéentre équipements de collecte de journaux et équipements de génération d'alertes.

## Catégories

Les messages sont orientés au regard de leur origine, dont les codes sont regroupés suivant 24 types ci-dessous énumérés⁶ :

### Codes de catégorie

<table><thead><tr><td>Code</td><td>Mot-clé</td><td>Description</td></tr></thead><tbody><tr><td>0</td><td>Kern</td><td>kernel messages</td></tr><tr><td>1</td><td>User</td><td>user-level messages</td></tr><tr><td>2</td><td>Mail</td><td>mail system</td></tr><tr><td>3</td><td>daemon</td><td>system daemons</td></tr><tr><td>4</td><td>Auth</td><td>security/authorization messages</td></tr><tr><td>5</td><td>syslog</td><td>messages generated internally by syslogd</td></tr><tr><td>6</td><td>Lpr</td><td>line printer subsystem</td></tr><tr><td>7</td><td>news</td><td>network news subsystem</td></tr><tr><td>8</td><td>Uucp</td><td>UUCP subsystem</td></tr><tr><td>9</td><td></td><td>clock daemon</td></tr><tr><td>10</td><td>authpriv</td><td>security/authorization messages</td></tr></tbody></table>
<table><tr><td>11</td><td>ftp</td><td>FTP daemon</td></tr><tr><td>12</td><td>-</td><td>NTP subsystem</td></tr><tr><td>13</td><td>-</td><td>log audit</td></tr><tr><td>14</td><td>-</td><td>log alert</td></tr><tr><td>15</td><td>Cron</td><td>clock daemon</td></tr><tr><td>16</td><td>local0</td><td>local use 0 (local0)</td></tr><tr><td>17</td><td>local1</td><td>local use 1 (local1)</td></tr><tr><td>18</td><td>local2</td><td>local use 2 (local2)</td></tr><tr><td>19</td><td>local3</td><td>local use 3 (local3)</td></tr><tr><td>20</td><td>local4</td><td>local use 4 (local4)</td></tr><tr><td>21</td><td>local5</td><td>local use 5 (local5)</td></tr><tr><td>22</td><td>local6</td><td>local use 6 (local6)</td></tr><tr><td>23</td><td>local7</td><td>local use 7 (local7)</td></tr></table>

**Niveau de gravité[modifier | modifier le code]**

Les niveaux de gravité Syslog, appelés Severity level en anglais sont au nombre de huit représentés par un chiffre de 0 (Emergency) à 7 (Debug)⁶ :

**Codes de gravité**
<table><thead><tr><td>Code</td><td>Gravité</td><td>Mot-clé</td><td>Description</td></tr></thead><tbody><tr><td>0</td><td>Emergency</td><td>emerg (panic)</td><td>Système inutilisable.</td></tr><tr><td>1</td><td>Alert</td><td>alert</td><td>Une intervention immédiate est nécessaire.</td></tr><tr><td>2</td><td>Critical</td><td>crit</td><td>Érreur critique pour le système.</td></tr><tr><td>3</td><td>Error</td><td>err (error)</td><td>Érreur de fonctionnement.</td></tr><tr><td>4</td><td>Warning</td><td>warn (warning)</td><td>Avertissement (une erreur peut intervenir si aucune action n'est prise).</td></tr><tr><td>5</td><td>Notice</td><td>notice</td><td>Événement normal méritant d'être signalé.</td></tr><tr><td>6</td><td>Informational</td><td>info</td><td>Pour information.</td></tr><tr><td>7</td><td>Debugging</td><td>debug</td><td>Message de mise au point.</td></tr></tbody></table>

## L'écriture dans le journal syslog

### journalisation dans syslog (local ou distant) se fait via

* logger⁸ (commande Unix) pour les scripts shell

* vsyslog() ou syslog()⁹ pour les programmes compilés ; ce sont des fonctions implémentées dans des bibliothèques logicielles

## Fichier de configuration (syslog.conf)

À l'origine, le fichier de configuration syslog était construit sur le mode ligne, chaque ligne était découpée en deux parties :

* la première indique l'origine du message

* la seconde la destination

Ce fichier de configuration permet de différencier les messages et de les orienter vers des destinations particulières.
Dans les versions récentes (rsyslog, syslog-ng, nxlog ...), la configuration est plus évoluée et permet des filtrages plus élaborés, bien que dans certains cas la configuration basique soit encore utilisée.

## Origine

Les origines peuvent être multiples et sont juxtaposées à l'aide d'un ';'.

Elles sont construites sous la forme :

facility.criticity

La criticité doit être comprise comme la criticité minimale, ainsi user.crit correspond au message d'origine utilisateur pour le niveau de criticité critical et les niveaux supérieurs, en l'occurrence alert et emergency.

Le mot clef "none" peut lui aussi être utilisé afin de filtrer les messages, il est alors utilisé en lieu et place de la criticité.

## Destination

Dans syslog classique, la destination peut être soit un fichier soit un serveur distant. La destination peut être précédé d'un - afin d'indiquer la finalité de celle-ci. Le signe « - » est utilisé devant les chemins de fichiers les moins critiques pour améliorer les performances en écriture (pas de synchronisation des fichiers) au risque de perdre des données en cas de crash du système.

## Exemple

Extrait d'une partie d'un fichier de configuration :

<table><tr><td>daemon.*</td><td>-/var/log/daemon.log</td></tr><tr><td>user.crit</td><td>@serveurdelog</td></tr><tr><td>kern.*</td><td>-/var/log/kern.log</td></tr><tr><td>lpr.*</td><td>-/var/log/lpr.log</td></tr><tr><td>mail.info</td><td>-/var/log/mail.info</td></tr><tr><td>mail.warning</td><td>-/var/log/mail.warning</td></tr><tr><td>mail.err</td><td>/var/log/mail.err</td></tr><tr><td>Auth/authpriv</td><td>traces sécurité/identifiant ion</td></tr><tr><td>cron</td><td>traces d'un cron</td></tr><tr><td>daemon.*</td><td>trace d'un daemon</td></tr><tr><td>kern.*</td><td>traces du noyau</td></tr><tr><td>lpr.*</td><td>traces du système d'impression</td></tr><tr><td>mail</td><td>traces du système de messagerie</td></tr><tr><td>news</td><td>traces d'un service de news/réseau</td></tr><tr><td>syslog</td><td>traces du service syslog lui-même</td></tr><tr><td>user</td><td>trace des processus utilisateur</td></tr><tr><td>local0 à 7</td><td>traces issues des klogd</td></tr></table>
# CHAP.III : LES OUTILS DE SECURITE INFORMATIQUE

## III.1 LES SCANNEURS DES PORTS (Balayage de ports)

### III.1.1 NOTIONS SUR LE BALAYAGE DE PORT

En informatique, le balayage de ports (*port scanning* en anglais) est une technique servant à rechercher les ports ouverts sur un serveur de réseau. Cette technique est utilisée par les administrateurs des systèmes informatiques pour contrôler la sécurité des serveurs de leurs réseaux. La même technique est aussi utilisée par les pirates informatiques pour tenter de trouver des failles dans des systèmes informatiques. Un balayage de ports (*port scan* ou *portscan* en anglais) effectué sur un système tiers est généralement considéré comme une tentative d'intrusion, car un balayage de ports sert souvent à préparer une intrusion.

Le balayage de ports est une des activités considérées comme suspectes par un système de détection d'intrusion. Un système de détection d'intrusion peut être réglé à différents niveaux de sensibilité. Un niveau de sensibilité élevé génèrera plus de fausses alertes, un niveau de sensibilité bas risque de laisser passer les balayages effectués par des systèmes sophistiqués comme Nmap qui disposent de diverses options pour camoufler leurs balayages.

Pour tromper la vigilance des systèmes de détection et des pare-feu, les balayages peuvent se faire dans un ordre aléatoire, avec une vitesse excessivement lente (par exemple sur plusieurs jours), ou à partir de plusieurs adresses IP.

Les balayages de ports se font habituellement sur le protocole TCP ; néanmoins, certains logiciels permettent aussi d'effectuer des balayages UDP. Cette dernière fonctionnalité est beaucoup moins fiable, UDP étant orienté sans connexion, le service ne répondra que si la requête correspond à un modèle précis variant selon le logiciel serveur utilisé.

### III.3.2 Techniques de balayage des ports

#### 1. TCP

Un balayage de ports vise typiquement le protocole TCP, car c'est celui qui est utilisé par la majorité des applications. L'objectif du balayage est
de savoir si un logiciel est en écoute sur un numéro de port donné. Si un
logiciel écoute, on dit que le port est *ouvert*, sinon on dit qu'il est *fermé*.
Le balayage d'un port se passe en deux étapes :

1. l'envoi d'un paquet sur le port testé ;

2. l'analyse de la réponse.

Il existe de nombreuses variantes pour le paquet émis. Il y a le paquet
valide selon la norme TCP, le paquet « TCP SYN », et les paquets
invalides. L'utilisation des paquets invalides vise à tromper les systèmes
de détection d'intrusion. La liste des paquets invalides utilisés est :

* ACK ;

• FIN ;

* Maimon¹ (FIN/ACK) ;

• NULL (aucun) ;

• Xmas² (tous) ;

• Window (ACK).

Le serveur peut répondre de différentes manières :

* ouverture de connexion acceptée : envoi d'un paquet TCP SYN/ACK ;

• fermeture de la connexion : envoi d'un paquet TCP RST ;

* absence de réponse : on dit que le paquet est *droppé*.

La réponse *ouverture de connexion acceptée* indique clairement que le
port est ouvert. La réponse *fermeture de la connexion* indique que le port
est fermé. L'absence de réponse est souvent due à un pare-feu qui vise à
contrer le balayage de ports. Le pare-feu peut détecter un trafic anormal
et décider d'ignorer pendant un certain temps tous les paquets provenant
de la machine générant le trafic anormal. En absence de réponse, on ne
peut donc pas savoir avec certitude si le port est ouvert ou fermé.

La technique *Window* envoie un paquet TCP ACK et observe la taille de la fenêtre TCP du paquet de réponse (TCP RST). Si le port est fermé, la taille de la fenêtre de la réponse est nulle.

La technique *Mainon* est utilisée sur les systèmes BSD. Uriel Maimon a constaté que ces systèmes ignorent un paquet TCP FIN/ACK (invalide) si le port est ouvert au lieu d'envoyer la réponse TCP RST.

2. Autres techniques pour TCP
Une autre technique consiste à passer par un serveur FTP. On utilise la fonctionnalité de serveur mandataire des serveurs FTP pour balayer les ports.

Enfin, la technique Idle scanning utilise l'identifiant de fragmentation du protocole IP. Un système de détection d'intrusion pense que l'analyse provient d'un ordinateur zombi. Consultez l'article (en) Idle Scanning and Related IPID Games [archive] pour plus de renseignements.

### 3. UDP et IP

Pour le protocole UDP, on envoie un paquet UDP vide (de longueur nulle). Si le port est fermé, un message ICMP de type 3 (*destinataire inaccessible*) et code 3 est envoyé.

Il est également possible de lister les protocoles IP pris en charge par un hôte. On appelle cette technique *IP protocol*.

### 4. Version du scanner des ports

On peut détecter le système d'exploitation et sa version par la prise d'empreinte de la pile TCP/IP. Un logiciel tel que Nmap permet également de détecter le nom du logiciel écoutant sur un port, voire sa version.

## III.3.2 LE NMAP (Scanneurs des ports)

### III.3.2.1 PRESENTATION

Nmap

<figure><img src="image_23.png" /></figure>
<figure><img src="image_24.png" /></figure>

**Développeur** Fyodor

**Première version** 1er septembre 1997¹

**Dernière version** 7.70 (20 mars 2018)²

**Écrit en** C++, Python, C, Lua et Java

**Environnements** Multiplate-forme

**Type** Sécurité informatique

**Licence** GNU GPL

**Site web** nmap.org [archive]

modifier

**Nmap** est un **scanneur de ports libre** créé par **Fyodor** et distribué par **Insecure.org**. Il est conçu pour détecter les **ports ouverts**, identifier les **services** hébergés et obtenir des informations sur le **système d'exploitation** d'un ordinateur distant. Ce logiciel est devenu une référence pour les administrateurs réseaux car l'audit des résultats de Nmap fournit des indications sur la sécurité d'un **réseau**. Il est disponible sous **Windows**, **Mac OS X**, **Linux**, **BSD** et **Solaris**.

Le code source de Nmap est disponible sous la licence **GNU GPL**.

### III.3.2.2 Les bases du scan de ports

Même si le nombre de fonctionnalités de Nmap a considérablement augmenté au fil des ans, il reste un scanner de ports efficace, et cela reste sa fonction principale. La commande de base **nmap <target>** scanne plus de 1 660 ports TCP de l'hôte <target>. Alors que de nombreux autres scanners de ports ont partitionné les états des ports en ouverts ou fermés, Nmap a une granularité bien plus fine. Il divise les ports selon six états: **ouvert** (open), **fermé** (closed), **filtré** (filtered), **non-filtré** (unfiltered), **ouvert|filtré** (open|filtered), et **fermé|filtré** (closed|filtered).
Ces états ne font pas partie des propriétés intrinsèques des ports eux-mêmes, mais décrivent comment Nmap les perçoit. Par exemple, un scan Nmap depuis le même réseau que la cible pourrait voir le port 135/tcp comme ouvert alors qu'un scan au même instant avec les mêmes options au travers d'Internet pourrait voir ce même port comme filtré.

### III.3.2.3 Les six états de port reconnus par Nmap

#### ouvert (open)

Une application accepte des connexions TCP ou des paquets UDP sur ce port. Trouver de tels ports est souvent le but principal du scan de ports. Les gens soucieux de la sécurité savent pertinemment que chaque port ouvert est un boulevard pour une attaque. Les attaquants et les pen-testers veulent exploiter ces ports ouverts, tandis que les administrateurs essaient de les fermer ou de les protéger avec des pare-feux sans gêner leurs utilisateurs légitimes. Les ports ouverts sont également intéressants pour des scans autres que ceux orientés vers la sécurité car ils indiquent les services disponibles sur le réseau.

#### fermé (closed)

Un port fermé est accessible (il reçoit et répond aux paquets émis par Nmap), mais il n'y a pas d'application en écoute. Ceci peut s'avérer utile pour montrer qu'un hôte est actif (découverte d'hôtes ou scan ping), ou pour la détection de l'OS. Comme un port fermé est accessible, il peut être intéressant de le scanner de nouveau plus tard au cas où il s'ouvrirait. Les administrateurs pourraient désirer bloquer de tels ports avec un pare-feu, mais ils apparaîtraient alors dans l'état filtré décrit dans la section suivante.

#### filtré (filtered)

Nmap ne peut pas toujours déterminer si un port est ouvert car les dispositifs de filtrage des paquets empêchent les paquets de tests (probes) d'atteindre leur port cible. Le dispositif de filtrage peut être un pare-feu dédié, des règles de routeurs filtrants ou un pare-feu logiciel. Ces ports ennuient les attaquants car ils ne fournissent que très peu d'informations. Quelques fois ils répondent avec un message d'erreur ICMP de type 3 code 13 (« destination unreachable: communication administratively prohibited »), mais les dispositifs de filtrage qui rejettent les paquets sans rien
répondre sont bien plus courants. Ceci oblige Nmap à essayer
plusieurs fois au cas où ces paquets de tests seraient rejetés à
cause d'une surcharge du réseau et pas du filtrage. Ceci ralenti
terriblement les choses.

non-filtré (unfiltered)

L'état non-filtré signifie qu'un port est accessible, mais que Nmap est incapable de déterminer s'il est ouvert ou fermé. Seul le scan ACK, qui est utilisé pour déterminer les règles des pare-feux, catégorise les ports dans cet état. Scanner des ports non-filtrés avec un autre type de scan, comme le scan Windows, SYN ou FIN peut aider à savoir si un port est ouvert ou pas.

ouvert|filtré (open|filtered)

Nmap met dans cet état les ports dont il est incapable de
déterminer l'état entre ouvert et filtré. Ceci arrive pour les types de
scans où les ports ouverts ne renvoient pas de réponse. L'absence
de réponse peut aussi signifier qu'un dispositif de filtrage des
paquets a rejeté le test ou les réponses attendues. Ainsi, Nmap ne
peut s'assurer ni que le port est ouvert, ni qu'il est filtré. Les scans
UDP, protocole IP, FIN, Null et Xmas catégorisent les ports ainsi.

fermé|filtré (closed|filtered)

Cet état est utilisé quand Nmap est incapable de déterminer si un
port est fermé ou filtré. Cet état est seulement utilisé par le scan
Idle basé sur les identifiants de paquets IP.

### III.3.2.3 Spécification des cibles

Tout ce qui n'est pas une option (ou l'argument d'une option) dans la
ligne de commande de Nmap est considéré comme une spécification
d'hôte cible. Le cas le plus simple est de spécifier une adresse IP cible ou
un nom d'hôte à scanner.

Si vous désirez scanner un réseau entier d'hôtes consécutifs, Nmap supporte l'adressage du style CIDR. Vous pouvez ajouter / <numbits> à une adresse IP ou à un nom d'hôte de référence et Nmap scannera toutes les adresses IP dont les <numbits> bits de poids fort sont les mêmes que la cible de référence. Par exemple, 192.168.10.0/24 scannerait les 256 hôtes entre 192.168.10.0 (en binaire: 11000000 10101000 00001010
00000000) et 192.168.10.255 (en binaire: 11000000 10101000 00001010 11111111) inclusivement. 192.168.10.40/24 ferait donc aussi la même chose. Étant donné que l'hôte scanme.nmap.org est à l'adresse IP 205.217.153.62, scanme.nmap.org/16 scannerait les 65 536 adresses IP entre 205.217.0.0 et 205.217.255.255. La plus petite valeur autorisée est /1 qui scanne la moitié d'Internet. La plus grande valeur autorisée est 32, ainsi Nmap ne scanne que la cible de référence car tous les bits de l'adresse sont fixés.

La notation CIDR est concise mais pas toujours des plus pratiques. Par exemple, vous voudriez scanner 192.168.0.0/16 mais éviter toutes les adresses se terminant par .0 ou .255 car se sont souvent des adresses de diffusion (broadcast). Nmap permet de le faire grâce à l'adressage par intervalles. Plutôt que de spécifier une adresse IP normale, vous pouvez spécifier pour chaque octet de l'IP une liste d'intervalles séparés par des virgules. Par exemple, 192.168.0-255.1-254 évitera toutes les adresses se terminant par .0 ou .255. Les intervalles ne sont pas limités aux octets finals: 0-255.0-255.13.37 exécutera un scan de toutes les adresses IP se terminant par 137.37. Ce genre de spécifications peut s'avérer utile pour des statistiques sur Internet ou pour les chercheurs.

Les adresses IPv6 ne peuvent être spécifiées que par une adresse IPv6 pleinement qualifiée ou un nom d'hôte. L'adressage CIDR ou par intervalles n'est pas géré avec IPv6 car les adresses ne sont que rarement utiles.

Nmap accepte les spécifications de plusieurs hôtes à la ligne de commande, sans qu'elles soient nécessairement de même type. La commande **nmap scanme.nmap.org 192.168.0.0/8 10.0.0.1,3-7.0-255** fait donc ce à quoi vous vous attendez.

Même si les cibles sont souvent spécifiées dans les lignes de commandes, les options suivantes sont également disponibles pour sélectionner des cibles :

- *iL <inputfilename>* (Lit la liste des hôtes/réseaux cibles depuis le fichier)

Lit les spécifications des cibles depuis le fichier <inputfilename>. Il est souvent maladroit de passer une longue liste d'hôtes à la ligne de commande. Par exemple, votre serveur DHCP pourrait fournir une liste de 10 000 baux que vous souhaiteriez scanner. Ou alors voudriez scanner toutes les adresses IP sauf celles des baux DHCP
pour identifier les hôtes qui utilisent des adresses IP statiques non-autorisées. Générez simplement la liste des hôtes à scanner et passez ce fichier comme argument de l'option -iL. Les entrées peuvent être spécifiées dans n'importe quel des formats acceptés par la ligne de commande de Nmap (adresses IP, noms d'hôtes, CIDR, IPv6 ou par intervalles). Les entrées doivent être séparées par un ou plusieurs espaces, tabulations ou retours chariot. Vous pouvez utiliser un tiret (-) comme nom de fichier si vous souhaitez que Nmap lise les hôtes depuis l'entrée standard.

**-iR <num hosts>** (Choisit des cibles au hasard)

Pour des études à l'échelle d'Internet ou autres, vous pourriez désirer de choisir vos cibles au hasard. L'argument `<num hosts>` indique à Nmap combien d'IPs il doit générer. Les IPs à éviter, comme les plages d'adresses privées, multicast ou non allouées sont automatiquement évitées. On peut aussi utiliser l'argument `0` pour effectuer un scan sans fin. Rappelez-vous bien que certains administrateurs de réseau s'irritent lorsqu'on scanne leur réseau sans permission et peuvent porter plainte. Utilisez cette option à vos risques et périls! Un jour de pluie où vous ne savez pas quoi faire, essayez la commande **nmap -sS -PS80 -iR 0 -p 80** pour trouver des serveurs Web au hasard sur lesquels fureter.

**--exclude <host1[,host2][,host3],...>** (Exclut des hôtes/des réseaux des cibles)

Spécifie une liste de cibles séparées par des virgules à exclure du scan, même si elles font partie de la plage réseau que vous avez spécifiée. La liste que vous donnez en entrée utilise la syntaxe Nmap habituelle, elle peut donc inclure des noms d'hôtes, des blocs CIDR, des intervalles, etc. Ceci peut être utile quand le réseau que vous voulez scanner comprend des serveurs à haute disponibilité, des systèmes reconnus pour réagir défavorablement aux scans de ports ou des sous-réseaux administrés par d'autres personnes.

**--excludefile <exclude_file>** (Exclut des hôtes/des réseaux des cibles depuis le fichier)

Cette option offre les mêmes fonctionnalités que l'option `--exclude`, à la différence qu'ici les cibles à exclure sont spécifiées dans le fichier `<exclude_file>` au lieu de la ligne de commande. Les cibles sont séparées entre elles dans le fichier par des retours chariot, des espaces ou des tabulations.
### III.3.2.4 UTILISATION DU NMAP A MODE CONSOLE

NMAP est un logiciel open source permettant d'explorer le réseau afin de déceler d'éventuelles failles de sécurité. Nous avons la possibilité de le choisir afin de l'inclure dans notre solution de sécurité pour ses diverses capacités de scanneurs de ports, de détection de services et de découvertes de type de pare-feu présent sur la machine ciblée. De plus, il est fortement présent dans le domaine de la sécurité informatique de par sa simplicité d'utilisation et sa flexibilité. En effet, au départ créé pour scanner un grand nombre de machines rapidement, il peut tout aussi bien effectuer cette tâche sur une seule machine. Pour cela nous utiliserons la dernière version de NMAP, la 4.20.

#### 1. Détection de l'hôte

**nmap -sP ip** : Emet un ping à l'hôte, et permet de récupérer le nom de l'hôte. De plus cela permet de savoir si la machine répond aux ping ou non et donc de savoir si elle est ou non en ligne. Il y a deux types de scan dans cette commande, l'une ou vous devez être root et l'autre que vous aurez par défaut, cette dernière ressemble fortement au scan de type TCP connect(). Le scan nécessitant les droits administrateurs quant à lui utilise l'ICMP ECHO REPLY... (On peut désactiver l'ICMP scan en ajoutant l'argument -P0).

**nmap -O** : Permet de détecter le type d'OS utilisé sur la machine.

#### 2. Type de scan

**nmap -sT ip** : scan basic de type TCP connect(), ce type de scan permet de scanner les ports un par un afin d'obtenir une liste des ports ouvert ou non. Le problème majeur de cette technique est la facilité de détecter cette dernière.

**nmap -sS ip** : scan de type SYN Stealth, cette technique est basée directement sur le fonctionnement du TCP. En effet, il existe plusieurs "flags" permettant d'identifier la procédure de connection à un port :

* SYN : (synchronise) : demande de synchronisation.

* ACK (Acknowledge) : indique la réception de paquets.

* FIN (finished) : indique la fin de la connection, fin normale.

* RST (Reset) : indique la fermeture brutale de la connection.

La procédure est assez simple, on envoie un SYN, si le serveur envoie son SYN et un ACK, on envoie alors un RST avant que la connection soit établie afin d'éviter de se trouver dans les logs, concrètement cela signifie que le port est ouvert.
Si le serveur envoie un RST : le port est fermé

Si aucune réponse, le paquet est filtré.

On peut toutefois détecter ces types de connections avec des systèmes plus modernes de détection d'intrusions.

Exemple :

```
[root@localhost]# nmap -sS localhost
Starting Nmap 4.20 (http://insecure.org) at 2007-03-11 16:54 CET
Interesting ports on localhost.localdomain (127.0.0.1):
Not shown: 1689 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
111/tcp open rpcbind
389/tcp open ldap
443/tcp open https
631/tcp open ipp
720/tcp open unknown
```

nmap -sF, sN, sX : Ces trois modes de scans permettent de savoir si l'hôte est une machine Windows ou non. En effet, une machine Windows ne respectant pas le RFC 793, répond au SYN, et s'il ne répond à aucun de ces trois scans, alors cet hôte à de grandes chances d'être une machine windows.

Exemple :

```
[root@localhost pelletier]# nmap -sF localhost
Starting Nmap 4.20 (http://insecure.org) at 2007-03-11 16:54 CET
Interesting ports on localhost.localdomain (127.0.0.1):
Not shown: 1689 closed ports
PORT STATE SERVICE
22/tcp open/filtered ssh
25/tcp open/filtered smtp
80/tcp open/filtered http
111/tcp open/filtered rpcbind
389/tcp open/filtered ldap
443/tcp open/filtered https
631/tcp open/filtered ipp
720/tcp open/filtered unknown
```

On remarque ici la différence entre le scan FIN et le scan SYN Stealth, en effet, globalement le résultat est le même, cependant on peut facilement voir que les connections à ses ports sont logués...

nmap -sU : scan UDP, cette technique envoie un paquet UDP sur chaque port de la machine, si l'on reçoit un message ICMP Port Unreachable, cela signifie que le port est fermé sinon, on admet qu'il est ouvert. Cela permet surtout de détecter les trojans qui utilisent généralement le protocole UDP. Il faut cependant noter que certains Os limitent le nombre d' ICMP Port Unreachable (WINDOWS ne limite pas)

nmap -sO : Scan Protocole IP : Ce scan utilise le protocole ICMP, il est donc aussi limité en nombre d' ICMP Port Unreachable. de la même manière on envoie un type de paquet, si l'on reçoit un ICMP Port Unreachable, cela signifie que le port n'est pas en utilisation, sinon on admet qu'il est ouvert. Toutes les machines n'envoient pas forcément ce message. En effet, les firewalls, AIX et Certains Unix simulent et indiquent que tous ses ports sont ouverts.
Exemple :

[root@localhost pelletier]# nmap -sO localhost
Starting Nmap 4.20 (http://insecure.org) at 2007-03-11 17:11 CET
Interesting protocols on localhost.localdomain (127.0.0.1):
Not shown: 251 closed protocols
PROTOCOL STATE SERVICE
1 open icmp
2 open|filtered igmp
6 open tcp
17 open udp
255 open|filtered unknown

nmap -sI <zombie host[:probeport]> : Idlescan, ce scan est pratiquement invisible. En effet, pour cela il est nécessaire d'avoir un Hôte Zombie, votre cible pensera que cet Hôte sera celui qui l' "attaque", ce qui est bien entendu totalement faux ...De plus, vous n'envoyez AUCUN paquet à la cible ... il ne peut donc pas facilement vous retracez...

Donc par exemple on obtient :

[root@localhost]#nmap -P0 -p- -sI zombie.host.com cible.com
Starting nmap V. 3.10ALPHA3 (insecure.org/nmap/)
Idlescan using zombie zombie.host.com (192.150.13.111:80); Class: Incremental
Interesting ports on cible.com:
(The 65522 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
25/tcp open smtp
80/tcp open http
111/tcp open sunrpc
135/tcp open loc-srv
443/tcp open https
1027/tcp open IIS
1030/tcp open iad1
2306/tcp open unknown
5631/tcp open pcanywheredata
7937/tcp open unknown
7938/tcp open unknown
36890/tcp open unknown

A noter cependant que ce scan peut être très long, en effet on parcourt ici les ports de 1 à 65535. Pour faire uniquement les ports 1 à 1024 vous devez enlever l'argument -p-

nmap -sW : Il est parfois possible de détecter des ports ouverts grâce à ce scan, mais cela uniquement sur les anciennes machines Windows...

Détection de Service :

nmap -sV -A : ce scan permet de détecter les services lancés et leurs ports d'utilisations. De plus, l'argument -A permet d'utiliser l'empreinte de l'OS et sa version.
Exemple :

[root@localhost]# nmap -sV -A localhost
Starting Nmap 4.20 ( http://insecure.org ) at 2007-03-11 17:29 CET

Interesting ports on localhost.localdomain (127.0.0.1):

Not shown: 1689 closed ports

PORT STATE SERVICE VERSION

22/tcp open ssh OpenSSH 4.3 (protocol 2.0)

25/tcp open smtp Sendmail 8.13.8/8.13.8

80/tcp open http Apache httpd 2.2.3 ((Fedora))

111/tcp open rpcbind 2 (rpc #100000)

389/tcp open ldap (Anonymous bind OK)

443/tcp open ssl OpenSSL

631/tcp open ipp CUPS 1.2

720/tcp open status 1 (rpc #100024)

No exact OS matches for host (If you know what OS is running on it, see http://insecure.org/nmap/submit/).

TCP/IP fingerprint:

OS:SCAN(V=4.20%D=3/11%OT=22%CT=1%CU=35734%PV=N%DS=0%G=Y%TM=45F42E93%P=i686-

OS:pc-linux-gnu)SEQ(SP=CC%GCD=1%ISR=CB%TI=Z%II=I%TS=A)SEQ(SP=CC%GCD=2%ISR=C

OS:B%TI=Z%II=I%TS=A)OPS(O1=M400CST11NW5%O2=M400CST11NW5%O3=M400CNNNT11NW5%O4OS:=M

400CST11NW5%O5=M400CST11NW5%O6=M400CST11)WIN(W1=8000%W2=8000%W3=8000%WOS:4=8000%

W5=8000%W6=8000)ECN(R=Y%DF=Y%T=40%W=8018%O=M400CNNSNW5%CC=N%Q=)T1OS:(R=Y%DF=Y%

T=40%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=Y%DF=Y%T=40%W=8000%S=O%OS:A=S+%F=AS%O=M

400CST11NW5%RD=0%Q=)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=OS:0%Q=)T5(R=Y%DF=

Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%OS:S=A%A=Z%F=R%O=%

RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(OS:R=Y%DF=N%T=40%TOS
=C0%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUL=G%RUD=OS:G)IE(R=Y%DFI=N%T=40%T
OSI=S%CD=S%SI=S%DLI=S)

Uptime: 0.262 days (since Sun Mar 11 11:12:44 2007)

Network Distance: 0 hops

Service Info: OS: Unix

3. Timing

nmap possède des timings prédéfinis. En effet, le timing est extrêmement important dans les scans. Un timing trop agressif est largement plus facilement détecté qu’un scan avec un faible timing. De cette manière, vous pourrez ajouter l’argument :

« -T0 », le mode « Paranoid » afin d’être extrêmement prudent (il y aura un temps minimum de 5 minutes entre chaque paquet)

« -T3 », le mode « Normal », par défaut (aussi vite que possible)

« -T5 », le mode « Insane » afin de faire un scan rapide (0.3 secondes entre chaque paquet)

4. Les Leurres

nmap permet d'utiliser des leurres afin de scanner une machine. De cette manière la machine sera submergée d'une multitude de leurres, noyant alors votre scanning de la machine entre les leurres, il devient alors beaucoup plus difficile de savoir qui est le vrai du faux.

Pour cela vous devrez ajouter l'argument « -D ».

5. La fragmentation

La fragmentation permet simplement de passer à travers certains firewall, en effet ces derniers ne reconnaissent pas le paquet (puisqu'il est fragmenté), il décide de le laisser passer ...

Commande « -f »
6. Les Logs

Il est logique de vouloir garder une trace des commandes exécuter par nmap, pour cela vous devrez
rajouter l'un des arguments suivant :

-oN nomdufichier.log : permet de sauvegarder une version « lisible » de la commande

-oX nomdufichier.log : permet d'obtenir un log en XML

-oG nomdufichier.log : enregistre une version « grepable »

7. Quelques exemples

nmap -sS -A cible

nmap -sS -P0 -A -v cible

nmap -v -A scanme.nmap.org

nmap -v -sP 192.168.0.0/16 10.0.0.0/8

nmap -v -iR 10000 -P0 -p 80

### III.3.2.6 UTILISATION DU NMAP AVEC INTERFACE GRAPHIQUE

Il est possible d'avoir une interface graphique permettant aux personnes réticentes du mode console de pouvoir facilement utiliser NMAP. Cette interface se nomme Nmapfe.

Tout d'abord lorsque vous lancerez Nmapfe vous arriverez sur cette application :

<figure><img src="image_25.png" /></figure>
Sur cette capture d'écran, nous pouvons voir que vous devez entrer l'IP de la cible ou l'host name. Par la suite vous pouvez choisir différents types de scan, ainsi que diverses options. En effet, voyons les types de scan possibles :

<figure><img src="image_26.png" /></figure>

On peut remarquer la création de la commande en bas ...Celle qui aurait dût être saisie afin d'obtenir le même résultat.

Sur cette capture d'écran, nous pouvons voir que vous devez entrer l'IP de la cible ou l'host name. Par la suite vous pouvez choisir différents types de scan, ainsi que diverses options. En effet, voyons les types de scan possibles :

<figure><img src="image_27.png" /></figure>

On peut remarquer la création de la commande en bas ...Celle qui aurait dût être saisie afin d'obtenir le même résultat.
Voyons maintenant l'onglet « Discover » :

Cet onglet permet de choisir le type de ping afin de choisir ce que l'on décide de vérifier, de plus nous pouvons choisir les ports éventuels à ping.

<figure><img src="image_28.png" /></figure>

L'onglet « Timing » :

Dans cet onglet, nous pouvons choisir le temps de vie d'un ping, ainsi que le temps séparant deux pings .... (Cf. les différents modes)

<figure><img src="image_29.png" /></figure>
## L'onglet « Files »

Cet onglet permet de choisir un fichier d'entrée, par exemple une liste d'host à ping ainsi qu'un fichier de sortie, c'est dans ce fichier que NMAP va enregistrer tout ce qu'il a trouvé.

<figure><img src="image_30.png" /></figure>

## L'onglet « Options »

C'est ici que nous choisirons la « verbosity » du log, c'est-à-dire la précision de ce dernier, de plus vous pouvez choisir un port ou une ip particulière afin de ping l'host (c'est le mode Zombie). Enfin vous pourrez choisir de fragmenter vos ping (pour traverser les firewalls), choisir un ordre d'host aléatoire dans un fichier à ping ou encore de choisir un port aléatoirement afin de ping votre cible.

<figure><img src="image_31.png" /></figure>
Voici par exemple ce que l'on peut obtenir en fichier de sortie :

```
Starting Nmap 4.20 (http://insecure.org) at 2007-03-19 10:23 CET
Interesting ports on vir91-6-82-245-128-71.fbx.proxad.net (82.245.128.71):
Not shown: 1688 filtered ports
PORT STATE SERVICE
21/tcp closed ftp
22/tcp open ssh
80/tcp open http
389/tcp open ldap
554/tcp open rtsp
901/tcp open samba-swat
1241/tcp open nessus
6346/tcp closed gnutella
6881/tcp open bittorrent-tracker
Device type: general purpose printer specialized WAP storage-misc
Running (JUST GUESSING): Linux 2.6.X|2.4.X (94%), Xerox embedded (86%), Atmel Linux 2.6.X (86%), Linksys Linux 2.4.X (86%), Asus Linux 2.4.X (86%), Maxtor Linux 2.4.X (86%), Siemens linux (85%)
Aggressive OS guesses: Linux 2.6.9 (RHEL 4, SMP) (94%), Linux 2.6.17.8 SMP i686 (custom compiled) (89%), Linux 2.6.8-3 (Debian 3.1) (89%), Linux 2.6.18 (Arch Linux, x86) (89%), Linux 2.6.9-22.0.1.EL (CentOS 4.4) (89%), Linux 2.4.22 (Fedora Core 1, x86) (88%), Linux 2.6.9 - 2.6.12 (x86) (87%), Xerox WorkCentre Pro 265 multifunction printer (86%), Atmel AVR32 STK1000 development board (runs Linux 2.6.16.11) (86%), Linux 2.4.20 - 2.4.32, Linux-based embedded device (Linksys WRT54GL WAP, Buffalo AirStation WLA-G54 WAP, Maxtor Shared Storage Drive, or Asus Wireless Storage Router) (86%)
No exact OS matches for host (test conditions non-ideal).
Uptime: 0.035 days (since Mon Mar 19 09:33:55 2007)

OS detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/.
Nmap finished: 1 IP address (1 host up) scanned in 33.616 seconds
```

### III.3.2.6 UTILISATION DU NMAP EN GENERAL

#### Différentes options (1)

* commande de base:

`nmap <machine_cible>`

`nmap -P0 <machine_cible> ...... passe le firewall`

`[root@localhost ~]# nmap -P0 himalia`

```
Starting Nmap 4.20 (http://insecure.org) at 2008-03-26 08:28 CET
```

Interesting ports on himalia:

Not shown: 1694 closed ports

PORT STATE SERVICE

22/tcp open ssh

111/tcp open rpcbind

6000/tcp open X11

Nmap finished: 1 IP address (1 host up) scanned in 0.093 seconds
Différentes options (2)

* Découvrir application/services en écoute sur les ports TCP:
  nmap -sV <machine_cible>

[root@localhost ~]# nmap -sV himalia

Starting Nmap 4.20 (http://insecure.org) at 2008-03-26 08:31 CET

Interesting ports on himalia:

Not shown: 1694 closed ports

PORT STATE SERVICE VERSION

22/tcp open ssh OpenSSH 3.6.1p2 (protocol 1.99)

111/tcp open rpcbind 2 (rpc #100000)

6000/tcp open X11 (access denied)

Service Info: OS: Unix

Service detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/.

Nmap finished: 1 IP address (1 host up) scanned in 6.300 seconds
Différentes options (3)

* Découvrir le système d'exploitation :

nmap -sO <machine_cible>

[root@localhost ~]# nmap -O himalia

Starting Nmap 4.20 ( http://insecure.org ) at 2008-03-26 08:32 CET

Interesting ports on himalia:

Not shown: 1694 closed ports

PORT STATE SERVICE

22/tcp open ssh

111/tcp open rpcbind

6000/tcp open X11

Device type: general purpose|WAP|storage-misc

Running: Linux 2.4.X, Linksys Linux 2.4.X, Asus Linux 2.4.X, Maxtor Linux 2.4.X

OS details: Linux 2.4.20 - 2.4.32, Linux-based embedded device (Linksys WRT54GL WAP, Buffalo AirStation WLA-G54 WAP, Maxtor Shared Storage Drive, or Asus Wireless Storage Router)

Uptime: 68.640 days (since Thu Jan 17 17:11:08 2008)

Network Distance: 1 hop

OS detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/.

Nmap finished: 1 IP address (1 host up) scanned in 1.785 seconds
Différentes options (4)

balayage sur des réseaux entiers: rechercher les serveurs Web present sur un LAN, par ex

nmap -sS -sV -p 80 <@réseau_classeC / 24> ou <X.Y.Z.80 - 443>

[root@localhost ~]# nmap -P0 -sV -p 80 172.16.13.16-32

Starting Nmap 4.20 (http://insecure.org) at 2008-03-26 11:13 CET

Interesting ports on 172.16.13.16:

PORT STATE SERVICE VERSION

80/tcp open http Apache httpd 2.2.3 ((CentOS))

MAC Address: 00:14:5E:57:A2:5C (IBM)

Interesting ports on venus (172.16.13.18):

PORT STATE SERVICE VERSION

80/tcp closed http

MAC Address: 40:13:97:9D:00:14 (Unknown)

Interesting ports on pc-sig (172.16.13.22):

PORT STATE SERVICE VERSION

80/tcp filtered http

MAC Address: 00:14:22:26:DF:F2 (Dell)

Interesting ports on pleiades (172.16.13.25):

PORT STATE SERVICE VERSION

80/tcp open http Apache httpd 1.3.31 ((Unix) mod_perl/1.24 ApacheJserv/1.1.2)

MAC Address: 00:03:BA:14:A4:F4 (Sun Microsystems)

Interesting ports on glpi (172.16.13.29):

PORT STATE SERVICE VERSION

80/tcp open http Apache httpd 2.2.3 ((Mandriva Linux/PREFORK-1mdv2007.0))

MAC Address: 00:02:A5:62:E5:E7 (Compaq Computer)

Service detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/.

Nmap finished: 17 IP addresses (13 hosts up) scanned in 6.914 seconds

Option « -n » permet de désactiver la résolution DNS et ainsi accroître la rapidité du balayage.
## Options disponibles (1)

Pour Nmap 4.20, voici les options que nous pouvons utiliser :

* Les cibles peuvent être spécifiées par des noms d'hôtes, des adresses IP (v4 ou v6), des adresses de réseaux...

ex: www.cnrs.fr, 192.168.1.1, 192.168.1.0/24, microsoft.com/24, 10.0-255.0-255.1-254

* **Découverte des hôtes :**

* **-sL**: List Scan - Liste simplement les cibles à scanner

* **-sP**: Ping Scan - Ne fait que déterminer si les hôtes sont en ligne -P0: Considère que tous les hôtes sont en ligne-- évite la découverte des hôtes

* **-PN**: Considérer tous les hôtes comme étant connectés -- saute l'étape de découverte des hôtes

* **-PS/PA/PU [portlist]:** Découverte TCP SYN/ACK ou UDP des ports en paramètre

* **-PE/PP/PM**: Découverte de type requête ICMP echo, timestamp ou netmask

* **-PO [num de protocole]:** Ping IP (par type)

* **-n/-R**: Ne jamais résoudre les noms DNS/Toujours résoudre [résout les cibles actives par défaut]

* `--dns-servers <serv1[,serv2],...>`: Spécifier des serveurs DNS particuliers

* `--system-dns`: Utilise le resolveur DNS du système d'exploitation

## Options disponibles (2)

Techniques de scan :

* **-sS/sT/sA/sW/sM**: Scans TCP SYN/Connect() /ACK/Window/Maimon

* **-sN/sF/sX**: Scans TCP Null, FIN et Xmas

* **-sU**: Scan UDP (Cette option ne fonctionne pas en IPv6)

`--scanflags <flags>`: Personnalise les flags des scans TCP

* **-sI <zombie host[:probeport]>**: Idlescan (scan passif)

* **-sO**: Scan des protocoles supportés par la couche IP

* **-b <ftp relay host>**: Scan par rebond FTP

`--traceroute`: Détermine une route vers chaque hôte

`--reason`: Donne la raison pour laquelle tel port apparaît à tel état
# Options disponibles (3)

## Spécifications des ports et ordre de scan :

* `-p <plage de ports>`: Ne scanne que les ports spécifiés

Exemple: -p22; -p1-65535; -pU:53,111,137,T:21-25,80,139,8080

* `-F`: Fast - Ne scanne que les ports listés dans le fichier nmap-services

* `-r`: Scan séquentiel des ports, ne mélange pas leur ordre

- `--top-ports <nombre>`: Scan <nombre> de ports parmis les plus courants

- `--port-ratio <ratio>`: Scan <ratio> pourcent des ports les plus courants

## Détection de service/version :

* `-sV`: Teste les ports ouverts pour déterminer le service en écoute et sa version

- `--version-light`: Limite les tests aux plus probables pour une identification plus rapide

- `--version-intensity <niveau>`: De 0 (léger) à 9 (tout essayer)

- `--version-all`: Essaie un à un tous les tests possibles pour la détection des versions

- `--version-trace`: Affiche des informations détaillées du scan de versions (pour débogage)

# Options disponibles (4)

## Script scan :

* `-sC`: équivalent de `--script=safe,intrusive`

- `--script=<lua scripts>`: `<lua scripts>` est une liste de répertoires ou de scripts séparés des virgules

- `--script-args=<n1=v1,[n2=v2,...]>`: passer des arguments aux scripts

- `--script-trace`: Montre toutes les données envoyées ou recues

- `--script-updatedb`: Met à jour la base de données des scripts. Seulement fait si `-sC` ou

- `--script a été aussi donné`.

## Détection de système d'exploitation :

* `-O`: Active la détection d'OS

- `--osscan-limit`: Limite la détection aux cibles prométeuses

- `--osscan-guess`: Devine l'OS de façon plus agressive
# Options disponibles (5)

## Temporisation et performance :

Les options qui prennent un argument de temps sont en milisecondes a moins que vous ne spécifiez 's' (secondes), 'm' (minutes), ou 'h' (heures) à la valeur (e.g. 30m).

* `-T[0-5]`: Choisit une politique de temporisation (plus élevée, plus rapide)
  * `--min-hostgroup/max-hostgroup <msec>`: Tailles des groupes d'hôtes à scanner en parallèle
  * `--min-parallelism/max-parallelism <msec>`: Parallélisation des paquets de tests (probes)
  * `--min_rtt_timeout/max-rtt-timeout/initial-rtt-timeout <msec>`: Spécifie le temps d'aller-retour des paquets de tests
  * `--min_rtt_timeout/max-rtt-timeout/initial-rtt-timeout <msec>`: Spécifie le temps d'aller-retour des paquets detests
  * `--min-rtt-timeout/max-rtt-timeout/initial-rtt-timeout <time>`: Précise le round trip time des paquets de tests.
  * `--max-retries <tries>`: Nombre de retransmissions des paquets de tests des scans de ports.
  * `--host-timeout <msec>`: Délai d'expiration du scan d'un hôte
  * `--scan-delay/--max-scan-delay <time>`: Ajuste le délais entre les paquets de tests.

# Options disponibles (6)

## Evasion parefeu/ids et usurpation d'identité :

* `-f; --mtu <val>`: Fragmente les paquets (en spécifiant éventuellement la MTU)

* `-D <decoy1,decoy2[,ME],...>`: Obscurci le scan avec des leurres

* `-S <IP Address>`: Usurpe l'adresse source

* `-e <iface>`: Utilise l'interface réseau spécifiée

* `-g/--source-port <portnum>`: Utilise le numéro de port comme source
  * `--data-length <num>`: Ajoute des données au hasard aux paquets émis
  * `--ip-options <options>`: Envoi des paquets avec les options IP spécifiées.
  * `--ttl <val>`: Spécifie le champ time-to-live IP
  * `--spoof-mac <adresse MAC, préfixe ou nom du fabriquant>`: Usurpe une adresse MAC
  * `--badsum`: Envoi des paquets TCP/UDP avec une somme de contrôle erronée.
## Options disponibles (7)

### Sortie :

* `-oN/-oX/-oS/-oG <file>`: Sortie dans le fichier en paramètre des résultats du scan au format normal, XML, s|<rlpt klddi3 et Grepable, respectivement

* `-oA <basename>`: Sortie dans les trois formats majeurs en même temps

* `-v`: Rend Nmap plus verbeux (-vv pour plus d'effet)

* `-d[<level>`: Sélectionne ou augmente le niveau de débogage (significatif jusqu'à 9)

* `--packet-trace`: Affiche tous les paquets émis et reçus

* `--iflist`: Affiche les interfaces et les routes de l'hôte (pour débogage)

* `--log-errors`: Journalise les erreurs/alertes dans un fichier au format normal

* `--append-output`: Ajoute la sortie au fichier plutôt que de l'écraser

* `--resume <filename>`: Reprend un scan interrompu

* `--stylesheet <path/URL>`: Feuille de styles XSL pour transformer la sortie XML en HTML

* `--webxml`: Feuille de styles de références de Insecure.Org pour un XML plus portable

* `--no-stylesheet`: Nmap n'associe pas la feuille de styles XSL à la sortie XML

## Options disponibles (8)

### Divers :

* `-6`: Active le scan IPv6

* `-A`: Active la détection du système d'exploitation et des versions

* `--datadir <dirname>`: Spécifie un dossier pour les fichiers de données de Nmap

* `--send-eth/--send-ip`: Envoie des paquets en utilisant des trames Ethernet ou des paquets IP bruts

* `--privileged`: Suppose que l'utilisateur est entièrement privilégié
  * `-V`: Affiche le numéro de version

* `--unprivileged`: Suppose que l'utilisateur n'a pas les privilèges d'usage des raw socket

* `-h`: Affiche ce résumé de l'aide
# Résumé des techniques de Scan

<table><thead><tr><th>Nmap Scan</th><th>Command Syntax</th><th>Requires Privileged Access</th><th>Identifies TCP Ports</th><th>Identifies UDP Ports</th></tr></thead><tbody><tr><td>TCP SYN Scan</td><td>-sS</td><td>YES</td><td>YES</td><td>NO</td></tr><tr><td>TCP connect() Scan</td><td>-sT</td><td>NO</td><td>YES</td><td>NO</td></tr><tr><td>FIN Scan</td><td>-sF</td><td>YES</td><td>YES</td><td>NO</td></tr><tr><td>Xmas Tree Scan</td><td>-sX</td><td>YES</td><td>YES</td><td>NO</td></tr><tr><td>Null Scan</td><td>-sN</td><td>YES</td><td>YES</td><td>NO</td></tr><tr><td>Ping Scan</td><td>-sP</td><td>NO</td><td>NO</td><td>NO</td></tr><tr><td>Version Detection</td><td>-sV</td><td>NO</td><td>NO</td><td>NO</td></tr><tr><td>UDP Scan</td><td>-sU</td><td>YES</td><td>NO</td><td>YES</td></tr><tr><td>IP Protocol Scan</td><td>-sO</td><td>YES</td><td>NO</td><td>NO</td></tr><tr><td>ACK Scan</td><td>-sA</td><td>YES</td><td>YES</td><td>NO</td></tr><tr><td>Window Scan</td><td>-sW</td><td>YES</td><td>YES</td><td>NO</td></tr><tr><td>RPC Scan</td><td>-sR</td><td>NO</td><td>NO</td><td>NO</td></tr><tr><td>List Scan</td><td>-sL</td><td>NO</td><td>NO</td><td>NO</td></tr><tr><td>IdleScan</td><td>-sI</td><td>YES</td><td>YES</td><td>NO</td></tr><tr><td>FTP Bounce Attack</td><td>-b</td><td>NO</td><td>YES</td><td>NO</td></tr></tbody></table>

## exemple de mail envoyé par detescan

Analyse du fichier : /var/stats/firewall.tmp
Taille du fichier : 42 Mb
Destinataire : support@sciences.univ-nantes.fr,claude.dutreilly@univ-nantes.fr
Lignes : 212554
Debut de l'analyse : 26/03/2008 06:00:10
Fin de l'analyse : 26/03/2008 06:51:38
Parametres pour detection scans : nb machines minimum >= 3, nb ports minimum >= 5
Detescan v20040308 a detecte les scans suivants a partir des logs du routeur iptables
Statistiques des connexions rejetees (au moins 20 connexion(s) par port) :
5672 connexion(s) sur le port 53/udp (domain)
dont 1161 connexion(s) de 172.16.13.59 sur 193.52.103.2 ()
dont 2378 connexion(s) de 172.16.40.52 sur 192.168.100.2 ()
dont 814 connexion(s) de 172.16.11.24 sur 193.252.19.4 ()
dont 1082 connexion(s) de 172.16.11.24 sur 193.252.19.3 ()
## TCP Handshake

<figure><img src="image_32.png" /></figure>

* Une « poignée de main » en trois étapes établit une connexion TCP.

* Elle assure l'échange (drapeau SYN) et l'acquittement (drapeau ACK) des numéros de séquence initiaux.

## Scan TCP SYN : -sS

* cas d'un port fermé

### TCP SYN Scan Operation

Most of the ports queried during the TCP SYN scan will probably be closed. These closed port responses to the TCP SYN frame will be met with a RST frame from the destination station.

<figure><img src="image_33.png" /></figure>

* cas d'un port ouvert

If nmap receives an acknowledgment to a SYN request, then the port is open. Nmap then sends an RST to reset the session, and the handshake is never completed.

<figure><img src="image_34.png" /></figure>
## Scan TCP Connect: -sT

* cas d'un port fermé

### TCP connect() Scan Operation

The TCP connect() scan to a closed port looks exactly like the TCP SYN scan:

<figure><img src="image_35.png" /></figure>

Source
192.168.0.8

<figure><img src="image_36.png" /></figure>

<figure><img src="image_37.png" /></figure>

Destination
192.168.0.10

* cas d'un port ouvert

A scan to an open port results in a different traffic pattern than the TCP SYN scan:

<figure><img src="image_38.png" /></figure>

Source
192.168.0.8

<figure><img src="image_39.png" /></figure>

<figure><img src="image_40.png" /></figure>

Destination
192.168.0.10

## Scan TCP FIN: sF

* cas d'un port fermé

### FIN Scan

The FIN scan's "stealth" frames are unusual because they are sent to a device without first going through the normal TCP handshaking. If a TCP session isn't active, the session certainly can't be formally closed!

In this FIN scan, TCP port 443 is closed so the remote station sends a RST frame response to the FIN packet:

<figure><img src="image_41.png" /></figure>

Source
192.168.0.8

<figure><img src="image_42.png" /></figure>

<figure><img src="image_43.png" /></figure>

Destination
192.168.0.7

* cas d'un port ouvert

If a port is open on a remote device, no response is received to the FIN scan:

<figure><img src="image_44.png" /></figure>

Source
192.168.0.8

<figure><img src="image_45.png" /></figure>

<figure><img src="image_46.png" /></figure>

Destination
192.168.0.7
## Scan TCP FIN: -sF (suite)

The nmap output shows the open ports located with the FIN scan:

```
# nmap -sF -v 192.168.0.7
```

```
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 20:05-04-23
```

```
21:17 EDT
```

```
Initiating FIN Scan against 192.168.0.7 [1663 ports] at 21:17
```

```
The FIN Scan took 1.51s to scan 1663 total ports.
```

```
Host 192.168.0.7 appears to be up ... good.
```

```
Interesting ports on 192.168.0.7:
```

```
(The 1654 ports scanned but not shown below are in state: closed)
```

```
PORT      STATE      SERVICE
```

```
21/tcp   open|filtered ftp
```

```
22/tcp   open|filtered ssh
```

```
23/tcp   open|filtered telnet
```

```
79/tcp   open|filtered finger
```

```
110/tcp  open|filtered pop3
```

```
111/tcp  open|filtered rpcbind
```

```
514/tcp  open|filtered shell
```

```
886/tcp  open|filtered unknown
```

```
2049/tcp open|filtered nfs
```

```
MAC Address: 00:03:47:6D:29:D7 (Intel)
```

```
Nmap finished: 1 IP address (1 host up) scanned in 2.276 seconds
Raw packets sent: 1674 (66.9KB) | Rcvd: 1655 (76.1KB)
```

#

## Scan Xmas Tree: -sX

* cas d'un port fermé

The Xmas tree scan sends a TCP frame to a remote device with the URG, PUSH, and FIN flags set. This is called a Xmas tree scan because of the alternating bits turned on and off in the flags byte (00101001), much like the lights of a Christmas tree.

A closed port responds to a Xmas tree scan with a RST:

<figure><img src="image_47.png" /></figure>

Source
192.168.0.8

<figure><img src="image_48.png" /></figure>

Destination
192.168.0.7

* cas d'un port ouvert

Similar to the FIN scan, an open port on a remote station is conspicuous by its silence:

<figure><img src="image_49.png" /></figure>

Source
192.168.0.8

<figure><img src="image_50.png" /></figure>

Destination
192.168.0.7
## Scan Xmas Tree: -sX (suite)

The Xmas tree scan output shows similar results to the FIN scan:

```
# nmap -sX -v 192.168.0.7
```

```
Starting nmap 3.01 ( http://www.insecure.org/nmap/ ) at 2005-04-23
```

```
21:18 EDT
```

```
Initiating XMAS Scan against 192.168.0.7 [1663 ports] at 21:18
```

```
The XMAS Scan took 1.55s to scan 1663 total ports.
```

```
Host 192.168.0.7 appears to be up ... good.
```

```
Interesting ports on 192.168.0.7:
```

```
(The 1654 ports scanned but not shown below are in state: closed)
```

<table><thead><tr><th>PORT</th><th>STATE</th><th>SERVICE</th></tr></thead><tbody><tr><td>21/tcp</td><td>open</td><td>filtered ftp</td></tr><tr><td>22/tcp</td><td>open</td><td>filtered ssh</td></tr><tr><td>23/tcp</td><td>open</td><td>filtered telnet</td></tr><tr><td>79/tcp</td><td>open</td><td>filtered finger</td></tr><tr><td>110/tcp</td><td>open</td><td>filtered pop3</td></tr><tr><td>111/tcp</td><td>open</td><td>filtered rpcbind</td></tr><tr><td>514/tcp</td><td>open</td><td>filtered shell</td></tr><tr><td>886/tcp</td><td>open</td><td>filtered unknown</td></tr><tr><td>2049/tcp</td><td>open</td><td>filtered nfs</td></tr><tr><td>MAC Address:</td><td colspan="2">00:03:47:6D:29:D7 (Intel)</td></tr><tr><td colspan="3">Nmap finished: 1 IP address (1 host up) scanned in 2.432 seconds<br>Raw packets sent: 1674 (66.9KB) | Rcvd: 1655 (76.1KB)</td></tr></tbody></table>

## Scan NULL: -sN

* cas d'un port fermé

### The Null Scan (-sN)

The null scan turns off all flags, creating a lack of TCP flags that should never occur in the real world.

If the port is closed, a RST frame should be returned:

<figure><img src="image_51.png" /></figure>

* cas d'un port ouvert

As expected, the response of a null scan to an open port results in no response:

<figure><img src="image_52.png" /></figure>
# Détection de services / versions: -sV

## Version Detection Operation

The version detection scan runs in conjunction with another scan type that will identify open ports. If another scan type is not specified on the command line, nmap will run a TCP SYN scan (for a privileged user) or a TCP connect() scan (for non-privileged users) prior to running the version detection scan.

If open ports are found, the version detection scan will begin the probing process with the remote device. The version detection scan communicates directly with the remote application to uncover as much information as possible.

In this example, the default TCP SYN scan runs prior to the version detection scan to identify the open port:

<figure><img src="image_53.png" /></figure>

After the TCP SYN scan identifies port 80 as open, the version detection process begins. The process shown in this example is for this specific example. Other ports and application will operate differently.

<figure><img src="image_54.png" /></figure>

# nmap scan report : -oX

## nmap scan report - scan @ Wed Mar 26 14:10:43 2008

scan summary | scan info | 172.16.13.28 / monitor | runstats

### scan summary

nmap was initiated at Wed Mar 26 14:10:43 2008 with these arguments:

nmap -P 0 -sV -oX /tmp/res1.xml cups

The process stopped at Wed Mar 26 14:10:50 2008. Debugging was disabled, the verbosity level was 0.

### 172.16.13.28 / monitor

### address

* 172.16.13.28 (ipv4)

* 00:50 (DA:36:36:74 (mac)

### hostnames

* monitor (PTR)

### ports

The 1693 ports scanned but not shown below are in state: closed

<table><thead><tr><th>Port</th><th>State</th><th>Service</th><th>Product</th><th>Version</th><th>Extra info</th></tr></thead><tbody><tr><td>21</td><td>tcp</td><td>open</td><td>ftp</td><td>ProFTPD</td><td></td></tr><tr><td>22</td><td>tcp</td><td>open</td><td>ssh</td><td>OpenSSH</td><td>4.5</td></tr><tr><td>111</td><td>tcp</td><td>open</td><td>rpc</td><td></td><td>protocol 2.0</td></tr><tr><td>631</td><td>tcp</td><td>open</td><td>pp</td><td>CUPS</td><td>1.2</td></tr></tbody></table>

### runstats

* 7 sec. scanned

* 1 host(s) scanned

* 1 host(s) online

* 0 host(s) offline

* nmap version: 4.20

* xml output version: 1.01

* nmap.xsi version: 0.9b
## III.2 SCANNER DE VULNERABILITES

### III.2.1 NOTIONS SUR LES SCANNERS DE VULNERABILITES

En sécurité informatique, un scanner (ou scanneur) de vulnérabilités est un programme conçu pour identifier des vulnérabilités dans une application, un système d'exploitation, ou un réseau.

#### 1. Utilisation

Les scanneurs de vulnérabilités peuvent être utilisés dans des objectifs licites ou illicites :

* objectifs licites : les experts en sécurité informatique ou les entreprises utilisent les scanneurs de vulnérabilités pour trouver les failles de sécurité des systèmes informatiques et des systèmes de communications de leurs entreprises dans le but de les corriger avant que les pirates informatiques ne les exploitent ;

* objectifs illicites : les pirates informatiques utilisent les mêmes équipements pour trouver les failles dans les systèmes des entreprises pour les exploiter à leur avantage.

Cet outil peut être une brique intégrée d'une solution de sécurité plus large: un SIEM ou un SOC par exemple.

#### 2. Principes de fonctionnement

##### 2.1 Généralités

Les scanners de vulnérabilités se présentent sous plusieurs formes: logiciel à installer sur son système, machine virtuelle pré-configurée (virtual appliance) ou encore en SaaS dans le cloud.

Un scanner de vulnérabilités se "lance" sur une ou plusieurs cibles, dans un réseau interne ou sur Internet. Ces cibles (URL, adresse IP, sous-réseau) sont renseignées par l'utilisateur lorsqu'il désire mener son scan. La plupart des outils suivent le schéma de scan suivant:

* détection des cibles actives (attente d'une réponse ICMP, ARP, TCP, etc. pour déterminer si la cible répondra au scanner)

* détection des ports TCP et UDP accessibles sur la cible (scan de ports)

* détection des services actifs (SSH, HTTP, etc.) sur chacun de ces ports et de leurs versions (phase de "fingerprint")
* éventuellement: utilisation d'un compte fourni pour se connecter sur la machine et lister les programmes non visibles depuis le réseau (navigateur, liseuse, suite bureautique, etc.)

* éventuellement: reconnaissance des applications Web accessibles et construction de l'arbre de chaque site Web (phase dite de "crawling")

* sélection des modules de sécurité à lancer sur la cible selon les services précédemment reconnus

* lancement des modules de sécurité

* génération du rapport de sécurité

Un scanner de vulnérabilités est donc un outil complexe qui peut faire appel à de nombreux programmes spécifiques pour chacune des tâches pré-citées.

## 2.2 Cibles

Un scanner de vulnérabilités est théoriquement capable de tester tout élément joignable par une adresse IP :

* Ordinateur

* Serveur

* Routeur, commutateur, pare-feu

* Smartphone

* Objet connecté

* Site Web

* Automate, robot, machine

* Caméra IP

* IPBX, poste téléphonique sur IP

* etc.

Le fait de pouvoir joindre un élément n'implique cependant pas forcément que son niveau de sécurité puisse être audité correctement. Pour cela, le scanner doit embarquer les modules de sécurité idoines dans son catalogue. Par exemple, si une cible ne possède que le port UDP 161 ouvert avec le service SNMP, un scanner pourra reconnaître que cette cible est active mais ne pourra juger son niveau de sécurité qu'en incorporant des modules d'attaque contre SNMP.

## 2.3 Méthodes de détection

Pour établir la présence d'une vulnérabilité, un scanner dispose de plusieurs méthodes:
a) Fingerprint de version

Cette première méthode est la plus répandue. L'outil tente de déterminer
la nature et la version d'un service, par exemple: apache httpd 2.4.2.

Pour cela, il peut se fier aux bannières présentées par les différents
services, rechercher des motifs caractéristiques d'une version dans les
réponses du serveur (notamment dans les en-têtes), etc.

Une fois que la version est déterminée, l'outil utilise une base qui associe
à chaque version d'un outil, la liste des vulnérabilités publiquement
connues sur celui-ci.

De telles bases sont publiquement accessibles et enrichies par l'éditeur de
la solution concernée, par un État ou encore par une communauté. La
base la plus connue est celle des CVE: Common Vulnerabilities and
Exposures publiée par le MITRE, une organisation à but non lucratif
soutenue par le département de la Sécurité intérieure des États-Unis. Une
alternative indépendante est l'OSVDB (Open Source Vulnerability
Database). Ces bases tentent donc de recenser toutes les vulnérabilités
découvertes et de les associer aux produits vulnérables. Généralement
seuls les produits les plus connus font l'objet d'une entrée dans ces deux
bases. Les éditeurs les plus connus maintiennent aussi leur propres base:
Debian Security Advisory (DSA) pour Debian, CSA pour Cisco, RHSA pour
RedHat, idem pourWordpress, Gentoo, Drupal, etc.

De manière symétrique, la dénomination des programmes et de leurs
versions a été normalisée avec les CPE [archive] (Common Platform
Enumeration également maintenu par le MITRE) afin de pouvoir faire des
associations en base de données plus simple.

Cette méthode est cependant notoirement sujette aux faux positifs et aux
faux négatifs. De nombreux programmes ne laissent pas transparaître
leur version (désactivation des bannières, etc.), le scanner ne pourra donc
pas en déduire leurs vulnérabilités (faux négatifs). Inversement, des
programmes peuvent donner leur version mais avoir subi un rétroportage
des correctifs et donc, ne pas souffrir des vulnérabilités officiellement
rattachées à cette version (faux positifs). Ce dernier cas se produit très
fréquemment sur les versions paquetagées par les distributions Linux
comme Debian ou Ubuntu.
### b) Exploitation active

Lorsque des vulnérabilités sont publiquement dévoilées, elles sont parfois accompagnées d'un "exploit" (prononcé "exploite" ou "exploïte") qui est un programme permettant des les exploiter automatiquement.

Un scanner de vulnérabilités peut donc recourir à cet exploit pour vérifier la présence d'une vulnérabilité. Dans ce cas-là, le scanner n'a pas besoin de se fier à la version du programme qu'il audit, il se fie à la réussite ou à l'échec de l'exploit.

Plusieurs bases d'exploits existent telles que exploit-db [archive](maintenu par la communauté à l'origine de Kali Linux, distribution dédiée au tests d'intrusion) ou encore celle de l'outil metasploit [archive] (publié par Rapid7 qui édite notamment le scanner de vulnérabilités Nexpose).

Cette méthode est donc très efficace mais souffre de deux inconvénients. Premièrement il existe peu de vulnérabilités pour lesquelles un exploit est disponible: pour donner un ordre de grandeur, il existe 90 000 CVE enregistrées et moins de 4000 exploits dans metasploit. Deuxièmement, certains exploits peuvent avoir des effets de bord significatifs et perturber le fonctionnement de la machine auditée (pouvant aller jusqu'à un crash). Ils doivent donc être utilisés avec parcimonie et être rigoureusement qualifiés.

### c) Scan de configuration

Certaines vulnérabilités ne proviennent pas d'un défaut dans le code source du programme mais simplement d'un mauvais réglage de celui-ci dans un certain contexte. Les scanners de vulnérabilités peuvent donc détecter certaines vulnérabilités en analysant la configuration distante du service audité (ce qui est un service généralement prévus par celui-ci).

Ceci concerne par exemple les options de sécurité activées sur les cookies, les cipher suite dans la configuration SSL/TLS, les transferts de zone pour un server DNS, les mots de passe par défaut inchangés, les services par défaut laissés activés, etc.

Cette méthode est généralement sans risque (excepté tester les mots de passe par défaut qui peut bloquer des comptes après trop d'échecs) et la base des bonnes pratiques est relativement simple à maintenir (par rapport à celle des nouvelles vulnérabilités où l'on compte en moyenne 13 nouvelles CVE par jour). Cependant, il y a des risques de faux positifs
puisque le scanner de vulnérabilités n'est pas forcément à même de
connaître le contexte et donc de juger si la configuration en question est
adaptée ou non (exemple: un transfert de zone DNS est problématique
vers Internet mais relativement sans danger dans un réseau interne).

d) Scans authentifiés

Bien que la plupart des scanners soient "sans agents", ils fournissent
souvent la possibilité d'utiliser un compte renseigné par l'utilisateur pour
mener des tests authentifiés.

Lors d'un scan authentifié, le scanner utilise des modules appelés "local
security check" qui consistent à consulter la base des programmes
installés et leur version (en interrogeant le registre Windows ou Aptitude,
pacman, emerge, etc. pour Linux). En se basant sur les alertes de
sécurités des éditeurs (DSA, CSA, RHSA, etc.), le scanner pourra
constater la présence ou l'absence de programmes ayant des
vulnérabilités connues.

L'intérêt principal de cette méthode est de ne pas se limiter à la surface
visible de la machine depuis le réseau. En effet, une machine ayant un
navigateur obsolète pourrait facilement être compromise par un maliciel,
mais le navigateur étant un programme "client" et non pas "serveur", il
n'émet pas sur un port (puisqu'il consomme un service) comme le ferait
par exemple un serveur SSH (qui fournit un service). Donc, en l'absence
de scan authentifié, le risque peut demeurer totalement ignoré de
l'utilisateur du scanner de vulnérabilités.

Avec cette méthode, le scanner de vulnérabilités remplit donc également
une fonction proche du "patch management" (il permet la détection des
anomalies même s'il ne les corrige pas lui-même).

Cette méthode est fiable (pas ou peu de faux positifs/négatifs), ne risque
pas d'engendrer d'instabilités sur le système audité et est rapide. Elle
peut se substituer aux méthodes de fingerprint et d'exploitation active
mais pas à celle du scan de configuration qui demeure complémentaire.
En revanche, elle nécessite de fournir des comptes valides pour chaque
machine auditée.

e) Spécificité des applications Web

Les méthodes pré-citées ne sont pas suffisantes pour attester de la
sécurité d'un site Web. Elles permettent de savoir si le serveur Web sous-
jacent (exemples : Apache, Nginx, IIS) est exempt de vulnérabilités mais ne peuvent pas connaître la sécurité de l'application Web (ou du service Web) propulsée par ce serveur Web.

L'application Web peut souffrir de défauts de conception dans leur code source qui entraînent l'apparition de failles applicatives. Comme chaque site Web est unique, le scanner ne peut pas se fier à une quelconque base de connaissances. Néanmoins, les failles applicatives sont un sujet exhaustivement traité par l'OWASP (Open Web Application Security Project) qui est une communauté libre et ouverte œuvrant pour la sécurité des applications Web. L'OWASP recense toutes les familles de vulnérabilités Web et les attaques qui y sont associées. Certains scanners implémentent donc des modules de détection de ces familles de failles. D'autres scanners se spécialisent même exclusivement dans cette tâche (Burp suite, Zap, Wapiti...).

Il s'agit d'une approche comparable à l'exploitation active mais bien plus complexe. Ici, le scanner ne peut pas utiliser un exploit créé spécifiquement pour fonctionner sur un cas particulier bien connu. Le module d'attaque doit pouvoir s'adapter à tous les sites Web quelle que soit leur architecture. Pour cela, les tests Web incorporent une phase appelée "crawling" qui consiste à cartographier le site Web et tous ses points d'entrées de données (en suivant tous les liens ou même en tentant de deviner la présence de certaines pages : /admin, /phpmyadmin, etc.). Les points d'entrées sont ensuite soumis à des motifs d'attaque adaptatifs spécifiques aux familles d'attaques: injections SQL, XSS, LFI, RFI, traversée d'arborescence, etc.

Les scanners permettent généralement aussi de fournir un compte ou un cookie de session pour accéder aux parties réservées aux utilisateur authentifiés.

Les scanners Web sont cependant limités puisque des opérations complexes, comme remplir un formulaire d'assurance en ligne, ne peuvent être menées de bout en bout car elles peuvent nécessiter de renseigner des informations contextuelles et cohérentes que le scanner ne peut pas deviner.

## f) Restitution des résultats

La visualisation et la restitution des résultats se fait traditionnellement via deux paradigmes. Premièrement, une vue "par vulnérabilité" permettant
de lister toutes les vulnérabilités identifiées dans le scan et de donner
pour chacune d'elle la liste des machines affectées. Deuxièmement, une
vue "par machine" listant les cibles de l'audit associées à la liste de leur
vulnérabilités respectives.

Traditionnellement, en sécurité informatique, les vulnérabilités sont
restituées par ordre de criticité suivant une échelle à 4 niveaux :

* Critiques: les vulnérabilités permettant généralement une prise de contrôle ou une exécution de commande à distance dont l'exploitation est relativement simple

* Majeures: les vulnérabilités permettant une prise de contrôle ou une exécution de commande à distance dont l'exploitation demeure complexe

* Moyennes: les vulnérabilités ayant des impacts limités ou dont l'exploitation nécessite des conditions initiales non triviales

* Mineures: les vulnérabilités ayant des impacts faibles ou nuls à moins d'être combinées à d'autres vulnérabilités plus importantes

L'état de l'art associe à chaque vulnérabilité un score entre 0 et 10 appelé CVSS (Common Vulnerability Scoring System) qui dépend des caractéristiques de cette vulnérabilité. La version 3 du CVSS prend en compte, au minimum, les éléments suivants :

* Le vecteur d'attaque : est-ce que l'attaquant peut venir de n'importe où ou bien doit-il avoir une position de départ privilégiée ?

* Complexité : exploiter la vulnérabilité est-il trivial (par exemple si un exploit existe) ou bien hautement techniques ?

* Privilèges requis : l'attaquant doit-l disposer d'accès préalables (un compte utilisateur par exemple) pour pouvoir mener son action ?

* Interaction avec un utilisateur: l'attaquant doit-il amener la victime à effectuer une action pour que son attaque réussisse (comme l'inciter à cliquer sur un lien) ?

* Périmètre : est-ce qu'une exploitation permet à l'attaquant d'avoir accès à de nouvelles cibles ?

* Impacts : une exploitation réussie entraîne-t-elle des pertes de confidentialité/disponibilité/intégrité ?

Le score CVSS est régulièrement utilisé par les scanners de vulnérabilités pour pondérer les risques associés à une cible.

Les scanners doivent donner à l'utilisateur tous les éléments pertinents
pour sa compréhension de la vulnérabilité. Traditionnellement, une
description de vulnérabilité comporte les éléments suivants :
* Le nom de la vulnérabilité

* Sa criticité

* La cible touchée

* Une brève description de sa nature

* Une référence à une base de connaissance type CVE, OSVDB, DSA...

* Une mention de la simplicité de l'exploitation

* Une description de l'impact en cas d'exploitation réussie

* Une ou plusieurs préconisations pour la résoudre

Parfois, d'autres éléments y sont ajoutés:

* Le niveau de confiance à accorder à la vulnérabilité : quantification du risque qu'il s'agisse ou non d'un faux positif

* S'il existe ou non un exploit automatique

* Un extrait des données ayant permis au module de sécurité de conclure à la présence de cette faille

* La famille de vulnérabilité (authentification, mise à jour, etc.)

* Des liens pour en savoir plus (notamment pour des explications plus détaillées du fonctionnement technique de la vulnérabilité)

Les rapports sont souvent exportables aux formats PDF, CSV, HTML, etc.

# 3. Outils proches des scanners de vulnérabilités

## 3.1 Cas des outils d'audit de code

Certains outils d'audit de code se présentent parfois comme des scanners de vulnérabilités dans la mesure où ils permettent de détecter les failles applicatives en amont (directement dans le code source plutôt que via des tests externes). Il y a effectivement des similitudes dans la philosophie de ces outils. Ils se limitent cependant aux failles liées aux fonctionnement applicatifs mais ne couvrent pas les failles liées au déploiement (système d'exploitation et serveur sous-jacent) et à la configuration (mot de passe par défaut, données sensibles accessibles sans authentification).

## 3.2 Cas des scanners de ports

Les scanners de vulnérabilités embarquent un service de scan de ports, qu'il soit sur mesure ou sur étagère.

Les scanners de ports existent aussi tout à fait indépendamment des scanners de vulnérabilités. L'outil nmap est la référence incontournable dans ce domaine. En plus du scan de port, ils effectuent parfois aussi du fingerprint de service et peuvent tester la présence de certaines
vulnérabilités. Ces fonctionnalités sont cependant limités : pas de corrélation des versions (seulement de l'exploitation active et du scan de configuration), pas de scans authentifiés, pas de scans Web.

### 3.3 Cas des outils d'audit de configuration

Des outils comme lynis peuvent être déployés localement sur une machine pour vérifier le respect des bonnes pratiques de sécurité: permissions, mises à jour, configuration des services, etc. Leur approche les exclu cependant de découvrir certaines vulnérabilités puisqu'ils n'auditent la machine que d'après une liste figée de règles. Un mot de passe trivial sur un service de base de données ou un service lancée sans être installé sur le serveur (programme portable par exemple) échappent à ces outils.

### 3.4 Cas des outils de patch management

Certains outils permettent de lister tous les programmes installés et de vérifier leur état de mise à jour (et proposent d'appliquer les mises à jour nécessaire si besoin). Ces outils sont très puissants mais ne couvrent pas tout le périmètre des scanners de vulnérabilités: des programmes portables non à jour, des défauts de configuration, des mots de passe par défaut, sont autant d'éléments non pris en compte par ces outils.

### 3.5 Cas des scanners de vulnérabilités ciblés

Plusieurs outils permettent de détecter les vulnérabilités d'un seul type de cible :

* wpscan: pour les failles Wordpress

* routersploit: pour les failles sur routeur, commutateur et pare-feu

* sqlmap: pour les injections SQL uniquement

* brutespray: pour les mots de passe par défaut uniquement

* etc.

De même, les scanners de vulnérabilités uniquement orientés Web appartiennent, de fait, à cette catégorie: BurpSuite, Zap, W3af, Nikto, etc.

## 4. Distinctions entre les scanners

Les distinctions technologiques entre les scanners portent essentiellement sur les points suivants :
* Ergonomie

* Rapidité de la détection des cibles et ports ouverts

* Qualité de la fonction de fingerprint

* Support de la fonctionnalité de tests authentifiés

* Services testés: Web uniquement (comme BurpSuite, Wapiti, ...), tous excepté le Web (comme OpenVas, Nexpose free...), tous

* Richesse du catalogue des modules de sécurité et des technologies pouvant être auditées (systèmes d'exploitation, programmes, etc.)

* Rapidité du scan de vulnérabilités

* Clarté et exploitabilité des résultats restitués par le scanner

* Conformité à certaines normes sectorielles (PCI DSS, etc.)
## II.2.2 LE NESSUS

### 1. Généralités

Nessus

<figure><img src="image_55.png" /></figure>

<table><tr><td>Développeur</td><td>Tenable Network Security</td></tr><tr><td>Dernière version</td><td>5.2.6 (24 mars 2014)¹</td></tr><tr><td>Environnement</td><td>Multiplate-forme</td></tr><tr><td>Type</td><td>Scanner de vulnérabilité</td></tr><tr><td>Licence</td><td>GNU GPL, puis propriétaire</td></tr><tr><td>Site web</td><td>nessus.org [archive]</td></tr></table>

Nessus est un outil de sécurité informatique. Il signale les faiblesses potentielles ou avérées sur les machines testées. Ceci inclut, entre autres :

* les services vulnérables à des attaques permettant la prise de contrôle de la machine, l'accès à des informations sensibles (lecture de fichiers confidentiels par exemple), des dénis de service...
* les fautes de configuration (relais de messagerie ouvert par exemple)

* les patchs de sécurité non appliqués, que les failles corrigées soient exploitables ou non dans la configuration testée

* les mots de passe par défaut, quelques mots de passe communs, et l'absence de mots de passe sur certains comptes systèmes. Nessus peut aussi appeler le programme externe Hydra (de) pour attaquer les mots de passe à l'aide d'un dictionnaire.

* les services jugés faibles (on suggère par exemple de remplacer Telnet par SSH)

* les dénis de service contre la pile TCP/IP

## 2. Architecture et fonctionnement

Nessus détecte les machines vivantes sur un réseau, balaie les ports ouverts, identifie les services actifs, leur version, puis tente diverses attaques.

Nessus se divise en deux parties : nessusd qui est un daemon (service) exécutant les requêtes ainsi que la communication avec la cible, et nessus, une application cliente qui récupère les données et affiche le résultat.

Ce découpage est classique, le daemon tournant avec des privilèges élevés (root) alors que l'interface graphique, plus complexe et donc vulnérable, tourne sous l'identité d'un utilisateur non privilégié. Les tests sont joués par des plugins ; quelques-uns sont en C compilé, mais la majorité sont écrits dans le langage de script NASL (Nessus Attack Scripting Language).

La séquence des opérations est la suivante :

1. détection des machines vivantes sur le réseau par ping_host.nasl

2. « scan » des ports avec un des quatre analyseurs de ports internes, ou un scanner externe amap ou nmap, ce qui est déconseillé pour des raisons de performance.

3. récupération d'informations

1. type et version des divers services

2. Connexion (SSH, Telnet ou rsh) pour récupérer la liste des packages installés

4. attaques simples, peu agressives. Par exemple, directory traversal, test de relais de messagerie ouverts, etc.
5. attaques susceptibles d'être destructrices

6. dénis de service (contre les logiciels visés)

7. dénis de service contre la machine ou les équipements réseaux intermédiaires.

Les dernières catégories de tests, plus agressives, peuvent avoir des conséquences désastreuses sur la disponibilité du système (crash de la machine visée, voire des équipements réseaux) et peuvent être désactivées dans le mode *safe checks*.

Le logiciel client standard peut exporter les données sous divers formats (XML, HTML, LaTeX). Outre les failles, Nessus présente également diverses informations utiles à un auditeur comme la version des services ou du système d'exploitation.

## 3. Types de tests

Nessus étant un scanner de sécurité réseau (par opposition aux outils locaux comme le grand ancêtre COPS), la présentation des failles a été longtemps biaisée en faveur des failles exploitables à distance. Toutefois, Nessus sait détecter les failles exploitables localement :

* soit en identifiant un numéro de version dans une bannière, mais ce procédé est limité à une classe de failles particulière : les failles de services réseau exploitables seulement localement².

* soit en récupérant la liste des logiciels ou paquets installés sur la machine testée et en la comparant aux patchs publiés par les éditeurs. Ces tests locaux ont été introduits à partir de Nessus 2.2³.

## 4. Licence

Nessus est disponible sous licence GPL jusqu'à la version 2. Depuis la version 3, il est distribué sous licence propriétaire, mais toujours gratuit pour utilisation personnelle (Home Feed). La version 2 est maintenue. Il existe aussi un fork de Nessus 2 toujours sous licence GPL qui s'appelle OpenVAS.
## 4. Téléchargement

### Nessus 3.2.1.1 - Télécharger

https://nessus.fr.uptodown.com > Windows > Utilitaires > Sécurité > Blocage ▼

Télécharger Nessus 3.2.1.1. Inspectez la vulnérabilité de n'importe quel réseau. Nessus est un outil multiplateforme conçu pour les administrateurs de réseau ...

### télécharger nessus gratuit

https://nessus.fr.uptodown.com > Windows > Utilitaires > Sécurité > Blocage > Nessus ▼

téléchargement nessus, nessus, téléchargement gratuit.

### Nessus (64-bit) - libérez les revues de téléchargement et de logiciel ...

telecharger.cnet.com/Nessus-64-bit/3000-2085_4-75325456.html ▼

2 août 2016 - Nessus est la plateforme de balayage de vulnérabilité de confiance pour des auditeurs et des analystes de valeurs mobilières. Les utilisateurs ...

### Nessus | Tenable™

https://www.tenable.com/downloads/nessus ▼ Traduire cette page

Download Nessus and Nessus Manager. ... Binary download files for Nessus Professional, Nessus

Manager, and connecting Nessus Scanners to Tenable.io ...

Nessus Agents · Nessus Network Monitor · Web Application Scanning · Tenable

### Nessus - Télécharger gratuit

https://nessus.fr.jaleco.com/ ▼

Download Nessus 3.2.1.1. Analyse complète de la sécurité de votre réseau.

### Télécharger Nessus 3.2.1.1 - Download

https://nessus.fr.jaleco.com/download ▼

Télécharger Nessus 3.2.1.1 Gratuitement. En Français.

### Nessus - Télécharger

https://nessus.fr.softonic.com > Windows > Sécurité et vie privée ▼

Nessus Télécharger - Nessus (Nessus) 3.2.1.1: Analyse complète de la sécurité de votre réseau.

## 5. Installation et configuration

<figure><img src="image_56.png" /></figure>

Nessus Installation &
Configuration

Tenable
YouTube - 4 avr. 2012

<figure><img src="image_57.png" /></figure>

How To Install &
Configure Nessus In
Windows

My I.T
YouTube - 29 oct. 2017

<figure><img src="image_58.png" /></figure>

Video: Tenable
Appliance Installation &
Configuration - Blog

Tenable
Tenable - 4 nov. 2009
<figure><img src="image_59.png" /><figcaption>Nessus - Tutorial 1 -
Installation Guide</figcaption></figure>

Jenko022
YouTube - 17 juil. 2014

<figure><img src="image_60.png" /><figcaption>Nessus Installation &
Configuration</figcaption></figure>

Tenable
YouTube - 4 avr. 2012

<figure><img src="image_61.png" /><figcaption>How to Install Nessus
Vulnerability Scanner on
Windows | 26 January</figcaption></figure>

Rahul Tyagi
YouTube - 26 janv. 2016

6. UTILISATION NESSUS
<figure><img src="image_62.png" /></figure>

NATIXIS

Cockpit 1.15

MSCHALON

<figure><img src="image_63.png" /></figure>

<figure><img src="image_64.png" /></figure>

<figure><img src="image_65.png" /></figure>

<figure><img src="image_66.png" /></figure>

<figure><img src="image_67.png" /></figure>

<figure><img src="image_68.png" /></figure>

<figure><img src="image_69.png" /></figure>

Florant Amiot

INVENTAIRE

GESTION

OUTILS

INTEGRATION

ADMINISTRATION

3 utilisateurs connectés

about

export

impression

<figure><img src="image_70.png" /></figure>

Une exception a été définie par faraïok adive depuis le
20 09 10 07 08
## Présentation

Nessus est un scanneur de failles de sécurité, son but est de détecter rapidement les faiblesses d'une machine, que ce soit des failles permettant à une personne malintentionnée de prendre le contrôle de la machine ou simplement la présence d'un mot de passe par défaut...De plus, Nessus est le leader sur le marché de la sécurité informatique, dans le domaine de la détection de failles.

Le principe de Nessus est assez simple, il exécute tout d'abord un scan des ports ouvert, comme NMAP, cependant par la suite il exécute un script optimisé pour la détection des failles. Ce script est modifié par la configuration de Nessus et par les multiples plugins que l'on peut lui ajouter. Chaque plugin fournissant un degré de sécurité plus élevé.

Enfin Nessus peut, dans des cas précis, et suivant la configuration donnée exécuter des tentatives de crash de la machine, ainsi que des attaques de mot de passe par dictionnaire ou Brute Force.

## Installation

On installe le fichier rpm contenant Nessus version 3.05 à l'aide de cette commande :

```
rpm -ivh Nessus-3.05-fc6.i386.rpm
```

Lancement du programme « serveur » :

Nessus crée un processus, ce processus doit être activé à l'aide de cette commande :

```
/opt/nessus/sbin/nessus -D
```

## Enregistrement

Nessus n'étant pas open source, il est demandé de s'enregistrer avec une clef que l'on peut demander gratuitement sur le site officiel : http://www.nessus.org/

```
# /opt/nessus/bin/nessus-fetch --register 0F1C-9C27-171A-A76E-075B
```

## Mise à jour des plugins

Afin de télécharger les mises à jour du programme et de ses nouveaux plugins, vous devez être enregistré. De plus si vous souhaitez exécuter la mise à jour manuellement vous devez exécuter la commande suivante :

```
/opt/nessus/sbin/nessus-update-plugins
```

Cependant, Nessus possède un module permettant de vérifier d'éventuelles mises à jour à l'aide d'un planificateur de tâches, nous verrons cela par la suite.
## Configuration de Nessus

Afin de procéder à la configuration de Nessus, nous devons ouvrir le fichier nessusd.conf, pour cela vous devrez être connecté en root :

```
vi /opt/nessus/etc/nessus/nessusd.conf
```

Le fichier de configuration étant par défaut bien configuré pour un utilisateur « normal », nous vous présenterons uniquement quelques parties pouvant vous être utiles :

Par exemple la mise à jour des plugins :

```
# Automatic plugins updates - if enabled and Nessus is registered, then
# fetch the newest plugins from plugins.nessus.org automatically
auto_update = yes
# Number of hours to wait between two updates
auto_update_delay = 24
```

Ici nous autorisons la mise à jour (auto_update=yes). Cette mise à jour aura lieu toutes les 24 heures.

Il vous est possible de choisir le pseudo de la personne pouvant se connecter à distance à Nessus afin d'exécuter des mises à jour. De plus, vous pouvez changer les extensions des plugins à télécharger. (Il n'est généralement pas nécessaire de les modifier)

```
# Can users upload their plugins ?
plugin_upload = yes
# Suffixes of the plugins the user can upload :
plugin upload suffixes = .nasl, .nasl3, .inc, .inc3, .nbin, .audit
# Name of the user who can remotely update the plugins
admin_user = root
```

De plus, il est possible de forcer l'utilisation d'un certificat afin de garantir la sécurité d'accès à Nessus. Eventuellement, vous pouvez générer vos propres certificats afin d'identifier une seule machine capable de s'identifier à nessus.

```
# Added by nessus-mkcert
#
cert_file=/opt/nessus/com/nessus/CA/servercert.pem
key_file=/opt/nessus/var/nessus/CA/serverkey.pem
cac file=/opt/nessus/com/nessus/CA/cacert.pem
# If you decide to protect your private key with a password,
# uncomment and change next line
# pem_password=password
# If you want to force the use of a client certificate, uncomment next line
# force_pubkey_auth = yes
```
## Le Client distant

Installation :

Il est possible de vous connecter à distance sur Nessus, pour cela vous devrez disposer du client Nessus. Afin d'installer ce client vous devrez exécuter la commande :

Apt-get install nessus

Ensuite vous pourrez exécuter le client :

/usr/bin/nessus

Attention, Vous devez obligatoirement ouvrir le port 1241 en TCP sur votre firewall du serveur, sinon vous ne pourrez y accéder de l'extérieur.

## Interface Graphique

<figure><img src="image_71.png" /></figure>

Lors du lancement de Nessus, vous devrez inscrire l'IP du serveur ainsi que vos logins et mot de passe, puis vous cliquerez sur Log in pour tenter de vous connecter.

Lorsque vous serez connecté, vous aurez accès à l'onglet Plugins :
<figure><img src="image_72.png" /></figure>

C'est dans cet onglet que vous configurerez le scanneur de failles. L'option « Silent Dependencies » permet d'éviter l'affichage des bruits du réseau lors du rapport final.

L'option « Enable dependencies at runtime » permet à Nessus d'automatiquement activer les dépendances nécessaires au bon fonctionnement de vos plugins.

Dans notre cas nous avons choisi de tester Toutes les failles que nous avions. Afin d'obtenir l'aide détaillée d'une faille, il suffit de cliquer sur cette dernière.

Vous aurez alors par exemple la fenêtre suivante pour la faille AIX 5.1 : IY19744 :

On peut noter le nom de la faille, le numéro du plugins de Nessus ainsi que les révisions et l'explication de l'attaque en cas de succès. De plus, vous aurez bien sûr la solution attachée à cette attaque ainsi qu'une évaluation du risque. Ici cette attaque possède un Risque élevé.

<figure><img src="image_73.png" /></figure>
L'onglet suivant : Credentials :

C'est ici que vous choisirez vos options de connections, ssh, Kerberos ..., ces dernières sont facultatives.

<figure><img src="image_74.png" /></figure>

L'onglet suivant : Credentials :

C'est ici que vous choisirez vos options de connections, ssh, Kerberos ..., ces dernières sont facultatives.

<figure><img src="image_75.png" /></figure>
L'onglet Scan options :

<figure><img src="image_76.png" /></figure>

Ici vous choisisrez les ports à scanner, le nombre de tests à exécuter au même moment ainsi que les types de scan de ports. De plus, vous pouvez par exemple utiliser l'option « Safe Checks » qui désactive les tests pouvant faire crasher la machine ciblée. A noter qu'il est possible d'ajouter NMAP comme scanneur de port à la liste ...

L'onglet « Target » :

<figure><img src="image_77.png" /></figure>

Cet onglet permet de choisir la ou les cibles à scanner, soit vous entrez un host ou une ip, soit un fichier contenant la liste des ip, ou encore vous pouvez utiliser les masques de réseaux, par exemple : 192.168.10.0/24. (Vous scannerez toutes les machines du réseau 192.168.10.X)

Vous avez de plus une option « Perform a DNS zone transfert » permettant d'obtenir tout les host appartenant au domaine de la cible.

Avant configuré la majeure partie de ce programme, vous pouvez lancer le scan en cliquant sur :
« Start the Scan ».
Voici un exemple de rapport de scan :

<table><thead><tr><th>Nessus Scan Report</th></tr></thead><tbody><tr><td>This report gives details on hosts that were tested and issues that were found. Please follow the recommended steps and procedures to eradicate these threats.</td></tr></tbody></table>

<table><thead><tr><th colspan="2">Scan Details</th></tr></thead><tbody><tr><td>Hosts which were alive and responding during test</td><td>1</td></tr><tr><td>Number of security holes found</td><td>4</td></tr><tr><td>Number of security warnings found</td><td>1</td></tr></tbody></table>

<table><thead><tr><th colspan="2">Host List</th></tr><tr><th>Host(s)</th><th>Possible Issue</th></tr></thead><tbody><tr><td>localhost</td><td>Security hole(s) found</td></tr><tr><td>[ return to top ]</td><td></td></tr></tbody></table>

<table><thead><tr><th colspan="3">Analysis of Host</th></tr><tr><th>Address of Host</th><th>Port/Service</th><th>Issue regarding Port</th></tr></thead><tbody><tr><td>localhost</td><td>swat (901/tcp)</td><td>Security notes found</td></tr><tr><td>localhost</td><td>snmp (25/tcp)</td><td>Security notes found</td></tr><tr><td>localhost</td><td>ssh (22/tcp)</td><td>Security notes found</td></tr><tr><td>localhost</td><td>nessus (1241/tcp)</td><td>Security notes found</td></tr><tr><td>localhost</td><td>https (443/tcp)</td><td>Security notes found</td></tr><tr><td>localhost</td><td>ipp (631/tcp)</td><td>Security notes found</td></tr><tr><td>localhost</td><td>netbios-ssn (139/tcp)</td><td>Security notes found</td></tr><tr><td>localhost</td><td>sunrpc (111/tcp)</td><td>Security notes found</td></tr><tr><td>localhost</td><td>http (80/tcp)</td><td>Security notes found</td></tr><tr><td>localhost</td><td>Microsoft-ds (445/tcp)</td><td>Security warning(s) found</td></tr><tr><td>localhost</td><td>ldap (389/tcp)</td><td>Security notes found</td></tr><tr><td>localhost</td><td>unknown (743/tcp)</td><td>Security notes found</td></tr><tr><td>localhost</td><td>sunrpc (111/udp)</td><td>Security notes found</td></tr><tr><td>localhost</td><td>nettcp (740/udp)</td><td>Security notes found</td></tr><tr><td>localhost</td><td>general/tcp</td><td>Security hole found</td></tr><tr><td>localhost</td><td>netbios-ns (137/tcp)</td><td>Security notes found</td></tr></tbody></table>

Ici nous voyons clairement qu'il y a des failles de sécurité, dont 4 importantes ! Ces failles sont de type : « general/tcp». La suite sera la liste des failles découvertes, ainsi que les moyens de les corriger, par exemple :
<table><thead><tr><th>Type</th><th>Port</th><th>Issue and Fix</th><th>Security Issues and Fixes: localhost</th></tr></thead><tbody><tr><td rowspan="2">Vulnerability</td><td rowspan="2">general/tcp</td><td>The remote host is missing the patch for the advisory FEDORA-2007-293 (gnome-python2-extras).</td><td></td></tr><tr><td>The gnome-python-extra package contains the source packages for additional Python bindings for GNOME. It should be used together with gnome-python.</td><td></td></tr><tr><td rowspan="2">Vulnerability</td><td rowspan="2">general/tcp</td><td>Update information:<br/>* Man Feb 26 2007 Matthew Barnes &lt;mbarnes redhat.com&gt; - 2.14.2-9.fc6<br/>- Rebuild against Firefox-1.5.0.10.</td><td></td></tr><tr><td>Solution: Get the newest Fedora Updates<br/>Risk factor: High<br/>Nessus ID: 24729</td><td></td></tr><tr><td rowspan="2">Vulnerability</td><td rowspan="2">general/tcp</td><td>The remote host is missing the patch for the advisory FEDORA-2007-291 (kernel).</td><td></td></tr><tr><td>The kernel package contains the Linux kernel (vminux), the core of any Linux operating system. The kernel handles the basic functions of the operating system: memory allocation, process allocation, device input and output, etc.</td><td></td></tr><tr><td rowspan="2">Vulnerability</td><td rowspan="2">general/tcp</td><td>Update Information:<br/>Updated to kernel 2.6.19.5 plus additional fixes:<br/>[0]http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.19.4<br/>[9]http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.19.5</td><td></td></tr><tr><td>CVE-2007-0772:<br/>Summary: The Linux kernel before 2.6.20.1 allows remote attackers to cause a denial of service (oops) via a crafted NFSACL 2 ACCESS request that triggers a free of an incorrect pointer.</td><td></td></tr><tr><td rowspan="2">Vulnerability</td><td rowspan="2">general/tcp</td><td>CVE-2006-5753:<br/>Summary: Unspecified vulnerability in the listattr system call in Linux kernel, when a 'bad inode' is present, allows local users to cause a denial of service (data corruption) and possibly gain privileges via unknown vectors.</td><td></td></tr><tr><td>Fixed broken SCSI CDRROM IOCTLs.<br/>Added Xen, which was missing from 1.2911.6.3</td><td></td></tr><tr><td>Vulnerability</td><td>general/tcp</td><td>Solution: Get the newest Fedora Updates</td><td></td></tr></tbody></table>

## III.3 TESTS D'INTRUSION AVEC LE SNORT

### Présentation

Snort est un système de détection d'intrusion à partir d'analyse du trafic en temps réel. Pour cela, il effectue des analyses de protocole, recherche/correspondance de contenu et peut être utilisé pour détecter une grande variété d'attaques et de sondes comme des dépassements de buffers, scans, attaques sur des CGI, sondes SMB, essai d'OS fingerprintings et d'autres. Lorsque Snort détecte une intrusion, il peut soit prévenir l'administrateur système par un message sms/mail/vocal, soit interdire tout trafic provenant de l'attaquant, soit interdire tout trafic d'une classe d'adresse.

Toutefois Snort nécessite d'être maintenu à jour régulièrement pour rester efficace. Pour obtenir une représentation visuelle, on pourra utiliser des paquets tels que SnortSnarf, ACID, sguil ou BASE (Basic Analysis and Security Engine).

Snort a trois fonctionnalités :

* Sniffer le réseau : permet d'observer les paquets qui circulent sur le réseau.

* Générer des fichiers logs : génère des fichiers de logs au lieu d'afficher à l'écran les paquets.

* Détecter les intrusions : permet de détecter des intrusions suivant des règles contenues dans des fichiers. Ces fichiers sont téléchargeables sur http://www.snort.org/pub-bin/downloads.cgi

Snort s'utilise en ligne de commande et possède de nombreuses options...
## Sniffer le réseau

Afficher les en-têtes de paquets TCP/IP
snort -v

Afficher les en-têtes de paquets IP, TCP/UDP/ICMP et les données
snort -vd

Pour afficher tous les paquets en transit sur l'interface eth0 :
snort -dvi eth0

```
03/30-23:01:37.323403 192.168.0.113:22 --> 82.242.68.85:1468
TCP TTL:64 TOS:0x10 ID:43060 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0xC5184FA2 Ack: 0xF09B7CDB Win: 0x53C0 TcpLen: 20
4B 64 58 7C 2D C7 7D 74 22 C9 F2 A0 AF F0 1C 5E KdX|-.]t"......^
10 7F 52 B8 C1 31 75 DF 35 E4 6F 62 C5 D1 48 E1 ..R..lu.5.ob..H.
E3 A0 0C 53 6C C4 8F 2D 55 EA 20 26 7C 6E 90 65 ...Sl..-U. &|n.e
A7 F4 C6 32 3A 35 AB 9B 12 26 81 88 AA 32 E6 31 ...2:5...&...2.1
F1 88 54 69 5C EB 6C 6C 9D 0E 97 F2 A7 A7 93 68 ..Ti\..ll.......h
...
78 DE 01 E9 BB EC 5D 97 18 1D 1E 37 53 66 66 C9 x......]....7Sff.
BD 7E 83 F1 37 97 83 DA 75 39 4E C1 F1 0A 93 58 .~..7...u9N....X
93 72 DC 2C F0 77 B0 29 D8 45 D2 A6 AB E7 54 76 .r.,.w.).E....Tv
D2 59 F1 CE .Y..

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
```

```
*** Caught Int-Signal

Snort received 339 packets
  Analyzed: 63(18.584%)
  Dropped: 120(35.398%)
  Outstanding: 156(46.018%)

 Breakdown by protocol:
  TCP: 63      (100.000%)
  UDP: 0       (0.000%)
  ICMP: 0       (0.000%)
  ARP: 0       (0.000%)
  EAPOL: 0      (0.000%)
  IPv6: 0      (0.000%)
  ETHLOOP: 0    (0.000%)
  IPX: 0       (0.000%)
  FRAG: 0      (0.000%)
  OTHER: 0     (0.000%)
  DISCARD: 0    (0.000%)

Action Stats:
ALERTS: 0
LOGGED: 0
PASSED: 0

Snort exiting
```
## Générer des logs

Renvoie la sortie de la commande dans un fichier log dans le répertoire log
snort -dev -l ./log

Voir le fichier de log
snort -dv -r ./log/snort.log.1175196590

Voir seulement les paquets icmp du fichier de log
snort -dv -r ./log/snort.log.1175196590 icmp

## Détecter des intrusions

Permet d'analyser et détecter des intrusions suivant des règles
snort -dev -l ./log -h 192.168.0.0/24 -c /etc/snort/snort.conf

```
Running in IDS mode

---- Initializing Snort ----
Initializing Output Plugins!
Var 'tun0_ADDRESS' defined, value len = 24 chars, value = 10.8.0.1/255.255.255.255
Var 'any_ADDRESS' defined, value len = 15 chars, value = 0.0.0.0/0.0.0.0
Var 'lo_ADDRESS' defined, value len = 19 chars, value = 127.0.0.0/255.0.0.0
Initializing Preprocessors!
Initializing Plug-ins!
```
## Install Snort 2.9.8 on Windows - YouTube

<figure><img src="image_78.png" /></figure>

https://www.youtube.com/watch?v=RwWM0srLSg0

10 mai 2016 - Ajouté par Steve Gantz

This video demonstrates installing, configuring, and testing the ... difference in the Snort program or rules ...

## 07 MISRSM2G2 Installation et configuration de Snort avec Barnyard2 ...

<figure><img src="image_79.png" /></figure>

https://www.youtube.com/watch?v=3aBNj-7cV_4

6 juin 2014 - Ajouté par IT-Systems

L'installation et la configuration de Prelude-IDS et de tous les paquetages qu'il utilise. La plateforme de ...

## SNORT Basic Installation and Configuration (Windows) (IDS/IPS) | EN ...

<figure><img src="image_80.png" /></figure>

https://www.youtube.com/watch?v=vYJ9Khqgo4M

18 nov. 2017 - Ajouté par Cybersecenv

Cybersecenv SOCIAL MEDIA | REDES SOCIALES Cybersecenv Facebook

official Website https://www ...

## Télécharger Snort - 01net.com - Telecharger.com

www.01net.com › Télécharger Windows › Utilitaires › Réseau

<figure><img src="image_81.png" /></figure>

Note : 3 - 1 vote

Snort est un puissant système de détection d'intrusion (NIDS) qui vous ... Pour fonctionner correctement, Snort requiert l'installation préalable de WinPcap, un outil de filtrage qui vous permet de capturer des trames IP dans un environnement Windows. ... peut rédiger ses propres règles via le fichier de configuration Snort.

<figure><img src="image_82.png" /><figcaption>### Install Snort 2.9.7 on Windows</figcaption></figure>

Steve Gantz
YouTube - 25 mars 2015

<figure><img src="image_83.png" /><figcaption>### Install Snort 2.9.8 on Windows</figcaption></figure>

Steve Gantz
YouTube - 10 mai 2016

<figure><img src="image_84.png" /><figcaption>### Setup Snort IDS on Windows 7</figcaption></figure>

Michael Singh
YouTube - 27 oct. 2010
### III.4 LA SURVEILLANCE ET ANALYSE DES JOURNAUX LOGS (journaux d'évènements)

#### II.4.1 LA SURVEILLANCE DES JOURNAUX LOGS

##### a) Généralité

La surveillance (gestion de logs) comprend une approche de la gestion de grands volumes des messages de log générés par l'ordinateur (aussi connu comme journaux d'évènements, journalisation, etc.). La gestion des logs concerne en général¹:

* La collecte des logs

* L'agrégation centralisée des logs

* Le stockage à long terme et la durée de rétention des logs

* La rotation des fichiers de logs

* L'analyse des logs (en temps réel et en vrac après une période de stockage)

* Les rapports et l'étude des logs.

Les principaux enjeux de l'implémentation de la gestion des logs concernent la sécurité², les opérations systèmes et réseaux et la conformité du système. Les logs sont générés par presque tous les appareils informatiques, et peut souvent être dirigé vers différents endroits à la fois locales, dans le système de fichiers ou à dans un système distant.

L'analyse effective de grands volumes de divers journaux peuvent poser de nombreux défis, tels que:

* La volume: les journaux/logs peuvent atteindre des centaines de giga-octets de données par jour pour une grande organisation. La collecte, la centralisation et le stockage de données à ce volume peut être difficile.

* Normalisation: les journaux sont produites dans de multiples formats. Le processus de normalisation est conçu pour fournir une sortie commune pour l'analyse de diverses sources.

* Vitesse: La vitesse à laquelle les journaux sont produites à partir de dispositifs peuvent rendre la collecte et l'agrégation difficile

* Véracité: Journal des événements peut ne pas être exacte. Cela est particulièrement problématique à partir de systèmes qui effectuent la détection, tels que les systèmes de détection d'intrusion.

Les utilisateurs et les utilisateurs potentiels de la gestion du journal peuvent acheter des d'outils propriétaires complets ou construire leur propre outil de gestion de logs et outils d'intelligence, ou bien utiliser un assemblage de composants open-sources, ou bien encore ou d'acquérir des (sous-)systèmes de fournisseurs commerciaux. La gestion des journalisations est un processus complexe et les organisations font souvent des erreurs dans leurs approches³.
## b) Surveillance de journaux Logs avec Syslog-ng

### Présentation

Syslog-ng est un gestionnaire de journaux système de nouvelle génération (ng), anciennement syslog. A partir de syslog-ng, on peut centraliser les journaux de l'ordinateur lui-même mais aussi ceux des postes du réseau sur lequel il est connecté et permet de les trier facilement. Ce paquet est indispensable pour les administrateurs réseaux qui souhaitent garder un œil sur les performances de leurs machines. Parmi les avantages on peut citer la portabilité (Linux, FreeBSD, HP-UX, Solaris ou AIX), la configuration de base très avancée, l'export des logs vers une base de données mysql, la possibilité de confirmer les logs envoyés via la technologie SSL, l'utilisation des protocoles UDP et TCP lors du transport des logs ou bien encore la possibilité de trier les logs suivant les contenus, leur provenance ou leur facilité, et ce en pouvant utiliser les expressions régulières.

Pour les postes clients sous linux il suffit de configurer syslog-ng pour que la destination soit l'ordinateur qui centralise les journaux dans le fichier de configuration syslog-ng.conf. Sous Windows il faut installer le logiciel Snare qui permet d'envoyer des trames syslog à la norme RFC.

### Installation

Dans un premier temps il faut configurer mysql :

```
mysql_install_db
mysql -u root -p mysql
```

On va pouvoir ensuite installer et configurer php-syslog-ng, on va d'abord télécharger l'archive contenant les pages php de php-syslog-ng sur le site http://www.phpwizardry.com/php-syslog-ng/phpsyslogng-2.8.tar.gz.

Pour l'installer on va exécuter les commandes suivantes :

```
tar -xvzf phpsyslogng-2.8.tar.gz /var/www/html/php-syslog-ng
chown -R apache:apache /var/www/html/php-syslog-ng
```

On peut maintenant créer les tables permettant de stocker et ordonner les logs. Avant d'exécuter le script de configuration, il faut l'ouvrir et remplacer toutes les occurrences de PW_HERE par le mot de passe que l'on souhaite utiliser pour se connecter à l'interface :

```
mysql -uroot -p < dbsetup.sql
mysql -u root -p
> SET PASSWORD FOR syslogfeeder@localhost = PASSWORD('syslogfeederpassword');
> SET PASSWORD FOR syslogadmin@localhost = PASSWORD('syslogadminpassword');
```

Le script dbsetup.sql fourni avec le paquet php-syslog-ng est bien utile pour faire cela.
Ensuite il faut configurer syslog-ng pour qu'il rajoute les informations dans la base de données, pour cela on va rajouter dans le fichier `/etc/syslog-ng/syslog-ng.conf` les lignes suivantes :

```ini
destination d_mysql {
    pipe("/var/log/mysql.pipe")
    template("INSERT INTO logs
             (host, facility, priority, level, tag, datetime, program, msg)
             VALUES ('$HOST', '$FACILITY', '$PRIORITY', '$LEVEL', '$TAG', '$YEAR-$MONTH-$DAY
             $HOUR:$MIN:$SEC',
             '$PROGRAM', '$MSG');\n") template-escape(yes));
};
```

Il s'agit d'un nouveau champ destination permettant de rediriger les logs vers la base de données logs. Pour que l'ajout soit fait il faut rajouter un champ log qui va récupérer les données à partir de la source et les rediriger vers la destination. Nous avons ajouté le champ destination et le champ source doit déjà être présent dans le fichier de configuration de syslog-ng :

```json
log {
    source(s_sys);
    destination(d_mysql);
};
```

Pour Ferdora, il faut remplacer `s_all` de l'exemple fourni par `s_sys`.

Pour recevoir les logs des machines distantes sur le réseau, il faut décommenter la ligne « `udp()` ».

Le script `syslog2mysql.sh` qui est fourni dans le paquet `php-syslog-ng` permet de créer un fichier `pipe` FIFO pour remplir la base de données :

```bash
#!/bin/bash

if [ ! -e /var/log/mysql.pipe ]
then
    mkfifo /var/log/mysql.pipe
fi

while [ -e /var/log/mysql.pipe ]
do
    mysql -u syslogfeeder --password=PASS_HERE syslog < /var/log/mysql.pipe >/dev/null
done
```

Il faut bien sûr modifier l'avant dernière ligne de ce fichier en remplaçant `PASS_HERE` par le mot de passe que vous avez spécifié plus haut.

Pour exécuter ce script il faut le copier dans le fichier de démarrage de syslog-ng :

Il faut bien sûr modifier l'avant dernière ligne de ce fichier en remplaçant `PASSici HERE` par le mot de passe que vous avez spécifié plus haut.

Pour exécuter ce script il faut le copier dans le fichier de démarrage de syslog-ng :

```perl
start() {
    echo -n "$"Starting $prog:"
    daemon $exec $SYSLOGNG_OPTIONS
    $retval=$?
    echo
    [ $retval -eq 0 ] && touch $lockfile
    return $retval
}
# script permettant d'insérer les données dans la base de données mysql
/var/www/html/php-syslog-ng/scripts/syslog2mysql.sh
}
```
Par mesure de sécurité nous allons interdire l'accès aux fichiers scripts, includes et de configuration à partir d'un navigateur web, pour cela nous allons rajouter dans le fichier de configuration du serveur web Apache (sous Fedora /etc/httpd/conf/httpd.conf) les lignes suivantes :

```
<Directory "/var/www/phpsyslogng/scripts">
    Deny from all
</Directory>
```

```
<Directory "/var/www/phpsyslogng/includes">
    Deny from all
</Directory>
```

```
<Directory "/var/www/phpsyslogng/config">
    Deny from all
</Directory>
```

## Utilisation

<figure><img src="image_85.png" /></figure>

La page d'accueil de `phpsyslog-ng` permet de choisir ce que l'on veut afficher. On peut ainsi sélectionner les postes distants que l'on veut afficher ou non, les types de logs à afficher, en fonction du niveau d'erreur ou de la date...
<figure><img src="image_86.png" /></figure>

La capture d'écran si dessus montre comment sont affichées les informations : numéro d'entrée, le poste, le type de logs avec le niveau d'erreur suivant la couleur, la date et l'heure et enfin le message associé.
## III.2 ANALYSEUR DES JOURNAUX D'EVENEMENTS (LOG) AWSTATS

### Présentation

Awstats est un outil gratuit, puissant et très fonctionnel qui fournit des statistiques graphiques de serveurs web, de streaming, ftp ou de mail. Cet analyseur de fichiers logs fonctionne en tant que CGI ou en ligne de commande et résume toutes les informations contenues dans ces fichiers sur des graphiques. Il sait lire les fichiers logs de la majorité des serveurs web tel que Apache (NCSA combined/XLF/ELF log format or common/CLF log format), WebStar, IIS (W3C log format) et d'autres serveurs web, proxy, streaming, mail et ftp.

<table><thead><tr><th>Caractéristiques/Logiciels</th><th>AWStats</th><th>Analog</th><th>Webalizer</th></tr></thead><tbody><tr><td>Version - Date</td><td>6.5 - Décembre 2005</td><td>6.0 - Décembre 2004</td><td>2.01-10 - Avril 2002</td></tr><tr><td>Langage</td><td>Perl</td><td>C</td><td>C</td></tr><tr><td>Plateformes</td><td colspan="3">UNIX/Windows</td></tr><tr><td>Sources disponibles</td><td colspan="3">Oui</td></tr><tr><td>Prix/License</td><td colspan="3">Gratuit/GPL</td></tr><tr><td>Format Apache combined</td><td colspan="3">Oui</td></tr><tr><td>Format Apache common</td><td colspan="3">Quelques fonctionnalités</td></tr><tr><td>Format IIS (W3C)</td><td>Oui</td><td colspan="2">Avec un patch</td></tr><tr><td>Format personnalisé</td><td>Oui</td><td colspan="2">Non</td></tr><tr><td>Web/Ftp/Mail log</td><td>Oui/oui/oui</td><td colspan="2">Oui/non/non</td></tr></tbody></table>

### Configuration

#### Step 1

Lancer le script `awstats�ure.pl` (dans le répertoire `/usr/bin` sous Gentoo et dans `/usr/share/awstats/tools/awstats_pure.pl` sous fedora) comme ceci:

```
perl awstats_pure.pl
```

Vérifier les points suivant dans `httpd.conf`

* CustomLog /yourlogpath/yourlogfile combined (au lieu de common)

* Utilisation à partir du site web

#

# Directives to add to your Apache conf file to allow use of AWStats as a CGI.

# Note that path "/usr/local/awstats/" must reflect your AWStats Installation path.

#

Alias /awstatsclasses "/usr/local/awstats/wwwroot/classes/"

Alias /awstatscss "/usr/local/awstats/wwwroot/css/"

Alias /awstatsicons "/usr/local/awstats/wwwroot/icon/"

ScriptAlias /awstats/ "/usr/local/awstats/wwwroot/cgi-bin/"

#

# This is to permit URL access to scripts/files in AWStats directory.
#
<Directory "/usr/local/awstats/wwwroot">
  Options None
  AllowOverride None
  Order allow,deny
  Allow from all
</Directory>

Dans Gentoo on /usr/share/webapps/awstats/6.5-r2/ docs/ au lieu de /usr/local/awstats/wwwroot/ et /usr/share/webapps/awstats/6.5-r2/ hostroot/ cgi-bin au lieu de /usr/local/awstats/wwwroot/cgi-bin

Redémarrer Apache

/etc/init.d/apache2 restart

Step 2

Après avoir créé le awstats.mon.site.conf (dans /etc/awstats sous linux Gentoo) il est nécessaire de
vérifier certains points dans ce fichier:

➤ **LogFile**: chemin relatif des logs du serveur

* **LogType**: W pour analyser les fichiers logs web

* **LogFormat**: 1 pour (pour "NCSA apache combined/ELF/XLF log format") ou utiliser un autre format (http://awstats.sourceforge.net/docs/awstats_config.html#LogFormat)

* **SiteDomain**: nom de domaine du site (www.mon.site.com)

Step 3

Il faut ensuite exécuter la commande suivante (sous Gentoo awstats.pl se trouve dans
/usr/share/webapps/awstats/6.5-r2/hostroot/cgi-bin/):

perl awstats.pl -config=mon.site –update

On devrait alors obtenir :

Update for config "/etc/awstats/awstats.mysite.conf"
With data in log file "/pathtoyourlog/yourlog.log"...
Phase 1: First bypass old records, searching new record...
Searching new records from beginning of log file...
Phase 2 : Now process new records (Flush history on disk after 20000 hosts)...
Jumped lines in file: 0
 lines in file: 225730
Found 122 dropped records,
Found 87 corrupted records,
Found 0 old records,
Found 225521 new qualified records.

Utilisation

http://www.mon.site/awstats/awstats.pl?config=mon.site

Si le paramètre AllowToUpdateStatsFromBrowser est positionné à 1 dans awstats.mon.site.conf il sera
possible de mettre à jour les informations à partir du site web.
<figure><img src="image_87.png" /></figure>

Comme le montre la capture d'écran d'Internet Explorer 7, Awstats fournit dans un navigateur les statistiques graphiques du serveur web de notre machine. Sur la gauche, un menu permet d'accéder aux sous rubriques : Résumé, Historique mensuel, Historique hebdomadaire, Historique journalier, Heures, Pays des visiteurs, Hôtes, Durées de visite, Types de fichier, Pages les plus visitées, Systèmes d'exploitation, Navigateurs...
# CHAP.IV LES NORMES ET METHODES DE SECURITE INFORMATIQUE

## Introduction

La sécurité du système d'information d'une entreprise est un requis important pour la poursuite de ses activités. Qu'il s'agisse de la dégradation de son image de marque, du vol de ses secrets de fabrication ou de la perte de ses données clients ; une catastrophe informatique a toujours des conséquences fâcheuses pouvant aller jusqu'au dépôt de bilan.

Organiser cette sécurité n'est pas chose facile, c'est pourquoi il existe des méthodes reconnues pour aider les responsables informatiques à mettre en place une bonne politique de sécurité et à procéder aux audits permettant d'en vérifier l'efficacité.

Le but de ce document n'est pas d'expliquer comment concevoir une politique de sécurité mais de présenter les méthodes existantes.

### A. Politique de sécurité

Une politique de sécurité peut être vue comme l'ensemble des modèles d'organisation, des procédures et des bonnes pratiques techniques permettant d'assurer la sécurité du système d'information.

Mais qu'est-ce que la sécurité d'un SI ? Elle tourne autour des 5 principaux concepts suivants : l'intégrité des données, la confidentialité de l'information et des échanges, la disponibilité des services, l'authentification des utilisateurs et la non répudiation des transactions.

Pour garantir la sécurité, une politique de sécurité est généralement organisée autour de 3 axes majeurs : la sécurité physique des installations, la sécurité logique du système d'information et la sensibilisation des utilisateurs aux contraintes de sécurité.

### B. Audit

Un audit de sécurité permet de mettre en évidence les faiblesses de la mise en œuvre d'une politique de sécurité. Le problème peut venir de la politique elle-même : mal conçue ou inadaptée aux besoins de l'entreprise, ou bien d'erreurs quand à sa mise en application.

Des audits sont nécessaires : suite à la mise en place initiale d'une politique de sécurité, puis régulièrement pour s'assurer que les mesures de sécurité sont mises à niveau et que les usages restent conformes aux procédures.

## II. Comparatif des normes

Le tableau suivant liste les principales normes utilisées provenant des organismes de normalisation internationaux ainsi que celles soutenues par le secteur privé ou associatif :
<table><thead><tr><th>Méthode</th><th>Création</th><th>Popul arité</th><th>Auteur</th><th>Soutenue par</th><th>Pays</th><th>Outils disponibles</th><th>Etat</th></tr></thead><tbody><tr><td>EBIOS</td><td>1995</td><td>***</td><td>DCSSI</td><td>gouvernement</td><td>France</td><td>logiciel gratuit</td><td></td></tr><tr><td>Melisa</td><td></td><td>**</td><td>DGA</td><td>armement</td><td>France</td><td></td><td>abandonné e</td></tr><tr><td>Marion</td><td>1980</td><td>**</td><td>CLUSIF</td><td>association</td><td>France</td><td></td><td>abandonné e</td></tr><tr><td>Mehari</td><td>1995</td><td>***</td><td>CLUSIF</td><td>association</td><td>France</td><td>logiciel Risicare</td><td></td></tr><tr><td>Octave</td><td>1999</td><td>**</td><td>Université de Carnegie Mellon</td><td>universitaire</td><td>Etats-Unis</td><td>logiciel payant</td><td></td></tr><tr><td>Cramm</td><td>1986</td><td>**</td><td>Siemens</td><td>gouvernement</td><td>Angleterre</td><td>logiciel payant</td><td></td></tr><tr><td>SPRINT</td><td>1995</td><td>*</td><td>ISF</td><td>association</td><td>Angleterre</td><td>logiciel payant</td><td></td></tr><tr><td>BS 7799</td><td></td><td>***</td><td></td><td>gouvernement</td><td>Angleterre</td><td></td><td></td></tr><tr><td>ISO 17799</td><td></td><td>***</td><td></td><td>international</td><td></td><td></td><td></td></tr><tr><td>ISO 13335</td><td></td><td></td><td></td><td>international</td><td></td><td></td><td></td></tr><tr><td>ISO 15408</td><td></td><td></td><td></td><td>international</td><td></td><td></td><td></td></tr><tr><td>SCORE</td><td>2004</td><td></td><td>Ageris Consulting</td><td>secteur privé</td><td>France</td><td>logiciel payant</td><td></td></tr><tr><td>CALLIO</td><td>2001</td><td></td><td>CALLIO</td><td>secteur privé</td><td>Canada</td><td>logiciel payant</td><td></td></tr><tr><td>COBRA</td><td>2001</td><td></td><td>Technologies C &amp; A Systems Security Limited</td><td>secteur privé</td><td>Angleterre</td><td>logiciel payant</td><td></td></tr><tr><td>ISAMM</td><td>2002</td><td></td><td>Evosec</td><td>secteur privé</td><td>Belgique</td><td></td><td></td></tr><tr><td>RA2</td><td>2000</td><td></td><td>aaxis</td><td>secteur privé</td><td>Allemane</td><td>logiciel payant</td><td></td></tr></tbody></table>

En ce qui concerne les normes de sécurité des SI, la famille de normes ISO 27000 constitue un véritable espoir pour les RSSI dans la mesure où elle apporte une aide indéniable dans la définition, la construction et la déclinaison d'un SMSI efficace à travers une série de normes dédiées à la sécurité de l'information :
**§ ISO/CEI 27001** : système de Gestion de la Sécurité de l'Information (ISMS) - Exigences ;

**§ ISO/CEI 27002** : code de bonnes pratiques pour la gestion de la sécurité de l'information (anciennement ISO/CEI 17799) ;

**§ ISO/CEI 27003** : système de Gestion de la Sécurité de l'Information (ISMS) - Guide d'implémentation ;

**§ ISO/CEI 27004** : mesure de la gestion de la sécurité de l'information ;

**§ ISO/CEI 27005** : gestion du risque en sécurité de l'information ;

**§ ISO/CEI 27006** : exigences pour les organismes réalisant l'audit et la certification de Systèmes de Gestion de la Sécurité de l'Information (ISMS) ;

**§ ISO/CEI 27007** : guide pour l'audit de Systèmes de Gestion de la Sécurité de l'Information (ISMS).

# III. Présentation des principales normes

Seront abordées ici les principales méthodes employées en Europe et en Amérique du Nord.

## A. EBIOS

EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) permet d'identifier les risques d'un SI et de proposer une politique de sécurité adaptée aux besoin de l'entreprise (ou d'une administration). Elle a été créée par la DCSSI (Direction Centrale de la Sécurité des Systèmes d'Information), du Ministrère de la Défence (France). Elle est destinée avant tout aux administrations françaises et aux entreprises.

La méthode EBIOS se compose de 5 guides (Introduction, Démarche, Techniques, Outillages) et d'un logiciel permettant de simplifier l'application de la méthodologie explicitée dans ces guides. Le logiciel libre et gratuit (les sources sont disponibles) permet de simplifier l'application de la méthode et d'automatiser la création des documents de synthèse. La DCSSI possède un centre de formation où sont organisés des stages à destination des organismes publics français. Un club d'utilisateurs EBIOS a été créé en 2003 et constitue une communauté experts permettant le partage des expériences. Une base de connaissances à laquelle se connecte le logiciel EBIOS permet d'avoir à accès à la description d'un ensemble de vulnérabilités spécifiques, de contraintes de sécurité, de méthodes d'attaques. Elle peut être enrichie via le logiciel.

La méthode EBIOS est découpée en 5 étapes :

Les 5 étapes de la méthode EBIOS

1. étude du contexte
2. expression des besoins de sécurité

3. étude des menaces

4. identification des objectifs de sécurité

5. détermination des exigences de sécurité

<figure><img src="image_88.png" /></figure>

## Démarche EBIOS globale

L'étude du contexte permet d'identifier quel système d'information est la cible de l'étude. Cette étape délimite le périmètre de l'étude : présentation de l'entreprise, architecture du système d'information, contraintes techniques et réglementaires, enjeux commerciaux. Mais est aussi étudié le détail des équipements, des logiciels et de l'organisation humaine de l'entreprise.

L'expression des besoins de sécurité permet d'estimer les risques et de définir les critères de risque. Les utilisateurs du SI expriment durant cette étape leurs besoins de sécurité en fonction des impacts qu'ils jugent inacceptables.

L'étude des menaces permet d'identifier les risques en fonction non plus des besoins des utilisateurs mais en fonction de l'architecture technique du système d'information. Ainsi la liste des vulnérabilités et des types d'attaques est dressée en fonction des matériels, de l'architecture réseau et des logiciels employés. Et ce, quelles que soient leur origine (humaine, matérielle, environnementale) et leur cause (accidentelle, délibérée).

L'identification des objectifs de sécurité confronte les besoins de sécurité exprimés et les menaces identifiées afin de mettre en évidence les risques contre lesquels le SI doit être protégé. Ces objectifs vont former un cahier des charges de sécurité qui traduira le choix fait sur le niveau de résistance aux menaces en fonction des exigences de sécurité.

La détermination des exigences de sécurité permet de déterminer jusqu'où on devra aller dans les exigences de sécurité. Il est évident qu'une entreprise ne peut faire face à tout type de risques, certains doivent être acceptés afin que le coût de la protection ne soit pas exorbitant.
C'est notamment la stratégie de gestion du risque tel que cela est défini dans un plan de risque qui sera déterminé ici : accepter, réduire ou refuser un risque. Cette stratégie est décidée en fonction du coût des conséquences du risque et de sa probabilité de survenue. La justification argumentée de ces exigences donne l'assurance d'une juste évaluation.

EBIOS fournit donc la méthode permettant de contruire une politique de sécurité en fonction d'une analyse des risques qui repose sur le contexte de l'entreprise et des vulnérabilités liées à son SI.

## B. Melisa

Melisa (Méthode d'évaluation de la vulnérabilité résiduelle des systèmes d'information) fut inventée par Albert Harari au sein de la ⬒ Direction Générale de l'Armement (DGA/DCN) en France. Elle a été rachetée par la société CF6 qui en a fait la promotion pendant de nombreuses années. Depuis le rachat de CF6 par 📞 Telindus, Melisa a été abandonnée par ses propriétaires bien qu'elle fut largement utilisée en France.

Melisa est une méthode assez lourde basée sur un thésaurus de questions. Elle a vocation à être utilisée par de grandes entreprises.

En raison de son abandon, cette méthode ne sera pas traitée ici.

## C. Marion

Marion (Méthodologie d'Analyse de Risques Informatiques Orientée par Niveaux) a été développée par le CLUSIF dans les années 1980 mais a été abandonnée en 1998 au profit de la méthode Mehari. C'est une méthode d'audit de la sécurité d'une entreprise, elle ne permet pas de mettre en oeuvre une politique de sécuritée en tant que tel. A base d'un questionnaire, elle donne une évaluation chiffrée du risque informatique.

Marion repose sur l'évaluation des aspects organisationnels et techniques de la sécurité de l'entreprise à auditer.

Elle utilise 27 indicateurs classés en 6 thématiques. Chaque indicateur se voit attribuer une note entre 0 (insécurité) et 4 (excellent), la valeur 3 indiquant une sécurité correcte.

Thématiques des indicateurs de la méthode Marion

* Sécurité organisationnelle

* Sécurité physique

* Continuité

* Organisation informatique

* Sécurité logique et exploitation

* Sécurité des applications

La méthode se déroule en 4 phases :

Phases de la méthode Marion
1. Préparation

2. Audit des vulnérabilités

3. Analyse des risques

4. Plan d'action

La phase de préparation permet de définir les objectifs de sécuriter à atteindre ainsi que le champs d'action de l'audit et le découpage fonctionnel du SI à adopter pour simplifier la réalisation de l'étude.

L'audit des vulnérabilités consiste à répondre aux questionnaires. Ces réponses données vont permettre de recenser les risques du SI et les contraintes de l'entreprise. A l'issu de cet audit, sont construits une rosace et un diagramme différentiel représentant respectivement la note attribuée à chacun des indicateurs et les facteurs de risques particulièrement importants.

<figure><img src="image_89.png" /><figcaption>Exemple de rosace Marion</figcaption></figure>

La rosace présente dans un cercle la valeur de chacun des 27 indicateurs. Elle est un moyen de visualiser rapidement les points vulnérables du SI qui doivent être mieux protégés.

<figure><img src="image_90.png" /><figcaption>Exemple d'histogramme différentiel Marion</figcaption></figure>

L'histogramme différentiel est construit avec des barre représentant l'éloignement de chaque valeur d'indicateur à la valeur de référence 3. Cet éloignement est pondéré avec l'importance donné au facteur mesuré. Les indicateurs de valeur égale ou supérieur à 3 ne sont pas représentés. On visualise ainsi les vulnéralités du SI en fonction de leur criticités relatives.

L'analyse des risques permet de classer les risques selon leur criticité (en classes : Risques Majeurs et Risques Simples). Elle procède au découpage fonctionnel du SI pour une analyse
détailée des menaces, de leur impact respectif et de leur probabilité. La méthode Marion définit 17 types de menaces :

## Types de menaces Marion

* Accidents physiques

* Malveillance physique

* Carence de personnel

* Carence de prestataire

* Panne du SI

* Interruption de fonctionnement du réseau

* Erreur de saisie

* Erreur de transmission

* Erreur d'exploitation

* Erreur de conception / développement

* Détournement de fonds

* Détournement de biens

* Vice caché d'un progiciel

* Copie illicite de logiciels

* Indiscrétion / détournement d'information

* Sabotage immatériel

* Attaque logique du réseau

Le **plan d'action** propose les solutions à mettre en oeuvre pour élever la valeur des 27 indicateurs à la valeur 3 (niveau de sécurité satisfaisant) de l'audit des vulnérabilités et atteindre les objectifs fixés en préparation. Le coût de la mise à niveau est évalué et les tâches à réaliser pour y parvenir sont ordonnancées.

Cette méthode par questionnaire est assez simple à mettre oeuvre et est bien rodée du fait de son âge. Son pouvoir de comparaison des entreprises auditées est un plus indéniable.

La méthode Mehari qui lui succède va plus loin en proposant la création complète de la politique de sécurité.

## D. Mehari

Mehari (MEthode Harmonisée d'Analyse de RISques) est développée par le CLUSIF depuis 1995, elle est dérivée des méthodes Melisa et Marion. Existant en langue française et en anglais, elle est utilisée par de nombreuses entreprises publiques ainsi que par le secteur privé.

Le logiciel **RISICARE** développé par la société BUC SA est un outil de gestion des risques basé sur la méthode Mehari.

La démarche générale de Mehari consiste en l'analyse des enjeux de sécurité : quels sont les scénarios redoutés ?, et en la classification préalable des entités du SI en fonction de trois critères de sécurité de base (confidentialité, intégrité, disponibilité). Ces enjeux expriment les
dysfonctionnements ayant un impact direct sur l'activité de l'entreprise. Puis, des audits identifient les vulnérabilités du SI. Et enfin, l'analyse des risques proprement dite est réalisée.

<figure><img src="image_91.png" /></figure>

Schéma général de la méthode Mehari

Mehari s'articule autour de 3 types de livrables :

## Plans de la méthode Mehari

1. le Plan Stratégique de Sécurité (PSS)

2. les Plans Opérationnels de Sécurité (POS)

3. le Plan Opérationnel d'Entreprise (POE)

Le **Plan Stratégique de Sécurité** fixe les objectifs de sécurité ainsi que les métriques permettant de les mesurer. C'est à ce stade que le niveau de gravité des risques encourus par l'entreprise est évalué. Il définit la politique de sécurité ainsi que la charte d'utilisation du SI pour ses utilisateurs.

Les **Plans Opérationnels de Sécurité** définissent pour chaque site les mesures de sécurité qui doivent être mises en oeuvre. Pour cela, ils élaborent des scénarios de compromission et audite les services du SI. Sur la base de cet audit, une évaluation de chaque risque (probabilité, impact) est réalisée permettant par la suite d'exprimer les besoins de sécurité, et par la même les mesures de protections nécessaires. Enfin, une planification de la mise à niveau de la sécurité du SI est faite.

Le **Plan Opérationnel d'Entreprise** assure le suivi de la sécurité par l'élaboration d'indicateurs sur les risques identifiés et le choix des scénarios de catastrophe contre lesquels il faut se prémunir.
Des bases de connaissances permettent d'automatiser certains calculs de gravité des scénarios de risques, proposent des liens entre menaces et parades...

Mehari apporte une démarche centrée sur les besoins de continuité d'activité de l'entreprise et fournit des livrables types aidés d'un guide méthodologie. Les audits qu'elle propose permettent la création de plan d'actions concrets. Cette méthode permet donc de construire une politique de sécurité destinée à pallier les vulnérabilités constatées lors des audits du *Plans Opérationnels de Sécurité* et d'atteindre le niveau de sécurité correspondant aux objectifs fixés dans le *Plan Stratégique de Sécurité*.

## E. Octave

Octave (Operationally Critical Threat, Asset, and Vulnerability Evaluation) a été créé par l'université de Carnegie Mellon (Etats-Unis) en 1999. L'université de Carnegie Mellon est le centre de coordination des CERT. Octave est destinée aux grandes entreprises, mais depuis peu une version adaptée aux petites structures existe : Octave-S. Elle a pour but de permettre à une entreprise de réaliser par elle-même l'analyse des risques de leur SI, sans aide extérieure (consultants). Pour cela, un catalogue de bonnes pratiques de sécurité est fourni avec la méthode.

Octave est contitué de 3 phases :

Phases de la méthode Octave

1. vue organisationnelle

2. vue technique

3. stratégie de sécurité

<figure><img src="image_92.png" /></figure>

Phases de la méthode Octave

La vue organisationnelle permet d'identifier les actifs de l'entreprise, les menaces qui pè sent sur son fonctionnement, les vulnérabilités de son organisation, les objectifs de sécurité imposés par la direction et les mesures actuelles de sécurité. Ce sont trois processus de collecte de l'information qui sont réalisés durant cette phase, chacun par une population particulière : les cadres supérieurs, les cadres opérationnels et les équipes de production. La consolidation des informations nées de ces processus amène à créer des profils de menaces.
La vue technique identifie les éléments essentiels de chaque actif identifié plus haut et les audite afin d'en connaître les vulnérabilités.

Le développement de la **stratégie de sécurité** consiste à évaluer les risques identifiés (impact, probabilité) plus haut et à proposer les mesures permettant de les réduire. Un plan de réduction des risques est alors planifié.

La simplicité de la méthode Octave en fait dans le principe une méthode efficace, elle est assez répandue eux Etats-Unis et au Québec. Elle est centrée sur la protection des actifs de l'entreprise et le management du personnel. Elle couvre l'ensemble des processus métiers de l'entreprise à tous les niveaux (organisationnel et technique).

Cette méthode suppose la constitution d'une équipe pluridisciplinaire comprenant des membres de tous les services de l'entreprise. Elle leur permettra d'améliorer leur connaissance de leur entreprise et de mutualiser les bonnes pratiques de sécurité.

## F. Cramm

<figure><img src="image_93.png" /></figure>

Cramm (CCTA Risk Analysis and Management Method) a été inventée par **Siemens** en Anglettre et est soutenue par l'état. Cramm est une méthode exhaustive assez lourde, réservée aux grandes entreprises puisqu'elle recourt à près de 3 000 points de contrôle. Elle possède deux variantes : Cramm Express et Cramm Expert et est compatible avec la norme BS7799.

Des logiciels sont fournis avec la méthode à des fins de simulation, de reporting et de suivi des mesures de sécurité.

<figure><img src="image_94.png" /><figcaption>Démarche générale de la méthode Cramm</figcaption></figure>

La méthode Cramm est composée de 3 phases :

### Phases de la méthode Cramm

1. identification de l'existant

2. évaluation des menaces et des vulnérabilités

3. choix des remèdes

L'identification de l'existant permet de dresser l'inventaire des équipements, des applications, et des données qui constituent l'infrastructure informatique sur laquelle repose le SI de l'entreprise. Chacun des éléments de cet inventaire est évalué en terme de coût et d'impact en cas de compromission (indisponibilité, altération, destruction...).
L'évaluation des menaces et des vulnérabilités met en évidence les problèmes possibles.

Pour cela, la base de connaissances de Cramm fournit une liste importante des risques possibles dont il faut évaluer le niveau de criticité.

Le choix des remèdes consiste à sélectionner parmis une base de 3 000 contre-mesures possibles classées en 70 thèmes les remèdes aux risques identifiés plus haut. Le logiciel fourni avec Cramm détermine les remèdes à adopter en fonction des risques, de leur criticité identifiés précédement et du niveau de sécurité désiré.

# IV. Critères de choix

Comment choisir une méthode parmis le panel existant ? Sur quels critères faire ce choix ? La liste suivante donne quelques pistes pour faciliter ce choix :

Critères de choix d'une méthode d'analyse des risques

* l'origine géographique de la méthode, la culture du pays jouant beaucoup sur le fonctionnement interne des entreprises et leur rapport au risque

* la langue de la méthode, il est essentiel de maîtriser le vocabulaire employé

* l'existence d'outils logiciels en facilitant l'utilisation

* l'existence d'un club d'utilisateurs afin d'avoir un retour d'expériences

* la qualité de la documentation

* la facilité d'utilisation et le pragmatisme de la méthode

* la compatibilité avec une norme nationale ou internationale

* le coût de la mise en oeuvre

* la quantité de moyens humains qu'elle implique et la durée de mobilisation

* la taille de l'entreprise à laquelle elle est adaptée

* le support de la méthode par son auteur, une méthode abandonnée n'offre plus la possibilité de conseil et de support de la part son éditeur

* sa popularité, une méthode très connue offre un réservoir de personnels qualifiés pour la mettre en oeuvre

# V. Conclusion

Il existe de nombreuses méthodes d'analyse des risques, certaines simples d'utilisation, avec parfois des outils logiciels en simplifiant l'utilisation. D'autres méthodes sont réservées à des grands comptes du fait de leur complexité et des ressources humaines impliquées. Il vous reste à choisir la méthode qui s'applique le mieux à votre entreprise ou organisme public.
# VI. SUPERVISION RESEAU ET SECURITE

## 1 - Introduction

* L'administrateur réseau a plusieurs rôles, et en particulier :

* vérifier que ses matériels fonctionnent bien

* surveiller l'évolution du trafic sur son réseau

* On dit que l'administrateur **supervise** son réseau = “surveille” son réseau

* Les différents moyens pour superviser

* test de présence des matériels et des services

* ping, connexion TCP, ...

* récolte de valeurs de variables sur les matériels

* MIB + SNMP

* récolte des journaux systèmes sur les matériels

* SYSLOG

* La plupart des logiciels de supervision intègrent ces trois méthodes
# 2 - Cartographie de présence

* C'est le premier niveau de supervision

* On cherche à tester la présence des matériels, et des services sur les matériels

* Objectif

* Créer une cartographie, avec un code de couleur

* vert = le matériel / service est présent

* jaune / orange = ne répond pas aux dernières demandes

* rouge = ne répond pas depuis longtemps

## 1.1 PRINCIPES DE SUPERVISION RESEAU

### 1.1.1. Généralités

La supervision réseau a pour but d'observer et d'analyser les comportements et l'évolution des éléments réseau. Il peut s'agir de machines physiques, d'éléments d'extrémité, câblage lui-même, ou encore des composants logiques et logiciels, tels que les logiciels de base de données, ou n'importe quel autre logiciel d'importance crucial dont le fonctionnement doit être vérifier en permanence.

La surveillance du réseau dépend de trois principes qui doivent être respectés pour la mise en place d'une architecture cohérente de la supervision réseau :

1. L'accès aux informations de la supervision réseau : comment définir avec précision les informations nécessaires et ne pas s'encombrer des dizaines d'informations inutiles qui rendent celles pertinentes inexploitables ; et comment récupérer les informations utiles pour les centraliser et les rendre explicites ;

2. Définir les mécanismes de la supervision réseau : une fois les sources d'informations définies, il faut s'interroger sur les besoins en informations ; sur la fréquence à laquelle les informations doivent être collectées ; et sur les technologies en mettre en place pour assurer une surveillance du réseau ;

3. L'application des informations recueillies : en effet, la partie surement la plus importante de la supervision réseau est de correctement réagir aux informations collectées ; le but
d'une bonne stratégie de surveillance réseau est de prévenir les défaillances. Ainsi, si un
administrateur ne prend pas en compte les alertes successives sur un appareil particulier,
la panne aura lieu comme si la supervision réseau n'existait pas.

La supervision est d'un point de vue théorique assez simple à expliquer. Il s'agit en fait de répéter de manière régulière un processus de test ou de surveillance d'un équipement ou d'une application. Le but étant d'obtenir très rapidement et simplement une vision précise des événements ou anomalies sur la période analysée.<fnref n="1" />

1.1.2. Rôles de la supervision

L'objectif de la supervision informatique est de surveiller le système et de garantir sa disponibilité même en cas d'anomalie pour cela, deux étapes sont essentiellement nécessaires pour les administrateurs :

- Tenter de prévenir en cas de problème (défaillances matérielles ou interruption des services) et garantir une remontée d'information rapide ;

- Automatiser les taches de récupération des applications et des services en assurant des mécanismes de redondance en une durée d'innervation minimale (par exemple le redémarrage des services interrompus, l'arrêt de la machine en cas de surcharge du CPU, la sauvegarde des données en cas du risque de perte d'un disque dur, etc...

Dans la gestion du parc informatique, la supervision est un élément incontournable et a pour
rôles :

- Réduire la dégradation de la disponibilité : Il s'agit de détecter les anomalies le plus tôt possible, idéalement avant qu'elles n'aient des incidents sur les utilisateurs, réduire leur temps de traitement, simplifier et automatiser les taches d'administration et mesurer l'intégrité et l'état de processus sur un équipement par exemple.

- Maximiser l'utilisation des infrastructures : il s'agit ici d'analyser et de recueillir les données de capacité des performances de systèmes et services, d'optimiser l'architecture et l'infrastructure du système d'information et donner la priorité des ressources aux processus métiers et applications critique.

1.1.3. Fonctionnalités et niveaux d'information

<footnote n="1">¹ fr.wikipedia.org/wiki/supervision</footnote>
Généralement la supervision regroupe les fonctionnalités illustrées dans la figure suivante :

<figure><img src="image_95.png" /><figcaption>Figure 1 : Fonctionnalités de la supervision</figcaption></figure>

**Supervision réseau** : elle porte sur la surveillance de manière continue de la disponibilité des services en ligne, du fonctionnement du réseau, des débits et bande passante, de la sécurité, etc.

**Supervision système** : c'est la vérification de la santé d'un serveur coté ressources matérielles (la mémoire, le CPU, le disque dur, etc.).

**Exécution de commandes** : qui sont des actions ou programmes lancés automatiquement.

**Envoi d'alertes** : c'est une émission de message d'alerte sous forme sonore, visuelle ou encore par e-mail.

**Cartographie** : présente la vue d'ensemble de l'architecture informatique surveillée.
Rapports d'activité (reporting) : comme les tableaux de bord et les histogrammes.

Il est à noter qu'à partir de ces fonctionnalités qui sont réalisées par des modules spécifiques constituant le système de monitoring.<fnref n="2" />

## 1.2. Le monitoring et la supervision

### 1.2.1 Présentation

La supervision réseau est une fonction qui consiste à indiquer et à commander l'état d'un appel, d'un système ou d'un réseau. La supervision d'un réseau consiste à des activités qui permettent de surveiller, visualiser, analyser, piloter et agir. La supervision d'un réseau permet de superviser l'ensemble du système d'information de l'entreprise ; le réseau et ses équipements, les serveurs, et les applications.

Le monitoring d'un réseau est une opération qui consiste à la supervision d'un réseau en temps réel. Il existe plusieurs types d'activités de monitoring : le monitoring de disponibilité, le monitoring des temps de réponses, le monitoring des activités technique.

Le monitoring de disponibilité appelé aussi le monitoring de type 2 est la plus ancienne forme de monitoring. Il consiste à assurer la disponibilité réelle des composants hardware et software. Ce type de monitoring est appelé aussi monitoring de type 1 et il est largement basé sur l'utilisation du protocole SNMP.

Le monitoring des temps de réponses appelé aussi le monitoring de type 2 consiste à mesurer le temps de réponses de points en points aux requêtes des utilisateurs sur les applications. Cette mesure peut s'effectuer, soit en sortie de lieu MAN, sont depuis l'extérieur par l'intermédiaire de prestataires spécialisés. Ce type de monitoring est très utilisé pour le contrôle de niveau de service.

Le monitoring des activités techniques appelé aussi monitoring de type 3, est basé sur l'installation de sondes (capteurs) spécifiques dans tous les composants d'une application ; serveur HTTP, serveur d'application, middleware orientées messages, base de données. Il offre une vision détaillée des performances (et donc des variations de performances) de chacun des éléments de l'application.

Il existe plusieurs types de logiciels de supervision de réseaux. Certains réalisent un seul type de monitoring et d'autre on réaliser plusieurs comme le PRTG version 7.<fnref n="3" />

<footnote n="2">² fr.wikipedia.org/wiki/Fonctionnalités et niveaux d'information</footnote>

<footnote n="3">³ www.cnrtl.fr/definition/monitoring</footnote>
### 1.2.2 Le monitoring de la performance du réseau

#### 1.2.2.1 Les indicateurs de performance

On peut distinguer deux types d'indicateur de performance :

Les indicateurs basés sur la mesure des services du réseau, servant par exemple à assurer que les réseaux maintiennent un niveau de performance suffisant pour assurer le bon travail des utilisateurs : par exemple la disponibilité des services ou leur temps de réponse.

Les indicateurs basés sur la tolérance du réseau avant une baisse trop importante du niveau de service.

**1) Disponibilité des services**

La disponibilité d'un service ou d'un composant du réseau est représentée par le pourcentage de temps durant lequel cette ressource est disponible pour les utilisateurs. La disponibilité est basée sur le bon fonctionnement global de l'application ou du service.

La fiabilité représente la disponibilité effective d'un composant ou d'un service pour les utilisateurs du réseau.

La défaillance d'un composant est définie par le MTBF (Mean Time Before Failure) est la durée de bon fonctionnement entre deux défaillances et le MTTR (Mean Time To Repair) est la durée de réparation moyenne d'une défaillance.

La disponibilité D est définie par la relation suivante :

$$D = MTBF/(MTBF+MTTR)$$.
La disponibilité devient de plus en plus complexe à déterminer si on ajoute à son calcul, en plus de la simple fonctionnalité du composant, la configuration du réseau et sa charge acceptable.

**2) Le temps de réponse**

Le temps de réponse est la durée nécessaire à un système pour répondre à une demande, par exemple le temps entre la frappe d'une touche sur le clavier et l'affichage de cette touche à l'écran.

Maintenir un temps de réponse très court impose un coût des équipements croissant avec la taille du réseau et le nombre d'utilisateurs. En effet, il faut des technologies de connectivité efficace, par exemple des commutateurs à la place des concentrateurs. De plus, les capacités des serveurs d'application doivent être suffisantes pour soutenir les nombreuses connexions simultanées que peuvent imposer un flux réseau important.

**3) Exactitude**
L'exactitude du réseau représente le temps durant lequel aucune erreur ne survient, pendant la livraison des données d'un élément du réseau à un autre. Bien sûr, idéalement ce temps doit tendre vers l'infini.

En raison de la façon dont sont conçus actuellement les protocoles de communication, cette partie de la performance réseau n'est pas souvent visible par l'utilisateur. En effet, les protocoles modernes sont construits autour de fonctions de correction d'erreur et de récupération de celles-ci.

Cependant il y a parfois des sources de "bruit" qui nuisent à la bonne circulation des informations sur le backbone ou le câblage qui peuvent être localisées et corrigées par l'administrateur.

#### 4) La charge

On peut définir la charge comme le nombre d'évènements réseau qui ont lieu sur une période de temps donné. On compte par exemple dans la charge les éléments suivants :

- Le nombre de transaction d'un type précis sur une période donnée ;

- Le nombre de broadcast réseau généré par certains éléments du réseau ; ou - D'autres types de transactions réseau.

Il est important de garder une vue précise et permanente sur la charge afin de voir quels sont les éléments de défaillance en cas d'augmentation du trafic et de pouvoir mettre à niveau rapidement le réseau à moindre cout.

#### 5) La capacité

La capacité est le pourcentage d'utilisation d'une ressource par rapport à son potentiel théorique, par exemple une carte full duplex 100mbs doit délivrer un taux de transfert théorique de 100 mégabits par seconde.

C'est une mesure beaucoup plus fine que la charge bien qu'elle soit basée sur un débit théorique car il est plus facile de comparer une mesure réelle à un maximum théorique, que d'essayer de calculer une réelle valeur de la charge maximale du réseau. En fonction de certaines informations, il est possible de diviser la charge réseau pour la rendre équivalente sur chaque lien du réseau. Ce qui permet également d'augmenter la performance d'un réseau sans en changer l'infrastructure ou la technologie mais en opérant juste un bon équilibrage des charge.

#### 1.2.2.2 La surveillance des indicateurs de performance (monitoring de surveillance)
Afin d'avoir une bonne vision de la performance du réseau et après avoir pris connaissance des indicateurs à surveiller et de ce qu'ils représentent, il faut mettre en place les méthodes de surveillance de ceux-ci. La mesure de la performance s'effectue en générant des statistiques sur le trafic réseau, de façon instantanée ou sur une période donnée. Dans un LAN, la plupart des informations importantes peuvent être collectées par un agent distant qui observe simplement le trafic du réseau. Cette simple méthode permet d'identifier les nœuds d'importance du réseau et de les surveiller pour éviter toute défaillance.

L'analyse de la performance réseau est donc l'étape essentielle qui suit la récupération des informations. Pour cela les divers logiciels de monitoring proposent une mise en forme de l'information pour la rendre plus claire, ce qui permet aux administrateurs de répondre aux questions les plus importantes telles que, quelles sont les erreurs possibles ou les défaillances actuelles du réseau, les impacts de l'augmentation du trafic, le nombre de paquets perdus, etc. il est donc ainsi possible de générer une vue du réseau qui permet une réelle surveillance de celui-ci.

On peut opposer cependant les deux façons de recueillir les informations sur le réseau, de façon exhaustive ou de façon statistique. Il n'est évidemment pas simple de recueillir les informations de façon exhaustive surtout durant des périodes de grande activité réseau ou le trafic engendré par les tests peuvent augmenter la charge inutilement voire même être la source de défaillance. L'alternative est de prendre des mesures à des moments aléatoires et d'établir une statistique qui donnera un état du réseau, les décisions réseau sont ensuite prises par rapport à la donnée statistique, ce qui permet de minimiser l'impact de certains tests qui peuvent échouer en raison d'un trafic réseau ponctuellement trop important.

Néanmoins, la méthode statistique comporte elle aussi des désavantages. Tout d'abord, les données une fois traitées par cette voie, sont moins pertinentes et peuvent plus facilement être trompeuses : un chiffre moyen sur la charge ne permet pas de savoir si la charge est bonne le plus clair du temps et si seul quelques pics ont eu lieu, ou si le trafic est toujours moyen. Enfin, certains points d'un réseau ne peuvent pas se permettre de subir des défaillances, mêmes minimes.

### 1.2.2.3 Surveillance des défaillances (monitoring des défaillances)

#### a) Définition et objectifs

L'objectif du monitoring des défaillances est d'identifier les possibles défaillances du réseau le plus rapidement possible après leur occurrence et de pouvoir définir la source de ces défaillances facilement. Et ainsi, de rendre la reprise sur incident la plus efficace possible.
Cependant, ce type de surveillance n'est pas toujours facile à mettre en place car certaines défaillances ne sont pas faciles à mettre en évidence. Par exemple, un disque dur dont un secteur devient corrompu ou défectueux n'est pas toujours repérable, ou seulement localement à la machine par un test qui doit être conduit manuellement et donc hors de porter du monitoring réseau. Pire encore, certaines ressources ne peuvent tout simplement pas être testées car les constructeurs n'ont pas mis en place de moyens de diagnostique disponibles pour l'utilisateur. De plus, de nombreuses défaillances peuvent être observées mais l'origine de la défaillance ne peut pas toujours être mise en lumière aisément. Par exemple, un routeur qui ne délivre plus de paquet correctement peut représenter un véritable casse-tête pour ce qui est de localiser la panne, elle peut être matérielle comme logicielle ou ce peut être les infrastructures d'interconnexion qui sont défaillantes.

Enfin, certaines alertes peuvent tout simplement être factices. En effet, un logiciel du monitoring indiquer que toute une partie du réseau ne répond plus, cela pouvant provenir d'un concentrateur défectueux, mais il peut s'agir simplement d'un trafic trop important qui a empêché les tests d'aboutir.

b) Méthode de gestion des défaillances

Afin d'agir de la meilleure façon contre les défaillances du réseau il est nécessaire de maintenir des fichiers de rapport qui contiennent tous les éléments et les erreurs qui se sont produites sur le réseau.

Il peut être nécessaire de mettre en place une surveillance des agents ou du logiciel de monitoring lui-même, afin de ne pas avoir de faux rapport en cas de défaillance de ceux-ci.

Toute la finesse de ce type surveillance est de mettre en place un système de tests et de rapports qui permettent d'anticiper la défaillance d'un composant du réseau. Il faut donc mettre en place des quotas ou des limites sur tous les éléments quantifiables tels que la charge, la bande passante, ou encore le temps de réponse.

Il est aussi nécessaire de croiser les types de tests sur une même ressource pour pouvoir plus facilement découvrir la raison d'une défaillance, ou pour pouvoir noter dégradation progressive d'un service. L'analyse précise des rapports est bien sur un élément essentiel : les fichiers de rapport générés par les résultats doivent être très attentivement étudiés afin de détecter les défaillances possibles à venir.

1.2.2.4 Monitoring de surveillance des utilisateurs

1.2.2.4.1 Définition et objectifs
La surveillance des utilisateurs vise à garder une trace de l'utilisation des ressources
réseau par les utilisateurs. Il ne s'agit pas d'espionner le travail ou la vie privée des
utilisateurs d'un réseau d'entreprise, mais de veiller à la façon dont les utilisateurs se servent
de l'outil qui est mis à leur disposition. De plus, cela permet bien souvent découvre les
problèmes de charge du réseau en localisant les ressources fréquemment utilisées pour
permettre de diviser les charge soit en séparant certaine ressources qui, regroupées, crée un
goulot d'étranglement sur le réseau, ou pour augmenter la bande passante de certains
éléments qui ne donnent pas satisfaction aux utilisateurs, comme des serveurs mail, par
exemple.

1.2.2.4.2 Méthode de surveillance des utilisateurs

Dans la pluparts des réseaux d'entreprise, la premier stratégie de surveillance des
utilisateurs est mis en place par le contrôle de ressources réseau, par la gestion des droits
d'accès à ces dites ressources. Les politiques de sécurité réseau n'étant pas liées directement
au monitoring réseau, nous ne bâteront pas de ce sujet. Cependant, une stratégie de
monitoring réseau doit être établie en fonction des politiques des droits réseau et système
existants. D'une façon générale, la surveillance des utilisateurs revint surtout à vérifier le
comportement des utilisateurs sur le réseau. En effet, il est important de mettre en place des
systèmes de surveillance des volumes des stockages utilisés par les utilisateurs pour parer à
une crise de l'espace qui peut s'avérer très dommageable pour une entreprise.

De même, les utilisateurs sont souvent la proie de nombreuses attaques visant à
ouvrir des moyens d'accès aux ressources réseau à l'entreprise. En cela le monitoring des
utilisateurs se rapproche beaucoup de la sécurité réseau: en surveillant le nombre de sessions
qu'un utilisateur peut avoir ouvert en simultané, on peut découvrir des tentatives d'intrusion.
Enfin les utilisateurs sont souvent à l'origine de défaillances réseau dues à un manque de
connaissance des outils, donc être utile de vérifier la façon dont un utilisateur se comporte sur
le réseau, taille des mails, travail en réseau, alors que le local serait moins consommateur de
ressources etc. sur cet aspect, la surveillance des utilisateurs se rapproche de la surveillance
des défaillances.

1.3. Les différentes approches de la supervision

Jusqu'ici, nous avons ce qu'était la supervision. Définissons maintenant ce que nous pouvons
en faire avec les approches ou types d'informations pouvant être fournies par la supervision.
Il s'agit :
* la fiabilité : il s'agit de loin de l'utilisation la plus courante de la supervision informatique. Le but ici est de surveiller en permanence la disponibilité de l'équipement afin de détecter la moindre anomalie et si nécessaire de remonter une alerte ;

* La performance : la supervision de performance a pour but de retourner des informations sur la disponibilité d'un équipement comme par exemple le temps de résolution DNS, le temps de connexion, le temps de récupération du premier octet et dans le cas d'une page Web le temps de récupération de page et de l'ensemble des éléments de celle-ci(image scripts...). Grace à cette analyse, nous allons pouvoir diagnostiquer une montée en charge difficile ou même un surdimensionnement de votre bande passante ;

* Le contenu : dans ce cas, les informations retournées par les éléments surveillés sont analysés, pour par exemple, détecter la suppression d'un fichier sur un serveur ftp, la modification d'une page Web ou la disparition d'un mot clef. Toutes ces approches sont complémentaires et peuvent bien entendu se retrouver regroupées dans une seule analyse. L'analyse fiabilité étant implicitement présente dans le cas d'une analyse performance et contenu.

## 1.4. LA NORME ISO 7498/4

L'ISO (International standards Organization) ou l'Organisme international de Normalisation, s'intéresse de près à la supervision. Et, dès 1989, l'organisme publie la norme ISO7498-4 définissant les principales fonctions qui doivent implémenter les systèmes de supervision et d'administration. Il s'agit de :

a. La gestion de performance

b. La gestion des configurations

c. La gestion de la comptabilité

d. La gestion des anomalies

e. La gestion de la sécurité.

### a) Gestion Des Performances

Elle doit pouvoir évaluer les performances des ressources du système et leur efficacité. Elle comprend les procédures de collecte de données et statistique. Elle doit aboutir à l'établissement de tableaux de bord. Les informations recueillies doivent aussi permettre de planifier les évolutions du réseau. Les performances du réseau sont évaluées à partir de quatre paramètres :
1. Le temps de réponse

2. Le débit

3. Le taux d'erreur

4. La disponibilité

## b) Gestion Des Configurations

La gestion de configuration permet d'identifier, de paramétrer et de contrôler les différents objets du réseau. Les procédures requises pour gérer une configuration sont :

1. La collecte d'information

2. Le contrôle d'état

3. La sauvegarde historique de la configuration de l'état du système.

## c) Gestion De La Comptabilité

Son rôle est de connaître les charges des objets gérés ainsi que leurs coûts de communication. Des quotas d'utilisation peuvent être fixés temporairement ou non sur chacune des ressources réseaux. De plus, la gestion de la comptabilité autorise la mise en place de systèmes de facturation en fonction de l'utilisation pour chaque utilisateur.

## d) Gestion Des Anomalies

La gestion des anomalies de détecte les problèmes réseaux (logiciels ou matériels). Elle essai d'isoler le plus précisément le problème en effectuent divers testes. Quand cela est possible, elle règle elle-même de manière automatique l'anomalie. Sinon, elle alerte les personnes concernées par le type du problème afin de solliciter leur intervention. La gestion des anomalies garde dans une base de données l'ensemble des problèmes survenus ainsi que leur solution, de manière à être encore plus efficace face à un incident reçurent. Cette fonction de la norme ISO 7498-4 demeure de loin la fonction la plus implémentée à ce jour. La gestion des fautes permet la détection, la localisation et la correction d'anomalies passagères ou persistantes. Elle doit également permettre le rétablissement du service à une situation normale

## e) Gestion De La Sécurité

La gestion de la sécurité contrôle l'accès aux ressources en fonction des politiques de droits d'utilisation établies. Elle veille à ce que les utilisateurs non autorisés ne puissent
accéder à certaines ressources protégées. Elle a également pour rôle de mettre en application
les politiques de sécurité.<fnref n="4" />

# 1.5 LE PROTOCOLE DE SUPERVISION DE RESEAU SNMP

## 1.5.1 Définition

La grande majorité des solutions de supervision de base sur l'utilisation du protocole SNMP pour fonctionner. SNMP signifie « Simple Network Management Protocol », en français « Protocole simple de gestion de réseau ».

C'est un protocole de communication qui permet aux administrateurs réseau de gérer les équipements du réseau, de superviser et de diagnostiquer des problèmes réseaux et matériels à distance. Pour cela, deux principes sont utilisés afin de récolter des informations :

* Requête du serveur vers l'équipement

* Alertes envoyés spontanément de l'équipement vers le serveur (traps)

## 1.5.2 Architecture

Les différents éléments que l'on peut identifier avec le protocole SNMP sont synthétisés par le schéma ci-dessous.

* Les agents SNMP : ce sont les équipements (réseau ou serveur) qu'il faut superviser.

* Le superviseur SNMP : c'est une machine centrale à partir de laquelle un opérateur humain peut superviser en temps réel toute son infrastructure et diagnostiquer les problèmes

* Le MIB : ce sont les informations dynamiques instanciées par les différents agents SNMP et remontées en temps réel au superviseur.

<footnote n="4">⁴ https://astuces-top.blogspot.com/2016/08/livre-nagios-supervision.html</footnote>
### 1.5.3 Le manager

Rappelons que le Manager se trouvera sur une machine d'administration (un poste de travail en général). Il reste un client avant tout, étant donné que c'est lui qui envoie les différentes requêtes aux agents. Il devra disposer d'une fonction serveur, car il doit également rester à l'écoute des alertes que les différents équipements sont susceptibles d'émettre à tout moment Si l'on se base sur le schéma précédent, l'administrateur peut observer correctement le comportement de ses différents équipements en réseau. Le Manager dispose d'un serveur qui reste à l'écoute sur le port UDP 162 ainsi que d'éventuels signaux d'alarme appelés des "traps". Le Manager peut tout autant être installé sur une machine.

### 1.5.4 L'agent SNMP :

L'agent est un programme qui fait partie de l'élément actif du réseau. L'activation de cet agent permet de recueillir la base de données d'informations et la rend disponible aux interrogations. Les principales fonctions d'un agent SNMP :

* Collecter des informations de gestion sur son environnement local.

* Récupérer des informations de gestion telle que déni dans la MIB propriétaire.

* Signaler un évènement au gestionnaire.

Par ailleurs même si la principale fonction de l'agent est de rester à l'écoute des éventuelles requêtes du Manager et y répondre s'il y est autorisé, il doit également être capable d'agir de sa propre initiative, s'il a été configuré. Par exemple, il pourra émettre une alerte si le débit d'une interface réseau, atteint une valeur considérée par l'administrateur comme étant critique. Plusieurs niveaux d'alertes peuvent ainsi être définis, selon la complexité de l'agent (température du processeur, occupation disque dur, utilisation CPU...)<fnref n="5" />

### 1.5.5 MIB :

Chaque agent SNMP maintient une base de données décrivant les paramètres de l'appareil géré. Le Manager SNMP utilise cette base de données pour demander à l'agent des renseignements spécifiques. Cette base de données commune partagée entre l'agent et le Manager est appelée Management Information Base (MIB). Généralement ces MIB contiennent l'ensemble des valeurs statistiques et de contrôle définis pour les éléments actif

<footnote n="5">⁵ https://astuces-top.blogspot.com/2016/08/livre-nagios-supervision.html</footnote>
du réseau. SNMP permet également l'extension de ces valeurs standards avec des valeurs
spécifiques à chaque agent, grâce à l'utilisation de MIB privées. Un fichier MIB est écrit en
utilisant une syntaxe particulière, cette syntaxe s'appelle SMI 3, basée sur ASN.1 tout comme
SNMP lui-même.

En résumé, les fichiers MIB sont l'ensemble des requêtes que le Manager peut
effectuer vers l'agent. L'agent collecte ces données localement et les stocke, tel que défini
dans la MIB. Ainsi le Manager doit être conscient de la structure (que celle-ci soit de type
standard ou privée) de la MIB afin d'interroger l'agent au bon endroit. La structure d'une
MIB est une arborescence hiérarchique dont chaque nœud est défini par un nombre ou un
Object Identifier (OID). Chaque identifiant est unique et représente les caractéristiques
spécifiques du périphérique géré. Lorsqu'un OID est interrogé, la valeur de retour n'est pas
un type unique (texte, entier, compteur, tableau...) Un OID est donc une séquence de
chiffres séparés par des points. Une MIB est un arbre très dense, il peut y avoir des milliers
d'OID dans la MIB<fnref n="6" />

1.5.6 Les requêtes SNMP

Une requête SNMP est un datagramme UDP habituellement à destination des ports 161 et 162 lorsqu'il s'agit de traps. Les systèmes de gestion de réseau sont basés sur trois éléments principaux : un superviseur, des équipements et des agents. Le superviseur est la console qui permet à l'administrateur réseau d'exécuter des requêtes de management. Il a le rôle du serveur de management et est la cible pour la gestion des traps. Les agents sont des entités qui se trouvent au niveau de chaque interface, connectant au réseau l'équipement et permettant de récupérer des informations sur différents objets issus de la MIB.

1.6. BANDE PASSANTE

Pour les réseaux informatiques, le terme de bande passante est synonyme de taux de transfert
de données, c'est-à-dire le volume de données pouvant être transporté d'un point à un autre
dans un laps de temps donné (généralement une seconde).

Dans cette acceptation, la bande passante d'un réseau est généralement exprimée en bits par seconde (bit/s). Sur les réseaux modernes, le débit est mesuré en millions de bits par seconde

<footnote n="6">⁶ https://fr.wikipedia.org/wiki/MIB</footnote>
(mégabits par seconde, ou Mbit/s) ou en milliards de bits par seconde (gigabits par seconde, ou Gbit/s).

La bande passante n'est pas le seul facteur qui affecte les performances du réseau : la perte de paquets, la latence et la gigue sont d'autres facteurs qui dégradent le débit d'un réseau et ramènent le fonctionnement d'une liaison au niveau de celle d'une bande passante inférieure.

Un chemin de réseau comprend généralement une succession de liaisons, chacune ayant sa propre bande passante. La bande passante de bout en bout est donc limitée à celle de la liaison la plus lente (le goulet d'étranglement).

Les applications n'utilisent pas toutes la même bande passante. Ainsi, une conversation par messagerie instantanée peut utiliser moins de 1 000 bits par seconde (bit/s) ; une conversation en voix sur IP (VoIP) nécessite 56 kilobits par seconde (Kbit/s) pour être de bonne qualité. La vidéo à définition standard (480p) fonctionne à 1 mégabit par seconde (Mbit/s), la vidéo HD (720p) exige environ 4 Mbit/s et la vidéo HDX (1080p), plus de 7 Mbit/s.

La bande passante effective, soit le plus haut débit fiable d'un chemin de réseau, est mesurée au moyen d'un test. Ce débit peut être déterminé par la mesure répétée du temps nécessaire au téléchargement d'un fichier de son point d'origine à sa destination.<fnref n="7" />

# INSTALLATION ET CONFIGURATION DE L'OUTIL WHATSUP GOLD

## 4.1. Installation de whatsup gold

L'installation de whatsup gold ainsi que sa configuration est relativement simple comparée à des autres outils de supervision. Il faut avoir des connaissances concernant l'utilisation du terminal (installation manuelle des paquets, modification des droits, créations des utilisateurs...).

Il nous faudra installer "Net-SNMP" afin de pouvoir lancer des requêtes snmp pour superviser des routeurs ou switchs par exemple.

<footnote n="7">⁷ Lemagit.fr/définition/bande-passante</footnote>
Après nous avons téléchargé les paquets d'installation des versions stables disponibles à partir du site de officiel de whatsup gold qui sont : le paquet de l'outil whatsup gold (Version 3.1.0) et le paquet contenant les plugins (Version 2.0.2).

Pour téléchargé whatsup gold il nous est demande de remplir un formulaire tel que si dessous ;

<figure><img src="image_96.png" /></figure>

Nous avons une configuration de base sur les routeurs: adresses IP, communauté SNMP, combinaison nom d'utilisateur / mot de passe, etc. La configuration sur R1

Puisqu'il doit y avoir une connectivité entre l'outil de surveillance du réseau et les périphériques à surveiller, assurons-nous que nous pouvons envoyer un ping aux deux routeurs à partir de Windows Server:
<figure><img src="image_97.png" /></figure>

Avec la configuration de nos appareils, nous allons maintenant procéder à l'installation et à la
configuration de WhatsApp Gold. La version WhatsApp Gold 2017.

L'installation de WhatsApp Gold est assez simple, du moins si vous choisissez l'installation
standard par rapport à l'installation avancée.

<figure><img src="image_98.png" /></figure>

Le fichier d'installation va d'abord effectuer quelques vérifications du système pour
s'assurer que votre système répond aux exigences. Dans mon cas, Microsoft IIS n'a pas été
activé et la configuration a informé qu'il sera activé pour moi.
<figure><img src="image_99.png" /></figure>

Ensuite, on reçoit les détails de notre licence. Dans notre cas, puisque j'utilise une licence d'évaluation, il me dit que j'ai 30 jours de plus. Je n'ai pas eu à spécifier cela parce que la clé de licence d'évaluation était liée au fichier d'installation.

<figure><img src="image_100.png" /></figure>

On devra ensuite spécifier une adresse IP que le scrutateur local utilisera pour communiquer avec les scrutateurs distants (le cas échéant). Vous pouvez utiliser des interrogateurs distants pour distribuer la charge sur le serveur principal WhatsApp Gold à d'autres systèmes.

<figure><img src="image_101.png" /></figure>
On sera alors présenté avec un résumé de ce qui sera installé et après environ 10 minutes, l'installation devrait être terminée et il nous sera demandé si l'on veut redémarrer notre système.

Après le redémarrage, on recherche WhatsApp Gold comme on le fera pour n'importe quelle autre application. On Clique sur "WhatsApp Gold" qui ouvre la console Web WhatsApp Gold dans notre navigateur Web par défaut.

Une fois que nous dépassons l'écran de démarrage de la licence, une boîte de dialogue de visite s'affiche. On peut passer par la visite pour obtenir un cours de base sur l'utilisation de WhatsApp Gold. Cependant, puisque nous allons passer en revue la configuration dans cet article, je vais passer la visite.

## 4.1.2. Découverte du réseau

Le premier écran / onglet majeur de l'interface de WhatsApp Gold est l'onglet "DISCOVER" qui est logique depuis que nous nous connectons pour la première fois.

Une chose que nous remarquons lorsque vous ouvrez WhatsApp Gold pour la première fois est qu'il n'y a pas de périphériques surveillés. Pour ce faire, des outils installent généralement un agent de surveillance sur leur serveur local. Cependant, il semble que WhatsApp Gold soit sans agent même sur le serveur local sur lequel il est installé.

<figure><img src="image_102.png" /></figure>

Il existe différentes options pour découvrir un réseau: analyser un sous-réseau, analyser une plage d'adresses IP, en utilisant un périphérique de départ.
<figure><img src="image_103.png" /></figure>

En spécifiant un périphérique de démarrage, l'outil peut analyser ce périphérique, puis passer de ce périphérique à d'autres réseaux connectés. On peut spécifier jusqu'où on veut que l'outil saute. Pour ce laboratoire, je vais juste spécifier R1 (172.16.123.1) comme le périphérique de départ et je m'attends à trouver R2.

<figure><img src="image_104.png" /></figure>

Sur l'écran suivant, on doit spécifier les informations d'identification avec lesquelles scanner / découvrir les périphériques. Les outils de surveillance de réseau s'appuient sur le protocole SNMP pour la découverte de périphériques.

Un autre avantage avec WhatsApp Gold, c'est comment ils ont toutes les informations d'identification dans un endroit plutôt que d'avoir une page pour SNMP, une autre page pour WMI et ainsi de suite.
<figure><img src="image_105.png" /></figure>

<figure><img src="image_106.png" /></figure>

Une fois que nous décidons les appareils à surveiller, on clique simplement sur le bouton Démarrer. Avec cela, les appareils devraient maintenant être surveillés

Il y a plusieurs onglets sur la page État du périphérique, notamment l'onglet Général, l'onglet Disque / CPU / Mémoire, Routeur / Commutateur / Interface et Surveillance.

<figure><img src="image_107.png" /></figure>
<figure><img src="image_108.png" /></figure>

### 4.1.3. Gestion de la configuration

Une autre fonctionnalité intéressante disponible uniquement dans l'édition Total Plus de WhatsUp Gold est la gestion de la configuration. Avec la gestion de la configuration, on peut archiver les fichiers de configuration, alerter sur les modifications apportées à la configuration, et également respecter certaines normes réglementaires (qui nécessitent une configuration à auditer fréquemment).

Pour simplifier, on va créer une tâche simple pour sauvegarder la configuration de démarrage sur l'un de nos routeurs pour un essai. Accédez à Paramètres → Gestion de la configuration → Bibliothèque de tâches on ajouter une nouvelle tâche. Nous allons planifier cette tâche pour fonctionner tous les jours à 23h00.

Après avoir créé la tâche, je l'exécuterai immédiatement afin que nous ayons un fichier de configuration sauvegardé.

Si je vais dans les propriétés du périphérique de R1 et que je regarde l'onglet Tâche, j'y verrai ma tâche planifiée et aussi le résultat de l'exécution de la tâche une fois.

<figure><img src="image_109.png" /></figure>
### 4.1.4. Configurer les alertes

Il est en fait assez facile de configurer des actions d'alerte pour un périphérique; Cependant, il était difficile au début de déterminer où trouver des alertes pour tous les appareils surveillés. Par exemple, il n'y a pas un seul tableau de bord "d'alerte" qui me montre tous les problèmes sur le réseau en une fois, comme les périphériques qui sont en panne ou les périphériques avec un processeur élevé. Il existe plutôt plusieurs tableaux de bord sous l'onglet ANALYSE qui affichent des informations spécifiques.

Une chose que l'on devrait pouvoir faire avec n'importe quel outil de surveillance est d'être avertie quand quelque chose ne va pas. L'outil devrait fournir plusieurs moyens d'alerte comme l'envoi d'un e-mail, SMS, ou même simplement apparaître sur le tableau de bord (par défaut).

C'est ici que nous allons mettre en place des alertes de sorte que lorsque R2 tombe pendant plus de deux minutes, un email sera envoyé et une alarme web sera affichée sur le tableau de bord. Pour commencer, cliquez sur les propriétés du périphérique pour R2.

<figure><img src="image_110.png" /></figure>

Allez dans l'onglet Actions cliquez sur le bouton Actions et stratégies. La boîte de dialogue Actions et stratégies comporte deux parties: la bibliothèque d'actions et les stratégies d'action. Nous pouvons spécifier les actions à entreprendre (par exemple envoyer un e-mail, une alarme sonore)
lorsqu'une politique particulière est déclenchée (par exemple, l'appareil a été arrêté pendant 2 minutes).

Alors commençons par créer une action pour envoyer un email. Cliquez sur le signe plus dans la section Bibliothèque d'actions et sélectionnez "Action par e-mail".

What'sUp Gold ne possède pas son propre serveur SMTP interne, on doit donc configurer nos propres paramètres de serveur de messagerie. On peut également consulter le modèle d'e-mail par défaut qui sera utilisé pour envoyer l'e-mail. Cliquez sur OK une fois terminée.

C'est là que l'on pourra définir notre politique d'action. Cliquez sur le signe plus pour ajouter une nouvelle politique d'action. Nous appellerons cette politique "Device Down 2 minutes" et y ajouterons deux actions: sonner une alarme web lorsque l'appareil est arrêté depuis 2 minutes et envoyer un e-mail.

<figure><img src="image_111.png" /></figure>

Pour simuler une panne, nous allons fermer l'interface Fa0 / 0 de R2 en utilisant la commande no shutdown. Une fois cela fait, nous verrons que R2 est dans l'onglet MY NETWORKS.

<figure><img src="image_112.png" /></figure>
Après deux minutes, une alarme web sera affichée:

<figure><img src="image_113.png" /></figure>

Il n'y a pas de tableau de bord spécifique pour les rapports dans WhatsUp Gold. Cependant, ce qui est bon, c'est qu'on peut exporter les informations affichées à partir des différents tableaux de bord sous l'onglet ANALYSE.

# 3.1. Zabbix

## 3.1.1. Présentation de l'outil :

Zabbix est un outil de supervision, ambitionnant de concurrencer Nagios et MRTG. Il permet de supervise le réseau, système (processeur, disque, mémoire, processus...). Zabbix offre des vues graphiques et des alertes sur seuil. Les « serveurs Zabbix » peuvent être décomposés en 3 parties séparées : le serveur de données, l'interface de gestion et le serveur de traitement. Chacune d'elles peut être disposée sur une machine différente pour repartir la charge et optimiser les performances.

<figure><img src="image_114.png" /></figure>

Avantage :

* une solution très complète : cartographie de réseaux, gestion poussée d'alarme via SMS, Email, gestion de pannes, statistiques et reporting.

* une interface vaste mais Claire.

* une gestion des templates poussée, modification via interface.
De performance au rendez-vous : l'application a été testée avec succès ayant 1000 équipement a supervisé.

<figure><img src="image_115.png" /></figure>

Inconvénients :

➤ l'interface est vaste, la mise en place des templates n'est pas évidente au début : petits temps de formation nécessaire.

➤ l'agent zabbix communique pas défaut en clair les informations d'où la nécessité de sécuriser ces données

➤ commence à être connus, mais pas encore auprès des entreprises: peut d'interfaçage avec d'autre solution commerciale.

## 3.2 Op Manager :

### Présentation de l'outil :

Logiciel de Surveillance Réseau, Serveur et Virtualisation

Intérêts d'Op Manager

Utilisation optimale des ressources.

Prendre les bonnes décisions en identifiant les points de contention et les ressources non utilisées, grâce à de nombreux rapports disponibles en ligne ou en différé.

Statistiques d'utilisation des ressources (CPU, mémoire, disque, applications, etc...).

Il résous les problèmes tel que :

➤ Qui utilise ma bande passante ?

➤ Comment ma liaison WAN ralentit-elle l'exécution des applications ?

➤ Dois-je investir dans plus de bande passante ?

➤ Pourquoi les utilisateurs ont-ils un mauvais temps de réponse ?

Comment puis-je identifier les menaces de sécurité ?

**Op Manager -** Logiciel de Surveillance Réseau, Serveur et Virtualisation
L'Intérêts de Op Manager et de;

Prendre les bonnes décisions en identifiant les points de contention et les ressources non utilisées, grâce à de nombreux rapports disponibles en ligne ou en différé.

## 3.3 Nagios :

### 3.3.1. Présentation de l'outil :

Nagios (anciennement appelé Netsaint) est une application permettant la surveillance système et réseau. Elle surveille les hôtes et services spécifiés, alertant lorsque les systèmes ont des dysfonctionnements et quand ils repassent en fonctionnement normal. C'est un logiciel libre sous licence GPL.

C'est un programme modulaire qui se décompose en trois parties :

* Le moteur de l'application qui vient ordonnancer les tâches de supervision.

* L'interface web, qui permet d'avoir une vue d'ensemble du système d'information et des possibles anomalies.

* Les sondes (appelées greffons ou plugins), une centaine de mini programmes que l'on peut compléter en fonction des besoins de chacun pour superviser chaque service ou ressource disponible sur l'ensemble des ordinateurs

<figure><img src="image_116.png" /></figure>

#### Avantages

* Performances : L'application semble pouvoir tenir la charge avec énormément de machines surveillées grâce au moteur multithreade.
* Alarmes : Il est possible de configurer des évènements qui avertissent l'administrateur d'un fonctionnement anormal.

* interface : L'interface permet de gérer un grand nombre de machines, classées dans des groupes.

<figure><img src="image_117.png" /></figure>

Gestion des utilisateurs

<figure><img src="image_118.png" /></figure>

Inconvénient

* Interface : L'interface n'est pas très accueillante et est déroutante au début.

* Configuration : Il n'est pas très aisé d'ajouter de nouveaux équipements à surveiller si l'on sort du cadre du Template prédéfinie.

* Un développement lent, peu de versions et très espacées dans le temps (environ une année).

* Aucune gestion de carte de réseau, et aspect rudimentaire des alarmes. Aucune gestion de panne.

### 3.1.1 L'OUTIL PRTG

PRTG Network Monitor est un logiciel de surveillance réseau facile à utiliser qui existe en 2 versions : l'une gratuite et l'autre payante. La version gratuite est limitée à 10 sondes. Ses fonctionnalités contiennent : la surveillance de la disponibilité, du trafic et de la consommation, le packet sniffing, l'analyse détaillée, des rapports précis, et plus. PRTG Network Monitor est optimisé pour une installation, une configuration et une utilisation faciles. Il vous permet de configurer la surveillance de votre réseau en quelques minutes :

<figure><img src="image_119.png" /></figure>

identification réseau automatique

* modèles préconfigurés avec des sets de sondes recommandés pour différents périphériques utilisation conviviale optimisée pour une surface hautement interactive et personnalisée

* configuration via une structure arborescente avec une transmission optionnelle des réglages.
L'interface conviviale permet aux utilisateurs de configurer rapidement les périphériques
réseau et les sondes. Toutes les méthodes courantes pour l'acquisition de données de la
consommation du réseau sont soutenues : SNMP, WMI, Packet Sniffing et NetFlow. PRTG
Network Monitor fonctionne avec plus de 10.000 capteurs. La surveillance LAN, WAN, WLAN
et VPN des réseaux éloignés géographiquement à l'aide de remote probes (agents) est possible.
PRTG contient 30 sortes de sondes pour tous les services communs du réseau (par exemple
PING, HTTP, SMTP, POP3, FTP, etc.) permettant aux utilisateurs de surveiller la vitesse et les
pannes d'un réseau. Dès qu'une panne survient, le logiciel vous informe immédiatement en vous
envoyant un e-mail, un SMS, un message pager ou par d'autres canaux d'information.

3.1.2 L'OUTIL NTOPNG

NTOPNG n'est autre que la dernière évolution en date de l'outil NTOP. C'est un logiciel
libre multiplate-forme de surveillance et de mesure du trafic IP. Il est complet et stable, et
permet de connaître très précisément la caractérisation de la bande passante en temps réel sur un
réseau telle que : quelle est la charge, quelles sont les stations qui consomme le plus la bande
passante, les protocoles utilisés, qui échange avec qui, et tout ceci par le biais d'une interface
web.

Pour capturer les paquets sur une ou plusieurs interfaces, il utilise la bibliothèque portable « libpcap ». NTOPNG utilise les couches 2 et 3 pour présenter par machines, une synthèse de tous les protocoles utilisés. Dans sa nouvelle version, il vient résoudre certains problèmes de stabilité et de persistance des données dont soufrai NTOP.

En effet, à un intervalle régulier, ou lorsque le serveur redémarrai, les données étaient
effacés. Ainsi NTOPNG utilise présentement une base de données SQLite pour stocker ses
données. Une de ses nouvelles fonctionnalités est la possibilité d'exporter ses données au
format JSON pour l'analyse par des outils externes. Comme inconvénient, seule la version
Windows souffre d'une limitation de capture de 2000 paquets maximum à moins que l'on
s'enregistre ou que l'on fasse un don.

3.1.3 L'OUTIL NETFLOW ANALYZER DE MANAGEENGINE

NetFlow Analyzer est également un outil complet de collecte et d'analyse du trafic,
offrant également une visibilité en temps réel de la performance de la bande passante du réseau.
Ainsi cet outil fournit un ensemble d'information sur l'utilisation de la bande à savoir qui l'utilise et pour quoi. Parmi ces fonctionnalités, il permet de faire un monitoring de la bande passante du réseau, de l'allocation de la bande passante nécessaire aux applications importantes. En plus, il permet de faire des notifications en temps réel du réseau en fonction des alarmes établies et permet de détecter les machines et applications gourmandes en bande passante. De plus, il permet de faire une gestion de priorité des paquets du réseau en fonction des applications utilisées, et dispose d'outils de monitoring capable d'interagir avec des équipements Cisco. Les principaux avantages que possèdent cet outil sont qu'il est multiplateforme, ne nécessite pas de matériel physique dédié, possèdent des outils avancés d'analyse et de gestion, et qu'il supporte les technologies de plusieurs grands équipementiers. Le principale inconvénient est qu'il est payant, avec une version de démonstration complète utilisable uniquement 30 jours.

### 3.1.4 L'OUTIL WIRESHARK

Le logiciel Wireshark (anciennement Ethereal) permet la capture et l'analyse de trames sur Ethernet. Son utilité est indéniable pour contrôler le bon fonctionnement de réseau ou vérifier les trames transitant sur une interface d'un commutateur ou analyser les trafics inutiles ou ceux impactant les performances du réseau. Voici un petit récapitulatif des capacités de Wireshark :
- Décoder les trames (niveau 2 et 3)
- Calculer le débit moyen sur la durée de la capture (Mbps)
- Tracer un graphe du trafic pour tout ou partie des flux capturés
- Afficher les temps de réponses des trames TCP (basé sur les acquittements)
- Indiquer les erreurs ou les alertes détectées (paquets perdus, retransmis, dupliqués...)
- Suivre un dialogue TCP (notamment HTTP)
- Donner les statistiques sur les tailles des trames réseaux Etc. Pour cela, il suffit de l'installer sur un PC munit d'une interface réseau 100 Mbps sou plus et fonctionnant sous Windows ou Linux
Limitation de la taille des paquets L'analyse des trames se faisant généralement sur les premiers octets (les entêtes), il est utile de limiter la taille des paquets capturés à une taille maximum : pour cela, il suffit de cocher la case« Limit each packet to » et de choisir un nombre entre 68 octets (entête TCP) et 132 (informations complémentaires pour des flux HTTP ou TNS par exemple). Cela n'a aucune influence sur les statistiques concernant les tailles de trames puisque cette information est inscrite dans l'entête des trames Ethernet. Arrêt automatique sur seuil Il est possible de limiter la capture sur 3 critères : nombre de paquets, taille de la capture et délai dans le temps. Ces trois critères peuvent être combinés. Cet arrêt automatique permet de limiter le travail d'analyse plus tard et de ne pas écraser un événement important. Captures circulaires C'est le mode le plus intéressant, surtout si la sonde dispose d'un espace disque suffisant. En