====== Snort : détection d'intrusion =======
Contributeur : (SISR2-2017- Melvyn Bruneau){{ :snortlogo.png?200|}}

===== Présentation =====
Snort un outil qui permet de détecter des comportements anormaux sur un réseau informatique et :
  * d’alerter sur une console ou à un destinataire en cas d'activation d'une règle afin d’intervenir le plus rapidement lors d’attaques, d’indisponibilités des services, ou d’équipements
  * de journaliser les évènements de manière à pouvoir remonter la démarche ou l'historique d'une attaque

De plus il peut  venir en complément d'un pare-feu.

Un tel outil est capable de détecter des événements comme : 
  * Défaillance d’un service ou d’un système par débordement stack overflow
  * tentative de //scan de port// sur une machine
  * augmentation subite du trafic sur une interface réseau
  * augmentation anormale du temps de réponse d’un équipement ou d’un service
  * circulation d’un protocole illicite

Afin de prévenir ce genre de risque, la mise en place de l’outil <wrap em>snort</wrap> qui est libre et gratuit est une solution. 

L’installation sera effectuée sur une machine physique  connectée sur un port en miroir sur un switch pour que le serveur IDS puisse capturer un maximum de données sur le réseau.

===== Installation de l’outil snort =====
La description correspond à une installation sur un os Debian 8. Une fois Debian 8 installé, il faut vérifier que celui-ci est bien à jour. Pour cela effectuer les commandes //**apt-get update**//, et **//apt-get upgrade//**. 
 

Snort fait partie des packages disponibles dans les sources officielles.
<code lscript>apt install snort</code>

<WRAP center round info 60%>
[[snortold|Ancienne version]]pour une installation manuelle de snort
</WRAP>

==== 3 Test de la configuration snort ====
Afin de vérifier la bonne configuration du fichier snort.conf il est possible d’utiliser la commande suivante 
<code lscript>snort -T -c /etc/snort/snort.conf</code>
{{ :snortvalid.png?600 |}}

La configuration du fichier est validée.

===== Configuration du port miroir =====

Le miroir de port permet de renvoyer le trafic d’un port d'un switch sur un autre port. Dans notre cas afin d’avoir accès a un maximum de données on va faire un miroir de port entre un port 26 en mode  trunk vers le port ou est brassé notre serveur IDS le port 4. 

==== Configuration pour un switch Cisco ====
Le mirroring de port(s) sur Cisco passe par des **//sessions//** qui prennent une ou plusieurs **//sources//** vers une **//destination//**.

La syntaxe est : 
<code lscript>
//pour les ports source
monitor session <numero_session_mirroring> source interface <nom_interface> <sens_trafic>
//pour le port destination
monitor session <numero_session_mirroring> destination interface <nom_interface> 
</code>

  * La **//source//** peut être un **//port//**, une **//plage de ports//** ou un **//vlan//**.
  * On peut rediriger le trafic reçu (**//rx//**), transmis (**//tx//**) ou les deux (**//both//**)
  * La **//destination//** est un port unique.

**__Exemples__**
<code lscript>
monitor session 1 source interface fa 0/1 both
monitor session 1 source interface fa0/2 - fa0/4 tx
monitor session 1 source interface fa0/6 - fa0/8 rx
monitor session 1 destination interface fa0/2
</code>

On peut vérifier le paramétrage :
<code lscript>show monitor session 1</code>

==== Configuration pour le  switch D-link ====

Se rendre dans **// monitoring/ mirror/ port mirror settings //**.

Dans un premier temps il faut le state à //enable// pour activer le miroir de port ensuite dans //target port// il faut sélectionner le port de renvoi des données ici le port 4 enfin sur le port 26 il faut sélectionner //both// pour que le port 4 puisse envoyer et recevoir des paquets.
//Rx// c’est pour recevoir, et //Tx// c’est pour la transmission.

===== Configuration de règles snort =====
L’outil snort est maintenant opérationnel, il faut donc créer des règles afin de pouvoir détecter les éventuels problèmes sur le réseau (intrusion, panne de services, etc.…).
IL est possible de récupérer des règles directement sur le site snort. 

Pour configurer des règles personnelles il faut aller dans le fichier //** /etc/snort/rules/local.rules**//.

Voilà un exemple de règle créée pour la détection de scan de port sur le serveur portefeuille.
{{ :snortcommandeportefeuille.png?600 |}}

Une règle est construite avec différentes valeurs qui sont les suivantes.

^ Information  ^  Explication  ^
|Types d’actions de la règle| il existe différents types d’actions : \\ * alert - génère une alerte en utilisant la méthode d'alerte sélectionnée, et alors journalise le paquet \\ * log - journalise le paquet \\ * pass - ignore le paquet \\ * activate - alerte et alors active une autre règle dynamic \\ * dynamic - reste passive jusqu'à être activée par une règle activate, alors agit comme une règle log|
|le protocole à analyser entre TCP, UDP, ICMP| Dans notre cas c’est le protocole TCP qui est analysé.|
|L’adresse IP source avec son masque de sous-réseau que l’on souhaite analyser. |Dans notre cas la valeur est a any pour analyser toutes les adresses IP sources.|
|Le port utilisé par l’adresse IP source.| Cela peut-être un port défini (80, 22, 21) une plage de port 1 : 80 pour les ports de 1 à 80 par exemple. ou any pour analyser tous les ports.|
|L’opérateur de direction | Il permet de définir le sens du trafic :  il y a trois types de directions : \\ * ->  Le trafic venant de la source extérieure vers un réseau, ou une machine spécifique dans notre cas c’est l’analyse de tous les adresses IP vers le serveur Portefeuille 172.20.x.x/32 \\ * <- Le trafic inverse c’est-à-dire venant du réseau interne vers l’extérieur \\ * < > Le trafic bidirectionnel qui va analyser les échanges dans les deux sens.|
|L’adresse IP et le masque de sous réseau de la destination. | |
|Le port de l’adresse IP | ici any pour tous les ports.|
|L’option msg | Elle va permettre d’entrer un message spécifique afin que l’utilisateur puisse comprendre rapidement.|
|Sid | C'est l’identifiant unique pour identifier les règles il y a trois types : \\   * <100 Réservé pour une utilisation future \\ 100-999,999 Règles incluses dans la distribution de Snort \\ >1 000 000 Utilisé pour les règles locales \\ Dans notre cas la règle a un Sid 1 000 000 2 pour signifier que c’est la deuxième règle .|
|La révision | Elle indique un numéro de version, permettant de faire évoluer une règle dans le temps \\ Il faut faire très attention lors de la création de règle, c’est sensible à la casse, et le lancement d’analyse ne se lance pas. |

Voici ci-dessous des exemples de règles locales :
 {{ :snortregles.png?700 |}}

La règle numéro une va analyser les tentatives d’accès root aux nas, pour ce qui est de la seconde règle c’est l’analyse des scans port sur le serveur de portefeuille. Et enfin la dernière règle va analyser un accès FTP (port 21) non autorisé sur le serveur portefeuille. 

Liste des liens internet intéressant pour la construction de règles snort.
[[http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node31.html#keyword_sid]]
[[http://madchat.fr/reseau/ids%7Cnids/L'%E9criture%20de%20r%E8gles%20Snort.htm]]

===== Lancement de l’analyse =====
Snort a besoin d’être lancé pour remonter les alertes lors de problèmes sur le réseau. Il y a plusieurs types de commande de lancement.
  * Mode détection d’intrusion qui permet de remontée des alertes et prendre des décisions si nécessaires. <code lscript> /usr/local/bin/snort -A console -q -u snort -g snort -c /etc/snort/snort.conf -i eth0 </code> {{ :snortdetecintrusion.png?600 |}}
Toutes les alertes sont remontées sur la console automatiquement. Exemple en mode d’intrusion lors d’un accès au Nas avec le compte root ou une règle informe une tentative de connexion en tant que utilisateur root. De plus un fichier log va être créé automatiquement lors des alertes.
{{ :snortexec.png?600 |}}

  * Mode écoute est le mode sniffer c’est-à-dire qu’il analyse tous les paquets du réseau qui se lance par la commande snort-v la commande va générer beaucoup d’informations car il écoute tous les communications mais ne produit pas de fichier log.

{{ :snortderoulement.png?600 |}}

==== Lecture des logs ====
Les fichiers Logs sont stocké dans le répertoire //** /var/log/snort**// au format //Tcpdump log// pour lancer la lecture d’un fichier il faut utiliser la commande <code lscript>tcpdump –r <nomdufichier></code>. 

{{ :snortlogs.png?600 |}}
Dans le log de l’accès au nas par l’utilisateur root on retrouve l’adresse IP source vers le serveur nas avec le protocole FTP et l’utilisateur root.

==== Test de l’outil snort ====

__Test capture de communication__

Pour finaliser l’intégration de l’outil il faut effectuer différents tests. Tout d’abord il faut vérifier que celui-ci capture toutes les données sur le réseau.

Lancement de la commande snort-v et attendre les retours voire si on capture bien des paquets. Au lancement de la commande on obtient l’initialisation.
{{ :snortcapturetrafic.png?600 |}}
 
Ensuite on a le retour de nombreux paquets par exemple celui-ci-dessous lors d’une connexion sur le nas. 
{{ :snortcapturenas.png?600 |}}

On retrouve bien la source vers le Nas avec le protocole TCP.  Ensuite il va falloir arrêter la capture un ctrl+C suffit.

Une fois la capture arrêtée on a un récapitulatif sur la capture les paquets entrant et sortant, ainsi que les paquets qui ont été analyse. De plus on a aussi des informations sur les protocoles utilisés sur le réseau TCP, UDP, ARP, etc. … avec le nombre de paquets et le pourcentage. 
{{ :snortcapturepaquets.png?400 |}}

Le test de la capture est donc validé car il y a eu des captures TCP, UDP, ICMP.

__Test de détection d’un scan de port__

Le scan de port va permettre de trouver quels ports son ouvert sur une machine afin de trouver un protocole avec lequel on peut essayer d’avoir accès à une machine. Le but de la détection est de remontée l’information à l’utilisateur afin qu’il puisse bloquer le port concerné et évité l’intrusion.

Dans notre cas on à la règle suivante va permettre de remontée  une tentative de scan de port vers la machine portefeuille.
{{ :snortcommandeportefeuille.png?600 |}}

Lors de scans de port on doit avoir une alerte qui est remontée dans la console et inscrite dans le fichier log automatique lors du lancement de la détection d’intrusion.

__Lancement de la console de détection.__
{{ :snortscanconsole.png?600 |}}

Une fois la console lancée il va falloir lancer des scans de port via une machine  ici sous Windows avec un logiciel.
{{ :snortconsolezenmap.png?600 |}}

Le scan des ports nous montre qu’il y a différents ports ouverts sur le serveur portefeuille on a donc les ports sur lesquels il peut y avoir des tentatives d’attaque.

Le serveur d’intrusion a joué son rôle car il a remonté le scan des ports sur le serveur portefeuille  dans la console.
{{ :snortremontee.png?600 |}}

Les résultats obtenus sont le précèdent on voit bien que l’adresse IP 10.9.0.14 a contacté plusieurs fois le serveur 172.20.20.20 sur différents ports 443, 80, 554, 1720, 3306, 199… En peu de temps avec le message scan port portefeuille. La détection est donc opérationnelle.

__Détection d’accès non autorisé__ 
 
La détection d’accès non autorisé va permettre de remontée les alertes lorsqu’un utilisateur tente de se connecter avec un compte sur une machine ou services.

Par exemple l’accès en root au serveur nas avec la règle  suivante.
{{ :snortnas.png?600 |}} 

Il faut relancer la console de détection d’intrusion et essayer une connexion avec l’utilisateur root au nas.
{{ :snortremonteenas.png?600 |}}

La console ids remonte bien une tentative d’accès au nas  avec l’utilisateur root de l’adresse 10.9.0.14. La détection d’accès est donc opérationnelle.
{{ :snortremonteenas.png?600 |}}

__Détection d’un protocole non autorisé__
 
La détection d’un protocole non autorisé est importante, effet il peut permettre d’avertir  d’un problème sur le réseau (attaque, scan de port).

L’accès au serveur portefeuille via le port 21 était non autorisé. La règle suivante va donc remonter une alerte lorsqu'il y a une tentative d’accès via le port 21.
{{ :snortportrefus.png?600 |}} 

//Tentative d’accès au serveur portefeuille en telnet avec le port 21//.
{{ :snorttelnet.png?600 |}}

Le serveur de détection d’intrusion remonte bien l’alerte de tentative d’accès au portefeuille avec le port 21 la détection de protocole non autorisé est opérationnelle. 
{{ :snortremonteeport.png?600 |}}