Techniques d’évasion des attaquants

Qu’il s’agisse de collecter des informations ou de lancer une attaque, on s’attend généralement à ce que l’attaquant évite d’être détecté. Bien que certaines analyses d’adresses IP et de ports soient flagrantes et facilement détectables, les attaquants les plus rusés utilisent une variété de moyens pour dissimuler leur activité. Des techniques telles que l’utilisation d’analyses FIN au lieu d’analyses SYN, que les attaquants savent que la plupart des pare-feu et des programmes de détection d’intrusion détectent, indiquent une évolution des techniques de reconnaissance et d’exploitation pour échapper à la détection et accomplir leurs tâches avec succès.

Une analyse FIN envoie des segments TCP avec l’indicateur FIN défini dans le but de provoquer une réponse (un segment TCP avec l’indicateur RST défini) et ainsi découvrir un hôte actif ou un port actif sur un hôte. Les attaquants peuvent utiliser cette approche plutôt que d’effectuer un balayage d’adresse avec des requêtes d’écho ICMP ou un balayage d’adresse avec des segments SYN, car ils savent que de nombreux pare-feu protègent généralement contre ces deux dernières approches, mais pas nécessairement contre les segments FIN. L’utilisation de segments TCP avec l’indicateur FIN peut échapper à la détection et ainsi aider les attaquants à réussir leurs efforts de reconnaissance.

Par défaut, Junos OS recherche les indicateurs SYN dans le premier paquet d’une session et rejette tous les segments TCP avec des indicateurs non-SYN qui tentent de lancer une session. Vous pouvez laisser ce flux de paquets tel quel ou le modifier afin que Junos OS n’applique pas la vérification des indicateurs SYN avant de créer une session. La Figure 1 illustre les séquences de flux de paquets lorsque la vérification des indicateurs SYN est activée et lorsqu’elle est désactivée.

Figure 1 : vérification de l’indicateur SYN

Lorsque Junos OS avec la vérification des indicateurs SYN activée reçoit un segment TCP non-SYN qui n’appartient pas à une session existante, il abandonne le paquet. Par défaut, Junos OS n’envoie pas de TCP RST à l’hôte source à la réception du segment non-SYN. Vous pouvez configurer le périphérique pour qu’il envoie TCP RST à l’hôte source à l’aide de la set security zones security-zone trust tcp-rst commande. Si le bit de code du paquet TCP initial non-SYN est RST, l’équipement n’envoie pas de TCP-RST.

Ne pas vérifier l’indicateur SYN dans les premiers paquets offre les avantages suivants :

• NSRP avec routage asymétrique : dans une configuration NSRP active/active dans un environnement de routage dynamique, un hôte peut envoyer le segment TCP initial avec l’indicateur SYN défini à un périphérique (Device-A), mais le SYN/ACK peut être acheminé vers l’autre périphérique du cluster (Device-B). Si ce routage asymétrique se produit après que l’appareil A a synchronisé sa session avec l’appareil B, tout va bien. En revanche, si la réponse SYN/ACK atteint l’appareil B avant que l’appareil A ne synchronise la session et que la vérification SYN soit activée, l’appareil B rejette l’appareil SYN/ACK et la session ne peut pas être établie. Lorsque la vérification SYN est désactivée, l’appareil B accepte la réponse SYN/ACK, même s’il n’existe aucune session existante à laquelle elle appartient, et crée une nouvelle entrée de table de session pour celle-ci.

• Sessions ininterrompues : si vous réinitialisez l’appareil ou même modifiez un composant dans la section principale d’une stratégie et que la vérification SYN est activée, toutes les sessions existantes ou les sessions auxquelles la modification de stratégie s’applique sont interrompues et doivent être redémarrées. La désactivation de la vérification SYN permet d’éviter de telles perturbations des flux de trafic réseau.

  Note:

  Une solution à ce scénario consiste à installer l’appareil en désactivant initialement la vérification SYN. Puis, au bout de quelques heures, lorsque des sessions établies sont en cours d’exécution sur l’appareil, activez la vérification SYN. La section principale d’une stratégie contient les principaux composants suivants : les zones source et de destination, les adresses source et de destination, un ou plusieurs services et une action.

Cependant, les avantages précédents exigent les sacrifices de sécurité suivants :

• Trous de reconnaissance : lorsqu’un segment TCP initial avec un indicateur non SYN (tel que ACK, URG, RST, FIN) arrive sur un port fermé, de nombreux systèmes d’exploitation (Windows, par exemple) répondent avec un segment TCP dont l’indicateur RST est défini. Si le port est ouvert, le destinataire ne génère aucune réponse.

  En analysant ces réponses ou leur absence, un collecteur de renseignements peut effectuer une reconnaissance sur le réseau protégé ainsi que sur le jeu de stratégies Junos OS. Si un segment TCP est envoyé avec un ensemble d’indicateurs non-SYN et que la stratégie l’autorise, l’hôte de destination recevant un tel segment peut l’abandonner et répondre avec un segment TCP dont l’indicateur RST est défini. Une telle réponse informe l’auteur de la présence d’un hôte actif à une adresse spécifique et que le numéro de port ciblé est fermé. Le collecteur d’informations apprend également que la stratégie de pare-feu autorise l’accès à ce numéro de port sur cet hôte.

  En activant la vérification des indicateurs SYN, Junos OS supprime les segments TCP sans indicateur SYN s’ils n’appartiennent pas à une session existante. Il ne renvoie pas de segment TCP RST. Par conséquent, l’analyseur n’obtient aucune réponse, quelle que soit la stratégie définie ou si le port est ouvert ou fermé sur l’hôte ciblé.

• Sessions Table Floods (Inondations de tables de sessions) : si la vérification SYN est désactivée, un attaquant peut contourner la fonctionnalité de protection contre les inondations SYN de Junos OS en inondant un réseau protégé d’un barrage de segments TCP sur lesquels des indicateurs non-SYN sont définis. Bien que les hôtes ciblés abandonnent les paquets et envoient éventuellement des segments TCP RST en réponse, un tel flood peut remplir la table de session du périphérique Juniper Networks. Lorsque la table des sessions est pleine, l’équipement ne peut pas traiter de nouvelles sessions pour le trafic légitime.

  En activant la vérification SYN et la protection contre les inondations SYN, vous pouvez déjouer ce type d’attaque. Vérifier que l’indicateur SYN est défini sur le paquet initial d’une session force toutes les nouvelles sessions à commencer par un segment TCP sur lequel l’indicateur SYN est défini. La protection contre les inondations SYN limite alors le nombre de segments TCP SYN par seconde afin que la table de sessions ne soit pas submergée.

Si vous n’avez pas besoin de désactiver la vérification SYN, Juniper Networks vous recommande vivement de l’activer (son état par défaut pour une installation initiale de Junos OS). Vous pouvez l’activer à l’aide de la set flow tcp-syn-check commande. Lorsque la vérification SYN est activée, l’équipement rejette les segments TCP dont les indicateurs non-SYN sont définis, sauf s’ils appartiennent à une session établie.

Une méthode pour tenter d’accéder à une zone restreinte du réseau consiste à insérer une fausse adresse source dans l’en-tête du paquet pour faire croire que le paquet provient d’une source fiable. Cette technique s’appelle l’usurpation d’adresse IP. Le mécanisme de détection de l’usurpation d’adresse IP repose sur les entrées de la table de routage. Par exemple, si un paquet avec l’adresse IP source 10.1.1.6 arrive à ge-0/0/1, mais que Junos OS a une route vers 10.1.1.0/24 via ge-0/0/0, une vérification de l’usurpation d’adresse IP découvre que cette adresse est arrivée à une interface non valide telle que définie dans la table de routage. Un paquet valide de 10.1.1.6 ne peut arriver que via ge-0/0/0, et non ge-0/0/1. Par conséquent, Junos OS conclut que le paquet a une adresse IP source usurpée et l’ignore. Junos OS détecte et supprime les paquets usurpés IPv4 et IPv6.

Cet exemple montre comment configurer un écran pour bloquer les attaques par usurpation d’adresse IP.

Lors d’une attaque par usurpation d’usurpation d’adresse IP, l’attaquant accède à une zone restreinte du réseau et insère une fausse adresse source dans l’en-tête du paquet pour faire croire que le paquet provient d’une source fiable. L’usurpation d’adresse IP est le plus souvent utilisée dans les attaques par déni de service (DoS). Lorsque les pare-feu SRX Series fonctionnent en mode transparent, le mécanisme de vérification de lusurpation d’adresse IP utilise les entrées du carnet d’adresses. Les carnets d’adresses n’existent que sur le moteur de routage. L’usurpation d’adresse IP en mode transparent de couche 2 est effectuée sur le moteur de transfert de paquets. Les informations du carnet d’adresses ne peuvent pas être obtenues à partir du moteur de routage chaque fois qu’un paquet est reçu par le moteur de transfert de paquets. Par conséquent, les carnets d’adresses attachés aux zones de couche 2 doivent être envoyés au moteur de transfert de paquets.

Lorsqu’un paquet est reçu par le moteur de transfert de paquets, l’adresse IP source du paquet est vérifiée pour déterminer s’il se trouve dans le carnet d’adresses de la zone entrante. Si l’adresse IP source du paquet se trouve dans le carnet d’adresses de la zone entrante, cette adresse IP est autorisée sur l’interface et le trafic est transmis.

Si l’adresse IP source n’est pas présente dans le carnet d’adresses de la zone entrante, mais qu’elle existe dans d’autres zones, alors l’adresse IP est considérée comme une adresse IP usurpée. En conséquence, des actions telles que la perte et la journalisation peuvent être prises en fonction de la configuration de l’écran (alarme-sans-chute).

Si l’adresse IP source d’un paquet n’est pas présente dans le carnet d’adresses de la zone entrante ou dans d’autres zones, vous ne pouvez pas déterminer si l’adresse IP est usurpée ou non. Dans ce cas, le paquet est transmis.

Junos OS prend en compte les conditions de correspondance suivantes lorsqu’il recherche des adresses IP sources dans le carnet d’adresses :

• Host-match: la correspondance d’adresse IP trouvée dans le carnet d’adresses est une adresse sans préfixe.

• Prefix-match: la correspondance d’adresse IP trouvée dans le carnet d’adresses est une adresse avec un préfixe.

• Any-match: la correspondance d’adresse IP trouvée dans le carnet d’adresses est « any », « any-IPv4 » ou « any-IPv6 ».

• No-match—Aucune correspondance d’adresse IP n’a été trouvée.

Le routage source a été conçu pour permettre aux utilisateurs à la source d’une transmission de paquets IP de spécifier les adresses IP des périphériques (également appelés « sauts ») le long du chemin qu’ils souhaitent qu’un paquet IP emprunte pour se rendre à sa destination. À l’origine, les options de routage source IP avaient pour but de fournir des outils de contrôle du routage pour faciliter l’analyse diagnostique. Si, par exemple, la transmission d’un paquet vers une destination particulière rencontre un succès irrégulier, vous pouvez d’abord utiliser l’option d’enregistrement ou d’horodatage IP pour découvrir les adresses des périphériques le long du ou des chemins empruntés par le paquet. Vous pouvez ensuite utiliser l’option de route source lâche ou stricte pour diriger le trafic le long d’un chemin spécifique, en utilisant les adresses que vous avez apprises à partir des résultats produits par les options d’itinéraire d’enregistrement ou d’horodatage. En modifiant les adresses des périphériques pour modifier le chemin et en envoyant plusieurs paquets sur des chemins différents, vous pouvez noter les modifications qui améliorent ou diminuent le taux de réussite. Grâce à l’analyse et au processus d’élimination, vous pourriez être en mesure de déduire où se situe le problème. Reportez-vous à la figure 2.

Figure 2 : routage des sources IP

Bien que l’utilisation des options de routage source IP soit à l’origine bénigne, les attaquants ont appris à les utiliser à des fins plus détournées. Ils peuvent utiliser les options de route source IP pour masquer leur véritable adresse et accéder aux zones restreintes d’un réseau en spécifiant un chemin différent. Pour obtenir un exemple illustrant comment un attaquant peut utiliser ces deux tromperies, considérez le scénario suivant, illustré à la figure 3.

Figure 3 : option de routage de source IP lâche pour la tromperie

Junos OS n’autorise le trafic 2.2.2.0/24 que s’il passe par Ethernet1, une interface liée à zone_external. Les appareils 3 et 4 appliquent les contrôles d’accès, mais pas les appareils 1 et 2. En outre, l’appareil 2 ne vérifie pas l’usurpation d’adresse IP. L’attaquant usurpe l’adresse source et, à l’aide de l’option loose source route, dirige le paquet via l’appareil 2 vers le réseau 2.2.2.0/24 et de là vers l’équipement 1. L’équipement 1 le transmet à l’appareil 3, qui lui-même est transféré à l’équipement Juniper Networks. Étant donné que le paquet provient du sous-réseau 2.2.2.0/24 et qu’il possède une adresse source provenant de ce sous-réseau, il semble être valide. Cependant, il reste un vestige de la chicane antérieure : l’option de route source lâche. Dans cet exemple, vous avez activé l’option d’écran de routage source IP de refus pour zone_external. Lorsque le paquet arrive à Ethernet3, l’appareil le rejette.

Vous pouvez permettre à l’équipement de bloquer tous les paquets avec des options de routage source lâches ou strictes définies ou de détecter ces paquets, puis d’enregistrer l’événement dans la liste des compteurs de l’interface d’entrée. Les options d’écran sont les suivantes :

• Deny IP Source Route Option (Refuser l’option de route source IP) : activez cette option pour bloquer tout le trafic IP qui utilise l’option de route source lâche ou stricte. Les options de route source peuvent permettre à un attaquant d’accéder à un réseau avec une fausse adresse IP.

• Detect IP Loose Source Route Option (Détecter l’option IP Loose Source Route Option) : l’équipement détecte les paquets pour lesquels l’option IP est 3 (Loose Source Routing) et enregistre l’événement dans la liste des compteurs d’écran de l’interface d’entrée. Cette option spécifie une liste partielle de routes pour qu’un paquet effectue son voyage de la source à la destination. Le paquet doit se dérouler dans l’ordre des adresses spécifié, mais il est autorisé à passer par d’autres périphériques entre ceux spécifiés.

• Option Detect IP Strict Source Route (Détecter l’adresse IP Strict Source Route Option) : l’équipement détecte les paquets pour lesquels l’option IP est 9 (Strict Source Routing) et enregistre l’événement dans la liste des compteurs d’écran de l’interface d’entrée. Cette option spécifie la liste complète des routes qu’un paquet doit emprunter pour son voyage de la source à la destination. La dernière adresse de la liste remplace l’adresse dans le champ de destination. Actuellement, cette option d’écran ne s’applique qu’à IPv4.

Cet exemple montre comment bloquer des paquets avec un ensemble d’options de route source lâche ou stricte.

Cet exemple montre comment détecter des paquets avec une option de route source lâche ou stricte.