Disquisizione tra amici:

In una qualunque notte informatica di esperimenti informatici tra amici informatici la disquisizione verte su un problema reale che, almeno una volta, ha toccato tutti i tecnici, consulenti e sistemisti: come si può gestire la posta elettronica di un proprio cliente che ha un’elevata mole di messaggi ogni giorno?

Premessa e problema:

Ad oggi, l’accesso alla posta elettronica che ognuno di noi ha su questo o quell’altro gestore, è regolato dagli standard di due protocolli applicativi, POP3 e IMAP. A grandi linee (salvo configurazioni particolari dei client di posta elettronica) i due protocolli hanno, come sostanziale differenza nel metodo di funzionamento, che il POP3 si collega al server del nostro gestore di posta, scarica i messaggi della nostra casella sul nostro client di posta e li cancella dalla casella ospitata sul server; il protocollo IMAP invece, una volta stabilita la connessione con il server del nostro gestore, crea una sorta di sincronizzazione di quelli che sono i messaggi e le sotto directory tra la casella ospitata sul server e il client di posta.

Sempre a grandi linee possiamo dire che, utilizzando il POP3, tutta la nostra posta risiederà sul nostro pc, consultabile dal nostro client di posta e la nostra casella sul server sarà sempre pulita… Se però non ho il mio pc sotto mano non posso consultare la mia posta. Utilizzando il protocollo IMAP e con l’avvento dei WebMail ho la possibilità di accedere sempre e comunque alla mia posta elettronica da qualsiasi pc che sia connesso a internet… Se però ho un’eccessiva mole di messaggi corro il rischio che la mia casella si blocchi facendo ricevere ai mittenti dei miei messaggi quel fastidioso errore 552, con messaggi del tipo “Requested mail action aborted: exceeded storage allocation”. Conclusione: ci sono pro e contro nell’utilizzo di tutti e due i protocolli di posta.

Un ulteriore problema è che la maggior parte dei client di posta (outlook e outlook express più di tutti) lavorando con grandi quantità di messaggi di posta, dopo un pò si bloccano, questo perchè i client di posta scaricano la posta archiviando il tutto in files con estensione proprietaria dai quali vanno a leggere ogni volta che apriamo il programma. Per outlook questo file ha estensione .pst, tale file cresce in maniera direttamente proporzionale ai messaggi che scarico e leggo sul mio client outlook e, al raggiungimento e/o al superamento della soglia dei 2 Gb manda pressochè in crash il client stesso.

Tutti questi problemini ed errori, fanno sì che spesso, tecnici, consulenti e sistemisti, debbano dire al proprio cliente che ha perso quasi irrimediabilmente la sua posta elettronica. In questo scenario, come si può correre ai ripari in maniera preventiva?

Soluzione:

Probabilmente ci sono anche altri software che fanno quello che stiamo per fare, ma diamo per scontato che alcuni sono a pagamento e altri non ci soddisfano, quindi procediamo nel configurare una Linux Box che si preoccupi di accedere alla nostra casella di posta e di creare un archivio dei nostri messaggi da poter poi consultare senza il supporto di webmail o client di posta. Per fare ciò decidiamo di trasformare i nostri messaggi di posta in pagine web, dove l’html ci dà la possibilità di non essere vincolati a un software in particolare per poter leggere i nostri messaggi e soprattutto abbiamo la possibilità di spostare i file dove vogliamo e di eseguire backup su qualsiasi supporto.

Per questo esperimento è stata utilizzata una Ubuntu Server 12.10 per la comodità di poter visualizzare il risultato direttamente sul server web Apache2 della distribuzione ma, può essere usata una qualsiasi distribuzione linux, anche desktop e senza il supporto di un server web perchè le pagine html sono comunque interpretabili localmente dal browser.

La prima cosa da fare è dotare il sistema operativo di due tool che serviranno per raggiungere lo scopo; il primo si chiama Archivemail e il suo compito è collegarsi al server di posta in IMAP e creare un archivio della casella di posta in locale nel formato MBOX. Potete scaricare questo tool da qui oppure, su distribuzioni Debian based, installarlo direttamente con il gestore di pacchetti APT tramite il comando:

sudo apt-get install archivemail

Il secondo tool si chiama Hypermail ed è quello che si occupa di trasformare gli archivi MBOX in pagine html, il tool Hypermail non è più incluso nei repository ufficiali di Ubuntu, ma possiamo installarlo a mano tramite i comandi:

wget http://archive.ubuntu.com/ubuntu/pool/universe/h/hypermail/hypermail_2.2.0.dfsg-2_i386.deb
dpkg -i hypermail_2.2.0.dfsg-2_i386.deb

se le installazioni sono andate a buon fine tramite il comando which dovremmo vedere una cosa del genere:

draven@osiris:/$which archivemail hypermail
/usr/bin/archivemail
/usr/bin/hypermail

Ora non resta che far funzionare i nostri due tool; per prima cosa creiamo una cartella all’interno della home del nostro utente che ospiterà gli archivi MBOX:

draven@osiris:/$mkdir /home/draven/archivioposta

Creiamo l’archivio MBOX tramite i comandi:

cd /home/draven/archivioposta
archivemail -d0 -u --no-compress --copy imap://username:password@server/directory

Archivemail ha diversi attributi, visualizzabili tramite il man, per personalizzare l’archiviazione; quelli che abbiamo utilizzato sono:

• -d0 indica il numero di giorni al di sotto dei quali i messaggi vengono presi in considerazione per l’archiviazione, in questo caso, scrivendo zero giorni vengono archiviati tutti i messaggi.
• -u evita di archiviare i messaggi contrassegnati come non letti nella casella di posta.
• –no-compress crea i file MBOX senza comprimerli in formato gzip.
• –copy importantissimo per evitare che i messaggi archiviati nel file MBOX vengano cancellati automaticamente dal programma all’interno della casella
• imap://username:password@server/directory sono le coordinate da dare al programma per farlo collegare in IMAP alla nostra casella di posta; vi ricordo che le directory delle caselle di posta solitamente si chiamano: INBOX (posta in arrivo), Sent (posta inviata), Trash (cestino), mentre invece le cartelle create dall’utente hanno lo stesso nome ma preceduto da INBOX., quindi un’ipotetica cartella “Lavoro” si chiamerà INBOX.Lavoro.

Il risultato che troverete all’interno della cartella archivioposta sarà un file MBOX con il nome della cartella che avete specificato nel comando di archivemail più _archive (Es.: INBOX_archive).

Ora non ci resta che trasformare il file MBOX in pagine html consultabili tramite il comando:

hypermail -L it -m /home/draven/archivioposta/INBOX_archive -d /var/www/posta -p

Anche hypermail ha diversi attributi, quelli usati sono:

• -L it specifica la lingua italiana.
• -m /home/draven/archivioposta/INBOX_archive dice a programma qual’è il file MBOX da processare.
• -d /var/www/posta specifica la cartella di destinazione dei file html, nel mio caso /var/www/posta dove /var/www è la root del server web e di conseguenza ho la possibilità di vedere direttamente la posta tramite il browser all’indirizzo http://indirizzomioserver/posta.
• -p è l’attributo che dice ad hypermail di stamparmi a video un report del processo di creazione in corso.

A questo punto, quello che dovreste vedere all’interno della cartella di destinazione che ospita i vostri files, è una serie di pagine html

La pagina index.html è la principale, che visualizza l’elenco dei messaggi contenuti all’interno della cartella che abbiamo processato con archivemail; attachment, author, date e subject fanno la stessa cosa della index, elencando però i messaggi in ordine per allegato, autore, data e oggetto. Cliccando sul titolo del messaggio in elenco vedo il contenuto del messaggio che, come vediamo dall’immagine sopra corrisponde ad una pagina html nominata sequenzialmente con dei numeri; quindi, se all’interno della cartella che ho archiviato ci sono 100 messaggi, hypermail creerà 100 pagine html del tipo 0001.html, 0002.html, ecc. Gli allegati dei messaggi verranno salvati in delle cartelle chiamate att- e il numero corrispondente al messaggio.

A questo punto abbiamo concluso il nostro esperimento che, vi assicuro, funziona benissimo. Ma siccome non bisogna mettere limiti alla “sperimentazione informatica”, prossimamente vedremo come automatizzare questo processo grazie all’aiuto di Bash scripting e eventualmente come personalizzare la generazione dei file html di hypermail con l’aiuto del C.

Il vantaggio dei sistemi embedded è che possono essere implementati tramite l’utilizzo di hardware non proprio “standardizzato” come può essere un personal computer, questo comporta che la scelta dell’hardware può essere fatta in relazione alle risorse che il sistema dovrà utilizzare per lavorare efficientemente. Esistono varie società specializzate nella progettazione e creazione di piccoli sistemi hardware che, molto spesso, sembrano studiati su misura per particolari necessità.

Se il nostro scopo ultimo è uno sniffer hardware per intercettazioni LAN, le esigenze che devono sicuramente essere soddisfatte sono le seguenti:

• Dimensioni ridotte: il nostro “intercettatore” dovrà essere facilmente occultabile.
• Aspetto: meno lo sniffer appare simile a un computer meglio è, soprattutto se dovrà risiedere all’interno di un armadio rack.
• Potenza di calcolo: se la rete da intercettare è a 1 Gbit c’è bisogno di una discreta potenza di calcolo per processare il flusso di dati in transito.
• Schede di rete multiple: esistono diversi sistemi embedded con più di una scheda di rete (4 – 8 o 16) collegate direttamente sulla scheda madre.
• Velocità di I/O: se si pensa sempre al peggio, cioè avere a che fare con intercettazioni di rete a 1 Gbit, i dischi in dotazione al nostro sistema embedded dovranno essere di ottimo livello (e forse anche configurati in RAID)

Per hardware di questo tipo o per qualsiasi altro network appliance che dovrete creare, vi consiglio di dare un’occhiata al seguente url: www.win-ent.com

Per quanto riguarda la parte software del nostro sniffer utilizzeremo naturalmente Linux; i nuovi kernel delle moderne distribuzioni Linux mettono a disposizione decine di funzionalità utili all’implementazione di un sistema per networking. Tra le più in vista troviamo:

• Bond device: possibilità di unire più canali fisici in un unico canale logico, aumentando così la banda passante a disposizione.
• VLAN: Linux offre un supporto totale alle VLAN, dal supporto completo del protocollo 802.11Q fino ad arrivare a funzioni avanzate come il routing tra VLAN, il firewalling e lo sniffing.
• Bridge device: una distribuzione Linux, tramite i device bridge può trasformarsi in uno switch software.

Oltre alle funzionalità native del kernel, la creazione di uno sniffer prevede che la distribuzione possegga i seguenti pacchetti:

• Bridge utils: un pacchetto di utility user mode per la gestione del bridge del kernel.
• Ebtables: è il pacchetto per la gestione del firewalling di Linux.
• Sniffer: sarà necessario l’uso di uno sniffer di rete per raccogliere e filtrare il flusso di dati in transito.

n.b.: Sappiate che la configurazione dello sniffer è implementabile con qualsiasi distribuzione Linux, ma sappiate anche che alcuni dei comandi utilizzati possono variare tra una distribuzione e un’altra.

La macchina ideale per la creazione del nostro intercettatore dovrà avere almeno tre schede di rete, due delle quali saranno configurate senza indirizzo IP e collegate come porte di uno switch software, la terza sarà dotata di un indirizzo da utilizzare per l’accesso al dispositivo. Per prima cosa bisogna creare lo switch software e poniamo il caso che le nostre schede siano eth0, eth1 e eth2. Le prime due sono quelle che faranno parte dello switch software. Per fare ciò, digitiamo in console i seguenti comandi:

ifconfig eth0 -arp up
ifconfig eth1 -arp up

Questi comandi attivano le due schede di rete senza fornire loro un indirizzo IP e, inoltre, vietando loro l’utilizzo del protocollo ARP. Attivate le porte bisogna utilizzare le bridge utils per la creazione dello switch virtuale:

brctl addbr br0

Questo comando crea il nostro switch virtuale al quale diamo il nome di br0, dove br0 è anche il nome dell’interfaccia virtuale che il sistema operativo assocerà al backplane dello switch di rete. Ora bisogna associare le interfacce di rete allo switch virtuale:

brctl addif br0 eth0
brctl addif br0 eth1

Fatto questo, ora che le due schede sono a tutti gli effetti due porte dello switch br0, dobbiamo aumentare la sicurezza disabilitando il protocollo di spanning tree su br0, in questo modo br0 non si annuncerà al mondo nel caso in cui siano presenti altri switch con questo protocollo attivo:

brctl stp br0 off

Ora non resta che attivare l’interfaccia corrispondente al backplane del nostro switch virtuale:

ifconfig br0 -arp up

Abbiamo br0 che adesso è un’interfaccia di rete come tutte le altre, è quindi possibile utilizzare uno sniffer per catturare il traffico passante su di essa. Possiamo scegliere in una vasta categoria di software, sicuramente in prima linea (per numero di utilizzatori e facilità di utilizzo) troviamo l’indiscusso tcpdump. Il suo punto di forza è la possibilità di utilizzare un potente sistema di filtri che ci permette di intercettare solo il traffico che ci interessa. Il comando da scrivere in console per intercettare il traffico sul backplane dello switch software che abbiamo creato è il seguente:

tcpdump -n -w /var/spool/sniffer/intercettazione.pcap -s0 -C 100 -i br0

Vediamo cosa significa:

• tcpdump: chiaramente richiama il nostro software di sniffing.
• -n: specifica al programma di non effettuare conversioni riguardanti i nomi dei servizi associati alle porte, gli host, ecc., lasciando tutto quello che viene intercettato in formato numerico. Se non specificato accadrebbe che, in un esempio pratico, se il traffico intercettato fosse una connessione ssh, sul record corrispondente alla connessione intercettata verrebbe scritto SSH invece di 22 nella parte che si riferisce alle porte utilizzate.
• -w nomefile: dice al programma di salvare i dati intercettati nel file specificato (in formato pcap).
• -s0: questa opzione è importante perché normalmente tcpdump salva soltanto i primi 68 elementi di un pacchetto intercettato (questo perché solitamente viene utilizzato come strumento di diagnosi dagli amministratori di rete, ai quali interessa più che altro l’header del pacchetto e non il contenuto). Specificando questa opzione il programma catturerà sia l’header che il body del pacchetto.
• -C 100: questa opzione ci permette di gestire una rotazione dei file di output dell’intercettazione, in questo modo eviteremo di dover gestire file di dimensioni smisurate quando andremo ad analizzare il traffico che abbiamo intercettato. Specificando questa opzione tcpdump crea un nuovo file con lo stesso nome più un numero progressivo alla fine del nome del file nel momento in cui vede che il file precedente ha raggiunto la soglia specificata dopo -C.
• -i interfaccia: naturalmente dobbiamo specificare (e lo facciamo tramite questa opzione) quale è l’interfaccia oggetto del nostro sniffing.

Finito il nostro viaggio all’interno dello sniffing di rete posso solo consigliarvi Wireshark (www.wireshark.org) come software da utilizzare per l’analisi dei dati intercettati che, probabilmente è la parte più spiacevole di tutto il processo di intercettazione, vista la mole di dati generata da uno sniffing di rete (la quale comprende una minima parte di dati che ci interessa e che dobbiamo ritrovare all’interno di tutto il resto!).

#include <iostream>
class Saluti
{
public:
    void ciao()
    {
        std::cout << "Hello World!" << std::endl;
    }
};
int main()
{
    Saluti s;
    s.ciao();
    return 0;
}