# NOTES DU COURS DE SECURITE INFORMATIQUE AVANCEE

Djamba Tunda-Olembe

► To cite this version:

Djamba Tunda-Olembe. NOTES DU COURS DE SECURITE INFORMATIQUE AVANCEE. Licence. SÉCURITÉ INFORMATIQUE II, Lubumbashi, Congo-Kinshasa. 2022, pp.91. hal-04925109

HAL Id: hal-04925109

https://hal.science/hal-04925109v1

Submitted on 1 Feb 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

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

Distributed under a Creative Commons Attribution 4.0 International License
REPUBLIQUE DEMOCRATIQUE DU
CONGO
ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE
UNIVERSITE MARIA MALKIA

COURS DE SECURITE INFORMATIQUE II

(L2 GESTION)

PAR MASTER ING CIVIL TUNDA-OLEMBE DJAMBA

AVRIL 2021
# CHAP.I 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>Anglete rre</td><td>logiciel payant</td><td></td></tr><tr><td>SPRINT</td><td>1995</td><td>*</td><td>ISF</td><td>Association</td><td>Anglete rre</td><td>logiciel payant</td><td></td></tr><tr><td>BS 7799</td><td></td><td>***</td><td></td><td>Gouvernement</td><td>Anglete rre</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>Technologi secteur privé es</td><td>Canada</td><td>logiciel payant</td><td></td></tr><tr><td>COBRA</td><td>2001</td><td></td><td>C & A Systems Security Limited</td><td>secteur privé</td><td>Anglete rre</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>Allema gne</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_2.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é 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_3.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_4.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étaillé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 (Méthode 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_5.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_6.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_7.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_8.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.
# CHAP.II : LES OUTILS DE SECURITE INFORMATIQUE

## II.1 LES PORTS LOGIQUES, LES VULNERABILITES INFORMATIQUES ET LES JOURNAUX D'EVENEMENTS LOGS

### II.1.1 LES PORTS LOGIQUES

Dans la suite des protocoles Internet et correspondant à la couche de transport du modèle OSI, la notion de **port** logiciel permet, sur un ordinateur donné, de distinguer différents interlocuteurs. Ces interlocuteurs sont des programmes informatiques qui, selon les cas, écoutent ou émettent des informations sur ces ports. Un port est distingué par son numéro.

Le terme **port** est aussi parfois utilisé pour désigner les **interfaces de connexion**, un concept sensiblement différent.

o

#### Origine du mot

**Port**, en informatique, est une traduction erronée de l'anglais **port** (en) [archive] ; l'étymologie du mot au sens informatique est le latin *porta* (→ *porte*), et non *portus* (*→ port*)¹.

#### Explication métaphorique

Pour simplifier, on peut considérer les ports comme des *portes donnant accès au système d'exploitation* : (Microsoft Windows, Mac OS, GNU/Linux, Solaris...). Pour fonctionner, un programme (par exemple un jeu à accélération 3D/2D, ou un logiciel de retouche photo) ouvre des portes pour entrer dans le système d'exploitation, mais lorsque l'on quitte le programme, la porte n'a plus besoin d'être ouverte.

#### Utilité

Grâce à cette abstraction, on peut exécuter plusieurs logiciels serveurs sur une même machine, et même simultanément des logiciels clients et des serveurs, ce qui est fréquent sur les systèmes d'exploitation multitâches et multiutilisateurs.

#### Attribution des ports

Un numéro de port est codé sur 16 bits, ce qui fait qu'il existe un maximum

de 65 536 ports distincts par machine. Ces ports sont classés en 3 catégories en fonction de leur numéro :

* les numéros de port de 0 à 1 023 correspondent aux ports "bien-connus" (well-known ports), utilisés pour les services réseaux les plus courants.
* les numéros de ports de 1 024 à 49 151 correspondent aux ports enregistrés (registered ports), assignés par l'IANA

* les numéros de ports de 49 152 à 65 535 correspondent aux ports dynamiques, utilisables pour tout type de requêtes TCP ou UDP autres que celle citées précédemment.

Lorsqu'un logiciel client veut dialoguer avec un logiciel serveur, aussi appelé service, il a besoin de connaître le port écouté par ce dernier. Les ports utilisés par les services devant être connus par les clients, les principaux types de services utilisent des ports qui sont dits réservés. Par convention, ce sont tous ceux compris entre 0 et 1 023² inclus et leur utilisation par un logiciel serveur nécessite souvent que celui-ci s'exécute avec des droits d'accès particuliers. Les services utilisant ces ports sont appelés les services bien connus ("Well-Known Services").

Le fichier services indique la liste de ces services dits well-known. Sous UNIX, ce fichier est directement dans /etc ; sous Windows, ce fichier est par défaut dans C:\Windows\System32\drivers\etc. Les services les plus utilisés sont :

* 9, pour le WoL, Wake-on-LAN, c'est-à-dire le démarrage à distance par un câble réseau ethernet. Wake-on-LAN

* 20/21, pour l'échange de fichiers via FTP

* 22, pour l'accès à un shell sécurisé Secure SHell, également utilisé pour l'échange de fichiers sécurisés SFTP

* 23, pour le port telnet

* 25, pour l'envoi d'un courrier électronique via un serveur dédié SMTP

* 53, pour la résolution de noms de domaine en adresses IP : DNS

* 67/68, pour DHCP et bootpc

* 80, pour la consultation d'un serveur HTTP par le biais d'un navigateur web

* 110, pour la récupération de son courrier électronique via POP

* 123, pour la synchronisation de l'horloge : Network Time Protocol (NTP)

* 143, pour la récupération de son courrier électronique via IMAP

* 389, pour la connexion à un LDAP

* 443, pour les connexions HTTP utilisant une surcouche de sécurité de type SSL : HTTPS

* 465, pour l'envoi d'un courrier électronique via un serveur dédié utilisant une surcouche de sécurité de type SSL : SMTPS

* 500, port utilisé pour le canal d'échange de clés IPsec

* 554, port utilisé pour accepter les connexions client RTSP entrantes et pour fournir des paquets de données aux clients qui diffusent en utilisant RTSPT.

* 636, pour l'utilisation d'une connexion à un LDAP sécurisé par une couche SSL/TLS

* 1352, pour le protocole Lotus Notes Domino

* 1433, serveur de base de données MS SQL

* 1521, serveur de base de données Oracle Database

* 1723, pour l'utilisation du protocole de VPN PPTP

* 3306, serveur de base de données MySQL

* 3389, pour la prise de contrôle à distance RDP

* 5432, serveur de base de données PostgreSQL

* 6667, pour la connexion aux serveurs IRC

* 25565, port par défaut des serveurs Minecraft³,⁴,⁵
# Liste de ports logiciels

**Liste de ports TCP et UDP.**

Afin de permettre aux clients de connecter des serveurs, des numéros de ports logiciels sont bien connus.

Les informations qui suivent sont en général reprises par chaque système dans un fichier ; par exemple :

*Les ports affichés ci-dessous peuvent être changés selon la configuration du programme*

* sur Linux et OS X : /etc/services

* sur Windows : %SystemRoot%\system32\drivers\etc\services.

## II.1.2 LES VULNERABILITES INFORMATIQUES

### II.1.2.1 PRESENTATION

Dans le domaine de la sécurité informatique, une **vulnérabilité** ou **faille** est une faiblesse dans un système informatique permettant à un attaquant de porter atteinte à l'intégrité de ce système, c'est-à-dire à son fonctionnement normal, à la confidentialité ou à l'intégrité des données qu'il contient.

Ces vulnérabilités sont la conséquence de faiblesses dans la conception, la mise en œuvre ou l'utilisation d'un composant matériel ou logiciel du système, mais il s'agit souvent d'anomalies logicielles liées à des erreurs de programmation ou à de mauvaises pratiques. Ces dysfonctionnements logiciels sont en général corrigés à mesure de leurs découvertes, mais l'utilisateur reste exposé à une éventuelle exploitation tant que le correctif (temporaire ou définitif) n'est pas publié et installé. C'est pourquoi il est important de maintenir les logiciels à jour avec les correctifs fournis par les éditeurs de logiciels. La procédure d'exploitation d'une vulnérabilité logicielle est appelée exploit.

### II.1.2.2 Causes

Les vulnérabilités informatiques proviennent souvent de la négligence ou de l'inexpérience d'un programmeur. Il peut y avoir d'autres causes liées
au contexte comme l'évolution des technologies, notamment en cryptographie. Une vulnérabilité permet généralement à l'attaquant de duper l'application, par exemple en outrepassant les vérifications de contrôle d'accès ou en exécutant des commandes sur le système hébergeant l'application.

Quelques vulnérabilités surviennent lorsque l'entrée d'un utilisateur n'est pas contrôlée, permettant l'exécution de commandes ou de requêtes SQL (connues sous le nom d'injection SQL). D'autres proviennent d'erreurs d'un programmeur lors de la vérification des buffers de données (qui peuvent alors être dépassés), causant ainsi une corruption de la pile mémoire (et ainsi permettre l'exécution de code fourni par l'attaquant).

## II.1.2.3 Publication d'une vulnérabilité

### Méthode de publication

La méthode de publication des vulnérabilités est un sujet qui fait débat au sein de la communauté de la sécurité des systèmes d'information. Certains affirment qu'il est nécessaire de publier immédiatement toutes les informations à propos d'une vulnérabilité dès qu'elle a été découverte (full disclosure). D'autres prétendent qu'il est préférable de limiter en premier lieu la publication uniquement aux utilisateurs qui en ont un besoin important (divulgation responsable, voire coordonnée), puis après un certain délai, de publier en détail, s'il y a besoin.

Ces délais peuvent permettre de laisser le temps aux développeurs de corriger la vulnérabilité et à ces utilisateurs d'appliquer les patchs de sécurité nécessaires, mais peuvent aussi accroître les risques pour ceux qui n'ont pas ces informations. Les éditeurs de logiciels appellent cette méthode de publication la divulgation responsable et encouragent les chercheurs en sécurité à l'utiliser. En théorie, ces délais permettent aux éditeurs de publier les correctifs nécessaires pour protéger leurs logiciels et leurs utilisateurs, mais en pratique, cela ne les contraint pas à corriger les vulnérabilités. Il a ainsi pu arriver que certaines vulnérabilités soient restées non corrigées pendant des mois voire des années, tant qu'aucun exploit n'a été publié. Devant cette situation, certains ont décidé de 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.1.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.1.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.1.3 JOURNAUX DES EVENEMENTS (FICHIERS LOGS) ET SYSLOG

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

<figure><img src="image_9.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ème 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é 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.

## II.1.3.2 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

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

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>
## II.2 LES SCANNEURS DES PORTS (Balayage de ports)

### II.2.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é.

### II.2.2 Techniques de balayage des ports

#### II.2.2.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.
II.2.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.

II.2.2.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*

II.2.2. 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.

II.2.3. LE NMAP (Scanneurs des ports)

II.2.3.1 Présentation

Nmap
<figure><img src="image_11.png" /></figure>

<figure><img src="image_12.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**

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

**Nmap** est un [scanneur de ports libre](https://www.insecure.org/) créé par [Fyodor](https://www.insecure.org/) et distribué par Insecure.org. Il est conçu pour détecter les [ports ouverts](https://www.insecure.org/) ou identifier les [services](https://www.insecure.org/) hébergés et obtenir des informations sur le [système d'exploitation](https://www.insecure.org/) 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](https), [Mac OS X](https), [Linux](https), [BSD](https) et [Solaris](https).

Le code source de Nmap est disponible sous la licence [GNU GPL](https).

### II.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é.

### II.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.

## II.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.

### II.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

II.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_14.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_15.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_16.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_17.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_18.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_19.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_20.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

## II.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écifiiez '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_21.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_22.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_23.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_24.png" /></figure>

Source
192.168.0.8

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

<figure><img src="image_26.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_27.png" /></figure>

Source
192.168.0.8

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

<figure><img src="image_29.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_30.png" /></figure>

Source
192.168.0.8

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

<figure><img src="image_32.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_33.png" /></figure>

Source
192.168.0.8

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

<figure><img src="image_35.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_36.png" /></figure>

Source
192.168.0.8

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

<figure><img src="image_38.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_39.png" /></figure>

Source
192.168.0.8

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

<figure><img src="image_41.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><td>PORT</td><td>STATE</td><td>SERVICE</td></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 colspan="3">MAC Address: 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) | Recvd: 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_42.png" /></figure>

Source
192.168.0.8

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

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

Destination
192.168.0.7

* 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_45.png" /></figure>

Source
192.168.0.8

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

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

Destination
192.168.0.7
# 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_48.png" /></figure>

Source
192.168.0.8

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

Destination
192.168.0.10

<figure><img src="image_50.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_51.png" /></figure>

Source
192.168.0.8

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

Destination
192.168.0.10

<figure><img src="image_53.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 cup1

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></td><td></td></tr><tr><td>22</td><td>tcp</td><td>open</td><td>ssh</td><td>OpenSSH</td><td>4.5</td><td>protocol 2.0</td></tr><tr><td>111</td><td>tcp</td><td>open</td><td>rpc</td><td></td><td></td></tr><tr><td>631</td><td>tcp</td><td>open</td><td>pp</td><td>CUPS</td><td>1.2</td><td></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
## II.3 LE SCANNEUR DE VULNERABILITES

### II.3.1 Présentation

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.

### II.3.2 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.

### II.3.3 Principes de fonctionnement

#### II.3.3.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.

### II.3.3.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.

### II.3.3.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 pour Wordpress, 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.

## II.3.4 Outils proches des scanners de vulnérabilités

### II.3.4.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).

### II.3.4.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.

### II.3.4.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.

### II.3.4.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.

### II.3.4.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.

### II.3.5. 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.3.6 LE NESSUS

### II.3.6.1. Généralités

Nessus

<figure><img src="image_54.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

### II.3.6.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.

### II.3.6.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³.

### II.3.6.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.
## II.3.7. 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.

## II.3.8. Installation et configuration

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

Nessus Installation &
Configuration

Tenable
YouTube - 4 avr. 2012

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

How To Install &
Configure Nessus In
Windows

My I.T
YouTube - 29 oct. 2017

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

Video: Tenable
Appliance Installation &
Configuration - Blog

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

Jenko022
YouTube - 17 juil. 2014

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

Tenable
YouTube - 4 avr. 2012

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

Rahul Tyagi
YouTube - 26 janv. 2016
II.3.9. UTILISATION NESSUS

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

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

Une exception a été définie par farnold active depuis le
30 2009 10:07PM
## 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_63.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_64.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.3.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_65.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_66.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_67.png" /></figure>
L'onglet Scan options :

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

Ici vous choisirez 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_69.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.

Ayant 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>smtp (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>Vulnerability</td><td>general/tcp</td><td>The remote host is missing the patch for the advisory FEDORA-2007-293 (gnome-python2-extras).<br>The gnome-python-extra package contains the source packages for additional Python bindings for GNOME. It should be used together with gnome-python.<br>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.<br>Solution: Get the newest Fedora Updates<br>Risk factor: High<br>Nessus ID: 24729</td><td></td></tr><tr><td>Vulnerability</td><td>general/tcp</td><td>The remote host is missing the patch for the advisory FEDORA-2007-291 (kernel).<br>The kernel package contains the Linux kernel (vmlinux), 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.<br>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<br>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.<br>CVE-2006-5753:<br>Summary: Unspecified vulnerability in the listattr system call in Linux kernel, when a 'bad node' is present, allows local users to cause a denial of service (data corruption) and possibly gain privileges via unknown vectors.<br>Fixed broken SCSI CDROM IOCTLs.<br>Added Xen, which was missing from 1.2911.6.3<br>Solution: Get the newest Fedora Updates</td><td></td></tr></tbody></table>
## II.4 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..1u.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\..11.......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:

<table><tr><td>TCP: 63</td><td>(100.000%)</td></tr><tr><td>UDP: 0</td><td>(0.000%)</td></tr><tr><td>ICMP: 0</td><td>(0.000%)</td></tr><tr><td>ARP: 0</td><td>(0.000%)</td></tr><tr><td>EAPOL: 0</td><td>(0.000%)</td></tr><tr><td>IPv6: 0</td><td>(0.000%)</td></tr><tr><td>ETHLOOP: 0</td><td>(0.000%)</td></tr><tr><td>IPX: 0</td><td>(0.000%)</td></tr><tr><td>FRAG: 0</td><td>(0.000%)</td></tr><tr><td>OTHER: 0</td><td>(0.000%)</td></tr><tr><td>DISCARD: 0</td><td>(0.000%)</td></tr></table>

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_70.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_71.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_72.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

★★★★☆ 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_73.png" /><figcaption>### Install Snort 2.9.7 on Windows</figcaption></figure>

Steve Gantz
YouTube - 25 mars 2015

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

Steve Gantz
YouTube - 10 mai 2016

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

Michael Singh
YouTube - 27 oct. 2010

<figure><img src="image_76.png" /></figure>
## II.5 LA SURVEILLANCE ET ANALYSE DES JOURNAUX
LOGS (journaux d'évènements)

### II.5.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 chiffrer 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.php wizardy.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 :

```shell
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_77.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_78.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é.
## II.5.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_79.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...