La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
Questo articolo fa parte di una serie di articoli che spiegano come risolvere in modo sistematico i problemi relativi al percorso dei dati nei sistemi Firepower per determinare se i componenti di Firepower possono influire sul traffico. Per informazioni sull'architettura delle piattaforme Firepower e per i collegamenti agli altri articoli sulla risoluzione dei problemi relativi ai percorsi di dati, consultare l'articolo di panoramica.
In questo articolo viene descritta la quarta fase della risoluzione dei problemi relativi al percorso dati di Firepower, ovvero Access Control Policy (ACP). Queste informazioni sono valide per tutte le piattaforme e le versioni Firepower attualmente supportate.
In generale, determinare quale regola ACP corrisponde a un flusso dovrebbe essere piuttosto semplice. È possibile esaminare gli eventi di connessione per verificare quale regola/azione viene applicata. Se l'operazione non mostra chiaramente l'operazione del provider di servizi di audioconferenza con il traffico, è possibile eseguire il debug nell'interfaccia CLI (Command Line Interface) di Firepower.
Dopo aver avuto un'idea dell'interfaccia in entrata e in uscita, il traffico dovrebbe corrispondere, così come le informazioni sul flusso, il primo passo per capire se Firepower sta bloccando il flusso è controllare gli eventi di connessione per il traffico in questione. È possibile visualizzarli in Firepower Management Center in Analisi > Connessioni > Eventi.
Nota: Prima di controllare gli eventi di connessione, verificare che la registrazione sia abilitata nelle regole del provider di servizi di audioconferenza. La registrazione è configurata nella scheda "Registrazione" all'interno di ciascuna regola dei criteri di controllo di accesso e nella scheda Security Intelligence. Verificare che le regole sospette siano configurate per l'invio dei registri al "Visualizzatore eventi". Ciò vale anche per l'azione predefinita.
Facendo clic su "Edit Search" (Modifica ricerca) e filtrato da un indirizzo IP di origine univoco (Iniziatore), è possibile visualizzare i flussi rilevati da Firepower. Nella colonna Azione viene visualizzato "Consenti" per il traffico dell'host.
Se Firepower blocca intenzionalmente il traffico, l'azione conterrà la parola "Blocca". Facendo clic su "Table View of Connection Events" vengono forniti ulteriori dati. I seguenti campi negli eventi di connessione possono essere rivisti se l'azione è "Blocca":
- Motivo
- Regola di controllo di accesso
Per risolvere rapidamente un problema che si ritiene causato dalle norme ACP, è possibile effettuare le seguenti operazioni:
Nota: Queste soluzioni rapide richiedono modifiche alle regole che potrebbero non essere possibili in tutti gli ambienti. Prima di apportare modifiche ai criteri, è consigliabile provare a utilizzare la traccia di supporto del sistema per determinare la regola che il traffico corrisponde.
È possibile eseguire ulteriori procedure di risoluzione dei problemi per le operazioni ACP tramite l'utility > system support firewall-engine-debug CLI.
Nota: Sulle piattaforme Firepower 9300 e 4100, è possibile accedere alla shell in questione tramite i seguenti comandi:
# connetti console modulo 1
Firepower-module1> connessione ftd
>
Per le istanze multiple, è possibile accedere alla CLI del dispositivo logico con i seguenti comandi.
# connect module 1 telnet
Firepower-module1> connessione ftd ftd1
Connessione alla console ftd(ftd1) del contenitore in corso... immettere "exit" per tornare alla CLI di avvio
>
L'utilità system support firewall-engine-debug ha una voce per ciascun pacchetto valutato dal provider di servizi di audioconferenza. Indica il processo di valutazione delle regole in corso e il motivo per cui una regola è associata o meno.
Nota: Nella versione 6.2 e successive, è possibile eseguire lo strumento di traccia del supporto di sistema. Vengono utilizzati gli stessi parametri ma vengono forniti ulteriori dettagli. Assicurarsi di immettere 'y' quando richiesto con "Enable firewall-engine-debug too?".
Nell'esempio seguente, la creazione di una sessione SSH viene valutata usando il supporto di sistema firewall-engine-debug.
Si tratta del punto ACP in esecuzione sul dispositivo Firepower.
L'ACP ha tre regole.
Nello scenario di risoluzione dei problemi, viene analizzata una connessione SSH da 192.168.62.3 a 10.123.175.22.
Ci si aspetta che la sessione corrisponda alla regola 3 dell'AC relativa al backup del server di trust. La domanda è: quanti pacchetti ci vogliono affinché questa sessione soddisfi questa regola? Sono necessarie tutte le informazioni nel primo pacchetto per determinare la regola AC o sono necessari più pacchetti, e in caso affermativo, quante?
Dalla CLI di Firepower, viene immesso quanto segue per visualizzare il processo di valutazione delle regole ACP.
> system support firewall-engine-debug
Please specify an IP protocol: tcp
Please specify a client IP address: 192.168.62.3
Please specify a client port:
Please specify a server IP address: 10.123.175.22
Please specify a server port: 22
Monitoring firewall engine debug messages
Suggerimento: È consigliabile compilare il maggior numero di parametri possibile quando si esegue firewall-engine-debug, in modo che solo i messaggi di debug interessanti vengano stampati sullo schermo.
Nell'output del comando debug riportato di seguito vengono visualizzati i primi quattro pacchetti della sessione in fase di valutazione.
SYN
SYN,ACK
ACK
Primo pacchetto SSH (da client a server)
Questo è un grafico che illustra ulteriormente la logica di debug.
Per questo flusso, sono necessari 4 pacchetti affinché il dispositivo soddisfi la regola.
Questa è una spiegazione dettagliata dell'output del comando debug.
In breve, la connessione impiega 4 pacchetti per corrispondere alla sessione perché deve attendere che il firewall identifichi l'applicazione poiché la regola 2 contiene un vincolo per l'applicazione.
Se la regola 2 avesse solo reti di origine e non fosse XFF, sarebbe stato necessario 1 pacchetto per corrispondere alla sessione.
È sempre consigliabile posizionare i livelli 1-4 delle regole al di sopra di tutte le altre regole nel criterio, quando possibile, poiché queste regole in genere richiedono un pacchetto per prendere una decisione. Tuttavia, è possibile notare che anche con i soli layer 1-4 delle regole, potrebbe essere necessario più di un pacchetto per soddisfare una regola AC e la ragione è l'intelligence di sicurezza URL/DNS. Se si dispone di una di queste opzioni, il firewall deve determinare l'applicazione per tutte le sessioni valutate dal criterio AC perché deve determinare se si tratta di HTTP o DNS. Quindi, deve stabilire se consentire la sessione in base alle liste nere.
Di seguito viene riportato un output troncato del comando firewall-engine-debug, i cui campi sono evidenziati in rosso. Prendere nota del comando utilizzato per ottenere il nome dell'applicazione identificata.
In alcuni scenari il traffico può essere bloccato nonostante la corrispondenza di una regola di trust nel provider di servizi di audioconferenza. Nell'esempio seguente viene valutato il traffico con gli stessi criteri di controllo di accesso e gli stessi host.
Come illustrato sopra, l'output firewall-engine-debug mostra che il traffico corrisponde a un "Trust", mentre gli eventi di connessione mostrano l'azione di blocco a causa di una regola dei criteri per le intrusioni (determinata perché la colonna Motivo mostra il blocco delle intrusioni).
Ciò può verificarsi a causa del criterio di intrusione utilizzato prima che venga determinata la regola di controllo di accesso Impostazione nella scheda Avanzate del punto ACP. Prima che il traffico possa essere considerato attendibile in base all'azione della regola, il criterio intrusione in questione identifica una corrispondenza di schema e scarta il traffico. Tuttavia, la valutazione della regola del provider di servizi di audioconferenza determina una corrispondenza della regola di trust, poiché gli indirizzi IP non corrispondono ai criteri della regola di "trust server backup".
Affinché il traffico non venga sottoposto all'ispezione della policy sulle intrusioni, la regola di trust può essere posizionata al di sopra della regola di "ispezione", che sarebbe una buona pratica in entrambi i casi. Poiché l'identificazione dell'applicazione è necessaria per una corrispondenza e una mancata corrispondenza della regola "inspect", il criterio di intrusione utilizzato prima della determinazione della regola di controllo di accesso viene utilizzato per il traffico che viene valutato dalla stessa regola. Se si inserisce la regola "trust server backup" al di sopra della regola "inspect", il traffico corrisponderà alla regola quando viene visualizzato il primo pacchetto poiché la regola è basata sull'indirizzo IP, che può essere determinato nel primo pacchetto. Non è pertanto necessario utilizzare i criteri per le intrusioni utilizzati prima della determinazione della regola di controllo di accesso.
In questo scenario gli utenti segnalano che cnn.com è bloccato. Tuttavia, non esiste una regola specifica che blocchi la CNN. Gli eventi di connessione, insieme all'output firewall-engine-debug, mostrano il motivo del blocco.
In primo luogo, accanto ai campi dell'applicazione è disponibile una casella di informazioni Eventi connessione che mostra le informazioni sull'applicazione e il modo in cui Firepower categorizza tale applicazione.
Tenendo presenti queste informazioni, il sistema esegue firewall-engine-debug. Nell'output del comando debug, il traffico viene bloccato in base al tag dell'applicazione.
Anche se non esiste una regola che blocca esplicitamente http://cnn.com, la visualizzazione degli annunci contrassegnati viene bloccata nella scheda Applicazioni di una regola ACP.
Dati | Istruzioni |
Risoluzione dei problemi relativi al file dal dispositivo Firepower per il controllo del traffico | http://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html |
supporto di sistema - debug firewall-engine e output system-support-trace | Per istruzioni, vedere questo articolo |
Esportazione criteri di controllo di accesso | Selezionare Sistema > Strumenti > Importa/esporta, selezionare la policy di controllo dell'accesso e fare clic sul pulsante Esporta |
Attenzione: Se il provider di servizi di audioconferenza contiene un criterio SSL, rimuovere il criterio SSL dal provider di servizi di audioconferenza prima dell'esportazione per evitare di divulgare informazioni riservate sull'infrastruttura a chiave pubblica
Se è in uso un criterio SSL e la risoluzione dei problemi relativi al criterio di controllo dell'accesso non ha rilevato il problema, il passaggio successivo consiste nella risoluzione dei problemi relativi al criterio SSL.
Fare clic qui per continuare con l'articolo successivo.