Firewall-vastleggingen analyseren om netwerkproblemen op te lossen
Inhoud
Inleiding
In dit document worden verschillende technieken voor analyse van pakketvastlegging omschreven die bedoeld zijn om netwerkproblemen effectief op te lossen.
Voorwaarden
Vereisten
Cisco raadt kennis van de volgende onderwerpen aan:
- Firepower-platformarchitectuur
- NGFW-logs
- NGFW-pakkettracer
Voordat u begint met het analyseren van pakketopnames, is het ten zeerste aan te raden om aan deze vereisten te voldoen:
- De protocolbewerking kennen - Begin niet met het controleren van een pakketopname als u niet begrijpt hoe het vastgelegde protocol werkt.
- Ken de topologie - U moet de doorvoerapparaten end-to-end kennen. Als dit niet mogelijk is, moet u op zijn minst de upstream en downstream apparaten kennen.
- Ken het toestel - U moet weten hoe uw apparaat omgaat met pakketten, wat de betrokken interfaces zijn (ingress / egress), wat de apparaatarchitectuur is en wat de verschillende opnamepunten zijn.
- Ken de configuratie - U moet weten hoe een pakketstroom door het apparaat moet worden verwerkt in termen van:
- Routing/uitgang-interface
- Toegepast beleid
- Network Address Translation (NAT)
- Ken de beschikbare tools - Samen met de opnames wordt aanbevolen om klaar te zijn om andere tools en technieken toe te passen (zoals logging en tracers) en indien nodig te correleren met de vastgelegde 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 met FTD-software 6.5.x.
- FMC met 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 live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Achtergrondinformatie
Packet capture is een van de meest over het hoofd geziene tools voor probleemoplossing die vandaag beschikbaar zijn. Dagelijks lost Cisco TAC veel problemen op met de analyse van vastgelegde gegevens.
Het doel van dit document is om netwerk- en beveiligingsingenieurs te helpen bij het identificeren en oplossen van veelvoorkomende netwerkproblemen, voornamelijk op basis van analyse van pakketafvang.
Alle scenario's die in dit document worden gepresenteerd, zijn gebaseerd op echte gebruikerscases in het Cisco Technical Assistance Center (TAC).
Het document behandelt de pakketopnames vanuit het oogpunt van een Cisco Next-Generation Firewall (NGFW), maar dezelfde concepten zijn ook van toepassing op andere apparaattypen.
Hoe te verzamelen en te exporteren Captures op de NGFW Product Family?
In het geval van een Firepower toestel (1xxx, 21xx, 41xx, 93xx) en een Firepower Threat Defense (FTD) applicatie kan een pakketverwerking gevisualiseerd worden zoals getoond in de afbeelding.
- Een pakket komt de ingangsinterface binnen en wordt afgehandeld door de interne switch van het chassis.
- Het pakket komt binnen in de FTD Lina-motor die voornamelijk L3 / L4-controles uitvoert.
- Als het beleid vereist dat het pakket wordt geïnspecteerd door de Snort motor (voornamelijk L7 inspectie).
- De Snort-engine geeft een oordeel voor het pakket.
- De LINA-engine wijst het pakket af of stuurt het door op basis van het Snort-oordeel.
- Het pakket verlaat het chassis via de interne switch van het chassis.
Op basis van de getoonde architectuur kunnen de FTD-opnames op drie (3) verschillende plaatsen worden gemaakt:
- FXOS
- FTD Lina-motor
- FTD Snort-engine
FXOS-opnamen verzamelen
Het proces wordt beschreven in dit document:
FXOS-opnamen kunnen alleen worden gemaakt in de ingangsrichting vanuit het oogpunt van de interne switch die hier in de afbeelding wordt weergegeven.
Hier weergegeven zijn dit twee opnamepunten per richting (vanwege de interne switch-architectuur).
Opgenomen pakketten in de punten 2, 3 en 4 hebben een virtuele netwerktag (VNTag).
FTD Lina-opnamen inschakelen en verzamelen
Belangrijkste opnamepunten:
- Ingress-interface
- Uitganginterface
- Versneld beveiligingspad (ASP)
U kunt de gebruikersinterface van het Firepower Management Center (FMC UI) of de FTD CLI gebruiken om de FTD Lina-opnamen in te schakelen en te verzamelen.
Opname vanuit CLI inschakelen in de INSIDE-interface:
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.
Schakel ASP-opname in om alle pakketten te zien die door de FTD Lina-engine zijn gedropt:
firepower# capture ASP type asp-drop all
Een FTD Lina-opname exporteren naar een FTP-server:
firepower# copy /pcap capture:CAPI ftp://ftp_username:ftp_password@192.168.78.73/CAPI.pcap
Een FTD Lina-opname exporteren naar een TFTP-server:
firepower# copy /pcap capture:CAPI tftp://192.168.78.73
Vanaf de FMC 6.2.x-versie kunt u FTD Lina-opnamen inschakelen en verzamelen via de FMC UI.
Een andere manier om FTD-opnames te verzamelen van een door FMC beheerde firewall is deze.
Stap 1
In het geval van LINA of ASP neemt u de opname over naar de FTD-schijf.
firepower# copy /pcap capture:capin disk0:capin.pcap Source capture name [capin]? Destination filename [capin.pcap]? !!!!
Stap 2
Navigeer naar de expertmodus, zoek de opgeslagen opname en kopieer deze 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. Zoek het FTD-apparaat en selecteer het pictogram Problemen oplossen:
Stap 4
Geavanceerde probleemoplossing selecteren:
Geef de naam van het vastlegbestand op en selecteer Downloaden:
Zie dit document voor meer voorbeelden over het inschakelen/verzamelen van opnames van de FMC-gebruikersinterface:
FTD Snort Captures inschakelen en verzamelen
Het opnamepunt wordt hier in de afbeelding getoond.
Vastleggen 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
Om de opname naar een bestand met de naam capture.pcap te schrijven en deze via FTP naar een externe server te 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. >
Raadpleeg dit document voor meer korte opnamefilters met verschillende opnamefilters:
Problemen oplossen
Situatie 1. Geen TCP SYN op de Egress-interface
De topologie wordt hier in de afbeelding getoond:
Probleembeschrijving: HTTP werkt niet
Beïnvloede stroming:
SRC IP: 192.168.0.100
Dst IP: 10.10.1.100
Protocol: TCP 80
Capture-analyse
Captures inschakelen op de FTD LINA-engine:
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
Vastleggingen - Functioneel scenario:
Als basislijn is het altijd erg handig om opnames te hebben van een functioneel scenario.
Opname gemaakt op NGFW INSIDE interface, zoals getoond in de afbeelding:
Belangrijkste punten:
- TCP 3-weg handshake.
- Bidirectionele gegevensuitwisseling.
- Geen vertragingen tussen de pakketten (op basis van het tijdsverschil tussen de pakketten).
- Source MAC is het juiste downstream-apparaat.
Opname genomen op NGFW OUTSIDE interface, wordt getoond in de afbeelding hier:
Belangrijkste punten:
- Dezelfde gegevens als in de CAPI-opname.
- Bestemming MAC is het juiste upstream-apparaat.
Vastleggingen - Niet-functioneel scenario
Vanaf het apparaat zien de CLI-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 CAPI-opname in Wireshark:
Belangrijkste punten:
- Alleen TCP SYN-pakketten worden weergegeven (geen TCP 3-weg handshake).
- Er zijn 2 TCP-sessies (bronpoort 3171 en 3172) die niet kunnen worden ingesteld. De bronclient verzendt de TCP SYN-pakketten opnieuw. Deze opnieuw verzonden pakketten worden door de Wireshark geïdentificeerd als TCP Retransmissions.
- De TCP-heruitzendingen vinden elke ~3 dan 6 etc seconden plaats.
- Het MAC-adres van de bron is afkomstig van het juiste downstreamapparaat.
Op basis van de 2 opnames kan worden geconcludeerd dat:
- Een pakket van een specifieke 5-tuple (src/dst IP, src/dst-poort, protocol) arriveert op de firewall op de verwachte interface (INSIDE).
- Een pakket verlaat de firewall niet op de verwachte interface (BUITEN).
Aanbevolen acties
De acties die in deze sectie worden vermeld, hebben als doel het probleem verder te beperken.
Actie 1. Controleer het spoor van een geëmuleerd pakket.
Gebruik de packet-tracer tool om te zien hoe een pakket wordt verondersteld te worden behandeld door de firewall. Als het pakket wordt gedropt door het toegangsbeleid van de firewall, lijkt het spoor van het geëmuleerde 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 levende pakketten.
Schakel het traceren van pakketten in om te controleren hoe de echte TCP SYN-pakketten door de firewall worden behandeld. Standaard worden alleen de eerste 50 ingresspakketten getraceerd:
firepower# capture CAPI trace
Verwijder de opnamebuffer:
firepower# clear capture /all
In het geval dat het pakket wordt verwijderd door het toegangsbeleid van de firewall, ziet het traceren er ongeveer hetzelfde uit als 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 de FTD Lina-logs.
Als u Syslog on FTD via FMC wilt configureren, controleert u dit document:
Het wordt ten zeerste aanbevolen om een externe Syslog-server te configureren voor FTD Lina-logs. Als er geen externe Syslog-server is geconfigureerd, schakelt u lokale bufferlogboeken in de firewall in terwijl u problemen oplost. De logboekconfiguratie in dit voorbeeld is een goed startpunt:
firepower# show run logging … logging enable logging timestamp logging buffer-size 1000000 logging buffered informational
Stel de terminalpager in op 24 regels om de terminalpager te bedienen:
firepower# terminal pager 24
Verwijder de opnamebuffer:
firepower# clear logging buffer
Test de verbinding en controleer de logs met een parserfilter. In dit voorbeeld worden de pakketten gedropt door het toegangsbeleid van de firewall:
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 of de firewall ASP is gevallen.
Als u vermoedt dat het pakket door de firewall is gedropt, ziet u de tellers van alle pakketten die door de firewall op softwareniveau zijn gedropt:
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 inschakelen om alle dalingen op ASP-softwareniveau 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 verfijnen:
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 al op interfaceniveau worden getraceerd, wordt de reden voor de daling niet vermeld in de ASP-opname. Vergeet niet dat een pakket slechts op één plaats kan worden getraceerd (ingress-interface of ASP-drop). In dat geval wordt aanbevolen om meerdere ASP-druppels te nemen en een specifieke ASP-valreden in te stellen. Hier is een aanbevolen aanpak:
1. Wis de huidige ASP-valtellers:
firepower# clear asp drop
2. Stuur de stroom die u problemen oplost via de firewall (voer een test uit).
3. Controleer nogmaals de ASP-valtellers en noteer de verhoogde.
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-vastlegging(en) in voor de specifieke waargenomen druppels:
firepower# capture ASP_NO_ROUTE type asp-drop no-route firepower# capture ASP_ACL_DROP type asp-drop acl-drop
5. Stuur de stroom die u problemen oplost via de firewall (voer een test uit).
6. Controleer de ASP-opnamen. In dit geval werden de pakketten gedropt vanwege een afwezige route:
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-verbindingstabel.
Er kunnen gevallen zijn waarin u verwacht dat het pakket interface 'X' verlaat, maar om welke reden dan ook interface 'Y' verlaat. De bepaling van de firewall-uitgang is gebaseerd op deze volgorde van gebruik:
- Opzoeken van verbinding tot stand gebracht
- Network Address Translation (NAT) opzoeken - UN-NAT (destination NAT) fase heeft voorrang op PBR en route opzoeken.
- Beleidsgebaseerde routering (PBR)
- Routeringstabel opzoeken
U controleert als volgt de FTD-verbindingstabel:
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:
- Op basis van de vlaggen (Aa) is de verbinding embryonaal (half geopend - alleen TCP SYN werd gezien door de firewall).
- Op basis van de bron-/bestemmingspoorten is de ingangsinterface INSIDE en de uitgang-interface DMZ.
Dit kan worden gevisualiseerd in de afbeelding hier:
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 22Uitgang 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
Uitgang 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: 228982375Bovendien geeft de show conn lang de NATed IP's binnen een haakje weer in het geval van een netwerkadresvertaling:
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 de cache van het Firewall Address Resolution Protocol (ARP).
Als de firewall de volgende hop niet kan oplossen, laat de firewall het oorspronkelijke pakket stilletjes vallen (in dit geval TCP SYN) en verzendt voortdurend ARP-verzoeken totdat het de volgende hop oplost.
Gebruik de opdracht om de ARP-cache van de firewall te bekijken:
firepower# show arp
Als u bovendien wilt controleren of er onopgeloste hosts zijn, kunt u de opdracht gebruiken:
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-bewerking 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 uitvoer probeert de firewall (192.168.2.50) de next-hop (192.168.2.72) op te lossen, maar er is geen ARP-antwoord
De uitvoer hier toont een functioneel scenario met de 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
Als er geen ARP-vermelding is, wordt een spoor van een levend TCP SYN-pakket weergegeven:
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 te zien is in de uitvoer, toont de trace Action: allow zelfs wanneer de volgende hop niet bereikbaar is en het pakket stilletjes door de firewall wordt gedropt! In dit geval moet ook het packet-tracer-gereedschap worden gecontroleerd, omdat het een nauwkeurigere 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 vorige bericht geoptimaliseerd om:
Drop-reason: (no-v4-adjacency) No valid V4 adjacency. Check ARP table (show arp) has entry for nexthop., Drop-location: f
Mogelijke oorzaken en aanbevolen acties Samenvatting
Als u alleen een TCP SYN-pakket ziet op de ingress-interfaces, maar geen TCP SYN-pakket wordt verzonden vanuit de verwachte uitgang-interface, zijn enkele mogelijke oorzaken:
|
Mogelijke oorzaak |
Aanbevolen acties |
|
Het pakket wordt gedropt door het firewall-toegangsbeleid. |
|
|
Het afvangfilter is fout. |
|
|
Het pakket wordt verzonden naar een andere uitgang interface. |
Als het pakket naar een verkeerde interface wordt verzonden omdat het overeenkomt met een huidige verbinding, gebruikt u de opdracht om het adres van conn te wissen en geeft u de 5-dubbele verbinding op die u wilt wissen. |
|
Er is geen route naar de bestemming. |
|
|
Er is geen ARP-ingang op de uitgang-interface. |
|
|
De uitgang-interface is uitgeschakeld. |
Controleer de uitvoer van de opdracht show interface ip brief op de firewall en controleer de status van de interface. |
Situatie 2. TCP SYN vanaf client, TCP RST vanaf server
Deze afbeelding toont de topologie:
Probleembeschrijving: HTTP werkt niet
Beïnvloede stroming:
SRC IP: 192.168.0.100
Dst IP: 10.10.1.100
Protocol: TCP 80
Capture-analyse
Schakel opnames in op de FTD LINA-engine.
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
Vastleggingen - Niet-functioneel scenario:
Zo zien de opnamen eruit vanaf de CLI van het apparaat:
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 vangst van CAPI in Wireshark.
Belangrijkste punten:
- De bron verzendt een TCP SYN-pakket.
- Een TCP RST wordt naar de bron gestuurd.
- De bron verzendt de TCP SYN-pakketten opnieuw.
- De MAC-adressen zijn correct (op toegangspakketten behoort het MAC-adres van de bron tot de downstream router, het MAC-adres van de bestemming behoort tot de firewall INSIDE-interface).
Deze afbeelding toont de vangst van CAPO in Wireshark:
Belangrijkste punten:
- De bron verzendt een TCP SYN-pakket.
- Een TCP RST arriveert op de OUTSIDE-interface.
- De bron verzendt de TCP SYN-pakketten opnieuw.
- De MAC-adressen zijn correct (op uitgangspakketten is de firewall BUITEN de bron MAC, upstream router is de bestemming MAC).
Op basis van de 2 opnames kan worden geconcludeerd dat:
- De TCP 3-weg handshake tussen de client en de server wordt niet voltooid
- Er is een TCP RST die aankomt op de firewall uitgang interface
- De firewall 'praat' met de juiste upstream- en downstreamapparaten (op basis van de MAC-adressen)
Aanbevolen acties
De acties die in deze sectie worden vermeld, hebben als doel het probleem verder te beperken.
Actie 1. Controleer het MAC-adres van de bron waarmee de TCP RST wordt verzonden.
Controleer of de bestemmings-MAC in het TCP SYN-pakket dezelfde is als de bron-MAC in het TCP RST-pakket heeft gezien.
Deze controle heeft als doel om 2 dingen te bevestigen:
- Controleer of er geen asymmetrische stroom is.
- Controleer of de MAC tot het verwachte upstream-apparaat behoort.
Actie 2. Vergelijk ingress en egress pakketten.
Vergelijk visueel de 2 pakketten op Wireshark om te controleren of de firewall de pakketten niet wijzigt/corrumpeert. Enkele verwachte verschillen worden belicht.
Belangrijkste punten:
- Tijdstempels zijn anders. Het verschil moet klein en redelijk zijn. Dit is afhankelijk van de functies en beleidscontroles die op het pakket worden toegepast, evenals de belasting op het apparaat.
- De lengte van de pakketten verschilt vooral als er een dot1Q-header is toegevoegd / verwijderd door de firewall aan slechts één kant.
- De MAC-adressen zijn verschillend.
- Een dot1Q-header kan op zijn plaats zijn als de opname op een subinterface is gemaakt.
- De IP-adressen zijn verschillend in het geval dat NAT of Port Address Translation (PAT) op het pakket wordt toegepast.
- De bron- of bestemmingspoorten zijn anders als NAT of PAT op het pakket wordt toegepast.
- Als u de optie Relatief volgnummer van Wireshark uitschakelt, ziet u dat de TCP-volgnummers/bevestigingsnummers worden gewijzigd door de firewall vanwege de randomisatie van het eerste volgnummer (ISN).
- Sommige TCP-opties kunnen worden overschreven. De firewall wijzigt bijvoorbeeld standaard de TCP Maximum Segment Size (MSS) in 1380 om fragmentatie van pakketten in het doorgangspad te voorkomen.
Actie 3. Neem een foto op de bestemming.
Neem indien mogelijk een foto op de bestemming zelf. Als dit niet mogelijk is, neem dan een opname zo dicht mogelijk bij de bestemming. Het doel hier is om te controleren wie de TCP RST verzendt (is de bestemmingsserver of is er een ander apparaat in het pad?).
Situatie 3. TCP 3-weg handshake + RST vanaf één eindpunt
Deze afbeelding toont de topologie:
Probleembeschrijving: HTTP werkt niet
Beïnvloede stroming:
SRC IP: 192.168.0.100
Dst IP: 10.10.1.100
Protocol: TCP 80
Capture-analyse
Schakel opnames in op de FTD LINA-engine.
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
Vastleggingen - Niet-functioneel scenario:
Er zijn een paar verschillende manieren waarop dit probleem zich kan manifesteren in captures.
3.1 - TCP 3-weg handshake + vertraagde RST van de client
Zowel CAPI als CAPO worden door de firewall vastgelegd en bevatten dezelfde pakketten, zoals in de afbeelding wordt getoond.
Belangrijkste punten:
- De TCP 3-weg handshake gaat door de firewall.
- De server verzendt de SYN/ACK opnieuw.
- De client verzendt de ACK opnieuw.
- Na ~20 sec geeft de client het op en stuurt een TCP RST.
Aanbevolen acties
De acties die in deze sectie worden vermeld, hebben als doel het probleem verder te beperken.
Actie 1. Leg de beelden zo dicht mogelijk bij de twee eindpunten vast.
De firewall-opnames geven aan dat de client-ACK niet door de server is verwerkt. Dit is gebaseerd op deze feiten:
- De server verzendt de SYN/ACK opnieuw.
- De client verzendt de ACK opnieuw.
- De client verzendt een TCP RST of FIN/ACK voordat er gegevens worden verzonden.
Vastleggen op de server toont het probleem. De client ACK van de TCP 3-way handshake is nooit aangekomen:
3.2 - TCP 3-weg handshake + vertraagde FIN/ACK van client + vertraagde RST van de server
Zowel CAPI als CAPO worden door de firewall vastgelegd en bevatten dezelfde pakketten, zoals in de afbeelding wordt getoond.
Belangrijkste punten:
- De TCP 3-weg handshake gaat door de firewall.
- Na ~5 sec stuurt de client een FIN/ACK.
- Na ~20 sec geeft de server het op en stuurt een TCP RST.
Op basis van deze opname kan worden geconcludeerd dat hoewel er een TCP 3-weg handshake door de firewall lijkt het dat het nooit echt wordt voltooid op één eindpunt (de heruitzendingen geven dit aan).
Aanbevolen acties
Net als in geval 3.1
3.3 - TCP 3-weg handshake + vertraagde RST van de client
Zowel CAPI als CAPO worden door de firewall vastgelegd en bevatten dezelfde pakketten, zoals in de afbeelding wordt getoond.
Belangrijkste punten:
- De TCP 3-weg handshake gaat door de firewall.
- Na ~20 sec geeft de client het op en stuurt een TCP RST.
Op basis van deze vaststellingen kan worden geconcludeerd dat:
- Na 5-20 seconden geeft één eindpunt het op en besluit de verbinding te beëindigen.
Aanbevolen acties
Net als in geval 3.1
3.4 - TCP 3-weg handshake + onmiddellijke RST van de server
Zowel de firewall capi en capo vastleggen bevatten deze pakketten, zoals weergegeven in de afbeelding.
Belangrijkste punten:
- De TCP 3-weg handshake gaat door de firewall.
- Er is een TCP RST van de server een paar milliseconden na het ACK-pakket.
Aanbevolen acties
Actie: Neem foto's zo dicht mogelijk bij de server.
Een onmiddellijke TCP RST van de server kan wijzen op een slecht werkende server of een apparaat in het pad dat de TCP RST verzendt. Maak een opname op de server zelf en bepaal de bron van de TCP RST.
Situatie 4. TCP RST van de client
Deze afbeelding toont de topologie:
Probleembeschrijving: HTTP werkt niet.
Beïnvloede stroming:
SRC IP: 192.168.0.100
Dst IP: 10.10.1.100
Protocol: TCP 80
Capture-analyse
Captures inschakelen op FTD LINA-engine.
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
Vastleggingen - 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 firewall-logs 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 logs geven aan dat er een TCP RST is die binnenkomt op de firewall INSIDE-interface
CAPI-vangst in Wireshark:
Volg de eerste TCP-stream, zoals weergegeven in de afbeelding.
Navigeer onder Wireshark naar Bewerken > Voorkeuren > Protocollen > TCP en schakel de optie Relatieve reeksnummers uit zoals in de afbeelding wordt weergegeven.
Deze afbeelding toont de inhoud van de eerste stroom in CAPI-opname:
Belangrijkste punten:
- De client verzendt een TCP SYN-pakket.
- De client verzendt een TCP RST-pakket.
- Het TCP SYN-pakket heeft een volgnummer dat gelijk is aan 4098574664.
Dezelfde stroom in CAPO-opname bevat:
Belangrijkste punten:
- De client verzendt een TCP SYN-pakket. De firewall maakt het ISN willekeurig.
- De client verzendt een TCP RST-pakket.
Op basis van de twee opnames kan worden geconcludeerd dat:
- Er is geen TCP 3-weg handshake tussen de client en de server.
- Er is een TCP RST die afkomstig is van de klant. De waarde voor het RST-volgnummer van de TCP in CAPI-opname is 1386249853.
Aanbevolen acties
De acties die in deze sectie worden vermeld, hebben als doel het probleem verder te beperken.
Actie 1. Neem een foto van de klant.
Op basis van de opnamen die op de firewall zijn verzameld, is er een sterke indicatie van een asymmetrische stroom. Dit is gebaseerd op het feit dat de client een TCP RST verzendt met een waarde van 1386249853 (het gerandomiseerde ISN):
Belangrijkste punten:
- De client verzendt een TCP SYN-pakket. Het volgnummer is 4098574664 en is hetzelfde als op de firewall INSIDE interface (CAPI)
- Er is een TCP SYN/ACK met ACK-nummer 1386249853 (wat wordt verwacht vanwege ISN-randomisatie). Dit pakket werd niet gezien in de firewall captures
- De client verzendt een TCP RST omdat deze een SYN/ACK verwachtte met een ACK-waarde van 4098574665, maar deze ontving een waarde van 1386249853
Dit kan als volgt worden weergegeven:
Actie 2. Controleer de routering tussen de client en de firewall.
Bevestigen dat:
- De MAC-adressen in de opnames zijn de verwachte.
- Zorg ervoor dat de routering tussen de firewall en de client symmetrisch is.
Er zijn scenario's waarbij de RST afkomstig is van een apparaat dat tussen de firewall en de client zit terwijl er een asymmetrische routering in het interne netwerk is. Een typisch geval wordt getoond in de afbeelding:
In dit geval heeft de opname deze inhoud. Let op het verschil tussen het MAC-adres van de bron van het TCP SYN-pakket en het MAC-adres van de bron van het TCP RST en het MAC-adres van de bestemming 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)
...
Situatie 5. Trage TCP-overdracht (scenario 1)
Probleembeschrijving:
SFTP-overdracht tussen hosts 10.11.4.171 en 10.77.19.11 is traag. Hoewel de minimale bandbreedte (BW) tussen de 2 hosts 100 Mbps is, gaat de overdrachtssnelheid niet verder dan 5 Mbps.
Tegelijkertijd is de overdrachtssnelheid tussen hosts 10.11.2.124 en 172.25.18.134 behoorlijk hoger.
Achtergrondinformatie:
De maximale overdrachtssnelheid voor een enkele TCP-stroom wordt bepaald door het Bandwidth Delay Product (BDP). De gebruikte formule wordt getoond in de afbeelding:
Voor meer informatie over de BDP, bekijk de bronnen hier:
- Waarom uw toepassing alleen 10Mbps gebruikt Zelfs de koppeling is 1Gbps?
- BRKSEC-3021 - Geavanceerd - Firewallprestaties maximaliseren
Scenario 1. langzame overdracht
Deze afbeelding toont de topologie:
Beïnvloede stroming:
SRC IP: 10.11.4.171
Dst IP: 10 77 19 11
Protocol: SFTP (FTP over SSH)
Capture-analyse
Captures inschakelen op FTD LINA-engine:
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 acties die in deze sectie worden vermeld, hebben als doel het probleem verder te beperken.
Berekening van de retourreistijd (RTT)
Identificeer eerst de overdrachtsstroom en volg deze:
Wijzig de wireshark-weergave 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 2 pakketuitwisselingen (één richting de bron en één richting de bestemming) op te tellen. In dit geval toont pakket # 2 de RTT tussen de firewall en het apparaat dat het SYN / ACK-pakket (server) heeft verzonden. Pakket #3 toont de RTT tussen de firewall en het apparaat dat het ACK-pakket (client) heeft verzonden. De toevoeging van de 2 getallen geeft een goede schatting over de end-to-end RTT:
RTT ≈ 80 msec
Berekening van de grootte van het TCP-venster
Vouw een TCP-pakket uit, vouw de TCP-header uit, selecteer Berekende venstergrootte en selecteer Toepassen als kolom:
Controleer de kolom Berekende venstergrootte om te zien wat de maximale venstergrootte was tijdens de TCP-sessie. U kunt ook de kolomnaam selecteren en de waarden sorteren.
Als u een bestandsdownload test (server > client), moet u de waarden controleren die door de server worden geadverteerd. De maximale venstergrootte die door de server wordt geadverteerd, bepaalt de maximale bereikte overdrachtssnelheid.
In dit geval is de grootte van het TCP-venster ongeveer 50000 bytes
Op basis van deze waarden en met het gebruik van de Bandwidth Delay Product formule krijgt u de maximale theoretische bandbreedte die onder deze omstandigheden kan worden bereikt: 50000 * 8 / 0,08 = 5 Mbps maximale theoretische bandbreedte.
Dit komt overeen met wat de klant in dit geval ervaart.
Controleer de TCP 3-weg handshake goed. Beide zijden, en nog belangrijker de server, adverteren met een vensterschaalwaarde van 0, wat 2 ^ 0 = 1 betekent (geen Windows-schaling). Dit heeft een negatieve invloed op de overdrachtssnelheid:
Op dit punt is het nodig om een opname op de server te maken, te bevestigen dat het degene is die vensterschaal = 0 adverteert en deze opnieuw te configureren (controleer de serverdocumentatie voor hoe u dit doet).
Scenario 2. Snelle overdracht
Laten we nu het goede scenario bekijken (snelle overdracht via hetzelfde netwerk):
Topologie:
De stroom van interesse:
SRC IP: 10.11.2.124
Dst IP: 172 25 18 134
Protocol: SFTP (FTP over SSH)
Captures inschakelen op FTD LINA-engine
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
Round Trip Time (RTT) Berekening: In dit geval is de RTT ≈ 300 msec.
TCP-venstergrootteberekening: de server adverteert met een TCP-vensterschaalfactor van 7.
De grootte van het TCP-venster van de server is ≈ 1600000 bytes:
Op basis van deze waarden geeft de Bandwidth Delay Product formule:
1600000*8/0,3 = maximale theoretische overdrachtssnelheid van 43 Mbps
Situatie 6. Trage TCP-overdracht (scenario 2)
Probleembeschrijving: FTP-bestandsoverdracht (downloaden) via de firewall is traag.
Deze afbeelding toont de topologie:
Beïnvloede stroming:
SRC IP: 192 168 2 220
Dst IP: 192 168 1 220
Protocol: FTP
Capture-analyse
Schakel opnames in op de FTD LINA-engine.
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 on FTD INSIDE capture (CAPI):
De inhoud van de FTP-DATA-stream:
De CAPO-inhoud vastleggen:
Belangrijkste punten:
- TCP Out-of-Order (OOO)-pakketten zijn beschikbaar.
- Er is een TCP-hertransmissie.
- Er is een indicatie van een pakketverlies (gedropte pakketten).
Aanbevolen acties
De acties die in deze sectie worden vermeld, hebben als doel het probleem verder te beperken.
Actie 1. Identificeer de locatie van het pakketverlies.
In dit soort gevallen moet u gelijktijdig opnamen maken en de methode voor verdelen en veroveren gebruiken om het netwerksegment of de netwerksegmenten te identificeren die pakketverlies veroorzaken. Vanuit het oogpunt van de firewall zijn er 3 hoofdscenario's:
- Het pakketverlies wordt veroorzaakt door de firewall zelf.
- Het pakketverlies wordt stroomafwaarts van het firewallapparaat veroorzaakt (richting van server naar client).
- Het pakketverlies wordt stroomopwaarts naar het firewallapparaat veroorzaakt (richting van de client naar de server).
Verlies van pakketten veroorzaakt door de firewall: om te bepalen of het verlies van pakketten wordt veroorzaakt door de firewall, moet de ingress-opname worden vergeleken met de egress-opname. Er zijn veel manieren om 2 verschillende opnames te vergelijken. In dit gedeelte wordt een manier getoond om deze taak uit te voeren.
Procedure om 2 opnames te vergelijken om het pakketverlies te identificeren
Stap 1. Zorg ervoor dat de 2 opnamen pakketten uit hetzelfde tijdvenster bevatten. Dit betekent dat er geen pakketjes in de ene opname mogen zitten die voor of na de andere opname zijn vastgelegd. Er zijn een paar manieren om dit te doen:
- Controleer de eerste en laatste IP-identificatiewaarden van het pakket.
- Controleer de waarden van de eerste en laatste tijdstempel van het pakket.
In dit voorbeeld kunt u zien dat de eerste pakketten van elke opname dezelfde IP-ID-waarden hebben:
In het geval dat ze niet hetzelfde zijn:
- Vergelijk de tijdstempels van het eerste pakket van elke opname.
- Van de opname met de nieuwste tijdstempel krijgt u een filter van het wijzigen van de tijdstempelfilter van == naar >= (het eerste pakket) en <= (het laatste pakket), bijvoorbeeld:
(frame.time >= "16 okt 2019 16:13:43.244692000") &&(frame.time <= "16 okt 2019 16:20:21.785130000")
3. Exporteer de opgegeven pakketten naar een nieuwe opname, selecteer Bestand > Gespecificeerde pakketten exporteren en sla de weergegeven pakketten op. Op dit punt moeten beide opnamen pakketten bevatten die hetzelfde tijdvenster beslaan. U kunt nu beginnen met de vergelijking van de 2 opnames.
Stap 2. Geef op welk pakketveld wordt gebruikt voor de vergelijking tussen de 2 opnamen. Voorbeelden van velden die kunnen worden gebruikt:
- IP-identificatie
- RTP-volgnummer
- ICMP-volgnummer
Maak een tekstversie van elke opname die het veld bevat voor elk pakket dat u in stap 1 hebt opgegeven. Om dit te doen, laat u alleen de kolom van belang achter, bijvoorbeeld als u pakketten wilt vergelijken op basis van IP-identificatie en wijzigt u de opname zoals weergegeven in de afbeelding.
Het resultaat:
Stap 3. Maak een tekstversie van de opname (Bestand > Dissecties van pakketten exporteren > Als onbewerkte tekst...), zoals in de afbeelding wordt weergegeven:
Schakel de optie Kolomkoppen en pakketdetails opnemen uit om alleen de waarden van het weergegeven veld te exporteren, zoals in de afbeelding wordt weergegeven:
Stap 4. Sorteer de pakketten in de bestanden. Je kunt de Linux sorteeropdracht gebruiken om dit te doen:
# sort CAPI_IDs > file1.sorted # sort CAPO_IDs > file2.sorted
Stap 5. Gebruik een tekstvergelijkingstool (bijvoorbeeld WinMerge) of de Linux diff-opdracht om de verschillen tussen de 2 opnamen te vinden.
In dit geval zijn CAPI- en CAPO-vastlegging voor het FTP-gegevensverkeer identiek. Dit bewijst dat het pakketverlies niet door de firewall is veroorzaakt.
Identificeer upstream/downstream pakketverlies.
Belangrijkste punten:
1. Dit pakket is een TCP-hertransmissie. Concreet is het een TCP SYN-pakket dat van de client naar de server wordt verzonden voor FTP-gegevens in de passieve modus. Aangezien de client het pakket opnieuw verzendt en u de initiële SYN (pakket # 1) kunt zien, is het pakket stroomopwaarts naar de firewall verloren gegaan.
In dit geval bestaat de mogelijkheid dat het SYN-pakket de server heeft bereikt, maar dat het SYN/ACK-pakket op de terugweg verloren is gegaan:
2. Er is een pakket van de server en Wireshark heeft vastgesteld dat het vorige segment niet is gezien/vastgelegd. Aangezien het niet-vastgelegde pakket van de server naar de client is verzonden en niet is gezien in de firewall-opname, betekent dit dat het pakket verloren is gegaan tussen de server en de firewall.
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 veroveringsmethode toe te passen om het problematische segment dat het pakketverlies veroorzaakt verder te isoleren.
Belangrijkste punten:
- De ontvanger (in dit geval de FTP-client) volgt de binnenkomende TCP-volgnummers. Als het detecteert dat een pakket is gemist (een verwacht volgnummer is overgeslagen), genereert het een ACK-pakket met het ACK='verwacht volgnummer dat is overgeslagen'. In dit voorbeeld is de ACK=2224386800.
- De Dup ACK activeert een TCP Fast Retransmissie (hertransmissie binnen 20 msec nadat een Duplicate ACK is ontvangen).
Wat betekenen duplicaat-ACK's?
- Een paar dubbele ACK's, maar geen daadwerkelijke heruitzendingen geven aan dat er meer kans is dat er pakketten zijn die buiten de orde komen.
- Dubbele ACK's gevolgd door daadwerkelijke heruitzendingen geven aan dat er een zekere hoeveelheid pakketverlies is.
Actie 3. Bereken de firewallverwerkingstijd voor doorvoerpakketten.
Dezelfde opname toepassen op 2 verschillende interfaces:
firepower# capture CAPI buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 firepower# capture CAPI interface OUTSIDE
Exporteer de capture check het tijdsverschil tussen ingress vs. egress pakketten
Situatie 7. Probleem met TCP-connectiviteit (pakketbeschadiging)
Probleembeschrijving:
Draadloze client (192.168.21.193) probeert verbinding te maken met een bestemmingsserver (192.168.14.250 - HTTP) en er zijn 2 verschillende scenario's:
- Wanneer de client verbinding maakt met Access Point (AP) 'A', werkt de HTTP-verbinding niet.
- Wanneer de client verbinding maakt met Access Point (AP) 'B' dan werkt de HTTP-verbinding.
Deze afbeelding toont de topologie:
Beïnvloede stroming:
SRC IP: 192 168 21 193
Dst IP: 192 168 14 250
Protocol: TCP 80
Capture-analyse
Captures inschakelen op FTD LINA-engine:
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
Vastleggingen - Functioneel scenario:
Als basislijn is het altijd erg handig om opnames te hebben van een bekend goed scenario.
Deze afbeelding toont de opname gemaakt op NGFW INSIDE interface
Deze afbeelding toont de opname gemaakt op NGFW OUTSIDE interface.
Belangrijkste punten:
- De 2 opnames zijn bijna identiek (denk aan de ISN-randomisatie).
- Er zijn geen aanwijzingen voor een pakketverlies.
- Geen out-of-order (OOO) 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' omleidingsbericht.
Vastleggingen - Bekend foutief scenario:
De inhoud van de ingress capture (CAPI).
Belangrijkste punten:
- Er is een TCP 3-weg handdruk.
- Er zijn TCP-heruitzendingen en aanwijzingen voor een pakketverlies.
- Er is een pakket (TCP ACK) dat door Wireshark wordt geïdentificeerd als Misvormd.
Deze afbeelding toont de inhoud van de regresopname (CAPO).
Belangrijkste punten:
De 2 opnamen zijn bijna identiek (overweeg de ISN-randomisatie):
- Er is een TCP 3-weg handdruk.
- Er zijn TCP-heruitzendingen en aanwijzingen voor een pakketverlies.
- Er is een pakket (TCP ACK) dat door Wireshark wordt geïdentificeerd als Misvormd.
Controleer het verkeerd gevormde pakket:
Belangrijkste punten:
- Het pakket wordt geïdentificeerd als een misvormd door Wireshark.
- Het heeft een lengte van 2 bytes.
- Er is een TCP-payload van 2 bytes.
- Het laadvermogen is 4 extra nullen (00 00).
Aanbevolen acties
De acties die in deze sectie worden vermeld, hebben als doel het probleem verder te beperken.
Actie 1. Neem extra foto's. Neem opnamen op de eindpunten op en probeer indien mogelijk de methode voor verdelen en veroveren toe te passen om de bron van de pakketbeschadiging te isoleren, bijvoorbeeld:
In dit geval werden de 2 extra Bytes toegevoegd door de switch 'A' interfacestuurprogramma en de oplossing was om de switch die de corruptie veroorzaakt te vervangen.
Situatie 8. Probleem met UDP-connectiviteit (ontbrekende pakketten)
Probleembeschrijving: Syslog-berichten (UDP 514) worden niet weergegeven op de bestemmingsserver Syslog.
Deze afbeelding toont de topologie:
Beïnvloede stroming:
SRC IP: 192 168 1 81
Dst IP: 10.10.1.73
Protocol: UDP 514
Capture-analyse
Captures inschakelen op FTD LINA-engine:
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-opnamen 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 acties die in deze sectie worden vermeld, hebben als doel het probleem verder te beperken.
Actie 1. Controleer de FTD-verbindingstabel.
Als u een specifieke verbinding wilt controleren, kunt u deze syntaxis gebruiken:
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 ingangen en uitgangen zijn hetzelfde (U-bocht).
- Het aantal bytes heeft een aanzienlijk grote waarde (~5 GBytes).
- De vlag "o" staat voor flow offload (versnelde HW-stroom). Dit is de reden waarom de FTD-opnames geen pakketten tonen. Flow offload wordt alleen ondersteund op 41xx- en 93xx-platforms. In dit geval is het apparaat een 41xx.
Actie 2. Neem opnamen op chassisniveau.
Maak verbinding met de Firepower-chassismanager en schakel vastlegging in op de ingangsinterface (E1/2 in dit geval) en backplane-interfaces (E1/9 en E1/10), zoals weergegeven in de afbeelding:
Na een paar seconden:
Vóór:
Na:
Belangrijkste punten:
- Er wordt een weergavefilter toegepast om pakketduplicaten te verwijderen en alleen syslogs weer te geven.
- Het verschil tussen de pakketten is op het microseconde-niveau. Dit duidt op een zeer hoge pakketsnelheid.
- De waarde Time to Live (TTL) neemt voortdurend af. Dit duidt op een packet loop.
Actie 3. Gebruik packet-tracer.
Aangezien de pakketten niet door de firewall LINA-engine gaan, kunt u geen live-trace (vastleggen met trace) uitvoeren, maar u kunt een geëmuleerd pakket traceren met packet-tracer:
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-routering.
Controleer de routeringstabel van de firewall om te zien of er routeringsproblemen 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 uitgang interface.
- De route werd een paar minuten geleden geleerd (0:02:37).
Actie 5. Bevestig de uptime van de verbinding.
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
Kernpunt:
- De verbinding werd ~4 minuten geleden tot stand gebracht (dit is vóór de EIGRP-routeinstallatie in de routetabel)
Actie 6. Wis de tot stand gebrachte verbinding.
In dit geval komen de pakketten overeen met een gevestigde verbinding en worden ze naar een verkeerde uitgang-interface geleid; dit veroorzaakt een lus. Dit komt door de volgorde van de firewall:
- Opzoeken van verbinding (dit heeft voorrang op het opzoeken van de globale routeringstabel).
- Network Address Translation (NAT) opzoeken - UN-NAT (destination NAT) fase heeft voorrang op PBR en route opzoeken.
- Beleidsgebaseerde routering (PBR)
- Opzoeken van globale routeringstabel
Aangezien de verbinding nooit vervalt (de Syslog-client verzendt continu pakketten terwijl de time-out van de UDP-console 2 minuten is), is het nodig om de verbinding handmatig te wissen:
firepower# clear conn address 10.10.1.73 address 192.168.1.81 protocol udp port 514 1 connection(s) deleted.
Controleer of er 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. Floating Conn Time-out configureren.
Dit is de juiste oplossing om het probleem aan te pakken en suboptimale routering te voorkomen, vooral voor UDP-stromen. Navigeer naar Apparaten > Platforminstellingen > Time-outs en stel de waarde in:
Meer informatie over de time-out voor floating conn vindt u in de opdrachtverwijzing:
Situatie 9. Probleem met HTTPS-connectiviteit (scenario 1)
Probleembeschrijving: HTTPS-communicatie tussen client 192.168.201.105 en server 192.168.202.101 kan niet worden vastgesteld
Deze afbeelding toont de topologie:
Beïnvloede stroming:
SRC IP: 192 168 201 111
Dst IP: 192 168 202 111
TCP 443 (HTTPS)
Capture-analyse
Captures inschakelen op FTD LINA-engine:
Het IP-adres dat wordt gebruikt bij de externe vastlegging is anders vanwege de configuratie voor de vertaling 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 gemaakt op NGFW INSIDE interface:
Belangrijkste punten:
- Er is een TCP 3-weg handdruk.
- De SSL-onderhandeling wordt gestart. De klant stuurt een Hello-bericht.
- Er wordt een TCP ACK naar de client verzonden.
- Er wordt een TCP RST naar de client verzonden.
Deze afbeelding toont de opname gemaakt op NGFW OUTSIDE interface.
Belangrijkste punten:
- Er is een TCP 3-weg handdruk.
- De SSL-onderhandeling wordt gestart. De klant stuurt een Hello-bericht.
- Er zijn TCP-heruitzendingen verzonden vanuit de firewall naar de server.
- Er wordt een TCP RST naar de server gestuurd.
Aanbevolen acties
De acties die in deze sectie worden vermeld, hebben als doel het probleem verder te beperken.
Actie 1. Neem extra foto's.
Een opname die op de server is gemaakt, laat zien dat de server de TLS Client Hellos heeft ontvangen met een beschadigde TCP-checksum en deze stilletjes laat vallen (er is geen TCP RST of een ander antwoordpakket naar de client):
Als je alles bij elkaar legt:
In dit geval, om te begrijpen, is het nodig om Wireshark in te schakelen op de optie Valideer de TCP-checksum indien mogelijk. Navigeer naar Bewerken > Voorkeuren > Protocollen > TCP, zoals weergegeven in de afbeelding.
In dit geval is het handig om de opnames naast elkaar te plaatsen om het volledige beeld te krijgen:
Belangrijkste punten:
- Er is een TCP 3-weg handdruk. De IP ID's zijn hetzelfde. Dit betekent dat de stroom niet door de firewall is benaderd.
- Een TLS Hello Client komt van de client met IP ID 12083. Het pakket wordt door de firewall benaderd (de firewall is in dit geval geconfigureerd met TLS-decoderingsbeleid) en de IP-ID wordt gewijzigd in 52534. Bovendien wordt de TCP-controlesom van het pakket beschadigd (vanwege een softwaredefect dat later is opgelost).
- De firewall bevindt zich in de TCP Proxy-modus en stuurt een ACK naar de client (die de server vervalst).
- De firewall ontvangt geen TCP ACK-pakket van de server en verzendt het Hello-bericht van de TLS-client opnieuw. 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 een TCP RST naar de client.
- De firewall stuurt een TCP RST naar de server.
Ter referentie:
Firepower TLS/SSL-handshake-verwerking
Situatie 10. Probleem met HTTPS-connectiviteit (scenario 2)
Probleembeschrijving: registratie FMC Smart-licentie mislukt.
Deze afbeelding toont de topologie:
Beïnvloede stroming:
SRC IP: 192.168.0.100
DST: tools.cisco.com
TCP 443 (HTTPS)
Capture-analyse
Opname inschakelen op de FMC-beheerinterface:
Probeer je opnieuw te registreren. Zodra de foutmelding verschijnt, drukt u op CTRL-C om de opname te stoppen:
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 de FMC (Systeem > Gezondheid > Monitor, selecteer het apparaat en selecteer Geavanceerde probleemoplossing), zoals in de afbeelding wordt weergegeven:
De afbeelding toont de FMC-opname op Wireshark:
Volg een van de TCP-stromen (Volgen > TCP Stream), zoals weergegeven in de afbeelding.
Belangrijkste punten:
- Er is een TCP 3-weg handdruk.
- De client (FMC) stuurt een SSL Client Hello-bericht naar het Smart Licensing-portaal.
- De SSL-sessie-ID is 0. Dit betekent dat het geen hervatte sessie is.
- De bestemmingsserver antwoordt met het bericht Server Hello, Certificate en Server Hello Done.
- De client stuurt een SSL Fatal Alert die betrekking heeft op een ‘Onbekende CA’.
- De client verzendt een TCP RST om de sessie af te sluiten.
- De gehele duur van de TCP-sessie (van oprichting tot sluiting) was ~0,5 sec.
Selecteer het servercertificaat en vouw het veld uitgevende instelling uit om de commonName te zien. In dit geval onthult de Common Name een apparaat dat Man-in-the-middle (MITM) doet.
Dit wordt getoond in deze afbeelding:
Aanbevolen acties
De acties die in deze sectie worden vermeld, hebben als doel het probleem verder te beperken.
Actie 1. Neem extra foto's.
Maak opnamen op het firewallapparaat voor doorvoer:
CAPI toont:
CAPO toont:
Deze opnames bewijzen dat de transitfirewall het servercertificaat (MITM) wijzigt
Actie 2. Controleer de apparaatlogboeken.
U kunt de FMC TS-bundel verzamelen zoals beschreven in dit document:
In dit geval toont het bestand /dir-archives/var-log/process_stdout.log berichten als 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.
Situatie 11. IPv6-verbindingsprobleem
Probleembeschrijving: interne hosts (die zich achter de INSIDE-interface van de firewall bevinden) kunnen niet communiceren met externe hosts (hosts die zich achter de OUTSIDE-interface van de firewall bevinden).
Deze afbeelding toont de topologie:
Beïnvloede stroming:
SRC IP: fc00:1:1:1:100
Dst IP: fc00:1:1:2:2
Protocol: elke
Capture-analyse
Captures inschakelen op FTD LINA-engine.
firepower# capture CAPI int INSIDE match ip any6 any6 firepower# capture CAPO int OUTSIDE match ip any6 any6
Vastleggingen - Niet-functioneel scenario
Deze opnames werden parallel met een ICMP-connectiviteitstest van IP fc00:1:1:1:1:100 (binnenrouter) naar IP fc00:1:1:2:2 (upstream router) gemaakt.
De capture on firewall INSIDE-interface bevat:
Belangrijkste punten:
- De router verzendt een IPv6 Neighbor Solicitation-bericht en vraagt om het MAC-adres van het upstream-apparaat (IP fc00:1:1:1:1).
- De firewall antwoordt met een IPv6 Neighbor-advertentie.
- De router stuurt een ICMP Echo Request.
- De firewall verzendt een IPv6 Neighbor Solicitation-bericht en vraagt om het MAC-adres van het downstreamapparaat (fc00:1:1:1:1:100).
- De router antwoordt met een IPv6-buuradvertentie.
- De router verzendt extra IPv6 ICMP Echo-verzoeken.
De capture on firewall OUTSIDE-interface bevat:
Belangrijkste punten:
- De firewall verzendt een IPv6 Neighbor Solicitation-bericht waarin om het MAC-adres van het upstream-apparaat wordt gevraagd (IP fc00:1:1:2:2).
- De router antwoordt met een IPv6-buuradvertentie.
- De firewall verzendt een IPv6 ICMP Echo Request.
- Het upstream-apparaat (router fc00:1:1:2:2) verzendt een IPv6 Neighbor Solicitation-bericht waarin om het MAC-adres van het IPv6-adres fc00:1:1:1:1:100 wordt gevraagd.
- De firewall verzendt een extra IPv6 ICMP Echo Request.
- De upstream-router verzendt een extra IPv6 Neighbor Solicitation-bericht waarin wordt gevraagd naar het MAC-adres van het IPv6-adres fc00:1:1:1:1:100.
Punt 4 is zeer interessant. Normaal gesproken vraagt de upstream router om de MAC van de firewall OUTSIDE-interface (fc00: 1: 1: 2: 2), maar in plaats daarvan vraagt het om de fc00: 1: 1: 1: 100. Dit is een indicatie van een misconfiguratie.
Aanbevolen acties
De acties die in deze sectie worden vermeld, hebben als doel het probleem verder te beperken.
Actie 1. Controleer de IPv6-buurttabel.
De firewall IPv6 Neighbor Table is correct gevuld.
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 upstream apparaatconfiguratie laat de verkeerde configuratie zien:
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
Vastleggingen - Functioneel scenario
De verandering van het subnetmasker (van /48 naar /64) loste het probleem op. Dit is de CAPI-opname in het functionele scenario.
Kernpunt:
- De router verzendt een IPv6 Neighbor Solicitation-bericht waarin om het MAC-adres van het upstream-apparaat wordt gevraagd (IP fc00:1:1:1:1::1).
- De firewall antwoordt met een IPv6 Neighbor-advertentie.
- De router verzendt ICMP-echoverzoeken en krijgt echoantwoorden.
CAPO-inhoud:
Belangrijkste punten:
- De firewall verzendt een IPv6 Neighbor Solicitation-bericht waarin om het MAC-adres van het upstream-apparaat wordt gevraagd (IP fc00:1:1:2:2).
- De firewall antwoordt met een IPv6 Neighbor-advertentie.
- De firewall stuurt een ICMP Echo Request.
- De router verzendt een IPv6 Neighbor Solicitation-bericht waarin om het MAC-adres van het downstreamapparaat wordt gevraagd (IP fc00:1:1:1:1::1).
- De firewall antwoordt met een IPv6 Neighbor-advertentie.
- De firewall verzendt ICMP-echoverzoeken en krijgt echoantwoorden.
Situatie 12. Intermitterend connectiviteitsprobleem (ARP-vergiftiging)
Probleembeschrijving: interne hosts (192.168.0.x/24) hebben intermitterende verbindingsproblemen met hosts in hetzelfde subnet
Deze afbeelding toont de topologie:
Beïnvloede stroming:
SRC IP: 192.168.0.x/24
Dst IP: 192.168.0.x/24
Protocol: elke
De ARP-cache van een interne host lijkt te zijn vergiftigd:
Capture-analyse
Een opname inschakelen op de FTD LINA-engine
Met deze opname worden alleen ARP-pakketten vastgelegd op de INSIDE-interface:
firepower# capture CAPI_ARP interface INSIDE ethernet-type arp
Vastleggingen - Niet-functioneel scenario:
De opname op de firewall INSIDE-interface bevat.
Belangrijkste punten:
- De firewall ontvangt verschillende ARP-verzoeken voor IP's binnen het 192.168.0.x/24-netwerk
- De firewall antwoordt op alle van hen (proxy-ARP) met zijn eigen MAC-adres
Aanbevolen acties
De acties die in deze sectie worden vermeld, hebben als doel het probleem verder te beperken.
Actie 1. Controleer de NAT-configuratie.
Met betrekking tot de NAT-configuratie zijn er gevallen waarin het zoekwoord no-proxy-arp het eerdere 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 op de firewall-interface uit.
Als het zoekwoord 'no-proxy-arp' het probleem niet oplost, probeer dan proxy-ARP op de interface zelf uit te schakelen. In het geval van FTD moet u op het moment van schrijven FlexConfig gebruiken en de opdracht implementeren (geef de juiste interfacenaam op).
sysopt noproxyarp INSIDE
Situatie 13. Identificeer SNMP Object Identifiers (OID's) die CPU Hogs veroorzaken
Deze case laat zien hoe bepaalde SNMP OID's voor geheugenpolling werden geïdentificeerd als de hoofdoorzaak van CPU-hogs (prestatieprobleem) op basis van de analyse van SNMP versie 3 (SNMPv3) pakketopnames.
Probleembeschrijving: Overruns op data-interfaces nemen voortdurend toe. Verder onderzoek toonde aan dat er ook CPU-hogs zijn (veroorzaakt door het SNMP-proces) die de hoofdoorzaak zijn van de interface-overruns.
De volgende stap in het probleemoplossingsproces was het identificeren van de hoofdoorzaak van de CPU-hogs veroorzaakt door het SNMP-proces en in het bijzonder het beperken van de reikwijdte van het probleem om de SNMP Object Identifiers (OID) te identificeren die, wanneer gepolst, mogelijk kunnen resulteren in CPU-hogs.
Momenteel biedt de FTD LINA-engine geen 'show'-opdracht voor SNMP-OID's die in realtime worden gepolst.
De lijst met SNMP-OID's voor polling kan worden opgehaald uit de SNMP-monitoringtool, maar in dit geval waren er deze preventieve factoren:
- De FTD-beheerder had geen toegang tot de SNMP-monitoringtool
- SNMP versie 3 met verificatie en gegevenscodering voor privacy is geconfigureerd op FTD
Capture-analyse
Aangezien de FTD-beheerder over de referenties voor de SNMP versie 3-verificatie en gegevenscodering beschikte, werd dit actieplan voorgesteld:
- SNMP-pakketopnamen maken
- Sla de vastgelegde bestanden op en gebruik de voorkeuren van het Wireshark SNMP-protocol om de referenties van SNMP versie 3 op te geven om de pakketten van SNMP versie 3 te decoderen. De gedecodeerde opnamen worden gebruikt voor de analyse en het ophalen van SNMP-OID's
SNMP-pakketopnamen configureren op de interface die wordt gebruikt in de hostconfiguratie van de snmp-server:
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.
- De PDU van het SNMP-protocol kon niet worden gedecodeerd omdat privKey niet bekend is bij Wireshark.
- De waarde van de gecodeerde PDU primitief.
Aanbevolen acties
De acties die in deze sectie worden vermeld, hebben als doel het probleem verder te beperken.
Actie 1. De SNMP-opnamen decoderen.
Sla de vastgelegde bestanden op en bewerk de voorkeuren van het Wireshark SNMP-protocol om de referenties van SNMP versie 3 op te geven om de pakketten te decoderen.
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 Wireshark, selecteer een SNMP-pakket en navigeer naar Protocolvoorkeuren > Tabel Gebruikers, zoals weergegeven in de afbeelding:
In de SNMP-gebruikerstabel zijn de SNMP versie 3-gebruikersnaam, het verificatiemodel, het verificatiewachtwoord, het privacyprotocol en het privacywachtwoord opgegeven (de daadwerkelijke referenties worden hieronder niet weergegeven):
Nadat de SNMP-gebruikersinstellingen waren toegepast, toonde Wireshark gedecodeerde SNMP-PDU's:
Belangrijkste punten:
- De SNMP-monitoringtools gebruikten SNMP getBulkRequest om de bovenliggende OID 1.3.6.1.4.1.9.9.221.1 en gerelateerde OID's op te vragen en te doorlopen.
- De FTD reageerde op elke getBulkRequest met get-response die OID's bevatten die verband houden met 1.3.6.1.4.1.9.9.221.1.
Actie 2. Identificeer de SNMP OID's.
SNMP Object Navigator toonde aan dat OID 1.3.6.1.4.1.9.9.221.1 behoort tot de Management Information Base (MIB) met de naam CISCO-ENHANCED-MEMPOOL-MIB, zoals weergegeven in de afbeelding:
De OID's in een leesbaar formaat in Wireshark weergeven:
- Download de MIB CISCO-ENHANCED-MEMPOOL-MIB en zijn afhankelijkheden, zoals weergegeven in de afbeelding:
2. In Wireshark is in Bewerken > Voorkeuren > Naam resolutie het venster OID-resolutie inschakelen ingeschakeld. Geef in het venster MIB- en PIB-paden de map op met de gedownloade MIB's en in SMI-modules (MIB- en PIB-modules). De CISCO-ENHANCED-MEMPOOL-MIB wordt automatisch toegevoegd aan de lijst met modules:
3. Zodra Wireshark opnieuw is gestart, wordt de OID-resolutie geactiveerd:
Op basis van de gedecodeerde uitvoer van het vastleggingsbestand werd het SNMP-monitoringprogramma periodiek (met een interval van 10 seconden) gebruikt om gegevens te peilen over het gebruik van geheugenpools op de FTD. Zoals uitgelegd in het TechNote-artikel ASA SNMP Polling for Memory-Related Statistics, resulteert het pollen van het gebruik van de Global Shared Pool (GSP) met SNMP in een hoog CPU-gebruik. In dit geval van de opnames was het duidelijk dat het gebruik van de Global Shared Pool periodiek werd gepolst als onderdeel van SNMP getBulkRequest primitive.
Om de CPU-hogs veroorzaakt door het SNMP-proces te minimaliseren, werd aanbevolen om de mitigatiestappen voor de CPU Hogs voor SNMP te volgen die in het artikel worden genoemd en te voorkomen dat de OID's met betrekking tot GSP worden ondervraagd. Zonder de SNMP-enquête voor de OID's die betrekking hebben op GSP werden geen CPU-hogs waargenomen die werden veroorzaakt door het SNMP-proces en nam de snelheid van overschrijdingen aanzienlijk af.
Gerelateerde informatie
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
3.0 |
31-Jul-2024
|
Hercertificering, Alt Text, vaste kopteksten, interpunctie en HTML SEO-optimalisatie. |
2.0 |
02-Jun-2023
|
hercertificering |
1.0 |
21-Nov-2019
|
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)