Évasion aux IDS, Pare-feu et Pots de miel

I. Les systèmes de détection d’intrusion (IDS)

I.1 Définition

Un système de détection est un outil de protection et de défense d’un hôte en particulier, d’un réseau en général. Sa défense consiste à écouter les trafics sur le réseau ou sur l’hôte afin de pouvoir détecter d’éventuelles menaces (les attaques) et de les prévenir. Il garde aussi des traces de ces attaques détecter en les enregistrant dans des fichiers logs afin de pouvoir éventuellement les exploiter dans le futur.

Il peut être intégré dans le pare-feu ou placé en dehors et indépendamment, en fonction du trafic surveillé.

I.2 Les techniques de détection d’intrusion d’un IDS

Il existe plusieurs critères de classement des IDS. Toutefois, si nous considérons la méthode de détection des attaques, il existe trois principaux types d’IDS que sont : les IDS à base de signatures, les IDS à base d’anomalies et les IDS qui détectent les anomalies de protocole.

I.2.1 IDS à base de signatures

Les IDS à base de signatures ont une base de données comportant un ensemble de signatures d’attaques (base de signatures). Le principe de fonctionnement est le test de correspondance. Les données du réseau sont analysées et comparées aux signatures d’attaques connues stockées dans la base de signature. En cas de correspondance, une alerte est émise. Un avantage de ce système est qu’il a une meilleure précision lorsque les règles de signature sont correctes. Cette base de signatures est en générale pré initialisée avec des données de l’éditeur de l’IDS et mise à jour régulièrement pour prendre en compte les nouvelles attaques.

FIg.1 : Procédure de détection d’attaques d’un IDS à base de signature

I.2.2 IDS à base d’anomalies 

Cette catégorie d’IDS utilise un modèle statistique du fonctionnement de référence normal du réseau qui peut comprendre la bande passante utilisée, les protocoles définis pour le trafic, les ports et les périphériques qui font partie du réseau. Il surveille régulièrement le trafic réseau et le compare au modèle statistique. En cas d’anomalie ou de divergence, l’administrateur est alerté. Un avantage de ce système est qu’ils peuvent détecter des attaques nouvelles dont le comportement s’éloigne suffisamment de la normale.

FIg.2 : Procédure de détection d’attaques d’un IDS à base d’anomalies

Ce type d’IDS fonctionne en deux phases en général :

  • La phase d’apprentissage : ce type d’IDS va d’abord à la découverte du profil normal avec un apprentissage de l’ensemble des éléments surveillés. De ce fait, ils seront en mesure de signaler les trafics suspects.
  • La phase de détection : pour identifier les comportements anormaux.

I.2.3 Détection d’anomalie de protocole

On l’appelle aussi détection d’anomalie de comportement du réseau et c’est une approche de détection des menaces sur le réseau en identifiant les violations des spécifications du protocole se trouvant dans le RFC de celui-ci.

La recherche d’anomalies de protocole est intégrée dans les IDS modernes ainsi que les IPS (Systèmes de Prévention d’Intrusion).

Surveiller le réseau revient à :

  • Vérifier la structure des flux du trafic réseau ;
  • Étudier les données de performance du réseau ;
  • Analyser le trafic passif du réseau.

I.3 Indications générales des intrusions

I.3.1 Intrusions sur un système de fichier

Avec ce genre d’intrusion, on peut détecter de nouveaux fichiers ou des fichiers non familiers sur le système.

Il peut y avoir aussi des changements au niveau d’un fichier (permissions, taille), la présence de fichiers indésirables, la perte de fichiers, etc.

I.3.2 Intrusions sur un réseau 

Il existe des sondes répétées sur des services disponibles, des connexions sur des emplacements non utilisés, des ouvertures de session répétées provenant d’hôtes distants, des rentrées en masses d’un coup de données sur les logs.

I.3.3 Intrusions sur un système

Il y a une présence sur le système de logs courts ou incomplets, une absence de logs, des modifications sur le système, des fichiers de configurations, des ouvertures de comptes, des craches du système, des redémarrages, des processus non familiers, une très faible performance du système, etc.

I.4 Les différents types d’IDS

I.4.1 IDS basé sur le réseau (NIDS)

Il permet de surveiller l’état de la sécurité au niveau du réseau.

C’est un sonde qui est placé dans le réseau et qui surveille l’ensemble du réseau, capture et analyse tout le trafic réseau, recherche des paquets suspects, analyse le contenu des données, les adresses IP, MAC sources et destinations, envoie des alertes, etc.

I.4.2 IDS basé sur l’hôte (HIDS)

Il permet de surveiller le système et les applications de l’hôte sur lequel il est installé en analysant les informations des logs systèmes, en contrôlant l’accès aux appels systèmes et en vérifiant l’intégrité des systèmes de fichiers.

Il est particulièrement efficace pour déterminer si un hôte est contaminé.

Il ne surveille que l’hôte sur lequel il est installé et a accès à des composantes non accessibles sur le réseau, à savoir la base de registre de Windows.

I.5 L’IDS SNORT

I.5.1 Présentation de Snort et de ses modes

C’est un NIDS open source à base de signatures. Il est capable d’analyser en temps réel les paquets et le trafic tout entier dans un réseau IP.

Il capture le trafic qui passe sur le réseau et lance des alertes sur les éventuelles attaques détectées et disposant une règle de détection.

SNORT Il peut fonctionner sous 3 modes :

  • Le mode NIDS : avec les règles qui sont prédéfinies, il analyse le trafic du réseau et compare les résultats avec ces règles, pour savoir quelle action appliquer (alerte ou pas) ;
  • Le mode sniffer de paquets : il lit les paquets traversant le réseau et les affiche sur l’écran (comme tcpdump) ;
  • Le mode packet logger : pour lui permettre de journaliser les paquets dans le fichier log ;

Avec le mode NIDS, SNORT peut utiliser une base de données pour journaliser les alertes (MySQL, PostgreSQL ou Oracle).

Pour visualiser ces alertes, il est possible d’utiliser des outils graphiques comme :

  • Snort Report : qui est un outil graphique permettant d’afficher les rapports d’alerte sous format HTML. Il utilise la base de données pour récolter les informations sur les attaques, etc.
  • Snort-rep : il permet d’afficher les alertes par portscans, par ID, par remote host, par local host, etc. il peut afficher les rapports sous format HTML ou texte.
  • ACID (Analysis Console for Intrusion Databases) : qui est une interface WEB utilisant la base de données de SNORT pour exploiter les alertes qui y sont stockées. Il affiche aussi les statistiques qui concernent l’alerte.

I.5.2 Structure des règles de signatures de SNORT

Snort dispose d’une base de signatures conçue par la communauté et qui peut servir à initialiser la base d’une instance de Snort dans un réseau. 

Ces signatures, aussi appelées règles, aident à différencier les attaques du trafic normal.

Avec ces règles, SNORT peut analyser les événements ayant rapport aux protocoles ICMP, TCP, UDP et IP.

Une règle SNORT est constituée de deux parties :

  • L’entête :

Il contient l’action à appliquer, le protocole, les adresses (source et destination), la masque de sous-réseau et les numéros de ports d’écoute (source et destination) :

action  protocol  @ip_src  port_src -> @ip_dst  port_dst

Exemple :

      alert tcp any any  -> 192.168.1.0/24 111

Le premier any permet de spécifier que c’est pour n’importe quelle adresse source, et le deuxième any c’est pour n’importe quel port source.

  • Les options :

Cette partie permet de spécifier ce qu’il faut inspecter dans le paquet et le message d’alertes à envoyer. Elle est toujours mise entre parenthèses.

Exemple :

      (content: ’’|00 01 86 a5|’’ ; msg: ‘’external mountd access’’ ;)

Possible de faire des options sur les données des paquets :

Exemple : Restreindre la recherche aux champs de l’entête http :

      alert tcp any any  -> any 80 (content: ’’EFG’’ ; http_header;)

Possible de mettre en place des options sur les entêtes des paquets aussi en utilisant le

TTL par exemple : 

              ttl:-3 ; ttl:5-;

I.5.3 Les actions dans SNORT

SNORT dispose de 8 actions par défaut :

  • alert : génère une alerte en utilisant la méthode d’alerte sélectionnée, et alors journalise le paquet ;
  • log : journalise le paquet ;
  • pass : ignore le paquet ;
  • activate : alerte et alors active une autre règle dynamique ;
  • dynamic : reste passive jusqu’à être activée par une règle « activate », alors agit comme une règle log ;
  • drop : bloque et journalise le paquet ;
  • reject : bloque et journalise le paquet, puis envoie un RST si le protocole est TCP ou message « ICMP port unreachable » si le port est UDP ;
  • sdrop : bloque le paquet, mais ne le journalise pas.

I.5.4 Les options de règle

Les options de règle forment le cœur du moteur de détection d’intrusion de SNORT. Elles sont séparées les unes des autres par un caractère point-virgule « ; »

Les mots clés des options de règle sont séparés de leurs arguments avec un caractère deux points « : ».

Les mots clés couramment utilisés sont :

  • msg : affiche un message dans les alertes et journalise le paquet ;
  • logto : journalise le paquet dans un fichier nommé par l’utilisateur au lieu de la sortie standard ;
  • ttl : teste la valeur du champ TTL de l’entête ;
  • icmp_seq : teste le numéro de séquence ECHO ICMP contre une valeur spécifique ;
  • content : recherche un motif dans les données d’un paquet ;
  • content-list : recherche un ensemble de motifs dans les données d’un paquet ;
  • nocase : correspond à la procédure de chaine de contenu sans sensibilité aux différences majuscules/minuscules ;
  • resp : réponse active (ferme les connexions, etc.) ;
  • react : réponse active (bloque les sites web) ;
  • sameip : vérifie si la source et la destination ont la même adresse IP ;
  • dsize : teste la taille des données (Payload) d’un paquet ;
  • flags : cherche un flag spécifique de l’entête TCP.

I.5.5 Opérateurs de direction

  •  L’opérateur unidirectionnel « – > » indique l’orientation, ou la direction, du trafic auquel la règle s’applique. L’adresse IP et les numéros de port du côté gauche de l’opérateur de direction est considéré comme le trafic provenant du système source, et les informations d’adresse et de port du côté droit de l’opérateur est le système destination.
  • Il y a aussi un opérateur bidirectionnel indiqué par le symbole « <> ». ceci permet de considérer les paires adresse/port ou bien en source ou bien en destination de l’orientation. C’est utile pour enregistrer/analyser la conversation dans les deux sens.

Exemple : 

       log tcp !192.168.1 .0/24 any <> 192.168.1 .0/24 23

I.5.6 Exemples de règle

  • Journaliser le trafic udp preovenant de toute adresse IP, tout port et à destination de ports dans l’intervalle de 1 à 1024 :
         log udp any any  ->192.168.1.0/24 1:1024
  • Journaliser le trafic tcp depuis les ports privilégiés inférieurs ou égaux à 1024 vers les ports supérieurs ou égaux à 500 :
         log tcp any :1024  -> 192.168.1.0/24 500:
  • Lancer une alerte sur le trafic http ne contenant pas (!) le mot GET :
         alert tcp any any -> any 80 (content:!”GET”;)

I.6 Les différents types d’alertes

  •  Vrai positif (attaque détecté et alerte envoyée) :

C’est le fait d’envoyer un message d’alerte sur une attaque détectée.

  • Faux positif (fausse alerte car pas d’attaque) :

Quand l’IDS envoie de fausses alertes sur de potentielles menaces alors que ce n’est pas tout à fait une menace, on parle, dans ce cas que l’IDS à produit des faux positifs.

Cela arrive très souvent aux IDS à base d’anomalies à cause de la méthode utilisée pour l’élaboration du profil normal. Il peut y avoir des comportements normaux qui s’éloignent du profil normal, donc dans ce cas une fausse alerte peut être envoyée. L’avantage avec ce type IDS est qu’il peut même détecter les attaques qui ne sont pas encore connues.

  • Faux négatif (attaque mais pas d’alerte envoyée) :

Parfois les IDS laissent passer des attaques sans envoyer d’alertes pour les signaler, on parle de faux négatifs.

Cela arrive très souvent aux IDS à base de signatures, car la signature des attaques qu’ils sont sensés détectées se trouve déjà dans la base. Donc si de nouvelles attaques naissent alors que leurs signatures ne se trouvent pas dans la base, l’IDS va les laisser passer.

  • Vrai négatif (pas d’attaque donc pas d’alerte) :

Il n’y a pas d’alerte envoyée car l’IDS n’a détecté aucune attaque.

I.7 Les techniques d’évasion aux IDS

I.7.1 Attaque d’insertion

L’attaquant embrouille l’IDS en le forçant à lire des paquets invalides.

Il va insérer des données dans l’IDS à travers des paquets que ce dernier va accepter aveuglément et qui ont été rejetés par le système terminal.

Un NIDS est moins strict dans le traitement des paquets que le réseau interne.

L’attaquant dissimule du trafic supplémentaire et l’IDS va conclure que ce dernier est inoffensif. Par conséquent, l’IDS va recevoir plus de paquets que la destination.

I.7.2 Evasion

Cela consiste, pour l’attaquant, à faire accepter un paquet, que l’IDS va rejeter probablement, au système cible.

Avec cela, l’attaquant va exploiter l’hôte cible sans que jamais l’IDS ne s’en rende compte.

I.7.3 Déni de service (DoS)

Beaucoup d’IDS utilise un serveur centralisé pour journaliser les alertes. Si les attaquants connaissent l’adresse IP du serveur, ils peuvent initier des attaques de type DoS ou autre, pour le ralentir ou le faire planter.

De ce fait, les tentatives d’intrusions ne seront pas journalisées, donc pas de traces.

I.7.4 Technique de déroutement

C’est une technique consistant à l’attaquant de chiffrer la charge utile du paquet servant d’attaque de telle sorte que seule le destinataire pourrait le déchiffrer, mais pas l’IDS.

Il va manipuler le chemin indiqué dans la signature du paquet pour berner le HIDS.

L’attaquant peut aussi chiffrer les structures des attaques en Unicode pour contourner les filtres dans les IDS tout en étant compris par un serveur web IIS.

Il peut aussi utiliser un code polymorphe, c’est-à-dire créer des modèles d’attaque uniques, de ce fait l’attaque n’aura pas une signature unique. Cela va permettre de contourner les IDS à base de signatures.

Les attaques sur les protocoles cryptés tels que HTTPS sont déroutées si l’attaque en question a été cryptée.

I.7.5 Génération de faux positifs

L’attaquant va utiliser les fausses alertes pour cacher son trafic réel.

En effet, il va confectionner des paquets malveillants seulement pour générer un très grand nombre de faux positifs.

De ce fait, il pourra contourner l’IDS du moment où il est difficile de différencier le trafic provenant de l’attaque des faux positifs.

I.7.6 Session de raccordement

Les IDS disposent d’une technique de réassemblage de paquets. S’ils reçoivent un paquet fragmenté par exemple, ils attendent un certain délai pour recevoir les autres avant de les réassembler afin de pouvoir l’analyser.

Certains IDS arrêtent le réassemblage s’ils ne reçoivent pas de paquets pendant un certain temps.

Les attaquants sont conscients de cela et du délai. Du coup, ils divisent leur trafic en plusieurs et jouent sur ce délai pour contourner les IDS.

De ce fait, aucune tentative ne sera journalisée par les IDS.

I.7.7 Évasion Unicode

C’est un système de codage de caractère pour supporter l’échange, le traitement et l’affichage de textes écrits.

Tous les points du code sont traités différemment mais il est possible qu’il ait plusieurs représentations pour un seul caractère.

Certains IDS ne peuvent pas gérer correctement l’Unicode, du fait de la complexité de représentation dû au fait qu’un caractère peut avoir plusieurs interprétations.

Cela est avantageux pour les attaquants, car ça les permet de convertir les chaines issues de leurs attaques en caractères Unicode pour éviter les structures et correspondances de signatures mises en place dans l’IDS.

I.7.8 Attaque par fragmentation de paquet

La fragmentation peut être un vecteur d’attaque lorsque ses temps d’arrêt (timeouts) varient entre l’IDS et l’hôte.

Supposons que le timeout d’un fragment est de 10s au niveau de l’IDS et 20s sur le système cible, donc l’attaquant peut attendre 15s après le 1er fragment avant d’envoyer le second. L’IDS supprimera le deuxième fragment reçu après le temps de réassemblage, mais le système cible va réassembler les fragments.

L’attaquant va continuer d’envoyer la charge utile avec des délais de 15s jusqu’à ce que toute la charge de l’attaque soit réassemblée sur le système cible.

**********Démo avec HARMAN**********

I.7.9 Fragments superposés

C’est un type de superposition de numéros de séquence TCP sur une série de fragments minuscules : 1er 100 octets, 2ème 96 octets, et ainsi de suite.

Lors du réassemblage des paquets à destination, l’hôte doit savoir comment assembler les fragments TCP qui se chevauchent.

Certains systèmes d’exploitation vont prendre les fragments originaux avec un offset donné (w2k, xp, 2003) et d’autres vont prendre les fragments qui suivent avec un offset donné (Cisco IOS).

I.7.10 Attaque par TTL

Ici, la priorité est de connaitre la topologie du réseau. On peut utiliser Traceroute pour trouver le TTL, c’est-à-dire le nombre de sauts (routeurs) qui se trouvent entre l’attaquant et la victime.

Un paquet de ce type d’attaque se divise en 3 fragments :

  • Frag1 envoyé avec un TTL élevé, Frag2 avec un TTL faible ;
  • L’IDS va recevoir les fragments ensemble, mais la victime reçoit le premier seulement ;
  • Le Frag3 va être envoyé avec un TTL élevé ;
  • L’IDS fait le réassemblage dans un paquet insignifiant et supprime ;
  • Par contre, la victime reçoit un vrai Frag2 et subit une attaque, sans entrée.

I.7.11 Paquets RST invalides

TCP utilise 16bits pour la somme de contrôle. Cette dernière permet de vérifier les erreurs dans l’entête et dans les données.

Le flag RST de l’entête TCP permet de fermer une connexion.

L’attaquant va envoyer un paquet RST avec une somme de contrôle invalide. Avec ce paquet, l’IDS va arrêter le traitement du paquet en pensant que la session de communication est terminée, mais le paquet va arriver à destination de la cible.

Le système cible va vérifier la somme de contrôle du paquet RST et finit par supprimer ce dernier.

Cette attaque permet à l’attaquant de communiquer avec la cible alors que l’IDS pense que la communication est terminée.

I.7.12 Flag d’urgence

Le flag URG, sur 16bits, de l’entête TCP est utilisé pour un traitement urgent à la destination.

Le pointeur URG pointe sur le dernier octet des données urgentes dans le fragment.

De nombreux IDS ne considèrent pas le pointeur urgent et traitent tous les paquets du trafic, mais la cible traite seulement les données urgentes.

Alors, l’IDS et la cible auront des ensembles de paquets différents. Cela peut être exploité par les attaquants pour transmettre leurs trafics.

I.7.13 Shellcode polymorphe

Un NIDS à base de signatures détecte les attaques en cherchant une correspondance des signatures des paquets du trafic entrant et sortant dans sa base comportant un ensemble de signatures d’attaques connues.

L’IDS identifie les signatures pour les chaines utilisées couramment et intégrées dans le Shellcode.

Il est difficile de détecter la signature des attaques polymorphes, car réalisées avec de multiples signatures.

La charge utile sera chiffrée en utilisant quelques astuces. Par conséquent, le Shellcode est complétement réécrit à chaque fois qu’il est envoyé pour une détection d’évasion.

Cette technique évite d’utiliser les chaines de Shellcode courantes, ce qui va rendre ainsi ses signes inutilisables.

I.7.14 Shellcode ASCII

Le Shellcode ASCII inclut les caractères qui sont seulement présents dans la table ASCII.

Il ne correspond pas effectivement aux modèles.

La portée de l’ASCII est limitée car toutes les instructions rassemblées ne peuvent pas être converties en valeurs ASCII directement. Cette limitation peut être franchise en utilisant d’autres ensembles d’instructions pour faire correctement la conversion en valeurs ASCII

I.7.15 Attaques au niveau Application

Les applications qui accèdent aux fichiers média comme audio, images, vidéos, etc. compressent ces derniers en une taille très petite pour maximiser le taux de transfert.

Les IDS ne peuvent pas vérifier la signature d’un format de fichier compressé. Du coup, cela peut être exploité par un attaquant qui va utiliser cette vulnérabilité de données compressées.

L’IDS peut reconnaitre des conditions particulières de l’attaque, mais des alternatives sont présentes.

Cela rend difficile la détection des attaques par l’IDS.

I.7.16 Désynchronisation

I.7.16.1 Pré connexion SYN

Cela consiste à l’envoi d’un paquet SYN initial, avant que la vraie connexion ne soit établie, avec une somme de contrôle TCP invalide.

Si le paquet est reçu après l’ouverture du bloc de contrôle TCP, l’IDS réinitialise le numéro de séquence pour le faire correspondre avec le paquet SYN nouvellement reçu.

L’attaquant envoie un faux paquet SYN avec un numéro de séquence complètement invalide pour désynchroniser l’IDS. Ce qui va entrainer l’arrêt de la surveillance de l’IDS.

I.7.16.2 Post connexion SYN

Cela consiste à désynchroniser l’IDS à travers le numéro de séquence, envoyer un paquet SYN après l’établissement de la connexion et enfin resynchroniser. Il va ignorer que c’est une partie légitime du flux original.

Après avoir réussi la resynchronisation de l’IDS avec un paquet SYN, un paquet RST va être envoyé avec un nouveau numéro de séquence et la connexion va se fermer.

I.7.17 Autres types d’évasion

Il existe d’autres techniques d’évasion des IDS : le cryptage des données et l’inondation de paquets.

I.8 Les techniques de défenses contre l’évasion aux IDS

Pour se défendre contre les évasions aux IDS, il faut :

  • Fermer les ports associés aux hôtes des attaques connues ;
  • Corriger/mettre à jour régulièrement tous les systèmes ;
  • Déployer un IDS après une analyse minutieuse de la topologie, de la nature et du nombre d’hôtes du réseau ;
  • Utiliser des paquets RST et FIN pour mettre fin aux sessions TCP malveillantes ;
  • Mettre à jour les signatures d’antivirus ;
  • Stocker les informations sur les attaques pour un besoin dans le futur ;
  • S’assurer que les IDS normalisent les paquets fragmentés et autorisent les paquets à réassembler dans le bon ordre ;
  • Durcir la sécurité de tous les équipements tels que les modems, les routeurs, les commutateurs, etc.

II. Les pare-feu (Firewall)

II.1 Définition

Un pare-feu est un dispositif matériel ou logiciel permettant de prévenir les accès non autorisés depuis ou vers un réseau privé.

Il est souvent placé pour être une passerelle entre deux réseaux (privé et public habituellement).

Le pare-feu analyse l’ensemble du trafic entrant et sortant de l’Intranet afin de bloquer ceux qui ne répondent pas aux critères de sécurité.

Pour en savoir plus, consultez la section III de ce lien : https://techno-skills.com/composants-reseau/.

II.2 Positionnement d’un pare-feu

II.2.1 Hôte de Bastion (Bastion Host)

Cette architecture permet de protéger les ressources du réseau contre les attaques.

Ici, le pare-feu à deux interfaces, l’une connectée au réseau privé (LAN) et l’autre connectée au réseau public (Internet).

II.2.2 Sous réseau caché (Screened Subnet)

Ce positionnement du pare-feu va permettre de diviser le réseau en trois grandes zones :

  • La zone privée (LAN) : cette zone ne peut pas être accédée par les internautes, seuls les utilisateurs internes y auront accès.
  • La zone publique (WAN) : les utilisateurs du LAN peuvent accéder dans cette zone. Par contre les requêtes venant de cette zone seront traitées par la zone DMZ.
  • La zone démilitarisée (DMZ) : c’est la zone cachée ; elle sert de tampon entre le réseau sécurisé interne (LAN) et le réseau non sécurisé (public).

II.2.3 Pare-feu Multi-Homed

Ce pare-feu va permettre d’avoir une subdivision supplémentaire (au moins 4 zones).

II.3 Les technologies d’un pare-feu

II.3.1 Filtrage simple de paquet

Le filtrage se fait au niveau de la couche réseau du modèle OSI (internet du modèle TCP/IP), donc n’inspecte que les paquets IP.

Pour ce filtrage, chaque paquet est comparé à un ensemble de critère avant d’être transmis.

En fonction de ces critères, le pare-feu va décider s’il va transmettre ou non le paquet.

II.3.2 Passerelle de niveau circuit

Ce travail se fait à la couche session du modèle OSI (couche transport du modèle TCP/IP).

Les informations transmises à l’ordinateur distant à travers une passerelle de niveau circuit, semblent provenir de la passerelle.

Le pare-feu surveille les requêtes afin de créer des sessions.

Les pare-feu mandataires de circuit autorisent ou empêchent les flux de données.

II.3.3 Filtrage dynamique (ou filtrage de paquet avec état)

Il combine le filtrage simple, la passerelle de niveau circuit et le filtrage applicatif.

Il permet de filtrer les paquets à la couche réseau du modèle OSI pour déterminer s’ils sont légitimes et ensuite les évaluer au niveau de la couche Application.

La plupart des communications repose sur le protocole TCP, qui nécessite une ouverture de session afin d’établir un circuit de communication.

II.3.4 Passerelle applicatif

Ce type de pare-feu est aussi appelé passerelle applicatif, plus connu sous le nom de Proxy.

Le Proxy permet de filtrer le trafic application par application.

Il travaille comme un serveur proxy et filtre les connexions pour des services spécifiques en se basant sur leurs protocoles.

Le filtrage applicatif suppose donc une très bonne connaissance des protocoles de communication, car analysant finement les paquets.

II.3.5 Réseau privé virtuel (VPN)

Un VPN est un réseau privé conçu en utilisant un réseau public, tel qu’Internet, dans le but de sécuriser les communications.

Il permet d’établir une connexion virtuelle point à point à travers des connexions dédiées.

Le VPN est privé, donc seuls les équipements ayant les logiciels VPN qui tourne en local peuvent avoir accès à ce réseau.

II.4 Les limites d’un pare-feu

Comme toute technologie, un pare-feu a ses limites. On peut en citer quelques-unes :

  • Il ne peut pas protéger contre un nouveau virus, un Backdoor et des attaques internes ;
  • Il ne peut pas protéger lorsque la conception du réseau et la configuration sont défectueuses ;
  • Ce n’est pas une alternative pour un antivirus ou pour une protection contre les programmes malveillantes ;
  • Il ne peut pas protéger les systèmes d’exploitation contre leurs menaces ;
  • Il ne se soucie pas de la mauvaise utilisation des mots de passe ;
  • Il ne comprend que les attaques provenant des ports et applications fréquents ;
  • Il est incapable de comprendre le trafic tunnelé.

II.5 Les techniques d’évasion aux pare-feu

II.5.1 Usurpation d’adresse IP

Cela consiste à usurper les informations sur l’adressage IP se trouvant dans l’entête du paquet IP, plus particulièrement dans le champ de l’adresse IP source.

Cette représente celle d’un utilisateur légitime et l’attaquant va l’utiliser pour contourner le pare-feu du moment où cet utilisateur a été autorisé dans le pare-feu.

II.5.2 Routage à la source

La route peut être partiellement ou entièrement spécifiée pour guider le paquet dans le réseau.

Comme le paquet voyage à travers les nœuds du réseau, chaque routeur va examiner l’adresse IP de destination afin de choisir le prochain saut à s’adresser.

L’expéditeur prend certaines ou toutes ces décisions au niveau du routeur.

II.5.3 Contournement à travers un tunnel SSH

SSH permet d’obtenir un accès à distance sur un équipement. Les informations échangées lors de la tentative d’accès peuvent être visibles pour les barrières de sécurité comme les pare-feu.

Pour les masquer, il est possible d’utiliser OPENSSH pour crypter et tunneler tout le trafic.

On peut aussi utiliser d’autres outils comme Bitvise, Secure Pipes, etc.

II.5.4 Contournement à travers des systèmes externes

Le but est d’utiliser certains systèmes externes pour avoir accès au réseau.

L’attaquant va renifler le réseau pour voir le trafic utilisateur, voler un identifiant de session et des cookies.

Cela va lui permettre d’accéder au réseau de l’organisation, de contourner les pare-feu, obtenir l’identifiant de la fenêtre du processus Mozilla en cours d’exécution sur le système de l’utilisateur.

Il va utiliser la commande openURL() à la fenêtre trouvée, ouvrir le navigateur du client et entrer dans son serveur web.

Le code malveillant de son site Web est téléchargé et exécuté sur la machine de l’utilisateur.

II.5.5 Contournement à travers une attaque de type Man In The Middle (MITM)

L’attaquant va utiliser l’empoisonnement de serveur DNS.

En effet, il va envoyer une requête pour WWW.CERTIFIEDHACKER.COM au serveur DNS de l’organisation. Ce dernier envoie l’adresse IP à l’attaquant.

L’utilisateur va accéder au serveur malveillant et l’attaquant va se connecter avec un vrai hôte pour tunneler le trafic http de l’utilisateur.

Le code malveillant de sa page web est téléchargé et exécuté sur la machine de l’utilisateur.

II.5.6 Contournement en utilisant l’attaque XSS

Avec ce type de contournement, on peut utiliser

  • des paramètres d’entrées telles qu’un simple code en JavaScript (ex : <script>alert(« xss »)</script>) ;
  • des valeurs ASCII pour la charge utile (ex : <script>string.fromCharCode(97, 108, 101, 114,etc)</script>) ;
  • un codage en hexadécimal pour contourner les WAF (ex : %73%63%69%70%28%3E) ;
  • ou des déroutement pour obscurcir le jugement des WAF (ex : <sCriPT>aLeRT(« xss »)</sCriPT>) ;

II.5.7 Autres techniques d’évasion

On peut citer d’autres techniques d’évasion telles que :

  • Utilisation d’une adresse IP à la place d’un URL :

Au lieu d’utiliser les noms de domaines, l’attaquant utilise les adresses IP dans l’URL pour contourner les pare-feu.

On peut utiliser Host2ip pour trouver l’adresse IP.

  • Utilisation de sites anonymes :

Les sites anonymes comme ANONYMIZER.COM, GUARDSTER.COM, ZENDPROXY.COM, PROXIFY.COM peuvent être utiliser pour contourner les pare-feu.

  • Utilisation de serveurs Proxy :

On peut configurer un Proxy dans les propriétés d’Internet pour l’utilise afin de réussir le contournement.

  • ICMP tunneling :

Certains administrateurs autorisent le trafic ICMP dans les pare-feu pour pouvoir utiliser les outils tels que Ping et Traceroute.

Cela peut être exploité par un attaquant afin de contourner les pare-feu.

  • ACK tunneling :

Les paquets TCP avec le bit ACK positionné, utilisés pour acquitter la réception d’un paquet, peuvent être à l’origine de contournements, car certains pare-feu ne vérifient pas ces paquets parce qu’ils sont supposés appartenir à un trafic légitime.

Ouitls : AckCmd.(ntsecurity.nu).

  • HTTP tunneling :

Si une organisation utilise un serveur web public et qu’elle autorise les trafics sur le port 80 dans leurs pare-feu, un attaquant peut utiliser cela en encapsulant ses données sur un trafic http.

Il peut aussi activer le protocole FTP via http si les ports 80 et 443 sont libres.

Outils : HTTPPORT AND HTTHOST, SUPER NETWORK TUNNEL.

II.6 Les techniques de défenses contre l’évasion aux pare-feu

Pour se défendre contre les évasions aux pare-feu, il faut :

  • Configurer le pare-feu à filtrer les adresses IP d’un intrus ;
  • Mettre en place un ensemble de règles permettant d’interdire tous les trafics sauf les services dont on a besoin ;
  • Désactiver FTP ;
  • Élaborer la liste et passer en revue tous les trafics entrants et sortants ;
  • Contrôler l’accès physique au pare-feu ;
  • Planifier des audits réguliers de la sécurité du pare-feu ;
  • Spécifier les adresses IP ainsi que les ports source et destination ;
  • Surveiller et contrôler l’accès des utilisateurs au pare-feu.

III. Les pots de miel (Honeypots)

III.1 Définition

Un Honeypot est un ordinateur ou programme volontairement vulnérable destiné à attirer et à piéger les pirates.

Il a pour but :

  • D’occuper le pirate ;
  • De découvrir ses intentions ;
  • De découvrir de nouvelles attaques ;
  • De garder le maximum de traces des attaques.

III.2 Les types de Honeypot

Il existe différents types de Honeypot :

  • Faible interaction : nombre limité de services pour collecter une plus grande quantité d’informations ; émulation de services sans réel système sous-jacent.
  • Interaction moyenne : il simule un vrai système d’exploitation, services et application ; il ne répond que pour les commandes préconfigurées.
  • Forte interaction : il simule tous les services ; informations complètes sur un vecteur, intension et outils d’attaque.
  • Honeypots de production : ils émulent un vrai réseau de production d’une organisation ; mis en place pour collecter des imperfections internes et détecter les attaquants à l’intérieur de l’organisation.
  • Honeypots de recherche : essentiellement déployés pour les gouvernements, l’armée, la recherche ; les vulnérabilités sont exploitées et des techniques d’attaque apprises.

III.3 Détection de pots de miel

Il est possible de détecter un pot de miel (Honeypot) en faisant une sonde pour détecter les services en cours d’exécution.

En effet, il va falloir utiliser des paquets de sonde malveillants pour faire le scan pour des services tels que HTTP sur HTTPS, SMTP sur SMTPS, IMAP sur IMAPS.

S’il y a une présence de Honeypot, les ports avec des services particuliers en cours d’exécution vont refuser l’établissement de connexion TCP complète (3-way hanshake).

Il y a des outils pour faire la sonde comme Send-safe Honeypot hunter, Nessus, Hping.

COMBATTRE ET DETECTER UN HONEYPOT :

  • Surveiller la latence de la réponse ;
  • Analyser le taille de la fenêtre TCP ;
  • Si l’attaquant est dans le même réseau, analyser les réponses avec des adresses MAC uniques qui agissent comme une sorte de trou noir.
  • Regarder la norme IEEE pour la plage actuelle des adresses MAC assignées au VMWare Inc.
  • Réaliser des méthodes d’empreinte digitale TCP basées sur le temps (SYN proxy behavior) ;
  • Analyser la congestion dans la couche réseau ;
  • Analyser les paramètres TCP/IP spécifiques telles que like RTT, TTL, TCP timestamp etc.

Des outils pour mener à bien cette détection et ce combat : Send-safe Honeyport hunter.

IV. Tests de pénétrations sur les IDS et les pare-feu

IV.1 Tests de pénétration sur un pare-feu

Étape 1 : tracer la cible.

Étape 2 : effectuer un scan de port pour détecter le pare-feu.

Étape 3 : pare-feu détecté ? ———- (NON) —- > aller à 4, ———- (OUI) —- > aller à 6.

Étape 4 : effectuer une récupération de bannière (banner grabbing) pour détecter le pare-feu.

Étape 5 : pare-feu détecté ?

Étape 6 : effectuer le Firewalking (qui permet de manière générale à déterminer les règles de filtrage sur un équipement) pour détecter le pare-feu

Étape 7 : pare-feu détecté ? ———- (OUI) —- > aller à 9, ———- (NON) —- > aller à 8.

Étape 8 : pas de pare-feu.

Étape 9 : désactiver un hôte légitime.

Étape 10 : effectuer une usurpation d’adresse IP.

Étape 11 : effectuer le routage à la source.

Étape 12 : effectuer une fragmentation IP.

Étape 13 : utiliser une adresse IP à la place d’un URL.

Étape 14 : utiliser les sites web anonymes.

Étape 15 : utiliser les serveurs Proxy.

Étape 16 : effectuer l’ICMP tunneling.

Étape 17 : effectuer ACK tunneling.

Étape 18 : effectuer HTTP tunneling.

Étape 19 : effectuer SSH tunneling.

Étape 20 : utiliser les systèmes externes.

Étape 21 : effectuer l’attaque MITM.

Étape 22 : effectuer l’attaque XSS.Étape 23 : Documenter les résultats.

IV.2 Tests de pénétration sur un IDS

Étape 1 : désactiver un hôte légitime.

Étape 2 : effectuer l’attaque de type insertion.

Étape 3 : mettre en place une technique d’évasion.

Étape 4 : réaliser une attaque DoS.

Étape 5 : dérouter ou crypter la charge utile du paquet servant d’attaque.

Étape 6 : réaliser la technique de génération de faux positifs.

Étape 7 : effectuer la technique de la session de raccordement.

Étape 8 : effectuer la technique d’évasion Unicode.

Étape 9 : effectuer l’attaque par fragmentation.

Étape 10 : effectuer la technique de fragments superposés.

Étape 11 : effectuer l’attaque par TTL.

Étape 12 : effectuer la technique de paquets RST invalides.

Étape 13 : effectuer la technique de flag d’urgence.

Étape 14 : effectuer la technique du Shellcode polymorphe.

Étape 15 : effectuer la technique du Shellcode ASCII.

Étape 16 : couche application.

Étape 17 : techniques de cryptage et d’inondation de paquets.

Étape 18 : effectuer l’attaque Post connexion SYN

Étape 19 : effectuer l’attaque Pré connexion SYN

Étape 20 : documenter les résultats.

OUTILS DE DETECTION D’INTRUSION :

TIPPING POINT, FORTIGATE IPS, OSSEC, SURICATA, SNARE, CHECK POINT IPS SOFTWARE.

MOBILE: zIPS, WIFI INSPECTOR, WIFI INTRUDER DETECTOR PRO.

PARE-FEU :

ZoneAlarmPro, FirewallAnalyzer, comodo firewall, Cisco ASA, PeerBlock, Fortigate-Nextgen firewall.

MOBILE: Mobiwol, Mobile Privacy shield, netpatch firewall. firewall gold, root firewall.

OUTILS HONEYPOT :

KFSensor, SPECTER, Honeybot, galstopf, Sebek, UML, Honeyd, Labrea, Honeyd,

MOBILE: HosTaGe, Network guard.

OUTILS D’EVASION IDS/PARE-FEU :

TRAFFIC IQ PROFESSIONAL, FTESTER, HOTSPOT SHIELD, TOMAHAWK, SNARE AGENT FOR WINDOWS.

OUTILS GENERATEURS DE FRAGMENTS DE PAQUETS : COLASOFT PACKET BUILDER, NETSCANTOOLS PRO, OSTINATO.

<<< detournement de session
piratage de serveurs web >>>