Solucionar problemas de manejo de rutas de datos por UTD y filtrado de URL
Contenido
Introducción
Este documento describe cómo resolver problemas de Unified Threat Defence (UTD), también conocido como Snort y Uniform Resource Locator (URL) Filtering en routers IOS® XE WAN Edge.
Antecedentes
Snort es el sistema de prevención de intrusiones (IPS) más implementado del mundo. Desde 2013, la empresa que creó una versión comercial del software Snort, Sourcefire es adquirida por Cisco. A partir del software 16.10.1 IOS® XE SD-WAN, se han agregado contenedores UTD/URF-Filtering a la solución Cisco SD-WAN.
El contenedor se registra en el router IOS®XE mediante el marco app-nav. La explicación de ese proceso está fuera del alcance de este documento.
Vista de alto nivel de Datapath
En un nivel superior, la ruta de datos tiene el siguiente aspecto:
De la LAN/WAN al contenedor
El tráfico proviene del lado de la LAN. Dado que IOS® XE sabe que el contenedor está en un estado saludable, desvía el tráfico al contenedor UTD. La desviación utiliza la interfaz VirtualPortGroup1 como interfaz de salida, que encapsula el paquete dentro de un túnel de encapsulación de enrutamiento genérico (GRE).
El router realiza la acción "PUNT" utilizando cause :64 (Service Engine packet)" y envía el tráfico hacia el procesador de ruta (RP). Se agrega un encabezado de punt y el paquete se envía al contenedor mediante una interfaz de salida interna hacia el contenedor "[internal0/0/svc_eng:0]"
En esta etapa, Snort aprovecha sus preprocesadores y conjuntos de reglas. El paquete se puede descartar o reenviar en función de los resultados del procesamiento.
Del contenedor a LAN/WAN
Suponiendo que no se suponga que se descarta el tráfico, el paquete se reenvía de vuelta al router después del procesamiento UTD. Aparece en el procesador de flujo cuántico (QFP) como proveniente del túnel 6000001. A continuación, el router lo procesa y se debe enrutar (con suerte) hacia la interfaz WAN.
El contenedor controla el resultado de la desviación en la inspección UTD en la ruta de datos IOS® XE.
Por ejemplo, con el flujo HTTPS, los preprocesadores están interesados en ver los paquetes Hello del servidor / Hello del cliente con la negociación TLS. Posteriormente, el flujo no se redirige, ya que la inspección del tráfico cifrado de TLS tiene poco valor.
Perspectiva en profundidad de Datapath
Desde el punto de vista del rastreador de paquetes, se verán esos conjuntos de acciones (192.168.16.254 es un cliente web):
debug platform condition ipv4 192.168.16.254/32 both debug platform condition start debug platform packet-trace packet 256 fia-trace data-size 3000
Paquete de entrada desde el lado LAN o WAN hacia el contenedor
En este escenario en particular, el paquete rastreado proviene de la LAN. Desde el punto de vista de la redirección, existen diferencias importantes si el flujo proviene de LAN o WAN.
El cliente intenta acceder a www.cisco.com en HTTPS
cedge6#show platform packet-trace packet 14
Packet: 14 CBUG ID: 3849209
Summary
Input : GigabitEthernet2
Output : internal0/0/svc_eng:0
State : PUNT 64 (Service Engine packet)
Timestamp
Start : 1196238208743284 ns (05/08/2019 10:50:36.836575 UTC)
Stop : 1196238208842625 ns (05/08/2019 10:50:36.836675 UTC)
Path Trace
Feature: IPV4(Input)
Input : GigabitEthernet2
Output : <unknown>
Source : 192.168.16.254
Destination : 203.0.113.67
Protocol : 6 (TCP)
SrcPort : 35568
DstPort : 443
Feature: DEBUG_COND_INPUT_PKT
Entry : Input - 0x8177c67c
Input : GigabitEthernet2
Output : <unknown>
Lapsed time : 2933 ns
<snip>
El tráfico que coincide con la condición se rastrea en el ingreso en la interfaz GigabitEthernet2.
Feature: UTD Policy (First FIA)
Action : Divert
Input interface : GigabitEthernet2
Egress interface: GigabitEthernet3
Feature: OUTPUT_UTD_FIRST_INSPECT
Entry : Output - 0x817cc5b8
Input : GigabitEthernet2
Output : GigabitEthernet3
Lapsed time : 136260 ns
Feature: UTD Inspection
Action : Divert <<<<<<<<<<<<<<<<<<<<<<<<<<<<
Input interface : GigabitEthernet2
Egress interface: GigabitEthernet3
Feature: OUTPUT_UTD_FINAL_INSPECT
Entry : Output - 0x817cc5e8
Input : GigabitEthernet2
Output : GigabitEthernet3
Lapsed time : 43546 ns
<snip>
En la matriz de invocación de funciones de salida (FIA) de la interfaz de salida, UTD FIA decidió desviar este paquete al contenedor.
Feature: IPV4_OUTPUT_LOOKUP_PROCESS_EXT
Entry : Output - 0x81781bb4
Input : GigabitEthernet2
Output : Tunnel6000001
<removed>
Feature: IPV4_OUTPUT_LOOKUP_PROCESS_EXT
Entry : Output - 0x81781bb4
Input : GigabitEthernet2
Output : Tunnel6000001
<removed>
Feature: IPV4_INPUT_LOOKUP_PROCESS_EXT
Entry : Output - 0x8177c698
Input : Tunnel6000001
Output : VirtualPortGroup1
Lapsed time : 880 ns
<snip>
El paquete se coloca en el túnel predeterminado Tunnel600001 y se rutea a través de la interfaz VPG1. En esta etapa, el paquete original está encapsulado GRE.
Feature: OUTPUT_SERVICE_ENGINE
Entry : Output - 0x817c6b10
Input : Tunnel6000001
Output : internal0/0/svc_eng:0
Lapsed time : 15086 ns
<removed>
Feature: INTERNAL_TRANSMIT_PKT_EXT
Entry : Output - 0x8177c718
Input : Tunnel6000001
Output : internal0/0/svc_eng:0
Lapsed time : 43986 ns
El paquete se transmite internamente al contenedor.
Yendo más profundo en el router mismo, el tráfico llega a un VRF interno en la interfaz eth2 del procesador de ruta:
[cedge6:/]$ chvrf utd ifconfig
eth0 Link encap:Ethernet HWaddr 54:0e:00:0b:0c:02
inet6 addr: fe80::560e:ff:fe0b:c02/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1375101 errors:0 dropped:0 overruns:0 frame:0
TX packets:1366614 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:96520127 (92.0 MiB) TX bytes:96510792 (92.0 MiB)
eth1 Link encap:Ethernet HWaddr 00:1e:e6:61:6d:ba
inet addr:192.168.1.2 Bcast:192.168.1.3 Mask:255.255.255.252
inet6 addr: fe80::21e:e6ff:fe61:6dba/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:2000 Metric:1
RX packets:1069 errors:0 dropped:0 overruns:0 frame:0
TX packets:2001 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:235093 (229.5 KiB) TX bytes:193413 (188.8 KiB)
eth2 Link encap:Ethernet HWaddr 00:1e:e6:61:6d:b9
inet addr:192.0.2.2 Bcast:192.0.2.3 Mask:255.255.255.252
inet6 addr: fe80::21e:e6ff:fe61:6db9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:2000 Metric:1
RX packets:2564233 errors:0 dropped:0 overruns:0 frame:0
TX packets:2564203 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:210051658 (200.3 MiB) TX bytes:301467970 (287.5 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Eth0 es una interfaz de comunicación entre procesos de transporte (TIPC) conectada al proceso IOSd. El canal OneP se ejecuta sobre él para pasar configuraciones y notificaciones de ida y vuelta entre el IOSd y el contenedor UTD.
Por lo que le preocupa, "eth2 [ container interface]" se conecta en puente a "VPG1 [ 192.0.2.1/192.168.2.2 ]", que son las direcciones que vManage envía al IOS-XE y al contenedor.
Si ejecuta tcpdump, puede ver el tráfico encapsulado GRE que va al contenedor. La encapsulación GRE incluye un encabezado VPATH.
[cedge6:/]$ chvrf utd tcpdump -nNvvvXi eth2 not udp
tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
06:46:56.350725 IP (tos 0x0, ttl 255, id 35903, offset 0, flags [none], proto GRE (47), length 121)
192.0.2.1 > 192.0.2.2: GREv0, Flags [none], length 101
gre-proto-0x8921
0x0000: 4500 0079 8c3f 0000 ff2f ab12 c000 0201 E..y.?.../......
0x0010: c000 0202 0000 8921 4089 2102 0000 0000 .......!@.!.....
0x0020: 0000 0000 0300 0001 0000 0000 0000 0000 ................
0x0030: 0004 0800 e103 0004 0008 0000 0001 0000 ................
0x0040: 4500 0039 2542 4000 4011 ce40 c0a8 10fe E..9%B@.@..@....
0x0050: ad26 c864 8781 0035 0025 fe81 cfa8 0100 .&.d...5.%......
0x0060: 0001 0000 0000 0000 0377 7777 0363 6e6e .........www.cnn
0x0070: 0363 6f6d 0000 0100 01 .com.....
Paquete de entrada desde el contenedor hacia el lado LAN o WAN
Después del procesamiento de Snort (suponiendo que el tráfico no se descarte), se vuelve a inyectar en la ruta de reenvío QFP.
cedge6#show platform packet-trace packet 15 Packet: 15 CBUG ID: 3849210 Summary Input : Tunnel6000001 Output : GigabitEthernet3 State : FWD
Tunnel600001 es la interfaz de salida del contenedor.
Feature: OUTPUT_UTD_FIRST_INSPECT_EXT
Entry : Output - 0x817cc5b8
Input : GigabitEthernet2
Output : GigabitEthernet3
Lapsed time : 2680 ns
Feature: UTD Inspection
Action : Reinject
Input interface : GigabitEthernet2
Egress interface: GigabitEthernet3
Feature: OUTPUT_UTD_FINAL_INSPECT_EXT
Entry : Output - 0x817cc5e8
Input : GigabitEthernet2
Output : GigabitEthernet3
Lapsed time : 12933 ns
Dado que el tráfico ya ha sido inspeccionado, el router sabe que se trata de una reinyección.
Feature: NAT
Direction : IN to OUT
Action : Translate Source
Steps :
Match id : 1
Old Address : 192.168.16.254 35568
New Address : 172.16.16.254 05062
El tráfico se NATed y sale hacia Internet.
Feature: MARMOT_SPA_D_TRANSMIT_PKT
Entry : Output - 0x8177c838
Input : GigabitEthernet2
Output : GigabitEthernet3
Lapsed time : 91733 ns
Integración de registro de flujo UTD con seguimiento de paquetes
IOS-XE 17.5.1 agregó la integración de registro de flujo UTD con packet-trace, donde la salida de path-trace incluirá un veredicto UTD. El veredicto puede ser uno de los siguientes, por ejemplo:
- el paquete que UTD decide bloquear/alertar para Snort
- permitir/descartar para URLF
- bloquear/permitir AMP
Para los paquetes que no tienen la información de veredicto de UTD, no se registra ninguna información de registro de flujo. Tenga en cuenta también que no se registra el veredicto de aprobación/autorización de IPS/IDS debido a un posible impacto negativo en el rendimiento.
Para habilitar la integración de registro de flujo, utilice la plantilla de complemento CLI con:
utd engine standard multi-tenancy
utd global
flow-logging all
Ejemplo de salida para diferentes veredictos:
Límite de tiempo de búsqueda de URL:
show platform packet-trace pack all | sec Packet: | Feature: UTD Inspection
Packet: 31 CBUG ID: 12640
Feature: UTD Inspection
Action : Reinject
Input interface : GigabitEthernet2
Egress interface : GigabitEthernet3
Flow-Logging Information :
URLF Policy ID : 1
URLF Action : Allow(1)
URLF Reason : URL Lookup Timeout(8)
Reputación y veredicto de URLF Permitir:
Packet: 21 CBUG ID: 13859
Feature: UTD Inspection
Action : Reinject
Input interface : GigabitEthernet3
Egress interface : GigabitEthernet2
Flow-Logging Information :
URLF Policy ID : 1
URLF Action : Allow(1)
URLF Reason : No Policy Match(4)
URLF Category : News and Media(63)
URLF Reputation : 81
Bloque de veredicto y reputación de URLF:
Packet: 26 CBUG ID: 15107
Feature: UTD Inspection
Action : Reinject
Input interface : GigabitEthernet3
Egress interface : GigabitEthernet2
Flow-Logging Information :
URLF Policy ID : 1
URLF Action : Block(2)
URLF Reason : Category/Reputation(3)
URLF Category : Social Network(14)
URLF Reputation : 81
Requisito previo:
Comprobando si la versión de UTD es compatible con IOS XE
cedge7#sh utd eng sta ver
UTD Virtual-service Name: utd
IOS-XE Recommended UTD Version: 1.10.33_SV2.9.16.1_XEmain
IOS-XE Supported UTD Regex: ^1\.10\.([0-9]+)_SV(.*)_XEmain$
UTD Installed Version: 1.0.2_SV2.9.16.1_XE17.5 (UNSUPPORTED)
Si se muestra "UNSUPPORTED" (NO ADMITIDO), se requiere la actualización del contenedor como primer paso antes de iniciar la resolución de problemas.
Compruebe si hay una configuración válida del servidor de nombres en el contenedor
Algunos de los servicios de seguridad, como AMP y URLF, requerirán que el contenedor UTD pueda resolver los nombres de los proveedores de servicios en la nube, por lo que el contenedor UTD debe tener configuraciones de servidor de nombres válidas. Esto se puede verificar comprobando el archivo resolv.conf para el contenedor en el shell del sistema:
cedge:/harddisk/virtual-instance/utd/rootfs/etc]$ more resolv.conf
nameserver 208.67.222.222
nameserver 208.67.220.220
nameserver 8.8.8.8
Problema 1
Por diseño, Unified Thread Defence se debe configurar junto con el caso práctico de acceso directo a Internet (DIA). El contenedor intentará resolver api.bcti.brightcloud.com para consultar las categorías y las reputaciones de URL. En este ejemplo, ninguna de las URL inspeccionadas se bloquea incluso si se aplica la configuración adecuada
Troubleshoot
Observe siempre el archivo de registro del contenedor.
cedge6#app-hosting move appid utd log to bootflash:
Successfully moved tracelog to bootflash:
iox_utd_R0-0_R0-0.18629_0.20190501005829.bin.gz
Que copia el archivo de registro en la propia flash.
La visualización del registro se puede lograr con el comando:
cedge6# more /compressed iox_utd_R0-0_R0-0.18629_0.20190501005829.bin.gz
La visualización del registro muestra:
2019-04-29 16:12:12 ERROR: Cannot resolve host api.bcti.brightcloud.com: Temporary failure in name resolution
2019-04-29 16:17:52 ERROR: Cannot resolve host api.bcti.brightcloud.com: Temporary failure in name resolution
2019-04-29 16:23:32 ERROR: Cannot resolve host api.bcti.brightcloud.com: Temporary failure in name resolution
2019-04-29 16:29:12 ERROR: Cannot resolve host api.bcti.brightcloud.com: Temporary failure in name resolution
2019-04-29 16:34:52 ERROR: Cannot resolve host api.bcti.brightcloud.com: Temporary failure in name resolution
2019-04-29 16:40:27 ERROR: Cannot resolve host api.bcti.brightcloud.com: Temporary failure in name resolution
De forma predeterminada, vManage aprovisiona un contenedor que utiliza el servidor OpenDNS [208.67.222.222 y 208.67.220.220]
Causa raíz
El tráfico del Sistema de nombres de dominio (DNS) para resolver api.bcti.brightcloud.com se descarta en algún lugar de la ruta entre el contenedor y los servidores DNS de sombrilla. Asegúrese siempre de que ambos DNS sean accesibles.
Problema 2
En una situación en la que se supone que los sitios web de las categorías Computer e Internet Info están bloqueados, la solicitud http a www.cisco.com se descarta correctamente mientras que las solicitudes HTTPS no lo están.
Troubleshoot
Como se explicó anteriormente, el tráfico se dirige al contenedor. Cuando este flujo se encapsula en el encabezado GRE, el software agrega también un encabezado VPATH. Aprovechando este encabezado, el sistema permite pasar una condición de depuración al contenedor en sí. Esto significa que los contenedores UTD están bien mantenidos.
En este escenario, la dirección IP del cliente es 192.168,16.254. Vamos a resolver el problema de manejo de snort por el contenedor mismo para el tráfico que viene de mi cliente.
debug platform condition ipv4 192.168.16.254/32 both
debug platform condition feature utd controlplane submode serviceplane-web-filtering level verbose
debug platform condition start
Este conjunto de comandos indica a IOS-XE que marque el tráfico desde o hacia 192.168.16.254. Esto permite que el indicador debug-me sea pasado al contenedor a través del encabezado VPATH
Snort depura solamente ese flujo específico mientras que otros se procesan normalmente.
En esta etapa, puede solicitar al usuario que active el tráfico del cliente hacia www.cisco.com.
El siguiente paso sería recuperar los registros:
app-hosting move appid utd log to bootflash:
En el caso del tráfico HTTP, el preprocesador snort HTTP detecta la URL en la solicitud get.
2019-04-26 13:04:27.773:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 39540, p->dst_port = 80
2019-04-26 13:04:27.793:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 80, p->dst_port = 39540
2019-04-26 13:04:27.794:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 39540, p->dst_port = 80
2019-04-26 13:04:27.794:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 39540, p->dst_port = 80
2019-04-26 13:04:27.794:(#1):SPP-URL-FILTERING got utmdata_p
2019-04-26 13:04:27.794:(#1):SPP-URL-FILTERING HTTP Callback, direction = 00000080
2019-04-26 13:04:27.795:(#1):SPP-URL-FILTERING White list regex match not enabled
2019-04-26 13:04:27.795:(#1):SPP-URL-FILTERING Black list regex match not enabled
2019-04-26 13:04:27.795:(#1):SPP-URL-FILTERING URL database Request: url_len = 12, msg overhead 12 url: www.cisco.com/ <<<<<<<
2019-04-26 13:04:27.795:(#1):SPP-URL-FILTERING Send to URL database: req_id=0x10480047
2019-04-26 13:04:27.795:(#1):SPP-URL-FILTERING Sent to URL database 24 bytes
2019-04-26 13:04:27.795:(#1):SPP-URL-FILTERING Send to URL database done, idx: 71, URL: www.cisco.com/
2019-04-26 13:04:27.795:(#1):SPP-URL-FILTERING Received from URL database 24 bytes
2019-04-26 13:04:27.816:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 80, p->dst_port = 39540
2019-04-26 13:04:27.816:(#1):SPP-URL-FILTERING Found UTMData at 0x007f8d9ee80878, action = 0000000a
2019-04-26 13:04:27.816:(#1):SPP-URL-FILTERING Utm_verdictProcess: vrf_id 1, category 0x63, score 81 <<<<<<<<<<<<<<<<<<<<<<<<<
2019-04-26 13:04:27.816:(#1):SPP-URL-FILTERING Category 0x3f <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2019-04-26 13:04:27.816:(#1):SPP-URL-FILTERING index = 63, action = 1 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2019-04-26 13:04:27.816:(#1):SPP-URL-FILTERING Blocking category = 0x3f <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
En el caso del tráfico https, el preprocesador HTTPS ha extraído el DNS de destino del saludo del servidor
2019-05-01 00:56:18.870:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 35322, p->dst_port = 443
2019-05-01 00:56:18.886:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 443, p->dst_port = 35322
2019-05-01 00:56:18.887:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 35322, p->dst_port = 443
2019-05-01 00:56:18.887:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 35322, p->dst_port = 443
2019-05-01 00:56:18.903:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 443, p->dst_port = 35322
2019-05-01 00:56:18.906:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 443, p->dst_port = 35322
2019-05-01 00:56:18.906:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 35322, p->dst_port = 443
2019-05-01 00:56:18.907:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 443, p->dst_port = 35322
2019-05-01 00:56:18.907:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 443, p->dst_port = 35322
2019-05-01 00:56:18.907:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 443, p->dst_port = 35322
2019-05-01 00:56:18.908:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 443, p->dst_port = 35322
2019-05-01 00:56:18.908:(#1):SPP-URL-FILTERING utm_sslLookupCallback
2019-05-01 00:56:18.908:(#1):SPP-URL-FILTERING got utmdata_p
2019-05-01 00:56:18.909:(#1):SPP-URL-FILTERING White list regex match not enabled
2019-05-01 00:56:18.909:(#1):SPP-URL-FILTERING Black list regex match not enabled
2019-05-01 00:56:18.909:(#1):SPP-URL-FILTERING URL database Request: url_len = 11, msg overhead 12 url: www.cisco.com <<<<<<<<
2019-05-01 00:56:18.909:(#1):SPP-URL-FILTERING Send to URL database: req_id=0x10130012
2019-05-01 00:56:18.909:(#1):SPP-URL-FILTERING Sent to URL database 23 bytes
2019-05-01 00:56:18.909:(#1):SPP-URL-FILTERING Send to URL database done, idx: 18, URL: www.cisco.com
2019-05-01 00:56:18.909:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 443, p->dst_port = 35322
2019-05-01 00:56:18.910:(#1):SPP-URL-FILTERING Found UTMData at 0x007f1d9c479640, action = 00000008
2019-05-01 00:56:18.910:(#1):SPP-URL-FILTERING Verdict very late, in queryig state 2, idx=18
2019-05-01 00:56:18.910:(#1):SPP-URL-FILTERING UTM preprocessor p->src_port = 443, p->dst_port = 35322
2019-05-01 00:56:18.910:(#1):SPP-URL-FILTERING Found UTMData at 0x007f1d9c479640, action = 00000009
2019-05-01 00:56:18.910:(#1):SPP-URL-FILTERING Verdict very late, in queryig state 2, idx=18 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2019-05-01 00:56:18.909:(#1):SPP-URL-FILTERING Received from URL database 24 bytes
Aquí no se ve que se active la página de bloqueo ya que el software no informa los resultados de la consulta de webroot.
Causa raíz
CSCvo77664 
"El filtrado de URL de UTD para la búsqueda de categorías está fallando con el fallo de la búsqueda de webroot" se trata de que el tráfico se está filtrando cuando el software no tiene respuesta a nuestra solicitud de veredicto de URL todavía.
Problema 3
En este escenario, de forma intermitente, se descartan las sesiones de navegación web que debería permitir el filtrado de URL [ debido a su clasificación]. Por ejemplo, el acceso a www.google.com no es posible aleatoriamente, incluso si se permite la categoría "motor de búsqueda web".
Troubleshoot
Paso 1: Recopilar estadísticas generales
cedge7#show utd engine standard statistics internal
*************Engine #1*************
<removed>
===============================================================================
HTTP Inspect - encodings (Note: stream-reassembled packets included): <<<<<<<<<< generic layer7 HTTP statistics
POST methods: 0
GET methods: 7
HTTP Request Headers extracted: 7
HTTP Request Cookies extracted: 0
Post parameters extracted: 0
HTTP response Headers extracted: 6
HTTP Response Cookies extracted: 0
Unicode: 0
Double unicode: 0
Non-ASCII representable: 0
Directory traversals: 0
Extra slashes ("//"): 0
Self-referencing paths ("./"): 0
HTTP Response Gzip packets extracted: 0
Gzip Compressed Data Processed: n/a
Gzip Decompressed Data Processed: n/a
Http/2 Rebuilt Packets: 0
Total packets processed: 13
<removed>
===============================================================================
SSL Preprocessor: <<<<<<<<<< generic layer7 SSL statistics
SSL packets decoded: 38
Client Hello: 8
Server Hello: 8
Certificate: 2
Server Done: 6
Client Key Exchange: 2
Server Key Exchange: 2
Change Cipher: 10
Finished: 0
Client Application: 2
Server Application: 11
Alert: 0
Unrecognized records: 11
Completed handshakes: 0
Bad handshakes: 0
Sessions ignored: 4
Detection disabled: 1
<removed>
UTM Preprocessor Statistics < URL filtering statistics including
---------------------------
URL Filter Requests Sent: 11
URL Filter Response Received: 5
Blacklist Hit Count: 0
Whitelist Hit Count: 0
Reputation Lookup Count: 5
Reputation Action Block: 0
Reputation Action Pass: 5
Reputation Action Default Pass: 0
Reputation Action Default Block: 0
Reputation Score None: 0
Reputation Score Out of Range: 0
Category Lookup Count: 5
Category Action Block: 0
Category Action Pass: 5
Category Action Default Pass: 0
Category None: 0
UTM Preprocessor Internal Statistics
------------------------------------
Total Packets Received: 193
SSL Packet Count: 4
Action Drop Flow: 0
Action Reset Session: 0
Action Block: 0
Action Pass: 85
Action Offload Session: 0
Invalid Action: 0
No UTM Tenant Persona: 0
No UTM Tenant Config: 0
URL Lookup Response Late: 4 <<<<< Explanation below
URL Lookup Response Very Late: 64 <<<<< Explanation below
URL Lookup Response Extremely Late: 2 <<<<< Explanation below
Response Does Not Match Session: 2 <<<<< Explanation below
No Response When Freeing Session: 1
First Packet Not From Initiator: 0
Fail Open Count: 0
Fail Close Count : 0
UTM Preprocessor Internal Global Statistics
-------------------------------------------
Domain Filter Whitelist Count: 0
utmdata Used Count: 11
utmdata Free Count: 11
utmdata Unavailable: 0
URL Filter Response Error: 0
No UTM Tenant Map: 0
No URL Filter Configuration : 0
Packet NULL Error : 0
URL Database Internal Statistics
--------------------------------
URL Database Not Ready: 0
Query Successful: 11
Query Successful from Cloud: 6 <<< 11 queries were succesful but 6 only are queried via brightcloud. 5 (11-6) queries are cached
Query Returned No Data: 0 <<<<<< errors
Query Bad Argument: 0 <<<<<< errors
Query Network Error: 0 <<<<<< errors
URL Database UTM disconnected: 0
URL Database request failed: 0
URL Database reconnect failed: 0
URL Database request blocked: 0
URL Database control msg response: 0
URL Database Error Response: 0
===============================================================================
Files processed: none
===============================================================================
- "solicitud tardía": representa el HTTP GET o el certificado de cliente/servidor HTTPS [ donde SNI / DN se pueden extraer para la búsqueda. Las solicitudes tardías se reenvían.
- "solicitudes muy tardías": significa que se descarta algún tipo de contador de pérdida de sesión en el que se descartan más paquetes en el flujo hasta que el router recibe un veredicto de URL de Brightcloud. En otras palabras, cualquier cosa después de la HTTP GET inicial o el resto del flujo SSL se descartará hasta que se reciba un veredicto.
- "solicitudes extremadamente tardías": cuando la consulta de sesión a Brightcloud se ha restablecido sin proporcionar un veredicto. La sesión expirará después de 60 segundos para la versión < 17.2.1. A partir de la versión 17.2.1, la sesión de consultas a Brightcloud se agotará en el tiempo de espera después de 2 segundos. [ vía CSCvr98723 UTD: solicitudes de URL con tiempo de espera después de dos segundos]
En este escenario, vemos contadores globales que resaltan una situación poco saludable.
Paso 2: Examinar el archivo de registro de la aplicación
El software Unified Thread Detection va a registrar los eventos en el archivo de registro de la aplicación.
cedge6#app-hosting move appid utd log to bootflash:
Successfully moved tracelog to bootflash:
iox_utd_R0-0_R0-0.18629_0.20190501005829.bin.gz
Extrae el archivo de registro de la aplicación contenedora y lo guarda en la propia memoria flash.
La visualización del registro se puede lograr con el comando:
cedge6# more /compressed iox_utd_R0-0_R0-0.18629_0.20190501005829.bin.gz La visualización del registro muestra:
.....
2020-04-14 17:47:57.504:(#1):SPP-URL-FILTERING txn_id miss match verdict txn_id 245 , utmdata txn_id 0
2020-04-14 17:47:57.504:(#1):SPP-URL-FILTERING txn_id miss match verdict txn_id 248 , utmdata txn_id 0
2020-04-14 17:47:57.504:(#1):SPP-URL-FILTERING txn_id miss match verdict txn_id 249 , utmdata txn_id 0
2020-04-14 17:47:57.504:(#1):SPP-URL-FILTERING txn_id miss match verdict txn_id 250 , utmdata txn_id 0
2020-04-14 17:47:57.660:(#1):SPP-URL-FILTERING txn_id miss match verdict txn_id 251 , utmdata txn_id 0
2020-04-14 17:47:57.660:(#1):SPP-URL-FILTERING txn_id miss match verdict txn_id 254 , utmdata txn_id 0
2020-04-14 17:47:57.660:(#1):SPP-URL-FILTERING txn_id miss match verdict txn_id 255 , utmdata txn_id 0
2020-04-14 17:48:05.725:(#1):SPP-URL-FILTERING txn_id miss match verdict txn_id 192 , utmdata txn_id 0
2020-04-14 17:48:37.629:(#1):SPP-URL-FILTERING txn_id miss match verdict txn_id 208 , utmdata txn_id 0
2020-04-14 17:49:55.421:(#1):SPP-URL-FILTERING txn_id miss match verdict txn_id 211 , utmdata txn_id 0
2020-04-14 17:51:40 ERROR: Cannot send to host api.bcti.brightcloud.com: Connection timed out
2020-04-14 17:52:21 ERROR: Cannot send to host api.bcti.brightcloud.com: Connection timed out
2020-04-14 17:52:21 ERROR: Cannot send to host api.bcti.brightcloud.com: Connection timed out
2020-04-14 17:53:56 ERROR: Cannot send to host api.bcti.brightcloud.com: Connection timed out
2020-04-14 17:54:28 ERROR: Cannot send to host api.bcti.brightcloud.com: Connection timed out
2020-04-14 17:54:29 ERROR: Cannot send to host api.bcti.brightcloud.com: Connection timed out
2020-04-14 17:54:37 ERROR: Cannot send to host api.bcti.brightcloud.com: Connection timed out
....
- "ERROR: no se puede enviar al host api.bcti.brightcloud.com": indica que la sesión de consulta a Brightcloud ha agotado el tiempo de espera [ 60 segundos < 17.2.1 / 2 segundos >= 17.2.1 ]. Este es el signo de una mala conectividad con Brightcloud.
Para demostrar el problema, el uso de EPC [ Embedded Packet Capture] permitiría visualizar el problema de conectividad.
- "SPP-URL-FILTERING txn_id miss match verdict" - Esta condición de error requiere una explicación un poco más detallada. La consulta de Brightcloud se realiza a través de un POST donde el router genera un ID de consulta
Problema 4
En esta situación, IPS es la única función de seguridad habilitada en UTD y el cliente experimenta problemas con la comunicación de la impresora, que es una aplicación TCP.
Troubleshoot
Para resolver este problema de trayectoria de datos, primero tome la captura de paquetes del host TCP que tiene el problema. La captura muestra un intercambio de señales TCP de 3 vías exitoso, pero los paquetes de datos subsiguientes con datos TCP parecen haber sido descartados por el router cEdge. A continuación, active packet-trace, que muestra lo siguiente:
edge#show platform packet-trace summ
Pkt Input Output State Reason
0 Gi0/0/1 internal0/0/svc_eng:0 PUNT 64 (Service Engine packet)
1 Tu2000000001 Gi0/0/2 FWD
2 Gi0/0/2 internal0/0/svc_eng:0 PUNT 64 (Service Engine packet)
3 Tu2000000001 Gi0/0/1 FWD
4 Gi0/0/1 internal0/0/svc_eng:0 PUNT 64 (Service Engine packet)
5 Tu2000000001 Gi0/0/2 FWD
6 Gi0/0/1 internal0/0/svc_eng:0 PUNT 64 (Service Engine packet)
7 Tu2000000001 Gi0/0/2 FWD
8 Gi0/0/2 internal0/0/svc_eng:0 PUNT 64 (Service Engine packet)
9 Gi0/0/2 internal0/0/svc_eng:0 PUNT 64 (Service Engine packet)
El resultado anterior indica que los paquetes número 8 y 9 se han desviado al motor UTD, pero no se volvieron a insertar en la ruta de reenvío. La comprobación de los eventos de registro del motor UTD tampoco revela ninguna pérdida de firma de Snort. A continuación, verifique las estadísticas internas de UTD, que revelan algunas caídas de paquetes debido al normalizador TCP:
edge#show utd engine standard statistics internal
<snip>
Normalizer drops:
OUTSIDE_PAWS: 0
AHEAD_PAWS: 0
NO_TIMESTAMP: 4
BAD_RST: 0
REPEAT_SYN: 0
WIN_TOO_BIG: 0
WIN_SHUT: 0
BAD_ACK: 0
DATA_CLOSE: 0
DATA_NO_FLAGS: 0
FIN_BEYOND: 0
Causa raíz
La causa raíz del problema se debe a un comportamiento incorrecto de la pila TCP en las impresoras. Cuando la opción Timestamp se negocia durante el intercambio de señales TCP de 3 vías, RFC7323 establece que TCP DEBE enviar la opción TSopt en cada paquete que no sea <RST>. Un examen más detallado de la captura de paquetes mostrará que los paquetes de datos TCP que se descartan no tienen estas opciones habilitadas. Con la implementación de IOS-XE UTD, el normalizador de Snort TCP con la opción de bloqueo se habilita independientemente de IPS o IDS.
Referencias
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
2.0 |
23-Feb-2022 |
integración agregada de registro de flujo con packet-trace y cambios en el archivo de registro utd btrace |
1.0 |
10-Jan-2020 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)