Problème de filtre de trafic BotNet avec Adaptive Security Appliance

Introduction

Ce document décrit les étapes à suivre pour dépanner la fonctionnalité de filtre de trafic BotNet sur l'appliance de sécurité adaptative (ASA). Pour obtenir de l'aide sur la configuration du filtre de trafic BotNet, reportez-vous à ce guide de configuration : Configuration du filtre de trafic BotNet.

Informations générales

Le filtre de trafic BotNet surveille les requêtes et les réponses du serveur de noms de domaine (DNS) entre les clients DNS internes et les serveurs DNS externes. Lorsqu'une réponse DNS est traitée, le domaine associé à la réponse est vérifié par rapport à la base de données des domaines malveillants connus. En cas de correspondance, tout trafic supplémentaire vers l’adresse IP présente dans la réponse DNS est bloqué. Voir ce schéma.

1. Vérifiez la base de données de filtre dynamique. L'ASA télécharge régulièrement une base de données actuelle des domaines malveillants et des adresses IP connus. La SIO (Security Intelligence Operations) de Cisco détermine que les domaines et les adresses IP de cette base de données servent des programmes malveillants ou d'autres contenus malveillants.
2. Assurez-vous que le trafic DNS traverse l'ASA. Un utilisateur sur le réseau interne ou une machine infectée sur le réseau interne tente d'accéder à un serveur malveillant afin de télécharger un programme malveillant ou de participer à un BotNet. Pour se connecter au serveur malveillant, l’ordinateur hôte doit effectuer une recherche DNS. Dans cet exemple, la machine tente d'accéder à badsite.cisco.com. La machine hôte envoie une requête DNS à un serveur DNS local ou directement à un serveur DNS externe. Dans les deux cas, une requête DNS doit traverser l'ASA et la réponse DNS doit également traverser le même ASA.
3. Vérifiez le cache DNS-snoop. La fonction DNS-snoop de l'inspection DNS, si elle est activée, surveille le trafic DNS et détermine qu'une réponse d'enregistrement A DNS a été renvoyée par le serveur DNS. La fonction DNS-snoop prend le domaine et les adresses IP présents dans la réponse A-Record et l'ajoute au cache DNS-snoop. Le domaine est comparé à la base de données téléchargée à l'étape 1 et une correspondance est trouvée. La réponse DNS n'est pas abandonnée et est autorisée à passer.
4. Testez le filtre de trafic BotNet avec le trafic. Comme il y a eu correspondance à l'étape 3, l'ASA ajoute une règle interne qui indique que tout le trafic en provenance ou à destination de l'adresse IP associée à badsite.cisco.com est abandonné. L'ordinateur infecté tente ensuite d'accéder au serveur badsite.cisco.com et le trafic est abandonné. 

Dépannage du workflow

Suivez ces étapes afin de dépanner et de vérifier que la fonctionnalité fonctionne.

Étape 1 : Vérifier la base de données de filtre dynamique

Vérifiez si la base de données a été téléchargée et entrez la commande show dynamic-filter data. Voir cet exemple de résultat : 

# show dynamic-filter data      
Dynamic Filter is using downloaded database version '1404865586'
Fetched at 21:32:02 EDT Jul 8 2014, size: 2097145
Sample contents from downloaded database:
  dfgdsfgsdfg.com  bulldogftp.com  bnch.ru  52croftonparkroad.info
  paketoptom.ru  lzvideo.altervista.org  avtovirag.ru  cnner.mobi
Sample meta data from downloaded database:
  threat-level: very-high,	category: Malware,
  description: "These are sources that use various exploits to deliver adware, 
   spyware and other malware to victim computers.  Some of these are associated 
   with rogue online vendors and distributors of dialers which deceptively 
   call premium-rate phone numbers."  threat-level: high,	category: Bot 
   and Threat Networks,  description: "These are rogue systems that 
   control infected computers.     They are either systems hosted on 
   threat networks or systems that are part of the botnet itself
  threat-level: moderate,	category: Malware,
  description: "These are sources that deliver deceptive or malicious anti-spyware, 
   anti-malware, registry cleaning, and system cleaning software."
  threat-level: low,	category: Ads,
  description: "These are advertising networks that deliver banner ads, 
   interstitials, rich media ads, pop-ups, and pop-unders for websites, 
   spyware and adware.  Some of these networks send ad-oriented HTML emails 
   and email verification services."
Total entries in Dynamic Filter database:
  Dynamic data: 80677 domain names , 4168 IPv4 addresses
  Local data: 0 domain names , 0 IPv4 addresses
Active rules in Dynamic Filter asp table:
  Dynamic data: 0 domain names , 4168 IPv4 addresses
  Local data: 0 domain names , 0 IPv4 addresses

 Dans cette sortie, l'ASA indique l'heure de la dernière récupération de base de données réussie et un exemple du contenu de cette base de données. Si vous exécutez la commande show dynamic-filter data, et que la commande indique qu'aucune base de données n'a été téléchargée, dépannez d'abord cette étape. Les problèmes courants qui empêchent l'ASA d'obtenir la base de données de filtre dynamique sont les suivants :

• Configuration DNS manquante ou incorrecte sur l'ASA. Le client de mise à jour de filtre dynamique doit résoudre le nom d'hôte du serveur de mise à jour. Le DNS doit être configuré et fonctionnel sur l'ASA. Envoyez une requête ping aux domaines connus à partir de la ligne de commande et déterminez si l'ASA peut résoudre les noms d'hôte.
• Pas d'accès Internet à partir de l'ASA. Si l'ASA se trouve sur un réseau qui n'a pas accès à Internet, ou si un périphérique en amont bloque l'adresse IP externe de l'ASA de l'accès à Internet, la mise à jour échoue.
• Le client de mise à jour n'est pas activé. La commande dynamic-filter updater-client enable doit être configurée pour que l'ASA puisse télécharger la base de données.

Entrez la commande debug dynamic-filter updater-client afin de déboguer la base de données. Reportez-vous à cet exemple de résultat de la commande :

Dynamic Filter: Updater client fetching dataDynamic Filter: update 
startingDBG:01:2902417716:7fff2c33ec28:0000: Creating fiber 
0x7fff2c4dce90 [ipe_request_fiber], stack(16384) = 
0x7fff2c505c60..0x7fff2c509c58 (fc=2), 
sys 0x7fff20906038 (FIBERS/fibers.c:fiber_create:544)
DBG:02:2902417779:7fff2c4dce90:0000: Jumpstarting ipe_request_fiber 0x7fff2c4dce90, 
sys 0x7fff2c33eba0 (FIBERS/fibers-jumpstart.c:_fiber_jumpstart:36)
Dynamic Filter: Created lua machine, launching lua script
DBG:03:2902422654:7fff2c4dce90:0000: Connecting to 00000000:1591947792 
(SAL/netsal.c:netsal_client_sock_connect:323)
DBG:04:2902422667:7fff2c4dce90:0000: otherPifNum 3, nexthop4 17c12ac 
(SAL/netsal.c:netsal_client_sock_connect:374)
DBG:05:2902422691:7fff2c4dce90:0000: about to call netsal__safe_encapsulate for 
(sal-np/ssl/CONNECT/3/208.90.58.5/443/M/0/NOTUNGW) 
(SAL/netsal.c:netsal_client_sock_connect:446)
DBG:06:2902422920:7fff2c4dce90:0000: connection timeout set for 10 seconds 
(SAL/netsal.c:netsal_client_sock_connect:473)
DBG:07:2902750615:7fff2c4dce90:0000: SALNPCLOSENOTIFY: p=0x0 0/0 more buffered 
(SAL/channel-np.c:_sal_np_ioctl:1312)
Dynamic Filter: Processing updater server response
Dynamic Filter: update file url1 =
http://updates.ironport.com/threatcast/1.0/blacklist/2mb-1file/1404865586
Dynamic Filter: update file url2 =
http://updates.ironport.com/threatcast/1.0/blacklist/2mb-1file/1404865586
Channel NP p=0x0000000000000000 0/0 more bufferedchannel-np.cDBG:08:2902784011:
7fff2c4dce90:0000: Connecting to 00000000:538976288 
(SAL/netsal.c:netsal_client_sock_connect:323)
DBG:09:2902784026:7fff2c4dce90:0000: otherPifNum 3, nexthop4 17c12ac 
(SAL/netsal.c:netsal_client_sock_connect:374)
DBG:10:2902784051:7fff2c4dce90:0000: about to call netsal__safe_encapsulate for 
(sal-np/tcp/CONNECT/3/208.90.58.25/80/M/0/NOTUNGW) 
(SAL/netsal.c:netsal_client_sock_connect:446)
DBG:11:2902784241:7fff2c4dce90:0000: connection timeout set for 10 seconds 
(SAL/netsal.c:netsal_client_sock_connect:473)
DBG:12:2902914651:7fff2c4dce90:0000: SALNPCLOSENOTIFY: p=0x0 0/0 more buffered 
(SAL/channel-np.c:_sal_np_ioctl:1312)
DBG:13:2902914858:7fff2c4dce90:0000: Connecting to 00000000:25465757 
(SAL/netsal.c:netsal_client_sock_connect:323)
DBG:14:2902914888:7fff2c4dce90:0000: otherPifNum 3, nexthop4 17c12ac 
(SAL/netsal.c:netsal_client_sock_connect:374)
DBG:15:2902914912:7fff2c4dce90:0000: about to call netsal__safe_encapsulate for 
(sal-np/tcp/CONNECT/3/208.90.58.25/80/M/0/NOTUNGW) 
(SAL/netsal.c:netsal_client_sock_connect:446)
DBG:16:2902915113:7fff2c4dce90:0000: connection timeout set for 10 seconds 
(SAL/netsal.c:netsal_client_sock_connect:473)
Channel NP p=0x0000000000000000 0/0 more bufferedchannel-np.cDBG:17:2907804137:
7fff2c4dce90:0000: SALNPCLOSENOTIFY: p=0x0 0/0 more buffered 
(SAL/channel-np.c:_sal_np_ioctl:1312)
Dynamic Filter: Successfully downloaded the update file from url1
Dynamic Filter: Successfully finished lua script
DBG:18:2907804722:7fff2c4dce90:0000: Fiber 0x7fff2c4dce90 finished leaving 3 more 
(FIBERS/fibers-jumpstart.c:_fiber_jumpstart:64)
DBG:19:2907804746:7fff2c4dce90:0000: Exiting fiber 0x7fff2c4dce90 
(FIBERS/fibers.c:fiber__kill:1287)
DBG:20:2907804752:7fff2c4dce90:0000: Fiber 0x7fff2c4dce90 terminated, 2 more 
(FIBERS/fibers.c:fiber__kill:1358)
Dynamic Filter: Downloaded file successfully
Channel NP p=0x0000000000000000 0/0 more bufferedchannel-np.cDynamic Filter: read 
ramfs bytes 2097152
Dynamic Filter: file MD5 verification check succeeded
Dynamic Filter: decrypt key succeeded
Dynamic Filter: decrypt file succeeded byte = 2097145
Dynamic Filter: updating engine bytes = 2097145
Dynamic Filter: meta data length = 2987
INFO: Dynamic Filter: update succeeded

Dans cette sortie, vous pouvez voir ces étapes que le mises à jour effectue lorsqu'il obtient une nouvelle base de données :

• Le responsable de mise à jour accède à l'URL http://update-manifests.ironport.com afin de déterminer quelle base de données il télécharge.
• Le serveur manifeste renvoie deux URL possibles pour le téléchargement.
• Le client de mise à jour télécharge la base de données.
• La base de données est déchiffrée et stockée en mémoire pour être utilisée par le processus de filtrage dynamique.

Les problèmes de connectivité des différents serveurs de mise à jour se manifestent en tant qu'erreurs dans ce résultat et aident à dépanner plus loin. Forcer le client de mise à jour à s'exécuter manuellement avec la commande dynamic- filter database fetch.

Étape 2 : Assurez-vous que le trafic DNS traverse cet ASA

La fonctionnalité de filtre de trafic BotNet de l'ASA est construite à partir des adresses IP qui correspondent aux domaines, de sorte que l'ASA doit être en ligne avec les requêtes et les réponses DNS qui traversent le réseau. Certaines topologies peuvent entraîner le trafic DNS à emprunter un chemin qui n'inclut pas l'ASA en question. La plupart des réseaux ont des serveurs DNS internes qui agissent en tant que redirecteurs et caches DNS pour les utilisateurs internes. Tant que ces serveurs, lorsqu'ils transmettent une demande DNS pour un domaine dont ils ne sont pas propriétaires ou ne peuvent pas répondre, transmettent la demande à un serveur qui nécessite de traverser l'ASA, aucun problème ne doit se produire. Reportez-vous à ces topologies avec et sans serveurs DNS internes :

Cet exemple de topologie montre les utilisateurs qui pointent vers un serveur DNS interne qui transfère vers un serveur DNS externe.

Cet exemple de topologie montre les utilisateurs qui pointent directement vers un serveur DNS externe. 

Dans les deux exemples de topologie, la clé d'un déploiement fonctionnel du filtre de trafic BotNet est que les demandes d'enregistrement A- DNS pour les domaines externes doivent passer par l'ASA qui exécute la fonctionnalité DNS-snoop. Dans l'exemple de serveur interne, si le serveur DNS interne emprunte un chemin réseau différent pour accéder à Internet que la machine utilisateur, et que dans le processus ne traverse pas l'ASA, la table DNS-snoop ne contient pas de mappages IP-à-domaine provoqués par les requêtes DNS de la machine utilisateur et la machine utilisateur ne peut pas être filtrée comme prévu.

Utilisez ces techniques afin de vérifier que le trafic DNS passe par l'ASA :

• Vérifiez la stratégie de service. Examinez le résultat de show service-policy afin de déterminer si l'inspection DNS est appliquée, configurée avec le mot clé dynamic-filter-snoop et voit le trafic. Le nombre de paquets associé à l'inspection DNS doit augmenter au fur et à mesure que vous faites des requêtes DNS.
• Utiliser des captures. La fonctionnalité DNS-snoop examine les paquets DNS qui traversent l'ASA, il est donc important de vérifier que les paquets atteignent l'ASA. Utilisez la fonction de capture intégrée de l'ASA afin de vous assurer que le trafic DNS entre et quitte correctement cet ASA.

Étape 3 : Vérifier le cache DNS Snoop

Les disponibilités DNS-snoop doivent être remplies avec des mappages IP-à-domaine. Une adresse IP unique peut avoir un nombre illimité de domaines associés. C'est ainsi que les entreprises qui hébergent des sites Web peuvent desservir des milliers de domaines avec seulement quelques adresses IP. Entrez la commande show dynamic-filter dns-snoop detail et voyez un vidage des données actuellement dans le cache DNS-snoop. Il s'agit d'un enregistrement de toutes les cartes IP-domaine que l'ASA obtient avec l'utilisation de la fonction DNS-snoop de l'inspection DNS. Voir cet exemple de résultat :

DNS Reverse Cache Summary Information: 3 addresses, 3 names
Next housekeeping scheduled at 22:28:01 EDT Jul 8 2014,
DNS reverse Cache Information:
[198.151.100.77] flags=0x1, type=0, unit=0 b:u:w=0:1:0, cookie=0x0
    [cisco.com] type=0, ttl=31240
[198.151.100.91] flags=0x23, type=0, unit=0 b:u:w=1:1:0, cookie=0x0
    [magnus.cisco.com] type=1, ttl=0
    [raleigh.cisco.com] type=0, ttl=0
[198.151.100.1] flags=0x2, type=0, unit=0 b:u:w=1:0:0, cookie=0x0
    [badsite.cisco.com] type=1, ttl=0

Dans cet exemple, l'ASA apprend des informations sur trois adresses IP mais quatre domaines. magnus.cisco.com et raleigh.cisco.com se résolvent tous deux en 198.151.100.91. Dans cet exemple, deux des domaines magnus.cisco.com et badsite.cisco.com sont de type 1. Cela signifie que le domaine se trouve dans la base de données en tant que domaine sur liste noire. Les autres domaines sont de type 0, ce qui indique que le domaine n'est pas mis en liste noire ou blanche et qu'il s'agit simplement d'un domaine normal.

1. Vérifiez que les requêtes DNS d'un ordinateur utilisateur traversent le pare-feu de manière régulière et sont traitées par DNS-snoop et effectuent une requête DNS. Recherchez dans le cache une entrée correspondant. Tester et utiliser un domaine qui résout mais qui est assez obscur pour qu'il n'ait pas été interrogé récemment et qu'il figure déjà dans la table. Par exemple, le domaine asa.cisco.com est choisi. L'outil de ligne de commande nslookup est utilisé pour interroger ce nom d'hôte. Reportez-vous à l’exemple suivant :
   
   

   $ nslookup asa.cisco.com
   
   Name:	asa.cisco.com
   Address: 198.151.100.64

2. Vérifiez le cache DNS-snoop. Reportez-vous à l’exemple suivant :
   
   

   DNS Reverse Cache Summary Information: 5 addresses, 7 names 
   Next housekeeping scheduled at 22:48:01 EDT Jul 8 2014, 
   DNS reverse Cache Information:
   [198.151.100.64] flags=0x11, type=0, unit=0 b:u:w=0:1:0, cookie=0x0
       [asa.cisco.com] type=0, ttl=86359

L'entrée est présente dans le cache DNS-snoop. Si l'entrée n'était pas présente avant le test nslookup, cela signifie que la fonctionnalité DNS-snoop fonctionne et que l'ASA fonctionne correctement avec les requêtes et les réponses DNS.

Si l'entrée ne s'affiche pas, assurez-vous que le trafic DNS passe par l'ASA. Vous devrez peut-être vider le cache DNS sur l'ordinateur hôte ou les serveurs DNS internes, le cas échéant, afin de vous assurer que les requêtes ne sont pas traitées à partir d'un cache. 

La fonctionnalité DNS-snoop ne prend pas en charge EDNS0. Si le client ou le serveur DNS utilise EDNS0, l'ASA peut ne pas remplir le cache DNS-snoop avec des mappages IP-à-domaine si la réponse contient des enregistrements de ressources supplémentaires. Cette limitation est suivie par l'ID de bogue Cisco CSCta36873.

Étape 4 : Tester le filtre de trafic BotNet avec le trafic

À l'étape 3, le cache DNS-snoop indique que le domaine badsite.cisco.com figure sur la liste noire. Envoyez une requête ping au domaine en question afin de tester la fonctionnalité de botnet. Lorsque vous envoyez une requête ping au domaine, il est plus sûr que si vous essayez de charger le domaine dans un navigateur Web. Ne testez pas la fonctionnalité de filtre dynamique à l'aide de votre navigateur Web, car votre machine risque d'être compromise si le navigateur charge du contenu malveillant. Utilisez le protocole ICMP (Internet Control Message Protocol), car il s'agit d'une méthode plus sûre et d'un test valide du filtre de trafic BotNet, car il bloque en fonction d'IP et de rien de spécifique à un port ou à un protocole.

Si vous ne connaissez pas un site sur liste noire, vous pouvez en trouver un facilement. Entrez la commande dynamic-filter database find <search_term> pour rechercher les domaines mis en liste noire et correspondant au terme de recherche fourni. Reportez-vous à l’exemple suivant :

ASA# dynamic-filter database find cisco verybadsite.cisco.com	
m=44098 acmevirus.cisco.com	m=44098Found more than 2 matches,
 enter a more specific string to find an exact match
 

Envoyez une requête ping à l'un des domaines renvoyés. Lorsque vous envoyez une requête ping à ce domaine, les actions suivantes se produisent :

1. L’hôte génère une requête DNS pour le domaine en question.
2. La requête DNS traverse l'ASA, soit directement à partir de la machine hôte, soit transmise par un serveur interne.
3. La réponse DNS traverse l'ASA, soit de nouveau vers la machine hôte, soit vers le serveur interne.
4. La fonction DNS-snoop remplit cette carte IP-domaine dans le cache DNS-snoop.
5. L'ASA compare le domaine à la base de données de filtre dynamique et détermine une correspondance. L'ASA bloque le trafic entrant et sortant de l'adresse IP associée au domaine malveillant.
6. La machine hôte envoie une requête d'écho ICMP que l'ASA abandonne car elle est destinée à une adresse IP associée à un domaine malveillant.

Lorsque l'ASA abandonne le trafic de test ICMP, il enregistre un journal système (syslog) similaire à cet exemple :

Jul 08 2014 23:14:17: %ASA-4-338006: Dynamic Filter dropped blacklisted 
ICMP traffic from inside:192.168.1.100/23599 (203.0.113.99/23599) to 
outside:198.151.100.72/0 (198.151.100.72/0), destination 198.151.100.72 
resolved from dynamic list: acmevirus.cisco.com, threat-level: very-high, 
category: Malware

La sortie de la commande show dynamic-filter statistics indique les connexions qui sont classées et potentiellement abandonnées. Reportez-vous à l’exemple suivant :

ASA(config)# show dynamic-filter statistics
Enabled on interface inside
 Total conns classified 163, ingress 163, egress 0
 Total whitelist classified 0, ingress 0, egress 0
 Total greylist classified 8, dropped 0, ingress 8, egress 0
 Total blacklist classified 155, dropped 154, ingress 155, egress 0
Enabled on interface outside
 Total conns classified 0, ingress 0, egress 0
 Total whitelist classified 0, ingress 0, egress 0
 Total greylist classified 0, dropped 0, ingress 0, egress 0
 Total blacklist classified 0, dropped 0, ingress 0, egress 0
Enabled on interface management
 Total conns classified 0, ingress 0, egress 0
 Total whitelist classified 0, ingress 0, egress 0
 Total greylist classified 0, dropped 0, ingress 0, egress 0
 Total blacklist classified 0, dropped 0, ingress 0, egress 0

Le compteur classifié augmente uniquement si une tentative de connexion est effectuée à une adresse IP qui est mise sur liste noire, liste blanche ou liste grise. Tout autre trafic n'entraîne pas l'augmentation du compteur classifié. Un nombre faible pour la liste classée ne signifie pas que l'ASA n'a pas évalué les nouvelles tentatives de connexion par rapport au filtre de trafic BotNet. Ce nombre faible indique à la place que peu d'adresses IP source ou de destination sont mises en liste noire, liste blanche ou liste grise. Utilisez les instructions de ce document afin de confirmer les fonctions correctement.

Si le trafic de test n'est pas abandonné, vérifiez la configuration afin de vous assurer qu'elle est configurée pour abandonner le trafic avec un niveau de menace approprié. Consultez cet exemple de configuration, qui active le filtre de trafic BotNet globalement sur l'ASA ici :

dynamic-filter updater-client enable
dynamic-filter use-database
dynamic-filter enable
dynamic-filter drop blacklist