Fehlerbehebung bei Datenpfadbehandlung durch UTD und URL-Filterung
Inhalt
Einleitung
In diesem Dokument wird die Fehlerbehebung bei Unified Threat Defense (UTD), auch bekannt als Snort and Uniform Resource Locator (URL) Filtering, auf IOS® XE WAN Edges-Routern beschrieben.
Hintergrundinformationen
Snort ist das weltweit am häufigsten eingesetzte Intrusion Prevention System (IPS). Seit 2013, dem Hersteller einer kommerziellen Version der Snort-Software, wird Sourcefire von Cisco übernommen. Ab Version 16.10.1 der IOS® XE SD-WAN-Software wurden der Cisco SD-WAN-Lösung UTD-/URF-Filtercontainer hinzugefügt.
Der Container wird mithilfe des App-nav-Frameworks beim IOS®XE-Router registriert. Die Erläuterung dieses Prozesses geht über den Rahmen dieses Dokuments hinaus.
High-Level-Ansicht von DataPath
Allgemein sieht der Datenpfad folgendermaßen aus:
Vom LAN/WAN zum Container
Der Datenverkehr kommt von der LAN-Seite. Da IOS® XE weiß, dass sich der Container in einem fehlerfreien Zustand befindet, wird der Datenverkehr an den UTD-Container umgeleitet. Bei der Umleitung wird die VirtualPortGroup1-Schnittstelle als Ausgangsschnittstelle verwendet, die das Paket innerhalb eines Generic Routing Encapsulation (GRE)-Tunnels kapselt.
Der Router führt die PUNT-Aktion mit der Ursache :64 (Service Engine Packet) durch und sendet den Datenverkehr an den Route Processor (RP). Ein Punt-Header wird hinzugefügt, und das Paket wird mithilfe einer internen Ausgangsschnittstelle zum Container "[internal0/0/svc_eng:0]" gesendet.
In dieser Phase nutzt Snort seine Präprozessoren und Regelsätze. Das Paket kann aufgrund der Verarbeitungsergebnisse verworfen oder weitergeleitet werden.
Vom Container zum LAN/WAN
Wenn der Datenverkehr nicht verworfen werden soll, wird das Paket nach der UTD-Verarbeitung zurück an den Router geleitet. Sie wird auf dem Quantum Flow Processor (QFP) als von Tunnel6000001 stammend angezeigt. Diese wird dann vom Router verarbeitet und muss (hoffentlich) an die WAN-Schnittstelle weitergeleitet werden.
Container steuert das Umleitungsergebnis in der UTD-Inspektion im IOS® XE-Datenpfad.
Beim HTTPS-Fluss sind die Präprozessoren beispielsweise daran interessiert, die Hello-/Client Hello-Pakete des Servers mit TLS-Aushandlung anzuzeigen. Anschließend wird der Datenfluss nicht umgeleitet, da die Überprüfung von TLS-verschlüsseltem Datenverkehr wenig Vorteile bietet.
Datapath Deep Dive
Vom Standpunkt der Paketverfolgung aus werden diese Aktionen angezeigt (192.168.16.254 ist ein Web-Client):
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
Eingangspaket von LAN- oder WAN-Seite zum Container
In diesem speziellen Szenario stammt das verfolgte Paket aus dem LAN. Hinsichtlich der Umleitung gibt es relevante Unterschiede, wenn der Datenfluss aus dem LAN oder WAN stammt.
Der Client versucht über HTTPS auf www.cisco.com zuzugreifen.
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>
Der an die Bedingung angepasste Datenverkehr wird für den Eingang an der Schnittstelle GigabitEthernet2 zurückverfolgt.
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>
Im Egress Feature Invocation Array (FIA) der Egress-Schnittstelle hat UTD FIA entschieden, dieses Paket an den Container umzuleiten.
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>
Das Paket wird im Standard-Tunnel Tunnel600001 platziert und über die VPG1-Schnittstelle geroutet. Zu diesem Zeitpunkt wird das ursprüngliche Paket GRE-gekapselt.
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
Das Paket wird intern an den Container übertragen.
Auf dem Router selbst kommt der Datenverkehr in einer internen VRF an der Routingprozessor-Schnittstelle eth2 an:
[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 ist eine TIPC-Schnittstelle (Transport Inter Process Communication), die mit dem IOSd-Prozess verbunden ist. Der OnePKanal wird darüber ausgeführt, um Konfigurationen und Benachrichtigungen zwischen dem IOSd- und dem UTD-Container hin und her zu übertragen.
Aus Ihrer Sicht wird "eth2 [ Containerschnittstelle]" zu "VPG1 [ 192.0.2.1/192.168.2.2 ]" überbrückt. Dies sind die Adressen, die von vManage an IOS-XE und den Container weitergeleitet werden.
Wenn Sie tcpdump ausführen, sehen Sie, dass der GRE-gekapselte Datenverkehr an den Container geht. Die GRE-Kapselung enthält einen 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.....
Eingangspaket vom Container zur LAN- oder WAN-Seite
Nach der Snort-Verarbeitung (unter der Annahme, dass der Datenverkehr nicht verworfen werden soll) wird er wieder in den QFP-Weiterleitungspfad zurückgeleitet.
cedge6#show platform packet-trace packet 15 Packet: 15 CBUG ID: 3849210 Summary Input : Tunnel6000001 Output : GigabitEthernet3 State : FWD
Tunnel600001 ist die Ausgangsschnittstelle des Containers.
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
Da der Datenverkehr bereits überprüft wurde, weiß der Router, dass es sich um eine erneute Injektion handelt.
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
Der Datenverkehr wird per NAT geleitet und geht in Richtung Internet.
Feature: MARMOT_SPA_D_TRANSMIT_PKT
Entry : Output - 0x8177c838
Input : GigabitEthernet2
Output : GigabitEthernet3
Lapsed time : 91733 ns
Integration der UTD-Flow-Protokollierung mit Packet-Trace
IOS-XE 17.5.1 hat die Integration der UTD-Flow-Protokollierung mit Packet-Trace hinzugefügt, wobei die Path-Trace-Ausgabe ein UTD-Verdict enthält. Ein Verdict kann beispielsweise eines der folgenden sein:
- das Paket, das UTD blockiert/für Snort alarmiert
- Zulassen/Löschen für URLF
- Blockieren/Zulassen für AMP
Bei Paketen ohne UTD-Verdict-Informationen werden keine Flow-Protokollierungsinformationen protokolliert. Beachten Sie außerdem, dass aufgrund möglicher negativer Auswirkungen auf die Leistung keine Protokollierung des IPS/IDS-Passes/Zulassen-Verdicts durchgeführt wird.
Um die Flow-Protokollierung zu aktivieren, verwenden Sie die CLI-Add-On-Vorlage mit:
utd engine standard multi-tenancy
utd global
flow-logging all
Beispielausgabe für verschiedene Urteile:
Timeout für URL-Suche:
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)
URL-Reputation und -Beurteilung Zulassen:
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
URL-Reputation und Verdict Block:
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
Voraussetzung:
Überprüfen der Kompatibilität der UTD-Version mit 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)
Wenn "UNSUPPORTED" (Nicht unterstützt) angezeigt wird, muss das Container-Upgrade als erster Schritt vor Beginn der Fehlerbehebung durchgeführt werden.
Überprüfen Sie, ob im Container eine gültige Namenserver-Konfiguration vorhanden ist.
Für einige Sicherheitsdienste wie AMP und URLF muss der UTD-Container Namen für die Cloud-Service-Provider auflösen können. Der UTD-Container muss daher gültige Namenserver-Konfigurationen aufweisen. Dies kann überprüft werden, indem die Datei resolv.conf für den Container unter der System-Shell überprüft wird:
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
Problem 1
Die Unified Thread Defense-Funktion muss entsprechend des Designs zusammen mit dem DIA (Direct Internet Access Use Case) konfiguriert werden. Der Container wird versuchen, api.bcti.brightcloud.com aufzulösen, um URL-Reputationen und -Kategorien abzufragen. In diesem Beispiel wird keine der inspizierten URLs blockiert, selbst wenn die richtige Konfiguration angewendet wird
Fehlerbehebung
Schauen Sie sich immer die Container-Protokolldatei an.
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
Dadurch wird die Protokolldatei in den Flash-Speicher kopiert.
Das Protokoll kann mit dem folgenden Befehl angezeigt werden:
cedge6# more /compressed iox_utd_R0-0_R0-0.18629_0.20190501005829.bin.gz
Durch das Anzeigen des Protokolls werden folgende Informationen angezeigt:
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
vManage stellt standardmäßig einen Container bereit, der OpenDNS-Server verwendet [208.67.222.222 und 208.67.220.220]
Ursache
Der DNS-Datenverkehr (Domain Name System) zur Auflösung von api.bcti.brightcloud.com wird irgendwo im Pfad zwischen dem Container und den übergeordneten DNS-Servern verworfen. Stellen Sie immer sicher, dass beide DNS erreichbar sind.
Problem 2
In einem Szenario, in dem Websites der Kategorie Computer und Internetinformationen blockiert werden sollen, wird die HTTP-Anforderung an www.cisco.com ordnungsgemäß verworfen, während HTTPS-Anforderungen nicht blockiert werden.
Fehlerbehebung
Wie bereits erläutert, wird der Verkehr auf den Container gelenkt. Wenn dieser Fluss in den GRE-Header gekapselt ist, wird die Software sowie ein VPATH-Header angefügt. Mithilfe dieses Headers ermöglicht das System die Übergabe einer Debugbedingung an den Container selbst. Das bedeutet, dass UTD-Container gut gewartet werden können.
In diesem Szenario lautet die Client-IP-Adresse 192.168.16.254. Beheben wir nun die Fehlerbehebung für den vom Client stammenden Datenverkehr durch den Container selbst.
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
Diese Befehle weisen IOS-XE an, Datenverkehr von oder zu 192.168.16.254 zu markieren. Dadurch kann das debug-me-Flag über den VPATH-Header an den Container übergeben werden.
Snort debuggt nur diesen bestimmten Fluss, während andere normal verarbeitet werden.
In dieser Phase können Sie den Benutzer auffordern, den Datenverkehr vom Client zu www.cisco.com auszulösen.
Der nächste Schritt wäre das Abrufen der Protokolle:
app-hosting move appid utd log to bootflash:
Im Fall von HTTP-Datenverkehr erkennt der snort HTTP-Präprozessor die URL in der get-Anforderung.
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 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Bei HTTPS-Datenverkehr wurde das Ziel-DNS vom HTTPS-Präprozessor aus dem Hello-Server extrahiert.
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 wird die Sperrseite nicht ausgelöst, da die Software die Ergebnisse der Webroot-Abfrage nicht meldet.
Ursache
CSCvo77664 
"Die UTD-URL-Filterung für die Kategoriensuche schlägt fehl, wenn die Webroot-Suche fehlschlägt" bezieht sich darauf, dass Datenverkehr durchsickert, wenn Software noch keine Antwort auf unsere URL-Verdict-Anfrage hat.
Problem 3
In diesem Szenario werden gelegentlich Webbrowsersitzungen, die von URL-Filterung [ aufgrund ihrer Klassifizierung] zugelassen werden sollten, verworfen. Beispielsweise ist der Zugriff auf www.google.com nach dem Zufallsprinzip nicht möglich, selbst wenn die Kategorie "Web-Suchmaschine" erlaubt ist.
Fehlerbehebung
Schritt 1: Sammeln allgemeiner Statistiken
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": Diese Eigenschaft stellt HTTP GET oder das HTTPS-Client/Server-Zertifikat dar [ wobei SNI/DN für die Suche extrahiert werden kann. Verspätete Anfragen werden weitergeleitet.
- "sehr späte Anfragen": Dies bedeutet, dass eine Art Session-Drop-Zähler, bei dem weitere Pakete im Flow verworfen werden, bis der Router eine URL-Beurteilung von Brightcloud erhält. Mit anderen Worten, alles nach dem ersten HTTP GET oder der verbleibende Teil des SSL-Flusses wird verworfen, bis ein Urteil eingegangen ist.
- "extrem späte Anfragen" - wenn die Sitzungsabfrage zu Brightcloud zurückgesetzt wurde, ohne ein Urteil abzugeben. Das Timeout für die Sitzung wird nach 60 Sekunden für Version < 17.2.1 beendet. Ab 17.2.1 wird die anfragende Sitzung zu Brightcloud nach 2 Sekunden beendet. [ über CSCvr98723 UTD: Timeout-URL-Anforderungen nach zwei Sekunden]
In diesem Szenario sehen wir globale Zähler, die eine ungesunde Situation hervorheben.
Schritt 2: Überprüfen der Anwendungsprotokolldatei
Die Unified Thread Detection-Software zeichnet Ereignisse in der Anwendungsprotokolldatei auf.
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
Dadurch wird die Protokolldatei der Containeranwendung extrahiert und im Flash-Speicher gespeichert.
Das Protokoll kann mit dem folgenden Befehl angezeigt werden:
cedge6# more /compressed iox_utd_R0-0_R0-0.18629_0.20190501005829.bin.gz Durch das Anzeigen des Protokolls werden folgende Informationen angezeigt:
.....
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
....
- "FEHLER: Kann nicht an Host api.bcti.brightcloud.com gesendet werden" - bedeutet, dass bei der abfragenden Sitzung zu Brightcloud ein Timeout aufgetreten ist [ 60 Sekunden < 17.2.1 / 2 Sekunden >= 17.2.1 ]. Dies ist ein Zeichen für eine schlechte Verbindung mit Brightcloud.
Um das Problem zu veranschaulichen, kann durch die Verwendung von EPC [ Embedded Packet Capture] das Verbindungsproblem visualisiert werden.
- "SPP-URL-FILTERING txn_id miss match verdict" - Dieser Fehler erfordert eine genauere Erklärung. Die Brightcloud-Abfrage wird über einen POST durchgeführt, bei dem vom Router eine Abfrage-ID generiert wird.
Problem 4
In diesem Szenario ist IPS die einzige Sicherheitsfunktion, die in UTD aktiviert ist, und der Kunde hat Probleme mit der Druckerkommunikation, bei der es sich um eine TCP-Anwendung handelt.
Fehlerbehebung
Um dieses Datenpfadproblem zu beheben, nehmen Sie zunächst die Paketerfassung vom TCP-Host, der das Problem hat. Die Erfassung zeigt einen erfolgreichen TCP-Drei-Wege-Handshake, aber nachfolgende Datenpakete mit TCP-Daten scheinen vom cEdge-Router verworfen worden zu sein. Als Nächstes aktivieren Sie "packet-trace", was Folgendes zeigt:
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)
Die oben angegebenen Paketnummern 8 und 9 wurden an die UTD-Engine umgeleitet, wurden jedoch nicht erneut in den Weiterleitungspfad eingespeist. Bei der Überprüfung der Protokollierungsereignisse des UTD-Moduls werden auch keine Snort-Signaturverluste festgestellt. Überprüfen Sie anschließend die internen UTD-Statistiken, die einige Paketverluste aufgrund des TCP-Normalisierungsprogramms aufdecken:
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
Ursache
Die Ursache des Problems liegt in einem fehlerhaften TCP-Stack auf den Druckern. Wenn die Option Timestamp (Zeitstempel) während des TCP-3-Wege-Handshakes ausgehandelt wird, gibt RFC7323 an, dass TCP die Option TSopt in jedem Nicht-<RST>-Paket senden MUSS. Eine genauere Untersuchung der Paketerfassung zeigt, dass diese Optionen bei den verworfenen TCP-Datenpaketen nicht aktiviert sind. Bei der IOS-XE UTD-Implementierung ist der Snort TCP-Normalisierer mit der Blockoption unabhängig von IPS oder IDS aktiviert.
Referenzen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
23-Feb-2022 |
Integration von Flow-Logging mit Packet-Trace und den Änderungen der Protokolldatei utd btrace |
1.0 |
10-Jan-2020 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)