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

In questo articolo vedremo i vari step per arrivare all’implementazione di un tool che, per conto nostro, si preoccupi di testare la raggiungibilità dei server e dei servizi di cui siamo amministratori. Partiamo innanzitutto dal presupposto di avere installata una distribuzione Linux, io ho utilizzato una Debian 7.4 (Wheezy). Il nostro obiettivo finale sarà quello di ricevere una email nel caso in cui uno dei nostri server non sia raggiungibile; per fare questo abbiamo bisogno di un paio di strumenti che consentano alla nostra Debian di inviare email. Il primo è un MUA (mail user agent), ovvero un client di posta. Debian è dotata di un MUA di nome Mail che è un client utilizzabile da riga di comando (proprio quello che fa al caso nostro). Il secondo strumento è un MTA (mail transfer agent), il daemon smtp che realmente si prende in carico il compito di inviare il messaggio. Esistono moltissimi MTA, come ad esempio Postfix, SendMail, ecc., io ho scelto Ssmtp perchè in modalità satellite funziona molto bene ed è semplicissimo da configurare.

N.B. Si dice modalità satellite quando un MTA non fa da server smtp ma si occupa soltanto di trasferire il messaggio ad un altro server smtp che poi lo invierà al destinatario. Ho scelto questa modalità perchè il nostro scopo è solo quello di inviare dei messaggi, non di implementare un server di posta.

Per installare Ssmtp su debian utilizziamo il comodissimo APT:

root@ibm:/home/draven#apt-get install ssmtp

Dopo averlo installato lo configuriamo editando il file /etc/ssmtp/ssmtp.conf. Questo file dovrà contenere le informazioni del reale server smtp che utilizzeremo per l’invio, un pò come quando si configura un client di posta elettronica, io ho utilizzato un mio account Gmail e quindi nel .conf ho scritto quanto segue:

root@ibm:/home/draven#nano /etc/ssmtp/ssmtp.conf
 
root=ilmioindirizzo@gmail.com
mailhub=smtp.gmail.com:587
AuthUser=ilmiousername
AuthPass=lamiapassword
UseSTARTTLS=YES
UseTLS=YES
AuthMethod=LOGIN

A questo punto la nostra Debian è in grado di inviare email. Passiamo ora alla creazione dello script che farà i test verso i nostri server. Lo script è in Python, un linguaggio di programmazione che per funzionare ha bisogno di un interprete e, anche qui la Debian ci aiuta perchè l’interprete Python è un pacchetto già installato sulla distribuzione. Il formato degli script python è .py, quindi creiamo un file nella posizione che vogliamo, con il nome che vogliamo e con estensione .py:

root@ibm:/home/draven#nano srvmon.py

All’interno del file che io ho chiamato srvmon.py andiamo a scrivere il nostro tool:

#! /usr/bin/env python
 
from os import system
from urllib2 import urlopen
from socket import socket
from sys import argv
from time import strftime
 
def tcp_test(server_info):
    cpos = server_info.find(':')
    try:
        sock = socket()
        sock.connect((server_info[:cpos], int(server_info[cpos+1:])))
        sock.close
        return True
    except:
        return False
 
def http_test(server_info):
    try:
        data = urlopen(server_info).read()
        return True
    except:
        return False
 
def server_test(test_type, server_info):
    if test_type.lower() == 'tcp':
        return tcp_test(server_info)
    elif test_type.lower() == 'http':
        return http_test(server_info)
 
def send_error(test_type, server_info, email_address):
    subject = '%s: %s %s errore' % (strftime("%d/%m/%Y %H:%M:%S"), test_type.upper(), server_info)
    message = 'Il test di tipo %s verso %s e' fallito, l'host e' down!' % (test_type.upper(), server_info)
    system('echo "%s" | mail -s "%s" %s' % (message, subject, email_address))
 
if __name__ == '__main__':
    if len(argv) != 4:
        print('Numero di argomenti errato.')
    elif not server_test(argv[1], argv[2]):
        send_error(argv[1], argv[2], argv[3])

Analizziamo questo script:

1. nella prima parte vengono richiamate delle librerie usate all’interno dello script.
2. il blocco tcp_test è la funzione che si occuperà di effettuare test tcp su una porta e un host passati come parametri.
3. il blocco http_test è la funzione che si occuperà di effettuare test su protocollo http.
4. il blocco server_test è la funzione che prende in carico i parametri passati allo script, li controlla e decide che tipo di test effettuare.
5. il blocco send_error costruisce il messaggio da inviare e invoca il programma mail.
6. l’ultimo blocco è di controllo, restituisce un errore se i parametri passati allo script non sono esatti, altrimenti richiama la funzione send_error.

A questo punto possiamo provare ad utilizzare manualmente lo script; nel caso in cui voglio effettuare un test tcp verso un host, i parametri da inviare allo script sono i seguenti:

root@ibm:/home/draven#python srvmon.py tcp drav.it:22 miamail@mioisp.it

oppure

root@ibm:/home/draven#python srvmon.py http http://www.drav.it miamail@mioisp.it

Nel primo caso, richiamo lo script e gli passo come parametri:
protocollo = tcp
host = drav.it
porta = 22
email del destinatario della notifica = miamail@mioisp.it

Nel secondo caso, il concetto è lo stesso ma, il test che eseguo è una richiesta http sulla porta 80 verso un host.

Ora quello che realmente ci interessa è automatizzare questo processo, per farlo utilizzeremo cron, una utility che nei sistemi operativi Unix Like si occupa di schedulare e automatizzare dei processi. Per modificare il cron e fargli avviare il nostro script digitiamo:

root@ibm:/home/draven#crontab -e

all’interno di cron inseriamo tante righe quanti sono gli host che vogliamo far controllare al nostro script, in questo modo:

*/5 * * * * python /home/draven/srvmon.py tcp host1:22 miamail@mioisp.it
*/5 * * * * python /home/draven/srvmon.py tcp host2:23 miamail@mioisp.it
*/5 * * * * python /home/draven/srvmon.py tcp host3:25 miamail@mioisp.it
ecc.

Fatto questo il cron avvierà ogni 5 minuti il controllo di tutti gli host che abbiamo inserito e lo script ci invierà una email nel caso in cui il test dell’host fallirà.

In una infrastruttura web che espone siti e servizi usando un reverse proxy Nginx davanti ai web server Apache, generalmente, accade che le chiamate fatte al server web hanno come sorgente il reverse proxy. Questo comporta che i file di log del server web registreranno come ip client sempre e solo l'ip del reverse proxy. Tutto questo anche se, Nginx, ha tra i suoi header HTTP X-Forwarded-For.

HTTP X-Forwarded-For contiene l'ip reale del client, ma, Apache di default non preleva i dati da questo header. Per abilitare questa funzione è necessario installare sul web server Apache il modulo mod_rpaf:

apt-get install libapache2-mod-rpaf

Dopo l'installazione del modulo, quest'ultimo va configurato inserendo il seguente codice all'interno del file /etc/apache2/mods-available/rpaf.conf

<IfModule mod_rpaf.c>
	RPAFenable On
	RPAFsethostname On
	RPAFproxy_ips xxx.xxx.xxx.xxx (indirizzo ip del reverse proxy)
</IfModule>

Salvato il file è necessario riavviare il web server Apache.

E' possibile anche forzare il passaggio degli header inserendo i seguenti parametri nel virtual host del reverse proxy Nginx:

proxy_set_header   Host             $host;
proxy_set_header   X-Real-IP        $remote_addr;
proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;