Problema de filtrado de tráfico BotNet con dispositivo de seguridad adaptable

Introducción

Este documento describe los pasos para resolver problemas de la funcionalidad de filtrado de tráfico BotNet en Adaptive Security Appliance (ASA). Para obtener ayuda con la configuración del filtro de tráfico de BotNet, vea esta guía de configuración: Configuración del Filtro de Tráfico de BotNet.

Antecedentes

El filtro de tráfico BotNet supervisa las solicitudes y respuestas del Servidor de nombres de dominio (DNS) entre los clientes DNS internos y los servidores DNS externos. Cuando se procesa una respuesta DNS, el dominio asociado a la respuesta se compara con la base de datos de dominios maliciosos conocidos. Si hay una coincidencia, se bloquea cualquier tráfico adicional a la dirección IP presente en la respuesta DNS. Consulte este diagrama.

1. Verifique la base de datos de filtros dinámicos. El ASA descarga periódicamente una base de datos actual de direcciones IP y dominios malintencionados conocidos. Cisco Security Intelligence Operations (SIO) determina que los dominios y las direcciones IP de esta base de datos sirven al malware u otro contenido malicioso.
2. Asegúrese de que el tráfico DNS atraviese el ASA. Un usuario en la red interna o una máquina infectada en la red interna intenta acceder a un servidor malintencionado para descargar malware o participar en un BotNet. Para conectarse al servidor malintencionado, la máquina host debe realizar una búsqueda DNS. En este ejemplo, la máquina intenta acceder a badsite.cisco.com. La máquina host envía una solicitud DNS a un servidor DNS local o directamente a un servidor DNS externo. En ambas situaciones, una solicitud DNS debe atravesar el ASA y la respuesta DNS también debe atravesar el mismo ASA.
3. Verifique la memoria caché DNS-snoop. La función DNS-snoop de la inspección DNS, si está activada, monitorea el tráfico DNS y determina que se ha devuelto una respuesta de registro A de DNS desde el servidor DNS. La función DNS-snoop toma el dominio y las direcciones IP presentes en la respuesta A-Record y lo agrega a la memoria caché DNS-snoop. El dominio se comprueba con la base de datos descargada del paso 1 y se encuentra una coincidencia. La respuesta DNS no se descarta y se le permite pasar.
4. Pruebe el filtro de tráfico de BotNet con tráfico. Debido a que hubo una coincidencia en el paso 3, el ASA agrega una regla interna que indica que todo el tráfico hacia o desde la IP asociada con badsite.cisco.com se descarta. A continuación, el equipo infectado intenta acceder al servidor de la dirección URL badsite.cisco.com y se descarta el tráfico. 

Solución de problemas de flujo de trabajo

Utilice estos pasos para resolver problemas y verificar que la función funciona.

Paso 1: Comprobar la base de datos de filtros dinámicos

Verifique si la base de datos se ha descargado e ingrese el comando show dynamic-filter data. Vea este ejemplo de salida: 

# 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

 En este resultado, el ASA indica la hora de la última búsqueda exitosa de la base de datos y un ejemplo del contenido de esta base de datos. Si ejecuta el comando show dynamic-filter data y el comando muestra que no se ha descargado ninguna base de datos, solucione primero este paso. Entre los problemas comunes que impiden que ASA obtenga la base de datos de filtros dinámicos se incluyen los siguientes:

• Falta la configuración de DNS o es incorrecta en el ASA. El cliente actualizador de filtro dinámico debe resolver el nombre de host del servidor de actualización. DNS debe configurarse y funcionar en el ASA. Haga ping en dominios conocidos desde la línea de comandos y determine si ASA puede resolver nombres de host.
• No hay acceso a Internet desde el ASA. Si el ASA se encuentra en una red que no tiene acceso a Internet o un dispositivo ascendente bloquea el acceso a Internet a la dirección IP externa del ASA, la actualización falla.
• El cliente actualizador no está habilitado. El comando dynamic-filter updater-client enable se debe configurar para que el ASA pueda descargar la base de datos.

Ingrese el comando debug dynamic-filter updater-client para depurar la base de datos. Vea este ejemplo de salida del comando:

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

En este resultado, puede ver los pasos que el actualizador realiza cuando obtiene una nueva base de datos:

• El actualizador llega a la URL http://update-manifests.ironport.com para determinar qué base de datos descarga.
• El servidor de manifiestos devuelve dos URL posibles para la descarga.
• El cliente actualizador descarga la base de datos.
• La base de datos se descifra y se almacena en la memoria para que la utilice el proceso de filtrado dinámico.

Los problemas de conectividad de diferentes servidores de actualización se manifiestan como errores en este resultado y ayudan a resolver problemas adicionales. Obligar al cliente actualizador a ejecutarse manualmente con el comando dynamic- filter database fetch.

Paso 2: Asegúrese de que el tráfico DNS cruza este ASA

La funcionalidad de filtrado de tráfico de BotNet del ASA está integrada en las direcciones IP que coinciden con los dominios, por lo que el ASA debe estar en línea con las solicitudes y respuestas de DNS que atraviesan la red. Algunas topologías pueden hacer que el tráfico DNS tome una ruta que no incluye el ASA en cuestión. La mayoría de las redes tienen servidores DNS internos que actúan como reenviadores DNS y memorias caché para usuarios internos. Mientras estos servidores, cuando reenvíen una solicitud DNS para un dominio del que no son propietarios o no pueden responder, reenvíen la solicitud a un servidor que requiera atravesar el ASA, no debería producirse ningún problema. Vea estas topologías con y sin servidores DNS internos:

Esta topología de ejemplo muestra a los usuarios que apuntan a un servidor DNS interno que se reenvía a un servidor DNS externo.

Esta topología de ejemplo muestra usuarios que apuntan directamente a un servidor DNS externo. 

En ambos ejemplos de topología, la clave para una implementación funcional del filtro de tráfico BotNet es que las solicitudes de registro A de DNS para dominios externos deben pasar a través del ASA que ejecuta la función DNS-snoop. En el ejemplo de servidor interno, si el servidor DNS interno toma una trayectoria de red diferente para alcanzar Internet que el equipo del usuario y en el proceso no atraviesa el ASA, la tabla DNS-snoop no contendrá mapas de IP a dominio causados por las solicitudes DNS del equipo del usuario y es posible que el equipo del usuario no se filtre como se esperaba.

Utilice estas técnicas para verificar que el tráfico DNS pasa a través del ASA:

• Verifique la política de servicio. Observe el resultado de show service-policy para determinar si se aplica la inspección de DNS, configurada con la palabra clave dynamic-filter-snoop y ve el tráfico. El recuento de paquetes asociado con la inspección DNS debe aumentar a medida que se realizan solicitudes DNS.
• Utilice capturas. La función DNS-snoop observa los paquetes DNS que atraviesan el ASA, por lo que es importante que verifique que los paquetes alcancen el ASA. Utilice la función de captura integrada del ASA para asegurarse de que el tráfico DNS entre y salga correctamente de este ASA.

Paso 3: Verifique la memoria caché de Snoop DNS

El efectivo de DNS-snoop debe rellenarse con mapas de IP a dominio. Una única dirección IP puede tener un número ilimitado de dominios asociados a ella. Así es como las empresas que alojan sitios web pueden servir a miles de dominios con solo unas pocas direcciones IP. Ingrese el comando show dynamic-filter dns-snoop detail y vea un volcado de los datos actualmente en la memoria caché DNS-snoop. Este es un registro de todos los mapas de IP a dominio que el ASA obtiene con el uso de la función DNS-snoop de la inspección DNS. Vea este ejemplo de salida:

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

En este ejemplo, ASA aprende información sobre tres direcciones IP pero cuatro dominios. magnus.cisco.com y raleigh.cisco.com resuelven a 198.151.100.91. En este ejemplo, dos de los dominios, magnus.cisco.com y badsite.cisco.com enumeran como tipo 1. Esto significa que el dominio se encuentra en la base de datos como un dominio en la lista negra. Los otros dominios se enumeran como tipo 0, lo que indica que el dominio no está en la lista negra ni en la lista blanca y es simplemente un dominio normal.

1. Compruebe que las solicitudes DNS de un equipo de usuario atraviesan el firewall y son procesadas por DNS-snoop y realice una solicitud DNS. Verifique la memoria caché para una entrada que coincida. Pruebe y utilice un dominio que se resuelva pero que está lo suficientemente oscuro como para que no se haya consultado recientemente y que ya esté en la tabla. Por ejemplo, se elige el dominio asa.cisco.com. La herramienta de línea de comandos nslookup se utiliza para consultar ese nombre de host. Observe este ejemplo:
   
   

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

2. Verifique la memoria caché DNS-snoop. Observe este ejemplo:
   
   

   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

La entrada está presente en la memoria caché DNS-snoop. Si la entrada no estaba presente antes de la prueba nslookup, significaría que la función DNS-snoop funciona y que ASA funciona correctamente con las solicitudes y respuestas DNS.

Si la entrada no se muestra, asegúrese de que el tráfico DNS pasa a través del ASA. Es posible que deba vaciar la memoria caché DNS en la máquina host o en los servidores DNS internos, si procede, para asegurarse de que las solicitudes no se atienden desde una memoria caché. 

La función DNS-snoop no admite EDNS0. Si el cliente o servidor DNS utiliza EDNS0, es posible que el ASA no rellene la memoria caché DNS-snoop con mapas de IP a dominio si la respuesta tiene registros de recursos adicionales presentes. Esta limitación es rastreada por Cisco bug ID CSCta36873.

Paso 4: Prueba del Filtro de Tráfico de BotNet con el Tráfico

En el paso 3, la memoria caché DNS-snoop muestra que domain badsite.cisco.com está en la lista negra. Haga ping en el dominio en cuestión para probar la funcionalidad Botnet. Cuando hace ping en el dominio, es más seguro que si intenta cargar el dominio en un navegador web. No pruebe la función de filtro dinámico utilizando el explorador Web porque su equipo podría verse comprometido si el explorador carga contenido malintencionado. Utilice el protocolo de mensajes de control de Internet (ICMP) porque es un método más seguro y es una prueba válida del filtro de tráfico de BotNet a medida que se bloquea en función de la IP y nada específico del puerto o protocolo.

Si no conoce un sitio en la lista negra, puede encontrarlo fácilmente. Ingrese el comando dynamic-filter database find <search_term> para encontrar dominios que estén en la lista negra y que coincidan con el término de búsqueda proporcionado. Observe este ejemplo:

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
 

Haga ping en uno de los dominios que devuelve. Al hacer ping a este dominio, se producirán estas acciones:

1. El host genera una solicitud DNS para el dominio en cuestión.
2. La solicitud DNS atraviesa el ASA, ya sea directamente desde la máquina host o reenviada por un servidor interno.
3. La respuesta DNS atraviesa el ASA, ya sea de vuelta a la máquina host o al servidor interno.
4. La función DNS-snoop rellena este mapa de IP a dominio en la memoria caché DNS-snoop.
5. El ASA compara el dominio con la base de datos de filtro dinámico y determina una coincidencia. El ASA bloquea aún más el tráfico entrante y saliente de la IP asociada al dominio malintencionado.
6. La máquina host envía una solicitud de eco ICMP que descarta el ASA porque está destinada a una IP asociada con un dominio malintencionado.

Cuando ASA descarta el tráfico de prueba ICMP, registra un registro del sistema (syslog) similar a este ejemplo:

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

El resultado del comando show dynamic-filter statistics indica conexiones que se clasifican y potencialmente se descartan. Observe este ejemplo:

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

El contador clasificado sólo aumenta si se intenta establecer una conexión a una dirección IP que se muestra en la lista negra, en la lista blanca o en la lista gris. El resto del tráfico no hace que aumente el contador clasificado. Un número bajo para la lista clasificada no significa que el ASA no haya evaluado los nuevos intentos de conexión con el filtro de tráfico BotNet. En su lugar, este número bajo indica que pocas direcciones IP de origen o de destino están en la lista negra, en la lista blanca o en la lista gris. Utilice las instrucciones de este documento para confirmar las funciones de la función correctamente.

Si el tráfico de prueba no se descarta, verifique la configuración para asegurarse de que esté configurada para descartar el tráfico con un nivel de amenaza adecuado. Vea este ejemplo de configuración, que permite el filtrado de tráfico BotNet globalmente en el ASA aquí:

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