Version actuelle datée du 21 janvier 2021 à 18:55

Sommaire

1 Présentation générale
- 1.1 Description
- 1.2 Organisation du projet
2 Travail réalisé

Présentation générale

Description

Dans le cadre de notre Projet de Fin d'Etudes nous nous préparons pour les olympiades nationales des métiers en Cybersécurité.

Ce projet nous demandera de développer des compétences en sécurisation d'équipements réseaux, sécurisation d'environnement Linux (principalement CentOS), Windows. La deuxième partie de l'épreuve consiste à utiliser des méthodes Forensics et reverse engineering pour analyser des malwares ou des dumps de disques dur. La troisième partie est une attaque d'un environnement Windows et Linux où l'objectif est l'élévation de privilèges afin de devenir administrateur du réseau. La quatrième et dernière partie consiste à une cyberdéfense en temps réel, il s'agira de bloquer des attaques grâce à Palo Alto (une solution de pare-feu).

Ce projet est encadré par M. Thomas VANTROYS

Organisation du projet

Dans un premier temps nous avons choisi de nous familiariser avec tous les exercices fournis par l'expert métier (le guide de préparation est disponible sur le wiki) et nous ferons donc des fiches récapitulant les commandes à exécuter pour chaque exercice. L'objectif étant d'être capable de réaliser ces tâches le plus rapidement possible.

Au cours de ce projet nous installerons en salle E306 un Network Service Monitoring afin de surveiller l’activité des utilisateurs et de détecter d’éventuelles failles ou diffusion de malwares. Il faudra donc installer un port forwarding vers la machine pour intercepter toute l’activité du réseau et mettre en place des outils de monitoring comme Kibana pour visualiser cette activité et qualifier les menaces potentielles. Nous serons amené à réaliser un guide d’utilisation de ces outils afin de permettre la prise en main de cette solution après notre installation.

Travail réalisé

Prise en main des utilitaires de la compétition

Dans le cadre de la compétition, l'expert métier national Damien NAVILLIAT nous a transmis des exercices à réaliser pour s'assurer d'un niveau décent. Ces exercices (que vous pouvez retrouver dans le guide de préparation au bas du wiki) nous demande de savoir utiliser des utilitaires tels que certtool, OpenVPN, OpenSSL etc.

Nous avons donc réalisé chacun de ces exercices et fait des fiches qui nous permettront de nous entraîner et de réviser rapidement une solution.

Pour des raisons de lisibilité ces fiches seront uploadés par la suite sur ce wiki sous format pdf.

Cette étape a constitué la première grande partie de ce projet. La suite consistera à s'entraîner sur le sujet officiel de l'épreuve (disponible en bas de page également).

Nous avons également copié une image de VM CentOS disposant de tous les utilitaires nécessaires pour suivre le guide d'entraînement. Nous la mettrons à disposition pour que les autres élèves puissent s'entraîner.

Mise en place de supervision de la salle E306

Introduction

Splunk

Nous avons mis en place sur la VM security.plil.info un service de monitoring via Splunk. Le fonctionnement de cette supervision est la suivante :

Splunk est un SIEM (security information and event management), il permet donc de collecter, agréger, corréler et archiver les alertes détectées sur le réseau. Pour fonctionner un SIEM doit réceptionner des données. Nous avons donc besoin de mettre en place des IDS (Intruction Detection System) sur des équipements du réseau.

Nous installons donc Splunk sur security.plil.info et les Splunk forwarders sur les zabeth du réseau (au départ zabeth02, zabeth03 et zabeth18).

Splunk nous permet d'avoir une interface web permettant de visualiser les alertes remontées du réseau.

Splunk Forwarder

Les Splunk forwarders installés sur les zabeth sont assez simple à configurer : il suffit de préciser les ports et les ip pour la communication entre l'indexeur splunk et le forwarder. Il faut ensuite installer les IDS sur les zabeth.

On monitorera également les logs ssh des zabeth pour tracer les connexions et les tentatives de connexion au réseau.

Snort

Snort est un système de détection d'intrusion. Il permet de s'appuyer sur des règles (existantes ou à écrire) pour faire remonter des alertes. Nous l'utilisons ici par exemple pour détecter les scans de ports sur les zabeth.

Installation et configuration du serveur Splunk

Pour l'installation du serveur Splunk, nous devons télécharger le package directement sur le site, ce package est une version d'essaie complète de 60 jours, au delà de ce délai le serveur Splunk continuera à fonctionner mais en désactivant les options premiums. Celle-ci ne nous intéresse que très peu pour le monitoring de la salle.

wget https://www.splunk.com/bin/splunk/DownloadActivityServlet?architecture=x86_64&platform=linux&version=8.1.1&product=splunk&filename=splunk-8.1.1-08187535c166-linux-2.6-amd64.deb&wget=true
dpkg -i splunk-8.1.1-08187535c166-linux-2.6-amd64.deb

Une fois le SIEM installé, nous passons à la configuration, celui-ci doit être allumé en permanence pour pourvoir accéder aux données et aux alertes.

/opt/splunk/bin/splunk enable boot-start
/opt/splunk/bin/splunk start

Lors du premier démarrage de splunk, la création d'un compte administrateur est demandé, celui-ci nous servira à accéder à l'interface web. Il nous faut également configurer le port par lequel passeront les informations venant des forwarders, le port 9997 est celui utilisé par défaut mais il peut très bien être modifié.

/opt/splunk/bin/splunk enable listen 9997

Une fois cela fait nous pouvons vérifier le bon fonctionnement en nous rendant à l'adresse security.plil.info:8000.

Installation et configuration d'un splunk forwarder

Le Splunk forwarder est l'outils nous permettant de remonter un fichier de log au serveur, celui-ci nous permet donc de créer une connexion entre la machine sur lequel il est installé qui sera le client et la machine sur lequel est installé le serveur splunk.

Pour télécharger splunk forward il faut également passer par le site comme pour le package du serveur.

wget https://www.splunk.com/bin/splunk/DownloadActivityServlet?architecture=x86_64&platform=linux&version=8.1.1&product=universalforwarder&filename=splunkforwarder-8.1.1-08187535c166-linux-2.6-amd64.deb&wget=true
dpkg -i splunkforwarder-8.1.1-08187535c166-linux-2.6-amd64.deb

Une fois le forwarder installé, nous passons à la configuration, celui-ci doit être allumé en permanence pour pourvoir envoyer les données au serveur.

/opt/splunkforwarder/bin/splunk enable boot-start
/opt/splunkforwarder/bin/splunk start

Comme pour le serveur, il faut spécifier ou l'on va envoyer nos données, on ajoute donc un forward-server dans notre liste de forward-server avec la commande suivante.

/opt/splunkforwarder/bin/splunk add forward-server security.plil.info:9997

Pour vérifier que la communication se fait correctement nous pouvons utiliser la commande suivante.

/opt/splunkforwarder/bin/splunk list forward-server

Enfin la commande nous permettant de monitorer un fichier est la suivante

/opt/splunkforwarder/bin/splunk add monitor /path/to/app/logs/ -index main -sourcetype %app%

Installation et configuration de snort

Comme dit plus haut Snort sera notre IDS (Intrusion detection system), nous créerons des règles et celui-ci pourra lever des alertes quand les paquets qu'il récupèrera ne seront pas conformes à la règle.

Installation et configuration

Pour l'installation nous devons d'abord installer les dépendances :

sudo apt install -y gcc libpcre3-dev zlib1g-dev libluajit-5.1-dev libpcap-dev openssl libssl-dev libnghttp2-dev libdumbnet-dev bison flex libdnet autoconf libtool

Nous devons ensuite télécharger et installer les deux packages à installer pour le bon fonctionnement de snort.

wget https://www.snort.org/downloads/snort/daq-2.0.7.tar.gz
wget https://www.snort.org/downloads/snort/snort-2.9.17.tar.gz

tar -xvzf daq-2.0.7.tar.gz
cd daq-2.0.7
./configure && make && sudo make install

On retourne dans le dossier précédent.

tar -xvzf snort-2.9.17.tar.gz
cd snort-2.9.17
./configure --enable-sourcefire && make && sudo make install

Création de règles

Comme dit plus haut snort utilise un système de règles pour lever des alertes, pour savoir comment celle-ci fonctionnait et pouvoir écrire des règles qui nous intéresse nous nous somme aidé de ce lien qui est très complet.

https://paginas.fe.up.pt/~mgi98020/pgr/writing_snort_rules.htm

Une règle est de la forme :

alert tcp any any -> any any (content: "GET"; msg: "Récupération d'une page web"; sid:1;)

Si nous exécutons snort avec cette règle, celui-ci va écrire une alert dans un fichier dès que quelqu'un va essayer de récupérer une page web située sur notre ordinateur ou si nous cherchons à en récupérer une.

Si nous voulons enregistrer nos alertes dans un fichier spécifique nous pouvons rajouter cette ligne au début de notre règle:

output alert_full: alert.full

Cela nous permettra d'enregistrer nos alertes dans le fichier alert.full.

Mise en place du monitoring

Nous avons pour commencé déterminé avec les professeurs les éléments intéressant a monitorer, nous sommes donc parti sur le monitoring du protocole ssh, d'un monitoring préventif sur de l'arp spoofing et les tentatives de reconnaissances de l'utilitaire nmap ainsi que les packets sortant du réseau de la salle vers internet pour visualiser une potentielle attaque de dénie de service en partant des machines de la salle E306.

Création des alertes

Nous avons commencé par écrire nos alertes Snort nous permettant de lever les alertes que nous voulions. Après quelques recherche nous nous sommes rendu compte que les alertes permettant de prévenir de l'arp spoofing était très complexe à réaliser, cela semble possible car des thèses de recherches sur le sujet sont disponibles sur internet mais celle-ci sont payantes nous avons donc abandonnés cette partie.

output alert_full: alert.full
alert tcp any any -> any any (msg:"FIN Scan" ; flags: F ; sid:1;)
alert tcp any any -> any any (msg:"Xmas Scan" ; flags: FUP ; sid:2;)
alert tcp any any -> any any (msg:"Null Scan" ; flags: 0 ; sid:3;) 

alert tcp 2001:660:4401:6050::/64 any -> any any (msg:"Communication TCP" ; sid:4;)
alert udp 2001:660:4401:6050::/64 any -> any any (msg:"Communication UDP"; sid:5;)

Cette règle nous permet de lever des alertes à chaque détection d'un nmap ou dès qu'une communication UDP/TCP est établit depuis l'intérieur vers l'extérieur. Chaque alerte est enregistré dans le fichier alert.full.

Une alerte est de cette forme :

[**] [1:1:0] FIN Scan [**]
[Priority: 0]
01/07-16:24:20.934869 172.26.145.68:62097 -> 172.26.145.52:22
TCP TTL:51 TOS:0x0 ID:8369 IpLen:20 DgmLen:40
*******F Seq: 0xE478719E  Ack: 0x0  Win: 0x400  TcpLen: 20

Mise en forme des alertes avec Splunk

Pour pouvoir mettre en forme les alertes avec Splunk il faut tout d'abord envoyer les fichiers de logs a monitorer. Il faut ensuite se rendre sur l'onglet de recherche des alertes sur Splunk "Search and reporting", dans cette onglet nous pouvons sélectionner des filtres permettant d'affiner nos recherches sur les alertes qui nous intéressent.

La liste des filtres nous permettant d'affiner notre recherche ce forme toute seule mais nous pouvons également créer nos propres filtres grâce avec des expressions régulières et leur donner un nom afin de les appeler dans notre recherche. Comme nous pouvons le voir sur la photo beaucoup d'évènements sont renvoyés lors d'une connexion ssh, les filtres nous permettent donc de réduire notre champs de vision est de nous concentrer par exemple que sur les tentatives infructueuse.

Par exemple sur l'image du dessus nous ajoutons le filtre "sourcetype=amanite_auth_log" et le mot "failure", ce qui nous permet de ne récupérer que les alertes de ssh infructueux sur la machine amanite. Et comme nous pouvons le constater les tentatives sont nombreuses environs 10 par minutes. Notre machine amanite possède une ip routée, nous pouvons donc voir ici l'intérêt de ne pas utiliser un mot de passe bidon ou facilement trouvable dans les dictionnaires.

Nous pouvons voir que beaucoup d'évènements sont disponibles mais la mise en page n'est pas très visuel, nous allons donc tracer un graphique, pour ce faire nous appuyons sur "Statistiques" puis "Pivot". Cette fonction nous permet de tracer des multitudes de graphiques en fonction de nos besoins en isolant par exemple les machines depuis lesquels sont faites les connexions ou combien de requêtes sont émises.

Sur l'image du dessus nous pouvons voir le nombre colossale de tentatives infructueuse de connexion en ssh par jour. Ce sont en faites des bots qui tente de se connecter a notre machine en essayant des mots de passes basique issus de dictionnaires. Pour mieux visualiser cela nous pouvons afficher le nombre de requêtes par rhost (adresse ip de la machine tentant de se connecter).

Nous pouvons voir qu'environs une cinquantaine de bots ont tenté de se connecter dans la journée en faisant environs une trentaine de tentatives de connexion chacune. Lors d'une tentative, il faut que le mot de passe soit faux trois fois d'affilé pour que la connexion soit fermé, nous pouvons donc en déduire que les bots tentent environs une centaine de mots de passe chacun.

Le graphique du dessus nous semble être le plus pertinent celui-ci nous montre le nombres de bots tentant de se connecter a notre machine.

Familiarisation des failles de sécurité

Root Me

Sur la plateforme Root Me (https://www.root-me.org) nous avons à disposition des challenges et des images de machines à compromettre. Cela nous permet de nous familiariser avec des failles précises pour les challenges et de nous confronter à des situations "réelles" sur des machines à distance.

Nous avons réalisé 99 challenges (au 06/11/2020) sur ce site et 4 compromissions de machines.

TryHackMe

De la même manière le site TryHackMe met à disposition des rooms permettant de s'entraîner et de découvrir des frameworks, des méthodes et des failles à étudier.

Ce site est exclusivement en anglais et permet d'avoir accès à des VM configurées pour les rooms. L'utilisateur n'a donc qu'à se connecter au serveur de sa VM via un VPN et il peut commencer à apprendre.

Les cours s'organisent sous forme de TP et la communauté est très active sur les forums ou sur Discord.

L'inscription est gratuite mais il existe un mode premium permettant un accès à des rooms particulières.

Nous avons notamment travaillé sur le top 10 des failles OWASP (Open Web Application Security Project) qui sont des standards à maîtriser pour la compétition :

Injection

Les failles d'injections sont relativement communes dans les applications aujourd'hui. Ces défauts apparaissent lorsque le serveur traitent les inputs de l'utilisateur comme des commandes. De cette manière l'attaquant peut lancer des requêtes SQL par exemple. Ces failles peuvent êtres critiques car on peut récupérer les informations dans la base de données mais également la supprimer.

Broken Authentication

Cette faille consiste à casser ou à contourner le système de gestion de l'authentification et de la session. Cela passe par des attaques par bruteforce des utilisateurs et des mots de passes ou même des cookies de sessions qui permettent au serveur d'identifier l'utilisateur.

Sensitive Data Exposure

Les données utilisées par les applications doivent être impérativement chiffrées car un attaquant peut encore une fois récupérer les tables de la base de données et avoir accès à tous les utilisateurs, les mots de passes, les cartes de crédits etc. en clair.

XML External Entity

Permet d'exploiter les fonctionnalités d'XML pour interagir avec le back-end pour récupérer des fichiers. On peut réaliser des attaques par Déni de Service ou faire des SSRF (Server-Side Request Forgery) pour envoyer des requêtes à des applications à partir du serveur.

Broken Access Control

Si l'application est mal configuré on peut essayer d'accéder à des informations sensibles sur l'utilisation. Si un utilisateur arrive à accéder à une page de gestion du site la sécurité de l'application est compromise.

Security Misconfiguration

Les mauvaises configurations de sécurité apparaissent également souvent, si les permissions ne sont pas configurés, si les mots de passe des applications sont encore celles par défaut etc. Un attaquant n'a que quelques recherches à faire pour gagner l'accès à ces applications.

Cross-site Scripting

Aussi appelé XSS est une injection de code javascript, Flash, CSS etc. qui permet d'interagir avec le serveur. L'exploitation peut passer par exemple par l'upload d'un payload sur le serveur et la mise en place d'un reverse shell.

Insecure Deserialization

Il s'agit de remplacer des données exécuté par une application, ce qui permet d'envoyer un payload ou d'agir sur le système d'information. Ces failles sont assez difficiles à mettre en place car la méthode est propre à chaque application et l'attaquant doit donc faire beaucoup de recherches sur l'application avant de la mettre en place.

Components with Known Vulnerabilities

Beaucoup d'application aujourd'hui utilisent des versions de logiciels pas à jour. Il existe énormément de ressources (metasploit, exploit-db, les CVE) mettant en évidence les failles de logiciels avec leurs versions.

D'où l'importance de toujours faire les mises à jour de sécurité le plus rapidement possible.

Insufficent Logging & Monitoring

Toute action des utilisateurs devrait être enregistrée afin de pouvoir tracé les actions et estimer les risques de l'application.

Challenge DGSE - Brigitte Friang

Le 24 Octobre la DGSE (Direction Générale de la Sécurité Extérieure) a mis en ligne un CTF en équipe en partenariat avec l'ESIEE mettant à disposition de tous des challenges d'un niveau lycéen à expert.

https://www.defense.gouv.fr/dgse/tout-le-site/operation-brigitte-friang-prets-pour-relever-le-defi

La première partie du challenge était assez facile à réaliser : un directory traversal, une traduction en morse, l'analyse d'un schéma électronique, décrypter un message codé en AES 256 ECB etc.

La deuxième partie nous amène sur une plateforme de CTF avec des épreuves d'un tout autre niveau dans divers domaines.

Challenge 2e partie

Le write up des challenges est disponible à cette adresse : https://challenge-friang.gitbook.io/challenge-brigitte-friang/

Challenge DGA - DG'Hack

Le 12 novembre la DGA (Direction Générale de l'Armement) a également mis en ligne une série d'épreuves à réaliser. Au programme : de la stéganographie, du web, de l'inforensique et du reverse engineering.

https://www.dghack.fr/

Nous avons cette fois ci travaillé individuellement sur ces épreuves.

Les challenges nous ont permis d'utiliser les failles XSS, XSS avec obfuscation et CSRF pour le Web.

Le challenge de stéganographie nous donnait un fichier pcap et s'intitulait "Time for something different". Le fichier pcap ne contenait que des requêtes ICMP, toutes identiques sauf pour le temps de l'émission. La clé de ce challenge consistait à soustraire le temps n au temps n+1, multiplier le résultat par 100 et le transcrire en ascii. De cette manière on obtenait le flag pour valider.

Le challenge d'inforensique nous fournissait un dump d'un disque dur que nous devions monter. Il s'agissait d'une image d'un raspberry pi. Après avoir fouillé les fichiers on trouvait son utilité : permettre un backdoor sur l'infrastructure réseau. Le flag était le nom du programme permettant le backdoor.

Le challenge de cryptographie se basait sur le chiffre de Mersenne. Nous disposions du programme de cryptage ainsi que le message crypté. Nous devions donc trouver un moyen de décoder. Après plusieurs tests nous avons compris comment fonctionnait le programme et le nombre de possibilités de cryptage était limité à 26^3 puisque le programme prenait en entrée 3 charactères alphabétiques en minuscule. Nous avons donc coder un script de décryptage assez simple pour bruteforcer le fichier. Ce challenge a été un succès.

Cours Sécurité des réseaux informatiques

Nous avons suivi le cours Sécurité des réseaux informatiques sur la plateforme France Université Numérique. C'est un cours qui s'étend sur 5 semaines, accessible en ligne, et mettant à disposition des vidéos de cours, des TPs, ainsi que des QCM, un bureau d'étude et une évaluation finale.

C'est un cours très complet qui revient sur les couches liaison, réseau, transport et application. Il détaille les spécificités de ces couches, les protocoles utilisés ainsi que les failles possible à chaque niveau. Les TP à disposition permettent de mettre en œuvre ces attaques pour se placer du côté de l'attaquant. Le cours revient aussi sur les notions de filtrage, les différentes solutions possibles : proxy, firewall etc. Il aborde le côté cryptographique avec TLS, les méthodes symétriques et asymétriques de chiffrement, l'utilisation dans les normes de réseau wifi : WEP, WPA2, WPA-PSK, WPA-Enterprise et WPA3.

Nous avons suivi ce cours jusqu'à la fin et participé à l'évaluation finale avec une note de 15/16.

Fichier:Attestation suivi course-v1 MinesTelecom+04037+session01 5e94689935ce5a17e37b93d226b78ec5.pdf

Documents Rendus

Guide_de_préparation_métier_cybersécurité_-_Lyon_2020.pdf

Cahier_des_Charges.pdf

Cahier_des_spécifications.pdf

Fichier regroupant les différents protocoles de sécurisation de linux

@@ Ligne 38 : / Ligne 38 : @@
 ==Mise en place de supervision de la salle E306==
 === Introduction ===
+====Splunk====
 Nous avons mis en place sur la VM security.plil.info un service de monitoring via Splunk.
 Le fonctionnement de cette supervision est la suivante :
@@ Ligne 77 : / Ligne 78 : @@
 [[Fichier:splunk_page.png|800px|"Page d'authentification sur splunk"]]
+=== Installation et configuration d'un splunk forwarder ===
+Le Splunk forwarder est l'outils nous permettant de remonter un fichier de log au serveur, celui-ci nous permet donc de créer une connexion entre la machine sur lequel il est installé qui sera le client et la machine sur lequel est installé le serveur splunk.
+Pour télécharger splunk forward il faut également passer par le site comme pour le package du serveur.
+ wget https://www.splunk.com/bin/splunk/DownloadActivityServlet?architecture=x86_64&platform=linux&version=8.1.1&product=universalforwarder&filename=splunkforwarder-8.1.1-08187535c166-linux-2.6-amd64.deb&wget=true
+ dpkg -i splunkforwarder-8.1.1-08187535c166-linux-2.6-amd64.deb
+Une fois le forwarder installé, nous passons à la configuration, celui-ci doit être allumé en permanence pour pourvoir envoyer les données au serveur.
+ /opt/splunkforwarder/bin/splunk enable boot-start
+ /opt/splunkforwarder/bin/splunk start
+Comme pour le serveur, il faut spécifier ou l'on va envoyer nos données, on ajoute donc un forward-server dans notre liste de forward-server avec la commande suivante.
+ /opt/splunkforwarder/bin/splunk add forward-server security.plil.info:9997
+Pour vérifier que la communication se fait correctement nous pouvons utiliser la commande suivante.
+ /opt/splunkforwarder/bin/splunk list forward-server
+Enfin la commande nous permettant de monitorer un fichier est la suivante
+ /opt/splunkforwarder/bin/splunk add monitor /path/to/app/logs/ -index main -sourcetype %app%
+=== Installation et configuration de snort ===
+Comme dit plus haut Snort sera notre IDS (Intrusion detection system), nous créerons des règles et celui-ci pourra lever des alertes quand les paquets qu'il récupèrera ne seront pas conformes à la règle.
+==== Installation et configuration ====
+Pour l'installation nous devons d'abord installer les dépendances :
+ sudo apt install -y gcc libpcre3-dev zlib1g-dev libluajit-5.1-dev libpcap-dev openssl libssl-dev libnghttp2-dev libdumbnet-dev bison flex libdnet autoconf libtool
+Nous devons ensuite télécharger et installer les deux packages à installer pour le bon fonctionnement de snort.
+ wget https://www.snort.org/downloads/snort/daq-2.0.7.tar.gz
+ wget https://www.snort.org/downloads/snort/snort-2.9.17.tar.gz
+ tar -xvzf daq-2.0.7.tar.gz
+ cd daq-2.0.7
+ ./configure && make && sudo make install
+On retourne dans le dossier précédent.
+ tar -xvzf snort-2.9.17.tar.gz
+ cd snort-2.9.17
+ ./configure --enable-sourcefire && make && sudo make install
+==== Création de règles ====
+Comme dit plus haut snort utilise un système de règles pour lever des alertes, pour savoir comment celle-ci fonctionnait et pouvoir écrire des règles qui nous intéresse nous nous somme aidé de ce lien qui est très complet.
+ https://paginas.fe.up.pt/~mgi98020/pgr/writing_snort_rules.htm
+Une règle est de la forme :
+ alert tcp any any -> any any (content: "GET"; msg: "Récupération d'une page web"; sid:1;)
+Si nous exécutons snort avec cette règle, celui-ci va écrire une alert dans un fichier dès que quelqu'un va essayer de récupérer une page web située sur notre ordinateur ou si nous cherchons à en récupérer une.
+Si nous voulons enregistrer nos alertes dans un fichier spécifique nous pouvons rajouter cette ligne au début de notre règle:
+ output alert_full: alert.full
+Cela nous permettra d'enregistrer nos alertes dans le fichier alert.full.
+=== Mise en place du monitoring ===
+Nous avons pour commencé déterminé avec les professeurs les éléments intéressant a monitorer, nous sommes donc parti sur le monitoring du protocole ssh,  d'un monitoring préventif sur de l'arp spoofing et les tentatives de reconnaissances de l'utilitaire nmap ainsi que les packets sortant du réseau de la salle vers internet pour visualiser une potentielle attaque de dénie de service en partant des machines de la salle E306.
+==== Création des alertes ====
+Nous avons commencé par écrire nos alertes Snort nous permettant de lever les alertes que nous voulions. Après quelques recherche nous nous sommes rendu compte que les alertes permettant de prévenir de l'arp spoofing était très complexe à réaliser, cela semble possible car des thèses de recherches sur le sujet sont disponibles sur internet mais celle-ci sont payantes nous avons donc abandonnés cette partie.
+ output alert_full: alert.full
+ alert tcp any any -> any any (msg:"FIN Scan" ; flags: F ; sid:1;)
+ alert tcp any any -> any any (msg:"Xmas Scan" ; flags: FUP ; sid:2;)
+ alert tcp any any -> any any (msg:"Null Scan" ; flags: 0 ; sid:3;)
+ alert tcp 2001:660:4401:6050::/64 any -> any any (msg:"Communication TCP" ; sid:4;)
+ alert udp 2001:660:4401:6050::/64 any -> any any (msg:"Communication UDP"; sid:5;)
+Cette règle nous permet de lever des alertes à chaque détection d'un nmap ou dès qu'une communication UDP/TCP est établit depuis l'intérieur vers l'extérieur. Chaque alerte est enregistré dans le fichier alert.full.
+Une alerte est de cette forme :
+ [**] [1:1:0] FIN Scan [**]
+ [Priority: 0]
+/07-16:24:20.934869 172.26.145.68:62097 -> 172.26.145.52:22
+ TCP TTL:51 TOS:0x0 ID:8369 IpLen:20 DgmLen:40
+ *******F Seq: 0xE478719E  Ack: 0x0  Win: 0x400  TcpLen: 20
+==== Mise en forme des alertes avec Splunk ====
+Pour pouvoir mettre en forme les alertes avec Splunk il faut tout d'abord envoyer les fichiers de logs a monitorer. Il faut ensuite se rendre sur l'onglet de recherche des alertes sur Splunk "Search and reporting", dans cette onglet nous pouvons sélectionner des filtres permettant d'affiner nos recherches sur les alertes qui nous intéressent.
+[[Fichier:search_and_reporting2.png|1600px|"Page de recherche Splunk"]]
+La liste des filtres nous permettant d'affiner notre recherche ce forme toute seule mais nous pouvons également créer nos propres filtres grâce avec des expressions régulières et leur donner un nom afin de les appeler dans notre recherche. Comme nous pouvons le voir sur la photo beaucoup d'évènements sont renvoyés lors d'une connexion ssh, les filtres nous permettent donc de réduire notre champs de vision est de nous concentrer par exemple que sur les tentatives infructueuse.
+[[Fichier:search_and_reporting3.png|1600px|"Page de recherche Splunk 2"]]
+Par exemple sur l'image du dessus nous ajoutons le filtre "sourcetype=amanite_auth_log" et le mot "failure", ce qui nous permet de ne récupérer que les alertes de ssh infructueux sur la machine amanite. Et comme nous pouvons le constater les tentatives sont nombreuses environs 10 par minutes. Notre machine amanite possède une ip routée, nous pouvons donc voir ici l'intérêt de ne pas utiliser un mot de passe bidon ou facilement trouvable dans les dictionnaires.
+Nous pouvons voir que beaucoup d'évènements sont disponibles mais la mise en page n'est pas très visuel, nous allons donc tracer un graphique, pour ce faire nous appuyons sur "Statistiques" puis "Pivot". Cette fonction nous permet de tracer des multitudes de graphiques en fonction de nos besoins en isolant par exemple les machines depuis lesquels sont faites les connexions ou combien de requêtes sont émises.
+[[Fichier:search_and_reporting4.png|1600px|"Page de recherche Splunk 3"]]
+Sur l'image du dessus nous pouvons voir le nombre colossale de tentatives infructueuse de connexion en ssh par jour. Ce sont en faites des bots qui tente de se connecter a notre machine en essayant des mots de passes basique issus de dictionnaires. Pour mieux visualiser cela nous pouvons afficher le nombre de requêtes par rhost (adresse ip de la machine tentant de se connecter).
+[[Fichier:search_and_reporting5.png|1600px|"Page de recherche Splunk 4"]]
+Nous pouvons voir qu'environs une cinquantaine de bots ont tenté de se connecter dans la journée en faisant environs une trentaine de tentatives de connexion chacune. Lors d'une tentative, il faut que le mot de passe soit faux trois fois d'affilé pour que la connexion soit fermé, nous pouvons donc en déduire que les bots tentent environs une centaine de mots de passe chacun.
+[[Fichier:search_and_reporting6.png|1600px|"Page de recherche Splunk 5"]]
+Le graphique du dessus nous semble être le plus pertinent celui-ci nous montre le nombres de bots tentant de se connecter a notre machine.
 ==Familiarisation des failles de sécurité==

IMA5 2020/2021 P3 : Différence entre versions