Analisi delle acquisizioni di Firepower Firewall per la risoluzione efficace dei problemi di rete
Sommario
Introduzione
Questo documento descrive varie tecniche di analisi dell'acquisizione dei pacchetti che mirano a risolvere in modo efficace i problemi relativi alla rete.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- Architettura della piattaforma Firepower
- Log NGFW
- Packet-tracer NGFW
Inoltre, prima di iniziare ad analizzare le acquisizioni dei pacchetti, si consiglia di soddisfare i seguenti requisiti:
- Conoscere il protocollo - Non iniziare a controllare l'acquisizione di un pacchetto se non si comprende come funziona il protocollo acquisito.
- Conoscere la topologia: è necessario conoscere tutti i dispositivi di transito. Se ciò non è possibile, è necessario conoscere almeno i dispositivi a monte e a valle.
- Conoscere l'accessorio - È necessario sapere in che modo il dispositivo gestisce i pacchetti, quali sono le interfacce interessate (in entrata e in uscita), qual è l'architettura del dispositivo e quali sono i vari punti di acquisizione.
- Conoscere la configurazione - È necessario sapere in che modo il dispositivo deve gestire il flusso di un pacchetto in termini di:
- Interfaccia di routing/uscita
- Criteri applicati
- NAT (Network Address Translation)
- Conoscere gli strumenti disponibili - Oltre alle clip, si consiglia di essere pronti ad applicare altri strumenti e tecniche (come il logging e i tracer) e, se necessario, di correlarli ai pacchetti acquisiti
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
- La maggior parte degli scenari si basa su FP4140 con software FTD 6.5.x.
- FMC con software 6.5.x.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
L'acquisizione dei pacchetti è uno degli strumenti di risoluzione dei problemi più sottovalutati oggi disponibili. Ogni giorno, Cisco TAC risolve molti problemi relativi all'analisi dei dati acquisiti.
Obiettivo di questo documento è aiutare i tecnici di rete e della sicurezza a identificare e risolvere i problemi comuni della rete, basandosi principalmente sull'analisi dell'acquisizione dei pacchetti.
Tutti gli scenari presentati in questo documento si basano sui casi effettivi degli utenti rilevati nel Cisco Technical Assistance Center (TAC).
Il documento descrive i pacchetti acquisiti da un punto di vista di Cisco Next-Generation Firewall (NGFW), ma gli stessi concetti possono essere applicati anche ad altri tipi di dispositivi.
Come raccogliere ed esportare le clip sulla famiglia di prodotti NGFW?
Nel caso di un'appliance Firepower (1xxx, 21xx, 41xx, 93xx) e di un'applicazione Firepower Threat Defense (FTD), è possibile visualizzare un'elaborazione dei pacchetti come mostrato nell'immagine.
- Un pacchetto entra nell'interfaccia in entrata e viene gestito dallo switch interno dello chassis.
- Il pacchetto entra nel motore FTD Lina che esegue principalmente controlli L3/L4.
- Se la politica richiede che il pacchetto sia ispezionato dal motore Snort (principalmente l'ispezione L7).
- Il motore Snort restituisce un verdetto per il pacchetto.
- In base a questo verdetto, il motore LINA elimina il pacchetto o lo inoltra.
- Il pacchetto attraversa lo chassis attraverso lo switch interno dello chassis.
In base all'architettura mostrata, le clip FTD possono essere acquisite in tre (3) posti diversi:
- FXOS
- Motore FTD Lina
- FTD Motore Snort
Raccogli acquisizioni FXOS
Il processo è descritto nel presente documento:
Le riprese FXOS possono essere effettuate solo in entrata dal punto di vista dello switch interno; l'immagine mostra questa schermata.
Qui mostrati, questi sono due punti di acquisizione per direzione (a causa dell'architettura dello switch interno).
I pacchetti acquisiti ai punti 2, 3 e 4 hanno un tag di rete virtuale (VNTag).
Abilita e raccogli acquisizioni di linea FTD
Punti di acquisizione principali:
- Interfaccia in ingresso
- Interfaccia in uscita
- ASP (Accelerated Security Path)
È possibile utilizzare l'interfaccia utente di Firepower Management Center (FMC UI) o l'interfaccia CLI di FTD per abilitare e raccogliere le acquisizioni di Lina FTD.
Abilitare l'acquisizione dalla CLI sull'interfaccia INSIDE:
firepower# capture CAPI interface INSIDE match icmp host 192.168.103.1 host 192.168.101.1
Questa acquisizione corrisponde al traffico tra gli indirizzi IP 192.168.103.1 e 192.168.101.1 in entrambe le direzioni.
Abilitare l'acquisizione ASP per visualizzare tutti i pacchetti scartati dal motore Lina FTD:
firepower# capture ASP type asp-drop all
Esportare un'acquisizione Lina FTD in un server FTP:
firepower# copy /pcap capture:CAPI ftp://ftp_username:ftp_password@192.168.78.73/CAPI.pcap
Esportare un'acquisizione Lina FTD in un server TFTP:
firepower# copy /pcap capture:CAPI tftp://192.168.78.73
A partire dalla versione 6.2.x di FMC è possibile abilitare e raccogliere le acquisizioni di Lina FTD dall'interfaccia utente di FMC.
Un altro modo per raccogliere le acquisizioni FTD da un firewall gestito da FMC è questo.
Passaggio 1
In caso di acquisizione LINA o ASP, copiare l'acquisizione sul disco FTD.
firepower# copy /pcap capture:capin disk0:capin.pcap Source capture name [capin]? Destination filename [capin.pcap]? !!!!
Passaggio 2
Passare alla modalità Expert, individuare l'acquisizione salvata e copiarla nella posizione /ngfw/var/common:
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
Passaggio 3
Accedere al FMC che gestisce l'FTD e selezionare Dispositivi > Gestione dispositivi. Individuare il dispositivo FTD e selezionare l'icona Risoluzione problemi:
Passaggio 4
Selezionare Advanced Troubleshooting (Risoluzione avanzata problemi):
Specificare il nome del file di acquisizione e selezionare Scarica:
Per ulteriori esempi su come abilitare/raccogliere le acquisizioni dall'interfaccia utente di FMC, vedere questo documento:
Abilita e raccogli acquisizioni di snort FTD
Il punto di cattura è mostrato nell'immagine qui.
Abilita acquisizione a livello di snort:
> 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
Per scrivere l'acquisizione in un file denominato capture.pcap e copiarlo tramite FTP su un server remoto:
> 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. >
Per altri esempi di acquisizione a livello di snort che includono filtri di acquisizione diversi, consultare questo documento:
Risoluzione dei problemi
Caso 1. Nessun TCP SYN su interfaccia in uscita
La topologia è mostrata nell'immagine qui:
Descrizione del problema: HTTP non funziona
Flusso interessato:
Src IP: 192.168.0.100
Dst IP: 10.10.1.100
Protocollo: TCP 80
Analisi acquisizione
Abilita le clip sul motore LINA FTD:
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
Clip - Scenario funzionale:
Come base, è sempre molto utile avere acquisizioni da uno scenario funzionale.
La cattura è stata effettuata con l'interfaccia NGFW INSIDE, come mostrato nell'immagine:
Considerazioni principali:
- Handshake TCP a 3 vie.
- Scambio bidirezionale di dati.
- Nessun ritardo tra i pacchetti (in base alla differenza di tempo tra i pacchetti)
- L'indirizzo MAC di origine è il dispositivo downstream corretto.
Le immagini acquisite tramite l'interfaccia NGFW OUTSIDE sono mostrate nell'immagine seguente:
Considerazioni principali:
- Stessi dati dell'acquisizione CAPI.
- L'indirizzo MAC di destinazione è il dispositivo upstream corretto.
Acquisizioni - Scenario non funzionale
Dalla CLI del dispositivo le clip hanno questo aspetto:
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
Contenuto CAPI:
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
Questa è l'immagine di CAPI capture in Wireshark:
Considerazioni principali:
- Vengono visualizzati solo i pacchetti TCP SYN (nessun handshake a 3 vie TCP).
- Impossibile stabilire due sessioni TCP (porta di origine 3171 e 3172). Il client di origine invia nuovamente i pacchetti TCP SYN. Questi pacchetti ritrasmessi vengono identificati da Wireshark come ritrasmissioni TCP.
- Le ritrasmissioni TCP avvengono ogni ~3, 6, ecc.
- L'indirizzo MAC di origine proviene dal dispositivo downstream corretto.
Sulla base delle due catture si può concludere che:
- Un pacchetto di una 5-tupla specifica (src/dst IP, src/dst port, protocollo) arriva sul firewall sull'interfaccia prevista (INSIDE).
- Un pacchetto non esce dal firewall sull'interfaccia prevista (ESTERNA).
Azioni consigliate
Le azioni elencate in questa sezione hanno lo scopo di limitare ulteriormente il problema.
Azione 1. controllare la traccia di un pacchetto emulato.
Utilizzare lo strumento packet-tracer per verificare come deve essere gestito un pacchetto dal firewall. Se il pacchetto viene scartato dai criteri di accesso del firewall, la traccia del pacchetto emulato avrà un aspetto simile al seguente output:
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
Azione 2. Controllare le tracce dei pacchetti live.
Abilitare la traccia dei pacchetti per controllare come i pacchetti TCP SYN reali vengono gestiti dal firewall. Per impostazione predefinita, vengono tracciati solo i primi 50 pacchetti in entrata:
firepower# capture CAPI trace
Cancellare il buffer di acquisizione:
firepower# clear capture /all
Se il pacchetto viene scartato dai criteri di accesso del firewall, la traccia avrà un aspetto simile al seguente output:
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
Azione 3. Controllare i registri Lina FTD.
Per configurare Syslog su FTD tramite FMC, controllare questo documento:
Si consiglia di configurare un server Syslog esterno per i log Lina FTD. Se non è configurato alcun server Syslog remoto, abilitare i log del buffer locale sul firewall durante la risoluzione dei problemi. La configurazione del log mostrata in questo esempio è un buon punto di partenza:
firepower# show run logging … logging enable logging timestamp logging buffer-size 1000000 logging buffered informational
Impostare il cercapersone terminale su 24 linee per controllare il cercapersone terminale:
firepower# terminal pager 24
Cancellare il buffer di acquisizione:
firepower# clear logging buffer
Verificare la connessione e controllare i registri con un filtro parser. Nell'esempio i pacchetti vengono scartati dai criteri di accesso del 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]
Azione 4. Controllare le gocce ASP del firewall.
Se si sospetta che il pacchetto sia stato scartato dal firewall, è possibile visualizzare i contatori di tutti i pacchetti scartati dal firewall a livello di software:
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
È possibile abilitare le acquisizioni per visualizzare tutte le perdite a livello di software ASP:
firepower# capture ASP type asp-drop all buffer 33554432 headers-only
Per controllare il contenuto dell'acquisizione, è possibile utilizzare un filtro per restringere la ricerca:
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 questo caso, poiché i pacchetti vengono già tracciati a livello di interfaccia, la causa del rilascio non viene menzionata nell'acquisizione ASP. Tenere presente che un pacchetto può essere tracciato solo in un punto (interfaccia in entrata o rilascio ASP). In tal caso, è consigliabile accettare più rilasci ASP e impostare un motivo di rilascio ASP specifico. Di seguito è riportato un approccio consigliato:
1. Cancella i contatori di rilascio ASP correnti:
firepower# clear asp drop
2. Inviare il flusso che si sta risolvendo attraverso il firewall (eseguire un test).
3. Controllare nuovamente i contatori a discesa ASP e notare che quelli aumentati.
firepower# show asp drop Frame drop: No route to host (no-route) 234 Flow is denied by configured rule (acl-drop) 71
4. Abilitare le acquisizioni ASP per le gocce specifiche rilevate:
firepower# capture ASP_NO_ROUTE type asp-drop no-route firepower# capture ASP_ACL_DROP type asp-drop acl-drop
5. Inviare il flusso per il quale si stanno risolvendo i problemi attraverso il firewall (eseguire un test).
6. Controllare le acquisizioni ASP. In questo caso, i pacchetti sono stati scartati a causa di un percorso assente:
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>
Azione 5. Controllare la tabella delle connessioni Lina FTD.
In alcuni casi, il pacchetto deve uscire dall'interfaccia 'X', ma in altri casi, per qualsiasi motivo, il pacchetto esce dall'interfaccia 'Y'. La determinazione dell'interfaccia di uscita del firewall si basa sul seguente ordine di funzionamento:
- Ricerca connessione stabilita
- Ricerca NAT (Network Address Translation) - La fase UN-NAT (NAT di destinazione) ha la precedenza sulla ricerca PBR e route.
- Policy-Based Routing (PBR)
- Ricerca nella tabella di routing
Per controllare la tabella di connessione FTD:
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
Considerazioni principali:
- In base alle bandiere (Aa) la connessione è embrionale (aperta a metà - solo TCP SYN è stato visto dal firewall).
- In base alle porte di origine/destinazione, l'interfaccia in entrata è INSIDE e l'interfaccia in uscita è DMZ.
È possibile visualizzare questa immagine qui:
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
Uscita 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
Output 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
Inoltre, il comando show conn long visualizza gli IP NAT tra parentesi in caso di Network Address Translation:
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
Azione 6. Controllare la cache ARP (Address Resolution Protocol) del firewall.
Se il firewall non è in grado di risolvere l'hop successivo, scarta automaticamente il pacchetto originale (in questo caso TCP SYN) e invia continuamente le richieste ARP finché non risolve l'hop successivo.
Per visualizzare la cache ARP del firewall, utilizzare il comando:
firepower# show arp
Inoltre, per verificare la presenza di host non risolti, è possibile utilizzare il comando:
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
Se si desidera controllare ulteriormente l'operazione ARP, è possibile abilitare un'acquisizione specifica per ARP:
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 questo output, il firewall (192.168.2.50) tenta di risolvere l'hop successivo (192.168.2.72), ma non esiste una risposta ARP
L'output riportato di seguito mostra uno scenario funzionale con una risoluzione ARP appropriata:
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
Nel caso in cui non sia presente una voce ARP, una traccia di un pacchetto TCP SYN live mostra:
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
Come è possibile notare nell'output, il comando trace restituisce Action: allow anche quando l'hop successivo non è raggiungibile e il pacchetto viene scartato automaticamente dal firewall. In questo caso, è necessario controllare anche lo strumento di traccia dei pacchetti perché fornisce un output più accurato:
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
Nelle versioni ASA/Firepower recenti, il messaggio precedente è stato ottimizzato per:
Drop-reason: (no-v4-adjacency) No valid V4 adjacency. Check ARP table (show arp) has entry for nexthop., Drop-location: f
Sintetico delle possibili cause e delle azioni consigliate
Se si vede solo un pacchetto TCP SYN sulle interfacce in entrata, ma non un pacchetto TCP SYN inviato dall'interfaccia in uscita prevista, alcune possibili cause sono:
| Possibile causa |
Azioni consigliate |
| Il pacchetto viene scartato dai criteri di accesso del firewall. |
|
| Il filtro di acquisizione è errato. |
|
| Il pacchetto viene inviato a un'interfaccia di uscita diversa. |
Se il pacchetto viene inviato a un'interfaccia errata perché corrisponde a una connessione corrente, utilizzare il comando clear conn address e specificare la 5-tupla della connessione da cancellare. |
| Non c'è un percorso verso la destinazione. |
|
| Nessuna voce ARP sull'interfaccia in uscita. |
|
| Interfaccia in uscita inattiva. |
Controllare l'output del comando show interface ip brief sul firewall e verificare lo stato dell'interfaccia. |
Caso 2. TCP SYN da client, TCP RST da server
Nell'immagine è illustrata la topologia:
Descrizione del problema: HTTP non funziona
Flusso interessato:
Src IP: 192.168.0.100
Dst IP: 10.10.1.100
Protocollo: TCP 80
Analisi acquisizione
Abilitare le acquisizioni sul motore LINA FTD.
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
Acquisizioni - Scenario non funzionale:
Dalla CLI del dispositivo le clip hanno il seguente aspetto:
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
Contenuto CAPI:
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> ...
Contenuto del capo:
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>
Questa immagine mostra l'acquisizione di CAPI in Wireshark.
Considerazioni principali:
- L'origine invia un pacchetto TCP SYN.
- Viene inviato TCP RST verso l'origine.
- L'origine trasmette nuovamente i pacchetti TCP SYN.
- Gli indirizzi MAC sono corretti (sui pacchetti in entrata l'indirizzo MAC di origine appartiene al router a valle, l'indirizzo MAC di destinazione appartiene all'interfaccia INSIDE del firewall).
Questa immagine mostra l'acquisizione di CAPO in Wireshark:
Considerazioni principali:
- L'origine invia un pacchetto TCP SYN.
- Sull'interfaccia ESTERNA arriva un TCP RST.
- L'origine trasmette nuovamente i pacchetti TCP SYN.
- Gli indirizzi MAC sono corretti (sui pacchetti in uscita, il firewall ESTERNO è l'indirizzo MAC di origine, il router a monte è l'indirizzo MAC di destinazione).
Sulla base delle due catture si può concludere che:
- L'handshake a 3 vie TCP tra il client e il server non viene completato
- TCP RST in arrivo sull'interfaccia in uscita del firewall
- Il firewall comunica con i dispositivi upstream e downstream appropriati (in base agli indirizzi MAC)
Azioni consigliate
Le azioni elencate in questa sezione hanno lo scopo di limitare ulteriormente il problema.
Azione 1. Controllare l'indirizzo MAC di origine che invia TCP RST.
Verificare che l'indirizzo MAC di destinazione rilevato nel pacchetto TCP SYN sia lo stesso dell'indirizzo MAC di origine rilevato nel pacchetto TCP RST.
L'obiettivo di questo controllo è confermare due elementi:
- Verificare che non vi sia alcun flusso asimmetrico.
- Verificare che l'indirizzo MAC appartenga al dispositivo upstream previsto.
Azione 2. Confrontare i pacchetti in entrata e in uscita.
Confrontare visivamente i 2 pacchetti di Wireshark per verificare che il firewall non li modifichi/corrompa. Sono evidenziate alcune differenze previste.
Considerazioni principali:
- I timestamp sono diversi. D'altro canto, la differenza deve essere minima e ragionevole. Ciò dipende dalle funzionalità e dai controlli dei criteri applicati al pacchetto, nonché dal carico sul dispositivo.
- La lunghezza dei pacchetti può differire, soprattutto se c'è un'intestazione dot1Q aggiunta/rimossa dal firewall su un solo lato.
- Gli indirizzi MAC sono diversi.
- L'intestazione dot1Q può essere inserita se l'acquisizione è stata effettuata su una sottointerfaccia.
- Gli indirizzi IP sono diversi se al pacchetto viene applicato NAT o Port Address Translation (PAT).
- Le porte di origine o di destinazione sono diverse se al pacchetto viene applicato NAT o PAT.
- Se si disattiva l'opzione Wireshark Relative Sequence Number, si osserverà che i numeri di sequenza TCP/riconoscimento vengono modificati dal firewall a causa della randomizzazione dell'ISN.
- Alcune opzioni TCP possono essere sovrascritte. Ad esempio, per impostazione predefinita il firewall modifica il valore TCP Maximum Segment Size (MSS) a 1380 per evitare la frammentazione dei pacchetti nel percorso di transito.
Azione 3. Effettuare una cattura a destinazione.
Se possibile, eseguire una cattura nella stessa destinazione. Se ciò non fosse possibile, eseguire la cattura il più vicino possibile alla destinazione. L'obiettivo è verificare chi invia TCP RST (il server di destinazione è un altro dispositivo nel percorso?).
Caso 3. Handshake TCP a 3 vie + RST da un endpoint
Nell'immagine è illustrata la topologia:
Descrizione del problema: HTTP non funziona
Flusso interessato:
Src IP: 192.168.0.100
Dst IP: 10.10.1.100
Protocollo: TCP 80
Analisi acquisizione
Abilitare le acquisizioni sul motore LINA FTD.
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
Acquisizioni - Scenario non funzionale:
Ci sono un paio di modi diversi in cui questo problema può manifestarsi nelle clip.
3.1 - Handshake TCP a 3 vie + RST ritardato dal client
Sia il firewall acquisisce CAPI che CAPO contengono gli stessi pacchetti, come mostrato nell'immagine.
Considerazioni principali:
- L'handshake a 3 vie TCP attraversa il firewall.
- Il server ritrasmette il SYN/ACK.
- Il client ritrasmette l'ACK.
- Dopo circa 20 secondi il client si arrende e invia un RST TCP.
Azioni consigliate
Le azioni elencate in questa sezione hanno lo scopo di limitare ulteriormente il problema.
Azione 1. Acquisire le clip il più vicino possibile ai due endpoint.
Le acquisizioni del firewall indicano che l'ACK del client non è stato elaborato dal server. Ciò si basa sui seguenti fatti:
- Il server ritrasmette il SYN/ACK.
- Il client ritrasmette l'ACK.
- Il client invia un TCP RST o FIN/ACK prima di qualsiasi dato.
La cattura sul server mostra il problema. L'ACK client dall'handshake TCP a 3 vie non è mai arrivato:
3.2 - Handshake TCP a 3 vie + FIN/ACK ritardato dal client + RST ritardato dal server
Sia il firewall acquisisce CAPI che CAPO contengono gli stessi pacchetti, come mostrato nell'immagine.
Considerazioni principali:
- L'handshake a 3 vie TCP attraversa il firewall.
- Dopo circa 5 sec il client invia un messaggio FIN/ACK.
- Dopo circa 20 secondi, il server si arrende e invia un RST TCP.
In base a questa acquisizione si può concludere che, anche se esiste un handshake a 3 vie TCP attraverso il firewall, sembra che non venga mai effettivamente completato su un endpoint (le ritrasmissioni indicano questa condizione).
Azioni consigliate
Come nel caso 3.1
3.3 - Handshake TCP a 3 vie + RST ritardato dal client
Sia il firewall acquisisce CAPI che CAPO contengono gli stessi pacchetti, come mostrato nell'immagine.
Considerazioni principali:
- L'handshake a 3 vie TCP attraversa il firewall.
- Dopo circa 20 secondi il client si arrende e invia un RST TCP.
Sulla base di tali acquisizioni si può concludere che:
- Dopo 5-20 secondi, un endpoint rinuncia e decide di terminare la connessione.
Azioni consigliate
Come nel caso 3.1
3.4 - Handshake TCP a 3 vie + RST immediato dal server
Entrambi i firewall acquisiscono CAPI e CAPO contengono questi pacchetti, come mostrato nell'immagine.
Considerazioni principali:
- L'handshake a 3 vie TCP attraversa il firewall.
- Il server invia un segnale TCP RST pochi millisecondi dopo il pacchetto ACK.
Azioni consigliate
Azione: acquisire le clip il più vicino possibile al server.
Un RST TCP immediato dal server potrebbe indicare un server malfunzionante o un dispositivo nel percorso che invia l'RST TCP. Eseguire un'acquisizione sul server stesso e determinare l'origine di TCP RST.
Caso 4. TCP RST dal client
Nell'immagine è illustrata la topologia:
Descrizione del problema: HTTP non funziona.
Flusso interessato:
Src IP: 192.168.0.100
Dst IP: 10.10.1.100
Protocollo: TCP 80
Analisi acquisizione
Abilita le acquisizioni sul motore LINA FTD.
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
Acquisizioni - Scenario non funzionale:
Questi sono i contenuti CAPI.
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
Questi sono i contenuti di CAPO:
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
I registri del firewall visualizzano:
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
Questi registri indicano la presenza di una RST TCP che arriva all'interfaccia INSIDE del firewall
CAPI di Wireshark:
Seguire il primo flusso TCP, come mostrato nell'immagine.
In Wireshark, selezionare Modifica > Preferenze > Protocolli > TCP e deselezionare l'opzione Numeri di sequenza relativi come mostrato nell'immagine.
Questa immagine mostra il contenuto del primo flusso in CAPI capture:
Considerazioni principali:
- Il client invia un pacchetto TCP SYN.
- Il client invia un pacchetto TCP RST.
- Il valore del numero di sequenza del pacchetto TCP SYN è uguale a 4098574664.
Lo stesso flusso nell'acquisizione CAPO contiene:
Considerazioni principali:
- Il client invia un pacchetto TCP SYN. Il firewall rende casuale l'ISDN.
- Il client invia un pacchetto TCP RST.
Sulla base delle due acquisizioni si può concludere che:
- Non esiste alcun handshake TCP a 3 vie tra il client e il server.
- È presente un RST TCP che proviene dal client. Il valore del numero di sequenza TCP RST nell'acquisizione CAPI è 1386249853.
Azioni consigliate
Le azioni elencate in questa sezione hanno lo scopo di limitare ulteriormente il problema.
Azione 1. Acquisisci un'immagine sul client.
In base alle acquisizioni raccolte sul firewall, esiste una forte indicazione di un flusso asimmetrico. Ciò si basa sul fatto che il client invia un RST TCP con un valore di 1386249853 (l'ISN randomizzato):
Considerazioni principali:
- Il client invia un pacchetto TCP SYN. Il numero di sequenza è 4098574664 ed è lo stesso di quello visualizzato sull'interfaccia CAPI (Firewall INSIDE Interface)
- È presente un TCP SYN/ACK con numero ACK 1386249853 (previsto a causa della randomizzazione ISDN). Il pacchetto non è stato rilevato nelle acquisizioni del firewall
- Il client invia una richiesta RST TCP perché si aspettava un valore SYN/ACK con numero ACK pari a 4098574665, ma ha ricevuto il valore di 1386249853
Ciò può essere visualizzato come:
Azione 2. Controllare il routing tra il client e il firewall.
Confermare che:
- Gli indirizzi MAC visualizzati nelle clip sono quelli previsti.
- Verificare che il routing tra il firewall e il client sia simmetrico.
In alcuni scenari, l'RST proviene da un dispositivo situato tra il firewall e il client mentre nella rete interna è presente un routing asimmetrico. Nell'immagine viene in genere visualizzato un caso:
In questo caso, l'acquisizione ha questo contenuto. Si noti la differenza tra l'indirizzo MAC di origine del pacchetto TCP SYN e l'indirizzo MAC di origine del pacchetto TCP RST e l'indirizzo MAC di destinazione del pacchetto TCP SYN/ACK:
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)
...
Caso 5. Trasferimento TCP lento (scenario 1)
Descrizione del problema:
Il trasferimento SFTP tra gli host 10.11.4.171 e 10.77.19.11 è lento. Sebbene la larghezza di banda minima (BW) tra i 2 host sia di 100 Mbps, la velocità di trasferimento non supera i 5 Mbps.
Allo stesso tempo, la velocità di trasferimento tra gli host 10.11.2.124 e 172.25.18.134 è notevolmente superiore.
Nozioni di base:
La velocità massima di trasferimento per una singola connessione TCP è determinata dal BDP (Bandwidth Delay Product). La formula utilizzata è illustrata nell'immagine:
Per ulteriori informazioni sul BDP, consultare le risorse disponibili al seguente indirizzo:
- Perché l'applicazione utilizza solo 10 Mbps Anche il collegamento è 1 Gbps?
- BRKSEC-3021 - Avanzate - Ottimizzazione delle prestazioni del firewall
Scenario 1. Trasferimento lento
Nell'immagine è illustrata la topologia:
Flusso interessato:
Src IP: 10.11.4.171
Dst IP: 10.7.19.11
Protocollo: SFTP (FTP over SSH)
Analisi acquisizione
Abilita acquisizioni sul motore LINA FTD:
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.
Azioni consigliate
Le azioni elencate in questa sezione hanno lo scopo di limitare ulteriormente il problema.
Calcolo del tempo di andata e ritorno (RTT)
Identificare innanzitutto il flusso di trasferimento e seguirlo:
Cambiate la vista di Wireshark in modo da visualizzare i secondi trascorsi dal precedente pacchetto visualizzato. Questo semplifica il calcolo dell'RTT:
L'RTT può essere calcolato sommando i valori temporali tra due scambi di pacchetti (uno verso l'origine e uno verso la destinazione). In questo caso, il pacchetto 2 mostra il segnale RTT tra il firewall e il dispositivo che ha inviato il pacchetto SYN/ACK (server). Nel pacchetto 3 viene mostrato il segnale RTT tra il firewall e il dispositivo che ha inviato il pacchetto ACK (client). L'aggiunta dei due numeri fornisce una buona stima dell'RTT end-to-end:
RTT ≈ 80 msec
Calcolo dimensioni finestra TCP
Espandere un pacchetto TCP, espandere l'intestazione TCP, selezionare Dimensione calcolata finestra e selezionare Applica come colonna:
Controllare la colonna Valore dimensioni finestra calcolate per verificare il valore massimo delle dimensioni della finestra durante la sessione TCP. È inoltre possibile selezionare il nome della colonna e ordinare i valori.
Se si verifica il download di un file (server > client), è necessario controllare i valori annunciati dal server. Il valore massimo delle dimensioni della finestra annunciato dal server determina la velocità di trasferimento massima raggiunta.
In questo caso, le dimensioni della finestra TCP sono ≈ 50000 byte
In base a questi valori e con l'uso della formula Prodotto ritardo larghezza di banda si ottiene la massima larghezza di banda teorica che può essere raggiunta in queste condizioni: 50000*8/0.08 = 5 Mbps larghezza di banda teorica massima.
In questo caso, corrisponde a ciò che il client sperimenta.
Controllare attentamente l'handshake TCP a 3 vie. Entrambi i lati, e soprattutto il server, annunciano un valore di scala della finestra pari a 0 che significa 2^0 = 1 (nessuna scala delle finestre). Questo influisce negativamente sulla velocità di trasferimento:
A questo punto, è necessario eseguire un'acquisizione sul server, verificare che sia quello che annuncia la scala della finestra = 0 e riconfigurarla (consultare la documentazione del server per informazioni su come eseguire questa operazione).
Scenario 2. Trasferimento rapido
Esaminiamo ora lo scenario positivo (trasferimento rapido attraverso la stessa rete):
Topologia:
Il flusso di interessi:
Src IP: 10.11.2.124
Dst IP: 172.25.18.134
Protocollo: SFTP (FTP over SSH)
Abilita acquisizioni sul motore LINA FTD
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
Calcolo del tempo di andata e ritorno (RTT, Round Trip Time): In questo caso, il valore RTT è ≈ 300 msec.
Calcolo dimensioni finestra TCP: il server annuncia un fattore di scala della finestra TCP pari a 7.
Le dimensioni della finestra TCP del server sono ≈ 1600000 byte:
In base a questi valori, la formula Ritardo larghezza di banda prodotto fornisce:
1600000*8/0,3 = velocità teorica massima di trasferimento 43 Mbps
Caso 6. Trasferimento TCP lento (scenario 2)
Descrizione del problema: il trasferimento di file FTP (download) attraverso il firewall è lento.
Nell'immagine è illustrata la topologia:
Flusso interessato:
Src IP: 192.168.2.220
Dst IP: 192.168.1.220
Protocollo: FTP
Analisi acquisizione
Abilitare le acquisizioni sul motore LINA FTD.
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
Selezionare un pacchetto FTP-DATA e seguire il canale dati FTP sull'acquisizione CAPI (FTD INSIDE capture):
Contenuto del flusso FTP-DATA:
Il contenuto dell'acquisizione di CAPO:
Considerazioni principali:
- Sono presenti pacchetti TCP non in ordine (OO).
- Ritrasmissione TCP.
- C'è un'indicazione di una perdita di pacchetto (pacchetti scartati).
Azioni consigliate
Le azioni elencate in questa sezione hanno lo scopo di limitare ulteriormente il problema.
Azione 1. Identificare l'ubicazione di perdita del pacchetto.
In casi come questo, è necessario acquisire immagini simultaneamente e usare la metodologia "divide and conquista" per identificare i segmenti di rete che causano la perdita di pacchetti. Dal punto di vista del firewall, ci sono 3 scenari principali:
- La perdita di pacchetti è causata dal firewall stesso.
- La perdita di pacchetti è causata a valle del dispositivo firewall (direzione da server a client).
- La perdita di pacchetti è causata a monte del dispositivo firewall (direzione dal client al server).
Perdita di pacchetti causata dal firewall: per stabilire se la perdita di pacchetti è causata dal firewall, è necessario confrontare l'acquisizione in entrata con l'acquisizione in uscita. Ci sono molti modi per confrontare 2 diverse clip. In questa sezione viene illustrato un modo per eseguire questa operazione.
Procedura per confrontare 2 acquisizioni e identificare la perdita di pacchetti
Passaggio 1. Verificare che le 2 clip contengano pacchetti provenienti dalla stessa finestra temporale. Ciò significa che in un'acquisizione non devono essere presenti pacchetti acquisiti prima o dopo l'altra. A tale scopo, è possibile procedere in diversi modi:
- Controllare il primo e l'ultimo valore di identificazione (ID) dell'IP del pacchetto.
- Controllare i valori del primo e dell'ultimo timestamp del pacchetto.
In questo esempio si nota che i primi pacchetti di ciascuna acquisizione hanno gli stessi valori di ID IP:
In caso contrario:
- Confrontare gli indicatori orari del primo pacchetto di ciascuna acquisizione.
- Dall'acquisizione con l'ultimo Timestamp ottenere un filtro da esso modificare il filtro Timestamp da == a >= (il primo pacchetto) e <= (l'ultimo pacchetto), ad esempio:
(frame.time >= "16 ott 2019 16:13:43.244692000") &&(frame.time <= "16 ott 2019 16:20:21.785130000")
3. Esportare i pacchetti specificati in una nuova acquisizione, selezionare File > Esporta pacchetti specificati, quindi salvare i pacchetti visualizzati. A questo punto, entrambe le clip devono contenere pacchetti che coprono la stessa finestra temporale. A questo punto è possibile iniziare il confronto delle due clip.
Passaggio 2. Specificare il campo del pacchetto da utilizzare per il confronto tra le due acquisizioni. Esempio di campi utilizzabili:
- Identificazione IP
- Numero di sequenza RTP
- Numero di sequenza ICMP
Creare una versione di testo di ciascuna acquisizione contenente il campo per ciascun pacchetto specificato nel passaggio 1. A tale scopo, lasciare solo la colonna di interesse; ad esempio, se si desidera confrontare i pacchetti basati sull'identificazione IP, modificare l'acquisizione come mostrato nell'immagine.
Il risultato:
Passaggio 3. Create una versione di testo dell'acquisizione (File > Esporta dismissioni pacchetti > Come testo normale...), come mostrato nell'immagine:
Deselezionare le opzioni Includi intestazioni di colonna e Dettagli pacchetto per esportare solo i valori del campo visualizzato, come mostrato nell'immagine:
Passaggio 4. Ordinare i pacchetti nei file. A tale scopo, è possibile utilizzare il comando Linux sort:
# sort CAPI_IDs > file1.sorted # sort CAPO_IDs > file2.sorted
Passaggio 5. Usare uno strumento di confronto del testo (ad esempio, WinMerge) o il comando Linux diff per trovare le differenze tra le due clip.
In questo caso, l'acquisizione CAPI e CAPO per il traffico di dati FTP è identica. Ciò dimostra che la perdita del pacchetto non è stata causata dal firewall.
Identificare la perdita di pacchetti a monte e a valle.
Considerazioni principali:
1. Questo pacchetto è una ritrasmissione TCP. In particolare, si tratta di un pacchetto TCP SYN inviato dal client al server per i dati FTP in modalità passiva. Poiché il client invia nuovamente il pacchetto e si può vedere il SYN iniziale (pacchetto 1), il pacchetto è stato perso a monte del firewall.
In questo caso, è possibile che il pacchetto SYN sia arrivato al server, ma che il pacchetto SYN/ACK sia stato perso durante il ritorno:
2. Il server invia un pacchetto e Wireshark identifica che il segmento precedente non è stato rilevato/acquisito. Poiché il pacchetto non acquisito è stato inviato dal server al client e non è stato rilevato nell'acquisizione del firewall, il pacchetto è stato perso tra il server e il firewall.
Ciò indica che esiste una perdita di pacchetti tra il server FTP e il firewall.
Azione 2. Acquisisci Altre Clip.
Acquisire altre clip insieme a quelle sugli endpoint. Provare ad applicare il metodo divide and conquister per isolare ulteriormente il segmento problematico che causa la perdita del pacchetto.
Considerazioni principali:
- Il ricevitore (in questo caso il client FTP) tiene traccia dei numeri di sequenza TCP in arrivo. Se rileva che un pacchetto è stato perso (un numero di sequenza previsto è stato ignorato), genera un pacchetto ACK con il numero di sequenza previsto ACK='ignorato'. In questo esempio, Ack=2224386800.
- Il Dup ACK attiva una ritrasmissione rapida TCP (ritrasmissione entro 20 msec dopo la ricezione di un Duplicate ACK).
Cosa significano gli ACK duplicati?
- Alcuni ACK duplicati, ma nessuna ritrasmissione effettiva, indicano che è più probabile che vi siano pacchetti non in ordine.
- La presenza di ACK duplicati, seguiti da ritrasmissioni effettive, indica che si è verificata una perdita di pacchetti.
Azione 3. Calcolare il tempo di elaborazione del firewall per i pacchetti di transito.
Applicare la stessa acquisizione su 2 interfacce diverse:
firepower# capture CAPI buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 firepower# capture CAPI interface OUTSIDE
Esportazione dell'acquisizione controllo della differenza di tempo tra i pacchetti in entrata e in uscita
Caso 7. Problema di connettività TCP (pacchetti danneggiati)
Descrizione del problema:
Il client wireless (192.168.21.193) tenta di connettersi a un server di destinazione (192.168.14.250 - HTTP) e vi sono due scenari diversi:
- Quando il client si connette al punto di accesso (punto di accesso) 'A', la connessione HTTP non funziona.
- Quando il client si connette al punto di accesso 'B', la connessione HTTP funziona.
Nell'immagine è illustrata la topologia:
Flusso interessato:
Src IP: 192.168.21.193
Dst IP: 192.168.14.250
Protocollo: TCP 80
Analisi acquisizione
Abilita acquisizioni sul motore LINA FTD:
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
Clip - Scenario funzionale:
Di base, è sempre molto utile disporre di acquisizioni da uno scenario riconosciuto valido.
Nell'immagine viene mostrata l'acquisizione effettuata sull'interfaccia NGFW INSIDE
L'immagine mostra l'acquisizione effettuata sull'interfaccia NGFW OUTSIDE.
Considerazioni principali:
- Le due clip sono quasi identiche (si consideri la randomizzazione ISN).
- Non ci sono indicazioni di una perdita di pacchetti.
- Nessun pacchetto non in ordine
- Sono disponibili 3 richieste HTTP GET. Al primo viene assegnato un 404 "Non trovato", al secondo un "OK" di 200 e al terzo un messaggio di reindirizzamento "Non modificato" di 304.
Acquisizioni - Scenario noto con errori:
Il contenuto CAPI (Ingress Capture).
Considerazioni principali:
- Handshake TCP a 3 vie.
- Ci sono ritrasmissioni TCP e indicazioni di una perdita di pacchetto.
- Un pacchetto (TCP ACK) viene identificato da Wireshark come non valido.
L'immagine mostra il contenuto della cattura in uscita (CAPO).
Considerazioni principali:
Le due clip sono quasi identiche (si consideri la randomizzazione ISN):
- Handshake TCP a 3 vie.
- Ci sono ritrasmissioni TCP e indicazioni di una perdita di pacchetto.
- Un pacchetto (TCP ACK) viene identificato da Wireshark come non valido.
Controllare il pacchetto in formato non valido:
Considerazioni principali:
- Il pacchetto viene identificato come non valido da Wireshark.
- Ha una lunghezza di 2 byte.
- Il payload TCP è di 2 byte.
- Il carico utile è di 4 zeri in più (00 00).
Azioni consigliate
Le azioni elencate in questa sezione hanno lo scopo di limitare ulteriormente il problema.
Azione 1. Acquisisci altre clip. Includere le acquisizioni negli endpoint e, se possibile, provare ad applicare il metodo divide and conquista per isolare l'origine del danneggiamento del pacchetto, ad esempio:
In questo caso, i 2 byte aggiuntivi sono stati aggiunti dal driver dell'interfaccia 'A' dello switch e la soluzione è stata quella di sostituire lo switch che causa il danneggiamento.
Caso 8. Problema di connettività UDP (pacchetti mancanti)
Descrizione del problema: i messaggi Syslog (UDP 514) non vengono visualizzati sul server Syslog di destinazione.
Nell'immagine è illustrata la topologia:
Flusso interessato:
Src IP: 192.168.1.81
Dst IP: 10.10.1.73
Protocollo: UDP 514
Analisi acquisizione
Abilita acquisizioni sul motore LINA FTD:
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
Le clip FTD non mostrano pacchetti:
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
Azioni consigliate
Le azioni elencate in questa sezione hanno lo scopo di limitare ulteriormente il problema.
Azione 1. Controllare la tabella di connessione FTD.
Per verificare una connessione specifica, è possibile utilizzare la sintassi seguente:
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
Considerazioni principali:
- Le interfacce in entrata e in uscita sono le stesse (inversione a U).
- Il numero di byte ha un valore molto grande (~5 GByte).
- Il flag "o" indica l'offload del flusso (flusso accelerato HW). Questo è il motivo per cui le clip FTD non mostrano alcun pacchetto. Flow offload è supportato solo sulle piattaforme 41xx e 93xx. In questo caso, il dispositivo è un 41xx.
Azione 2. Acquisizione a livello di chassis.
Collegarsi al gestore dello chassis Firepower e abilitare l'acquisizione sull'interfaccia in entrata (in questo caso E1/2) e sulle interfacce del backplane (E1/9 e E1/10), come mostrato nell'immagine:
Dopo alcuni secondi:
Prima:
Dopo:
Considerazioni principali:
- Viene applicato un filtro di visualizzazione per rimuovere i duplicati dei pacchetti e visualizzare solo i syslog.
- La differenza tra i pacchetti è al livello del microsecondo. Ciò indica una velocità di trasmissione dei pacchetti molto elevata.
- Il valore TTL (Time to Live) diminuisce continuamente. Ciò indica un loop di pacchetto.
Azione 3. Usare packet-tracer.
Poiché i pacchetti non attraversano il motore LINA del firewall, non è possibile eseguire una traccia in tempo reale (acquisizione con traccia), ma è possibile tracciare un pacchetto emulato con 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
Azione 4. Confermare il ciclo FTD.
Controllare la tabella di routing del firewall per verificare se sono presenti problemi di routing:
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
Considerazioni principali:
- Il percorso punta verso l'interfaccia di uscita corretta.
- Il percorso è stato appreso qualche minuto fa (0:02:37).
Azione 5. Confermare il tempo di attività della connessione.
Controllare il tempo di attività della connessione per verificare quando è stata stabilita la connessione:
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
Punto chiave:
- La connessione è stata stabilita circa 4 minuti fa (prima dell'installazione del percorso EIGRP nella tabella di routing)
Azione 6. Cancellare la connessione stabilita.
In questo caso, i pacchetti corrispondono a una connessione stabilita e vengono instradati a un'interfaccia di uscita errata; ciò provoca un loop. Ciò è dovuto all'ordine delle operazioni del firewall:
- Ricerca di connessioni stabilita (ha priorità rispetto alla ricerca nella tabella di routing globale).
- Ricerca NAT (Network Address Translation) - La fase UN-NAT (NAT di destinazione) ha la precedenza sulla ricerca PBR e route.
- Policy-Based Routing (PBR)
- Ricerca nella tabella di routing globale
Poiché la connessione non scade mai (il client Syslog invia continuamente i pacchetti mentre il timeout di inattività della connessione UDP è di 2 minuti), è necessario cancellare manualmente la connessione:
firepower# clear conn address 10.10.1.73 address 192.168.1.81 protocol udp port 514 1 connection(s) deleted.
Verificare che sia stata stabilita una nuova connessione:
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
Azione 7. Configurare il timeout della connessione mobile.
Questa è la soluzione ideale per risolvere il problema ed evitare un routing non ottimale, soprattutto per i flussi UDP. Passare a Dispositivi > Impostazioni piattaforma > Timeout e impostare il valore:
Per ulteriori informazioni sul timeout della conn mobile, vedere la Guida di riferimento per i comandi:
Caso 9. Problema di connettività HTTPS (scenario 1)
Descrizione del problema: impossibile stabilire la comunicazione HTTPS tra il client 192.168.201.105 e il server 192.168.202.101
Nell'immagine è illustrata la topologia:
Flusso interessato:
Src IP: 192.168.201.111
Indirizzo IP: 192.168.202.111
Protocollo: TCP 443 (HTTPS)
Analisi acquisizione
Abilita acquisizioni sul motore LINA FTD:
L'indirizzo IP utilizzato nell'acquisizione OUTSIDE è diverso a causa della configurazione Port-Address Translation.
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
Nell'immagine viene mostrata l'acquisizione effettuata sull'interfaccia NGFW INSIDE:
Considerazioni principali:
- Handshake TCP a 3 vie.
- Avvio della negoziazione SSL. Il client invia un messaggio Hello al client.
- Al client è stato inviato un ACK TCP.
- RST TCP inviato al client.
L'immagine mostra l'acquisizione effettuata sull'interfaccia NGFW OUTSIDE.
Considerazioni principali:
- Handshake TCP a 3 vie.
- Avvio della negoziazione SSL. Il client invia un messaggio Hello al client.
- Sono presenti ritrasmissioni TCP inviate dal firewall al server.
- RST TCP inviato al server.
Azioni consigliate
Le azioni elencate in questa sezione hanno lo scopo di limitare ulteriormente il problema.
Azione 1. Acquisisci altre clip.
Un'acquisizione effettuata sul server rivela che il server ha ricevuto gli Helper del client TLS con checksum TCP corrotti e li scarta in modo invisibile all'utente (non esiste TCP RST o alcun altro pacchetto di risposta verso il client):
Quando si mette tutto insieme:
In questo caso, per comprenderlo, è necessario abilitare su Wireshark l'opzione Validate the TCP checksum (Convalida checksum TCP se possibile). Passare a Modifica > Preferenze > Protocolli > TCP, come mostrato nell'immagine.
In questo caso, è utile mettere le clip una accanto all'altra per avere una visione completa:
Considerazioni principali:
- Handshake TCP a 3 vie. Gli ID IP sono gli stessi. Ciò significa che il flusso non è stato inviato tramite proxy dal firewall.
- Il client TLS Hello viene dal client con ID IP 12083. Il pacchetto viene inoltrato dal firewall (in questo caso, il firewall è stato configurato con i criteri di decrittografia TLS) e l'ID IP viene modificato in 52534. Inoltre, il checksum TCP del pacchetto viene danneggiato (a causa di un difetto del software che in seguito è stato risolto).
- Il firewall è in modalità Proxy TCP e invia un ACK al client (che falsifica il server).
- Il firewall non riceve alcun pacchetto TCP ACK dal server e trasmette nuovamente il messaggio Hello del client TLS. Anche in questo caso, la causa è la modalità TCP Proxy attivata dal firewall.
- Dopo circa 30 secondi, il firewall si disattiva e invia un RST TCP al client.
- Il firewall invia una richiesta RST TCP verso il server.
Per riferimento:
Elaborazione handshake Firepower TLS/SSL
Caso 10. Problema di connettività HTTPS (scenario 2)
Descrizione del problema: la registrazione della licenza Smart License di FMC non è riuscita.
Nell'immagine è illustrata la topologia:
Flusso interessato:
Src IP: 192.168.0.100
Dst: tools.cisco.com
Protocollo: TCP 443 (HTTPS)
Analisi acquisizione
Abilitare l'acquisizione sull'interfaccia di gestione FMC:
Riprovare a eseguire la registrazione. Quando viene visualizzato il messaggio Error (Errore), premere CTRL-C per interrompere l'acquisizione:
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#
Raccogliere l'acquisizione dal FMC (Sistema > Integrità > Monitor, selezionare il dispositivo e selezionare Advanced Troubleshooting), come mostrato nell'immagine:
L'immagine mostra l'acquisizione della FMC su Wireshark:
Seguire uno dei flussi TCP (Segui > Flusso TCP), come mostrato nell'immagine.
Considerazioni principali:
- Handshake TCP a 3 vie.
- Il client (FMC) invia un messaggio Hello per il client SSL al portale di Smart Licensing.
- L'ID sessione SSL è 0. Ciò significa che non si tratta di una sessione ripresa.
- Il server di destinazione risponde con il messaggio Server Hello, Certificate e Server Hello Done.
- Il client invia un avviso SSL irreversibile relativo a un'autorità di certificazione sconosciuta.
- Il client invia una richiesta RST TCP per chiudere la sessione.
- L'intera durata della sessione TCP (dalla definizione alla chiusura) è stata di circa 0,5 sec.
Selezionare il Certificato server ed espandere il campo autorità emittente per visualizzare il nome comune. In questo caso, il nome comune indica un dispositivo che esegue il comando Man-in-the-middle (MITM).
Questa è la figura:
Azioni consigliate
Le azioni elencate in questa sezione hanno lo scopo di limitare ulteriormente il problema.
Azione 1. Acquisisci altre clip.
Acquisire immagini sul dispositivo firewall di transito:
CAPI mostra:
CAPO mostra:
Queste acquisizioni dimostrano che il firewall di transito modifica il certificato server (MITM)
Azione 2. Controllare i registri del dispositivo.
È possibile raccogliere il bundle FMC TS come descritto nel presente documento:
In questo caso, il file /dir-archives/var-log/process_stdout.log visualizza messaggi come questo:
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/
Soluzione consigliata
Disabilitare il servizio MITM per il flusso specifico in modo che FMC possa eseguire correttamente la registrazione nel cloud di Smart Licensing.
Caso 11. Problema di connettività IPv6
Descrizione del problema: gli host interni (dietro l'interfaccia INSIDE del firewall) non sono in grado di comunicare con gli host esterni (dietro l'interfaccia OUTSIDE del firewall).
Nell'immagine è illustrata la topologia:
Flusso interessato:
Src IP: fc00:1:1:1::100
Dst IP: fc00:1:1:2::2
Protocollo: qualsiasi
Analisi acquisizione
Abilita le acquisizioni sul motore LINA FTD.
firepower# capture CAPI int INSIDE match ip any6 any6 firepower# capture CAPO int OUTSIDE match ip any6 any6
Acquisizioni - Scenario non funzionale
Le clip sono state acquisite in parallelo con un test di connettività ICMP da IP fc00:1:1:1:10 (router interno) a IP fc00:1:1:2:2 (router upstream).
L'interfaccia INSIDE di acquisizione su firewall contiene:
Considerazioni principali:
- Il router invia un messaggio di richiesta router adiacente IPv6 e richiede l'indirizzo MAC del dispositivo upstream (IP fc00:1:1:1:1).
- Il firewall risponde con un annuncio router adiacente IPv6.
- Il router invia una richiesta Echo ICMP.
- Il firewall invia un messaggio di richiesta router adiacente IPv6 e richiede l'indirizzo MAC del dispositivo downstream (fc00:1:1:1:100).
- Il router risponde con un annuncio router adiacente IPv6.
- Il router invia ulteriori richieste echo ICMP IPv6.
L'acquisizione sull'interfaccia ESTERNA del firewall contiene:
Considerazioni principali:
- Il firewall invia un messaggio di richiesta router adiacente IPv6 che richiede l'indirizzo MAC del dispositivo upstream (IP fc00:1:1:2:2).
- Il router risponde con un annuncio router adiacente IPv6.
- Il firewall invia una richiesta echo ICMP IPv6.
- Il dispositivo upstream (router fc00:1:1:2:2) invia un messaggio di richiesta router adiacente IPv6 che richiede l'indirizzo MAC dell'indirizzo IPv6 fc00:1:1:1:100.
- Il firewall invia una richiesta echo ICMP IPv6 aggiuntiva.
- Il router upstream invia un messaggio aggiuntivo di richiesta router adiacente IPv6 che richiede l'indirizzo MAC dell'indirizzo IPv6 fc00:1:1:1:100.
Il punto 4 è molto interessante. Normalmente il router a monte chiede l'indirizzo MAC dell'interfaccia OUTSIDE del firewall (fc00:1:1:2:2), ma invece chiede l'indirizzo fc00:1:1:1:100. Ciò indica una configurazione errata.
Azioni consigliate
Le azioni elencate in questa sezione hanno lo scopo di limitare ulteriormente il problema.
Azione 1. Controllare la tabella adiacente IPv6.
La tabella adiacente IPv6 del firewall è popolata correttamente.
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
Azione 2. Controllare la configurazione IPv6.
Questa è la configurazione del firewall.
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
La configurazione del dispositivo a monte rivela la configurazione errata:
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
Acquisizioni - Scenario funzionale
La modifica della subnet mask (da /48 a /64) ha risolto il problema. Questa è l'acquisizione CAPI nello scenario funzionale.
Punto chiave:
- Il router invia un messaggio di richiesta router adiacente IPv6 che richiede l'indirizzo MAC del dispositivo upstream (IP fc00:1:1:1:1).
- Il firewall risponde con un annuncio router adiacente IPv6.
- Il router invia richieste echo ICMP e riceve risposte echo.
Contenuto del capo:
Considerazioni principali:
- Il firewall invia un messaggio di richiesta router adiacente IPv6 che richiede l'indirizzo MAC del dispositivo upstream (IP fc00:1:1:2:2).
- Il firewall risponde con un annuncio router adiacente IPv6.
- Il firewall invia una richiesta echo ICMP.
- Il router invia un messaggio di richiesta router adiacente IPv6 che richiede l'indirizzo MAC del dispositivo downstream (IP fc00:1:1:1:1).
- Il firewall risponde con un annuncio router adiacente IPv6.
- Il firewall invia richieste echo ICMP e riceve risposte echo.
Caso 12. Problema di connettività intermittente (avvelenamento ARP)
Descrizione del problema: gli host interni (192.168.0.x/24) presentano problemi di connettività intermittenti con gli host della stessa subnet
Nell'immagine è illustrata la topologia:
Flusso interessato:
Src IP: 192.168.0.x/24
Dst IP: 192.168.0.x/24
Protocollo: qualsiasi
La cache ARP di un host interno sembra essere avvelenata:
Analisi acquisizione
Abilita un'acquisizione sul motore LINA FTD
Questa acquisizione acquisisce solo i pacchetti ARP sull'interfaccia INSIDE:
firepower# capture CAPI_ARP interface INSIDE ethernet-type arp
Acquisizioni - Scenario non funzionale:
L'acquisizione sull'interfaccia INSIDE del firewall contiene.
Considerazioni principali:
- Il firewall riceve varie richieste ARP per gli IP all'interno della rete 192.168.0.x/24
- Il firewall risponde a tutti (proxy-ARP) con il proprio indirizzo MAC
Azioni consigliate
Le azioni elencate in questa sezione hanno lo scopo di limitare ulteriormente il problema.
Azione 1. Controllare la configurazione NAT.
Per quanto riguarda la configurazione NAT, in alcuni casi la parola chiave no-proxy-arp può impedire il comportamento precedente:
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
Azione 2. Disabilitare la funzionalità proxy-arp sull'interfaccia del firewall.
Se la parola chiave "no-proxy-arp" non risolve il problema, provare a disabilitare il proxy ARP sull'interfaccia stessa. Nel caso di FTD, al momento della scrittura, è necessario utilizzare FlexConfig e distribuire il comando (specificare il nome dell'interfaccia appropriato).
sysopt noproxyarp INSIDE
Caso 13. Identificazione degli identificatori di oggetti (OID) SNMP che causano il blocco della CPU
In questo caso viene mostrato come alcuni OID SNMP per il polling della memoria sono stati identificati come la causa principale dei log della CPU (problema di prestazioni) in base all'analisi delle acquisizioni di pacchetti SNMP versione 3 (SNMPv3).
Descrizione del problema: gli overrun sulle interfacce dati aumentano continuamente. Ulteriori ricerche hanno rivelato che ci sono anche hook della CPU (causati dal processo SNMP) che sono la causa principale dei sovraccarichi dell'interfaccia.
Il passaggio successivo del processo di risoluzione dei problemi consisteva nell'identificare la causa principale dei log della CPU causati dal processo SNMP e, in particolare, restringere l'ambito del problema per identificare gli identificatori di oggetto SNMP (OID) che, se esaminati, potrebbero potenzialmente causare hog della CPU.
Al momento, il motore LINA FTD non fornisce un comando 'show' per gli OID SNMP di cui viene eseguito il polling in tempo reale.
L'elenco degli OID SNMP per il polling può essere recuperato dallo strumento di monitoraggio SNMP; tuttavia, in questo caso, erano presenti i seguenti fattori preventivi:
- L'amministratore FTD non aveva accesso allo strumento di monitoraggio SNMP
- SNMP versione 3 con autenticazione e crittografia dei dati per la privacy è stato configurato su FTD
Analisi acquisizione
Poiché l'amministratore FTD disponeva delle credenziali per l'autenticazione SNMP versione 3 e la crittografia dei dati, è stato proposto questo piano d'azione:
- Acquisizione di pacchetti SNMP
- Salvare le clip e usare le preferenze del protocollo Wireshark SNMP per specificare le credenziali SNMP versione 3 per decrittografare i pacchetti SNMP versione 3. Le clip decrittografate vengono utilizzate per l'analisi e il recupero degli OID SNMP
Configurare le acquisizioni dei pacchetti SNMP sull'interfaccia utilizzata nella configurazione dell'host 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
Considerazioni principali:
- Indirizzi/porte di origine e di destinazione SNMP.
- Impossibile decodificare la PDU del protocollo SNMP. PrivKey è sconosciuto a Wireshark.
- Il valore della primitiva encryptedPDU.
Azioni consigliate
Le azioni elencate in questa sezione hanno lo scopo di limitare ulteriormente il problema.
Azione 1. Decrittografare le clip SNMP.
Salvare le clip e modificare le preferenze del protocollo SNMP Wireshark per specificare le credenziali SNMP versione 3 per decrittografare i pacchetti.
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
Aprire il file di acquisizione su Wireshark, selezionare un pacchetto SNMP e selezionare Protocol Preferences > Users Table (Preferenze protocollo > Tabella utenti), come mostrato nell'immagine:
Nella tabella Utenti SNMP sono stati specificati il nome utente SNMP versione 3, il modello di autenticazione, la password di autenticazione, il protocollo di privacy e la password per la privacy (le credenziali effettive non sono mostrate di seguito):
Una volta applicate le impostazioni degli utenti SNMP, Wireshark ha mostrato le PDU SNMP decrittografate:
Considerazioni principali:
- Gli strumenti di monitoraggio SNMP hanno utilizzato SNMP getBulkRequest per eseguire query sull'OID 1.3.6.1.4.1.9.9.221.1 padre e sugli OID correlati e per esaminarlo.
- L'FTD ha risposto a ogni getBulkRequest con get-response contenente OID correlati a 1.3.6.1.4.1.9.9.221.1.
Azione 2. Identificare gli OID SNMP.
SNMP Object Navigator ha mostrato che OID 1.3.6.1.4.1.9.9.221.1 appartiene al MIB (Management Information Base) denominato CISCO-ENHANCED-MEMPOOL-MIB, come mostrato nell'immagine:
Per visualizzare gli OID in formato leggibile in Wireshark:
- Scaricare il MIB CISCO-ENHANCED-MEMPOOL-MIB e le relative dipendenze, come mostrato nell'immagine:
2. In Wireshark in Modifica > Preferenze > finestra Risoluzione nome, è selezionata l'opzione Abilita risoluzione OID. Nella finestra SMI (percorsi MIB e PIB) specificare la cartella con i MIB scaricati e nei moduli SMI (MIB e PIB). Il CISCO-ENHANCED-MEMPOOL-MIB viene aggiunto automaticamente all'elenco dei moduli:
3. Dopo il riavvio di Wireshark, viene attivata la risoluzione OID:
In base all'output decrittografato del file di acquisizione, lo strumento di monitoraggio SNMP ha eseguito periodicamente (a intervalli di 10 secondi) il polling dei dati sull'utilizzo dei pool di memoria sull'FTD. Come spiegato nell'articolo di TechNote ASA SNMP Polling for Memory-Related Statistics , il polling dell'utilizzo del Global Shared Pool (GSP) con il protocollo SNMP determina un elevato utilizzo della CPU. In questo caso dalle acquisizioni, è chiaro che l'utilizzo del pool condiviso globale è stato periodicamente sottoposto a polling come parte della primitiva getBulkRequest di SNMP.
Per ridurre al minimo i blocchi della CPU causati dal processo SNMP, è stato consigliato di seguire i passaggi di mitigazione per i blocchi della CPU per il protocollo SNMP indicati nell'articolo e di evitare il polling degli OID relativi all'SPG. Senza il sondaggio SNMP per gli OID relativi all'SPG, non sono stati osservati hog della CPU causati dal processo SNMP e la velocità di sovraccarico è diminuita in modo significativo.
Informazioni correlate
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
2.0 |
02-Jun-2023 |
Certificazione |
1.0 |
21-Nov-2019 |
Versione iniziale |
Feedback