Upload
aminelion
View
144
Download
3
Embed Size (px)
Citation preview
2/7/2010
1
Détection d’intrusionsDétection d intrusionsSNORT
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
2/7/2010
2
Pourquoi un IDS ?Un IDS pourra détecter
– NetScan: Scan réseau• Recherche d’une machine cible• Recherche d une 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 yd’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/7/2010
3
IDS: méthode de détection
• Deux approches complémentaires:1. La détection d’utilisation malveillantes selon la signature
Si N° d i li lé d l d é il• Signature: N° de port particulier, mots clés dans les données utiles, 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 « normal »• 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’apprentissage du comportement normal du• Phase d apprentissage 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!)
2/7/2010
4
Faux negatifs vs. Faux positifs
• Faux positive : détection erronéeDét ti d’ ti ité lé iti ti ité– Détection d’une activité légitime comme une activité 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égitimep 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 d f l tl’absence des fausses alertes
• Résistance aux attaques– IDS doit tourner sur une machine bien sécurisée
• Détection en temps réelTemps entre l’intrusion et la détection– Temps entre l intrusion et la détection
2/7/2010
5
IPS et IDS> Sécurité active (IPS: Intrusion Prevention System)
Filtrer et bloquer des flux (IPS)P é ti d i t i l é /hôt Prévention des intrusions sur le réseau/hôtes Défense proactiveFonctionnalité intégrée aux firewalls
Un IPS ne remplace pas un firewall
> Sécurité passive (IDS: Instrusion Detection System)Détection/Reconnaissance d’intrusions (IDS)Détection/Reconnaissance d intrusions (IDS)
IDS: Signature• Fonctions
– Capture de trames• Routeur E/S (bordure) LAN etcRouteur 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’activitésDétection d activités– Déclenchement des alertes: (email, SMS, SNMP, pop‐up, etc.)
– Stockage de logs
2/7/2010
6
IDS: Signature• Limitations
– Connaissance à priori de la signature de l’attaque pour pouvoir détecter l’attaquepouvoir 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 …
applicationt firewall
Présentation
Webserver
FTPDNSserver
gateway
Internet
Internalnetwork
firewall
server
Demilitarized zone
= IDS sensor
2/7/2010
7
Système de détection d’intrusion
Sondes
2/7/2010
8
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 fragmentstraitement 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 serveurUne 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
2/7/2010
9
IDS evasion tool: FragRouter
• Sur le système Unix/Linux
attacksystem(EX: nmap)
attackobfuscation(fragrouter)
IDS target
Internet
• Sur 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 & loggerff gg– Dispo : Linux, Unix, Windows– Peut facilement traiter 100
Mbps du trafic
• Signatures (IDS)– Rédigé par la communauté de
Snort – Toute personne peut rédiger
ses propres règles
snortsensor
hub
firewall
p p g– La plus grande collection de
signatures pour un IDS
• Snort: c’est la référenceinternalnetwork
2/7/2010
10
Snort deploymentSwitch SPAN port: (port Mirroring)• fournit la fctionalitéde surveillance (monitoring)
snortsensor
hub
firewall
firewall
de tous le trafic sur le port SPAN • sélection des ports à mettre sur écoute• pas besoin d’un hubunidirectional
sniffing cable
internalnetwork
snortsensor
internalnetwork
switch
Snort et ses 4 modes
Snort fonctionne en 4 modes:1. Sniffer (snort –vde): comme tcpdump, wireshark2. Logger (snort –vde –l ./log)3. NIDS (Intrusion detection system)4. IPS (Intrusion prevention system)
2/7/2010
11
TCP/IP layer
Sniffer mode & logger modeSniffer 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 –l ./log#snort dev l ./log
‐enregistrement des paquets dans un fichier‐l : répertoire pour enregistrer le fichier (./log dans
l’exemple)
2/7/2010
12
Sniffer mode & logger mode
Snort en NIDS mode
• Détection d’intrusion selon les signaturesP dé diffé d’• Peut détecter différent type d’attaques
• Différent façons de remonter les alertes• Fichier, database, Log viewer, etc
• Snort –c /etc/snort/snort.conf
2/7/2010
13
Architecture de Snort en IDS mode
Composants sont1 Dé d d t Snort1. Décodeur de paquet2. Préprocesseurs3. Moteur de détection4. Système de
journalisation/alerte et les
Packet Decoder
Preprocessor(Plug-ins)
Detection Engine(Plug-ins)
Sniffing
Snort
Data Flow
modules de sortie Output Stage(Plug-ins) Alerts/Logs
Snort preprocessors
libcappre‐process
detectengine output
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 rejeterP• Portscan– 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
2/7/2010
14
Snort detection & output
libcappre‐process
detectengine output
• 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/24var EXTERNAL_NET !193.152.1.1/24Var HTTP_SERVERS 193.152.1.17Var HTTP_PORTS 80 8080
2/7/2010
15
Snort Alert
• Pour un test rapide de snort :t A l / t / t/ t f– snort –A console –c /etc/snort/snort.conf
• 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èglealert 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
2/7/2010
16
Actions de base
1. alert – génère une alerte définie et journalise (log) le paquetjournalise (log) le paquet
2. log – journalise le paquet3. pass – ignore le paquet 4. activate – déclenche une alerte et active une
règle dynamique5. dynamic – reste passif jusqu’à l’activation par
une action activate dans une autre règle
Règles: Syntaxe– L'adresse source et destination
anyAdresse IP suivi de l'espace d'adressage
alert tcp any any -> 192.168.1.0/24 any
– Le port source et destination
Adresse IP suivi de l espace d adressage
Opérateur de négation "!" – 193.51.138.0/24
– !193.51.138.0/24
Pas de mécanisme par nom de domaine
l t t 192 168 1 0/24anyPort spécifique Gamme de port avec ":"
– 1:1024Opérateur de négation "!"
– !6000:6010
alert tcp any any -> 192.168.1.0/24 any
2/7/2010
17
Règles: Syntaxe
– Indique l'orientation du trafic auquel la règle s'applique
Opérateur de direction
Unidirectionnel "->" – log udp any any -> 194.78.45.0/24 any
Options de règles
Bidirectionnel "<>" – log 193.51.138.0/24 any <> 194.78.45.0/24 any
– Cœur du moteur de détection d'intrusion(flags:SF; msg:"Possible SYN FIN scan";)
– 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
2/7/2010
18
Rule Format – Protocol
• alert tcp 10.1.1.1 any ‐> 10.1.1.2 80 (msg:"foo"; content:"bar";)(msg: foo ; content: 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";)
• Examples10.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.255y 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
2/7/2010
19
Rule Format ‐ Port• alert tcp 10.1.1.1 any ‐> 10.1.1.2 80 (msg:"foo"; content:"bar";) • Examples:
any801:1023
• 1 through 1023 (inclusive):1023
• less than or equal to 102310:
• 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
2/7/2010
20
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
2/7/2010
21
Meta‐Data keywords
• Msg– msg:"my evil attack"; g y ;
• Reference– reference:url,www.snort.org;
• sid– sid:100000;
• Rev– rev:10;– 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:"foo"; depth:10;– content: foo ; depth:10;
• Offset– content:"foo"; offset:10;
• Uricontent– uricontent:"foo";
2/7/2010
22
Complicated Payload Options
• distance
• Within
• Isdataat
• byte_test
• byte_jump
• pcre
Non‐Payload options:
• ack (TCP Acknowledge Number)k 0– ack:0;
• dsize (Packet Size) – dsize:>10;
• id (IP ID)– id:10;
• fragoffset (fragment offset)– fragoffset:0;
• fragbits (IP fragment bits)– fragbits:MD;
2/7/2010
23
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)0– seq:0;
• ttl (IP Time To Live)– ttl:10;
• window (TCP Window Size)– window:55808;
• itype (ICMP Type)– itype:8;
• icode (ICMP Code)– icode:0;
2/7/2010
24
Even more non‐payload options (again)
• icmp_id (ICMP ID) i id 0– icmp_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;
> msgDescription de la règle
> flags
Règles: Syntaxe
gTest des drapeaux TCP (ACK, SYN…), opérateur logique (+,*,!)Exemple : (flags:SF;msg:"SYN FIN scan")
> ackTeste le champ d’acquittement TCP pour une valeur donnéeExemple : (flags:A;ack:0;msg:"NMap TCP ping")
> TTL TTLTeste la valeur du TTLExemple : (alert tcp any any -> any any(msg: “Traceroute";TTL:1)
2/7/2010
25
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
Alert tcp 1.1.1.1 any -> 2.2.2.2 any
Rule Options
(flags: SF; msg: “SYN-FIN Scan”;)Alert tcp 1.1.1.1 any -> 2.2.2.2 anyAlert tcp 1.1.1.1 any -> 2.2.2.2 any
(flags: S+; msg: “SYN Scan”;)(flags: F; msg: “FIN Scan”;)
2/7/2010
26
• Les logs (suite)– Visualisation des fichiers de log
Résultat
Règle :alert TCP any any -> $MY_NET any (msg:"NMAP TCP ping !"; flags: A; ack: 0;)
Règle :
date heure@IP source
port source@IP dest
port dest
protocole
drapeaux n°d'ordre d’acquittementen hexadécimal
n°d'ordre d'identificationdu paquet
temps de vie restant
n°séquenceen hexadécimal
type de service
Les règles dans SNORT
• Les options d’une règle – L’option msg
• Le message d’alerte associé à une règle.
alert udp any any -> 129.210.18.0/24 31337 \
(msg: “Back Orifice”;)Règle:
[**] 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
Log:
2/7/2010
27
Les règles dans SNORT
– L’option TTLP t d ifi l l d TTL d l t• Permet de specifier la valeur de TTL dans le paquet
• 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;)
2/7/2010
28
Les règles dans SNORT
– L’option flags
L’ ti t t– L’option content
alert tcp any any -> any any \(msg: “null scan”; flags: 0;)
l t d $EXTERNAL NET > $HOME NET 53 \alert udp $EXTERNAL_NET any -> $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: "FTP root login";) ; g 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";)
2/7/2010
29
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• icmp.rules netbios.rules misc.rulesp• backdoor.rules shellcode.rules policy.rules• porn.rules info.rules icmp‐info.rules• virus.rules local.rules attack‐responses.rules
Une architecture de baseSensor(s)
Server
Snort IDSDetect EventsForward Alerts
MySQL, Apache S l
ConsoleSyslogReceives & Stores Alerts
Web BrowserDisplays Alerts
2/7/2010
30
IDS Snort & ses compagnons
• BASE+Snort+MySQL
ACID
Correspondance de signatures
Most rule matches result of UDP traffic
2/7/2010
31
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/