Risoluzione dei problemi relativi alla gestione dei percorsi di dati tramite UTD e filtro URL
Sommario
Introduzione
In questo documento viene descritto come risolvere i problemi relativi a Unified Threat Defense (UTD), noto anche come filtro Snort e Uniform Resource Locator (URL) sui router IOS® XE WAN Edge.
Premesse
Snort è il sistema di prevenzione delle intrusioni (IPS) più diffuso al mondo. Dal 2013, la società che ha creato una versione commerciale del software Snort, Sourcefire è acquisita da Cisco. A partire dal software 16.10.1 IOS® XE SD-WAN, sono stati aggiunti contenitori di filtro UTD/URF alla soluzione Cisco SD-WAN.
Il contenitore si registra sul router IOS® XE utilizzando il framework app-nav. La spiegazione di questo processo esula dall'ambito del presente documento.
Vista di alto livello di Datapath
Ad alto livello, il percorso dati è simile al seguente:
Dalla LAN/WAN al contenitore
Il traffico proviene dalla LAN. Poiché IOS® XE sa che il contenitore è in uno stato integro, devia il traffico verso il contenitore UTD. La deviazione utilizza l'interfaccia VirtualPortGroup1 come interfaccia in uscita, che incapsula il pacchetto all'interno di un tunnel GRE (Generic Routing Encapsulation).
Il router esegue l'azione "PUNT" sulla causa :64 (pacchetto del motore di servizio) e invia il traffico al processore di routing (RP). Viene aggiunta un'intestazione punt e il pacchetto viene inviato al contenitore utilizzando un'interfaccia di uscita interna verso il contenitore "[internal0/0/svc_eng:0]"
In questa fase, Snort sfrutta i preprocessori e i set di regole. In base ai risultati dell'elaborazione, il pacchetto può essere eliminato o inoltrato.
Dal contenitore alla rete LAN/WAN
Supponendo che il traffico non debba essere scartato, il pacchetto viene inoltrato nuovamente al router dopo l'elaborazione UTD. Appare sul Quantum Flow Processor (QFP) come proveniente dal Tunnel6000001. Quindi, viene elaborato dal router e deve essere (si spera) indirizzato verso l'interfaccia WAN.
Il contenitore controlla il risultato della diversione nell'ispezione UTD nel percorso dati IOS® XE.
Ad esempio, con il flusso HTTPS, i preprocessori sono interessati a vedere i pacchetti Hello / Hello del server con negoziazione TLS. In seguito, il flusso non viene reindirizzato perché il valore nell'ispezione del traffico crittografato TLS è ridotto.
Datapath Deep Dive
Dal punto di vista del tracer dei pacchetti, queste azioni devono essere verificate (192.168.16.254 è un client 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
Pacchetto in entrata dal lato LAN o WAN verso il contenitore
In questo scenario particolare, il pacchetto tracciato proviene dalla LAN. Dal punto di vista del reindirizzamento, se il flusso proviene da una rete LAN o WAN, esistono differenze rilevanti.
Il client tenta di accedere a www.cisco.com su 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>
Il traffico che soddisfa la condizione viene tracciato in entrata sull'interfaccia Gigabit Ethernet2.
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>
Sul Feature Invocation Array (FIA) in uscita dell'interfaccia in uscita, la FIA UTD ha deciso di deviare questo pacchetto al contenitore.
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>
Il pacchetto viene posizionato sul tunnel predefinito Tunnel600001 e viene instradato sull'interfaccia VPG1. In questa fase, il pacchetto originale è incapsulato dal 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
Il pacchetto viene trasmesso internamente al contenitore.
Andando più a fondo del router, il traffico arriva in un VRF interno sull'interfaccia eth2 del processore di routing:
[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 è un'interfaccia TIPC (Transport Inter Process Communication) collegata al processo IOSd. Il canale OneP viene eseguito su di esso per il passaggio di configurazioni e notifiche tra il contenitore IOSd e UTD.
Dal punto di vista dell'utente, "eth2 [ container interface]" è collegato a "VPG1 [ 192.0.2.1/192.168.2.2 ]" sono gli indirizzi inviati da vManage a IOS-XE e al contenitore.
Se si esegue tcpdump, è possibile vedere il traffico incapsulato del GRE diretto al contenitore. L'incapsulamento GRE include un'intestazione 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.....
Pacchetto in entrata dal contenitore verso il lato LAN o WAN
Dopo l'elaborazione Snort (presupponendo che il traffico non venga scartato), viene reinserito nel percorso di inoltro QFP.
cedge6#show platform packet-trace packet 15 Packet: 15 CBUG ID: 3849210 Summary Input : Tunnel6000001 Output : GigabitEthernet3 State : FWD
Tunnel600001 è l'interfaccia in uscita dal contenitore.
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
Poiché il traffico è già stato ispezionato, il router sa che si tratta di una reiniezione.
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
Il traffico arriva al NAT e va verso Internet.
Feature: MARMOT_SPA_D_TRANSMIT_PKT
Entry : Output - 0x8177c838
Input : GigabitEthernet2
Output : GigabitEthernet3
Lapsed time : 91733 ns
Integrazione registrazione flusso UTD con Packet-trace
IOS-XE 17.5.1 ha aggiunto l'integrazione della registrazione di flusso UTD con packet-trace, dove l'output della traccia del percorso includerà un verdetto UTD. Il valore Verdict può essere uno dei seguenti, ad esempio:
- il pacchetto che UTD decide di bloccare/avvisare per Snort
- consenti/rilascia per URLF
- blocca/consenti AMP
Per i pacchetti che non dispongono di informazioni sul verdetto UTD, non vengono registrate informazioni sulla registrazione del flusso. Si noti inoltre che non è disponibile alcuna registrazione di IPS/IDS pass/allow verdict a causa di un potenziale impatto negativo sulle prestazioni.
Per abilitare l'integrazione del log di flusso, utilizzare il modello aggiuntivo CLI con:
utd engine standard multi-tenancy
utd global
flow-logging all
Output di esempio per verdetti diversi:
Timeout ricerca 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)
La reputazione e il verdetto dell'URLF permettono:
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
Blocco della reputazione e del verdetto di 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
Prerequisito:
Verifica della compatibilità della versione UTD 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)
Se viene visualizzato "UNSUPPORTED", l'aggiornamento del contenitore è richiesto come primo passo prima di iniziare la risoluzione dei problemi.
Verifica la presenza di una configurazione valida del server dei nomi nel contenitore
Alcuni servizi di sicurezza, ad esempio AMP e URLF, richiedono che il contenitore UTD sia in grado di risolvere i nomi dei provider di servizi cloud, pertanto il contenitore UTD deve disporre di configurazioni del server dei nomi valide. È possibile verificare questa condizione verificando il file resolv.conf per il contenitore nella shell di 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
In base alla progettazione, Unified Thread Defense deve essere configurato insieme a Direct Internet Access Use Case (DIA). Il contenitore tenterà di risolvere api.bcti.brightcloud.com per interrogare la reputazione e le categorie degli URL. Nell'esempio, nessuno degli URL ispezionati viene bloccato anche se viene applicata la configurazione corretta
Risoluzione dei problemi
Esaminare sempre il file di registro del contenitore.
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
Il file di registro viene copiato sul flash stesso.
Per visualizzare il registro, usare il comando:
cedge6# more /compressed iox_utd_R0-0_R0-0.18629_0.20190501005829.bin.gz
La visualizzazione del registro rivela:
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
Per impostazione predefinita, vManage esegue il provisioning di un contenitore che utilizza il server OpenDNS [208.67.222.222 e 208.67.220.220]
Causa principale
Il traffico DNS (Domain Name System) per risolvere api.bcti.brightcloud.com viene interrotto nel percorso tra il contenitore e i server DNS ombrello. Verificare sempre che entrambi i DNS siano raggiungibili.
Problema 2
In uno scenario in cui i siti Web delle categorie Computer e Informazioni su Internet dovrebbero essere bloccati, la richiesta HTTP a www.cisco.com viene correttamente eliminata mentre le richieste HTTPS non lo sono.
Risoluzione dei problemi
Come spiegato in precedenza, il traffico viene punito al container. Quando questo flusso è incapsulato nell'intestazione GRE, il software aggiunge anche un'intestazione VPATH. Utilizzando questa intestazione, il sistema consente di passare una condizione di debug al contenitore stesso. Ciò significa che i contenitori UTD sono facilmente gestibili.
L'indirizzo IP del client è 192.168.16.254. Vediamo come risolvere i problemi relativi alla gestione dei russetti da parte del contenitore stesso per il traffico proveniente dal mio client.
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
Questo gruppo di comandi indica a IOS-XE di contrassegnare il traffico da o verso 192.168.16.254. In questo modo, il flag debug-me viene passato al contenitore tramite l'intestazione VPATH
Il debug degli snort viene eseguito solo su quel flusso specifico, mentre gli altri vengono elaborati normalmente.
In questa fase, è possibile chiedere all'utente di attivare il traffico dal client verso www.cisco.com.
Il passaggio successivo consiste nel recuperare i log:
app-hosting move appid utd log to bootflash:
Nel caso del traffico HTTP, il preprocessore HTTP snort individua l'URL nella richiesta 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 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
In caso di traffico HTTPS, il DNS di destinazione è stato estratto dal preprocessore HTTPS dal server hello
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
In questa schermata non viene attivata la pagina di blocco poiché il software non riporta i risultati della query Webroot.
Causa principale
CSCvo77664 
"UTD URL filtering for category lookup is fail with webroot lookup failure" (Il filtro URL UTD per la ricerca di categorie non è riuscito con errore di ricerca Web) riguarda il traffico che viene perso quando il software non ha ancora risposto alla nostra richiesta di verdetto URL.
Problema 3
In questo scenario, vengono interrotte a intermittenza le sessioni di esplorazione Web che dovrebbero essere consentite dal filtro URL [ a causa della relativa classificazione]. Ad esempio, l'accesso a www.google.com non è possibile in modo casuale anche se è consentita la categoria "motore di ricerca Web".
Risoluzione dei problemi
Passaggio 1: Raccolta delle statistiche generali
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
===============================================================================
- "late request": rappresenta il GET HTTP o il certificato client/server HTTPS [ dove è possibile estrarre SNI / DN per la ricerca. Le richieste in ritardo vengono inoltrate.
- "richieste molto in ritardo" - indica che una sorta di contatore di perdita di sessione in cui ulteriori pacchetti nel flusso vengono scartati finché il router non riceve un verdetto URL da Brightcloud. In altre parole, qualsiasi elemento successivo all'HTTP GET iniziale o al flusso SSL rimanente verrà eliminato fino alla ricezione di un verdetto.
- "richieste estremamente in ritardo" - quando la sessione di query su Brightcloud è stata reimpostata senza fornire un verdetto. La sessione scadrà dopo 60 secondi per la versione < 17.2.1. A partire dalla versione 17.2.1, la sessione di query su Brightcloud scadrà dopo 2 secondi. [ via CSCvr98723 UTD: Timeout richieste URL dopo due secondi]
In questo scenario, vediamo contatori globali che evidenziano una situazione dannosa.
Passaggio 2: Esaminare il file di log dell'applicazione
Il software Unified Thread Detection registrerà gli eventi nel file di registro dell'applicazione.
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
che estrae il file di registro dell'applicazione contenitore e lo salva sul flash stesso.
Per visualizzare il registro, usare il comando:
cedge6# more /compressed iox_utd_R0-0_R0-0.18629_0.20190501005829.bin.gz La visualizzazione del registro rivela:
.....
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
....
- "ERRORE: impossibile inviare all'host api.bcti.brightcloud.com" - indica che si è verificato un timeout della sessione di query su Brightcloud [ 60 secondi < 17.2.1 / 2 secondi >= 17.2.1 ]. Questo è il segno di una cattiva connettività a Brightcloud.
Per dimostrare il problema, l'uso di EPC [ Embedded Packet Capture] consente di visualizzare il problema di connettività.
- "SPP-URL-FILTERING txn_id miss match verdict" - Questa condizione di errore richiede una spiegazione più dettagliata. La query Brightcloud viene eseguita tramite un POST in cui il router genera un ID query
Problema 4
In questo scenario, IPS è l'unica funzionalità di sicurezza abilitata in UTD e il cliente ha problemi con la comunicazione con la stampante che è un'applicazione TCP.
Risoluzione dei problemi
Per risolvere il problema del percorso dati, acquisire il pacchetto dall'host TCP che ha il problema. L'acquisizione mostra un handshake TCP a 3 vie riuscito, ma i successivi pacchetti di dati con dati TCP sembrano essere stati scartati dal router cEdge. Quindi abilitare packet-trace, che ha mostrato quanto segue:
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)
L'output sopra riportato indica che i pacchetti numero 8 e 9 sono stati deviati al motore UTD ma non sono stati reinseriti nel percorso di inoltro. Il controllo degli eventi di registrazione del motore UTD inoltre non rivela alcuna perdita di firma Snort. Controllare quindi le statistiche interne dell'UTD, che rivelano alcune perdite di pacchetti dovute al normalizzatore 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 principale
La causa principale del problema è un comportamento errato dello stack TCP sulle stampanti. Quando l'opzione Timestamp (Data e ora) viene negoziata durante l'handshake a 3 vie TCP, la RFC 7323 indica che TCP DEVE inviare l'opzione TSopt in ogni pacchetto non <RST>. Un esame più attento dell'acquisizione dei pacchetti mostrerà che i pacchetti di dati TCP che vengono scartati non hanno queste opzioni abilitate. Con l'implementazione UTD di IOS-XE, Snort TCP normalizer con l'opzione block è abilitato indipendentemente da IPS o IDS.
Riferimenti
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
2.0 |
23-Feb-2022 |
aggiunta dell'integrazione della registrazione di flusso con packet-trace e modifiche al file di log di traccia utd |
1.0 |
10-Jan-2020 |
Versione iniziale |
Feedback