Probleemoplossing voor gegevensverwerking door UTD en URL-filtering
Inhoud
Inleiding
Dit document beschrijft hoe u problemen kunt oplossen bij Unified Threat Defense (UTD), ook bekend als Snelheids- en Uniform Resource Locator (URL)-filtering op IOS® XE WAN-randen.
Achtergrondinformatie
Snort is het meest gebruikte inbraakpreventiesysteem (IPS) in de wereld. Sinds 2013, het bedrijf dat een commerciële versie van de Snort-software heeft gemaakt, wordt Sourcefire overgenomen door Cisco. Vanaf 16.10.1 IOS® XE SD-WAN-software zijn UTD/URF-filtering containers toegevoegd aan de Cisco SD-WAN oplossing.
De container registreert zich bij de IOS®XE router met behulp van het app-nav framework. De uitleg van dat proces valt buiten de reikwijdte van dit document.
Datapath-weergave op hoog niveau
Op een hoog niveau ziet het datapath er als volgt uit:
Van LAN/WAN naar de container
Het verkeer komt van de LAN kant. Aangezien IOS® XE weet dat de container in een gezonde staat is, leidt het het verkeer naar de container UTD af. De omleiding gebruikt de VirtualPortGroup1-interface als de uitgangsinterface, die het pakket inkapselt binnen een GRE-tunnel (Generic Routing Encapsulation).
De router voert "PUNT"actie uit met behulp van oorzaak :64 (het pakket van de Motor van de Dienst)" en verstuurt het verkeer naar de routeprocessor (RP). Er wordt een puntheader toegevoegd en het pakket wordt naar de container verzonden met behulp van een interne uitgangsinterface naar de container "[internal0/0/svc_eng:0]"
In dit stadium maakt Snort gebruik van zijn voorprocessors en regelsets. Het pakket kan worden gelaten vallen of door:sturen gebaseerd op de verwerkingsresultaten.
Van de Container naar LAN/WAN
Ervan uitgaande dat het verkeer niet hoeft te worden gedropt, wordt het pakket na de UTD-verwerking teruggestuurd naar de router. Het verschijnt op de Quantum Flow Processor (QFP) zoals komend uit Tunnel6000001. Dan wordt het verwerkt door de router en moet (hopelijk) naar de WAN-interface worden verstuurd.
Container regelt het afleidingsresultaat in de UTD-inspectie in het IOS® XE datapath.
Bijvoorbeeld, met HTTPS flow, zijn de preprocessors geïnteresseerd om de server Hello / Client Hello pakketten met TLS onderhandeling te zien. Daarna wordt de stroom niet omgeleid omdat het inspecteren van TLS-versleuteld verkeer weinig waarde heeft.
Datapath Deep Dive
Vanuit een pakkettracer standpunt, gaat die reeks actie worden gezien (192.168.16.254 is een webclient):
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
Ingress Packet vanaf LAN of WAN-zijde naar de container
In dit bepaalde scenario is het overgetrokken pakket afkomstig van het netwerk. Vanuit een omleidingsstandpunt zijn er relevante verschillen als de stroom afkomstig is van LAN of WAN.
De client probeert toegang te krijgen tot www.cisco.com op 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>
Het verkeer dat de voorwaarde aanpast is overgetrokken toegang op interface 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>
In de egress Feature Invocation Array (FIA) van de egress-interface heeft UTD FIA besloten om dit pakket naar de container af te leiden.
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>
Het pakket wordt geplaatst op de standaardtunneltunnel600001 en wordt gerouteerd over de VPG1 interface. In deze fase is het oorspronkelijke pakket GRE ingekapseld.
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
Het pakket wordt intern naar de container verzonden.
Dieper gaand in de router zelf, komt het verkeer in een interne VRF op de routeprocessorinterface eth2:
[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 is een Transport Inter Process Communication (TIPC) interface die is verbonden met het IOSd-proces. Het OneP-kanaal loopt over het voor het doorgeven van configuraties en meldingen tussen de IOSd en UTD-container.
Van wat u bezighoudt, "eth2 [ container interface]" is overbrugd naar "VPG1 [ 192.0.2.1/192.168.2.2 ]" zijn de adressen die door vManager naar de IOS-XE en container worden geduwd.
Als u tcpdump in werking stelt, kunt u het GRE ingekapselde verkeer zien gaan naar de container. De GRE-insluiting bevat een VPATH-header.
[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.....
Ingress Packet vanaf container naar LAN- of WAN-zijde
Na snortverwerking (ervan uitgaande dat er geen verkeer wordt gedropt) wordt het opnieuw naar het QFP-doorsturen pad gespoten.
cedge6#show platform packet-trace packet 15 Packet: 15 CBUG ID: 3849210 Summary Input : Tunnel6000001 Output : GigabitEthernet3 State : FWD
Tunnel600001 is de uitgang interface van de container.
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
Aangezien het verkeer al is geïnspecteerd, weet de router dat dit een herinjectie is.
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
Het verkeer wordt NATed en gaat naar het internet toe.
Feature: MARMOT_SPA_D_TRANSMIT_PKT
Entry : Output - 0x8177c838
Input : GigabitEthernet2
Output : GigabitEthernet3
Lapsed time : 91733 ns
UTD-integratie van flow logging met pakkettracering
IOS-XE 17.5.1 voegde UTD flow logging integratie met packet-trace toe, waar de path-trace uitvoer een UTD-vonnis zal bevatten. Een vonnis kan een van de volgende zijn, bijvoorbeeld:
- het pakket dat UTD besluit te blokkeren/te alarmeren voor Snel
- sta/drop voor URLF toe
- blokkeren/toestaan voor AMP
Voor pakketten die niet de UTD-oordeelinformatie hebben, wordt geen informatie over flow logging vastgelegd. Let ook op dat er geen vastlegging van IPS/IDS-pas/laat vonnis toe te schrijven aan potentieel negatieve prestatie-impact.
Om flow-logging integratie mogelijk te maken, gebruikt u de CLI Add-On-sjabloon met:
utd engine standard multi-tenancy
utd global
flow-logging all
Voorbeeld output voor verschillende verdicts:
Time-out bij URL-zoeken:
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)
URLF reputatie en uitspraak Toestaan:
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
URLF reputatie en vonnis Blok:
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
Belangrijk:
Controleren of de UTD-versie compatibel is met 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)
Als "UNSUPPORT" wordt weergegeven, moet u de container upgraden om te beginnen met het oplossen van problemen.
Controleer in de container of er geldige naamserverconfiguratie is
Sommige beveiligingsdiensten zoals AMP en URLF zullen vereisen dat de UTD-container namen voor de cloudserviceproviders kan oplossen, zodat de UTD-container geldige naamserverconfiguraties moet hebben. Dit kan worden geverifieerd door het bestand resolv.conf te controleren op de container onder de systeemshell:
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
Probleem 1
Per ontwerp moet Unified Thread Defense volledig worden geconfigureerd met de Direct Internet Access use case (DIA). De container zal proberen om api.bcti.brightcloud.com op te lossen om URL reputaties en categorieën te bevragen. In dit voorbeeld wordt geen van de geïnspecteerde URL's geblokkeerd, zelfs niet als de juiste configuratie wordt toegepast
Problemen oplossen
Kijk altijd naar het containerlogbestand.
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
Dat kopieert het logbestand op de flitser zelf.
Het weergeven van het logbestand kan worden bereikt met de opdracht:
cedge6# more /compressed iox_utd_R0-0_R0-0.18629_0.20190501005829.bin.gz
Wanneer u het logbestand weergeeft:
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
Standaard vManager-bepalingen voor een container die OpenDNS-server gebruikt [208.67.222.222 en 208.67.220.220]
Hoofdoorzaak
Domain Name System (DNS) verkeer om api.bcti.brightcloud.com op te lossen wordt ergens in het pad tussen de container en de paraplu DNS-servers gedropt. Zorg er altijd voor dat beide DNS bereikbaar zijn.
Probleem 2
In een scenario waarin websites uit de categorie Computer en Internet Info worden geblokkeerd, wordt het http-verzoek aan www.cisco.com correct geschrapt terwijl HTTPS-verzoeken niet worden geblokkeerd.
Problemen oplossen
Zoals eerder uitgelegd, wordt het verkeer gestraft aan de container. Wanneer deze stroom in de GRE-header is ingesloten, voegt de software ook een VPATH-header toe. Leveraging deze header, het systeem staat toe om een debug voorwaarde aan de container zelf over te gaan. Dit betekent dat UTD-containers goed te onderhouden zijn.
In dit scenario is het IP-adres van de client 192.168.16.254. Laten we de snortbehandeling oplossen door de container zelf voor het verkeer dat van mijn client komt.
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
Deze set opdrachten instrueert IOS-XE om verkeer te markeren van of naar 192.168.16.254. Hiermee kan de debug-me-vlag via de VPATH-header aan de container worden doorgegeven
Snort debugt alleen die specifieke flow terwijl anderen normaal worden verwerkt.
In dit stadium kunt u de gebruiker vragen om het verkeer van de klant naar www.cisco.com te activeren.
De volgende stap zou zijn de logbestanden terug te halen:
app-hosting move appid utd log to bootflash:
In het geval van HTTP-verkeer detecteert de snort HTTP-preprocessor de URL in de get request.
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 het geval van https-verkeer is de bestemming DNS door de HTTPS-voorverwerker uit de server verwijderd
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
Hier ziet u niet dat de blokkerende pagina wordt geactiveerd omdat de software de resultaten van de webroot query niet rapporteert.
Hoofdoorzaak
CSCvo77664 
"UTD URL filtering voor categorie lookup faalt met webroot lookup falen" gaat over het verkeer wordt gelekt wanneer software nog geen reactie heeft op ons URL verdict verzoek.
Probleem 3
In dit scenario worden af en toe webbrowsersessies die door URL-filtering zouden moeten worden toegestaan [ vanwege hun classificatie], geschrapt. Zo is toegang tot www.google.com willekeurig niet mogelijk, zelfs niet als de categorie "web search engine" is toegestaan.
Problemen oplossen
Stap 1: Verzamelen van algemene statistieken
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 aanvraag" - staat voor HTTP GET of het HTTPS client/server certificaat [ waar SNI / DN kan worden geëxtraheerd voor opzoeking. Een te laat ingediend verzoek wordt doorgestuurd.
- "zeer late verzoeken" - betekent dat een soort sessie drop teller waar verdere pakketten in de flow worden gelaten vallen tot de router een URL-oordeel van Brightcloud ontvangt. Met andere woorden, alles na de eerste HTTP GET of de rest van de SSL flow zal worden gedropt totdat een vonnis is ontvangen.
- "extreem late aanvragen" - wanneer de sessie query naar Brightcloud is gereset zonder dat er een uitspraak is gedaan. De sessie wordt na 60 seconden uitgeschakeld voor versie < 17.2.1. Vanaf 17.2.1 zal de querying sessie naar Brightcloud na 2 seconden uitlopen. [ via CSCvr98723 UTD: URL-aanvragen voor tijdelijke oplossing na twee seconden]
In dit scenario zien we mondiale tellers die een ongezonde situatie aan het licht brengen.
Stap 2: Het logbestand van de toepassing bekijken
De Unified Thread Detection-software gaat gebeurtenissen opnemen in het toepassingslogbestand.
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
Dat haalt het logbestand van de containertoepassing uit en slaat het op de flitser zelf op.
Het weergeven van het logbestand kan worden bereikt met de opdracht:
cedge6# more /compressed iox_utd_R0-0_R0-0.18629_0.20190501005829.bin.gz Wanneer u het logbestand weergeeft:
.....
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
....
- "FOUT: Kan niet naar host api.bcti.brightcloud.com verzenden" - betekent dat de querying sessie naar Brightcloud timing is geweest [ 60 seconden < 17.2.1 / 2 seconden >= 17.2.1 ]. Dit is het teken van een slechte verbinding met Brightcloud.
Om het probleem aan te tonen, zou het gebruik van EPC [ Embedded Packet Capture] het mogelijk maken het connectiviteitsprobleem te visualiseren.
- "SPP-URL-FILTERING txn_id mismatch verdict" - Deze fout voorwaarde vereist een beetje meer uitleg. Brightcloud query wordt uitgevoerd via een POST waar een query-id wordt gegenereerd door de router
Probleem 4
In dit scenario is IPS de enige beveiligingsfunctie die in UTD is ingeschakeld, en de klant ondervindt problemen met printercommunicatie die een TCP-toepassing is.
Problemen oplossen
Om deze datapadkwestie problemen op te lossen, neem eerst het pakketopname van de TCP-host die het probleem heeft. De opname toont een succesvolle TCP 3-weg handdruk, maar latere gegevenspakketten met TCP-gegevens lijken te zijn gedropt door de cEdge-router. Schakel vervolgens packet-trace in, die het volgende liet zien:
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)
De hierboven aangegeven output van pakketnummer 8 en 9 is omgeleid naar de UTD-engine, maar ze werden niet opnieuw geïnjecteerd in het voorwaartse pad. Het controleren van de UTD-motorlogboekgebeurtenissen onthult ook geen enkele snort-signatuur vallen. Controleer vervolgens de interne UTD-statistieken, die wel wat pakketdalingen aan het licht brengen vanwege de TCP-normalizer:
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
Hoofdoorzaak
De worteloorzaak van het probleem is toe te schrijven aan het misdragen van de stapel van TCP op de printers. Wanneer de tijdstempeloptie tijdens de TCP 3-weg handdruk wordt onderhandeld, verklaart RFC7323 dat TCP de TSoptieoptie in elk niet-<RST> pakket MOET verzenden. Een nader onderzoek van de pakketopname zal tonen dat de TCP-gegevenspakketten die worden gedropt deze opties niet hebben ingeschakeld. Met de IOS-XE UTD-implementatie wordt Snort TCP-normalizer met de blokoptie ingeschakeld, ongeacht IPS of IDS.
Referenties
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
2.0 |
23-Feb-2022 |
integratie met toegevoegd flow-logging met packet-trace en wijzigingen in het logbestand utdtrace |
1.0 |
10-Jan-2020 |
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)