Firepower Firewall Captures analyseren om netwerkproblemen effectief op te lossen
Inhoud
Inleiding
Dit document beschrijft verschillende technieken voor de pakketvastlegging die zijn gericht op het effectief oplossen van netwerkproblemen. Alle scenario's die in dit document worden gepresenteerd, zijn gebaseerd op echte gebruikerscases die in het Cisco Technical Assistance Center (TAC) zijn gezien. Het document bestrijkt de pakketvastlegging vanuit het oogpunt van Cisco Next-generation firewall (NGFW), maar de dezelfde concepten zijn ook van toepassing op andere apparaten.
Voorwaarden
Vereisten
Cisco raadt kennis van de volgende onderwerpen aan:
- Firepower platform architectuur
- NGFW-loggen
- NGFW-pakkettracer
Bovendien is het, voordat u begint met het analyseren van de verpakking, zeer raadzaam om aan deze vereisten te voldoen:
- Weet u de protocolhandeling - het is zinloos om te beginnen met het controleren van een pakketvastlegging als u niet begrijpt hoe het opgenomen protocol werkt
- Ken de topologie - U moet de vervoermiddelen kennen. Idealiter. Indien dit niet mogelijk is, moet u ten minste de stroomopwaarts- en stroomafwaartse inrichtingen kennen
- Weet u het apparaat - U moet weten hoe uw apparaat pakketten verwerkt, wat de betrokken interfaces zijn (bijvoorbeeld instap/stress), wat de apparaatarchitectuur is en wat de verschillende opnamepunten zijn
- Weet u de configuratie - U moet weten hoe een pakketstroom door het apparaat moet worden verwerkt in termen van:
- Routing/fax-interface
- Toepasselijk beleid
- Netwerkadresomzetting (NAT)
- Weet u de beschikbare gereedschappen - samen met de opnames wordt aanbevolen om ook klaar te zijn voor het toepassen van andere gereedschappen en technieken voor probleemoplossing zoals houtkap en tracers en indien nodig om deze samen te brengen met de opgenomen pakketten
Gebruikte componenten
De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:
- De meeste scenario's zijn gebaseerd op FP4140-actieve software 6.5.x.
- FMC-actieve software 6.5.x.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.
Achtergrondinformatie
De pakketvastlegging is een van de meest over het hoofd geziene gereedschappen voor probleemoplossing die momenteel beschikbaar zijn. Dagelijks lost Cisco TAC veel klantproblemen op door opgenomen gegevens te analyseren. Het doel van dit document is netwerk- en security engineers te helpen gemeenschappelijke netwerkproblemen te identificeren en oplossen, die voornamelijk op analyse van pakketvastlegging zijn gebaseerd.
Hoe Capture te verzamelen en te exporteren voor de NGFW-productfamilie?
In het geval van een FirePOWER-applicatie (1xxx, 21xx, 41xx, 93xx) en een Firepower Threat Defense (FTD) kan een pakketverwerking worden bekeken zoals in de afbeelding.
- Een pakje gaat in op de ingangsinterface en wordt behandeld door de interne schakelaar van het chassis.
- Het pakket voert de FTD Lina-motor in, die voornamelijk L3/L4-controles uitvoert.
- Indien het beleid vereist dat de pakking door de snortmotor wordt geïnspecteerd (hoofdzakelijk L7-inspectie).
- De Snort-machine geeft een oordeel voor het pakje terug.
- De LINA-motor daalt of verstuurt het pakket op basis van de uitspraak van de Snort.
- Het pakket maakt gebruik van het chassis door de interne chassisschakelaar.
Gebaseerd op de getoonde architectuur, kunnen de FTD Captures op 3 verschillende plaatsen worden genomen:
- FXOS
- FTD Lina-motor
- FTD Snortmachine
Verzamelen FXOS-opnamen
Dit proces wordt in dit document beschreven:
FXOS-opnamen kunnen alleen in de ingangsrichting worden genomen vanuit het interne switchstandpunt dat in de afbeelding hier wordt weergegeven.
Zoals in de afbeelding wordt getoond, zijn dit twee opnamepunten per richting (door interne switcharchitectuur).
Opgenomen pakketten in de punten 2, 3 en 4 hebben een virtuele netwerktag (VNTag).
FTD Lina Capture inschakelen en verzamelen
Belangrijkste opnamepunten:
- Ingoesinterface
- Egresse-interface
- Accelerated Security Path (ASP)
U kunt gebruikmaken van Firepower Management Center User Interface (FMC UI) of FTD CLI om de FTD LAN-opnamekaarten mogelijk te maken en te verzamelen.
Opname vanuit CLI op de INSIDE-interface inschakelen:
firepower# capture CAPI interface INSIDE match icmp host 192.168.103.1 host 192.168.101.1
Deze opname komt overeen met het verkeer tussen IP's 192.168.103.1 en 192.168.101.1 in beide richtingen.
ASP-opname inschakelen om alle pakketten die door de FTD Lina-motor zijn gedropt te zien:
firepower# capture ASP type asp-drop all
Exporteren van een FTD LAN-opname naar een FTP-server:
firepower# copy /pcap capture:CAPI ftp://ftp_username:ftp_password@192.168.78.73/CAPI.pcap
Exporteren van een FTD LAN-opname naar een TFTP-server:
firepower# copy /pcap capture:CAPI tftp://192.168.78.73
Vanaf de versie van FMC 6.2.x kunt u FTD Lina Captures inschakelen en verzamelen bij FMC UI.
Een andere manier om FTD Captures te verzamelen bij een door FMC beheerde firewall is dit.
Stap 1
Bij LINA- of ASP-opname dient u de opname naar de FTD-schijf te kopiëren, bijvoorbeeld.
firepower# copy /pcap capture:capin disk0:capin.pcap Source capture name [capin]? Destination filename [capin.pcap]? !!!!
Stap 2
Navigeren in naar deskundigenmodus, de opgeslagen opname vinden en kopiëren naar de /ngfw/var/common locatie:
firepower# Console connection detached. > expert admin@firepower:~$ sudo su Password: root@firepower:/home/admin# cd /mnt/disk0 root@firepower:/mnt/disk0# ls -al | grep pcap -rwxr-xr-x 1 root root 24 Apr 26 18:19 CAPI.pcap -rwxr-xr-x 1 root root 30110 Apr 8 14:10 capin.pcap -rwxr-xr-x 1 root root 6123 Apr 8 14:11 capin2.pcap root@firepower:/mnt/disk0# cp capin.pcap /ngfw/var/common
Stap 3
Meld u aan bij de FMC die de FTD beheert en navigeer naar Apparaten > Apparaatbeheer. Pak het FTD-apparaat en selecteer het pictogram Troubleshooter:
Stap 4
Selecteer Geavanceerde probleemoplossing:
Specificeer de naam van het opnamebestand en selecteer Downloaden:
Voor meer voorbeelden hoe u opnames van het FMC UI kunt inschakelen/verzamelen, controleert u dit document:
SND-korte Capture inschakelen en inzamelen
Het opnamepunt wordt hier in de afbeelding weergegeven.
Opname op korte niveau inschakelen:
> capture-traffic Please choose domain to capture traffic from: 0 - br1 1 - Router Selection? 1 Please specify tcpdump options desired. (or enter '?' for a list of supported options) Options: -n host 192.168.101.1
U kunt de opname als volgt schrijven naar een bestand met de naam Capture.pcap en deze via FTP naar een externe server kopiëren:
> capture-traffic Please choose domain to capture traffic from: 0 - br1 1 - Router Selection? 1 Please specify tcpdump options desired. (or enter '?' for a list of supported options) Options: -w capture.pcap host 192.168.101.1 CTRL + C <- to stop the capture
> file copy 10.229.22.136 ftp / capture.pcap Enter password for ftp@10.229.22.136: Copying capture.pcap Copy successful. >
Controleer dit document voor meer voorbeelden van opnamen op korte niveau die verschillende opnamefilters bevatten:
Problemen oplossen
Case 1. No TCP SYN on Egress Interface
De topologie wordt hier in de afbeelding getoond:
Beschrijving van probleem: HTTP werkt niet
Betrokken stroom:
SRC IP: 192.168.0.100
DT IP: 10.10.1.100
Protocol: TCP 80
Capture Analysis
Opname op de FTD LINA-motor inschakelen:
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
Captures - functioneel scenario:
Als basislijn is het altijd erg nuttig om opnamen te hebben van een functioneel scenario.
Opname op NGFW INSIDE-interface is zoals in de afbeelding weergegeven:
Belangrijkste punten:
- TCP 3-handdruk.
- Bidirectionele gegevensuitwisseling.
- Geen vertragingen tussen de pakketten (gebaseerd op het tijdsverschil tussen de pakketten)
- Bron MAC is het juiste stroomafwaartse apparaat.
De opgenomen beelden op een NGFW BUITEN de interface worden hier in het beeld weergegeven:
Belangrijkste punten:
- Dezelfde gegevens als in de CAPI-opname.
- Bestemming MAC is het juiste stroomopwaarts apparaat.
Captures - niet-functioneel scenario
Vanaf het apparaat CLI zien de opnamen er als volgt uit:
firepower# show capture capture CAPI type raw-data interface INSIDE [Capturing - 484 bytes] match ip host 192.168.0.100 host 10.10.1.100 capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes] match ip host 192.168.0.100 host 10.10.1.100
CAPI-inhoud:
firepower# show capture CAPI 6 packets captured 1: 11:47:46.911482 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 11:47:47.161902 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 11:47:49.907683 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 4: 11:47:50.162757 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 11:47:55.914640 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,nop,sackOK> 6: 11:47:56.164710 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,nop,sackOK>
firepower# show capture CAPO 0 packet captured 0 packet shown
Dit is de afbeelding van de CAPI-opname in Wireshark:
Belangrijkste punten:
- Er worden alleen TCP SYN-pakketten gezien (geen TCP 3-handdruk).
- Er zijn 2 TCP sessies (bronpoort 3171 en 3172) die niet kunnen worden ingesteld. De bronclient voert de TCP SYN-pakketten opnieuw uit. Deze opnieuw verzonden pakketten worden door de Wireshark geïdentificeerd als TCP-terugzendingen.
- TCP-terugzending vindt elke ~3, 6 etc. seconden plaats
- Het bron MAC adres is van het juiste stroomafwaarts apparaat.
Op basis van de twee opnamen kan worden geconcludeerd dat:
- Een pakket van een specifiek 5-voudig (src/dst IP, src/dst poort, protocol) arriveert in de firewall op de verwachte interface (INSIDE).
- Een pakket laat de firewall niet op de verwachte interface (BUITEN) staan.
Aanbevolen acties
De in deze paragraaf genoemde acties hebben tot doel de kwestie verder te beperken.
Actie 1. Controleer het spoor van een geëmuleerd pakket.
Gebruik het pakje-tracer gereedschap om te zien hoe een pakje door de firewall moet worden verwerkt. Heeft het pakket een knip gekregen in het firewalltoegangsbeleid, dan lijkt het overtrekken van het emulation-pakket op deze uitvoer:
firepower# packet-tracer input INSIDE tcp 192.168.0.100 11111 10.10.1.100 80 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Phase: 4 Type: ACCESS-LIST Subtype: log Result: DROP Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268439946 event-log flow-start access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE Additional Information: Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA
Actie 2. Controleer de sporen van actieve pakketten.
Schakel het pakkettransport in om te controleren hoe de echte TCP SYN-pakketten worden verwerkt door de firewall. Standaard worden alleen de eerste 50 ingangspakketten overgetrokken:
firepower# capture CAPI trace
Opname-buffer wissen:
firepower# clear capture /all
Heeft u een pakketfilter dat door het toegangsbeleid van de firewall is gevallen, dan lijkt de overtrek op deze uitvoer:
firepower# show capture CAPI packet-number 1 trace 6 packets captured 1: 12:45:36.279740 192.168.0.100.3630 > 10.10.1.100.80: S 2322685377:2322685377(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Phase: 4 Type: ACCESS-LIST Subtype: log Result: DROP Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268439946 event-log flow-start access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE Additional Information: Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA 1 packet shown
Actie 3. Controleer FTD Lina logs.
U kunt Syslog op FTD configureren via FMC van dit document:
Het wordt ten zeerste aanbevolen om een externe Syrische server voor FTD Lina-logbestanden te laten configureren. Als er geen op afstand gebaseerde Syslg-server is geconfigureerd, schakelt u de lokale bufferbestanden in in de firewall terwijl u een probleem hebt met de oplossing. De logconfiguratie die in dit voorbeeld wordt getoond, is een goed startpunt:
firepower# show run logging … logging enable logging timestamp logging buffer-size 1000000 logging buffered informational
Stel de terminalpagina in op 24 lijnen om de terminalpagina te besturen:
firepower# terminal pager 24
Opname-buffer wissen:
firepower# clear logging buffer
Test de verbinding en controleer de logbestanden met een parser filter. In dit voorbeeld worden de pakketten vervangen door het toegangsbeleid voor firewalls:
firepower# show logging | include 10.10.1.100 Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]
Actie 4. Controleer de afdruppels van de firewall ASP.
Als u vermoedt dat het pakket door de firewall is gevallen, kunt u de tellers van alle pakketten zien die door de firewall op softwarecliveau zijn gevallen:
firepower# show asp drop Frame drop: No route to host (no-route) 234 Flow is denied by configured rule (acl-drop) 71 Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15 Flow drop: Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15
U kunt opnamen mogelijk maken om alle ASIS software-level-druppels te zien:
firepower# capture ASP type asp-drop all buffer 33554432 headers-only
Om de inhoud van de opname te controleren, kunt u een filter gebruiken om uw zoekopdracht te vernauwen:
firepower# show capture ASP | include 10.10.1.100 18: 07:51:57.823672 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 19: 07:51:58.074291 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 26: 07:52:00.830370 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 29: 07:52:01.080394 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 45: 07:52:06.824282 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,nop,sackOK> 46: 07:52:07.074230 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,nop,sackOK>
In dit geval, aangezien de pakketten reeds op interfaceniveau worden getraceerd, wordt de reden voor de daling niet vermeld in de ASP-opname. Onthoud dat een pakje slechts op één plaats kan worden overgetrokken (ingress interface of ASP-druppel). In dat geval wordt aanbevolen meerdere ASP-druppels in te nemen en een specifieke ASP-druppelreden te geven. Hier volgt een aanbevolen benadering:
1. Wis de huidige ASP-druppelteller:
firepower# clear asp drop
2. Verzend de stroom die u problemen oplossen door de firewall (voer een test uit).
3. Controleer opnieuw de aftellers van de ASP en noteer deze meer, bijvoorbeeld
firepower# show asp drop Frame drop: No route to host (no-route) 234 Flow is denied by configured rule (acl-drop) 71
4. Schakel ASP-opname(s) in voor de waargenomen specifieke druppels:
firepower# capture ASP_NO_ROUTE type asp-drop no-route firepower# capture ASP_ACL_DROP type asp-drop acl-drop
5. Verzend de stroom die u problemen oplossen door de firewall (voer een test uit).
6. Controleer de ASP-opname. In dit geval werden de pakketten vanwege een ontoereikende route verzonden:
firepower# show capture ASP_NO_ROUTE | include 192.168.0.100.*10.10.1.100 93: 07:53:52.381663 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 95: 07:53:52.632337 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 101: 07:53:55.375392 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 102: 07:53:55.626386 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 116: 07:54:01.376231 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,nop,sackOK> 117: 07:54:01.626310 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,nop,sackOK>
Actie 5. Controleer de FTD Lina aansluitingstabel.
Er kunnen gevallen zijn waarin je verwacht dat het pakje interface 'X' zal belemmeren, maar om welke reden dan ook wordt 'Y' genoemd. De vaststelling van de interface voor firewalls is gebaseerd op deze volgorde van exploitatie:
- Vaste verbindingsaccount
- NAT-lookup (Network Address Translation) - UN-NAT (bestemmings-NAT) fase krijgt voorrang op PBR-systemen en routeswitches.
- Op beleid gebaseerde routing (PBR)
- Uitzicht routingtabel
U kunt de FTD-verbindingstabel als volgt controleren:
firepower# show conn
2 in use, 4 most used
Inspect Snort:
preserve-connection: 2 enabled, 0 in effect, 4 most enabled, 0 most in effect
TCP DMZ 10.10.1.100:80 INSIDE 192.168.0.100:11694, idle 0:00:01, bytes 0, flags aA N1
TCP DMZ 10.10.1.100:80 INSIDE 192.168.0.100:11693, idle 0:00:01, bytes 0, flags aA N1
Belangrijkste punten:
- Gebaseerd op de vlaggen (a) is de verbinding embryonaal (half geopend - slechts TCP SYN werd gezien door de firewall).
- Gebaseerd op de bron-/doelpoorten is de ingangsinterface INSIDE en de ress interface is DMZ.
U kunt dit in de afbeelding hier zien:
firepower# show interface detail | i Interface number is|Interface [P|E].*is up
...
Interface Ethernet1/2 "INSIDE", is up, line protocol is up
Interface number is 19
Interface Ethernet1/3.202 "OUTSIDE", is up, line protocol is up
Interface number is 20
Interface Ethernet1/3.203 "DMZ", is up, line protocol is up
Interface number is 22
Uitvoer 1:
firepower# show conn long ... TCP OUTSIDE: 192.168.2.200/80 (192.168.2.200/80) INSIDE: 192.168.1.100/46050 (192.168.1.100/46050), flags aA N1, idle 3s, uptime 6s, timeout 30s, bytes 0 Initiator: 192.168.1.100, Responder: 192.168.2.200 Connection lookup keyid: 228982375
Uitvoer 2:
firepower# show conn detail
...
TCP OUTSIDE: 192.168.2.200/80 INSIDE: 192.168.1.100/46050,
flags aA N1, idle 4s, uptime 11s, timeout 30s, bytes 0
Initiator: 192.168.1.100, Responder: 192.168.2.200
Connection lookup keyid: 228982375
Daarnaast worden in de show long de NATed IP’s binnen een parenthese weergegeven in het geval van een netwerkadresomzetting:
firepower# show conn long ... TCP OUTSIDE: 192.168.2.222/80 (192.168.2.222/80) INSIDE: 192.168.1.100/34792 (192.168.2.150/34792), flags aA N1, idle 0s, uptime 0s, timeout 30s, bytes 0, xlate id 0x2b5a8a4314c0 Initiator: 192.168.1.100, Responder: 192.168.2.222 Connection lookup keyid: 262895
Actie 6. Controleer het ARP-cache (Firewalladresoplossing Protocol).
Als de firewall de volgende hop niet kan oplossen, laat de firewall stilletjes het originele pakket (TCP SYN in dit geval) vallen en verstuurt continu ARP Verzoeken tot het de volgende hop oplost.
Gebruik de opdracht om de firewall ARP cache te zien:
firepower# show arp
Daarnaast kunt u deze opdracht gebruiken om te controleren of er onopgeloste hosts zijn:
firepower# show arp statistics
Number of ARP entries in ASA: 0
Dropped blocks in ARP: 84
Maximum Queued blocks: 3
Queued blocks: 0
Interface collision ARPs Received: 0
ARP-defense Gratuitous ARPS sent: 0
Total ARP retries: 182 < indicates a possible issue for some hosts
Unresolved hosts: 1 < this is the current status
Maximum Unresolved hosts: 2
Als u de ARP-handeling verder wilt controleren, kunt u een ARP-specifieke opname inschakelen:
firepower# capture ARP ethernet-type arp interface OUTSIDE firepower# show capture ARP ... 4: 07:15:16.877914 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50 5: 07:15:18.020033 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50
In deze output probeert de firewall (192.168.2.50) de volgende-hop op te lossen (192.168.2.72), maar er is geen ARP-antwoord
De output hier toont een functioneel scenario met juiste ARP-resolutie:
firepower# show capture ARP 2 packets captured 1: 07:17:19.495595 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50 2: 07:17:19.495946 802.1Q vlan#202 P0 arp reply 192.168.2.72 is-at 4c:4e:35:fc:fc:d8 2 packets shown
firepower# show arp
INSIDE 192.168.1.71 4c4e.35fc.fcd8 9
OUTSIDE 192.168.2.72 4c4e.35fc.fcd8 9
Heeft u geen ARP-ingang, dan geeft u een spoor van een levend TCP SYN-pakket weer:
firepower# show capture CAPI packet-number 1 trace 6 packets captured 1: 07:03:43.270585 192.168.0.100.11997 > 10.10.1.100.80: S 4023707145:4023707145(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE … Phase: 14 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 4814, packet dispatched to next module … Phase: 17 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: allow
Zoals in de output te zien is, toont het spoor Actie: laat zelfs toe wanneer de volgende hop niet bereikbaar is en het pakket stilletjes door de firewall wordt gedropt! In dit geval moet ook het pakje-tracer-gereedschap worden gecontroleerd omdat het een nauwkeuriger uitvoer biedt:
firepower# packet-tracer input INSIDE tcp 192.168.0.100 1111 10.10.1.100 80 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE … Phase: 14 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 4816, packet dispatched to next module … Phase: 17 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (no-v4-adjacency) No valid V4 adjacency, Drop-location: frame 0x00005647a4e86109 flow (NA)/NA
In recente ASA/Firepower versies is het bovenstaande bericht geoptimaliseerd voor:
Drop-reason: (no-v4-adjacency) No valid V4 adjacency. Check ARP table (show arp) has entry for nexthop., Drop-location: f
Samenvatting van mogelijke oorzaken en aanbevolen acties
Als u alleen een TCP SYN-pakket op de ingangsinterfaces ziet, maar geen TCP SYN-pakket dat uit de verwachte spanning-interface wordt verzonden, zijn een aantal mogelijke oorzaken:
| Mogelijke oorzaak |
Aanbevolen acties |
| Het pakket wordt ingetrokken door het toegangsbeleid voor firewalls. |
|
| Het opnamefilter is onjuist. |
|
| Het pakje wordt naar een andere accu verzonden. |
Als het pakket naar een verkeerde interface wordt verzonden omdat het overeenkomt met een bestaande verbinding, gebruikt u het opdracht duidelijke adres en specificeert u het 5-voud van de verbinding dat u wilt wissen. |
| Er is geen weg naar de bestemming. |
|
| Er is geen ARP ingang op de uitgang interface. |
|
| De spanning interface is omlaag. |
Controleer de uitvoer van het IP-opdracht van de show-interface in de firewall en controleer de interfacestatus. |
Case 2. TCP SYN vanaf client-TCP RST vanaf server
Dit beeld toont de topologie:
Beschrijving van probleem: HTTP werkt niet
Betrokken stroom:
SRC IP: 192.168.0.100
DT IP: 10.10.1.100
Protocol: TCP 80
Capture Analysis
Opname op de FTD LINA-motor inschakelen.
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
Captures - niet-functioneel scenario:
Vanaf het apparaat CLI zien de opnamen er als volgt uit:
firepower# show capture capture CAPI type raw-data trace interface INSIDE [Capturing - 834 bytes] match ip host 192.168.0.100 host 10.10.1.100 capture CAPO type raw-data interface OUTSIDE [Capturing - 878 bytes] match ip host 192.168.0.100 host 10.10.1.100
CAPI-inhoud:
firepower# show capture CAPI 1: 05:20:36.654217 192.168.0.100.22195 > 10.10.1.100.80: S 1397289928:1397289928(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 05:20:36.904311 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 05:20:36.905043 10.10.1.100.80 > 192.168.0.100.22196: R 1850052503:1850052503(0) ack 2171673259 win 0 4: 05:20:37.414132 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 05:20:37.414803 10.10.1.100.80 > 192.168.0.100.22196: R 31997177:31997177(0) ack 2171673259 win 0 6: 05:20:37.914183 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,nop,sackOK> ...
CAPO-inhoud:
firepower# show capture CAPO 1: 05:20:36.654507 802.1Q vlan#202 P0 192.168.0.100.22195 > 10.10.1.100.80: S 2866789268:2866789268(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 2: 05:20:36.904478 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4785344:4785344(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 3: 05:20:36.904997 802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4785345 win 0 4: 05:20:37.414269 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4235354730:4235354730(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 5: 05:20:37.414758 802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4235354731 win 0 6: 05:20:37.914305 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4118617832:4118617832(0) win 8192 <mss 1380,nop,nop,sackOK>
Deze afbeelding toont de opname van CAPI in Wireshark.
Belangrijkste punten:
- De bron stuurt een TCP SYN-pakket.
- Een TCP RST wordt naar de bron verzonden.
- De bron geeft de TCP SYN-pakketten opnieuw over.
- De adressen van MAC zijn correct (op ingress pakketten behoort het bron-MAC-adres tot de downstreamrouter, het doeladres van MAC tot de firewall-interface INSIDE).
Deze afbeelding toont de opname van CAPO in Wireshark:
Belangrijkste punten:
- De bron stuurt een TCP SYN-pakket.
- Een TCP RST arriveert op de BUITENinterface.
- De bron geeft de TCP SYN-pakketten opnieuw over.
- De MAC-adressen zijn correct (op IP-pakketten is de firewall BUITEN de bron MAC, de upstream-router de bestemming MAC).
Op basis van de twee opnamen kan worden geconcludeerd dat:
- De TCP 3-handdruk tussen de client en de server wordt niet voltooid
- Er is een TCP RST die op de interface van het firewallbereik aankomt
- De firewall 'praat' met de juiste upstream- en downstreamapparaten (gebaseerd op de MAC-adressen)
Aanbevolen acties
De in deze paragraaf genoemde acties hebben tot doel de kwestie verder te beperken.
Handeling 1. Controleer het bron-MAC-adres dat TCP RST verstuurt.
Controleer dat de bestemming MAC die in het TCP SYN-pakket is gezien, hetzelfde is als de bron MAC die in het TCP RST-pakket is gezien.
Deze controle heeft als doel twee dingen te bevestigen:
- Controleer dat er geen asymmetrische stroom is.
- Controleer dat de MAC tot het verwachte stroomopwaarts apparaat behoort.
Actie 2. Vergelijk instap- en spanningspakketten.
Vergelijk visueel de 2 pakketten op Wireshark om te controleren dat de firewall de pakketten niet aanpast/corrupt is. Er wordt gewezen op een aantal verwachte verschillen.
Belangrijkste punten:
- Time-postzegels zijn anders. Anderzijds moet het verschil klein en redelijk zijn. Dit hangt af van de functies en de beleidscontroles die op het pakket en de lading op het apparaat worden toegepast.
- De lengte van de pakketten kan anders zijn, vooral als er een punt1Q header is toegevoegd of verwijderd door de firewall op één kant.
- De MAC-adressen zijn anders.
- Een punt1Q-header kan worden gebruikt als de opname op een subinterface is uitgevoerd.
- Het IP-adres(en) is (zijn) anders voor het geval NAT of Port Address Translation (PAT) op het pakje wordt toegepast.
- De bron- of doelpoorten zijn anders voor het geval dat NAT of PAT op het pakket is toegepast.
- Als u de optie Relatief Volgnummer Wireshark uitschakelt, ziet u dat de TCP-sequentienummers/ontvangstnummers worden gewijzigd door de firewall vanwege de initiële sequentienummer (ISN) randomisatie.
- Sommige TCP-opties kunnen worden overschreven. Bijvoorbeeld, verandert de firewall het TCP Maximum Segment Size (MSS) in 1380 om pakketfragmentatie in het doorvoerpad te voorkomen.
Actie 3. Neem een opname op de plaats van bestemming.
Neem indien mogelijk een opname op de bestemming zelf. Als dit niet mogelijk is, neem dan een opname die zo dicht mogelijk bij de bestemming ligt. Het doel is om te verifiëren wie de TCP RST verstuurt (is de doelserver of is een ander apparaat in het pad?).
Case 3. TCP-handdruk + RST vanaf één endpoint
Dit beeld toont de topologie:
Beschrijving van probleem: HTTP werkt niet
Betrokken stroom:
SRC IP: 192.168.0.100
DT IP: 10.10.1.100
Protocol: TCP 80
Capture Analysis
Opname op de FTD LINA-motor inschakelen.
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
Captures - niet-functioneel scenario:
Er zijn een paar verschillende manieren waarop deze kwestie zich kan manifesteren in gevangenissen.
3.1 - TCP-handdruk + vertraagde RST vanaf de client
Zowel de firewall CAPI als de CAPO bevatten dezelfde pakketten, zoals in de afbeelding wordt getoond.
Belangrijkste punten:
- De TCP 3-handdruk gaat door de firewall.
- De server zendt SYN/ACK opnieuw uit.
- De cliënt geeft de ACK terug.
- Na ~20 seconden geeft de client op en stuurt hij een TCP RST.
Aanbevolen acties
De in deze paragraaf genoemde acties hebben tot doel de kwestie verder te beperken.
Actie 1. Maak zo dicht mogelijk bij de twee eindpunten.
De firewallopnamen geven aan dat de client-ACK niet door de server is verwerkt. Dit is gebaseerd op deze feiten:
- De server zendt SYN/ACK opnieuw uit.
- De cliënt geeft de ACK terug.
- De client verstuurt een TCP RST of FIN/ACK voordat er gegevens beschikbaar zijn.
De opname op de server toont het probleem. De client ACK van de TCP 3-manier handdruk is nooit gearriveerd:
3.2 - TCP 3-handdruk + vertraagde FIN/ACK bij client + vertraagde RST vanaf de server
Zowel de firewall CAPI als de CAPO bevatten dezelfde pakketten, zoals in de afbeelding wordt getoond.
Belangrijkste punten:
- De TCP 3-handdruk gaat door de firewall.
- Na ongeveer 5 seconden stuurt de client een FIN/ACK.
- Na ~20 seconden geeft de server op en stuurt hij een TCP RST.
Op basis van deze opname kan worden geconcludeerd dat, alhoewel er een TCP 3-handdruk door de firewall is, deze blijkbaar nooit op één eindpunt wordt voltooid (de terugzending geeft dit aan).
Aanbevolen acties
Hetzelfde als in geval 3.1
3.3 - TCP-handdruk + vertraagde RST vanaf de client
Zowel de firewall CAPI als de CAPO bevatten dezelfde pakketten, zoals in de afbeelding wordt getoond.
Belangrijkste punten:
- De TCP 3-handdruk gaat door de firewall.
- Na ~20 seconden geeft de client op en stuurt hij een TCP RST.
Op basis van deze opnamen kan worden geconcludeerd dat:
- Na 5-20 seconden geeft één eindpunt op en besluit de verbinding te beëindigen.
Aanbevolen acties
Hetzelfde als in geval 3.1
3.4 - TCP-handdruk + onmiddellijke RST vanaf de server
Beide firewalls bevatten deze pakketten, zoals in de afbeelding, CAPI en CAPO.
Belangrijkste punten:
- De TCP 3-handdruk gaat door de firewall.
- Er is een TCP RST van de server een paar milliseconden na het ACK-pakket.
Aanbevolen acties
Actie: Neem opnamen zo dicht mogelijk bij de server.
Een onmiddellijke TCP RST van de server kon op een defecte server of een apparaat in het pad wijzen dat de TCP RST verstuurt. Neem een opname op de server zelf en bepaalt de bron van de TCP RST.
Case 4. TCP RST van de client
Dit beeld toont de topologie:
Probleembeschrijving: HTTP werkt niet.
Betrokken stroom:
SRC IP: 192.168.0.100
DT IP: 10.10.1.100
Protocol: TCP 80
Capture Analysis
Opname op FTD LINA-motor inschakelen.
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
Captures - niet-functioneel scenario:
Dit zijn de CAPI-inhoud.
firepower# show capture CAPI 14 packets captured 1: 12:32:22.860627 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 12:32:23.111307 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 12:32:23.112390 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 4: 12:32:25.858109 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 12:32:25.868698 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 6: 12:32:26.108118 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 7: 12:32:26.109079 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 8: 12:32:26.118295 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 9: 12:32:31.859925 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,nop,sackOK> 10: 12:32:31.860902 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 11: 12:32:31.875229 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 12: 12:32:32.140632 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 13: 12:32:32.159995 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,nop,sackOK> 14: 12:32:32.160956 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 14 packets shown
Dit zijn de CAPO-inhoud:
firepower# show capture CAPO 11 packets captured 1: 12:32:22.860780 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 2: 12:32:23.111429 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3000518857:3000518857(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 3: 12:32:23.112405 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 3514091874:3514091874(0) win 0 4: 12:32:25.858125 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 5: 12:32:25.868729 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 2968892337:2968892337(0) win 0 6: 12:32:26.108240 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3822259745:3822259745(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 7: 12:32:26.109094 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 40865466:40865466(0) win 0 8: 12:32:31.860062 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 4294058752:4294058752(0) win 8192 <mss 1380,nop,nop,sackOK> 9: 12:32:31.860917 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 1581733941:1581733941(0) win 0 10: 12:32:32.160102 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 4284301197:4284301197(0) win 8192 <mss 1380,nop,nop,sackOK> 11: 12:32:32.160971 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 502906918:502906918(0) win 0 11 packets shown
De firewalllogbestanden tonen:
firepower# show log | i 47741 Oct 13 2019 13:57:36: %FTD-6-302013: Built inbound TCP connection 4869 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:36: %FTD-6-302014: Teardown TCP connection 4869 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE Oct 13 2019 13:57:39: %FTD-6-302013: Built inbound TCP connection 4870 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:39: %FTD-6-302014: Teardown TCP connection 4870 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE Oct 13 2019 13:57:45: %FTD-6-302013: Built inbound TCP connection 4871 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:45: %FTD-6-302014: Teardown TCP connection 4871 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE
Deze logboeken geven aan dat er een TCP RST is die op firewall INSIDE-interface aankomt
CAPI-opname in draadloos:
Volg de eerste TCP stream, zoals getoond in de afbeelding.
Onder Wireshark, navigeer om > Voorkeuren > Protocols > TCP te bewerken en deselecteer de Relatieve sequentienummers zoals in de afbeelding weergegeven.
Deze afbeelding toont de inhoud van de eerste stroom in de CAPI-opname:
Belangrijkste punten:
- De client stuurt een TCP SYN-pakket.
- De client stuurt een TCP RST-pakket.
- Het TCP SYN-pakket heeft een waarde van het sequentienummer die gelijk is aan 4098574664.
Dezelfde stroom in CAPO-opname bevat:
Belangrijkste punten:
- De client stuurt een TCP SYN-pakket. De firewall willekeurig ISN.
- De client stuurt een TCP RST-pakket.
Op basis van de twee opnamen kan worden geconcludeerd dat:
- Er is geen TCP 3-manier handdruk tussen de client en de server.
- Er is een TCP RST die van de cliënt komt. De waarde van het TCP RST-sequentienummer in CAPI-opname is 1386249853.
Aanbevolen acties
De in deze paragraaf genoemde acties hebben tot doel de kwestie verder te beperken.
Handeling 1. Vul de cliënt in.
Gebaseerd op de opnamen die op de firewall zijn verzameld is er een sterke aanwijzing van een asymmetrische stroom. Dit is gebaseerd op het feit dat de klant een TCP RST met een waarde van 1386249853 (het gerandomiseerde ISN) verstuurt:
Belangrijkste punten:
- De client stuurt een TCP SYN-pakket. Het sequentienummer is 4098574664 en is hetzelfde als het nummer dat wordt gezien op INSIDE-interface (CAPI) met firewall
- Er is een TCP SYN/ACK met ACK-nummer 1386249853 (wat verwacht wordt door ISDN-randomisatie). Dit pakket is niet gezien in de firewallopname
- De klant stuurt een TCP-RST omdat hij een SYN/ACK had verwacht met ACK-waarde van 4098574665, maar de waarde van 1386249853
Dit kan als volgt worden gevisualiseerd:
Actie 2. Controleer de routing tussen de client en de firewall.
Bevestig dat:
- De MAC-adressen die in de Captures worden gezien, zijn de verwachte adressen.
- Zorg ervoor dat de routing tussen de firewall en de client symmetrisch is.
Er zijn scenario's waar RST van een apparaat komt dat tussen de firewall en de client zit terwijl er een asymmetrische routing in het interne netwerk is. In de afbeelding wordt een typisch geval weergegeven:
In dit geval heeft de opname deze inhoud. Merk het verschil op tussen het bron-MAC-adres van het TCP-SYN-pakket en het bron-MAC-adres van de TCP-RST en het doeladres van het TCP-SYN/ACK-pakket:
firepower# show capture CAPI detail
1: 13:57:36.730217 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66
192.168.0.100.47740 > 10.10.1.100.80: S [tcp sum ok] 3045001876:3045001876(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25661)
2: 13:57:36.981104 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66
192.168.0.100.47741 > 10.10.1.100.80: S [tcp sum ok] 3809380540:3809380540(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25662)
3: 13:57:36.981776 00be.75f6.1dae a023.9f92.2a4d 0x0800 Length: 66
10.10.1.100.80 > 192.168.0.100.47741: S [tcp sum ok] 1304153587:1304153587(0) ack 3809380541 win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK> (DF) (ttl 127, id 23339)
4: 13:57:36.982126 a023.9f92.2a4d 00be.75f6.1dae 0x0800 Length: 54
192.168.0.100.47741 > 10.10.1.100.80: R [tcp sum ok] 3809380541:3809380541(0) ack 1304153588 win 8192 (ttl 255, id 48501)
...
Case 5. Trage TCP-overdracht (scenario 1)
Beschrijving van probleem:
SFTP-overdracht tussen hosts 10.11.4.171 en 10.7.19.11 is traag. Hoewel de minimum bandbreedte (BW) tussen de 2 hosts 100 Mbps is, gaat de overdrachtsnelheid niet verder dan 5 Mbps.
Tegelijkertijd is de overdrachtssnelheid tussen hosts 10.11.2.124 en 172.25.18.134 veel hoger.
Achtergrondinformatie:
De maximum overdrachtsnelheid voor één enkele TCP-stroom wordt bepaald door het Bandwidth Delay Product (BDP). De gebruikte formule wordt in de afbeelding getoond:
Kijk hier voor meer informatie over het BDP op de bronnen:
- Waarom gebruikt uw toepassing slechts 10 Mbps zelfs de link 1 Gbps?
- BRK-SEC-3021 - geavanceerde - optimaliserende firewallprestaties
Scenario 1. Langzame overdracht
Dit beeld toont de topologie:
Betrokken stroom:
SRC IP: 10.11.4.171
DT IP: 10.77.19.11
Protocol: SFTP (FTP over SSH)
Capture Analysis
Opname op FTD LINA-motor inschakelen:
firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11 firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11
firepower# capture CAPI type raw-data trace interface inside match icmp any any WARNING: Running packet capture can have an adverse impact on performance.
Aanbevolen acties
De in deze paragraaf genoemde acties hebben tot doel de kwestie verder te beperken.
Ronde Trip Time (RTT) Berekening
Geef eerst de overdrachtsstroom op en volg deze:
Verander de weergave van het draadloze venster om de seconden weer te geven sinds het vorige weergegeven pakket. Dit vergemakkelijkt de berekening van de RTT:
De RTT kan worden berekend door de tijdwaarden tussen twee pakketuitwisselingen (één naar de bron en één naar de bestemming) toe te voegen. In dit geval toont pakket #2 RTT tussen de firewall en het apparaat dat het SYN/ACK-pakket (server) heeft verzonden. Packet #3 toont RTT tussen de firewall en het apparaat dat het ACK-pakket (client) heeft verzonden. De toevoeging van de 2 getallen biedt een goede schatting van de end-to-end RTT:
RTT heuvel 80 msec
TCP-vensterberekening
Vouw een TCP-pakket uit, breid de TCP-header uit, selecteer Geschatte venstergrootte en selecteer Toepassen als kolom:
Controleer de kolom Calculated venster size om te zien wat de maximum venstergrootte tijdens de TCP sessie was. U kunt ook de kolom naam selecteren en de waarden sorteren.
Als u een bestand download (server > client) test, moet u de door de server geadverteerde waarden controleren. De maximum waarde van de venstergrootte die door de server wordt geadverteerd bepaalt de maximale overboekingssnelheid die wordt bereikt.
In dit geval is de grootte van het TCP-venster heuvelig tot 50000 bytes
Gebaseerd op deze waarden en met het gebruik van de productformule van de Bandbreedtevertraging krijg u de maximale theoretische bandbreedte die onder deze omstandigheden kan worden bereikt: 5000*8/0,08 = 5 Mbps maximale theoretische bandbreedte.
Dit komt overeen met wat de klant in dit geval ervaart.
Controleer de TCP 3-handdruk nauwkeurig. Beide kanten, en nog belangrijker de server, adverteren met een waarde van de venster van 0, wat 2^0 = 1 (geen venster schalen) betekent. Dit beïnvloedt het overdrachtspercentage negatief:
Op dit punt is het nodig om een opname op de server te maken, bevestig dat het degene is die venster schaal = 0 adverteert en stel het dan opnieuw in (u zou de serverdocumentatie kunnen moeten controleren hoe dit te doen).
Scenario 2. Snelle overdracht
Laten we nu het goede scenario onderzoeken (snelle overdracht via hetzelfde netwerk):
Topologie:
Rentestroom:
SRC IP: 10.11.2.124
DT IP: 172.25.18.134
Protocol: SFTP (FTP over SSH)
Opname op FTD LINA-motor inschakelen
firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134 firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134
Ronde Trip Time (RTT) Berekening: In dit geval is RTT ongeveer 300 msec.
Berekening van TCP-venstergrootte: De server adverteert met een TCP venster schaal factor 7.
De TCP-venstergrootte van de server is ongeveer 1600000 bytes:
Op basis van deze waarden geeft de productformule van de Bandbreedteswitch Delay:
160000*8/0,3 = 43 Mbps maximale theoretische overdrachtsnelheid
Case 6. Trage TCP-overdracht (scenario 2)
Beschrijving van probleem: FTP-bestandsoverdracht (download) door de firewall is traag.
Deze foto toont de Topologie:
Betrokken stroom:
SRC IP: 192.168.2.220
DT IP: 192.168.1.220
Protocol: FTP
Capture Analysis
Opname op de FTD LINA-motor inschakelen.
firepower# capture CAPI type raw-data buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 firepower# cap CAPO type raw-data buffer 33554432 interface OUTSIDE match tcp host 192.168.2.220 host 192.168.1.220
Selecteer een FTP-DATA-pakket en volg het FTP Data Channel op FTD INSIDE Capture (CAPI):
De inhoud van de FTP-DATA-stream:
De inhoud van de CAPO:
Belangrijkste punten:
- Er zijn TCP Out-Order (OO)-pakketten.
- Er is een TCP-terugzending.
- Er is een indicatie van het verlies van een pakje (verzonden pakketten).
Aanbevolen acties
De in deze paragraaf genoemde acties hebben tot doel de kwestie verder te beperken.
Actie 1. Identificeer de locatie van het pakketverlies.
In gevallen als deze moet u simultane opnamen nemen en de verdeel- en veroveringsmethode gebruiken om het(de) netwerksegment(s) te identificeren die pakketverlies veroorzaakt. Vanuit het oogpunt van firewalls zijn er drie hoofdscenario's:
- Het pakketverlies wordt veroorzaakt door de firewall zelf.
- Het pakketverlies wordt stroomafwaarts veroorzaakt naar het firewallapparaat (richting van server naar client).
- Het pakketverlies wordt stroomopwaarts naar het firewallapparaat (richting van de client naar de server) veroorzaakt.
Packet-verlies veroorzaakt door de firewall: Om te identificeren of het pakketverlies wordt veroorzaakt door de firewall is het nodig om de invoeropname te vergelijken met de stress-opname. Er zijn heel veel manieren om twee verschillende opnamen te vergelijken. Dit deel laat één manier zien om deze taak te vervullen.
Procedure om 2 Captures te vergelijken om het pakketverlies te identificeren
Stap 1. Zorg ervoor dat de 2 opnamen pakketten uit hetzelfde venster bevatten. Dit betekent dat er geen pakketten in de ene opname zijn opgenomen die voor of na de andere opname werden opgenomen. Hier zijn een paar manieren voor:
- Controleer de eerste en de laatste IP-identificatiewaarden (ID) van het pakket.
- Controleer de waarden voor het eerste en het laatste pakje tijd.
In dit voorbeeld kunt u zien dat de eerste pakketten van elke opname dezelfde IP-ID-waarden hebben:
Indien zij niet hetzelfde zijn, dan:
- Vergelijk de timestamps van het eerste pakket van elke opname.
- Vanaf de opname met de nieuwste tijdstempel krijg je een filter vanuit deze functie en verander het Tijdstempel filter van == naar >= (het eerste pakket) en <= (het laatste pakket), bijvoorbeeld:
(frame.time >= "16 okt. 2019 16:13:43.244692000") en (frame.time <= "16 okt. 2019 16:20:21.7851300 0")
3. Exporteren de gespecificeerde pakketten naar een nieuwe opname, selecteer Bestand > Opgegeven pakketten exporteren en slaan vervolgens de weergegeven pakketten op. Op dit punt moeten beide opnames pakketten pakketten bevatten die het zelfde venster omvatten. U kunt nu beginnen met de vergelijking van de twee opnamen.
Stap 2. Specificeer welk pakketveld wordt gebruikt voor de vergelijking tussen de 2 opnamen. Voorbeeld van velden die kunnen worden gebruikt:
- IP-identificatie
- RTP-sequentienummer
- ICMP-sequentienummer
Maak een tekstversie van elke opname die het veld voor elk pakket bevat dat u in stap 1 hebt gespecificeerd. Laat om dit te doen alleen de belangenkolom achter, bijvoorbeeld als u pakketten wilt vergelijken op basis van IP-identificatie, dan pas de opname aan zoals in de afbeelding.
Het resultaat:
Stap 3. Maak een tekstversie van de opname (Bestand > Verscheidingen van uitvoeringspakket > Zoals duidelijke tekst...) zoals in de afbeelding:
Schakel de opties kop-kolom en pakketdetails uit om alleen de waarden van het weergegeven veld uit te voeren, zoals in de afbeelding:
Stap 4. Sorteer de pakketten in de bestanden. U kunt de Linux sorteren opdracht gebruiken om dit te doen:
# sort CAPI_IDs > file1.sorted # sort CAPO_IDs > file2.sorted
Stap 5. Gebruik een tekstvergelijkingsgereedschap (bijvoorbeeld WinMerge) of de Linux-diff-opdracht om de verschillen tussen de 2 opnamen te vinden.
In dit geval zijn de CAPI- en CAPO-opname voor het FTP-gegevensverkeer identiek. Dit bewijst dat het pakketverlies niet door de firewall is veroorzaakt.
Identificeer upstream/downstream pakketverlies.
Belangrijkste punten:
1. Dit pakje is een TCP-terugzending. In het bijzonder is het een TCP SYN-pakket dat van de client naar de server wordt verzonden voor FTP-gegevens in passieve modus. Aangezien de client het pakket opnieuw opstelt en u het eerste SYN (pakket #1) kunt zien, is het pakket stroomopwaarts verloren aan de firewall.
In dit geval kan het zijn dat het SYN-pakket het op de server heeft gemaakt, maar dat het SYN/ACK-pakket op de terugweg verloren is:
2. Er is een pakket van de server en Wireshark heeft geïdentificeerd dat het vorige segment niet werd gezien/opgenomen. Aangezien het niet-opgenomen pakket van de server naar de client is verzonden en niet in de firewallopname is gezien, betekent dit dat het pakket tussen de server en de firewall is verloren.
Dit geeft aan dat er pakketverlies is tussen de FTP-server en de firewall.
Actie 2. Neem extra opnamen.
Neem extra opnamen samen met opnamen op de eindpunten. Probeer de verdeel- en verovermethode toe te passen om het problematische segment dat het pakketverlies veroorzaakt, verder te isoleren.
Belangrijkste punten:
- De ontvanger (de FTP client in dit geval) volgt de inkomende TCP sequentienummers. Als het ontdekt dat een pakje werd gemist (een verwacht sequentienummer werd overgeslagen) dan genereert het een ACK-pakket met het ACK='verwacht sequentienummer dat is overgeslagen'. In dit voorbeeld is de Ack=2224386800.
- Dup ACK veroorzaakt een TCP Fast Retmission (hertransmissie binnen 20 msec na ontvangst van een dubbele ACK).
Wat betekenen Duplicaten ACK's?
- Een paar dubbele ACK's maar geen echte terugzendingen geven aan dat er waarschijnlijk pakketten zijn die uit bestelling komen.
- Dubbele ACK's gevolgd door eigenlijke retransmissies geven aan dat er wat pakketverlies is.
Action 3. Bereken de verwerkingstijd van de firewall voor doorvoerpakketten.
Dezelfde opname op 2 verschillende interfaces toepassen:
firepower# capture CAPI buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 firepower# capture CAPI interface OUTSIDE
Exporteren de opname controleert het tijdverschil tussen ingress- vs bovengrondse pakketten
Case 7. TCP-connectiviteitsprobleem (Packet Corruption)
Beschrijving van probleem:
Draadloze client (192.168.21.193) probeert verbinding te maken met een doelserver (192.168.14.250 - HTTP) en er zijn 2 verschillende scenario's:
- Wanneer de client verbinding maakt met access point (AP) 'A' dan werkt de HTTP verbinding niet.
- Wanneer de client verbinding maakt met access point (AP) 'B' dan werkt de HTTP connectie.
Dit beeld toont de topologie:
Betrokken stroom:
SRC IP: 192.168.21.193
DT IP: 192.168.14.250
Protocol: TCP 80
Capture Analysis
Opname op FTD LINA-motor inschakelen:
firepower# capture CAPI int INSIDE match ip host 192.168.21.193 host 192.168.14.250 firepower# capture CAPO int OUTSIDE match ip host 192.168.21.193 host 192.168.14.250
Captures - functioneel scenario:
Als basislijn is het altijd erg nuttig om opnamen te hebben van een werkscenario.
Deze afbeelding toont de opname die is uitgevoerd op de NGFW INSIDE-interface
Deze afbeelding toont de opname die is uitgevoerd op NGFW BUITEN de interface.
Belangrijkste punten:
- De 2 opnamen zijn bijna identiek (zie de ISDN-randomisatie).
- Er zijn geen aanwijzingen voor een verlies van de verpakking.
- Geen out-of-order (OO) pakketten
- Er zijn 3 HTTP GET aanvragen. De eerste krijgt een 404 ‘Not Found’, de tweede krijgt een 200 ‘OK’ en de derde krijgt een 304 ‘Not Modified’ (niet gewijzigd) omleidingsbericht.
Capture - non-working scenario:
De inhoud van de ingangsopname (CAPI).
Belangrijkste punten:
- Er is een TCP 3-handdruk.
- Er zijn TCP-terugzendingen en aanwijzingen van een pakketverlies.
- Er is een pakket (TCP ACK) dat door Wireshark als misvormd wordt geïdentificeerd.
Deze afbeelding toont de inhoud van de ress Capture (CAPO).
Belangrijkste punten:
De 2 opnamen zijn bijna identiek (zie de ISN-randomisatie):
- Er is een TCP 3-handdruk.
- Er zijn TCP-terugzendingen en aanwijzingen van een pakketverlies.
- Er is een pakket (TCP ACK) dat door Wireshark als misvormd wordt geïdentificeerd.
Controleer het misvormde pakje:
Belangrijkste punten:
- Het pakket is geïdentificeerd als een misvormd door Wireshark.
- Het heeft een lengte van 2 bytes.
- Er is een TCP lading van 2 Bytes.
- De lading is 4 nullen extra (00 00).
Aanbevolen acties
De in deze paragraaf genoemde acties hebben tot doel de kwestie verder te beperken.
Actie 1. Neem extra opnamen met inbegrip van opnamen op de eindpunten en probeer indien mogelijk de verdeel- en verovermethode toe te passen om de bron van de pakketcorruptie te isoleren, bijv.
In dit geval werden de 2 extra Bytes toegevoegd door de schakelaar "A" interfacestuurprogramma en de oplossing was om de schakelaar te vervangen die de corruptie veroorzaakt.
Case 8. UDP-connectiviteitsprobleem (ontbrekende pakketten)
Beschrijving van probleem: Syslog (UDP 514)-berichten worden niet gezien op de server van het doelprogramma Syslog.
Dit beeld toont de topologie:
Betrokken stroom:
SRC IP: 192.168.1.81
DT IP: 10.10.1.73
Protocol: UDP 514
Capture Analysis
Opname op FTD LINA-motor inschakelen:
firepower# capture CAPI int INSIDE trace match udp host 192.168.1.81 host 10.10.1.73 eq 514 firepower# capture CAPO int OUTSIDE match udp host 192.168.1.81 host 10.10.1.73 eq 514
FTD Captures tonen geen pakketten:
firepower# show capture capture CAPI type raw-data trace interface INSIDE [Capturing - 0 bytes] match udp host 192.168.1.81 host 10.10.1.73 eq syslog capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes] match udp host 192.168.1.81 host 10.10.1.73 eq syslog
Aanbevolen acties
De in deze paragraaf genoemde acties hebben tot doel de kwestie verder te beperken.
Actie 1. Controleer de FTD-verbindingstabel.
U kunt een specifieke verbinding controleren met deze syntaxis:
firepower# show conn address 192.168.1.81 port 514
10 in use, 3627189 most used
Inspect Snort:
preserve-connection: 6 enabled, 0 in effect, 74 most enabled, 0 most in effect
UDP INSIDE 10.10.1.73:514 INSIDE 192.168.1.81:514, idle 0:00:00, bytes 480379697, flags -oN1
Belangrijkste punten:
- De ingang en de spanning interfaces zijn hetzelfde (draaien om het draaien).
- Het aantal bytes heeft een aanzienlijk grote waarde (~5 GBytes).
- De vlag "o" staat voor de stroom offload (HW accelerated flow). Dit is de reden waarom de FTD Captures geen pakketten tonen. Stroom offload wordt alleen ondersteund op 41x- en 93x-platforms. In dit geval is het apparaat een 41x.
Actie 2: Neem de opnamen op het niveau van het chassis.
Sluit aan op de FirePOWER-chassismanager en laat de opname op de ingangsinterface (E1/2 in dit geval) en backplane interfaces (E1/9 en E1/10) mogelijk zijn, zoals in de afbeelding wordt getoond:
Na enkele seconden:
Voor:
Na:
Belangrijkste punten:
- Een display filter wordt gebruikt voor het verwijderen van pakketduplicaten en het weergeven van alleen systeemdocumenten.
- Het verschil tussen de pakketten is op microseconde niveau. Dit duidt op een zeer hoog pakkettarief.
- De tijd om (TTL) te leven neemt voortdurend af. Dit duidt op een pakketlus.
Actie 3. Gebruik pakkettracer.
Aangezien de pakketten niet over de firewall LINA-motor lopen, kunt u geen bewegend spoor (opnemen met/overtrekken) uitvoeren, maar u kunt een geëluleerd pakket met pakkettracer overtrekken:
firepower# packet-tracer input INSIDE udp 10.10.1.73 514 192.168.1.81 514 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found flow with id 25350892, using existing flow Phase: 4 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Verdict: (fast-forward) fast forward this flow Phase: 5 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.1.81 using egress ifc INSIDE Phase: 6 Type: ADJACENCY-LOOKUP Subtype: next-hop and adjacency Result: ALLOW Config: Additional Information: adjacency Active next-hop mac address a023.9f92.2a4d hits 1 reference 1 Phase: 7 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: INSIDE output-status: up output-line-status: up Action: allow
Actie 4. Bevestig de FTD-routing.
Controleer de routingtabel in firewalls om te zien of er routingproblemen zijn:
firepower# show route 10.10.1.73
Routing entry for 10.10.1.0 255.255.255.0
Known via "eigrp 1", distance 90, metric 3072, type internal
Redistributing via eigrp 1
Last update from 192.168.2.72 on OUTSIDE, 0:03:37 ago
Routing Descriptor Blocks:
* 192.168.2.72, from 192.168.2.72, 0:02:37 ago, via OUTSIDE
Route metric is 3072, traffic share count is 1
Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 29/255, Hops 1
Belangrijkste punten:
- De route wijst naar de juiste spanning.
- We kregen de route een paar minuten geleden (0:02:37).
Actie 5. Bevestig de verbinding uptime.
Controleer de uptime van de verbinding om te zien wanneer deze verbinding tot stand is gebracht:
firepower# show conn address 192.168.1.81 port 514 detail
21 in use, 3627189 most used
Inspect Snort:
preserve-connection: 19 enabled, 0 in effect, 74 most enabled, 0 most in effect
Flags: A - awaiting responder ACK to SYN, a - awaiting initiator ACK to SYN,
b - TCP state-bypass or nailed,
C - CTIQBE media, c - cluster centralized,
D - DNS, d - dump, E - outside back connection, e - semi-distributed,
F - initiator FIN, f - responder FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - initiator data,
i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
k - Skinny media, L - decap tunnel, M - SMTP data, m - SIP media
N - inspected by Snort (1 - preserve-connection enabled, 2 - preserve-connection in effect)
n - GUP, O - responder data, o - offloaded,
P - inside back connection, p - passenger flow
q - SQL*Net data, R - initiator acknowledged FIN,
R - UDP SUNRPC, r - responder acknowledged FIN,
T - SIP, t - SIP transient, U - up,
V - VPN orphan, v - M3UA W - WAAS,
w - secondary domain backup,
X - inspected by service module,
x - per session, Y - director stub flow, y - backup stub flow,
Z - Scansafe redirection, z - forwarding stub flow
UDP INSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514,
flags -oN1, idle 0s, uptime 3m49s, timeout 2m0s, bytes 4801148711
Belangrijkste punt:
- De verbinding werd gevestigd ~4 minuten geleden (dit is vóór de bouw van de route Eur in de routingtabel)
Actie 6. Schakel de bestaande verbinding uit.
In dit geval passen de pakketten een gevestigde verbinding aan en worden ze naar een verkeerde interface gestuurd waardoor een lus wordt veroorzaakt. Dit komt voort uit de firewallvolgorde:
- Vaste verbindingsraadpleging (dit neemt voorrang op de globale benadering van de routingtabel).
- NAT-lookup (Network Address Translation) - UN-NAT (bestemmings-NAT) fase krijgt voorrang op PBR-systemen en routeswitches.
- Op beleid gebaseerde routing (PBR)
- Uitgebreide routingtabel
Aangezien de verbinding nooit uitkomt (de client van Syslog continu pakketten verstuurt terwijl de UDP inactiviteitstimer 2 minuten inactief is) moet de verbinding handmatig worden gewist:
firepower# clear conn address 10.10.1.73 address 192.168.1.81 protocol udp port 514 1 connection(s) deleted.
Controleer of een nieuwe verbinding tot stand is gebracht:
firepower# show conn address 192.168.1.81 port 514 detail | b 10.10.1.73.*192.168.1.81
UDP OUTSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514,
flags -oN1, idle 1m15s, uptime 1m15s, timeout 2m0s, bytes 408
Actie 7. Instellen van een zwevende-komma.
Dit is de juiste oplossing om het probleem aan te pakken en suboptimale routing te vermijden, vooral voor UDP-stromen. Navigatie naar Apparaten > Platform Instellingen > Time-outs en stel de waarde in:
U kunt meer informatie vinden over de drijvende-komma timeout in de Opdrachtreferentie:
Zaak 9. HTTPS-connectiviteitsprobleem (scenario 1)
Beschrijving van probleem: Er kan geen communicatie worden vastgesteld tussen client 192.168.201.105 en server 192.168.202.101
Dit beeld toont de topologie:
Betrokken stroom:
SRC IP: 192.168.201.111
DT IP: 192.168.202.111
Protocol: TCP 443 (HTTPS)
Capture Analysis
Opname op FTD LINA-motor inschakelen:
De IP die in de externe opname wordt gebruikt, is anders door de configuratie van het poortadres.
firepower# capture CAPI int INSIDE match ip host 192.168.201.111 host 192.168.202.111 firepower# capture CAPO int OUTSIDE match ip host 192.168.202.11 host 192.168.202.111
Deze afbeelding toont de opname die is uitgevoerd op de NGFW INSIDE-interface:
Belangrijkste punten:
- Er is een TCP 3-handdruk.
- SSL-onderhandeling start. De cliënt stuurt een bericht van Client Hallo.
- Er is een TCP ACK verzonden naar de client.
- Er is een TCP RST verzonden naar de client.
Deze afbeelding toont de opname die is uitgevoerd op NGFW BUITEN de interface.
Belangrijkste punten:
- Er is een TCP 3-handdruk.
- SSL-onderhandeling start. De cliënt stuurt een bericht van Client Hallo.
- Er worden TCP-terugzendingen verzonden vanuit de firewall naar de server.
- Er wordt een TCP RST naar de server verzonden.
Aanbevolen acties
De in deze paragraaf genoemde acties hebben tot doel de kwestie verder te beperken.
Actie 1. Neem extra foto's.
Een opname die op de server is genomen, onthult dat de server de TLS Client Hellos heeft ontvangen met gecorrumpeerde TCP-checksum en deze in stilte laat neerzetten (er is geen TCP RST of een ander antwoordpakket naar de client):
Als je alles samenstelt:
In dit geval, om te begrijpen wat er gebeurt is een noodzaak om bij Wireshark de TCP checksum indien mogelijk optie valideren in te schakelen. Navigeren in om > Voorkeuren > Protocols > TCP te bewerken, zoals in de afbeelding wordt weergegeven.
In dit geval is het handig om de opgenomen beelden naast elkaar te plaatsen voor een volledig beeld:
Belangrijkste punten:
- Er is een TCP 3-handdruk. De IP-ID’s zijn hetzelfde. Dit betekent dat de stroom niet werd onderbroken door de firewall.
- Een TLS-client-Hallo komt van de client met IP-ID 12083. Het pakket wordt door de firewall (de firewall is in dit geval ingesteld met TLS-decryptiebeleid) en de IP-ID wordt gewijzigd in 52534. Bovendien wordt de pakketTCP-checksum beschadigd (door een softwaredefect dat later is vastgesteld).
- De firewall is in de TCP Proxy-modus en stuurt een ACK naar de client (spoofing van de server).
- De firewall ontvangt geen TCP ACK-pakket van de server en geeft het bericht van de TLS-client Hallo opnieuw door. Dit is opnieuw te wijten aan de TCP Proxy-modus die de firewall heeft geactiveerd.
- Na ~30 seconden geeft de firewall het op en stuurt het een TCP RST naar de client.
- De firewall stuurt een TCP RST naar de server.
Zie voor meer informatie:
Firepower TLS/SSL-handshake Processing
Zaak 10. HTTPS-connectiviteitsprobleem (scenario 2)
Beschrijving van probleem: FMC Smart-licentieregistratie mislukt.
Dit beeld toont de topologie:
Betrokken stroom:
SRC IP: 192.168.0.100
DATUM: tools.cisco.com
Protocol: TCP 443 (HTTPS)
Capture Analysis
Opname op de FMC-beheerinterface inschakelen:
Probeer het opnieuw te registreren. Druk op CTRL-C om de opname te stoppen zodra het foutbericht verschijnt:
root@firepower:/Volume/home/admin# tcpdump -i eth0 port 443 -s 0 -w CAP.pcap HS_PACKET_BUFFER_SIZE is set to 4. tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes ^C264 packets captured <- CTRL-C 264 packets received by filter 0 packets dropped by kernel root@firepower:/Volume/home/admin#
Verzamel de opname vanuit het FMC (System > Health > Monitor, selecteer het apparaat en selecteer Advanced Troubleshooter) zoals in de afbeelding:
De foto toont de FMC-opname op Wireshark:
Volg een van de TCP stromen (Volg > TCP stream), zoals in de afbeelding wordt weergegeven.
Belangrijkste punten:
- Er is een TCP 3-handdruk.
- De client (FMC) verstuurt een SSL-bericht naar de Smart Licensing-portal.
- De SSL Sessieid is 0. Dit betekent dat het geen hervatting van de sessie is.
- De antwoorden van de doelserver met de server Hallo, Certificaat en Server Hallo bericht.
- De cliënt stuurt een SSL Fatal Alert die klaagt over een "Onbekende CA".
- De client stuurt een TCP RST om de sessie te sluiten.
- De hele duur van de TCP-sessie (van vestiging tot sluiting) was ~0,5 sec.
Selecteer het servercertificaat en breid het veld emittent uit om de gezamenlijke naam te zien. In dit geval onthult de Common Name een apparaat dat Man-in-the-middle (MITM) doet.
Dit wordt in deze afbeelding getoond:
Aanbevolen acties
De in deze paragraaf genoemde acties hebben tot doel de kwestie verder te beperken.
Actie 1. Neem extra foto's.
Neem opnamen op het apparaat met firewalls:
CAPI toont:
CAPO toont:
Deze opnames bewijzen dat de transitfirewall het servercertificaat (MITM) wijzigt
Actie 2. Controleer het apparaatlogboek.
U kunt de bundel voor VMC TS verzamelen, zoals in dit document wordt beschreven:
In dit geval toont het /dir-archives/var-log/process_stdout.log bestand berichten zoals deze:
SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-ERROR: ch_pf_curl_send_msg[494],
failed to perform, err code 60, err string "SSL peer certificate or SSH remote key was not OK" ...
SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-TRACE: ch_pf_curl_is_cert_issue[514],
cert issue checking, ret 60, url "https://tools.cisco.com/its/
Aanbevolen oplossing
Schakel de MITM uit voor de specifieke stroom zodat FMC zich met succes kan registreren in de Smart Licensing cloud.
Case 11. IPv6-connectiviteitsprobleem
Beschrijving van probleem: Interne hosts (gelegen achter de interface van BINNEN van de firewall) kunnen niet met externe hosts communiceren (hosts gelegen achter de externe interface van de firewall).
Dit beeld toont de topologie:
Betrokken stroom:
SRC IP: u 00:1:10:10
DT IP: fc00:1:1:2:2
Protocol: alle
Capture Analysis
Opname op FTD LINA-motor inschakelen.
firepower# capture CAPI int INSIDE match ip any6 any6 firepower# capture CAPO int OUTSIDE match ip any6 any6
Captures - niet-functioneel scenario
Deze opnames werden parallel genomen met een ICMP-connectiviteitstest van IP FC00:1:1:1:1:1:100 (binnenrouter) tot IP FC00:1:2:2 (upstream router).
De opname in firewallinterface bevat:
Belangrijkste punten:
- De router stuurt een IPv6 buurtaanvraag voor het MAC-adres van het upstream-apparaat (IP FC00:1:1:1:1).
- De firewall antwoordt met een IPv6-buurtadvertentie.
- De router stuurt een ICMP Echo-aanvraag.
- De firewall stuurt een IPv6 buurtaanvraag met het MAC-adres van het downstreamapparaat (fc00:1:1:1:100).
- De router antwoordt met een IPv6 buurtadvertentie.
- De router stuurt extra IPv6 ICMP-Echo-aanvragen.
De opname in firewalls BUITEN de interface bevat:
Belangrijkste punten:
- De firewall stuurt een IPv6 buurtaanvraag met het MAC-adres van het upstreamapparaat (IP fc00:1:1:2:2).
- De router antwoordt met een IPv6 buurtadvertentie.
- De firewall stuurt een IPv6 ICMP-verzoek.
- Het upstream apparaat (router FC00:1:1:2:2:2) stuurt een IPv6 buurtaanvraag voor het MAC-adres van het IPv6-adres fc00:1:1:1:1:1:1:100.
- De firewall stuurt een extra IPv6 ICMP-verzoek.
- De upstream router stuurt een extra IPv6-buurtaanvraag met het MAC-adres van het IPv6-adres 00:1:1:1:1:100.
Punt 4 is zeer interessant. Normaal gesproken vraagt de upstream router om het MAC van de firewall BUITEN DE-interface (FC00:1:1:2:2), maar in plaats daarvan vraagt hij om de FC00:1:1:1:100. Dit is een indicatie van een foutieve configuratie.
Aanbevolen acties
De in deze paragraaf genoemde acties hebben tot doel de kwestie verder te beperken.
Actie 1. Controleer de IPv6-buurttabel.
De IPv6-buurtabel van de firewall is goed bevolkt.
firepower# show ipv6 neighbor | i fc00 fc00:1:1:2::2 58 4c4e.35fc.fcd8 STALE OUTSIDE fc00:1:1:1::100 58 4c4e.35fc.fcd8 STALE INSIDE
Actie 2. Controleer de IPv6-configuratie.
Dit is de firewallconfiguratie.
firewall# show run int e1/2 ! interface Ethernet1/2 nameif INSIDE cts manual propagate sgt preserve-untag policy static sgt disabled trusted security-level 0 ip address 192.168.0.1 255.255.255.0 ipv6 address fc00:1:1:1::1/64 ipv6 enable firewall# show run int e1/3.202 ! interface Ethernet1/3.202 vlan 202 nameif OUTSIDE cts manual propagate sgt preserve-untag policy static sgt disabled trusted security-level 0 ip address 192.168.103.96 255.255.255.0 ipv6 address fc00:1:1:2::1/64 ipv6 enable
De configuratie van het upstream apparaat toont de misconfiguratie:
Router# show run interface g0/0.202 ! interface GigabitEthernet0/0.202 encapsulation dot1Q 202 vrf forwarding VRF202 ip address 192.168.2.72 255.255.255.0 ipv6 address FC00:1:1:2::2/48
Capture - functioneel scenario
De netto maskerverandering (van /48 aan /64) stelde de kwestie vast. Dit is de CAPI-opname in het functionele scenario.
Belangrijkste punt:
- De router stuurt een IPv6 buurtaanvraag voor het MAC-adres van het upstream-apparaat (IP FC00:1:1:1:1).
- De firewall antwoordt met een IPv6-buurtadvertentie.
- De router stuurt ICMP Echo-aanvragen en krijgt Echo-antwoorden.
CAPO-inhoud:
Belangrijkste punten:
- De firewall stuurt een IPv6 buurtaanvraag met het MAC-adres van het upstreamapparaat (IP fc00:1:1:2:2).
- De firewall antwoordt met een IPv6-buurtadvertentie.
- De firewall verstuurt een ICMP Echo-aanvraag.
- De router stuurt een IPv6 buurtaanvraag voor het MAC-adres van het downstreamapparaat (IP FC00:1:1:1:1).
- De firewall antwoordt met een IPv6-buurtadvertentie.
- De firewall stuurt ICMP Echo-aanvragen en krijgt Echo-antwoorden.
Case 12. Intermitterende connectiviteitsprobleem (ARP Poisoning)
Beschrijving van probleem: Interne gastheren (192.168.0.x/24) hebben intermitterende connectiviteitskwesties met hosts in hetzelfde net
Dit beeld toont de topologie:
Betrokken stroom:
SRC IP: 192.168.0.x/24
DT IP: 192.168.0.x/24
Protocol: alle
Het ARP cache van een interne host lijkt vergiftigd te zijn:
Capture Analysis
Schakel een opname op de FTD LINA-motor in
Deze opname neemt alleen ARP-pakketten op de INSIDE-interface op:
firepower# capture CAPI_ARP interface INSIDE ethernet-type arp
Captures - niet-functioneel scenario:
De opname in de firewall INSIDE-interface bevat.
Belangrijkste punten:
- De firewall ontvangt verschillende ARP-verzoeken om IP's binnen 192.168.0.x/24-netwerk
- De firewall antwoordt op al hen (proxy-ARP) met zijn eigen MAC-adres
Aanbevolen acties
De in deze paragraaf genoemde acties hebben tot doel de kwestie verder te beperken.
Actie 1. Controleer de NAT-configuratie.
Afhankelijk van de NAT-configuratie, zijn er gevallen waar het trefwoord zonder proxy-arp het bovenstaande gedrag kan voorkomen:
firepower# show run nat nat (INSIDE,OUTSIDE) source static NET_1.1.1.0 NET_2.2.2.0 destination static NET_192.168.0.0 NET_4.4.4.0 no-proxy-arp
Actie 2. Schakel de proxy-arp functionaliteit uit op de firewallinterface.
Als het "no-proxy-arp"-sleutelwoord het probleem niet oplost, moet u het uitschakelen van proxy ARP op de interface zelf overwegen. In het geval van FTD, zal u op het moment van dit schrijven FlexConfig moeten gebruiken en de volgende opdracht implementeren (specificeer de juiste interfacenaam).
sysopt noproxyarp INSIDE
Case 13. Identificeer SNMP-objecten (OID’s) die CPU-signalen veroorzaken
Deze case laat zien hoe bepaalde SNMP OID’s voor geheugenpeiling werden geïdentificeerd als de basisoorzaak van CPU’s (prestatiekwestie) op basis van de analyse van SNMP versie 3 (SNMPv3)-pakketvastlegging.
Beschrijving van probleem: De overschrijdingen op gegevensinterfaces nemen voortdurend toe. Uit verdere probleemoplossing bleek dat er ook CPU-slangen (veroorzaakt door het SNMP-proces) zijn, die de grondoorzaak van de interfaceoverschrijdingen zijn.
De volgende stap in het proces van de probleemoplossing was het identificeren van de diepere oorzaak van de CPU-telefoons die door het SNMP-proces worden veroorzaakt en, in het bijzonder, het beperken van de reikwijdte van de kwestie om de SNMP-Objectidentificatoren (OID) te identificeren die, wanneer besteld, potentieel kunnen resulteren in CPU-hogs.
Op dit moment biedt de FTD LINA-motor geen 'show'-opdracht voor SNMP-ID’s die in real-time worden bevraagd. De lijst van SNMP OIDs voor opiniepeiling kan worden opgeroepen uit het SNMP-monitoringgereedschap, maar in dit geval waren er deze beperkende factoren:
- De FTD-beheerder heeft geen toegang tot het SNMP-monitoringgereedschap
- SNMP versie 3 met verificatie en gegevensencryptie voor privacy is ingesteld op FTD
Capture Analysis
Aangezien de FTD-beheerder de geloofsbrieven voor de SNMP versie 3 van de authenticatie en gegevensencryptie had, werd dit actieplan voorgesteld:
- Neem SNMP-pakketvastlegging
- Save the Captures and use Wireless SNMP protocol voorkeuren om de SNMP versie 3 aanmeldingsgegevens te specificeren om versie 3 te decrypteren van SNMP versie 3 pakketten. De gedecrypteerde Captures worden gebruikt voor de analyse en het ophalen van SNMP OIDs
Configureer de SNMP-pakketvastlegging op de interface die in de configuratie van de SNMP-server wordt gebruikt:
firepower# show run snmp-server | include host snmp-server host management 192.168.10.10 version 3 netmonv3 firepower# show ip address management System IP Address: Interface Name IP address Subnet mask Method Management0/0 management 192.168.5.254 255.255.255.0 CONFIG Current IP Address: Interface Name IP address Subnet mask Method Management0/0 management 192.168.5.254 255.255.255.0 CONFIG firepower# capture capsnmp interface management buffer 10000000 match udp host 192.168.10.10 host 192.168.5.254 eq snmp firepower# show capture capsnmp capture capsnmp type raw-data buffer 10000000 interface outside [Capturing - 9512 bytes] match udp host 192.168.10.10 host 192.168.5.254 eq snmp
Belangrijkste punten:
- SNMP bron- en doeladressen/poorten.
- Het SNMP protocol PDU kon niet worden gedecodeerd omdat privKey niet bekend is met Wireshark.
- De waarde van de versleutelde PDU-primitief.
Aanbevolen acties
De in deze paragraaf genoemde acties hebben tot doel de kwestie verder te beperken.
Actie 1. Ontcijferen van SNMP-opnamen.
Save the Captures and bewerking the Wireless SNMP protocol voorkeuren om de SNMP versie 3 referenties te specificeren om de pakketten te decrypteren.
firepower# copy /pcap capture: tftp: Source capture name [capsnmp]? Address or name of remote host []? 192.168.10.253 Destination filename [capsnmp]? capsnmp.pcap !!!!!! 64 packets copied in 0.40 secs
Open het opnamebestand op Wireless, selecteer een SNMP-pakket en navigeer naar Protocol voorkeuren > Gebruikers-tabel, zoals in de afbeelding:
In de tabel van SNMP-gebruikers zijn de SNMP versie 3 Gebruikersnaam, Verificatiemodel, Wachtwoord voor verificatie, Privacyprotocol en het Privacywachtwoord gespecificeerd (de eigenlijke aanmeldingsgegevens worden niet hieronder weergegeven):
Zodra SNMP-gebruikersinstellingen werden toegepast, toonde Wireshark gedecrypteerde SNMP-PDU’s:
Belangrijkste punten:
- De SNMP-bewakingstools die SNMP heeft gebruikt, krijgenBulkApplication om gegevens te vragen en over de ouder OID 1.3.6.1.4.1.9.9.221.1 en verwante OID's te lopen.
- De FTD reageerde op elke getBulkrequest met een get-response die OID's bevat die verband houden met 1.3.6.1.4.1.9.221.1.
Actie 2. Identificeer de SNMP-ID’s.
SNMP Object Navigator toonde aan dat OID 1.3.6.1.4.1.9.9.221.1 tot de beheerinformatiebasis (MIB) behoort met de naam CISCO-ENHANCED-MEMPOOL-MIB, zoals in de afbeelding wordt getoond:
Als u de OID’s in een menselijk leesbaar formaat in Wireshark wilt weergeven, volgt u deze stappen:
- Download de MIB CISCO-ENHANCED-MEMPOOL-MIB en de bijbehorende afhankelijkheden in de afbeelding:
2. In het venster Bewerken > Voorkeuren > Resolutie naam selecteren, is de resolutie OID inschakelen ingeschakeld. In SMI (MIB en PIB paden) specificeert u de map met de gedownload MIBs en in SMI (MIB en PIB modules). CISCO-ENHANCED-MEMPOOL-MIB wordt automatisch toegevoegd aan de lijst van modules:
3. Zodra de haai opnieuw is gestart, wordt de OID-resolutie geactiveerd:
Op basis van de gedecrypteerde uitvoer van het opnamebestand was de SNMP-bewakingstool periodiek (10 seconden interval) enquêtegegevens over het gebruik van geheugenpools op de FTD. Zoals uitgelegd in het TechNotes-artikel ASA SNMP Polling for Memory-Gerelateerde Statistics polling the Global Shared Pool (GSP) met behulp van SNMP-resultaten in CPU-telefoons. In dit geval van de opnamen was het duidelijk dat het gebruik van 'Global Shared Pool' regelmatig werd ondervraagd als onderdeel van de primitieve SNMP GetBulkeconomisch verzoek.
Om de CPU’s die door het SNMP-proces worden veroorzaakt, te minimaliseren, werd aanbevolen de limiteringsstappen voor de CPU-Hogs voor SNMP te volgen die in het artikel worden genoemd, en te voorkomen dat de OID’s met betrekking tot het SAP worden geraadpleegd. Zonder de SNMP-enquête voor de OID's die betrekking hebben op het SAP, werden geen CPU-slangen waargenomen die door het SNMP-proces werden veroorzaakt, en is het aantal overschrijdingen aanzienlijk gedaald.
Gerelateerde informatie
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)