Nov 03 2009
Sniffing del traffico di rete con Cisco ASA 5505
Panoramica
Può capitare, alle volte, di trovarci nella necessità di dover fare troubleshooting sulla nostra rete in conseguenza di un qualche malfunzionamento (software o hardware che sia); in alcuni casi, può essere estremamente utile “sniffare” il traffico di rete, cioé avere in una qualche forma comprensibile all’essere umano l’insieme (o, più spesso, un sottoinsieme) delle comunicazioni che avvengono sulla rete.
Per sniffare il traffico su una rete locale (o solo su alcuni hosts della stessa), bisogna innanzitutto avere uno switch che consenta tale attività (cioé uno switch managed), quindi utilizzare un software che consenta l’attività di sniffing vera e propria: il più famoso di questi è senza dubbio Wireshark.
Può succedere però che si debba verificare se il traffico transita o meno sul nostro firewall; in tal caso, è necessario che l’operazione di sniffing avvenga direttamente sul firewall, e a meno che il firewall non sia una macchina Windows o Linux, non è possibile utilizzare Wireshark o tcpdump. Se il firewall è un Cisco ASA, è possibile utilizzare IOS per poter sniffare il traffico, oppure è possibile utilizzare ASDM (ovvero l’interfaccia web di amministrazione), che non ho la più pallida idea di come funzioni; in genere sui firewall Cisco si utilizza la riga di comando.
Sniffing del traffico
Per i miei test su questa funzionalità dell’ASA, ho ripreso l’ambiente di test descritto nel precedente articolo riguardante la VPN IPSEC tra due ASA 5505.
Come prima prova, effettuerò lo sniffing del traffico ICMP dal client su LAN1 al firewall ASA-1. Per farlo dovrò utilizzare il comando capture di IOS; sia questo comando, sia i successivi, vengono eseguiti in privileged mode:
capture traffic_asa1_inside interface inside
dove capture indica il comando da utilizzare per istruire l’ASA sulla cattura del traffico di rete, traffic_asa1_inside è un nome da dare a piacere che indica la singola operazione di sniffing (serve perché potrei voler utilizzare diversi processi di cattura per diversi scopi), interface inside indica l’interfaccia del firewall sulla quale avviene il monitoraggio del traffico; da notare che dando queste indicazioni, viene catturato tutto il traffico di rete.
Fatto questo, pingo, dal client su LAN1, il firewall ASA-1, quindi dovrò vedere sul dispositivo se la cattura avviene correttamente; a questo scopo, devo digitare il seguente comando sull’ASA (dopo aver pingato il firewall, ovviamente):
show capture traffic_asa1_inside
una parte dell’output del comando sarà simile al seguente:
1 2 3 4 5 6 7 8 | 14: 11:36:14.393961 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request 15: 11:36:14.394190 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply 16: 11:36:15.399072 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request 17: 11:36:15.399210 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply 18: 11:36:16.412881 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request 19: 11:36:16.413018 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply 20: 11:36:17.426812 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request 21: 11:36:17.426949 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply |
Vorrei porre l’attenzione sul fatto che tutte le righe iniziano con un numero, ma questo numero, nel mio caso, non parte da 1, ma da 14. Questo avviene perché, prima delle mie richieste ICMP, viene loggata l’attività che svolgo sul firewall, in quanto sono loggato allo stesso via SSH, di conseguenza, il comando capture così indicato sniffa tutto il traffico di rete, rendendo più complicata la lettura dell’output restituito. Per ovviare a questo inconveniente, devo limitare il traffico catturato, interrompendo prima di tutto lo sniffing del traffico, con il comando:
no capture traffic_asa1_inside
in questo modo al firewall viene indicato di interrompere la cattura del traffico. Per poter limitare lo sniffing dei pacchetti di rete a determinati protocolli, è necessario utilizzare delle access-list che indichino il tipo di traffico da monitorare, per poi essere utilizzate col comando capture, come mostrato di seguito:
1 2 3 4 | configure terminal access-list test_icmp extended permit icmp any interface inside exit capture icmp_asa1_inside access-list test_icmp interface inside |
le righe che ci interessano sono la 2 e la 4 (se il significato delle altre due righe non è conosciuto, consultare il precedente articolo riguardante la configurazione di base di un Cisco ASA), in particolare, la riga 2 rappresenta il comando per creare la access list chiamata test_icmp che consente il traffico ICMP tra la rete locale e l’ASA, mentre la riga 4 è la ripetizione del comando capture, con in più l’indicazione di monitorare esclusivamente il traffico consentito dall’access list test_icmp. Se dal mio PC vado a pingare il firewall ASA-1, posso poi dare il comando show capture per verificare il traffico ICMP sull’interfaccia inside:
show capture icmp_asa1_inside
il cui output è questo:
1 2 3 4 | 1: 12:41:30.148582 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request 2: 12:41:31.151572 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request 3: 12:41:32.154365 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request 4: 12:41:33.155280 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request |
In questo caso vedo solamente le richieste ICMP e non le relative risposte, ciò dipende dall’impostazione che ho dato precendentemente all’access-list; se voglio vedere anche le risposte alle richieste ICMP, modificherò l’access-list in questo modo:
1 2 3 4 | configure terminal access-list test_icmp extended permit icmp 192.168.1.0 255.255.255.0 192.168.1.0 255.255.255.0 no access-list test_icmp extended permit icmp any interface inside exit |
Per testare il funzionamento dello sniffing basato sulla access-list cambiata, è meglio pulire tutti i risultati della cattura raccolti fino ad ora:
clear capture icmp_asa1_inside
ora, se pingo il firewall e digito di nuovo il comando show capture mostrato in precedenza, avrò questo output:
1 2 3 4 5 6 7 8 | 1: 12:48:34.685541 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request 2: 12:48:34.685770 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply 3: 12:48:35.687037 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request 4: 12:48:35.687220 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply 5: 12:48:36.688593 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request 6: 12:48:36.688730 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply 7: 12:48:37.690989 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request 8: 12:48:37.691141 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply |
In questo caso è decisamente semplice interpretare l’output mostrato dal firewall Cisco, ma se mi trovo a dover sniffare il traffico di diversi protocolli su un link di rete piuttosto trafficato, potrei trovarmi in difficoltà nel capire ciò che avviene. In tal caso, il Cisco ASA ci viene incontro con una simpaticissima funzionalità, che consiste nel poter scaricare un file rappresentante la cattura del traffico visualizzabile con Wireshark. Per poter sfruttare questa funzionalità, è necessario avere il server web abilitato; nel caso non lo fosse, bisogna indicare questi comandi:
1 2 3 4 | configure terminal http server enable http 192.168.1.0 255.255.255.0 inside exit |
dove la riga 2 rappresenta il comando per abilitare il server web (che rimane in ascolto in modo predefinito in modalità https), mentre la riga 3 indica gli host che possono connettersi via https al firewall e su quale interfaccia, nel nostro caso, gli hosts della rete 192.168.1.0/24 sull’interfaccia inside.
Ora possiamo connetterci tramite un browser all’indirizzo
https://192.168.1.254/capture/icmp_asa1_inside/pcap
dove al posto di icmp_asa1_inside andremo a mettere il nome che abbiamo assegnato alla cattura del traffico tramite il comando capture. Essendo la connessione di tipo https, verrà segnalata l’inaffidabilità del certificato, possiamo proseguire ignorando tranquillamente la segnalazione, dopodiché ci verranno richiesti nome utente e password, ed a quel punto bisogna inserire la password per entrare in privileged mode, senza indicare il nome utente; fatti questi passaggi, ci verrà richiesto di salvare il file pcap, a cui daremo un nome a scelta con estensione .pcap, visualizzabile direttamente con Wireshark. Nei miei test (decisamente poco esaustivi), ho notato come Wireshark mi apra perfettamente i file generati dall’ASA, escludendo però l’ultima riga e restituendo questo errore all’apertura del file .pcap: “The capture file appears to have been cut short in the middle of a packet”; questo errorino comunque non pregiudica una corretta visualizzazione del traffico sniffato.
Conclusioni
La funzionalità di sniffing integrata nel Cisco ASA può risultare molto utile quando si tratta di effettuare troubleshooting su determinate connessioni di rete. In questo articolo ho fatto alcuni test connettendomi al firewall via SSH, ma nel mondo reale, secondo me è caldamente raccomandabile sniffare il traffico connettendosi all’ASA direttamente in console, questo per evitare che eventuali comunicazioni di rete tra il proprio host e il firewall si vadano a sovrapporre al traffico vero e proprio che si vuole monitorare.
Link di riferimento
http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a00807c35e7.shtml





