INTRUSION DETECTION

AND
PREVENTION SYSTEM

Presente par:

Rafiatou kambia & Daniela sossou

 SOMMAIRE:
I-INTRODUCTION
II-LES COMPOSANTS DE SNORT
III-MODE DE FONCTIONNEMENT DE SNORT
V-3-ARCHITECTURE DU PROJET SNORT IPS
IV-INSTALLATION ET CONFIGURATION DE
L’ENVIRONNEMENT DU LAB
VI-DETECTION ET PRÉVENTION D’ATTAQUE AVEC
SNORT
A-ATTAQUE D’INJECTION SQL
B-ATTAQUE DU CROSS-SITE SCRIPTING (XSS)
C-ATTAQUE DU SSH BRUTE FORCE AVEC LE
THCHYDRA
D-ATTAQUE DDOS
E-ATTAQUE ETHERNALBLUE
VII-CONCLUSION
I-INTRODUCTION
Comme décrit sur le site officiel de SNORT, "SNORT est un système de
prévention et de détection d'intrusion réseau open source utilisant un langage
orienté règle, qui combine les avantages des méthodes d'inspection basées sur
les signatures, les protocoles et les anomalies ’’.
SNORT est l'IPS open source le plus utilisé à ce jour. De nombreux UTM(Unified
threat management) utilisent SNORT pour fournir des services à leurs clients.
SNORT a introduit le mode inline qui peut être utilisé pour rejeter des paquets.
Ainsi, en utilisant le mode en ligne, SNORT peut également être utilisé comme
pare-feu.

 Les protocoles sur lesquels tournent la solution SNORT :

Snort est une solution qui tourne sur les protocoles suivants :
-le protocole TCP :
TCP/IP signifie Transmission Control Protocol/Internet
Protocol (Protocol de contrôle des transmissions/Protocole
Internet). TCP/IP est un ensemble de règles normalisées
permettant aux ordinateurs de communiquer sur un réseau tel
qu'Internet.

-le protocole UDP

UDP (User Datagram Protocol) est un protocole de
communication alternatif au protocole TCP (Transmission Control
Protocol) utilisé principalement pour envoyer des messages courts appelés
datagrammes, mais, il s’agit d’un protocole moins fiable et sans connexion.

-le protocole ICMP (Internet Control Message Protocol -

Protocole de message de contrôle sur Internet) est un protocol de niveau
3 sur le modèle OSI, qui permet le contrôle des erreurs de transmission.
En effet, comme le protocole IP ne gère que le transport des paquets et
ne permet pas l'envoi de messages d'erreur, c'est grâce à ce protocole
qu'une machine émettrice peut savoir qu'il y a eu un incident de réseau.

le protocole IP : IP signifie « Internet Protocol », protocole Internet.

 Il représente le protocole réseau le plus répandu. Il permet de découper
l’information à transmettre en paquets, de les adresser, de les transporter
indépendamment les uns des autres et de recomposer le message initial à
l’arrivée. Ce protocole utilise ainsi une technique dite de commutation de paquets.

II-LES COMPOSANTS DE SNORT

Snort est constitué de cinq composants principaux, à savoir : les Décodeurs, les
Préprocesseurs, le Moteur de détection, le Système de journalisation et d'alerte
et les modules de sortie.
1-Décodeur de paquets
Le premier composant de Snort est le décodeur de paquets, qui collecte les
paquets de données provenant de différentes interfaces réseau et les rend
disponibles pour le prétraitement.
2-Préprocesseurs
Les préprocesseurs arrangent et modifient les paquets pour qu'ils soient
analysés par le moteur de détection. Certains préprocesseurs détectent les
anomalies de base et enregistrent les activités de scanning des ports en
fragmentant les paquets.
3-Moteur de détection
Le moteur de détection est le composant principal de snort IDPS. Sa fonction
principale est d'analyser les paquets qui passent par lui, de disséquer les
paquets et d'appliquer des règles aux différents composants du paquet/
4-Système de journalisation et d'alerte
Après la détection, l'activité est enregistrée ou une alerte est générée. Ce
processus est effectué par le système de journalisation.

5-Modules de sortie ou plug-ins

Les modules de sortie permettent à snort de transférer la sortie générée vers
des bases de données comme Mysql ou d'envoyer des logs au serveur Syslog.
Les modules de sortie ou les plugins peuvent contrôler le type de sortie
générée par le système de journalisation et d'alerte.

III-MODES DE FONCTIONNEMENT DE SNORT

SNORT peut être configuré pour fonctionner dans l'un des modes suivants
- Mode sniffeur : Si SNORT est exécuté en mode sniffeur , il capture tous
les paquets et les affiche à l'écran dans le terminal. En redirigeant la sortie
écran, il est possible de capturer tous les paquets dans un fichier. Ce mode est
largement utilisé pour résoudre les problèmes de réseau.
- Mode Packet Logger : Ce mode est similaire au mode sniffeur , mais au
lieu d'afficher les paquets à l'écran, SNORT enregistre tous les paquets dans un
fichier journal s'il fonctionne en mode Packet Logger (enregistreur de paquets).
- Mode NIDS (Network Intrusion Detection System) : NDIS est le mode le
plus largement utilisé par SNORT. Lorsque SNORT fonctionne en mode NDIS, il
permet d'écrire des règles qui serviront à inspecter les paquets du réseau.
SNORT vérifie chaque paquet et effectue une opération prédéfinie si une règle
correspond à un paquet.
Mode inline - C'est le mode le plus important pour écrire une règle de parefeu.
Lorsque SNORT fonctionne en mode inline, il capture les paquets, les analyse et
les élimine ou les laisse passer en fonction de la règle. Il utilise les iptables pour
éliminer les paquets..

IV-CONFIGURATION DE L'ENVIRONNEMENT DE LAB

Pour montrer l’importance de snort , nous allons mettre en place un lab
composé de quatre machines dont : - Une machine tournant Ubuntu
- Une machine tournant Kali linux

- Une machine tournant sur Windows 7 - Un serveur web :

Metasploitable 2.
Dans ce lab , nous allons déployer snort pour qu’il fonctionne en mode inline ;
pour cela la machine Ubuntu servira de routeur entre le réseau qu’on protège
et le réseau dans lequel se trouve l’attaquant. Ainsi aucun paquet ne pourra
quitter le réseau de l’attaquant vers le réseau qu’on protège et vis-versa sans
passer par la machine Ubuntu.
On installera donc snort par la suite sur Ubuntu afin qu’il analyse tous les
paquets provenant du réseau dangereux.
Les machines windows 7 et Metasploitable 2 serviront de machines victimes
pour les attaques que nous effectuerons se situeront dans le réseau qu’on
protège.
La machine Kali servira de machine attaquante et se situera dans le réseau
dangereux.

D’après l’architecture ci-dessus , on a ce qui vient :

- La machine Ubuntu a deux interfaces réseaux ; l’un dans le réseau de
l’attaquant , l’autre dans le réseau qu’on protège. Cela permettra à snort
d’analyser tous les paquets à destination des machines victimes.
Réseau dangereux (Internet) :10.10.20.0 /24
• Machine attaquante : 10.10.20.2
• Machine Ubuntu : 10.10.20.1 ( Il représente le Gateway par défaut de la
machine
kali)
Réseau à protéger : 10.10.10.0 /24
• Machine windows 7 : 10.10.10.3
• Machine Metasploitable 2 : 10.10.10.30
Machine Ubuntu : 10.10.10.1 (Il représente le Gateway par défaut des
machines windows et metasploitable).

1. Installation de snort sur Ubuntu

Pour installer snort sur Ubuntu , la manière la plus facile est d’utiliser la
commande suivante dans le terminal :

Etape1: préparation de l’installation: Installation des

modules
sudo apt-get update sudo
apt-get dist-upgrade
Rédemarer après ces commandes ci-dessus sudo
apt-get install build-essential
sudo apt-get install -y libpcap-dev libpcre3-dev libdumbnet-dev
sudo apt-get install -y zlib1g-dev liblzma-dev openssl libssl-dev sudo
apt-get bison flex
Etape2 :Installation du Daq cd
~/snort
wget https://www.snort.org/downloads/snort/daq-2.0.7.tar.gz
tar -xvzf daq-2.0.7.tar.gz cd daq-2.0.7
./configure make
sudo make install
Etape3: installation du snort cd
~/snort
wget https://www.snort.org/downloads/snort/snort-2.9.8.3.tar.gz
tar -xvzf snort-2.9.8.3.tar.gz cd
snort-2.9.8.3
./configure make
sudo make install sudo
ldconfig
sudo ln -s /usr/local/bin/snort /usr/sbin/snort

pour vérifier que snort est bien installé

sudo chown -R snort:snort /etc/snort sudo

chown -R snort:snort /var/log/snort
sudo chown -R snort:snort /usr/local/lib/snort_dynamicrules

cd ~/snort/snort-2.9.8.3/etc/ sudo cp
*.conf* /etc/snort sudo cp *.map
/etc/snort sudo cp *.dtd /etc/snort
cd ~/snort/snort-2.9.8.3/src/dynamic-
preprocessors/build/usr/local/lib/snort_dynamicpreprocessor/ sudo
cp * /usr/local/lib/snort_dynamicpreprocessor/

sudo mkdir /etc/snort sudo mkdir

/etc/snort/rules sudo mkdir
/etc/snort/rules/iplists sudo mkdir
/etc/snort/preproc_rules sudo mkdir
/usr/local/lib/snort_dynamicrules sudo mkdir
/etc/snort/so_rules

sudo touch /etc/snort/rules/iplists/black_list.rules

sudo touch /etc/snort/rules/iplists/white_list.rules
sudo touch /etc/snort/rules/local.rules sudo touch
/etc/snort/sid-msg.map sudo mkdir /var/log/snort
sudo mkdir /var/log/snort/archived_logs

sudo chmod -R 5775 /etc/snort sudo chmod -R 5775

/var/log/snort sudo chmod -R 5775
/var/log/snort/archived_logs sudo chmod -R 5775
/etc/snort/so_rules sudo chmod -R 5775
/usr/local/lib/snort_dynamicrules
2-modification du fichier de configuration de snort
Pour configurer snort, certaines lignes sont éditées dans le fichier snort.conf.
Nous pouvons utiliser l’utilitaire nano pour éditer le fichier
/etc/snort/snort.conf .
Tout d'abord, nous devons indiquer à Snort la plage réseau du réseau à
protéger . Pour ce faire, nous modifions la ligne 45 de snort.conf pour lui
indiquer les plages IP de ce réseau.
Notre réseau domestique est 10.10.10.0 avec un masque de sous-réseau de
24 bits 255.255.255.0 .
ipvar HOME_NET 10.10.10.0/24 (ligne 45)

3-Configuration du mode inline de snort

Pour exécuter snort en mode IPS, le DAQ est configuré pour utiliser le type
nfq et le mode inline à l'aide des paramètres dans le fichier de configuration
snort.conf Pour se faire, décommenter les lignes suivantes dans le fichier
snort.conf et configurez comme suit :
config daq: nfq config
policy_mode: inline config
daq_mode: inline

4-Ecrire des règles snort personnalisées

Par défaut, pour écrire les règles personnalisées pour notre projet , snort
mets à notre disposition le fichier local.rules. Pour l’éditer avec nano ,
on utilise la commande : nano /etc/snort/rules/local.rules
Ainsi on peut y écrire toutes les règles snort qu’on veut afin de protéger notre
réseau.
*Comment écrire une règle SNORT typique
Toute règle SNORT typique peut être divisée en deux parties différentes : l'en-
tête de la règle et les options de la règle.
Format de la règle Snort :
[action] [protocole] [ip] [port] [direction] [ip] [port] (rule-options)
En-tête de la règle
L'en-tête de la règle contient l'action de la règle, le protocole, les adresses
source et destination, les masques de réseau, ainsi que les informations sur
les ports source et destination.
Action de la règle : Cette variable indique quelle opération doit être effectuée
lorsque le paquet correspondant est arrivé. Les valeurs possibles sont alert ;
log ; pass ; activate ;dynamic ; reject ; sdrop.

alert - génère une alerte en utilisant la méthode d'alerte sélectionnée, puis

enregistre le paquet. log - enregistre le paquet pass - ignore le paquet
activate - alerte, puis activation d'une autre règle dynamique.
dynamic - reste inactif jusqu'à ce qu'il soit activé par une règle d'activation,
puis agit comme une règle d'enregistrement.
drop - bloque et enregistre le paquet
reject - bloque le paquet, l'enregistre, puis envoie une réinitialisation TCP si le
protocole est TCP ou un message ICMP port unreachable si le protocole est
UDP.
sdrop - bloque le paquet mais ne l'enregistre pas.
- Protocol - Cette variable indique le protocole que le SNORT doit
rechercher. Les valeurs possibles sont TCP , UDP, IP et ICMP sont possibles.

- Adresse IP - Il est possible de bloquer les requêtes provenant de certaines

adresses IP uniquement. SNORT analysera uniquement les paquets
provenant de l'adresse IP spécifiée dans cette variable. Si la valeur "any"
est spécifiée dans cette variable, SNORT analysera tous les paquets
provenant de n’importe quel réseau.
- Port- Il est possible de bloquer les requêtes pour certains ports seulement.
SNORT
analysera seulement les paquets pour le port spécifié dans cette variable. Si la
valeur "any » est spécifiée dans cette variable, SNORT analysera tous les
paquets.
- Opérateur de direction - Il est possible de configurer SNORT pour vérifier
uniquement le trafic entrant ou le trafic entrant/sortant. Pour spécifier
ceci, il y a deux opérateurs différents qui doivent être utilisés. "->" peut
être utilisé pour spécifier tout le trafic entrant (Requêtes), "<-" peut être
utilisé pour spécifier le trafic entrant/sortant.
Options de règles
L'écriture des options de règle est tout aussi importante que celle des entêtes
de règle. Voici quelques informations clés sur les options de règles.
- Toutes les options de règles SNORT sont séparées les unes des autres par "
;".
- Les arguments des règles sont fournis en utilisant " :".
- Le mot "PCRE" est utilisé pour spécifier le support des regex de style PERL.
- Dans le cas des règles d'application web, lorsque PCRE est utilisé sans
"uricontent", SNORT évalue uniquement le premier URI. Il est donc
conseillé d'utiliser soit content soit uricontent pour rechercher un motif
dans tous les URI. (Les chances de contournement sont possibles si elles ne
sont pas utilisées).

VI-DÉTECTION ET PRÉVENTION D’ATTAQUE AVEC SNORT

A-Attaque d’injection SQL
L'injection SQL est une sorte d'attaque par injection qui permet d'exécuter des
instructions SQL malveillantes. Ces instructions contrôlent un serveur de base de
données derrière une application web. Les assaillants peuvent utiliser les vulnérabilités
d'injection SQL pour contourner les efforts de sécurité des applications. Ils peuvent
contourner l'authentification et l'autorisation d'une page ou d'une application web et
récupérer le contenu de l'ensemble de la base de données SQL. Ils peuvent également
utiliser l'injection SQL pour inclure, modifier et effacer des enregistrements dans la
base de données. La vulnérabilité de l'injection SQL peut influencer tout site ou
application web qui utilise la base de données SQL, par exemple, MySQL, Oracle, SQL
Server ou autres. Les pirates peuvent l'utiliser pour accroître l'accès non autorisé à vos
informations sensibles, données clients, secrets commerciaux, innovations sous licence,
et ce n'est que la partie émergée de l'iceberg. Les attaques par injection SQL sont l'une
des vulnérabilités des applications web les plus expérimentées, les plus répandues et
les plus dangereuses.

Ce sujet étant très vaste, nous ne pourrons pas mentionner tous les détails de
l'injection SQL, mais nous en expliquerons quelques-uns en commençant par
les bases. Pour Se faire? nous utiliserons l'application web Mutillidae de
metasploitable2, qui est vulnérable aux attaques par injection SQL, à des fins
de démonstration.
1- Démarrer metasploitable2.
2- Allez dans le navigateur de la machine attaquante et tapez l’adresse ip de
metasploitable2
dans la barre de recherche du navigateur. Vous aurez l’interface web de
metasploitable devant vous .
3-Sélectionnez le lien "Mutillidae" et allez dans l'onglet "Login/Register" et
enregistrez-vous pour créer un compte.
Fournissez les informations nécessaires et cliquez sur le bouton "Créer un
compte".
Utilisons maintenant des techniques d'injection SQL pour contourner la page
de connexion.
Le contournement de la page de connexion est, sans aucun doute, l'une des
techniques d'injection SQL les plus populaires.
Découverte d'injections SQL dans le champ POST
La structure de connexion de Mutilidae est simple. Elle contient deux champs
de saisie (nom d'utilisateur et mot de passe), qui sont tous deux vulnérables.
Le contenu du back-end crée une requête pour approuver le nom d'utilisateur
et le mot de passes donnés par l’utilisateur.
Voici un aperçu de la syntaxe du code SQL de la page qui permet de récupérer
les informations des identifiants fournis depuis la base de données :
($query = "SELECT * FROM users
WHERE username='$_POST[username]' AND password='$_POST[password]'"
;).
Note :
Dans le code sql précédent , l'instruction SELECT * est utilisée pour extraire
tous les données de la table spécifiée avec l’instruction FROM ; donc de ta
table users dans notre cas. Ensuite La clause WHERE est utilisée pour filtrer
les données selon les conditions spécifiées ;ainsi nous devons définir la
condition de filtrage. Dans notre exemple la requête récupère donc juste les
données relatives au nom d’utilisateur et au mot de passe fournit.
Pour mieux comprendre le concept des requêtes, voici un lien qui pourra vous
êtes utile : https://sql.sh/cours/select
Pour contourner la connexion et accéder aux zones restreintes, l'attaquant
doit construire une section SQL qui rendra la condition "WHERE" du code sql
vraie. Par exemple, les données de connexion ci-jointes donneraient accès à
l'agresseur en abusant de la faiblesse présente dans le paramètre du mot de
passe. Pour le nom d'utilisateur, mettez par exemple « Rafia" ou ce que vous
voulez et pour le mot de passe, mettez (admin' OR '1'='1) puis essayez de
vous connecter, et vous verrez apparaître une page de connexion admin ; ce
qui montre que l’attaque à réussi.
Examinons un instant la requête générée avec les identifiants qu’on a fourni :
Selon la syntaxe du code sql qui gère la page , la requête SQL générée devrait
être (SELECT * FROM users WHERE username=‘Rafia' AND password='admin'
OR '1'='1').
En raison de la priorité des opérateurs, la condition "AND" est évaluée en
premier. Ensuite, l'opérateur "OR" est évalué, ce qui rend l'instruction
"WHERE" vraie. La condition sera valable pour toutes les lignes de la table
"users". Elle implique que le nom d'utilisateur donné n'est pas pris en
compte, et que l'agresseur sera connecté en tant qu'utilisateur principal dans
la table "users". Cela signifie également que l'agresseur n'a pas besoin de
connaître un nom d'utilisateur pour accéder au site ; la requête en découvrira
un pour lui !
Dans ces exemples simples, nous avons vu qu'un agresseur peut contourner
un système d'authentification par une injection de requêtes SQL. Sans limiter
les conséquences désastreuses que cela peut avoir, il est essentiel de
mentionner qu'une injection SQL peut avoir un impact de sécurité beaucoup
plus important qu'un contournement de login. Vous trouverez ci-dessous une
liste de commandes qui peuvent être utilisées pour le contournement de
l'authentification par injection SQL or 1=1 or 1=1-- or 1=1# admin’-- admin’/*
admin’ or ‘1’=’1 admin’ or ‘1’=’1'-- admin”/* admin” or “1”=“1 admin” or
“1”=“1”-- admin” or “1”=“1”# admin” or “1”=“1”/* admin” or 1=1 or ““=“
admin” or 1=1 admin” or 1=1-- admin” or 1=1#
Règle Snort pour prévenir l’injection SQL
Pour prévenir cette attaque , nous pouvons écrire une règle snort permettant
de rejeter toutes les requêtes vers notre serveur web qui comportent des
méta-caractères utilisées pour l’injection sql. En voici une :
reject tcp !$HOME_NET any -> 10.10.10.0/24 $HTTP_PORTS (msg:"SQL meta
characters detected";pcre:"/(\%3D)|(=)[^\n]*(\%27)|(\')|(\-\- )|(\%3B)/i";
classtype:Web-application-attack; sid:1000049; rev:5;)

La règle ci-dessus détecte la présence de méta-caractères utilisés pour les

injections sql. Ceci est réalisé en utilisant le mot-clé pcre dans les options de
la règle. Le mot-clé pcre permet aux règles d'être écrites en utilisant des
expressions régulières compatibles avec Perl. Le code ci-dessus vérifie la
présence de l'expression régulière suivante.
(\%3D)|(=) [^\n]* Le signe '=' ou son équivalent hexagonal %3D. Il autorise
ensuite la
présence de zéro ou plusieurs caractères non linéaires
(\%27)|(\') guillemet simple omniprésent ou son équivalent hexadécimal
(\-\-) vérification du double tiret
(\%3B)/ vérifie le point-virgule ou son équivalent hexadécimal

Alerte générée lors d’une attaque d’injection SQL :

Blocage de sql injection par snort :

B-Attaque Cross-Site Scripting (XSS)

L'une des caractéristiques les plus importantes d'une application web bien
protégée est le nettoyage des données, un processus dans lequel les entrées
de l'utilisateur sont traitées, en supprimant ou en transformant tous les
caractères ou chaînes de caractères dangereux. Les données non assainies
permettent à un attaquant d'injecter et potentiellement d'exécuter un code
malveillant. Lorsque cette entrée non nettoyée est affichée sur une page
web, cela crée une vulnérabilité de type Cross-Site Scripting (XSS). Autrefois
considérée comme une vulnérabilité à risque relativement faible, la
vulnérabilité XSS est aujourd'hui à la fois à haut risque et répandue, ce qui
permet aux attaquants d'injecter des scripts côté client, tels que JavaScript,
dans les pages web consultées par d'autres utilisateurs. Il existe trois
variantes de Cross-Site Scripting : stored, reflected,et DOM-based. Les
attaques XSS stockées(stored), également connues sous le nom de Persistent
XSS, se produisent lorsque la charge utile d'exploitation est stockée dans une
base de données ou mise en cache par un serveur. L'application web récupère
alors cette charge utile et l'affiche à toute personne qui consulte une page
vulnérable. Une seule vulnérabilité XSS stockée peut donc attaquer tous les
utilisateurs du site. Les vulnérabilités XSS stockées existent souvent dans les
logiciels de forum, en particulier dans les sections de commentaires, ou dans
les revues de produits. Les attaques XSS réfléchies eux , incluent
généralement la charge utile dans une requête ou un lien élaboré.
L'application web prend cette valeur et la place dans le contenu de la page.
Cette variante n'attaque que la personne qui soumet la demande ou qui
consulte le lien. Les vulnérabilités XSS reflétées(reflected) peuvent souvent se
produire dans les champs de recherche et de résultats, ainsi que partout où
les entrées de l'utilisateur sont incluses dans
des messages d'erreur. Les attaques XSS basées sur le DOM sont similaires
aux deux autres types, mais se déroulent uniquement dans le Document
Object Model (DOM) de la page. Nous n'entrerons pas dans les détails mais
un navigateur analyse le contenu HTML d’une page et génère une
représentation interne du DOM. Le JavaScript peut interagir par
programmation avec ce DOM. Cette variante se produit lorsque le DOM d'une
page est modifié avec des valeurs contrôlées par l'utilisateur. Les XSS basés
sur le DOM peuvent être stockés ou reflétés.
La principale différence est que les attaques XSS basées sur le DOM se
produisent lorsqu'un navigateur analyse le contenu de la page et que le
JavaScript inséré est exécuté. Quelle que soit la manière dont la charge utile
XSS est livrée et exécutée, les scripts injectés s'exécutent dans le contexte de
l'utilisateur qui consulte la page affectée. C'est-à-dire que c'est le navigateur
de l'utilisateur, et non l'application web, qui exécute la charge utile XSS.

Néanmoins, ces attaques peuvent avoir un impact important et entraîner le

détournement de session, la redirection forcée vers des pages malveillantes,
l'exécution d'applications locales en tant qu'utilisateur, etc.
Dans cette section, nous verrons quelques points clés pour identifier une
vulnérabilité XSS reflété dans une application web.
Examinons les étapes suivantes :
1. Nous utiliserons Damn Vulnerable Web Application (DVWA) de
metasploitable
Connectez-vous en utilisant les identifiants par défaut de l'administrateur
(admin comme nom d'utilisateur et mot de passe) et allez à XSS reflected.

2. La première étape du test d'une vulnérabilité consiste à observer la

réponse normale de l'application. Introduisez un nom dans la zone de
texte et cliquez sur submit. Nous allons utiliser bob :

3. L'application a utilisé le nom que nous avons fourni pour former une
phrase. Que se
passe-t-il si, au lieu d'un nom valide, nous introduisons des caractères
spéciaux ou des chiffres ? Essayons avec <'c'est le 1er test’> :

4. Maintenant, nous voyons que tout ce que nous mettons dans la zone de
texte sera
reflété dans la réponse ; c'est-à-dire qu'il devient une partie de la page HTML
de réponse.
5. Essayez d'introduire un nom suivi d'un code de script très simple,
Bob<script>alert('XSS')</script> :
La page a exécuté le script, provoquant l'apparition d'une alerte, de sorte
qu’on puisse conclure que cette page est vulnérable à XSS
Les vulnérabilités XSS se produisent lorsque la validation de l'entrée est faible
ou inexistante et qu'il n'y a pas de codage correct de la sortie, tant du côté
serveur que du côté client. Cela signifie que l'application nous a permis
d'introduire des caractères qui sont également utilisés dans le code HTML et,
lorsqu'elle allait les envoyer à la page, n'a suivi aucun processus d'encodage
(comme l'utilisation des codes d'échappement HTML &lt ; et ...) pour éviter
qu'ils soient interprétés comme du code source HTML ou JavaScript.

Règle Snort pour prévenir le xss attack

reject tcp !$HOME_NET any -> 10 .10 .20 .0/24 (msg:"CSS Attack
Attempted";pcre:"/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i";
classtype:Web-application-attack; sid:1000051; rev:6;)
La règle ci-dessus détectent et rejette les paquets si des attaques css sont
effectuées. Ceci est fait en utilisant le mot clé pcre dans les options de la
règle. Le code ci-dessus vérifie l’expression régulière suivante :
(\%3C)|<) vérification de l'ouverture d'une balise ou de son équivalent
hexadécimal
(\%2F)|\/)* la barre oblique pour la balise fermante ou son équivalent
hexadécimal
[a-z0-9\%]+ vérification de la chaîne alphanumérique à l'intérieur de la balise
ou de sa
représentation hexadécimale
((\%3E)|>) vérification de la fermeture d’une balise ou son équivalent
hexadécimal

C-Attaque de brute force SSH avec le THCHydra

Le THC-Hydra est un outil puissant d'attaque des services réseau en cours de
développement actif et il vaut la peine d'être maîtrisé. Nous pouvons l'utiliser
pour attaquer divers schémas d'authentification de protocole, y compris SSH
et HTTP. Les options standard comprennent –l pour spécifier le nom
d'utilisateur cible, -P pour spécifier une liste de mots, et protocol://IP pour
spécifier le protocole cible et l'adresse IP respectivement. Nous allons
attaquer notre serveur web metasploitable 2.
Pour ce faire , le protocole étant le ssh , nous lancerons la commande
suivante pour effectuer le brute force :
hydra -l msfadmin -P password.txt ssh://10.10.10.30
Ainsi si le mot de passe correspondant à l’utilisateur msfadmin est présent
dans le fichier de mots de passe alors l’attaque réussira .

Règle Snort pour prévenir le brute force ssh

reject tcp !$HOME_NET any -> 192.168.3.5 22 (msg:"SSH Brute Force
Attempt"; flow:established,to_server;detection_filter:track by_src, count
5, seconds 30; sid:1000001; rev:1;)
Dans cette règle nous avons une nouvelle option de règles qui est
detection_filter ;
nous allons donc l’expliquer : detection_filter définit un taux qui doit être
dépassé par un hôte source ou de destination avant qu'une règle puisse
générer un événement. detection_filter a le format suivant :
detection_filter : track <by_src|by_dst>, count <c>, seconds <s> ; track
by_src|by_dst
En définissant l’option track , le trafic est surveillé soit par l'adresse IP source,
soit par l'adresse IP de destination. Cela signifie que le comptage est
maintenu pour chaque adresse IP source unique ou chaque adresse IP
destination unique.
count c
Il indique le nombre maximum de correspondances de règles dans les s
secondes autorisées avant que la limite du filtre de détection ne soit
dépassée. C doit être non nul.
secondes s
Il indique la période de temps sur laquelle le compte est accumulé. La valeur
doit être non nulle. Ainsi , notre règle se déclenchera à chaque tentative de
connexion échouée depuis
n’importe quelle réseau différent de celui qu’on protège pendant une période
de vérification de 30 secondes, après les 5 premières tentatives de connexion
échouées
Ainsi , les tentatives de brute force seront donc bloquer après 5 tentatives
pendants 30 secondes.

Alerte de snort :

Attaque ssh résultats :

Connexion réussie :

Connexion refusée car bloquée par snort :

D-Attaque DDOS :

 Première étape :
 Alerte DDOS générée par snort :

 Deuxième étape :
L’accès à l’application :
  Rejet de l’attaque :

E-Attaque EthernalBlue

Première étape :

 Scan de la cible :

 L’exloit :
 La prise de contrôle :

 Recherche d’information sur le système :

 L’acquisition des privilèges :

 Création des fichiers sur le bureau ou dans le répertoire

système 32 :

 Capture d’écran de la cible :

  Alerte générée par snort pour avoir détecter une
attaque EthernalBlue :

 Essayons de bloquer l’attaque et vérifions l’alerte

générée par snort :

On remarque que l’attaque a échoué par la présence du

« fail » ,car snort l’a bloqué .

VII-CONCLUSION
En conclusion , nous pouvons constater que le système de détection et de
prévention Snort est un puissant dispositif qui permettra de détecter les
intrusions dans les réseaux d’entreprise et de les protéger contre les attaques
informatiques.
Comme nous l'avons vu, SNORT peut fonctionner comme un pare-feu
d'application web avec quelques limitations. Mais il est important de
comprendre que les vulnérabilités basées sur les applications sont différentes
dans chaque application et ne peuvent pas être résolues par une règle
générique, ce qui est possible dans la sécurité du réseau. De même, il n'y a
pas d'alternative au codage sécurisé ; l'ajout de telles règles génériques et la
protection de l'application ne sont qu'une ligne de défense supplémentaire et
ne peuvent être considérés comme une alternative à la validation correcte
des entrées. La meilleure approche pour toute organisation est d'effectuer
des tests de pénétration pour l'application, d'écrire des règles SNORT pour
protéger temporairement contre les attaques et de commencer à modifier
l’infrastructure pour une mise en oeuvre correcte de la sécurité.