modle CIDF et interactions entre composants d'un systme de dtection d'attaques contre les scripts CGI
Le dveloppement des rseaux et de l'Internet rend les problmes de scurit, de confidentialit, de disponibilit et d'intgrit excessivement proccupants . Il s'avre primordial de pouvoir dtecter une tentative d'attaque distance afin de prendre les dispositions ncessaires . Beaucoup de ces attaques consistent en des utilisations dtournes de la suite de protocoles TCP/IP, le "langage universel" des machines communicantes. Des dispositifs tels que les firewalls ( pare-feu ) permettent de limiter la porte de ces attaques mais il existe de multiples faons de contourner ces lignes de dfense; sans parler des problmes de failles logicielles qu'un attaquant avis pourra exploiter son avantage. Bien souvent, il est ncessaire d'analyser les fichiers de log produits par les sniffers ( "mouchards" ) pour dtecter les attaques . Pour des rseaux forte frquentation, cette tche peut s'avrer extrmement fastidieuse voire impossible pour un oprateur humain . Cependant, en raison de la structure des attaques sur TCP/IP, il est possible de dgager des "signatures" caractrisant trs prcisment ces attaques, permettant l'utilisation d'outils de recherche de motifs dans les fichiers de log.
Il faut tout de mme tre conscient du fait que les outils de recherche de motifs ne peuvent pas tre utiliss "tels quels" : en effet, les logs reprsentent des fichiers de trs grande taille et de nombreuses signatures diffrentes sont envisageables selon ce que l'on veut dtecter . Il faut donc pouvoir s'assurer que les outils de recherche sont bien optimiss pour cette tche en termes d'utilisation des resources telles que la mmoire; voire leur adjoindre des fonctionnalits complmentaires s'ils ne suffisent pas . Enfin, l'efficacit d'un systme de dtection d'intrusion, de faon gnrale, dpend de sa configurabilit ( ie possibilit de dfinir de nouvelles spcifications d'attaques et de les rajouter ), de sa robustesse ( ie sa rsistance aux "plantages" ) et de la faible quantit de "faux-positifs" ( fausses alertes ) et de "faux-ngatifs" ( attaques non dtectes ) qu'il gnre .
D'aprs la dfinition mentionne dans la FAQ IDS, la dtection d'intrusion consiste en un processus de dcouverte et d'analyse de comportement hostile dirig contre un rseau. Actuellement deux types de systmes de dtection d'intrusion existent et ont des champs d'action complmentaires : les systmes orients rseau ( ou Network based Intrusion Detection software, soit NIDS ) et les systmes orients poste ( Host based IDS, ou HIDS ) .
Les systmes orients poste ont pour rle de dterminer si un ordinateur donn est en train d'tre attaqu ou si celui-ci a dj t attaqu, rsultant en une compromission de la scurit et de l'intgrit du systme . La surveillance aprs attaque se fait gnralement par analyse des fichiers prsents sur la machine . Les principaux produits sur le march considrs comme des HIDS sont Tripwire ( logiciel comparant les sommes de contrle - checksums - des fichiers sensibles avec les valeurs calcules pour un tat "sain" ), les logiciels d'anti-virus, les logs systme come syslog ...
Les systme orients rseau s'occupent de surveiller le trafic sur le rseau en confrontant les paquets dtects un ensemble de signatures ou de rgles . Si les rgles sont violes ou si une signature s'applique, le NIDS enregistre l'vnement comme une attaque . Les principaux produits utiliss par la communaut informatique sont Snort, Real Secure de ISS, et Network Flight Recorder .
Les systmes de dtection d'intrusion comportent des lments communs ( modle CIDF, Common Intrusion Detection Framework ):
Un gnrateur d'vnements, c'est l'lment qui envoie des informations sur le systme surveiller . Le gnrateur joue donc le rle de "senseur" pour le systme de dtection d'intrusion . Pour l'analyse de logs, c'est typiquement le logiciel qui gnre ces logs . Notons que le gnrateur d'vnements peut agir en "temps rel", si celui-ci est par exemple coupl un sniffer . L'analyse se fera alors pratiquement " chaud" .
un moteur d'analyse ou "A-box", dont le rle est de manipuler les donnes envoyes par le gnrateur d'vnements dans le but de dtecter une attaque .
un systme de stockage, ou "D-box", permettant de conserver une trace des vnements que le moteur d'analyse a considr comme tant hostiles .
ventuellement, un gnrateur de contre-mesures ( "C-Box" ), visant si cela est possible contrer une attaque en cours . Bien sr, ce type d'lment n'a d'utilit que si la dtection d'intrusion se fait en temps rel, au moment mme o l'attaque a lieu .
La dtection d'intrusion a pour but de relever un comportement hostile . Il faut donc initialement dfinir ce qu'on entend par "comportement hostile" . Deux grandes approches existent pour conceptualiser ceci : la dtection par anomalie ( anomaly detection ) et la dtection par mauvaise utilisation ( misuse detection ) .
La dtection par anomalie consiste considrer comme hostile tout ce qui n'est pas normal, au sens o on cherchera plutt bien dfinir ce qu'est un comportement normal sur le rseau pour pouvoir y opposer toute dviance, que l'on considrera comme tant une attaque ( "si ce n'est pas normal, alors c'est dangereux" ). Cette approche comprend donc deux phases :
Extraction d'informations sur le milieu, afin de dfinir la "normalit",
Etablir les limites de la "normalit", au-del desquelles le comportement est ncessairement anormal .
Par opposition, la dtection par mauvaise utilisation considre comme normal tout ce qui n'est pas hostile : ici il est impratif de bien connaitre les attaques possibles et le mot d'ordre est plutt " si ce n'est pas dangereux, alors c'est normal" . Si la dtection par anomalie a l'avantage de pouvoir dtecter des attaques pas forcment connues ( et donc ncessairement non releves par l'approche par mauvaise utilisation ), la dtection par mauvaise utilisation assure cependant que ce qui est relev par le moteur d'analyse est une attaque avec une plus forte probabilit que pour l'approche prcdente ( la dtection par anomalie amne ncessairement un grand nombre de fausses alertes ). La dtection par mauvaise utilisation est d'autre part moins "lourde" mettre en application, puisqu'elle ne ncessite pas de phase de renseignements sur le milieu avant d'tre oprationnelle ( cette opration peut de surcroit s'avrer coteuse en temps et renouveler frquemment ) .
Pour implmenter ces approches, diffrentes mthodes sont actuellement dveloppes et utilises :
Systme expert: il s'agit d'un systme corrl une base de connaissances tablie par des experts humains, offrant des possibilits de rsoudre des problmes ou au moins de fournir une aide la dcision . De faon gnrale, le systme utilise la base de connaissances sous forme de rgles, dont l'activation provoque la dtection d'une attaque ou ventuellement l'appel de nouvelles rgles ( structure de type "si rgle n1 alors rgle n2 ..." ) . Il est ici crucial de pouvoir assurer la maintenance de la base de connaissances, et il est noter que la qualit de cette base dpend grandement de l'expert humain qui la dfinit .
Langage de spcifications : cette mthode consiste en des dclarations d'vnements en cours, compltes par un ensemble de rgles, de la forme "motif -> action" ( si motif est dtect, alors le systme provoque action ). Une fois tablies en fonction de ce qui est observ ( les dclarations gardent une trace sous forme d'arguments des spcificits de l'vnement ), les dclarations d'vnements sont confrontes aux motifs . Le langage dfini permet de rendre plus complexe les motifs utiliss par composition squentielle, possibilit de tenir compte de contraintes temporelles, etc ...
Systme scnarios : le systme compare ce qu'il observe un ensemble de scnarios prdfinis ( par exemple des attaques se droulant en plusieurs tapes ) . L'analyse consiste en la dtection de l'tape du scnario en cours, puis faire l'hypothse de la prochaine tape que l'on devrait rencontrer si ce scnario est effectivement en cours d'application . Le systme tente alors de dtecter cette prochaine tape dans les donnes qu'il possde. Au fur et mesure que les donnes sont analyses, le systme tient jour les probabilits d'occurence de chaque scnario . Ici encore, la dfinition des scnarios est une tape cruciale .
Analyse par automates : les attaques sont considres comme des suites de transitions d'tats du systme surveill . Les tats dans le motif d'attaque correspondent aux tats du systme et sont associs des tests logiques qui doivent tre valids avant de passer l'tat suivant . Les tats successifs sont relis entre eux par des arcs correspondants aux conditions requises pour changer d'tat .
Analyse par graphe : il existe certaines attaques sur les rseaux tels que les worms ( programmes se propageant de faon autonome de machine en machine, et utilisant chaque machine contamine comme "base de lancement" et pour une tche dfinie par l'attaquant : calcul parallle, ou bien tout simplement dsactivation de la machine ) dont l'activit est facilement reprsentable par un graphe de structure caractristique ( structure en arbre ou en ventail ) . L'ide de l'analyse par graphe est donc de construire un graphe reprsentant les activits et les machines sur le rseau protger : si le graphe prsente une structure similaire celle d'une attaque, alors le rseau est probablement soumis une activit hostile. Le type d'attaques que cette mthode permet de dtecter est cependant limit ( sweeps, worms ) .
Intelligence artificielle : l'utilisation d'outils capables de s'auto-configurer tels que les rseaux neuronaux permet de faciliter le travail des oprateurs humains, notamment dans le domaine de la classification. Cette mthode est donc particulirement indique si on a choisi l'approche par dtection d'anomalie . De plus ce systme est assez flexible par rapport aux modles utilisant des signatures, ce qui permet de dtecter de lgres variations dans les attaques . L'inconvnient majeur est la puissance de calcul ncessaire pour utiliser de tels outils ( notamment pour tablir un modle de convergence pour le rseau de neurones ).
La suite de protocoles Transmission Control Protocol/Internet Protocol tient lieu de standard mondial pour les communications sur les rseaux entre machines . Le modle sous-jacent est un modle de communication en couches, prsente de la plus "haute" la plus "basse" :
Couche Application : il s'agit de la couche la plus haute. Gnralement, l'implmentation de cette couche est assure par les logiciels prsents sur les machines faisant office de clients ou serveurs ( navigateur web, etc ... ).
Couche Transport : cette couche gre les dtails de la connexion entre deux machines communicantes, et s'occupe notamment d'assurer que les donnes arrivent bon port . La couche Transport comprend deux protocoles : TCP est un protocole dit sr car il dispose de mcanismes de contrle de transfert des donnes ( sommes de contrles, numros d'acquittement .. ), et est utilis pour les connexions entre deux machines o il est inacceptable que des donnes soient perdues ; UDP ( pour User Datagram Protocol ) est un protocole de transfert plus rapide mais on ne peut garantir que des donnes ne seront pas perdues en cours de route .
Couche Rseau ( ou couche IP ) : cette couche s'occupe de transmettre les donnes de la source la destination, tape par tape; une tape pouvant tre une passerelle comme un routeur .
Couche Physique : la couche la plus basse s'occupe des communications entre une machine et le support physique auquel elle est relie . Cette couche est souvent Ethernet .
La structure en couches de TCP/IP induit le concept d'encapsulation de paquets : chaque couche de la source est suppose envoyer des donnes la couche correspondante de la destination . Ces donnes se prsentent sous la forme de paquets, chacun comprenant les donnes utiles prcdes par un en-tte ( l'en-tte fournit des informations la couche tandis que les donnes peuvent tre entres par l'utilisateur, comme une requte HTTP par exemple ) . Or les couches ne peuvent discuter directement, puisqu'elles sont empiles . Ainsi, la couche application de la source doit d'abord passer son paquet la couche Transport, qui utilisera celui-ci en tant que donnes utiles et y rajoutera son propre en-tte, et ainsi de suite jusqu' la couche physique . On obtient une sorte de "poupe russe" qui sera dpile par la machine faisant office de destination : les informations contenues dans les en-ttes respectifs sont analyses et les donnes sont passes la couche suprieure pour traitement ultrieur; d'o la notion d'encapsulation . A priori les informations contenues dans un en-tte d'une couche donne ne sont pas redondantes avec celle de l'en-tte d'une autre couche, si bien que chaque couche reste indpendante l'une de l'autre . Cette proprit offre des possibilits d'attaques comme nous le verrons par la suite .
TCP/IP comprend trois protocoles principaux : TCP et UDP, qui se situent au niveau de la couche transport; et ICMP ( Internet Control Message Protocol ) qui se situe au niveau IP . UDP est un protocole sans connexion et sans garantie d'arrive des paquets . Il en rsulte une plus grande rapidit mais avec sans garantie que toutes les donnes arrivent comme prvu. Ce protocole est donc plus adapt aux transmissions courte distance, comme dans les intranets par exemple . Par opposition, TCP est un protocole orient connexion, cette connexion tablie entre la source et la destination permettant d'assurer que toutes les donnes ont bien t transmises . La connexion TCP est tablie lors du handshake TCP o les machines s'changent leurs numros d'acquittement initiaux respectifs . Par la suite, chaque paquet TCP contient ces deux numros d'acquittement ( et un "flag" Acknowledge ), incrments selon la taille des donnes envoyes, ce qui permet de dterminer exactement o en est le transfert de donnes : chaque paquet qui n'a pas t "acquitt" est rmis par sa source. TCP assure de cette faon que tous les paquets envoys sont reus . ICMP est un protocole de "debugging" des rseaux : il est utilis par les routeurs pour informer une source d'un problme de communication avec une machine distante, ou bien pour vrifier qu'une machine est atteignable sur le rseau ( le fameux "ping" ) . Le traffic ICMP peut tre broadcast ( ie tre destin toutes les machines d'un rseau en mme temps ), ce qui peut tre utilis dans une optique d'attaque .
Lorsque l'on cre un outil, on n'a pas forcment conscience que celui-ci peut quelquefois tre utilis des fins trs diffrentes de celles prvues au dpart. Ainsi, de mme qu'un marteau sert initialement enfoncer des clous mais peut galement tre utilis pour provoquer des dommages physiques sur une personne, il existe des utilisations dtournes de TCP/IP permettant de mener des "attaques" contre des machines ou des rseaux entiers . Nous nous intresserons ici aux attaques que l'on peut mener via ou sur les couches Transport et IP . Ces attaques sont de trois types:
Reconnaissance : ces attaques ne sont pas "destructrices" au sens o elles empchent une entit de fonctionner correctement, mais permettent d'acqurir des informations parfois cruciales pour mener une attaque de plus grande envergure plus tard. Il s'agit notamment
des PORT SCANS ( scanning de ports ) qui permettent de savoir quels services sont actifs sur un poste donn. Certains scanners comme nmap ou queso permettent en plus de dtecter le type de systme d'exploitation prsent sur la machine ( soit par interrogation directe des dmons : le "banner grabbing", soit par analyse de la structure des paquets : par exemple les paquets provenant d'une machine sous BSD ont des TTL fixs 64 )
des SWEEPS ( balayage ) qui permettent de dtecter quelles machines sont actives sur le rseau, ce qui permet de dresser une carte de cibles potentielles. Ces balayages sont gnralement effectus l'aide de requtes ICMP ( "ping" ) .
solution "hybride" : il s'agit d'un balayage effectu sur un port particulier ( par exemple, on contacte toutes les machines du rseau sur le port 25 ) . L'attaquant cherche dterminer quelles machines ont un certain type de service activ . Ces scans hybrides sont par consquent utiliss couramment pour dtecter les machines infectes par un trojan ( en gnral le port est suprieur 1024), ou bien si une faille existe sur le service vis .
Dni de Service ( DoS ou Denial-of-Service ) : l'quivalence de ce genre d'attaques dans "le monde rel" serait les attentats terroristes. Il s'agit d'empcher par tous les moyens les utilisateurs de se servir de ressources disponibles en temps normal. Ces attaques sont but purement "destructeur", au sens o une telle attaque ne permet pas l'attaquant de compromettre une machine ni de voler des informations ( bien que dans certains cas, l'attaque vise dsactiver le systme de dtection d'intrusion -par exemple l'attaque "stick", laissant thoriquement le champ libre l'attaquant ). De telles attaques sont souvent trs simples mettre en place et donnent une sensation de puissance l'attaquant ( il a la facult de bloquer un service selon son bon vouloir ), ce qui explique leur frquence. Ces attaques sont loin d'tre bnignes pour des entits dont la source de revenus est la mise disposition d'un service sur le rseau ( E-Commerce ... ). Les DoS peuvent quelquefois cacher aussi des attaques plus labores ( par exemple tre le prlude une attaque de type "Mitnick", ou bien attirer l'attention ... ). Enfin, la tendance actuelle la paralllisation avec des outils comme Trinoo, TFN ou StachelDraht, des Dnis de Service ( machines "zombies" coordonnes par un serveur qui leur indique quel moment lancer une attaque globale dvastatrice ) rend cette menace trs srieuse. Lors de l'attaque du dbut de l'anne 2000 mene par "mafia boy" contre les principaux bastions du cybermonde ( yahoo, cnn et e-bay ), on a ainsi mesur une dgradation de performance de l'internet au niveau mondial d'environ 20% . Ces sites, pourtant prpars une trs forte demande, se sont vus submergs par une demande quivalente un an de connexions en quelques heures... (
Consommation de bande passante : par inondation du rseau en utilisant la "force pure" ( par exemple un rseau muni d'une connexion de type T1 - 1.5 Mbps - inondant un modem 56 kbps ) ou une mthode d'amplification ( voir l'attaque smurf )
Consommation de ressources : l'attaque vise "brler des cycles" sur la machine en faisant travailler le processeur pour rien, occuper tout l'espace mmoire disponible ... en somme l'attaque vise les ressources du systme plutt que les ressources du rseau.
Failles dans les programmes : certains systmes d'exploitation ne savent pas bien grer les paquets inhabituels ( non prvus dans les RFC ) ou bien ne ragissent pas bien selon les stimulus . Ceci donne des attaques de type teardrop, land ,WinNUKE ...
Attaques sur DNS et Routage : pirater un cache de DNS ayant autorit pour une machine donne peut empcher quiconque souhaitant contacter cette machine d'y accder, ou pire l'envoyer sur une machine-leurre . De telles attaques ont lieu souvent et peuvent servir par exemple rcuprer des mots de passe ou des numros de carte de crdit si le site touch est un portail de e-business. Le dessin suivant illustre ce type d'attaque :
Dtournement de connexion : par dfinition ces attaques ne concernent que TCP. Les attaquants utilisent une faille dans le modle en couches de TCP/IP, l'aide de la technique dite de prdiction de Sequence Number. Un attaquant se prsente comme une machine autre ( gnralement une machine en laquelle la victime a "confiance", et qui a t mise hors service ) et envoie sous cette identit un paquet de synchronisation de connexion ( premire tape du "3-way handshake" de TCP ). La victime envoie son paquet de reconnaissance ( SYN/ACK ) avec son Sequence Number. Ce paquet ne peut tre intercept par l'attaquant en gnral, mais si celui-ci envoie un dernier paquet (ACK) avec son adresse relle, en ayant devin le SN de la victime correctement, alors la connexion sera tablie par l'attaquant , et la victime croira avoir affaire l'autre machine ( celle en qui elle a "confiance" ) . Cette attaque permet de contourner les barrires comme les mots de passe: on attend que l'une des victimes ait tabli une connexion complte et se soit authentifi avant de se faire passer pour lui .
La notation s'inspire des expressions rgulires ... ainsi {a,b} veut dire "soit a, soit b" et [ a - b] " n'importe quel lment entre a et b". && et || sont respectivement le ET et OU logiques.
Pour les signatures exactes, consulter le fichier signaturs.pl dans le repertoire logre.
Explicitons tout d'abord le format de sortie des " sniffers " ( convention TCPdump ) :
-TCP
Timestamp src.sport > dst.dport : flags data-seqno ack window urgent options
o flags est un sous-ensemble non-vide de FLAG = { S ( SYN ), F ( FIN ), P (PUSH ), R ( RST ) , . ( NOFLAG : pas de flag activ )}
data-seqno est de la forme Start-SN :End-SN( End-SN - Start-SN )
ack Vaut soit ACK ack-num ou est vide (). Idem pour urgent : URG ou vide ().
La principale option qui nous intresse est l'option de fragmentation : (frag ID :size@offset{+, }) ( le + indique que le paquet n'est pas complet )
L'en-tte TCP contient des champs "rservs" pour une ventuelle mise niveau du protocole . Si les bits correspondants sont activs, le sniffeur renvoie un message d'erreur ( le paquet TCP est non valide ) .
-UDP
timestamp src.sport > dst.dport : udp data
-ICMP
timestamp src > dst : icmp : message
Les champs laisss par dfaut ou omis peuvent prendre n'importe quelle valeur. On omettra en particulier le champ timestamp pour les attaques ponctuelles.
Les attaques dites "ponctuelles" sont celles dtectables sans problme sur une seule ligne du fichier de log . La plupart de ces attaques consistent en un seul paquet trs particulier ( au sens o il est aisment identifiable ), les autres sont bases sur la rptition ( en vue d'une inondation ) d'un paquet anormal, ce qui rend par consquent leur dtection possible sur un seul paquet. On trouve une bonne description des paquets anormaux les plus communs dans l'article de Karen Frederick.
-LAND
L'attaque consiste envoyer un paquet o la source et la destination sont les mmes : certains systmes d'exploitation ne savent pas grer ce type de paquets et on assiste un "plantage".
src.sport > src.dport
-BROADCAST TCP
tcp est un protocole orient connexion, un broadcast n'a pas lieu d'tre.
src.sport > [ 0 - 255 ].[ 0 - 255 ].[0 - 255 ].{0,255}.dport
-ATTAQUES SUR PORTS
tentative d'atteindre des ports interdits ou suspects : 0, ports typiques utiliss par les chevaux de troie ... Cette signature est parmi les plus vulnrables ( voir "les limites du modles" )
src.sport > dst.{0, 31337, ...} ( une liste de ports se trouve ici, une autre est accesible dans le rpertoire logre)
- WinNUKE
Cette attaque provoque un cran bleu sur les machines windows : le systme ne sait pas grer les paquets "urgents" destins au port netBIOS sous certaines conditions.
src.sport > dst.139 : flags data-seqno ack Window URG
- CRAFTED PACKETS
Ces paquets sont construits de toutes pices, en s'loignant dlibrment des spcifications dcrites dans les RFC. Les ractions des OS devant de tels paquets sont donc souvent imprvisibles . Dans le meilleur des cas, ces paquets sont ignors, sinon ils constituent un outil de choix pour le scanning car il ne sont pas mentionns dans les logs du systme ( seul un sniffer peut les dtecter ).
Src.sport > dst.dport : S && Flag data-seqno ack window urg
O Flag est un sous-ensemble non vide de { F ( FIN ), P (PUSH ), R ( RST ) }
(cas particulier : XMAS PACKETS -> Flag = { F ( FIN ), P (PUSH ), R ( RST ) } et urg = URG et ack = ACK ack-num)
Src.sport > dst.dport : S data-seqno ack window URG
src.spot > dst.dport : . data-seqno window ( paquet NULL )
- SYN FRAG
les paquets de synchronisation de connexion ne devraient jamais tre fagments, vu leur taille . De faon gnrale, tout paquet fragment au niveau de l'en-tte ( size < 20 octets ) est hautement suspect. Il peut s'agir d'un moyen d'chapper aux rgles d'accs des firewalls qui ne font pas de reconstruction des paquets en transit : le paquet que voit passer le firewall est destin un port autoris par la liste de contrle d'accs ( ACL ), mais lorsque la machine de destination reconstruira le paquet, le port originel peut tre "chevauch" par les donnes d'un paquet, et donc tre remplac ( voir attaque "teardrop"). Plus simplement, la fragmentation peut servir duper les IDS effectuant un simple pattern matching sur les paquets, la recherche d'une signature donne . La fragmentation permet ainsi de "diluer" dans la masse l'attaque, ou encore de la "brouiller" et la rendre indtectable par pattern matching simple ( voir l'article de Hoglund pour des exemples )
Src.sport > dst.dport : S data-seqno ack window (frag ID :size@offset{+, })
- SYN + DATA
Il peut s'agir d'une tentative d'chapper la dtection : il n'est pas prvu dans les RFC que des donnes circulent lors du handshake. Certains IDS ne s'occupant pas des paquets contenant des donnes, ces paquets anormaux passent travers les filtres .
Src.sport > dst.dport : S Start-SN : !Start-SN
(ie End-SN diffrent de Start-SN)
- ECHO-CHARGEN :
Cette attaque revient tablir une boucle infernale faisant converser indfiniment les ports echo (service renvoyant les caractres qu'on lui prsente en entre) et chargen ( service gnrateur de caractres alatoires ). Ce genre de traffic tant hautement inhabituel, l'attaque est dtectable avec un seul paquet, mme si elle s'apparente une attaque par flooding donc temporelle .
(Src.7 > dst.19 || src.19 > dst.7 ) : udp
- FRAGGLE-AMPLI
L'attaque fraggle ( de mme que l'attaque smurf, voir plus bas ) permet tout un chacun d'utiliser de grosses ressources pour frapper la victime, sans pour autant les possder . L'ide sous-jacente est d'envoyer une requte quelconque au nom de la victime auprs d'un rseau choisi qui servira "d'amplificateur" . Ainsi, la victime recevra les rponses (non sollicites ) d'un rseau entier, ce qui peut reprsenter un grand nombre de paquets traiter d'un seul coup, entrainant ainsi un Dni de Service . Bien entendu, les paquets d'initiation de l'attaque tant "maquills" ds le dpart, il est fort improbable que l'attaquant soit retrouv .
Src.sport > [0- 255].[0 - 255].[0 - 255].{0,255}.{19,7} : udp
Ici src est la victime ... et le rseau vis va faire office d'amplificateur d'attaque . Dans notre cas , la signature peut tre allge en indiquant simplement l'adresse broadcast du rseau protg.
- FRAGGLE-VICTIME
idem, mais cette fois-ci dst est la victime .
Src.{19,7} > dst.dport : udp
Ce pattern sera dtect n = m * r fois, o r est la taille du rseau amplificateur et m le nombre de requtes envoy par l'attaquant . On voit bien ici comment le rseau amplificateur permet d'accroitre linairement l'ampleur de l'attaque.
- WINFREEZE
Cette attaque consiste envoyer des informations de reroutage erronnes la victime, notamment en lui faisant "croire" que la victime est elle-mme la prochaine tape sur la route vers la destination voulue . Ainsi, lorsque la victime souhaite contacter cette destination, une boucle se cre avec les consquences attendues : un Dni de Service .
Src > dst : icmp : redirect IP to host dst
- SMURF-AMPLI
Il s'agit d'une attaque de type Fraggle, version ICMP .
src > [ 0 - 255 ].[ 0 - 255 ].[0 - 255].{0,255}:icmp: echo request
Sous cette dsignation, sont regroupes toutes les attaques dont la trace dans les fichiers de log est rpartie sur plusieurs lignes ( ie paquets ) parce que les paquets qui composent ces attaques, pris individuellement, sont plus ou moins inoffensifs : les attaques temporelles proprement parler ( scans, balayages et flooding ), pour lesquelles existent un seuil de tolrance ( nombre de connexions maximum autoris avant de considrer qu'il s'agit d'une attaque ); et les attaques par fragmentation ( attaques impliquant un seul paquet mais dcoup en plusieurs morceaux, telles que Teardrop et Ping of Death ).
Lorsque l'on cherche attaquer un ennemi, on passe d'abord un certain temps chercher ses faiblesses pour les exploiter. Les scans ont exactement ce but, puisqu'ils permettent de dterminer d'une part la topologie d'un rseau ( rle des sweeps ou "balayages" ) et d'autre part quels sont les services actifs sur une machine donne, les versions de leurs implmentation ( par exemple Sendmail 8.9.3, etc .. ) , voire quel est son systme d'exploitation ( port scanning ): il suffira ensuite de se renseigner sur les vulnrabilits des implmentations des services recenss ou du systme d'exploitation concern, puis d'exploiter ces failles tout seul ou l'aide d'un programme prt l'emploi ( si ce programme existe, il se trouve l ou l ). Le scan fait donc office de reconnaissance du terrain avant l'assaut.
L'attaquant envoie des paquets SYN vers les ports qui l'intressent en vue d'tablir une connexion complte (le traditionnel handshake ) .
Ds que le handshake est fini, la connexion est tablie, indiquant videmment qu'un service tourne sur le port vis . L'attaquant est alors libre de clore la connexion, en gnral sans change de donnes . Ce type de scan basique au possible, ralisable la main avec un client telnet, est cependant des plus mauvais sur le plan de la furtivit, puisque la connexion sera enregistre dans les logs ( le handshake tant complt ). Or d'un point de vue tactique, il est crucial que la reconnaissance soit furtive : d'abord pour ne pas alarmer la cible et ainsi la prvenir d'une attaque future, et ensuite parce que les traces du scan font remonter une adresse IP possde par l'attaquant, permettant une ventuelle identification ( l'attaquant devant rcuprer les rsultats du scan d'une faon ou d'une autre, l'adresse source utilise dans le scan n'est pas maquille et pointe vers une machine dtenue - lgalement ou non ! - par l'attaquant ).
Pour plus de furtivit, il est ncessaire de faire appel des techniques plus labores, ayant souvent recours des paquets construits directement par le logiciel de scanning et non plus par le systme d'exploitation ( ce qui ncessite, pour pouvoir lancer ce scan, les droits "root" sur la machine ... condition de plus en plus facile remplir avec le dveloppement des stations personnelles sous linux ) . Les descriptions suivantes sont inspires du manuel de nmap:
TCP SYN scan ( option -sS avec nmap ):
Cette commande fait rfrence la technique de scan "mi-ouvert" (half open), car le handshake est entam mais n'est pas complet. Un paquet avec le flag SYN est envoy vers la cible, comme lors d'une connexion normale, si ce n'est que le paquet a t "forg" par le programme et non par le systme d'exploitation. Si le port est ouvert chez la cible, celle-ci rpond avec un paquet SYN/ACK ( 2e partie du handshake ) . Le systme d'exploitation de la machine de l'attaquant dtecte ce paquet, considr comme non sollicit ( puisque la demande de connexion par SYN n'est pas passe par l'OS ), et y rpond par un paquet RST, fermant ainsi la connexion avant qu'elle n'ai t tablie . Si le port est ferm ( donc inutilis ), la cible rpond par un paquet RST . L' avantage de ce type de scan est qu'il ne sera pas la plupart du temps dtect par la cible ( au sens o la connexion ne sera pas recense ).
TCP stealth scan ( options -sX, -sF, ou -sN):
Ces scans sont encore plus furtifs et consistent en un "mapping invers", ie on va dtecter les ports ferms pour en dduire ceux ouverts. D'aprs la RFC 793 dcrivant TCP, voici les comportements attendus de la part d'une implmentation TCP, pour un port ferm :
L'ide est donc d'envoyer des paquets sans flag RST, et sans ouvrir de connexion, et d'attendre les rponses des ports ferms , pour finalement tablir une carte des ports ouverts par dduction . D'o les techniques "FIN scan" ( paquets FIN faisant office de sonde ), "XMAS scan" ( flags FIN, URG, PSH ) et "NULL scan" ( aucun flag activ ) . La furtivit est meilleure puisque aucune connexion n'est ralise . Ce scan peut aussi permettre de reprer le systme d'exploitation de la cible selon la rponse produite ( elle dpend de l'implmentation TCP de l'OS : par exemple ces scans ne marchent pas sur des cibles Windows NT/95 ).
UDP scan:
Il est possible d'utiliser UDP pour scanner les ports, afin de contourner les IDS surveillant le trafic TCP uniquement. Cependant les rsultats obtenus sont beaucoup plus alatoires, UDP tant un protocole sans connexion, ce qui ne garantit pas qu'un paquet lors du scan atteigne toujours la machine cible .
FTP bounce attack:
on utilise ici le fonctionnalit de proxy des serveurs ftp : selon la rfc 959, les serveurs doivnt permettre d'envoyer des fichiers vers n'importe quelle destination sur internet . Ceci laisse le champ libre pour tous types d'attaques, l'attaquant se faisant passer pour le site ftp utilis pour le rebond .
Lorsqu'on veut valuer la difficult de dtecter un scan, on est confront un paradoxe . En effet les scans peuvent tre la fois trs faciles et trs difficiles reprer : la dtection par signature permet de reprer les scans les plus "bruyants", o une centaine de ports est contacte en moins de 30 secondes. Les scans ayant recours aux techniques furtives dcrites plus haut ne sont pas relevs par syslog puisqu'il n'y a pas de connexion tablie, mais sont facilement reprables l'aide d'un sniffeur puisque les paquets sont anormaux . Pourtant, les dsavantagse majeurs de la dtection par seuil sont:
comment dfinir ce seuil ? : il est assez difficile d'tablir un seuil, mme d'aprs l'exprience, puisque cela reste assez subjectif ( " combien de connexions est-ce que j'autorise avant de considrer qu'il s'agit d'une attaque ?" ) . Pour le flooding, ces seuils varient galement en fonction du port vis. Et une fois que ce seuil est dfini ...
certains "faux ngatifs" ne peuvent tre vits : un attaquant sera indtectable s'il "dlaie" suffisamment son attaque pour passer en dessous du seuil; ou bien s'il "paralllise" son scan en utilisant plusieurs machines.
Ici la difficult, d'un point de vue algorithmique, est qu'il faudrait faire appel des "meta-patterns" pour modliser ces attaques. Voici quelques exemples :
- PORT SCAN ( dterminer les services prsents sur une machine )
Time1 src.sport1 >dest.dport1 && ( 0 ou plusieurs entres quelconques ) &&
... && ( 0 ou plusieurs entres quelconques ) &&
Timen src.sportn > dest.dportn
Avec Timen - Time1 < 1000 ms et dport1 != ... != dportn . n correspond au nombre maximal de ports "scannables" avant de considrer qu'il s'agit d'une attaque.
- MITNICK ATTACK (TCP) ( camouflage d'IP )
PORT SCAN sur dport &&
Time1 src1.sport1 > dest.dport : S && ( 0 ou plusieurs entres quelconques ) &&
Time2 src2.sport2 > dest.dport : flags data-seqno ACK
La signature dcrit ici "l'attaque historique" mene par Kevin Mitnick contre le rseau de Tsutomu Shimomura, du point de vue de la machine attaque ( dest ). Dans ce cas particulier, il existait une " relation de confiance " ( . rhosts ) entre src1 et dest.On prfrera la signature "TCP HIJACK" pour une dtection plus gnrale des dtournements de connexion.
- STICK ( dsactivation distance de certains NIDS par dni de service )
Time1 src.sport1 >dest.dport R && ( 0 ou plusieurs entres quelconques ) &&
... && ( 0 ou plusieurs entres quelconques ) &&
Timen src.sportn > dest.dport R
Timen - Time1 < 1000 ms.
Contrairement aux attaques ponctuelles et assimiles, la dtection dans les logs des attaques temporelles devrait obligatoirement se faire en analysant plusieurs lignes ( comme on l'a vu plus haut, certaines attaques ponctuelles qui sont en fait du flooding sont facilement dtectables en raison du port utilis, etc ... ). Pour viter d'utiliser des motifs trop lourds, une alternative intressante est de faire appel une structure ractive : chaque fois que nous rencontrons un paquet qui pourrait faire partie d'une attaque, la structure volue jusqu' atteindre un niveau critique dclenchant une alerte . Concrtement, ce niveau critique peut tre un seuil de caractrisation de flood ou de scan, ou bien une taille totale pour un paquet fragment ... Nous associons donc chaque type d'attaque un objet la dcrivant, et une instance sera cre chaque fois qu'une attaque est potentiellement en cours, faisant office de "mmoire" . Ces objets hritent des classes suivantes, construites pour reflter la structure des logs TCPdump ( j'ai omis les constructeurs ) :
classe ICMP {
string icmp_type;
}
classe TCP {
list of strings flags;
/ flags est un sous-ensemble de { SYN,FIN,PSH,URG,ACK,RST } ou bien vide
list of ints data-seqno;
/ data-seqno = { Start-SN ;End-SN ]
int acknum;
/ si le flag ACK n'est pas activ, acknum = -1
}
classe TCP_FRAG hritant de TCP {
int fragID;
int size;
int offset;
boolean more;
/ indique si le bit "More Fragments" est activ
}
Dans l'optique d'une utilisation pour la dtection d'intrusion par signatures, je ne dfinis pas de super-classe PAQUET ou UDP . En effet, les objets que j'utiliserai peuvent contenir des listes d'IP ou de ports . J'ai donc fait ce choix par cohrence et souci de ne pas surcharger les structures ...
Nous avons dsormais des classes dcrivant la plupart des paquets qu'on aura filtrer . A partir de l, on peut dfinir des classes caractrisant les attaques temporelles . Par convention, ces objets sont stocks dans des tables indexes par la caractristique principale de l'attaque ( cible ou attaquant ) comme par exemple attaque_sur_IP[adresse_attaquant]. Ainsi:
- PING SWEEP (icmp):
Cette "attaque" de reconnaissance consiste bombarder un rseau de requtes "ping", afin d'obtenir une carte des adresses actives sur le rseau cibl .
classe PINGSWEEP hritant de ICMP{
string src;
/ la construction, icmp_type = "echo request"
time heure_de_debut;
time heure_en_cours;
int compteur;
list of strings victims;
/ victims sert stocker les IPs des machines "pinges"
function new ...
function alerte ...
}
Timei src > dsti : icmp : echo request ==>
si !(pingsweep[src]) {
pingsweep[src] = new PINGSWEEP / heure_de_debut = Timei et heure_en_cours= Timei;
}
si !( desti est dans pingsweep[src].victims ) {
pingsweep[src].compteur =+1;
pingsweep[src].heure_en_cours = Timei;
ajouter desti pingsweep[src].victims;
}
si ( pingsweep[src].compteur > pingsweep_max && pingsweep[src].heure_en_cours - pingsweep[src].heure_de_dbut < 1000 ms ) {
Alerte !
}
/ pingsweep_max est une variable de seuil dfinir
- TCP HIJACK
Cette attaque dsigne un dtournement de connexion selon la mthode prsente prcdemment, l'aide des "sequence numbers" / "acknowledge numbers" . Notons que dans ce cas, il est ncessaire de connaitre le trafic dans les deux sens . Jusqu' prsent, il tait possible de caractriser une attaque par la seule activit de l'agresseur . Ici, pour dterminer si une attaque est en cours, il faut d'abord vrifier si le numro de squence a t vol .
classe HIJACK hritant de TCP {
string victime;
string spoof;
time heure_de_debut;
time heure_en_cours;
}
Timei src.sport > dst.dport : flags Start-SNi:End-SNi(End-SNi - Start-SNi) ACK ack-numi ==>
si ( !hijack[src.sport] ) {
/ src : machine protger, on pourrait donc ventuellement filtrer les machines pour lesquelles on cre cet objet
hijack[src.sport] = new HIJACK;
/ hijack.victime = src.sport, hijack.spoof = dst.dport, hijack.acknum = ack-numi,
/hijack.data-seqno[1] = End-SNi, hijack.data-seqno[0] = Start-SNi, hijack.heure_de_debut = Timei;
}
si ( hijack[src.sport] ) {
hijack.acknum = ack-numi;
hijack.data-seqno[1] = End-SNi;
hijak.heure_de_debut = Timei;
/mise jour des paramtres cruciaux
}
si ( hijack[dst.dport] ) {
/ src est l'attaquant potentiel, ce coup-ci
si ( hijack.spoof != src.sport && Start-SNi == hijack.acknum && ack-numi == hijack.dta-seqno[1] ) {
hijack.heure_en_cours = Timei;
Alerte !
/ les 3 conditions du spoofing sont runies
}
}
Cette signature est peut-tre moins vidente saisir que les autres : supposons que nous avons ce paquet :
Timei victime.sport > spoof.dport : flags Start-SNi:End-SNi(End-SNi - Start-SNi) ACK ack-numi
victime envoie un paquet la machine spoof, qui peut potentiellement servir de masque un attaquant . Le paquet normalement attendu si la machine spoof existe bien et a effectivement sollicit le paquet prcdent est de la forme :
Timej spoof.sport > victim.dport : flags ack-numi:End-SNj(End-SNj - ack-numi) ACK End-SNj
Par contre, en cas de dtournement de connexion avr, nous verrions passer un paquet de cette sorte :
Timej attaquant.sport > victim.dport : flags ack-numi:End-SNj(End-SNj - ack-numi) ACK End-SNj
O attaquant est une machine diffrente de spoof . Cependant, pour confirmer le dtournement de connexion, il faut vrifier les numros de squence et d'acquittement, formant un doublet unique caractrisant l'avancement d'une connexion ( en effet, un mme port d'une machine peut tre accd par plusieurs machines en mme temps, comme le port http par exemple ) tout comme le quadruplet {src,sport,dst,dport} caractrise de faon unique une connexion . Si une machine usurpe un tel doublet, c'est qu'elle tente de dtourner la connexion.
L'attaque par dtournement de connexion amne une dernire considration : Au vu de la signature dfinie l'instant, il suffirait attaquant de se prsenter avec l'adresse de spoof lorsqu'il envoie ses paquets pour devenir indtectable ( l'utilisateur sur attaquant peut construire compltement ses paquets s'il est root sur cette machine ), puisqu' l'observation le traffic l'air tout fait normal. Le seul dsavantage pour le mchant est qu'il n'aura pas la possibilit de rcuprer la rponse son paquet - moins d'voluer en rseau shared, mais il existe de nombreuses attaques o il n'est pas ncessaire d'obtenir de rponse de la machine attaque ( effacement de fichier, etc ... ) . En fait, ce dtournement est absolument indtectable avec l'approche qu'on a choisie ( analyse des logs sur une seule machine ). Le seul moyen de dtecter ce genre d'attaque serait de confronter les logs de spoof et ceux de victime, pour mettre en vidence la dsynchronisation de la connexion au moment o attaquant s'est immisc. Ces attaques restent cependant improbables hors des sous-rseaux; on ne les verra donc probablement pas si on effectue l'analyse de logs au niveau d'un point de sortie du rseau ( routeur, firewall ... )
- SYN FLOOD ( tcp )
Lorsque le port d'une machine est sollicit pour une connexion TCP, la machine garde une trace de ce contact dans la queue de connexion ( connection stack ). Ainsi, lorsque le paquet d'acquittement revient ( la 3e partie du handshake ), la machine sait que tout va bien . La trace est maintenue dans la queue un certain temps qui dpend des systmes d'exploitations, et si l'acquittement n'est pas arriv avant cette limite temporelle la connexion est considre comme perdue et la trace est retire de la queue . Or cette queue a bien videmment une capacit limite . L'ide est donc de "bourrer" cette queue de requtes de connexions provenant de machines en ralit inexistantes ( pour viter qu'un paquet d'acquittement ou qu'un paquet de fin de connexion ne soit renvoy la victime ), si bien que toute connexion lgitime ne pourra tre stocke dans la queue et donc aboutir .De l'extrieur, le port de la victime semble inactif . Ici deux patterns agissent conjointement:
classe SYNFLOOD {
time heure_de_debut;
time heure_en_cours;
string dst;
int dport;
list of strings attackers;
/ contient les adresses IP des ventuels attaquants
}
Timei srci.sporti > dst.dport : S ==>
si !(synflood[dst.dport]) {
crer synflood[dst.dport] / heure_de_debut = Timei et heure_en_cours= Timei;
}
ajouter srci.sporti synflood[dst.dport].attackers;
synflood[dst.dport].compteur =+1;
si ( synflood[dest.dport].compteur > synflood_max[dport] ) {
Alerte !
}
Timei srci.sporti > dst.dport : flags data-seqno ACK ack-num ==>
si !(synflood[dst.dport]) {
Alerte !
/un paquet ACK sans handshake pralable n'est pas normal
/( soit un dtournement de connexion, soit une tentative d'chapper aux IDS )
}
sinon {
retirer srci.sporti de synflood[dst.dport].attackers;
synflood[dst.dport].compteur --;
}
Juste avant que la file d'attente soit engorge ( paramtrer avec synflood_max[dport], qui dpendra du port vis ), l'alerte est donne . Il faut pouvoir tenir compte du temps, afin de ne plus tenir compte des connexions qui ont t automatiquement dsactives par Timeout . D'autre part, on parvient dtecter une attaque que le pattern matching simple ne pouvait pas relever ( ncessit d'un retour en arrire ) : le dtournement du 3-way handshake de TCP " la Mitnick " .
- PORT SCAN
Le scanning de port sert dterminer les services prsents sur une machine. On en a fait une large prsentation plus haut .
classe PORTSCAN hritant de TCP_FRAG{
/ pour l'instant, pas de dtection de scans par UDP, viendra plus tard ...
string dest;
string src;
string type;
list of int ports;
/ ports scanns
int compteur;
}
Time1 src.sporti > dest.dporti : flags data-seqno ack window urg options
si !(portscan[dest]) {
if ( flags == SYN ) {
portscan[dest] = new PORTSCAN / heure_de_debut = Timei et heure_en_cours= Timei;
portscan(src).type = "SYN scan";
}
else if ( flags == FIN ) {
portscan[dest] = new PORTSCAN / heure_de_debut = Timei et heure_en_cours= Timei;
portscan(dest).type = "FIN scan";
}
else if ( flags == "" && ack == && urg == ) {
portscan[dest] = new PORTSCAN / heure_de_debut = Timei et heure_en_cours= Timei;
portscan(dest).type = "NULL scan";
}
else if ( flags == "FIN,PUSH" && urg == "URG" ) {
portscan[dest] = new PORTSCAN / heure_de_debut = Timei et heure_en_cours= Timei;
portscan(dest).type = "XMAS scan";
}
if ( sporti == 20 ) {
portscan[dest].type .= " via FTP bouncing";
}
if ( options contient (frag ID :size@offset{+, }) ) {
/ paquet fragments pour tromper les IDS
portscan[dest].type .= " avec fragmentation";
}
}
si ( dporti n'est pas dans portscan[dest].ports ) {
ajouter dporti portscan[dest].ports;
portscan[dest].compteur =+1;
}
si ( portscan[dest].compteur > scan_max ) {
/ scan_max = 10 parait tre un seuil correct ( surtout si on ne tient pas compte du temps )
/ confirmer avec l'exprience ...
Alerte !
}
- STICK
Stick est une tentative de dsactivation distance des systmes de dtection d'intrusion orients rseau . L'attaque consiste envoyer un trs grand nombre de paquets RST ( fin de connexion brutale ), ce qui a pour effet de surcharger de travail le NIDS. Ceci aura ventuellement pour effet de provoquer un dni-de-service contre le systme de dtection d'intrusion, laissant le rseau protg sans surveillance.
classe STICK hritant de TCP {
string dest;
string src;
time heure_de_debut;
time heure_de_fin;
int compteur;
}
Timei src.sporti > dest.dport : R =>
si !(stick[dest.dport]) {
stick[dest.dport] = new STICK
/ heure_de_debut = Timei et heure_en_cours= Timei;
}
stick[dest.dport].compteur =+1;
si ( stick[dest.dport].compteur > stick_max ) {
/stick_max = 10 ? plus de 10 paquets RST pour clore une connexion de faon abrupte, c'est louche !
Alerte !
}
- SMURF-VICTIME ( icmp )
principe identique fraggle-victime.
classe SMURF_VICTIME hritant de ICMP {
string dest;
list of string attackers;
/ stocke les IP des machines amplificatrices
time heure_de_debut;
time heure_en_cours;
int compteur;
}
timei srci > dst : icmp : echo reply ==>
si !(smurf-victim[dst]) {
smurf-victim[dst] = new SMURF_VICTIME;
/ heure_de_debut = Timei et heure_en_cours= Timei;
}
ajouter srci smurf-victim[dst].attackers;
smurf-victim[dst].compteur =+1;
si ( smurf-victim[dst].compteur > smurf_max ) {
Alerte !
}
La fragmentation a lieu lorqu'un datagramme IP en transit doit paser par un rseau dont la taille maximale de transmission ( MTU ) est plus petite que la taille du datagramme (en clair, il y a engorgement ). Par exemple, la MTU d'Ethernet est de 1500 octets; donc un datagramme de taille suprieure 1500 octets devra tre fragment pour voyager sur Ethernet. Les fragments se comportent exactement comme des paquets normaux, si ce n'est qu'ils sont rassembls par la machine destinataire . Pour se faire, chaque fragment contient les informations suivantes :
un identifiant de fragment ( Frag ID ), permettant la machine destination de regrouper tous les fragments appartenant un mme paquet .
un offset indiquant la place du fragment dans le paquet original .
la taille des donnes contenues dans le paquet fragment .
un indicateur pour savoir si le paquet fragment est suivi par d'autres paquets ou bien si il s'agit du dernier fragment . Cet indicateur est le flag "more fragments" (MF) .
Toutes ces informations se situent dans l'en-tte IP, cet en-tte tant lui-mme suivi par un fragment encapsul .
La fragmentation est un outil de choix pour mener des attaques pour les raisons suivantes :
En cas de chevauchement de donnes ( ie les donnes d'un fragment recoupent celles d'un autre la reconstruction du paquet ), les ractions de la destination peuvent tre imprvisibles. Ceci peut donner lieu des dnis de service comme Teardrop .
La fragmentation permet de "maquiller" des paquets de taille gigantesque, dont la manipulation est hasardeuse par le systme d'exploitation de la destination ( cas du "ping of death" ).
Beaucoup de systmes de dtection d'intrusion ou de firewalls ne reconstruisent pas les paquets pour voir ce qui est vraiment transmis la destination . Ceci peut poser des problmes de scurit : supposons qu'un attaquant veuille utiliser une faille de la couche application, par exemple une attaque sur CGI comme get /phf? via HTTP . Si celui-ci envoie sa requte HTTP directement dans un paquet, celle-ci risque de correspondre avec une signature d'attaque connue de l'IDS de la cible vu que la requte est suffisamment petite pour tenir dans un paquet de taille normale ( 1500 octets ) . Par contre, si la requte est envoye de faon fragmente, de sorte que chaque paquet ne contienne qu'une lettre de l'attaque, l'IDS sera bern puisqu'il ne reconnaitra aucune signature d'attaque mais la cible sera touche par l'attaque .
Hormis le premier fragment, les autres autres fragments ne contiennent pas les informations de l'en-tte du paquet original, notamment le port de destination . Ceci peut donc poser un problme de filtrage pour les firewalls . On peut aussi envisager la possibilit d'un chevauchement de donnes au niveau de l'en-tte original, permettant ventuellement de changer le port de destination au moment o le paquet est reconstruit, ou bien de camoufler une adresse IP source interdite, et donc de tromper les ACL des firewalls ( listes des ports d'accs autoris par l'extrieur, derrire le firewall ).
Les traces de paquets fragments sont un peu diffrentes de celles des paquets normaux dans les logs TCPdump, et refltent l'absence d'informations fournies par l'en-tte TCP . Dans ces conditions, les fragments ne contenant pas l'en-tte ont ce format gnrique :
Timestamp src > dst : (frag ID :size@offset{+, })
Les attaques suivantes fonctionneront donc avec 2 signatures : une premire pour dtecter le fragment contenant l'entte, et la suivante pour reprer les informations caractristiques de l'attaque par fragmentation proprement dite .
- TEARDROP (TCP)
L'attaque exploite le chevauchement de paquets fragments.
Ici, une difficult supplmentaire est prendre en compte : les paquets n'arrivent pas forcment dans le bon ordre, ie dans l'ordre des offsets . Pour un paquet fragment normal, et pour toute valeur de i, nous savons que offset_i + size_i = somme( size_j, j = 1 ... i ). Par consquent, une attaque teardrop est telle qu'il existe une valeur de i pour laquelle offset_i + size_i < somme( size_j, j = 1 ... i ) .
classe TEARDROP hritant de TCP_FRAG {
string dst;
int dport;
string src;
int sport;
int ID;
/ ID number du paquet fragment
int offset_max;
/ le plus grand offset reu en cours
int taille_theorique;
/ egal offset + size du dernier fragment reu
int taille_reelle;
/ somme des size_i reus
}
Timei SRC.SPORT > DST.DPORT : flags data-seqno ack window (frag ID :size_i@offset_i{+,}) ==>
si !( teardrop[ID] ) {
teardrop[ID] = new TEARDROP;
}
teardrop[ID].dst = DST;
/ etc ...
et
Timei SRC > DST : (frag ID :size_i@offset_i{+,}) ==>
si ( offset_i == max ( offset_i, teardrop[ID].offset_max) ) {
teardrop[ID].offset_max = offset_i ;
teardrop[ID].taille_theorique = offset_i + size_i;
}
teardrop[ID].taille_reelle =+ size_i;
si ( teardrop[ID].taille_theorique < teardrop[ID].taille_reelle ) {
Alerte !
/la condition ci-dessus n'est pas ncessaire mais elle est suffisante
/( elle devient ncessaire lorsque tous les fragments sont arrivs). A dfaut de trouver mieux ...
}
- PING OF DEATH (icmp)
L'envoie d'une requte ping trop grosse ( de taille suprieure 65 ko ) provoque un plantage de la machine cible, et donc un dni-de-service .
classe POD hritant de ICMP {
string src;
string dst;
int ID;
int total_size;
}
Timei src > dst : icmp : echo request (frag ID :size_i@offset_i{+,}) ==>
si !(pod[ID]) {
pod[ID] = new POD;
}
et
Timei SRC > DST : (frag ID:size_final@offset_final) ==>
/ si pod[ID] existe
pod[ID].total_size = offset_final + size_final;
si ( pod[ID].total_size > 65 k ) {
Alerte !
}
La taille du paquet Ping est connue grace au dernier paquet de la fragmentation ( celui ne contenant pas de + ), il suffit donc de reprer celui-ci, et de tester la taille du paquet . Une fois ce test effectu, on peut dtruire l'objet pod associ dans la table .
Sur Teardrop, l'inconvnient est qu'on n'a pas de moyen de dtruire l'objet une fois que le paquet complet a t reu, puisque les paquets fragments arrivent dans le dsordre. Ces attaques restent assez rares, ce qui devrait limiter le nombre d'objets correspondants crs.
Afin de tester l'efficacit des signatures prsentes dans ce rapport, un ensemble de scripts appel LOGre ( pour faire rfrence aux fichiers de log qu'il manipule et aux expressions rgulires qu'il utilise intensment ) a t mis en point en Perl . Ce langage a t choisi en raison de sa grande portabilit et de la puissance de ses outils de test d'expressions rgulires .
LOGre est un ensemble de scripts crits en perl, dont la fonction principale est de tester les signatures prsentes dans ce rapport . L'ensemble comprend trois parties :
les classes dcrivant les objets ncessaires pour dcrire et capter les attaques temporelles . Ce sont des fichiers de type "Perl Module" ( extension .pm )
Il est notamment possible d'exploiter ce qui a t fait dans le domaine de la recherche de motifs pour essayer d'acclrer la recherche de paquets suspects :
Le temps d'excution est une ressource cruciale dans notre problme, o d'normes quantits de donnes doivent tre manipules . Il s'avrerait donc intressant de pouvoir classer les signatures principales en une structure permettant de gagner du temps l'excution : certaines signatures prsentant des similitudes, il peut tre fructueux d'essayer de les "factoriser" en les rassemblant dans une structure d'arbre similaire un arbre de recherche ( TRIE ) . Cet arbre peut tre dfini une fois pour toutes au dmarrage du systme de dtection d'intrusion, et chang uniquement quand une nouvelle signature doit tre rajoute . De cette faon, chaque paquet est confront une signature ayant au plus la taille de la plus longue signature qu'on aura dfini. Le gain en vitesse de traitement est donc thoriquement significatif par rapport l'approche "nave" consistant comparer un paquet avec chaque signature, squentiellement . Il est mme encore possible d'amliorer le stockage en termes d'espace occup en optant pour une structure de DAWG ( Directed Acyclic Word Graph ), qui est une forme de TRIE sur lequel on a appliqu un algorithme de minimisation . D'aprs l'article Kucherov/Rusinowitch, le DAWG peut se construire en temps O( |S| ) o S est l'ensemble des signatures, et le rajout d'une signature s se fait en temps O( |s| ).
tenir compte de "l'age" des paquets ...
Les attaques temporelles tels que le scanning ou l'inondation ncessitent de tenir compte des paquets "suspects" que l'on rencontre lors de l'analyse et d'en garder une trace ( notamment le nombre de fois que ces paquets sont relevs ), comme on l'a vu prcdemment . Afin d'viter l'engorgement de la mmoire de stockage, il faudrait donc rgulirement purger les tables de stockage voques plus haut . On peut procder comme suit : chaque table possde une taille maximale . Lorsque cette taille est atteinte, on efface de la table les entres pour lesquelles le compteur a la plus faible valeur . On gagne ainsi de la place en dtruisant les rfrences des paquets ne faisant vraisembablement pas partie d'une attaque en cours ( sauf si on a affaire un attaquant particulirement vicieux et prt "dlayer" un scan sur de trs grandes dures de temps, mais dans ce cas il faut admettre qu'une telle attaque est de toutes faons quasiment indtectable ) .
Le modle que nous avons choisi d'tudier est ncessairement limit par le fait qu'il ne surveille que les attaques portant sur les couches Transport et IP . Or un grand nombre d'attaques existe pour la couche Applicative . Cependant, et de faon gnrale, la dtection d'intrusion prsente des limites et des problmes et peut quelquefois se montrer impuissante dans certains cas.
La solution retenue ici ne permet pas de contrer les attaques par "covert channels" de type Loki ... ie les logiciels qui permettent d'utiliser un canal a priori inoffensif pour faire transiter de l'info : par exemple loki fait communiquer le client et le serveur via des paquets icmp echo, AckCmd passe les firewalls en n'utilisant que des paquets ack ... . Ce genre de problme ncessite en fait de "sniffer" plus en profondeur et demande l'application d'une batterie de tests cryptanalytiques sur les paquets ( comme par exemple des tests statistiques sur les SN ), assez lourds en ressources de calcul . A l'heure actuelle, aucune solution n'existe contre ce danger potentiel, puisque mme l'interception en profondeur peut tre neutralise par l'usage de la cryptographie pour camoufler les donnes en transit.
Le mme problme apparait lorsqu'on cherche se prmunir des "trojan horses". Les "trojans" sont des applications s'apparentant aux virus dans la mesure o ceux ci sont installs souvent l'insu de l'utilisateur . Une fois en place, toute personne sachant contacter le trojan peut prendre le contrle de l'ordinateur infect comme si il en tait l'utilisateur actuel ( certains logiciels poussent mme le zle jusqu' permettre d'afficher l'cran de l'utilisateur pirat .. ) . Une faon de dtecter les trojans est donc de vrifier que les ports de communication habituellement ouverts par un trojan ne sont pas actifs sur la machine. Malheureusement, les trojans les plus rcents sont hautement configurables, et peuvent donc tre activs sur n'importe quel port . Ce genre de signature n'est donc plus efficace .
La seule mthode peu prs efficace pour dtecter ce genre d'attaque repose sur le fait qu'un serveur doit tre ncessairement install sur la machine infecte pour que le covert channel ou le trojan soit mis en place : ainsi, une analyse rigoureuse des changements sur le disque dur d'une machine associe l'observation ventuelle de trafic inexpliqu peut permettre de dcouvrir un covert channel ou un trojan en activit . Pour plus de dtails et des ides sur les covert channels, voir l'article de C. Rowland.
Un des gros dsavantages de la dtection par signatures d'attaques est son manque de flexibilit et par consquent sa vulnrabilit aux mutations : d'une part, il faut pour pouvoir dfinir une signature avoir dj t confront l'attaque considre . D'autre part, certaines de ces signatures se basent sur des caractristiques "volatiles" d'un outil, comme par exemple le port qu'un certain troyan ouvre par dfaut, la valeur de ISN choisie par tel autre outil de pirate, etc ... Souvent ces logiciels sont soit hautement configurables, soit "open-source" donc librement modifiables . Les caractristiques retenues pour dfinir la signature sont donc fragiles, et les signatures extrmement sensibles aux mutations . Un exemple actuel est l'outil ADMutate, qui permet de camoufler une attaque au niveau applicatif afin de la rendre non dtectable par les systmes de dtection d'intrusion conventionnels utilisant des signatures . Contre ce genre de problme, une parade consiste dfinir ce qu'est l'tat de "compromission", c'est--dire l'tat attendu d'une machine pendant ou aprs une attaque . On peut alors essayer de dtecter quand la machine entre dans cet tat : on ne saura pas comment la machine a t attaque si l'attaque tait de type inconnu, mais on se sera quand mme aperu que quelque chose a eu lieu. Bien sr, la difficult majeure dans cette parade est de dfinir ce fameux tat de "compromission". On pourrait donc penser qu'une approche par apprentissage serait une bonne alternative . Cependant, il n'en est rien : outre une convergence plutt longue vers un modle comportemental "normal", rien n'empche un pirate se sachant surveill de "rduquer" un tel systme en faisant voluer progressivement son modle de convergence vers un comportement tout fait anormal pour l'analyste, mais "normal" d'un point de vue statistique . On retrouve un problme similaire dans l'approche par signatures des attaques temporelles, la signature comprenant frquemment une valeur de seuil : si l'attaquant a du temps devant lui, il peut s'arranger pour dlayer ses attaques dans le "bruit" en prenant garde ne pas gnrer une activit dpassant les seuils fixs ( surtout vrai pour les scans de ports, par exemple : si on fixe le seuil de dtection 30 ports scanns, il suffit d'en scanner 29 ou moins de faon assez espace pour ne pas tre dtect ) . C'est un problme assez difficile rsoudre, dans la mesure o la difficult rside dans la dfinition d'une attaque temporelle en gnral ( et d'un scanning de ports en particulier ) . Une solution possible serait d'associer une "probabilit d'attaque" qui tendrait vers 1 quand le seuil fix est atteint ( par exemple, le rapport min (ports contacts, seuil ) / seuil ) . L'analyste humain dciderait alors lui-mme si l'activit releve est une attaque ou non . Cependant, avec cette approche, on peut passer ct d'attaques temporelles "distribues", par exemple .
Outre la taille des fichiers de log ( de l'ordre du Go ), la dtection d'intrusion est excessivement gourmande en ressources : par exemple le pattern SynFlood cre un objet par connexion TCP. Au pire, nous pouvons donc avoir O( R * 65000 ) objets synflood crs en mme temps, o R est le nombre de machines surveilles et 65000 le nombre approximatif de ports TCP existants . Ces objets disparaissent lorsque le handshake est complet pour toutes les connexions en cours sur les ports considrs . Il faudrait donc tenir compte du temps de "time out" des machines, en cas de handshake laiss en suspens. Les objets gnrs par teardrop ne sont pas dtruits, car il n'est pas possible de connaitre l'avance le nombre de fragments que l'on va recevoir . La raret de ces attaques en comparaison avec les syn flood et les scans compense ce dfaut. Le pattern HijackTCP "surveille" virtuellement tout le traffic TCP . L'optimisation par "nettoyage" des tables intervalles temporels rguliers peut donc tre trs utile .
On voit donc que la dtection d'intrusion est un exercice prilleux pour les ressources en espace . Un attaquant un peu malin peut chercher en profiter, en essayant de provoquer un dni-de-service au niveau du systme de dtection d'intrusion, ou au pire au niveau du systme d'exploitation de la machine supportant l' IDS. Une fois l'IDS dsactiv, l'attaquant a le champ libre pour tenter tout ce qui lui plait . Ainsi, l'attaque "STICK" est une tentative de dni-de-service contre les IDS ( en particulier contre ISS RealSecure ) : l' attaquant espre ainsi surcharger de travail l'IDS, au point de le dsactiver ou au moins de le rendre moins efficace .
La dtection d'intrusion oriente rseau prsente un problme fondamental : comment tre certain que ce que le gnrateur d'vnements va capturer est bien la mme chose que ce qui va atteindre les machines du rseau surveiller ?Une diffrence notable provient dj du fait que le systme de dtection d'intrusion se trouve rarement sur la machine qu'il est en train de protger . Il existe aussi des limitations due aux performances : les vitesses de transmission sont parfois telles qu'elles dpassent largement la vitesse d'criture des disques durs les plus rapides du march, ou mme la vitesse de traitement des processeurs . Il n'est donc pas rare qu'un "sniffeur" ait un taux de perte de paquets non nul, si bien que des paquets non reus par l'IDS seront peut-tre reus par la machine destinataire . D'autre part, un systme de dtection d'intrusion ne faisant pas de reconstruction de paquets fragments aura forcment un aperu de ce qui passe sur le rseau diffrent de ce qui sera rellement reu par les machines surveilles . Comme on l'a voqu prcdemment, un tel systme de dtection d'intrusion passerait ct des attaques de type Teardrop, du chevauchement des en-ttes ( pour modifier l'IP source, le port de destination, ect... au dernier moment ), ou encore des attaques au niveau applicatif qui seraient fragmentes pour leurrer le moteur d'analyse par pattern matching de l'IDS. Il se peut aussi que la diffrence de temps entre le moment o l'IDS reoit un paquet et celui o la machine destinataire reoit ce paquet soit cruciale : il peut par exemple se passer quelque chose sur la machine destinataire, faisant que ce paquet sera rejet, alors que l'IDS l'aura analys et fera l'hypothse que ce paquet a bien t reu et trait par sa destination . Dans l'autre sens, il se peut aussi qu'une diffrence de systmes d'exploitation entre la machine supportant l'IDS et la machine surveille fasse que certains paquets rejets par le systme de dtection d'intrusion soient accepts par la destination ( c'est par exemple le cas des paquets UDP avec une somme de contrle errone, rejets par la plupart des systmes d'exploitation, sauf les plus anciens ) . Ce problme peut engendrer deux types de faux ngatifs chez un systme de dtection d'intrusion :
faux ngatif par insertion : reprenons le cas d'une attaque contre la couche applicative, et supposons que la commande "attack" soit considre comme dangereuse . Le systme de dtection d'intrusion doit donc tre configurer pour relever tout paquet contenant la squence "attack", par exemple par pattern matching . L'attaquant, pour viter d'tre repr, peut commencer par fragmenter son paquet, de faon n'envoyer que des squences de 1 caractre . Mais si l'IDS reconstruit le paquet, l'attaque sera repre . Pour aller plus loin, l'attaquant peut s'arranger pour envoyer des paquets "leurres" qui seront rejets par la machine de destination, mais pas par l'IDS . En reconstruisant le flux, l'IDS ne parviendra pas appliquer sa signature pour "attack" mais la machine sera pourtant attaque . Le dessin suivant rsume la situation :
faux ngatif par vasion : dans ce cas, c'est le systme de dtection d'intrusion qui rejette un paquet qui sera pourtant accept par la destination, menant un rsultat comparable .
Etat de l'art:
the IDS FAQ : rponses aux questions les plus frquemment poses concernant la dtection d'intrusion .
A High-Performance Network Intrusion Detection System, R. Sekar, Y. Guang, S. Verma, T. Shanbhag, in ACM Computer & Communication Security, 1999.
Recent Adances in Intrusion Detection, Springer, 2000 .
Artificial Intelligence and Intrusion Detection: current and future directions, J. Frank, juin 1994.
The application of Artificial neural Networks to Misuse Detection: Initial Results, J. Cannady, J. Mahaffey
A pattern matching model for misuse Intrusion detection, S. Kumar, E. Spafford, 1994
The Design of GrIDS: a Graph-Based Intrusion Detection System, S. Cheung, R. Crawford, M. Dilger, J. Frank, J. Hoagland, K. Levitt, J. Rowe, S. Staniford-Chen, R. Yip, D. Zerkle, Janvier 1999.
ASL: A specification language for intrusion detection and network monitoring, Ravi Vankamamidi, Novembre 1998.
Fragmentation, furtivit et failles des IDS:
RFC1858: Security Considerations for IP Fragment Filtering, 1997
Multiple Levels of De-synchronization and other concerns with testing an IDS system, Greg Hoglund et Jon Gary, aout 2000 .
50 ways to defeat your IDS, Fred Cohen, 1997
Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection, T. Ptacek, T. Newsham, 1998
Covert channels:
Phrack, voir l'article sur Loki.
Covert Channels in the TCP/IP Protocol Suite, Craig H. Rowland, Novembre 1996
Aspects algorithmiques:
Matching a Set of Strings with Variable Length Don't Cares ,M. Rusinowitch, G. Kucherov, Theoretical Computer Science (178)1-2 (1997)
the analysis of hybrid Trie structures, J. Clment, P. Flajolet, B. Valle, Proceedings of the Ninth ACM-SIAM Symposium on Discrete Algorithms, Janvier 1998.
Logiciels:
Packet Storm : pour trouver tous les programmes voqus ici ou mettant en pratique les failles prsentes dans ce rapport ...
le site de Perl : un langage de script de haute portablilit et disposant d'outils trs puissants pour les expressions rgulires . Accessoirement, le langage de ralisation des tests ..
LOGre : un script de test de mes signatures, crit en perl .
m'crire: huin@loria.fr