Vous êtes sur la page 1sur 31

2/7/2010

Détection d
Détection d’intrusions
intrusions
SNORT
Osman SALEM
Université Paris Descartes
08 Février 2010

Détection d’intrusions (IDS)
• Système logiciel ou matériel
– Détection en temps réel de tentatives d’intrusion

1
2/7/2010

Pourquoi un IDS ?
Un IDS pourra détecter
– NetScan: Scan réseau
• Recherche d
Recherche d’une
une machine cible
machine cible
– PortScan: Scan de ports
• Vulnérabilité d’une service
– IDS application
• Détection des activités malveillantes en analysant les 
évènements observés par une application
– etc.
L’IDS fournit des alarmes pour l’administrateur
– Admin pourra améliorer la sécurité du réseau
– Administrateur pourra faire des investigations et 
remonter à l’attaquant

Différent type d’IDS
• IDS réseau (NIDS)‐ par ex. Snort, BRO
– Détection des activités malveillantes en analysant les flots 
y
d’information échangés sur un réseau
• IDS ordinateur hôte (HIDS)
– Détection des activités malveillantes en analysant les 
évènements observés par un ordinateur hôte
– Seulement couvre une machine
– IDS doit être placé sur le système où il y a des information 
critiques/sensibles pour l’entreprise

2
2/7/2010

IDS: méthode de détection
• Deux approches complémentaires:
1. La détection d’utilisation malveillantes selon la signature
• Si
Signature: N°
N° de port particulier, mots clés dans les données utiles, 
d i li lé d l d é il
etc.
• Base de données de signatures d’attaques doit être à jour
• Ne peut pas détecter les nouvelles attaques ou les variantes 
d’anciennes attaques dont les caractéristiques sont drastiquement 
modifiées
2. Détection d’anomalies
• Caractérisation du comportement «
Caractérisation du comportement « normal »
• Tout trafic déviant des caractéristiques normales est supposé 
malveillant (l’inverse n’est pas vraie)
• Peut détecter les nouvelles attaques dont les caractéristiques ne 
correspondent pas aux caractéristiques normales

Détection d’anomalies 
• Détection d’anomalies constatées sur le Système 
d’Information 
• Phase d
Phase d’apprentissage
apprentissage du comportement normal du 
du comportement normal du
système puis détection toute déviation par rapport 
au comportement normal
• Phase d’apprentissage : établir des profils 
correspondant aux comportements normaux
– par fonctionnement naturel des applications
– par habitude des utilisateurs
• Pas de connaissances à priori de l’attaque
• Encore en phase de recherche (en labo!)

3
2/7/2010

Faux negatifs vs. Faux positifs
• Faux positive : détection erronée
– Dét
Détection d’une activité légitime comme une activité 
ti d’ ti ité lé iti ti ité
malveillante
– Ex: un utilisateur a rentré un mauvais mot de passe 
plusieurs fois (erreur de typos)
• Faux négative : non détection d’une attaque
– Activité malveillante acceptée comme une activité légitime
p g
– L’alarme ne se déclenche pas durant l’attaque

Efficacité d’un IDS
• Précision: détection de vraies attaques et 
l’ b
l’absence des fausses alertes
d f l t
• Résistance aux attaques
– IDS doit tourner sur une machine bien sécurisée
• Détection en temps réel
– Temps entre l
Temps entre l’intrusion
intrusion et la détection
et la détection

4
2/7/2010

IPS et IDS
> Sécurité active (IPS: Intrusion Prevention System)
y Filtrer et bloquer des flux (IPS)
y Pé
Prévention
ti d des iintrusions
t i sur lle réseau/hôtes
é /hôt
y Défense proactive
y Fonctionnalité intégrée aux firewalls
y Un IPS ne remplace pas un firewall

> Sécurité passive (IDS: Instrusion Detection System)


y Détection/Reconnaissance d
d’intrusions
intrusions (IDS)

IDS: Signature
• Fonctions
– Capture de trames
• Routeur E/S (bordure), LAN, etc.
Routeur E/S (bordure) LAN etc
– Comparaison avec des signatures stockée en DB
• Signature: ensemble de règles pour détecter une intrusion
• Ex: any ICMP packet > 10.000 bytes
• Ex: un paquet FTP avec un contenu « User root »
– Les ingénieurs (connaissant bien les attaques) construit les 
signatures et les insèrent dans une BD
– Détection d
Détection d’activités
activités
– Déclenchement des alertes: (email, SMS, SNMP, pop‐up, 
etc.)
– Stockage de logs

5
2/7/2010

IDS: Signature
• Limitations
– Connaissance à priori de la signature de l’attaque pour 
pouvoir détecter l’attaque
pouvoir détecter l attaque
• il ne détecte pas les attaques dont on ne possède pas de 
signature 
• Ex: nouveaux attaques, modification de la signature, etc.
– Pas de connaissance sur l’intention des activités
• Déclenchement d’une alarme même si le trafic est légitime
– La BD de signature grandit
La BD de signature grandit
• Chaque paquet doit être comparer à chaque signature
• IDS surchargé par le traitement des paquets …
• Laisse passer certains paquets … ou jette les paquets …

Présentation

application
t
gateway firewall
Internet

Internal Web
network server DNS
FTP server
server

Demilitarized zone

= IDS sensor

6
2/7/2010

Système de détection d’intrusion

Sondes

7
2/7/2010

Comment évader de l’IDS ?
• L’intrus ne veux pas être détectée par l’IDS
• Souvent, l’intrus est très familier avec les IDS populaire et connait 
bien leurs faiblesses

• Technique fréquente: Fragmentation
• Pour détecter une activité malveillante, l’IDS doit capturer, stocker 
et analyser tous les fragments.
• Beaucoup de fragments s’étalent sur une longue période du temps 
=> IDS doit avoir de grandes zones tampons et une puissance de 
traitement pour rassembler ces fragments
traitement pour rassembler ces fragments

Comment évader de l’IDS ?
• L’attaquant crée deux fragments de chaque datagramme de l’attaque 
• Premier fragment avec un entête TCP avec un numéro de port 
inoffensif et pas fortement surveillé par la configuration de l’IDS 
(Ex:80)
• Deuxième fragment à un chevauchement avec le premier et 
comporte un numéro de port différent qui écrase le port originale
• IDS laisse passer les deux fragments
• Premier fragment pour un serveur WEB
• Deuxième fragment de la même session
• Une fois les deux datagramme arrive au serveur
Une fois les deux datagramme arrive au serveur
• Réassemblage de deux fragments avec la valeur du port dans le 
fragment numéro 2
• Segment dirigé vers un service vulnérable

8
2/7/2010

IDS evasion tool: FragRouter

Internet

attack attack IDS target


system obfuscation
(EX: nmap) (fragrouter)

• Sur
Sur le système Unix/Linux
le système Unix/Linux
• Fournit plus de 35 façons différentes pour la fragmention 
de données 
• Séparation de l’attaque de la fonctionnalité de 
fragmentation

IDS Snort
• Open source IDS
– 200,000 installations
• Sniffer & logger
ff gg
– Dispo : Linux, Unix, Windows firewall
– Peut facilement traiter 100 
Mbps du trafic
• Signatures (IDS)
– Rédigé par la communauté de  hub
Snort 
snort
– Toute personne peut rédiger  sensor
ses propres règles
p p g
– La plus grande collection de 
signatures pour un IDS 
• Snort: c’est la référence
internal
network

9
2/7/2010

Snort deployment
Switch SPAN port: (port 
Mirroring)
• fournit la fctionalité
de surveillance (monitoring)
firewall de tous le trafic sur le port SPAN 
• sélection des ports à 
mettre sur écoute
unidirectional firewall • pas besoin d’un hub
sniffing cable
hub
snort
sensor

switch snort
sensor
internal internal
network network

Snort et ses 4 modes

Snort fonctionne en 4 modes:


1. Sniffer (snort –vde): comme tcpdump, wireshark
2. Logger (snort –vde –l ./log)
3. NIDS (Intrusion detection system)
4. IPS (Intrusion prevention system)

10
2/7/2010

TCP/IP layer

Sniffer mode & logger mode
Sniffer mode
#snort ‐dev
‐d : imprime à l’écran les données dans les paquets
‐e : Imprime à l’écran l’entête ethernet (couche liaison)
‐v : verbose mode, pour l’affichage des informations 
contenus dans les entêtes TCP/IP
Logger mode
#snort –dev
dev –ll ./log
./log
‐enregistrement des paquets dans un fichier
‐l : répertoire pour enregistrer le fichier (./log dans 
l’exemple)

11
2/7/2010

Sniffer mode & logger mode

Snort en NIDS mode
• Détection d’intrusion selon les signatures
• Peut
P dé détecter diffé
différent type d’attaques
d’
• Différent façons de remonter les alertes
• Fichier, database, Log viewer, etc
• Snort –c /etc/snort/snort.conf

12
2/7/2010

Architecture de Snort en IDS mode
Composants sont
1 Décodeur
1. Dé d dde paquett Snort

2. Préprocesseurs Sniffing Packet Decoder

Data Flow
Preprocessor
3. Moteur de détection (Plug-ins)

4. Système de Detection Engine


(Plug-ins)
journalisation/alerte et les
modules de sortie Output Stage
(Plug-ins) Alerts/Logs

Snort preprocessors
pre‐ detect
libcap process output
engine

Quelques exemples:
• frag3
– Re‐assemblage de fragments pour le moteur de détection
– Rejet des fragments qui chevauchent
– Option Timeout : détermine combien du temps le fragment est gardé 
avant d’être rejeter
• Portscan
P
– Détection des anomalies port‐scan 
– Alarme quant le nombre de ports visité dépasse p dans s secondes, 
avec p et s configurable
– http_decode
– stream4

13
2/7/2010

Snort detection & output
pre‐ detect
libcap process output
engine

• Moteur de détection
– Recherche de signature dans les paquets
• Output
– Sorite de résultats
– Plusieurs types de sorties:
– Alert: syslog, text, database, unified
– Log: text, pcap, database, unified, CSV

snort.conf
Example:

var HOME_NET 193.152.1.1/24


var EXTERNAL_NET !193.152.1.1/24
Var HTTP_SERVERS 193.152.1.17
Var HTTP_PORTS 80 8080

14
2/7/2010

Snort Alert
• Pour un test rapide de snort :
– snort –A console –c /etc/snort/snort.conf
t A l / t / t/ t f
• D’une autre machine, utiliser nmap pour 
générer un scan port:
– nmap –sP <snort_machine_IP_address>
• Vous devez avoir l’alerte suivant:
03/27-15:18:06.911226 [**] [1:469:1] ICMP PING NMAP [**]
[Classification: Attempted Information Leak] [Priority: 2]
{ICMP} 192.168.1.20 -> 192.168.1.237

Règles: Syntaxe
• Exemple de règle
alert tcp any any ‐> 192.16.1.0/24 any (flags:SF; msg:"Possi. SYN FIN 
scan ;)
scan";)
• En‐tête de règle
– alert tcp any any ‐> 192.168.1.0/24 any 
• Action de la règle
– alert
– log
– Pass
– A i
Activate
– dynamic
• Le protocole
– tcp
– udp
– icmp

15
2/7/2010

Actions de base
1. alert – génère une alerte définie et 
journalise (log) le paquet
journalise (log) le paquet 
2. log – journalise le paquet
3. pass – ignore le paquet 
4. activate – déclenche une alerte et active une 
règle dynamique
5. dynamic – reste passif jusqu’à l’activation par 
une action activate dans une autre règle

Règles: Syntaxe
– L'adresse source et destination
alert tcp any any -> 192.168.1.0/24 any
any
Adresse IP suivi de ll'espace
espace d'adressage
d adressage
– 193.51.138.0/24
Opérateur de négation "!"
– !193.51.138.0/24
Pas de mécanisme par nom de domaine
– Le port source et destination
any alert
l t tcp
t any any -> 192.168.1.0/24
192 168 1 0/24 any
Port spécifique
Gamme de port avec ":"
– 1:1024
Opérateur de négation "!"
– !6000:6010

16
2/7/2010

Règles: Syntaxe
Opérateur de direction

– Indique l'orientation du trafic auquel la règle


s'applique
Unidirectionnel "->"
– log udp any any -> 194.78.45.0/24 any
Bidirectionnel "<>"
– log 193.51.138.0/24 any <> 194.78.45.0/24 any
Options de règles

(flags:SF; msg:"Possible SYN FIN scan";)


– Cœur du moteur de détection d'intrusion
– Combinaison de règles séparées par ";"
– Séparation du mot clé et de l'argument par ":"

Rule Format – Action
alert tcp 10.1.1.1 any ‐> 10.1.1.2 80 (msg:"foo"; 
content: bar ;)
content:"bar";)

• Tells snort what the rule does    
– In snort 
• pass alert log activate dynamic
– In snort‐inline
In snort inline
• pass alert log activate dynamic drop sdrop 

17
2/7/2010

Rule Format – Protocol
• alert tcp 10.1.1.1 any ‐> 10.1.1.2 80 
(msg:"foo";
(msg: foo ; content:
content:"bar";)
bar ;)

• Tells snort to look for a specific protocol
• Acceptable protocols:
– TCP
– UDP
– ICMP
– IP

Rule Format ‐ IP Address
• alert tcp 10.1.1.1 any ‐> 10.1.1.2 80 (msg:"foo"; 
content:"bar";)
• Examples
10.1.1.1
• @ IP source
10.1.1.0/24
• 10.1.1.0 through 10.1.1.255
!10.1.1.0/24
• anything but 10.1.1.0 through 10.1.1.255
y g g
[10.1.0.0/24,10.2.0.0./24]
• 10.1.0.0 through 10.1.0.255 or 10.2.0.0 through 10.2.0.255
![10.1.0.0/24,10.2.0.0./24] 
• anything but 10.1.0.0 through 10.1.0.255 or 10.2.0.0 through 10.2.0.255

18
2/7/2010

Rule Format ‐ Port
• alert tcp 10.1.1.1 any ‐> 10.1.1.2 80 (msg:"foo"; content:"bar";) 
• Examples:
any
80
1:1023
• 1 through 1023 (inclusive)
:1023
• less than or equal to 1023
10:
• greater than or equal to 10
!53
• not 53
!53:100
• not 53 through 100 (inclusive)

NOTE: NO PORT LISTS.  80,8080 IS NOT VALID!!!!

Rule Format ‐ Direction

• alert tcp 10.1.1.1 any ‐> 10.1.1.2 80 (msg:"foo"; 
content: bar ;)
content:"bar";)

‐>
– À partir du premier IP/Port vers le second IP/Port
– Sens unique
<>
• Deux sens : bidirectionnelle

19
2/7/2010

Rule Format ‐ variables
var EXTERNAL_NET any
var HTTP_PORTS 80
var SMTP_SERVERS 10.1.1.1

alert tcp $EXTERNAL_NET any ‐> 
$SMTP SERVERS $HTTP PORTS
$SMTP_SERVERS $HTTP_PORTS

Rule Format – Body
• alert tcp 10.1.1.1 any ‐> 10.1.1.2 80 (msg:"foo"; 
content: bar ;)
content:"bar";)

• Une paire de paramètres (clé:valeur;)
1. types du mot clé (keyword)
2. meta‐data

20
2/7/2010

Meta‐Data keywords
• Msg
– msg:"my evil attack"; 
g y ;
• Reference
– reference:url,www.snort.org;
• sid
– sid:100000;
• Rev
– rev:10;
• Classtype (see classification.config)
– classtype:attempted‐recon;
• Priority
– priority:3;

Payload 
• Content
– content:"foo";;
• Nocase
– content:"foo"; nocase;
• Rawbytes
– content:"foo"; rawbytes;
• Depth
– content:
content:"foo";
foo ; depth:10;
depth:10;
• Offset
– content:"foo"; offset:10;
• Uricontent
– uricontent:"foo";

21
2/7/2010

Complicated Payload Options
• distance
• Within
• Isdataat
• byte_test
• byte_jump
• pcre

Non‐Payload options:
• ack (TCP Acknowledge Number)
– ack:0;
k0
• dsize (Packet Size) 
– dsize:>10; 
• id  (IP ID)
– id:10;
• fragoffset (fragment offset)
– fragoffset:0;
• fragbits (IP fragment bits)
– fragbits:MD;

22
2/7/2010

More non‐payload options
• ttl (IP Time To Live)
– ttl:1; 
ttl 1
• tos (IP TOS)
– tos:30;
• ipopts (IP option)
– ipopts:lsrr;
• flags (TCP flags)
– flags:SF; 
• flow (TCP State)
– flow:to_server,established;

Even more non‐payload options:
• seq (TCP Sequence Number)
– seq:0;
0
• ttl (IP Time To Live)
– ttl:10;
• window (TCP Window Size)
– window:55808;
• itype (ICMP Type)
– itype:8;
• icode (ICMP Code)
– icode:0;

23
2/7/2010

Even more non‐payload options (again)

• icmp_id (ICMP ID) 
– icmp_id:0;
i id 0
• icmp_seq (ICMP Sequence Number) 
– icmp_seq:0;
• ip_proto (IP Protocol)
– ip_proto:6;
• sameip (Are the IPs the same)
– sameip;
• stateless (Not part of a flow)
– stateless;

Règles: Syntaxe
> msg
y Description de la règle
> flags
g
y Test des drapeaux TCP (ACK, SYN…), opérateur logique (+,*,!)
y Exemple : (flags:SF;msg:"SYN FIN scan")
> ack
y Teste le champ d’acquittement TCP pour une valeur donnée
y Exemple : (flags:A;ack:0;msg:"NMap TCP ping")
> TTL
y Teste la valeur du TTL
y Exemple : (alert tcp any any -> any any(msg: “Traceroute";TTL:1)

24
2/7/2010

Format de règles
alert tcp !10.1.1.0/24 any -> 10.1.1.0/24 any (flags: SF; msg: “SYN-FIN Scan”;)

• Deux parties pour une règle


• l’entête:
alert tcp !10.1.1.0/24 any -> 10.1.1.0/24 any
• les options:
(flags: SF; msg: “SYN-FIN Scan”;)

Alert tcp any any -> 10.1.1.0/24 100:600 (flags: S; msg: “HOULA
SYN Packet!”;)

Moteur de Détection : signature

Rule Header Rule Options

Alert tcp 1.1.1.1 any -> 2.2.2.2 any (flags: SF; msg: “SYN-FIN Scan”;)
Alert tcp 1.1.1.1 any -> 2.2.2.2 any (flags: S+; msg: “SYN Scan”;)
Alert tcp 1.1.1.1 any -> 2.2.2.2 any (flags: F; msg: “FIN Scan”;)

25
2/7/2010

Résultat 
• Les logs (suite)
– Visualisation des fichiers de log
Règle :
alert TCP any any -> $MY_NET any (msg:"NMAP TCP ping !"; flags: A; ack: 0;)

date heure port source port dest


@IP source @IP dest
protocole

n°d'ordre d’acquittement
drapeaux
type de en hexadécimal
n°séquence
service
temps de en hexadécimal n°d'ordre d'identification
vie restant du paquet

Les règles dans SNORT
• Les options d’une règle 
– L’option msg
• Le message d’alerte associé à une règle.

Règle: alert udp any any -> 129.210.18.0/24 31337 \


(msg: “Back Orifice”;)

Log: [**] Back Orifice [**]


05/10-08:44:26.398345 192.120.81.5:60256 -> 129.210.18.34:31337
UDP TTL:41 TOS:0x0 ID:49951
Len: 8

26
2/7/2010

Les règles dans SNORT
– L’option TTL
• Permet de specifier la valeur de TTL dans le paquet
P td ifi l l d TTL d l t
• Format: ttl: nombre

alert udp any any -> any any (msg: “Unix traceroute”; ttl: 100;)

– L’option ID
• 16‐bit dans l’entête du paquet IP

alert udp any any -> any any (msg: “Suspicious IP Identification”; ID: 0;)

Les règles dans SNORT
– L’option dsize (taille du payload)
– L’option sequence (numéro de sequence tcp)
p q ( q p)
– L’option Ack (numero de l’ack)

alert icmp any any -> 129.210.18.0 / 24 any \


(msg: “Large ICMP payload”; dsize: >1024;)

alert tcp any any -> any any \


(msg: “Possible Shaft DDoS”; seq: 0x28374839;)

alert tcp any any -> any any \


(msg: “nmap tcp ping”; flags: A; ack: 0;)

27
2/7/2010

Les règles dans SNORT
– L’option flags
– L’option content 
L’ ti t t

alert tcp any any -> any any \


(msg: “null scan”; flags: 0;)

alert
l t udp
d $EXTERNAL_NET
$EXTERNAL NET any -> > $HOME_NET
$HOME NET 53 \
(msg: “Exploit bind tsig Overflow attempt”; \
content: “|00 FA 00 FF|”; content: “/bin/sh”;)

La syntaxe de régles de Snort
• action proto src_ip src_port direction dst_ip dst_port (options)
• Ex : alert tcp any any -> 192.168.1.0/24 21 (content: "user
root";; msg:g "FTP root login";)
g ;)
• Ex : alert tcp any any -> 192.168.1.0/24 21 (content:
"USER root"; msg: "FTP root login";)
• Écrire une règle est un jeu d’enfant ?
– Non, pas vrai du tout
• Si le contenu est user<tab>root, la règle précédente ne
détecte rien
• alert tcp any any -> 192.168.1.0/24 21 (content: "root",
Pcre:"/user\s+root/i"; msg: "FTP root login";)

28
2/7/2010

Quelques règles de Snort

• bad‐traffic.rules exploit.rules scan.rules


• finger.rules ftp.rules telnet.rules
• smtp.rules rpc.rulesrservices.rules
• dos.rules ddos.rules dns.rules
• tftp.rules web‐cgi.rules web‐coldfusion.rules
• web‐frontpage.rules web‐iis.rules web‐misc.rules
• web‐attacks.rules sql.rules x11.rules
• p
icmp.rules netbios.rules misc.rules
• backdoor.rules shellcode.rules policy.rules
• porn.rules info.rules icmp‐info.rules
• virus.rules local.rules attack‐responses.rules

Une architecture de base
Sensor(s)

Server

ƒ Snort IDS
ƒ Detect Events
ƒ Forward Alerts

ƒ MySQL, Apache
S l
Syslog
Console ƒ Receives &
Stores Alerts

ƒ Web Browser
ƒ Displays Alerts

29
2/7/2010

IDS Snort & ses compagnons
• BASE+Snort+MySQL

ACID

Correspondance de signatures

Most rule matches


result of UDP traffic

30
2/7/2010

Références
• Écriture des règles Snort :
1. http://www.snort.org/docs/writing_rules/
2. http://www.groar.org/trad/snort/snort-
faq/writing_snort_rules.html
• Snort Rules Database
1. http://www.snort.org/snort‐db/

31