Archivi categoria: Networking

Proteggi Mysql con GreenSQL

SQL Injection

SQL Injection

Mysql DB, GreenSQL FW e le SQL injection

Nel corso degli anni i Database hanno conosciuto un’evoluzione repentina, a questa ha fatto seguito, data l’importanza dei dati contenuti, un’escalation dei problemi inerenti la sicurezza. Le vulnerabilita’ che colpiscono i DB sono ormai molte e differenziate e gli “exploit” di tipo SQL injection sono quasi all’ordine del giorno, tra i piu’ colpiti c’e’ proprio Mysql che in pochi anni e’ diventato il default DB di moltissime applicazioni web; ecco perche’ bisogna fare molta attenzione e sapere come correre ai ripari.

Come ben noto ai web master le SQL Injection sono un problema comune di molte applicazioni web li dove le piu’ banali cause possono venire arginate da un sitemista scrupoloso e attento ad un buon hardening di sistema, possono sempre insorgere altri “bachi” non voluti, negli algoritmi di arginazione.

Una soluzione efficiente e ben strutturata la propone GreenSQL, un software Open Source che si presenta sotto l’aspetto di un proxy/firewall, al quale ci si interfaccia come una comunissima connessione ai database e gestisce le connessione con il database filtrando eventuali codici “illegali”.

Come funziona

In pratica la query inviata alla web application viene esaminata da GreenSQL, che intercetta il traffico diretto al DB, e nel qual caso la query sia ritenuta rischiosa non viene inoltrata al database e il risultato restituito sara’ nullo.
Viceversa se l’interrogazione risulta conforme alle specifiche verrà inoltrata al database e il risultato reso disponibile all’applicazione.

Il software può lavorare in tre modalità:

  • Simulation Mode (IDS)
  • Blocking Suspicious Commands (Database IPS)
  • Learning Mode
  • Active protection da query sconosciute (DB Firewall)

Come agiscono
Se l’applicazione è impostata in Simulation Mode funziona sostanzialmente come un sistema IDS (Intrusion Detection System). Tutte le query ritenute dannose vengono semplicemente loggate e poi notificate all’amministratore che può consultarle attraverso la console d’amministazione.

In modalità Blocking Suspicious Commands il sistema invece funziona come un IPS (Intrusion Prevention System). In questa modalità le query che non sono all’interno della white list del programma vengono automaticamente bloccate e, il programma, restituisce un risultato nullo all’applicazione web. Altrimenti, se la query è considerata non maligna, viene eseguita. Durante questa modalità però possono essere generati falsi positivi o falsi negativi.
Per evitare i problemi dovuti alle due modalità sopra citate è stata sviluppata la modalità Learning mode durante la quale il programma impara tutte le query che l’applicazione web può inviare e le aggiunge alla white list. Una volta finita la modalità d’apprendimento si deve ripassare ad una delle due modalità citate in precedenza, in modo da avere un livello di protezione piu’ adeguato.
Si può inoltre attivare la protezione dalle query sconosciute, questa opzione permette di bloccare in automatico i comandi sconosciuti che giungono GreenSQL. Per poter calcolare se un comando è illegale o meno si avvale di un motore di pattern matching che lavora in due modalità. La prima controlla che la query inviata non vada ad eseguire comandi amministrativi (ad esempio GRANT o REVOKE, o comandi che vanno a modificare la struttura del database). L’altra invece calcola il rischio di una query basandosi su dei metodi euristici, se il rischio è sufficientemente alto la query viene bloccata in automatico.

Calcolare il rischio delle query
GreenSQL puo’ calcolare il rischio di ogni query ; essenzialmente, questo è un sottosistema di rilevamento delle anomalie. Dopo che il rischio è calcolato, GreenSQL è in grado di bloccare la query o semplicemente creare un messaggio di avviso (questo dipende dalla modalità attivata). Ci sono una serie di operazioni euristiche che GreenSQL utilizza per il calcolo del rischio. Per esempio, il rischio di query è aumentato da:

  • L’accesso alle tabelle sensibili (gli utenti, gli account, le informazioni di credito)
  • Commenti all’interno di comandi SQL
  • Una stringa password vuota
  • Una ‘OR’ all’interno di una query
  • Un’espressione SQL che restituisce sempre vero

Per trovare anomalie, GreenSQL usa il proprio lexer ( o analizzatore lessicale ) cercando SQL tokens (costituiti da identificatori, costanti e parole chiave).

Per maggiori chiarimenti e per avere una guida ufficiale non esitate ad andare sul sito ufficiale di GreenSQL FW

 

Marionnet simulatore di Reti

MarionnetVirtual Network Laboratory

Marionnet è un laboratorio di reti virtuali che permette agli utenti di definire e far girare delle reti di computer, anche complesse, senza bisogno di cablaggio fisico o hardware specifico. Basta una sola macchina GNU/Linux (volendo anche senza rete), per simulare un’intera rete TCP/IP su Ethernet completa di computer, router, hub, switch, cavi, e altro ancora. È inoltre possibile collegare la rete virtuale alla rete fisica della macchina host.

Marionnet è stato sviluppato come un progetto di e-learning col contributo dell’Università Parigi 13 e l’Istituto Universitario per la Tecnologia di Villetaneuse.

Marionnet è già utilizzato con successo per l’insegnamento delle reti e dell’amministrazione di sistema nelle strutture universitarie citate sopra, e da altre in tutto il mondo. L’interfaccia Gtk amichevole e internazionalizzata rende Marionnet adatto a studenti inesperti, ma l’applicazione è utile anche agli amministratori di rete per testare delle reti complesse.

Marionnet e’ il perfetto punto di contatto tra i libri di networking e gli apparati del mondo reale.

La virtualizzazione degli apparati di rete e’ resa possibile da VDE (Virtual Distributed Ethernet), mentre gli host virtuali funzionano grazie a UML (User Mode Linux).

Il motore di Marionnet è un’applicazione OCaml fortemente concorrente, che utilizza CamlP4 e bindings C, scritta in uno stile sperimentale che dovrebbe convergere lentamente verso la programmazione funzionale reattiva in OCaml.

Installare Marionnet

Nulla di piu’ semplice soprattutto sulle versioni recenti di Ubuntu :

sudo apt-get install marionnet

Data la complessita’ del progetto e la ottima community che lo supporta vi rimando per tutte le info relative alle mille configurazioni possibili al sito del produttore partendo dala pagine del WIKI .

GreenSQL il FW per i DB

greensql-architecture
GreenSQL: un reverse proxy contro gli attacchi SQL injection

GreenSQL è un’interessante applicazione che promette di proteggere un database da eventuali attacchi dannosi. Sostanzialmente si tratta di un firewall open source che fa da filtro tra l’applicazione web e il database. Funziona come un proxy, l’applicazione invece di connettersi al database si connette a GreenSQL che poi gestisce la connessione con il database vero e proprio.

Attacchi SQL injection

Un attacco di tipo SQL injection consiste nell’inserimento “injection” di una particolare query SQL nei dati passati in input ad una applicazione da parte di un client allo scopo di provocare l’esecuzione di comandi SQL predefiniti.
Un exploit di tipo SQL injection se coronato da successo può rivelare dati sensibili da un database, modificarli, eseguire operazioni amministrative sul database (come uno shutdown od un backup), e talvolta anche impartire comandi al sistema operativo sottostante.

GreenSQL è un database firewall Open Source utilizzabile per proteggere le basi di dati da attacchi di tipo SQL injection, operando come un proxy per comandi SQL,e con integrato il supporto per Mysql.

La sua logica operativa si basa sulla valutazione dei comandi SQL, sia utilizzando una matrice di indici di rischio, sia bloccando comandi amministrativi del db (DROP, CREATE, etc).

GreenSQL opera come un reverse proxy per le connessioni Mysql. Vale a dire che invece del server Mysql, le applicazioni si connettono al server GreenSQL, che analizzerà le queries SQL e le inoltrerà al server Mysql di back-end.

Sostanzialmente funziona così: se la query mandata dall’applicazione è ritenuta rischiosa da parte di GreeSQL essa non viene mandata al DB e GreenSQL restituisce all’applicazione un risultato nullo. Alternativamente, se la query non presenta problemi, viene inviata al server e la rispostata arriva poi alla web application.

Per default GreenSQL lavora sulla porta 3305 girando tutte le richieste al server Mysql sulla porta

http://127.0.0.1:3306

Si puo’ configurare in modalita’ differenti quali :

  • Simulation Mode (database IDS): Non effettua nessuna operazione ma permette l’analisi del comportamento di GreenSQL.
  • Blocking Suspicious Commands (database IPS): In questa modalita’ effettua un analisi euristica per cercare query giudicate “illegali” e le blocca automaticamente. In questa modalita’ si richia di bloccare falsi positivi e far eseguire query che risultano essere falsi negativi.
  • Learning mode: si usa per evitare i problemi del Blocking Suspicious mode. Permette di visionare l’analisi della query e “informare” di volta in volta il software se bloccare o no questo tipo di operazioni.
  • Active protection from unknown queries (db firewall): dopo un certo periodo di “apprendimento” nella modalita’ learning mode il sistema puo’ passare alla fase successiva (bene, ho imparato tutto, ora sono pronto ad operare da solo!).

Passiamo ora all’installazione:

Si scarichi l’ultima versione del software dalla url del sito http://www.greensql.net in particolare la “GreenSQL Firewall”
riferito alla vostra piattaforma ed una volta installato il pacchetto inerente alla vostra piattaforma.

Dopo l’installazione il server greensql girera’ sulla porta 3305. provate ad accedervi con il comando:

mysql -h 127.0.0.1 -P 3305 -u root -p

Dopo aver digitato la password di root dovreste andare sul prompt di mysql (quit per uscire).

Ora il sistema e’ pronto per essere utilizzato. Non dovete far altro che avere l’accortezza di modificare i vostri script di configurazione chiedendo di connettersi sulla porta 3305 piuttosto che la 3306.

Se ad esempio il vostro CMS e’ gia’ impostato per effettuare la connessione sulla porta di default allora editate il configuration.php (o relativo file) nella sezione specifica. Ad esempio se trovate qualcosa del tipo:

$link = mysql_connect('localhost', 'mysql_user', 'mysql_password');

sostituitela con

$link = mysql_connect('localhost:3305', 'mysql_user', 'mysql_password');

Installiamo ora la greensql-console che permette di gestire, manutenere ed impostare tutte le caratteristiche di GreenSQL.

Scaricate sempre dal link per i download scaricate la “Management Console” relativa alla vostra piattaforma :

tar xvfz greensql-console-<VERSIONE> -C /opt/

cd /opt/greensql-console

vim config.php

Editate i campi:

$db_name = "greendb";

$db_user = "green";

$db_pass = "greensqlpassword";

Accertatevi di aver impostato i permessi della cartella template_c a 777:

# chmod 777 templates_c

Ora potete accedere via web alla management Console dalla URL:

http://<vostro_indirizzo_ip>/greensql-console

Da qui potete verificare tutte le operazioni che effettua il GreenSQL con le varie possibilita’ di operare.

Infine per fermare e riavviare il servizio potete eseguire i comandi:

/etc/init.d/greensql-fw stop

/etc/init.d/greensql-fw start

Buon divertimento !

Catturare il traffico di rete

redirectRedirect fai da te

Molte volte vi capitera’ (ed a me e’ capitato piu’ volte) di aver bisogno di gestire il traffico di rete ottimizzandolo, filtrandolo e redirezionandolo.
Si pensi, ad esempio, ai test di sviluppo effettuati sulle molte VM in cui si deve tenere conto della quantita’ di Server interessati e del carico di rete da gestire bilanciando quest’ultimo e gestendo le porte interessate.

In questo articolo illustrero’ alcuni dei migliori tra quelli da me usati in ambito OpenSource sono, Rinetd, LVS e Pound, ma l’elenco potrebbe ancora allungarsi, magari per un seguito.

PARTIAMO

rinetd

E’ il piu’ semplice dei tre, dunque partiremo da questo; esso permette di ridirigere una destinazione TCP, definita attraverso una coppia <indirizzo-ip>:<numero-di-porta>, presso un’altra coppia di questi valori. Lo scopo di questo può essere semplicemente quello di dirigere una porta locale verso un’altra porta locale, oppure si può arrivare a intercettare il traffico IP che attraversa un router in modo da ridirigere alcune coppie di indirizzi e porte presso altre destinazioni.

Tutto è composto semplicemente da un daemon, rinetd, che si avvale di un file di configurazione, /etc/rinetd.conf, nel quale si indicano semplicemente le ridirezioni da applicare.

La presenza in funzione di rinetd è incompatibile con altri daemon che stanno in ascolto delle stesse porte che devono essere ridirette, anche se queste sono intese appartenere a host differenti.

Il programma rinetd è il demone che si occupa di ridirigere il traffico TCP in base a quanto contenuto nel file di configurazione /etc/rinetd.conf
E' sufficiente avviarlo e, se il file di configurazione risultera'corretto, iniziare subito a lavorarci. All'avvio, dopo aver letto la configurazione, rinetd deve poter stare in ascolto dell'indirizzo da ridirigere e della porta relativa; qualunque sia l'indirizzo in questione, è necessario che non ci sia già un programma locale che fa la stessa cosa su quella stessa porta; per esempio, non si può tentare di ridirigere il servizio HTTP di un indirizzo qualunque, se questo è presente localmente.

Un esempio di configurazione del file rinetd.conf dovrebbe essere sufficiente a chiarire le idee su questo file. Supponiamo di voler dirottare il traffico diretto verso l’indirizzo IP 10.11.12.13 alla porta 80, in modo che questo vada verso l’indirizzo IP 192.168.1.7, alla porta 80.

120.121.122.123 80 192.168.1.7 80

L’indirizzo da ridirigere, può appartenere a un’interfaccia del nodo presso cui si trova in funzione il demone rinetd,
oppure no, purché i pacchetti diretti a tale indirizzo transitino attraverso il nodo che attua la ridirezione.
Se si vuole apprendere il funzionamento di rinetd senza disporre di una rete vera e propria, basta una direttiva di configurazione simile a quella seguente:

localhost 8888 localhost html

In questo modo, la porta locale 8888 viene ridiretta sulla porta del servizio HTTP (80). Se il servizio HTTP è attivo, si può verificare la ridirezione con un programma di navigazione qualunque, puntando all’URL

http://localhost:8888

Rispetto ai prossimi due tool rinetd non e’ in grado di fungere anche come LoadBalancer.

ipvsadm

Questo servizio aggiorna la tabella d’instradamento IPVS nel kernel. Il demone lvs imposta e gestisce Load Balancer Add-On richiamando ipvsadm per aggiungere, modificare e cancellare le voci all’interno della tabella d’instradamento IPVS. Inoltre ipvsadm fa parte del paccheto LVS  che è una soluzione di bilanciamento del carico avanzato per sistemi Linux.
Si tratta di un progetto open source avviato da Wensong Zhang nel lontano 1998. La missione del progetto è di costruire un server ad alte prestazioni e ad alta disponibilità per Linux utilizzando tecnologie di clustering, offrendo una buona scalabilità, affidabilità e facilità di manutenzione. L’opera principale del progetto LVS è ora quello di sviluppare un software avanzato di bilanciamento del carico IP (IPVS), ed un software di bilanciamento a livello dell’applicazione (KTCPVS), ed i componenti di gestione dei cluster.

Ipvs in pratica

IPVS (IP Virtual Server) implementa un bilanciatore di carico a livello Layer 4 della rete. IPVS in esecuzione su un host si comporta come un sistema di bilanciamento del carico di fronte ad un insieme di server reali in cluster, può indirizzare le richieste per servizi basati si TCP/UDP ai veri server, e fa apparire i servizi dei server reali come un unico servizio virtuale su un unico indirizzo IP.

La componente IPVS è presente in tutti i recenti Kernel, per installare la componente in user-space utilizzate il vostro gestore di pacchetti, ad esempio in Ubuntu:

aptitude install ipvsadm

a questo punto si può creare uno script da far avviare al boot. Io di solito inserisco i comandi all’interno del file
/etc/rc.local.

Prima di tutto dobbiamo resettare l’attuale configurazione con il comando:
ipvsadm -C
Dopodiché iniziamo a dare le regole con i comandi come nell’esempio qui sotto in cui diciamo che le chiamate TCP (parametro -t) all’indirizzo 192.168.10.100 sulla porta 5060 (quella per il protocollo SIP) debbano essere inoltrate alla stessa porta dell’indirizzo 192.168.10.250.  Per reindirizzare una chiamata UDP sostituire il -t con -u.
ipvsadm -A -t 192.168.10.100:5060 -s rr

ipvsadm -a -t 192.168.10.100:5060 -r 192.168.10.250:5060 -m

Naturalmente è possibile catturare il traffico su una porta e inoltrarla ad un’altra con un comando tipo questo:
ipvsadm -A -t 192.168.10.100:88 -s rr
ipvsadm -a -t 192.168.10.100:88 -r 192.168.10.250:80 -m
In questo caso non abbiamo fatto altro che prendere le chiamate alla porta 88 dell’indirizzo 192.168.10.100 e rinviarle al server web dell’IP 192.168.10.250 sulla normale porta 80

Metodi di bilanciamento utilizzati da LVS

In caso si desideri testare il funzionamento di LVS senza la necessita’ di monitorare i servizi e possibile aggiungere e rimuovere nodi con il comando ipvsadm:

ipvsadm -C
ipvsadm -A -t 10.2.1.164:8080 -s lc
ipvsadm -a -t 10.2.1.164:8080 -r 10.2.1.166 -g
ipvsadm -a -t 10.2.1.164:8080 -r 10.2.1.165 -g

Le opzioni utilizzate nelle linee di comando di ipvsadm per l’esempio riportato sono le seguenti:

– -C, –clear: cancella la tabella del virtual server.
– -A, –add-service: crea un servizio virtuale.
– -a, –add-server: aggiunge un nodo ad un servizio virtuale.
– -t, –tcp-service: specifica indirizzo ip e numero di porta tcp del servizio virtuale.
– -s, –scheduler: specifica l’algoritmo di bilanciamento
– -r, –real-server: specifica l’indirizzo ip del nodo reale
– -g, –gatewaying: indica il metodo di forwarding direct routing (LVS-DR)

** algoritmi per il bilanciamento che possiamo usare con LVS.

Statici:

– Round Robin

– Weighted Round Robin

– Destination Hashing

– Source Hashing

Dinamici:

– Least-Connection

– Weighted least-connection

– Never queue

– Locality-based least-connection

– Locality-based least-connection with replication scheduling

– Shortest expected delay

pound

Pound è un proxy server di bilanciamento del carico inverso. Accetta richieste da HTTP / HTTPS clienti e li distribuisce a uno o più server web. Le richieste HTTPS vengono decifrati e passati al back-end come semplice protocollo HTTP.

Se più di un server back-end è definita, Pound sceglie uno di loro a caso, sulla base delle priorità definite. Per impostazione predefinita, Pound tiene traccia di associazioni tra client e server back-end (sessioni).

General Principles

In generale, Pound ha bisogno di tre tipi di oggetti definiti, al fine di funzione: ascoltatori , i servizi e back-end .

Ascoltatori
Un ascoltatore è una definizione di come Pound riceve le richieste dai client (browser). Due tipi di ascoltatori può essere definito: normale connessione HTTP ascoltatori e HTTPS (HTTP su SSL / TLS) ascoltatori . Per lo meno un ascoltatore deve definire l’indirizzo e la porta per l’ascolto su, con ulteriori requisiti per HTTPS ascoltatori .

Servizi
Un servizio è la definizione di come le domande trovano risposta. Il servizio può essere definito all’interno di un ascoltatore o al livello superiore (globale). Quando viene ricevuta una richiesta Pound tenta di far corrispondere a ciascun servizio , a sua volta, a partire dai servizi definiti nel ascoltatore stesso e, se necessario, di proseguire con l’ servizi definiti a livello globale. I servizi possono definire le proprie condizioni al quale le domande si può rispondere: in genere si tratta certo URL (solo foto, o un certo percorso) o intestazioni specifiche (come ad esempio l’intestazione Host). Un servizio può anche definire una sessione meccanismo: se definito le richieste future da un determinato cliente sarà sempre la stessa risposta da parte di back-end .

Back-end
Il back-end sono i server reale per il contenuto richiesto. Di per sé, Pound fornisce nessuna risposta – tutti i contenuti devono essere ricevuti da un vero e proprio “web server”. Il back-end definisce come il server dovrebbe essere contattato.

Tre tipi di back-end può essere definito: un “regolare” back-end che riceve le richieste e le risposte restituisce, un “redirect” back-end in questo caso, Pound risponde con una risposta redirect, senza l’accesso a qualsiasi back-end a tutti , o una “emergenza” back-end che sarà usato solo se tutti gli altri backend sono “morti”.

Multiple back-end può essere definito all’interno di un servizio , nel qual caso Pound sarà bilanciamento del carico tra i disponibili back-end .

Se un back-end non riesce a rispondere, sarà considerato “morto”, nel qual caso Pound si ferma l’invio di richieste ad esso. Dead indietro _ e NDS sono periodicamente controllate per la disponibilità, e una volta che rispondono ancora sono “resurected” e le richieste sono inviati di nuovo la loro strada. Se non back-end sono disponibili (nessuno è stato definito, o sono tutti “morti”), allora Pound risponderà con “503 Servizio non disponibile”, senza verificare ulteriori servizi .

Il collegamento tra Pound e il back end- è sempre via HTTP, a prescindere dal protocollo utilizzato tra Pound e il cliente.

Installazione 

sudo apt-get install pound

La gestione completa del servizio avviene tramite la configurazione del file /etc/pound/pound.cfg
Esempio 1:

Semplice configurazione HTTP Proxy
Supponiamo di forwardare le richieste http che arrivano dall”IP pubblico 202.54.10.5 all’IP sulla LAN 192.168.1.5 su cui è configurato un web server Apache sulla porta 8080.
Editiamo il file di configurazione di pound di una distro Debian/Ubuntu:

vim /etc/pound/pound.cfg

Questo è l’aspetto del file:

ListenHTTP
Address  202.54.10.5
Port          80
Service
BackEnd
Address  192.168.1.5
Port           8080
End
End
End

Salvare e chiudere il file e restartare Pound:

/etc/init.d/pound restart

Esempio 2
Semplice configurazione HTTP & HTTPS Proxy
In questo esempio vediamo come “proxare” una richiesta http e https dallo stesso IP pubblico 202.54.10.5 a due web server 192.168.1.5 e 192.168.1.6, entrambi sulla porta 80:

ListenHTTP
Address  202.54.10.5
Port          80
End

ListenHTTPs
Address   202.54.10.5
Port           443
Cert           “/etc/ssl/local.server.pem” -–>percorso certificato ssl
End

Service
BackEnd
Address     192.168.1.5
Port              80
Priority       1
Backend
Address     192.168.1.6
Port              80
Priority       3
End
End

Salviamo il file di configurazione e restartiamo pound.

In questo esempio le richieste alla porta 80 all’ ip 202.54.10.5  vengono inoltrate alla porta 80 del webserver 192.168.1.5, mentre le richieste alla porta 443 dall’ ip 202.54.10.5 vengono inoltrate alla porta 80 del web server 192.168.1.6  e in questo caso pound gestisce il certificato ssl, che è possibile generarsi senza alcuna modifica nel backend del web server, che continua a gestire chiamate in http.

PS: e’ possibile inoltre impostare una priorità di inoltro del traffico differente, nel caso si disponga di più server web, cosi’ come indicato dalla voce “Priority” presente nella configurazione del secondo esempio; minore è la cifra, maggiore sarà la priorità assegnata al server.

Buon divertimento !

Grafici di rete con Vnstat

vnstat-php-frontend-screenshots

Controllare la banda

Sui server, come sui PC, è utile monitorare e raccogliere dati circa l’utilizzo della banda di rete. E’ possibile utilizzare vnstat per avere un monitoraggio in tempo reale della banda; questo piccolo programma ha qualcosa in più degli altri, oltre a mostrare statistiche in tempo reale, la caratteristica in cui brilla questo piccolo programma è la sua capacità di raccogliere dati su un lungo periodo di tempo. vnstat è un monitor di traffico di rete basata su console per Linux e BSD che mantiene un log del traffico di rete per l’interfaccia/e che gli indicherete nel file di conf. Utilizza le statistiche dell’interfaccia di rete fornite dal kernel come fonte di informazioni, ciò significa che vnstat non sta effettivamente sniffando il traffico, inoltre assicura anche un basso impatto sull’uso delle risorse di sistema.

In Linux, è richiesto almeno un kernel della serie 2.2, che vuol dire che tutti oggigiorno sono in grado di utilizzare questo piccolo programma.

Il programma è open source/GPL e può essere utilizzato sia come root che come utente non privilegiato.

INSTALLAZIONE

sudo apt-get install vnstat
                     vnstati
                     apache2
                     php5
                     php5-gd

Primo setup

Durante la prima esecuzione è necessario inizializzare ogni interfaccia che desiderate registrare su vnstat. Ad esempio per una interfaccia cablata con cavo di rete è necessario utilizzare il comando:

# vnstat -u -i eth0

o per una interfaccia wireless:

# vnstat -u -i wlan0

Quando si inizializza una interfaccia per la prima volta ci potrà essere un messaggio di errore che stamperà ‘unable to read database’. Se questo messaggio è seguito da un messaggio di informazioni che dice ‘a new database has been created’ l’interfaccia è stata aggiunta con successo.
Se questo non accade verificare che l’interfaccia specificata sia valida.

Per vedere tutte le interfacce del vostro sistema Linux, è possibile utilizzare il comando

 ip link show
 
 ... ora scarichiamo il pacchetto vnstat_php_frontend nel seguente modo :
# cd /tmp
# wget http://www.sqweek.com/sqweek/files/vnstat_php_frontend-1.5.1.tar.gz
scompattiamolo nel percorso dei file di Apache ( /var/www/html )
# sudo tar zxvf vnstat_php_frontend-1.5.1.tar.gz -C /var/www/html/

a questo punto non rimane altro che spostarci nel percorso sopra indicato in cui potremo trovare la nuova directory
# cd /var/www/html
** rinominiamo x maggiore comodita’ da “vnstat_php_frontend-1.5.1” a semplicemente vnstat
# sudo mv vnstat_php_frontend-1.5.1 vnstat

…. spostiamoci all’interno della Directory vnstat ed andiamo a fare alcune veloci modifiche che ci permetteranno di diventare subito operativi.

# cd vnstat
…effettuiamo come consuetudine un backup del file config.php prima di fare qualunque modifica
# cp config.php config.php.bck

ora possiamo passare ad editare il file in questione e ad apportare le seguenti modifiche :
# vim config.php

*** modifichiamo nel seguente modo
$locale = 'en_US.UTF-8';
$language = 'en';
$iface_list = array('eth0', 'eth1'); # nel mio caso ho modificato le interfacce con la mia wlan0 


$iface_title['wlan0'] = 'Internal';
// $iface_title['eth1'] = 'External'; # se non avete due o piu' interfacce da monitorare potete commentarla

…salvate ed uscite dal file; a questo punto bastera’ puntare il browser all’URL

http://localhost/vnstat/

 

da qui in avanti potrete tenere sotto controllo i consumi della/e vostra interfaccia di rete (ora,giorno,mese).