Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Premesse

Come raccogliere ed esportare le clip sulla famiglia di prodotti NGFW?

Raccogli acquisizioni FXOS

Abilita e raccogli acquisizioni di linea FTD

Abilita e raccogli acquisizioni di snort FTD

Risoluzione dei problemi

Caso 1. Nessun TCP SYN su interfaccia in uscita

Analisi acquisizione

Azioni consigliate

Sintetico delle possibili cause e delle azioni consigliate

Caso 2. TCP SYN da client, TCP RST da server

Analisi acquisizione

Azioni consigliate

Caso 3. Handshake TCP a 3 vie + RST da un endpoint

Analisi acquisizione

3.1 - Handshake TCP a 3 vie + RST ritardato dal client

Azioni consigliate

3.2 - Handshake TCP a 3 vie + FIN/ACK ritardato dal client + RST ritardato dal server

Azioni consigliate

3.3 - Handshake TCP a 3 vie + RST ritardato dal client

Azioni consigliate

3.4 - Handshake TCP a 3 vie + RST immediato dal server

Azioni consigliate

Caso 4. TCP RST dal client

Analisi acquisizione

Azioni consigliate

Caso 5. Trasferimento TCP lento (scenario 1)

Scenario 1. Trasferimento lento

Analisi acquisizione

Azioni consigliate

Scenario 2. Trasferimento rapido

Caso 6. Trasferimento TCP lento (scenario 2)

Analisi acquisizione

Azioni consigliate

Esportare la cattura controllare la differenza di tempo tra i pacchetti in entrata e in uscitaCaso 7. Problema di connettività TCP (pacchetti danneggiati)

Analisi acquisizione

Azioni consigliate

Caso 8. Problema di connettività UDP (pacchetti mancanti)

Analisi acquisizione

Azioni consigliate

Analisi acquisizione

Azioni consigliate

Caso 10. Problema di connettività HTTPS (scenario 2)

Analisi acquisizione

Azioni consigliate

Analisi acquisizione

Azioni consigliate

Caso 12. Problema di connettività intermittente (avvelenamento ARP)

Analisi acquisizione

Azioni consigliate

Caso 13. Identificazione degli identificatori di oggetti (OID) SNMP che causano il blocco della CPU

Analisi acquisizione

Azioni consigliate

Informazioni correlate

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.

1. Un pacchetto entra nell'interfaccia in entrata e viene gestito dallo switch interno dello chassis.

2. Il pacchetto entra nel motore FTD Lina che esegue principalmente controlli L3/L4.

3. Se la politica richiede che il pacchetto sia ispezionato dal motore Snort (principalmente l'ispezione L7).

4. Il motore Snort restituisce un verdetto per il pacchetto.

5. In base a questo verdetto, il motore LINA elimina il pacchetto o lo inoltra.

6. 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:

https://www.cisco.com/c/en/us/td/docs/security/firepower/fxos/fxos271/web-guide/b_GUI_FXOS_ConfigGuide_271/troubleshooting.html#concept_E8823CC63C934A909BBC0DF12F301DED

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).

Nota: le acquisizioni a livello di chassis FXOS sono disponibili solo sulle piattaforme FP41xx e FP93xx. FP1xxx e FP21xx non offrono questa funzionalità.

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 Download:

Per ulteriori esempi su come abilitare/raccogliere le acquisizioni dall'interfaccia utente di FMC, vedere questo documento:

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html

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:

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html

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:

1. Handshake TCP a 3 vie.

2. Scambio bidirezionale di dati.

3. Nessun ritardo tra i pacchetti (in base alla differenza di tempo tra i pacchetti).

4. L'indirizzo MAC di origine è il dispositivo downstream corretto.

Le immagini acquisite tramite l'interfaccia NGFW OUTSIDE sono mostrate nell'immagine seguente:

Considerazioni principali:

1. Stessi dati dell'acquisizione CAPI.

2. 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:

1. Vengono visualizzati solo i pacchetti TCP SYN (nessun handshake a 3 vie TCP).

2. 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.

3. Le ritrasmissioni TCP avvengono ogni ~3, 6, ecc.

4. 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:

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/200479-Configure-Logging-on-FTD-via-FMC.html

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

Suggerimento: se non si è interessati al contenuto del pacchetto, è possibile acquisire solo le intestazioni del pacchetto (opzione solo intestazioni). In questo modo è possibile acquisire un numero molto maggiore di pacchetti nel buffer di acquisizione. Inoltre, è possibile aumentare la dimensione del buffer di acquisizione (per impostazione predefinita è di 500 Kbyte) fino a un valore di 32 Mbyte (opzione del buffer). Infine, a partire dalla versione 6.3 di FTD, l'opzione relativa alle dimensioni dei file consente di configurare un file di acquisizione fino a 10 GB. In tal caso, è possibile visualizzare solo il contenuto acquisito in formato pcap.

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:

1. Ricerca connessione stabilita

2. Ricerca NAT (Network Address Translation) - La fase UN-NAT (NAT di destinazione) ha la precedenza sulla ricerca PBR e route.

3. Policy-Based Routing (PBR)

4. 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:

Nota: poiché tutte le interfacce FTD hanno un livello di sicurezza 0, l'ordine delle interfacce nell'output show conn si basa sul numero di interfaccia. In particolare, l'interfaccia con il numero vpif-num più alto (numero di interfaccia della piattaforma virtuale) viene selezionata come interna, mentre l'interfaccia con il numero vpif-num più basso viene selezionata come esterna. Per visualizzare il valore interface vpif, usare il comando show interface detail. Miglioramenti correlati, Cisco bug ID CSCvi15290 ENH: FTD mostra la direzionalità della connessione nell'output 'show conn' FTD

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

Nota: a partire dal software Firepower versione 6.5, ASA versione 9.13.x, gli output del comando show conn long e show conn detail forniscono informazioni sull'iniziatore e sul risponditore della connessione

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.

- Utilizzare packet-tracer o capture w/trace per verificare come il firewall gestisce il pacchetto.

- Controllare i registri del firewall.

- Controllare le gocce ASP del firewall (show asp drop o tipo di acquisizione asp-drop).

- Controllare gli eventi di connessione FMC. In questo caso si presuppone che la registrazione della regola sia abilitata.

Il filtro di acquisizione è errato.

- Usare packet-tracer o capture w/trace per verificare se esiste una traduzione NAT che modifica l'IP di origine o di destinazione. In tal caso, regolare il filtro di acquisizione.

- l'output del comando show conn long visualizza gli IP NAT.

Il pacchetto viene inviato a un'interfaccia di uscita diversa.

- Usare packet-tracer o capture w/trace per verificare in che modo il firewall gestisce il pacchetto. Tenere presente l'ordine delle operazioni che riguardano la determinazione dell'interfaccia in uscita, la connessione corrente, UN-NAT, PBR e la ricerca nella tabella di routing.

- Controllare i registri del firewall.

- Controllare la tabella delle connessioni del firewall (show conn).

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.

- Utilizzare packet-tracer o capture w/trace per verificare come il firewall gestisce il pacchetto.

- Controllare le cadute ASP del firewall (show asp drop) per il motivo della caduta senza route.

Nessuna voce ARP sull'interfaccia in uscita.

- Controllare la cache ARP del firewall (show arp).

- Utilizzare packet-tracer per verificare la presenza di un'adiacenza valida.

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:

L'aspetto delle clip dalla CLI del dispositivo è il seguente:

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:

1. L'origine invia un pacchetto TCP SYN.

2. Viene inviato TCP RST verso l'origine.

3. L'origine trasmette nuovamente i pacchetti TCP SYN.

4. 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:

1. L'origine invia un pacchetto TCP SYN.

2. Sull'interfaccia ESTERNA arriva un TCP RST.

3. L'origine trasmette nuovamente i pacchetti TCP SYN.

4. 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:

1. 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.

2. La lunghezza dei pacchetti varia soprattutto se il firewall aggiunge/rimuove un'intestazione dot1Q.

3. Gli indirizzi MAC sono diversi.

4. L'intestazione dot1Q può essere inserita se l'acquisizione è stata effettuata su una sottointerfaccia.

5. Gli indirizzi IP sono diversi se al pacchetto viene applicato NAT o Port Address Translation (PAT).

6. Le porte di origine o di destinazione sono diverse se al pacchetto viene applicato NAT o PAT.

7. 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.

8. 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:

1. L'handshake a 3 vie TCP attraversa il firewall.

2. Il server ritrasmette il SYN/ACK.

3. Il client ritrasmette l'ACK.

4. 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:

1. L'handshake a 3 vie TCP attraversa il firewall.

2. Dopo circa 5 sec il client invia un messaggio FIN/ACK.

3. 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:

1. L'handshake a 3 vie TCP attraversa il firewall.

2. 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:

1. L'handshake a 3 vie TCP attraversa il firewall.

2. 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:

1. Il client invia un pacchetto TCP SYN.

2. Il client invia un pacchetto TCP RST.

3. Il valore del numero di sequenza del pacchetto TCP SYN è uguale a 4098574664.

Lo stesso flusso nell'acquisizione CAPO contiene:

Considerazioni principali:

1. Il client invia un pacchetto TCP SYN. Il firewall rende casuale l'ISDN.

2. 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:

1. Il client invia un pacchetto TCP SYN. Il numero di sequenza è 4098574664 ed è lo stesso di quello visualizzato sull'interfaccia CAPI (Firewall INSIDE Interface)

2. È presente un TCP SYN/ACK con numero ACK 1386249853 (previsto a causa della randomizzazione ISDN). Il pacchetto non è stato rilevato nelle acquisizioni del firewall

3. 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

Avviso: le acquisizioni LINA sulle acquisizioni FP1xxx e FP21xx influiscono sulla velocità di trasferimento del traffico che attraversa l'FTD. Non abilitare le acquisizioni LINA sulle piattaforme FP1xxx e FP21xxx quando si risolvono problemi di prestazioni (trasferimento lento tramite FTD). Usare invece SPAN o un dispositivo HW Tap in aggiunta alle acquisizioni sugli host di origine e di destinazione. Il problema è documentato nell'ID bug Cisco CSCvo30697.

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:

1. Sono presenti pacchetti TCP non in ordine (OO).

2. Ritrasmissione TCP.

3. C'è un'indicazione di una perdita di pacchetto (pacchetti scartati).

Suggerimento: salvare le clip mentre si passa a File > Esporta pacchetti specificati. Quindi salva solo l'intervallo di pacchetti visualizzati

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:

1. La perdita di pacchetti è causata dal firewall stesso.

2. La perdita di pacchetti è causata a valle del dispositivo firewall (direzione da server a client).

3. 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:

1. Confrontare gli indicatori orari del primo pacchetto di ciascuna acquisizione.

2. 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:

1. 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.

2. 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:

1. Le due clip sono quasi identiche (si consideri la randomizzazione ISN).

2. Non ci sono indicazioni di una perdita di pacchetti.

3. Nessun pacchetto non in ordine

4. 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:

1. Handshake TCP a 3 vie.

2. Ci sono ritrasmissioni TCP e indicazioni di una perdita di pacchetto.

3. 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):

1. Handshake TCP a 3 vie.

2. Ci sono ritrasmissioni TCP e indicazioni di una perdita di pacchetto.

3. Un pacchetto (TCP ACK) viene identificato da Wireshark come non valido.

Controllare il pacchetto in formato non valido:

Considerazioni principali:

1. Il pacchetto viene identificato come non valido da Wireshark.

2. Ha una lunghezza di 2 byte.

3. Il payload TCP è di 2 byte.

4. 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:

1. Le interfacce in entrata e in uscita sono le stesse (inversione a U).

2. Il numero di byte ha un valore molto grande (~5 GByte).

3. 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:

Suggerimento: in Wireshark escludere i pacchetti con tag VN per eliminare la duplicazione dei pacchetti a livello di interfaccia fisica

Prima:

Dopo:

Considerazioni principali:

1. Viene applicato un filtro di visualizzazione per rimuovere i duplicati dei pacchetti e visualizzare solo i syslog.

2. La differenza tra i pacchetti è al livello del microsecondo. Ciò indica una velocità di trasmissione dei pacchetti molto elevata.

3. 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:

1. Il percorso punta verso l'interfaccia di uscita corretta.

2. 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:

1. 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:

1. Ricerca di connessioni stabilita (ha priorità rispetto alla ricerca nella tabella di routing globale).

2. Ricerca NAT (Network Address Translation) - La fase UN-NAT (NAT di destinazione) ha la precedenza sulla ricerca PBR e route.

3. Policy-Based Routing (PBR)

4. 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:

https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/T-Z/asa-command-ref-T-Z.html#pgfId-1649892

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:

1. Handshake TCP a 3 vie.

2. Avvio della negoziazione SSL. Il client invia un messaggio Hello al client.

3. Al client è stato inviato un ACK TCP.

4. RST TCP inviato al client.

L'immagine mostra l'acquisizione effettuata sull'interfaccia NGFW OUTSIDE.

Considerazioni principali:

1. Handshake TCP a 3 vie.

2. Avvio della negoziazione SSL. Il client invia un messaggio Hello al client.

3. Sono presenti ritrasmissioni TCP inviate dal firewall al server.

4. 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:

1. Handshake TCP a 3 vie. Gli ID IP sono gli stessi. Ciò significa che il flusso non è stato inviato tramite proxy dal firewall.

2. 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).

3. Il firewall è in modalità Proxy TCP e invia un ACK al client (che falsifica il server).

4. 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.

5. Dopo circa 30 secondi, il firewall si disattiva e invia un RST TCP al client.

6. 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:

Suggerimento: per controllare tutte le nuove sessioni TCP acquisite, utilizzare il filtro di visualizzazione tcp.flags==0x2 su Wireshark. In questo modo vengono filtrati tutti i pacchetti TCP SYN acquisiti.

Suggerimento: applicare come colonna il campo Nome server dal client SSL Hello.

Suggerimento: applicare questo filtro di visualizzazione per visualizzare solo i messaggi del client Hello ssl.handshake.type == 1

Nota: al momento della stesura di questo documento, il portale delle licenze intelligenti (tools.cisco.com) utilizza gli indirizzi IP seguenti: 72.163.4.38, 173.37.145.8

Seguire uno dei flussi TCP (Segui > Flusso TCP), come mostrato nell'immagine.

Considerazioni principali:

1. Handshake TCP a 3 vie.

2. Il client (FMC) invia un messaggio Hello per il client SSL al portale di Smart Licensing.

3. L'ID sessione SSL è 0. Ciò significa che non si tratta di una sessione ripresa.

4. Il server di destinazione risponde con il messaggio Server Hello, Certificate e Server Hello Done.

5. Il client invia un avviso SSL irreversibile relativo a un'autorità di certificazione sconosciuta.

6. Il client invia una richiesta RST TCP per chiudere la sessione.

7. 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:

https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html

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:

1. Il router invia un messaggio di richiesta router adiacente IPv6 e richiede l'indirizzo MAC del dispositivo upstream (IP fc00:1:1:1:1).

2. Il firewall risponde con un annuncio router adiacente IPv6.

3. Il router invia una richiesta Echo ICMP.

4. Il firewall invia un messaggio di richiesta router adiacente IPv6 e richiede l'indirizzo MAC del dispositivo downstream (fc00:1:1:1:100).

5. Il router risponde con un annuncio router adiacente IPv6.

6. Il router invia ulteriori richieste echo ICMP IPv6.

L'acquisizione sull'interfaccia ESTERNA del firewall contiene:

Considerazioni principali:

1. Il firewall invia un messaggio di richiesta router adiacente IPv6 che richiede l'indirizzo MAC del dispositivo upstream (IP fc00:1:1:2:2).

2. Il router risponde con un annuncio router adiacente IPv6.

3. Il firewall invia una richiesta echo ICMP IPv6.

4. 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.

5. Il firewall invia una richiesta echo ICMP IPv6 aggiuntiva.

6. 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:

1. Il router invia un messaggio di richiesta router adiacente IPv6 che richiede l'indirizzo MAC del dispositivo upstream (IP fc00:1:1:1:1).

2. Il firewall risponde con un annuncio router adiacente IPv6.

3. Il router invia richieste echo ICMP e riceve risposte echo.

Contenuto del capo:

Considerazioni principali:

1. Il firewall invia un messaggio di richiesta router adiacente IPv6 che richiede l'indirizzo MAC del dispositivo upstream (IP fc00:1:1:2:2).

2. Il firewall risponde con un annuncio router adiacente IPv6.

3. Il firewall invia una richiesta echo ICMP.

4. Il router invia un messaggio di richiesta router adiacente IPv6 che richiede l'indirizzo MAC del dispositivo downstream (IP fc00:1:1:1:1).

5. Il firewall risponde con un annuncio router adiacente IPv6.

6. 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:

1. Il firewall riceve varie richieste ARP per gli IP all'interno della rete 192.168.0.x/24

2. 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:

1. Acquisizione di pacchetti SNMP

2. 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:

1. Indirizzi/porte di origine e di destinazione SNMP.

2. Impossibile decodificare la PDU del protocollo SNMP. PrivKey è sconosciuto a Wireshark.

3. 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:

1. 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.

2. 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:

1. 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

- Guide alla configurazione di Cisco Firepower Management Center

- Informazioni sulle azioni delle regole delle policy di controllo degli accessi di Firepower Threat Defense

- Uso di acquisizioni e Packet Tracer di Firepower Threat Defense

- Informazioni su Wireshark