INVIO DEI FILE ULOG SU WEB SERVER REMOTO DA PARTE DI UN HOT-SPOT LINKSYS WRT54GL BASATO SU CoovaAP

Legge sulla privacy, obbligo di conservare i log di accesso, tanti hot-spot sulla rete basati su CoovaAP. Come catturo e conservo i log di accesso che ogni hot-spot genera? Semplice: mando tutto ad un server remoto via web.

Scenario: Ho tanti hot-spot che sono dei Linksys WRT54GL. Sopra c’è installato CoovaAP Firmware (version 1.0 beta.12 – based on WHITE RUSSIAN (0.9+)). Il server web (che magari fa anche da server RADIUS e usa daloradius per la gestione) è una macchina linux con Apache2 e un pò di spazio libero su disco (i log li metto lì).

Come funziona?

Nel router wifi il servizio ulogd (se installato e opportunamente configurato) raccoglie il traffico generato dagli utenti wifi e lo scrive nel file ulogd.syslogemu nella directory /tmp/log (o /var/log visto che la directory /var è un link simbolico a /tmp).

Il servizio che viene avviato al boot sendulogfile, invoca l’eseguibile sh /jffs/usr/bin/sendlog.sh

Tale file controlla periodicamente il file ulogd.syslogemu e se lo trova maggiore di 100K oppure maggiore di 1 bytes e più vecchio di pochi minuti, allora prende tale file e lo invia tramite curl usando il metodo POST al web server e poi resetta il file.

Lo script PHP che gira sul server web remoto, legge le 2 variabili POST HS_ID (identificativo dell’hot-spot) e HS_Event (contiene il file di log inviato dall’hot-spot).

Lo script PHP aggiunge il contenuto di HS_EVent in un file compresso nominato $DATE_$HS_ID_Traffic.gz, quindi per ogni hot-spot esiste un file al giorno.

Da un test fatto per 5 giorni con 3 HS che simulavano un accesso WEB ad un sito ogni secondo e una PING sempre ogni secondo è stato generato un insieme di file con dimensione compressa pari a 3MB equivalenti a 40MB non compressi.

Continua a leggere

Una soluzione wifi per l’accesso ad internet gratuito della città di Jesi

Recentemente Fastnet, in collaborazione con Tecnomatic, ha vinto una gara pubblica con cui l’amministrazione di Jesi, una cittadina marchigiana di 40000 abitanti, voleva offrire un accesso wifi gratuito nel centro storico della città e nella biblioteca pubblica.

La soluzione è già operativa dal 3 giugno.

Le modalità di accesso per l’utente sono assai semplici:

  • raggiunge il Centro Storico di Jesi
  • si collega alla rete Jesi Wi-FI e accede alla pagina login
  • invia un SMS con “JESI” al numero di cellulare indicato
  • effettua il login con la sua password che riceverà via SMS

Il servizio, completamente gratuito, consentirà una connessione della durata massima di 2 ore, con la possibilità di scaricare contenuti per circa 50 MB.

Tra le specifiche della gara si richiedeva quindi di consentire, nel rispetto della legge Pisanu, il rilascio delle credenziali di accesso alla rete tramite l’utilizzo di un sms inviato dal cellulare dell’utente che intendeva accedere alla rete stessa.

Nella gara si chiedeva anche l’accesso ad una serie di report sul numero di nuovi utenti, utenti attivi, utenti on line e relativo traffico svilupato.

Dopo qualche ora spesa su Google a studiare la situazione ho fatto la seguente lista della spesa:

  • Sistema di autenticazione basata su Radius
  • Scelta dell’implemnetazione RADIUS open source: freeradius
  • Storage dei dati freeradius su mysql
  • Gestione di un modem gsm per la ricezione/invio di messaggi sms tramite gnokii
  • Scrittura in perl di un daemon per le gestione delle richieste via sms e generazione dei profili utenti sul backend mysql
  • Gestione delll’interfaccia di amministrazione di freeradius tramite DaloRADIUS

Gestione degli huntgroups

Una specifica della gara richiedeva che se l’utente si connetteva dalle vie del centro storico avesse dei limiti di tempo e di traffico diversi che se si fosse connesso dalla biblioteca.

Per far sì che, a seconda del nas a cui l’utente accede, la sessione wifi abbia caratteristiche diverse è stata utilizzata la funzionalità degli huntgroups presente in freeradius. Si veda questo link .

Tale funzionalità non è però gestita nell’interfaccia standard di daloradius per cui si è reso necessario un intervento sia a livello di database che a livello di applicazione web.

Tali modifiche le ho passate a Liran Tal autore di DaloRADIUS che le ha inserite nella versione standard.

Con Liran, che lavora e vive in Israele, è iniziata una collaborazione a distanza per lo sviluppo di daloradius: per il momento sto collaborando con lui alla revisione del sistema di Billing presente su daloradius.

Una patch per gestire counter di tipo data

E’ stato definito nel dictionary del freeradius un nuovo attributo Max-Daily-Traffic che tramite l’opportuna query definita in counter.conf consente di impostare il massimo limite di traffico giornaliero per un utente/gruppo.

Attributo per il Max-Daily-Traffic

sqlcounter dailytraffic {
counter-name = Daily-Traffic
check-name = Max-Daily-Traffic
reply-name = Mikrotik-Xmit-Limit
sqlmod-inst = sql
key = User-Name
reset = daily
counter-type = data
query = "SELECT (sum(AcctInputOctets)+sum(AcctOutputOctets)) FROM radacct
 \WHERE UserName='%{%k}' AND \
UNIX_TIMESTAMP(acctstarttime) + acctsessiontime > '%b'"}

Poiché il modulo rlm_sqlcounter prevede solo la gestione di contatori legati al tempo, se si attiva la gestione di counter legati al traffico, in concomitanza di una scadenza temporale, il counter legato ai dati restituisce valori non veritieri. Questa patch permette di distinguere il tipo di counter per cui nel file counter.sql va aggiunta la riga seguente per i counter che lavorano sul tempo.

Per chi fosse interessato può contattarmi a filippo.delprete[_-at-_]gmail.com