Hotspot Ubuntu Dapper Server HOWTO
Da Faber Libertatis.
Questo breve HowTo discute una possibile configurazione di un server AAA/Radius, appoggiato ad un database MySQL e la predisposizione della stessa macchina a svolgere il ruolo di NAS, quindi di controllare il traffico degli utenti Wireless e non solo.
Indice della pagina |
Obiettivi
Il software che verrà utilizzato nell'installazione è tutto rilasciato con licenza Free Software/OpenSource e facilmente reperibile in Internet. Dopo aver fornito in un precedente HowTo una linea di condotta per la creazione di un hotspot con Debian Sarge, ci dedicheremo qui a fornire le indicazioni necessarie all'installazione su di un Ubuntu Server versione Dapper Drake 6.06 LTS. Le richieste in tema di prestazione dell'hardware sono superiori a quelle richieste per una installazione basata su Debian Sarge dato anche il diverso Kernel, il più recente 2.6, il quale però permette una maggiore compatibilità con dispositivi di recente rilascio. Segue la lista dei software utilizzati con indicazione del sito web del progetto e della licenza:
- Apache HTTP Server http://httpd.apache.org/ Apache License
- ChilliSpot http://www.chillispot.org/ GNU GPL2
- FreeRadius e Dialup Admin http://www.freeradius.org/ GNU GPL2
- MySQL http://www.mysql.com/ GNU GPL2
- PHP4 http://www.php.net/ PHP License 3.0
Vediamo in brevi termini cosa ci prefiggiamo faccia il sistema che andremo ad implementare. Un utente dotato di una credenziale di accesso fornita dagli operatori che gestiscono l'hotspot si reca nell'area coperta dalla rete wireless. Effettua uno scanning della rete con il suo portatile dotato di interfaccia wireless e trova la rete non criptata HOTSPOT, si connette a questa ed il PC configura l'interfaccia di rete wireless con i parametri forniti dal DHCP, apre quindi il suo browser, appena tenterà di collegarsi ad un sito in internet (tranne i pochi di accesso libero) gli verrà chiesto di autentificarsi. Una volta autentificato il sistema registrerà la sua connessione e si potrà monitorare la sua connessione attraverso l'indirizzo IP assegnato. Per una maggiore grado di controllo si può implementare un transparent proxy che registi l'associazione tra l'IP address ed il traffico effettuato dall'utente.
Prerequisiti
Tutto ciò che viene riportato in questo HowTo ha funzionato nell'installazione di test e non è detto che debba necessariamente confomarsi a quelle che sono le esigenze di chi legge. Al fine di non incorrere in spiacevoli inconvenienti è necessario avere un'idea precisa di quanto si fa ed è necessario avere ben chiaro cosa comporta ogni singolo comando e configurazione. Conoscenze necessarie e sufficienti possono essere date da una media dimestichezza con i comandi da shell di un sistema GNU/Linux, il firewall NetFilter/IpTables e la configurazione dei servizi di una rete di piccole proporzioni.
I prerequisiti per l'installazione sono modesti e possono essere così esemplificati:
- Un computer con due interfacce di rete (il SERVER), nel nostro caso la configurazione adottata è PC PIII 1GHz + RAM 128 MByte + HD 10 GByte + 2 NIC Realtek 8139;
- un access-point wireless, non strettamente necessario se si vuole collegare computer cablati;
- un computer (il CLIENT) ulteriore necessario per i test, dotato di un interfaccia di rete ethernet o wireless e di un browser che supporti i Pop-Up.
In questo scheda vediamo "graficamente" come si prevede interagiscano i computer
________
| | access-point
| CLIENT | )))) ((( \|/ ________ Internet
|________| | | | |
+------| SERVER |------+
rete 192.168.2.0/24 eth1 |________| eth0
Si procede dunque all'installazione base di Ubuntu Server Dapper Drake 6.06 con kernel 2.6.15, di seguito un esempio di partizionamento del disco:
- 200 MByte di partizione primaria, file system ext3, montata su /boot (/dev/hda1);
- il resto del disco ospita una partizione estesa contenente un unica partizione logica configurata come LVM (/dev/hda2) tale da occupare tutto lo spazio sul disco;
- volume group vg00 a cui sia assegnato il volume fisico /dev/hda2
- volume logico lv00swap in vg00 di 256 MByte, file system swap (/dev/vg00/lv00swap)
- volume logico lv00root in vg00 di 9 GByte (il restante spazio), file system ext3 / (/dev/vg00/lv00root)
Si consiglia di procedere sin da subito all'attivazione dei repository Universe e Multiverse in APT. Modificare dunque il file /etc/apt/sources.list per vedervi le seguenti dichiarazioni:
deb http://archive.it.ubuntu.com/ubuntu dapper main restricted universe multiverse deb http://archive.it.ubuntu.com/ubuntu dapper-updates main restricted universe multiverse deb http://security.ubuntu.com/ubuntu dapper-security main restricted universe multiverse
E' da valutare se sostituire anche la repository Security con un mirror per migliorare la velocita' (per l'Italia si puo' sostituire l'indirizzo con http://ubuntu.fastbull.org/).
Effettuare dunque l'update e l'upgrade del nostro sistema:
$ sudo apt-get update $ sudo apt-get dist-upgrade
La rete
Modificare il file di configurazione delle interfacce di rete /etc/network/interfaces, il quale deve arrivare ad avere un aspetto simile al seguente:
auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp auto eth1 #iface eth1 inet dhcp
L'interfaccia eth0 è collegata al router/gateway verso Internet, va quindi impostata o in DHCP (se il router o un altro PC svolge questo servizio) oppure impostando staticamente i parametri di rete. L'eth1 si trova collegata con la rete wireless/wired a cui imporre l'autenticazione. L'interfaccia va attivata ma non deve essere impostata ad un indirizzo IP che possa venire impegnato da uno dei dispositivi o host di questa rete. Quindi o ci si limita ad attivare l'interfaccia con la direttiva auto oppure si configura in DHCP, non trovando nessun servizio DHCP si attiverà senza indirizzo IP o con un indirizzo fittizio.
Attivare in /etc/sysctl.conf l'IP Forward del router integrato nel Kernel decommentando la seguente riga
net/ipv4/ip_forward=1
ed effettuando subito la modifica:
$ echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
Riavviare la configurazione di rete del SERVER
$ sudo /etc/init.d/networking restart
Aggiungere all'avvio il caricamento del modulo tun. Per farlo aggiungere una riga con scritto "tun" in /etc/modules. Caricare nel frattempo il modulo con il comando:
$ sudo modprobe tun
E' poi necessario creare uno script per la configurazione del firewall di Linux, a meno di non volere creare uno ad hoc e adattarne uno pre-esistente si può ricorrere all'utilizzo dello script esemplificativo fornito assieme al pacchetto di ChilliSpot.
In ogni caso si proceda a scaricare e installare il pacchetto chillispot:
$ wget http://www.chillispot.org/download/chillispot_1.0_i386.deb $ sudo dpkg -i chillispot_1.0_i386.deb
Se si scegle di usare lo script di ChilliSpot eseguire i seguenti comandi:
$ sudo cp /usr/share/doc/chillispot/firewall.iptables /etc/init.d/chilli.iptables $ sudo chmod a+x /etc/init.d/chilli.iptables $ sudo ln -s ../init.d/chilli.iptables /etc/rcS.d/S41chilli.iptables
Editare, controllare ed eventualmente modificare lo script nelle prime righe dove impostano le variabili INTIF e EXTIF in modo che coincidano rispettivamente con l'interfaccia interna o LAN e quella esterna o WAN:
EXTIF=eth0 INTIF=eth1
Eseguire lo script:
$ sudo /etc/init.d/chilli.iptables
Eliminare un eventuale server DHCP dato che sarà chillispot a svolgere la funzione di fornire la configurazione di rete agli host connessi alla rete LAN.
Server Radius e Database
Installare i pacchetti mysql-server freeradius freeradius-mysql freeradius-dialupadmin:
$ sudo apt-get install mysql-server freeradius freeradius-mysql freeradius-dialupadmin
Impostare la password dell'utente amministratore del database:
$ mysqladmin -u root password 'mysqladminsecret' $ mysql -u root -p mysql> CREATE DATABASE radius; mysql> quit
Creare la struttura del database ed un utente con i privilegi di accesso e modifica del database radius:
zcat /usr/share/doc/freeradius/examples/db_mysql.sql.gz | mysql -u root -p radius $ mysql -u root -p mysql> GRANT ALL PRIVILEGES ON radius.* TO 'radius'@'localhost' IDENTIFIED BY 'mysqlsecret'; mysql> FLUSH PRIVILEGES; mysql> quit
Aggiustare il file /etc/freeradius/sql.conf con i dati di connessione al database appena settati:
server = "localhost" login = "radius" password = "mysqlsecret"
La configurazione del server Radius è un affare delicato e attualmente non sono riuscito a far operare contemporaneamente una configurazione basata sul file degli utenti Radius /etc/freeradius/users e una dove l'archivio degli utenti si trovi in un database. Consiglio comunque di andare per piccoli passi e di tentare prima di configurare il server Radius con una configurazione basata su file.
Modificare il file /etc/freeradius/radiusd.conf con i seguenti valori, mantenendo le altre impostazioni ai valori dati e facendo attenzione di rispettare l'ordine dei tag:
bind_address = 127.0.0.1
proxy_requests = no
authorize {
preprocess
# auth_log
# attr_filter
chap
mschap
# digest
# IPASS
suffix
# ntdomain
eap
files
# sql
# etc_smbpasswd
# ldap
# daily
# checkval
}
authenticate {
Auth-Type PAP {
pap
}
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP {
mschap
}
# digest
# pam
# unix
# Auth-Type LDAP {
# ldap
# }
eap
}
preacct {
preprocess
acct_unique
# IPASS
suffix
# ntdomain
files
}
accounting {
detail
# daily
unix
# sql
radutmp
# sradutmp
# main_pool
# pgsql-voip
}
session {
radutmp
# sql
}
Generalmente vanno modificate solo le righe relative al parametro bind_address e a unix nella sezione authenticate (che va commentato).
Configurare l'utente di test aggiungendo la seguente riga nel file /etc/freeradius/users rispettando l'ordine delle sezioni nel file di configurazione, un buon posto per inserirla è dopo l'esempio dell'untente "John Doe":
test Auth-Type := Local, User-Password == "testsecret"
Configurare il client 127.0.0.1 nel file /etc/freeradius/clients.conf con il valore della password per le connessioni al server Radius:
client 127.0.0.1 {
secret = radiussecret
}
Far eseguire il daemon radius in foreground con il comando, premunendosi che il daemon freeradius non sia in esecuzione (per interromperne l'esecuzione digitare Ctrl+C)
$ sudo /etc/init.d/freeradius stop $ sudo freeradius -XXX -A
Testare la configurazione con il seguente comando di test:
$ sudo radtest test testsecret 127.0.0.1 0 radiussecret
Se il test è andato a buon fine possiamo cambiare la configurazione, attivando il nostro server MySQL per andare poi a caricare i dati degli utenti utilizzando l'interfaccia Web di Dialup Admin. Modifichiamo il file /etc/freeradius/radiusd.conf commentando con un cancelletto tutte le due righe contententi la keyword files e decommentando quelle con sql.
E' una buona idea testare questa nuova configurazione prima di andare avanti, stoppiamo dunque il servizio freeradius con un Ctrl-C e riavviamolo nuovamente in modalità di debug. Quindi inseriamo un utente nel database:
$ echo "INSERT INTO radcheck (UserName, Attribute, Value) VALUES ('mysqltest', 'Password', 'testsecret');" | mysql -u radius -p radius
E ritentiamo il test di prima con i nuovi valori:
$ sudo radtest mysqltest testsecret 127.0.0.1 0 radiussecret
Server Apache
Questa parte del tutoriale si occupa di installare e rendere operativo in server httpd Apache 2 con tanto di PHP4, SSL e CGI attivi, il che è sicuramente affare di tutti i giorni per chi è arrivato fino a questo punto nella lettura. Installare dunque apache2 libapache-mod-ssl libapache2-mod-php4 libdate-manip-perl e php4-mysql (libdate-manip-perl sembra sia una dipendenza non molto dichiarata di freeradius-dialupadmin):
$ sudo apt-get install apache2 libapache-mod-ssl libapache2-mod-php4 libdate-manip-perl php4-mysql
Togliere in /etc/php4/apache2/php.ini il commento alla riga seguente far caricare a PHP l'estensione a MySQL:
extension=mysql.so
Troviamo un posto adatto per script di login che intercetterà le connessioni tentate dagli utenti non autentificati, il quale necessità di esseguito come uno script CGI e di essere visitato all'interno di una connessione HTTPS:
$ sudo mkdir -p /var/www/hotspot/cgi-bin $ zcat -c /usr/share/doc/chillispot/hotspotlogin.cgi.gz | sudo tee /var/www/hotspot/cgi-bin/hotspotlogin.cgi $ sudo chmod a+x /var/www/hotspot/cgi-bin/hotspotlogin.cgi
Modificare il file /var/www/hotspot/cgi-bin/hotspotlogin.cgi inserendoci una nuova password specifica per secretare la connessione tra ChilliSpot e lo script di login:
$uamsecret = "uamsecret"; $userpassword=1;
Creare il file /etc/apache2/sites-available/hotspot, che nel nostro caso fornisce la configurazione per il sito contenente sia lo script di login che l'interfaccia Web per amministrare gli utenti. A seconda delle necessità dell'installazione specifica si può preferire distinguere questi due servizi in due virtual host disting magari perevendo una pagina di Benvenuto. Questa comunque è una configurazione di massima nel caso abbiate bisogno di ispirarvi:
NameVirtualHost 192.168.2.1:443 <VirtualHost 192.168.2.1:443> ServerAdmin webmaster@dominio.org DocumentRoot "/var/www/hotspot" ServerName "192.168.2.1" <Directory "/var/www/hotspot/"> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory> Alias "/dialupadmin/" "/usr/share/freeradius-dialupadmin/htdocs/" <Directory "/usr/share/freeradius-dialupadmin/htdocs/"> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory> ScriptAlias /cgi-bin/ /var/www/hotspot/cgi-bin/ <Directory "/var/www/hotspot/cgi-bin/"> AllowOverride None Options ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> ErrorLog /var/log/apache2/hotspot-error.log LogLevel warn CustomLog /var/log/apache2/hotspot-access.log combined ServerSignature On SSLEngine on SSLCertificateFile /etc/apache2/ssl/apache.pem </VirtualHost>
Eseguire i seguenti comandi per abilitare il nuovo sito e il modulo SSL
$ sudo a2ensite hotspot $ sudo a2enmod ssl
Eseguire il seguente comando e inserire dei valori opportuni, ponendo particolare attenzione all'hostname che deve essere risolvibile in un DNS:
$ sudo apache2-ssl-certificate
Questi sono i valori esemplificativi a cui faremo riferimento in seguito e che adeguerete alle vostre esigenze: IT, Provincia, Città, Gestore, HotspotServer, 192.168.2.1, info@dominio.org.
Modificare il file /etc/apache2/ports.conf nel seguente modo:
Listen 192.168.2.1:80 Listen 192.168.2.1:443
Ed aggiungere al file /etc/apache2/apache2.conf il parametro, ad esempio dopo il parametro ServerRoot:
ServerName 192.168.2.1
Assicurarsi comunque che entrambi l'indirizzo IP dell'interfaccia LAN (nel nostro esempio 192.168.2.1) sia associato all'hostname del server nel file /etc/hosts:
192.168.2.1 hotspot.dominio.org hotspot
Fatto questo potremmo testare la configurazione riavviando il server Apache:
$ sudo /etc/init.d/apache2 restart
e visitare con un web browser l'indirizzo del sito appeno creato https://192.168.2.1/cgi-bin/hotspotlogin.cgi (l'indirizzo http://192.168.2.1:3990/, che effettivamente effettuerà il redirect all'opportuna pagina di login una volta configurato Chilli, non e' ancora attivo).
ChilliSpot
Diamo le informazioni che necessita a ChilliSpot configurando il file /etc/chilli.conf in modo opportuno:
net 192.168.2.0/24 dns1 ns1.dominio.org dns2 ns2.dominio.org domain dominio.org radiusserver1 127.0.0.1 radiusserver2 127.0.0.1 radiussecret radiussecret radiuslocationid isocc=it,cc=39,ac=41,network=HOTSPOT radiuslocationname GESTORE,IoSonoQui dhcpif1 eth1 uamserver https://192.168.2.1/cgi-bin/hotspotlogin.cgi uamsecret uamsecret uamlisten 192.168.2.1 uamallowed www.dominio1.tld,www.dominio2.tld,192.168.2.0/24
Alcune note a margine di questa ultima operazione: ChilliSpot monitorizza la rete sull'interfaccia eth1 segnalata dalla riga dhcpf1 eth1, quando un nuovo dispositivo si affaccia in rete chiede che un server DHCP gli fornisca i dati per connettersi e chilli gli risponde dandogli il primo indirizzo IP libero della rete 192.168.2.0, mentre esso rimane in ascolta con l'indirizzo 192.168.2.1 impostato con la direttiva uamlisten 192.168.2.1 che diventa anche il default gateway fornito al nuovo dispositivo di rete. Quando questo cerca di connettersi ad internet il suo traffico viene redirezionato verso l'UAM Server cioè il nostro script di login, il quale gli restituisce le informazioni su utente e password, a questo punto si collega con il server Radius all'indirizzo 127.0.01. Questo valore viene applicato sia al primo che al secondo server dato che se ne devono indicare sempre due anche se uguali. Infine radiuslocationid e radiuslocationname contengono informazioni utili alla localizzazione del punto di accesso, che poi sarebbe l'hotspot generato dal nostro access point wireless, il file di configurazione è autoesplicativo, comunque il significato è il seguente:
- isocc=it, codice ISO della nazione, in questo caso l'Italia
- cc=39, il prefisso internazionale della nazione, quello per chiamare coin il telefono, per l'italia +39
- ac=41, il prefisso locale, per esempio 041 per chiamare Venezia e provincia
- network=HOTSPOT, ESSID o la zona wireless coperta dall'access point
- radiuslocationname GESTORE,IoSonoQui, sono rispettivamente il fornitore del servizio e la localizzalizzazione precisa dell'access point
Lo uamsecret deve corrispondere a quello contenuto nello script hotpostlogin.cgi così come radiussecret deve corrispondere a quello impostato in /etc/freeradius/clients.conf nella sezione del client 127.0.0.1. Infine uamallowed permettere di indicare una lista di siti web e di reti a cui è permesse l'accesso anche senza una autenticazione. E' buona norma indicare sempre anche la rete locale dell'hotspot per evitare che il sistema blocchi l'accesso proprio alla pagina di autenticazione.
Ora possiamo testare l'utente mysqltest creato precedentemente, collegando un computer alla rete LAN, cercando di visitare un sito internet dopo essersi assicurati che l'interfaccia di rete si sia configurata in modo automatico attraverso il DHCP, e inserendo i dati di autenticazione. Se veniamo autentificati dovremmo agevolmente navigare in Internet fino a non effettuare il logout nella finestra di pop-up che si dovrebbe essere aperta o tornando a https://192.168.2.1/cgi-bin/hotspotlogin.cgi possibile anche visitando il link http://192.168.2.1:3990/.
Dialup Admin
E' giunto dunque il momento di configurare l'interfaccia Web di FreeRadius per facilitare l'inserimento degli utenti agli operatori che gestiranno l'hotspot. Prima bisogna aggiungere delle ulteriori tabelle nel nostro database, eseguiamo dunque i seguenti comandi:
$ sed "/auto_increment/ s/DEFAULT '0'//" /usr/share/freeradius-dialupadmin/sql/badusers.sql | mysql -u radius -p radius $ mysql -u radius -p radius < /usr/share/freeradius-dialupadmin/sql/mtotacct.sql $ mysql -u radius -p radius < /usr/share/freeradius-dialupadmin/sql/totacct.sql $ sed "/auto_increment/ s/DEFAULT '0'//" /usr/share/freeradius-dialupadmin/sql/userinfo.sql | mysql -u radius -p radius
Quello che siamo andati a fare nel caso del caricamento della tabella badusers e userinfo è stato eliminare parte della definizione della tabella per non incorrere in un errore rilevato dall'analizzatore sintattico della più recente versione di MySQL.
Cambiare in /etc/freeradius-dialupadmin/admin.conf le impostazioni opportune:
general_domain: dominio.org general_radius_server_secret: radiussecret general_encryption_method: clear sql_username: radius sql_password: mysqlsecret #sql_debug: true
Si noti che si è andato a commentare la riga concernente al debug dei comandi SQL, perchè se attiva visualizzerà nella schermata del browser tutte le query eseguite da Dialupadmin.
Testare dunque il servizio all'indirizzo https://192.168.2.1/dialupadmin/index.html cominciando a creare degli utenti da sottoporre poi al login ed al logout.
Dato che la pagina non chiede all'operatore di autentificarsi è una buona idea inserire una forma di autentificazione basata sul server web su cui ci appoggiamo, andando a modificare le impostazioni della directory in /etc/apache2/sites-available/hotspot:
<Directory "/usr/share/freeradius-dialupadmin/htdocs">
...
AuthName "Restricted Area"
AuthType Basic
AuthUserFile /etc/apache2/.htpasswd
require valid-user
</Directory>
Infine non ci resta che creare l'utente che possa accedere all'interfaccia di ammministrazione e riavviare Apache:
$ sudo htpasswd -bcm /etc/apache2/.htpasswd admin adminsecret $ sudo /etc/init.d/apache2 restart
Ora dovrebbe funzionare una buona parte dell'interfaccia tranne alcune schermate con informazioni statistiche. La più importante è sicuramente quella che ci informa sugli utenti in linea (Online Users), per renderla operativa è necessario modificare il file /etc/freeradius-dialupadmin/naslist.conf in modo che abbia i seguenti campi almeno, e gli altri commentati:
nas1_name: nas1.%{general_domain}
nas1_type: other
nas1_model: ChilliSpot
nas1_ip: 0.0.0.0
nas1_finger: database
Per ottenere invece l'operatività della finestra User Statistics è necessario che uno script fornito assieme al pacchetto freeradius-dialupadmin venga eseguito una volta al giorno, si tratta di /usr/share/freeradius-dialupadmin/bin/tot_stats, ma ha due difetti...
- non ha il permesso di esecuzione
- ha un errore, almeno nella versione installata con Debian
Il primo difetto si rivolve dando il solito comando:
$ sudo chmod a+x /usr/share/freeradius-dialupadmin/bin/tot_stats
Il secondo andando a controllare la correttezza della seguente riga di codice Perl:
SBAGLIATO: $sql_password = ($sql_pasword == '') ? '' : "-p$sql_password"; CORRETTO: $sql_password = ($sql_pasword eq '') ? '' : "-p$sql_password";
Stesso problema con un altro script che gestisce le statistiche mensili, si tratta di /usr/share/freeradius-dialupadmin/bin/monthly_tot_stats. Ora per rendere operativi questi script, eseguire il comando:
$ sudo cp /usr/share/doc/freeradius-dialupadmin/examples/freeradius-dialupadmin.cron /etc/cron.d/freeradius-dialupadmin
Infine se vogliamo che funzioni anche il la finestra che ci informa dei Failed Logins dobbiamo abilitare i seguenti parametri nel file di configurazione /etc/freeradius/radiusd.conf:
log_auth = yes log_auth_badpass = yes log_auth_goodpass = yes
Riavviare con la nuova configurazione il daemon Radius:
$ sudo /etc/init.d/freeradius restart
E fare eseguire il comando /usr/share/freeradius-dialupadmin/bin/log_badlogins /var/log/freeradius/radius.log ad ogni riavvio ad esempio creando un file di inizializzazione e impostandone l'avvio nel modo consueto. Creare il file /etc/init.d/freeradius.badlogins con il seguente contenuto:
#!/bin/sh /usr/share/freeradius-dialupadmin/bin/log_badlogins /var/log/freeradius/radius.log &
E metterlo in esecuzione all'avvio con i comandi:
$ sudo chmod a+x /etc/init.d/freeradius.badlogins $ sudo ln -s ../init.d/freeradius.badlogins /etc/rc2.d/S99freeradius.badlogins
E magari eseguirlo subito con i comandi:
$ sudo /usr/share/freeradius-dialupadmin/bin/log_badlogins /var/log/freeradius/radius.log /etc/freeradius-dialupadmin/admin.conf once $ sudo /etc/init.d/freeradius.badlogins
Transparent Proxy
In questo momento gli utenti del servizio di hotspot possono accedere alla rete Internet una volta autenticati. Attraverso le informazioni archiviate nel database radius possiamo identificare l'utente in base all'indirizzo IP assegnato, conoscerne il momento di accesso e quello di disconnessione, sapere quante informazioni ha inviato e quante ne ha ricevuto... non sappiamo però quali siti web ha visitato nel corso delle sue sessioni.
Per risolvere questa carenza informativa, richiesta dalla normativa vigente in materie di punti di accesso pubblico a reti telematiche, possiamo adottare la tecnologia del transparent proxy. Si tratta di attivare un proxy web che offra una cache per l'accesso al web dei client collegati, il quale sia predisposto per salvare un log sufficientemente particolareggiato contente almeno la data e l'ora dell'accesso, l'indirizzo IP del client e la pagina visitata.
Questa possibilità ci è offerta tra l'altro dal proxy Squid (http://www.squid-cache.org/), pieno di funzionalità, estremamente stabile e non di particolare difficoltà nella configurazione. Per evitare di costringere i singoli client a configurare nel proprio browser la connessione tramite proxy (con le problematiche che questo comporta in quanto a riconoscimento automatico) si è preferito addottare un sistema di transparent proxy, che effettui un caching automatico di tutto le connessioni a siti web non crittati (protocollo HTTP). Come potete immaginare questo impedisce di effettuare un controllo sulle connessioni a siti web crittati (protocollo HTTPS); comunque anche in presenza di un proxy caching tradizionale non otterremmo le informazioni sull'intero percorso del sito web (d'altro parte, la connessione è crittata apposta...) ma solo sull'indirizzo IP del server Internet a cui è diretta la richiesta. Possiamo comunque ottenere le informazioni sufficienti (la normativa richiede il solo indirizzo IP del server visitato) effettuando un log dal firewall NetFilter di Linux con una opportuna policy di iptables.
Invitando ad una attenta lettura della documentazione on-line sull'argomento riportiamo qui un breve esempio di configurazione.
Installate Squid e, consigliamo attentamente, anche l'analizzatore dei log SARG che fornirà una rappresentazione web-friendly di queste informazioni.
$ sudo apt-get install squid sarg
Modificate il file di configurazione /etc/squid/squid.conf introducendo almeno queste impostazioni:
http_port 192.168.2.1:3128 httpd_accel_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header on
Dare i seguenti comandi per redirigere le connessioni ai siti web verso la porta del proxy (di default per Squid la 3128) e modificare opportunamente il file /etc/init.d/chilli.iptables per renderli effettivi ad ogni riavvio.
$ sudo iptables -t nat -A PREROUTING -i tun0 -p tcp -s 192.168.2.0/24 --dport 80 -j REDIRECT --to 3128
E qui ora si apre un problema di cui si è molto discusso: praticamente si può accedere al web SENZA autenticarsi impostando il proxy a http://192.168.2.1:3128/... Mi hanno consigliato di effettuare un redirezione all'interfaccia di loopback (127.0.0.1) ma non sono riuscito a far funzionare il transparent proxy in questa modalità. Chiunque abbia soluzioni da proporre si faccia avanti.
Se si vuole restringere le informazioni raccolte dalle connessioni al solo indirizzo IP del server visitato possiamo usare un sistema simile a quello qui di seguito suggerito per tenere traccia delle connessioni in protocollo HTTPS (quelle crittate).
$ sudo iptables -I FORWARD 1 -i tun0 -o eth0 -s 192.168.2.0/24 -p tcp --dport 443 -m state --state NEW -j LOG --log-prefix HOTSPOT:
In seguito sarà possibile ottenere informazione della connessione di un utente controllando il Log di sistema /etc/log/syslog magari filtrando attraverso il prefisso HOTSPOT: per facilitarne la determinazione, oppure agendo sul file di configurazione del demone di logggind di sistema.
In questa fase si può anche prendere in considerazione la possibilità di adottare un sistema di content-filtering per eliminare grossi download, o impedire l'accesso a siti dai contenuti sconvenienti (violenza, pornografia, pratiche illegali). Per rispondere a queste esigenze può tornare utile adottare il programma DansGuardian facilmente disponibile pacchettizzato per Debian Sarge.
Script di backup e archiviazione dei log del traffico di rete
Come prevedibile la nostra installazione di Sarge sarà dotata di un sistema di rotazione dei log di sistema che ne limiterà l'ampliarsi effettuando una regolare, spesso giornaliera, operazione di compressione e cancellazione dei più vecchi. Alcuni log però sono vitali al fine del tracciamento delle connessioni. Stiamo parlando infatti del file /var/log/squid/access.log con tutte le connessioni rilevate dal proxy Squid oppure dei log di sistema in /var/log/syslog. Al fine di impedire la perdita di dati essenziali andremo ad agire sul sistema di rotazione dei log che è diverso per Squid e per il log di sistema.
I log di Squid sono rotati da logrotate e la configurazione per quanto concerne Squid si trova in /etc/logrotate.d/squid, andremo dunque a salvare aggiungendo nella sezione prerotate il seguente comando:
cp /var/log/squid/access.log /data/access.log-`date +%Y%m%d`
Ed il nostro log sarà conservato nella directory /data opportunamente identificato da una data aggiunta in coda all'estensione, pronto per un backup su CD con cdrecord oppure con Bacula e Amanda.
I log di sistema sono rotati dallo script in /etc/cron.daily/sysklogd, vale la pena quindi di aggiungere nello script una riga prima del comando savelog del tipo:
grep "HOTSPOT:" /var/log/syslog > /data/httpd_syslog.log-`date +%Y%m%d`
