Ricerche IT

Scenario

Facendo riferimento ai due precedenti articoli su Postfix e Dovecot, dove si era vista una configurazione minimale di un server di posta e l’utilizzo di alias e domini virtuali, sempre basandoci sull’ambiente di test precedentemente illustrato, in questo articolo vedremo come utilizzare le mailbox virtuali su Postfix, e quindi come accedere a queste mailbox con Dovecot. L’utilizzo di mailbox virtuali è un passo avanti rispetto alle configurazioni precedentemente trattate, poiché con questo tipo di caselle di posta elettronica, facciamo in modo che le mailbox siano completamente distinte dagli utenti di sistema, in questo modo non saremo costretti a creare un utente Linux da utilizzare ogniqualvolta abbiamo bisogno di una casella di posta. Oltre alle mailbox, avremo anche dei domini virtuali, in tal modo potremo ospitare sullo stesso server caselle di posta elettronica riferite a diversi domini, con tutti i vantaggi del caso. Le informazioni su mailbox e domini virtuali saranno contenute in file di testo sul file system del sistema operativo.

Configurazione di Postfix

Andremo a configurare mailbox virtuali sul server Giapeto per i domini cerere.mail e saturno.mail. In questa situazione, se esistono, è bene cancellare dal file di configurazione /etc/postfix/main.cf tutte le impostazioni relative ad alias e domini virtuali, poiché queste impostazioni andranno eventualmente riscritte secondo il formato richiesto dalle mailbox virtuali. La configurazione precedentemente descritta si esplicita nelle seguenti direttive nel file di configurazione /etc/postfix/main.cf; le altre informazioni riferite ai parametri basilari di Postfix rimangono quelle descritte nell’articolo riguardante la configurazione di base di Postfix:

1
2
3
4
5
6
7

virtual_mailbox_domains = cerere.mail saturno.mail
virtual_mailbox_base = /var/spool/vmail
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_minimum_uid = 5000
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
virtual_alias_maps = hash:/etc/postfix/virtual

La prima riga fa riferimento ai domini virtuali per i quali il sistema è abilitato a ricevere messaggi di posta, cioè cerere.mail e saturno.mail. La seconda riga fa riferimento alla directory di base scelta come deposito di tutta la posta ricevuta su questo server, al cui interno vi saranno le varie sottodirectory relative ai domini virtuali, e per ogni dominio virtuale vi saranno le directory riferite alle varie mailbox di quel dominio, dove verrà depositata la posta elettronica, secondo il formato di archiviazione Maildir, come vedremo di seguito. La terza riga indica il file dove vengono elencate le mailbox virtuali definite sul sistema e la loro posizione sul file system, a partire dalla directory definita in precedenza col parametro virtual_mailbox_base. La quarta riga specifica l’id minimo dell’utente utilizzato dal sistema per andare a scrivere i file rappresentanti i messaggi di posta sul file system, nella posizione indicata con il parametro virtual_mailbox_base; questo utente avrà un ID utente e un ID di gruppo, specificati con precisione nella quinta e nella sesta riga della porzione del file di configurazione specificata poco sopra. La settima e ultima riga è opzionale, e indica la posizione del file contenente gli alias virtuali delle mailbox virtuali effettive, come descritto nell’articolo precedente riguardante gli alias virtuali, anche se nell’articolo precedente gli alias si riferivano alle mailbox di sistema e non a quelle virtuali.

Modificata la configurazione di Postfix, creiamo la directory che conterrà le mailbox virtuali:

mkdir /var/spool/vmail

Ora invece dobbiamo creare la mappa che conterrà l’elenco delle mailbox virtuali definite sul sistema:

touch /etc/postfix/vmailbox

Quindi andremo ad editare il file vmailbox appena creato per definire l’elenco delle mailbox sul nostro sistema, in questo modo:

1
2
3
4

salvor.hardin@cerere.mail   cerere.mail/salvor.hardin/
hober.mallow@cerere.mail    cerere.mail/hober.mallow/
preem.palver@saturno.mail   saturno.mail/preem.palver/
stor.gendibal@saturno.mail  saturno.mail/stor.gendibal/

Questo è un tipico file di mappa di Postfix, dove nella prima colonna sono indicate le mailbox virtuali, mentre nella seconda è indicato il percorso della casella in cui andrà depositata la posta, a partire dalla “radice” che altro non è che il percorso indicato nella direttiva virtual_mailbox_base del file main.cf, come visto in precedenza; ad esempio, la posta della mailbox virtuale salvor.hardin@cerere.mail verrà depositata nella directory /var/spool/vmail/cerere.mail/salvor.hardin. Da notare lo slash (/) alla fine del percorso di ogni mailbox virtuale, il quale indica a Postfix di archiviare la posta nel formato Maildir.

Creare a questo punto la mappa in formato .db partendo dal file appena editato:

postmap /etc/postfix/vmailbox

Ora editiamo il file di mappa /etc/postfix/virtual in cui andare ad inserire gli alias per le mailbox virtuali:

1
2
3
4

postmaster@cerere.mail    salvor.hardin@cerere.mail
abuse@cerere.mail         salvor.hardin@cerere.mail
postmaster@saturno.mail   preem.palver@saturno.mail
abuse@saturno.mail        preem.palver@saturno.mail

e compiliamo quindi la mappa degli alias:

postmap /etc/postfix/virtual

Configurazione di Dovecot

Configurato Postfix, dobbiamo informare anche Dovecot delle mutate impostazioni di archiviazione della posta elettronica, per cui Dovecot dovrà essere informato della nuova posizione delle mailbox; inoltre, Dovecot non si baserà più sugli utenti di sistema per l’autenticazione sulla casella di posta, per cui andremo a fornirgli un file in cui sono elencati gli utenti ed un file in cui sono elencate le relative password, secondo lo schema stesso di Linux, basato su un file passwd dove sono indicati gli utenti, ed un file shadow dove sono elencate le password. Di seguito vediamo le impostazioni da inserire nel file di configurazione di Dovecot /etc/dovecot/dovecot.conf, fare attenzione ad aprire e chiudere le graffe, esistenti e non, all’interno del file di configurazione:

1
2
3
4
5
6
7
8
9
10

mail_location = Maildir:/var/spool/vmail/%d/%n
auth default {
  mechanisms = plain login
  userdb passwd-file {
    args = /var/spool/vmail/%d/etc/passwd
  }
  passdb passwd-file {
    args = /var/spool/vmail/%d/etc/shadow
  }
}

Nella riga 1 andiamo a specificare la posizione in cui Dovecot andrà a leggere la posta archiviata da Postfix, utilizzando delle variabili; ciò consente a Dovecot di leggere la posta di più domini, utilizzando la variabile %d, che indica la parte dopo la chiocciola dell’indirizzo di posta (il dominio), e la variabile %n, che indica la parte prima della chiocciola dell’indirizzo di posta (il nome utente): tra l’altro, ciò comporta l’accortezza di autenticarsi indicando, alla richiesta del nome utente, l’indirizzo completo di posta.

La seconda riga indica l’inizio della sezione riguardante le impostazioni di autenticazione su Dovecot, che sono evidenziate ad iniziare dalla terza riga, che indica i meccanismi di transito sulla rete delle password, che nel caso illustrato vengono trasmesse in chiaro per l’autenticazione su Dovecot; questo causa qualche problema di sicurezza, poiché le password viaggiano in chiaro sulla rete, quindi basta sniffarla il tempo necessario per carpire le password. Quarta e quinta riga indicano la posizione del file in cui sono indicati gli utenti possessori di una casella di posta, mentre settima e ottava riga indicano il percorso del file contenente il nome utente e la relativa password; da notare che anche in questo caso è stata utilizzata la variabile %d, seguita dalla directory etc/ che conterrà i due file: tale directory è stata creata semplicemente per coerenza con la struttura delle directory Linux, ma non è assolutamente necessaria.

Creazione directory, utenti e password

Ora bisogna creare gli utenti e le password sia per l’accesso di Postfix alla directory /var/spool/vmail, sia per l’autenticazione su Dovecot da parte di un qualsiasi MUA (Mail User Agent). Cominciamo creando l’utente di sistema che useremo per l’accesso alla directory in cui saranno contenute le mailbox virtuali:

useradd -d /var/spool/vmail -s /bin/false -m -U -u 5000 vmail

Con questo comando creiamo l’utente vmail, a cui assegnamo la home directory /var/spool/vmail e la shell “fasulla” /bin/false, ed a cui assegnamo l’id utente 5000, come indicato nella configurazione di Postfix; inoltre, con l’opzione –U andiamo a creare un gruppo con caratteristiche identiche all’utente appena creato. È possibile notare che la home directory assegnata all’utente vmail corrisponde alla directory indicata in Postfix come directory “root” per l’archiviazione di posta elettronica, in questo modo assegnamo subito a questo utente l’ownership (ovvero la proprietà) della directory, poiché sarà l’utente vmail che effettivamente avrà il compito di archiviare sul file system la posta elettronica.

Il passaggio successivo consiste nel creare le directory relative ai domini, ai file contenenti utenti e password, ed alle mailbox virtuali. Iniziamo con le directory relative ai domini cerere.mail e saturno.mail:

1
2

mkdir /var/spool/vmail/cerere.mail
mkdir /var/spool/vmail/saturno.mail

Ora creiamo la directory etc per ogni dominio, che conterrà i file relativi ad utenti e password corrispondenti alle mailbox virtuali create per ogni dominio; gli utenti e le password verranno utilizzati da Dovecot per autenticare l’accesso alle caselle di posta virtuali:

1
2

mkdir /var/spool/vmail/cerere.mail/etc
mkdir /var/spool/vmail/saturno.mail/etc

Ora andiamo a creare, per ogni dominio, il file degli utenti (passwd) e delle password (shadow), coerentemente con quanto indicato nel file di configurazione di Dovecot:

1
2
3
4

touch /var/spool/vmail/cerere.mail/etc/passwd
touch /var/spool/vmail/cerere.mail/etc/shadow
touch /var/spool/vmail/saturno.mail/etc/passwd
touch /var/spool/vmail/saturno.mail/etc/shadow

Creati i file, bisogna inserire il contenuto relativo a utenti e password, di seguito sono elencati i comandi per inserire i contenuti dei due file degli utenti passwd:

Utenti per il dominio cerere.mail

1
2

echo salvor.hardin::5000:5000::/var/spool/vmail/cerere.mail/salvor.hardin >> /var/spool/vmail/cerere.mail/etc/passwd
echo hober.mallow::5000:5000::/var/spool/vmail/cerere.mail/hober.mallow >> /var/spool/vmail/cerere.mail/etc/passwd

Utenti per il dominio saturno.mail

1
2

echo preem.palver::5000:5000::/var/spool/vmail/saturno.mail/preem.palver >> /var/spool/vmail/cerere.mail/etc/passwd
echo stor.gendibal::5000:5000::/var/spool/vmail/saturno.mail/stor.gendibal >> /var/spool/vmail/cerere.mail/etc/passwd

Dall’analisi di questi file, si può intuire che nel file viene indicato il nome utente, poi l’ID utente e di gruppo (il 5000 preso per l’utente locale vmail), quindi viene indicata la directory in cui Dovecot andrà a leggere la posta per quell’utente

Ora bisogna popolare il file shadow con le password degli utenti. Siccome voglio che le password siano criptate (ad esempio utilizzando l’algoritmo md5, anche se non è il più sicuro che esista), per generare le password dovrò utilizzare il comando dovecotpw. Ad esempio, per assegnare a tutti gli utenti la password Password00, dovrò scrivere qualcosa del genere:

Password per il dominio cerere.mail

1
2

echo salvor.hardin:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/cerere.mail/etc/shadow
echo hober.mallow:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/cerere.mail/etc/shadow

Password per il dominio saturno.mail

1
2

echo preem.palver:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/saturno.mail/etc/shadow
echo stor.gendibal:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/saturno.mail/etc/shadow

A questo punto, avendo trafficato con l’utente root all’interno della directory /var/spool/vmail, è necessario reimpostare l’ownership della directory e del suo contenuto con il comando

chown –R 5000:5000 /var/spool/vmail

Collaudo del sistema

Per testare il server di posta elettronica, è sufficiente inviare una mail ad uno degli indirizzi di posta appena creati, e Postfix, alla ricezione della mail, creerà la directory in cui depositare la posta e che rappresenterà il deposito di tutta la posta per quella determinata mailbox. Se voglio controllare cosa accade durante la ricezione della mail, sia per curiosità, sia per motivi di troubleshooting, è possibile consultare il log della posta, contenuto nel file /var/log/mail.log, che ci darà tutte le informazioni che ci necessitano. Se invece voglio controllare in tempo reale che accade, posso utilizzare un’opzione sciccosa del comando tail in questo modo:

tail –f /var/log/mail.log

che mi mostrerà appunto in tempo reale le righe che vengono eventualmente aggiunte al file /var/log/mail.log.

Conclusioni

Questa configurazione comincia ad essere un tantino più professionale rispetto alle configurazioni proposte in precedenza, infatti ora possiamo gestire con maggiore flessibilità più domini ed i relativi utenti, che non sono più utenti di sistema, per cui possiamo avere lo stesso nome utente per domini diversi. Questa configurazione però ha anche alcuni difetti, ovvero il metodo di creazione di utenti e password per l’accesso alla posta elettronica, che è un po’ macchinoso basandosi sulla riga di comando; un’altra mancanza non indifferente è rappresentata dal fatto che sostanzialmente, con questa configurazione, ci fidiamo di tutto ciò che ci arriva, poiché non vi sono restrizioni sulla posta in arrivo.

Per la definizione delle mappe delle mailbox virtuali e degli alias, nonché per la definizione di utenti e password per Dovecot, vedremo in seguito una configurazione in cui Postfix e Dovecot utilizzano MySQL al posto delle tecniche trattate finora, mentre per spam e antivirus verranno analizzati alcuni strumenti come greylist e blacklist, e ClamAV come sistema di scansione antivirus della posta elettronica. Rimane fondamentale una corretta configurazione di Postfix per impedire che il nostro MTA funga da open relay, ciò dipende essenzialmente, per quanto visto finora, da ciò che si inserisce nel parametro mynetworks, come illustrato negli articoli precedenti.

Link di riferimento

How to configure PostFix and Dovecot for Virtual Users with out a Database

Stasera, cazzeggiando un po’ per la blogosfera, che non ho voglia di dedicarmi a cose “serie”, mi sono imbattuto in questo post di Gaspar Torriero, in cui viene descritto un intervento che egli ha fatto al Venezia Camp (già svoltosi) insieme a Marco Massarotto, in cui, da quanto leggo dal blog di Gaspar Torriero, e se non ho capito male, si è parlato da due punti di vista differenti rispetto all’opportunità per le aziende di fare promozione tramite il Web, o qualcosa di simile.

Gaspar Torriero è scettico, e porta a sostegno della propria opinione alcuni esempi, tra cui questo thread del Bertuccia Forum. Il thread, a mio parere, è qualcosa di assolutamente esilarante. Astenersi dalla lettura se l’argomento “regolarità intestinale” è causa di qualsivoglia turbamento.

Scenario

Si prenda in considerazione un server Windows Server 2003 con Internet Information Services 6 con installato almeno un sito Web; il server in questione ha due o più schede di rete, oppure una scheda di rete con definiti due o più indirizzi IP, ad esempio, il nostro server ha due indirizzi IP, 172.16.1.1 e 172.16.1.10. Questo server ha un’installazione di IIS predefinita, con uno o più siti Web installati. In tale situazione, IIS rimane in ascolto sulla porta 80 su tutti gli indirizzi IP definiti sulla macchina.

Ora esaminiamo l’ipotesi di dover far girare sulla stessa macchina un altro server Web, che deve anch’esso rimanere in ascolto sulla porta 80: in questo caso, bisogna fare in modo che i siti di IIS rimangano in ascolto, invece che su entrambi gli indirizzi IP, su un solo indirizzo IP; nel nostro caso scegliamo l’indirizzo 172.16.1.1, in modo da lasciare “libero” l’indirizzo 172.16.1.10 per l’altro server Web.

A prima vista, la soluzione sembrerebbe semplice, cioé configurare il sito (o i siti) Web per rimanere in ascolto solamente sull’indirizzo 172.16.1.1, come mostrato in figura 1:

Purtroppo però questa soluzione non funziona, IIS continua a rimanere in ascolto sulla porta 80 su tutti gli indirizzi IP della macchina, com’è possibile vedere col comando netstat:

netstat -noa | find ":80"

il cui output risulta essere questo:

TCP    0.0.0.0:80             0.0.0.0:0              LISTENING       2548

che indica appunto che IIS si appropria della porta 80 su tutti gli IP disponibili.

Configurazione di IIS

Con i normali strumenti messi a disposizione dalla console di gestione di IIS, che io sappia non c’è modo di superare questa limitazione; per risolvere il problema, possiamo utilizzare l’utility httpcfg, contenuta nel pacchetto Windows Server 2003 Support Tools, che consente di svolgere questo e altri compiti su IIS.

Il primo passo consiste nel verificare su quali porte sta in ascolto IIS, col comando

httpcfg query iplisten

che, nel mio caso, restituisce questo output:

HttpQueryServiceConfiguration completed with 1168

Ciò significa che IIS segue l’impostazione predefinita, ovvero rimane in ascolto su tutti gli IP disponibili sulla macchina. Con httpcfg posso cambiare questa impostazione, istruendo IIS per rimanere in ascolto solamente sull’IP 172.16.1.1:

httpcfg set iplisten -i 172.16.1.1

il quale restituisce questo messaggio che conferma la corretta esecuzione del comando:

HttpSetServiceConfiguration completed with 0

La conferma è utile, ma è meglio controllare se la configurazione è corretta, digitando di nuovo il comando

httpcfg query iplisten

il cui output stavolta è differente:

      IP                      : 172.16.1.1
------------------------------------------------------------------------------

La configurazione è avvenuta correttamente, per renderla attiva è necessario riavviare il servizio HTTP e i servizi dipendenti, HTTP SSL e World Wide Web Publishing Service:

net stop http /y

L’opzione /y riavvia http e i servizi dipendenti da questo senza attendere la conferma dell’utente; procediamo ora all’avvio dei servizi fermati:

net start http
net start w3svc

Dopo aver riavviato i servizi, verifichiamo con netstat che IIS si sia piegato al nostro volere:

netstat -noa | find ":80"

ora l’output del comando netstat è quello “giusto”:

TCP    172.16.1.1:80          0.0.0.0:0              LISTENING       3928

Conclusioni

httpcfg è un’utility che consente di ovviare a quella che è una “curiosa” mancanza della GUI di IIS; una volta che se ne conosce l’esistenza e le modalità d’utilizzo, è abbastanza semplice arrivare al risultato desiderato, ma il sysadmin che si trova per la prima volta di fronte ad un problema simile può perdere anche parecchio tempo prima di risolvere il problema, e ciò secondo me è negativo e soprattutto poco sensato.

Link di riferimento

http://technet.microsoft.com/en-us/library/cc786389%28WS.10%29.aspx

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