Hotspot Ubuntu Hardy Server HOWTO

Da Faber Libertatis.

Questo breve HowTo è la versione modificata e aggiornata dello storico howto per gli hotspot.

Per questa versione è stato usato un approccio leggermente diverso (grazie a Stefano Sasso per le hint), ed è implementato anche lo strato di controllo della navigazione.


Indice della pagina

Obiettivi

La guida viene aggiornata sul nuovo sistema server Ubuntu 8.04 LTS che implementa alcune caratteristiche interessanti come il supporto per hardware più moderno, il sistema apparmor attivato di default e una buona disponibilità del software di gestione dell'hotspot aggionato.

Il software che verrà utilizzato nell'installazione è tutto rilasciato con licenza Free Software/OpenSource e facilmente reperibile in Internet. Segue la lista dei software utilizzati con indicazione del sito web del progetto e della licenza:

Vediamo in brevi termini cosa ci prefiggiamo faccia il sistema che andremo ad implementare.

1) Autenticazione

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. L'utente 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.

2) Monitoraggio della navigazione

Il sistema mantiene traccia di tutte le connessioni in uscita realizzate dai client, con orario e destinazione.

3) Protezione della connessione

La navigazione degli utenti vuole essere filtrata e controllata, evitando che vengano visualizzati considerati "sconvenienti" da parte del gestore. E' possibile decidere di applicare filtri per quel che riguarda tipi di file in download. Inoltre devono essere impedite connessioni strane, permettendo solo il traffico web,posta,ssh. I messenger (msn e skype) vengono permessi in quanto sono capaci di operare sulla porta 80.

4) Normativa

Per la normativa vigente è necessario mantenere traccia delle connessioni uscenti e degli utenti che le effettuano per un lungo periodo. Non vanno però tenute informazioni sul "cosa" visualizzano gli utenti (eventuali proxy dovranno essere no-cache)

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 Hardy 8.04 con kernel 2.6.24-xx.

Hardy server viene con i repository Universe e Multiverse già attivati, ma conviene controllare le relative righe in /etc/apt/sources.list.

La rete

Setup preliminare

Eliminare un eventuale server DHCP sull'Access Point, sul PC su cui si effettua l'installazione e sulla rete da autenticare dato che sarà ChilliSpot (o Coova-Chilli) a svolgere la funzione di fornire la configurazione di rete agli host connessi alla rete LAN.

Setup del server

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 static
    address 10.0.0.2
    netmask 255.255.255.0
    netmask 10.0.0.1

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. Si consiglia di impostarla staticamente per facilitare l'accesso al sito web di configurazione degli account utente ezRadius.

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 ci si limita ad attivare l'interfaccia con la direttiva auto.

Chillispot si occuperà di gestire la connessione tramite un'interfaccia tun, che andrà a prendere l'indirizzo del server sulla sottorete fisicamente collegata a eth1.

Attivare in /etc/sysctl.conf l'IP Forward del router integrato nel Kernel assicurandosi che sia decommentata 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

Server Radius e Database

Installare i pacchetti mysql-server freeradius e freeradius-mysql: 

$ sudo apt-get install mysql-server freeradius freeradius-mysql

Con le versioni più recenti di Ubuntu (dalla 8.10 in poi) sarà installata la versione 2 di FreeRadius, la quale prevede alcune differenze nella configurazione.

Il processo di installazione del pacchetto mysql-server richiederà automaticamente la password dell'utente amministratore del database, l'utente "root", e la sua conferma.

Se si volesse modificare la password dare il comando seguente, sostituendo "mysqladminsecret" con la password desiderata: 

$ mysqladmin -u root password 'mysqladminsecret'

Creare il database, che sarà utilizzato per la gestione del sistema di autenticazione RADIUS, con il seguente comando (rispondere al prompt "Enter password: " con la password dell'utente DB root e poi digitare al prompt "mysql> " i comandi seguenti): 

$ mysql -u root -p
Enter password: mysqladminsecret
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 non è possibile 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. Si consiglia di procedere a piccoli passi e di tentare prima di configurare il server Radius con una configurazione basata su file /etc/freeradius/users (che è quella predefinita).

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
        pap
}

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

	radutmp
#	sradutmp
#       main_pool
#       sqlippool
#	sql
#       sql_log
#	pgsql-voip
}

session {
	radutmp
#	sql
}

Generalmente vanno modificate solo le righe relative ai parametri bind_address e proxy_requests.

Configurare l'utente di test decommentando le seguenti righe bel file /etc/freeradius/users: 

"John Doe"     Cleartext-Password := "hello"
               Reply-Message = "Hello, %u"

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 ezRadius (un semplice programma per sostituire il Dialup Admin di FreeRadius). 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

ChilliSpot

Installiamo il pacchetto chillispot, che è presente nel repository. 

$ sudo apt-get install chillispot

In fase di installazione, ci saranno rivolte alcune domande per configurare chillispot. Ecco un elenco delle domande e delle risposte relative:

  • IP address of radius server 1: 127.0.0.1
  • Radius shared secret: radiussecret
  • Ethernet interface for DHCP to listen: eth1
  • URL of UAM server: https://10.1.0.1/cgi-bin/hotspotlogin.cgi
  • URL of UAM homepage:
  • Shared password between chillispot and webserver: uamsecret

Conviene comunque revisionare il file di configurazione per dare le informazioni che necessita a ChilliSpot configurando il file /etc/chilli.conf in modo opportuno: 

net 192.168.2.0/24
dns1 x.x.x.x
dns2 y.y.y.y
domain dominio.org
ipup /etc/chilli.ipup
ipdown /etc/chilli.ipdown
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
#uamhomepage
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. uamhomepage imposta invece una pagina diversa dallo script di login a cui effettuare il captive portal. Sarà poi necessario usare un link diretto verso http://192.168.2.1:3990/ per effettuare il login 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.

Modificare il file /etc/default/chillispot per abilitare l'avvio del programma chilli. Per fare questo modificare il parametro ENABLED nel modo seguente: 

ENABLED=1

Creare i due script per configurare il firewall di Linux al momento dell'attivazione dell'intefaccia tun0 di chilli. Per creare il file /etc/chilli.ipup eseguire i seguenti comandi: 

$ sudo cp /usr/share/doc/chillispot/firewall.iptables /etc/chilli.ipup
$ sudo chmod a+x /etc/chilli.ipup

Creare il file /etc/chilli.ipdown con il seguente contenuto: 

#!/bin/sh
#
# Firewall script for ChilliSpot
# A Wireless LAN Access Point Controller
#

IPTABLES="/sbin/iptables"

$IPTABLES -F INPUT
$IPTABLES -F FORWARD
$IPTABLES -F OUTPUT

$IPTABLES -P INPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT
$IPTABLES -P OUTPUT ACCEPT

$IPTABLES -t nat -F POSTROUTING

Rendere eseguibile lo script con il comando: 

$ sudo chmod a+x /etc/chilli.ipdown

Server Apache

Questa parte del tutorial si occupa di installare e rendere operativo in server httpd Apache 2 con PHP5, SSL e CGI attivi.

Installare dunque apache2, ssl-cert e php5-mysql: 

$ sudo apt-get install apache2 ssl-cert php5-mysql

Troviamo un posto adatto per script di login che intercetterà le connessioni tentate dagli utenti non autentificati, il quale necessità di essere eseguito 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 proteggere la connessione tra ChilliSpot e lo script di login: 

$uamsecret = "uamsecret";
$userpassword=1;

Creare il certificato per la modalità cifrata di connessione al sito web, con i seguenti comandi (il comando make-ssl-cert richiederà di inserire alcune informazioni sul certificata, l'unica indispensabile è il commonName, si consiglia di usare l'indirizzo IP dell'interfaccia aperta ai client dell'hotspot oppure un hostname risolvibile ed associato a quell'indirizzio IP): 

sudo mkdir /etc/apache2/ssl
sudo make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/apache.pem
sudo a2enmod ssl
sudo /etc/init.d/apache2 force-reload

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 prevedendo 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@faberlibertatis.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> 

	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 /etc/init.d/apache2 reload

Modificare il file /etc/apache2/ports.conf nel seguente modo, sostituendo gli indirizzi IP con quelli delle interfacce (la porta 443 va aperta sull'indirizzo IP da cui si collegano i client dell'hotspot): 

Listen 10.0.0.2:80
<IfModule mod_ssl.c>
    Listen 192.168.2.1:443
</IfModule>

Ed aggiungere al file /etc/apache2/apache2.conf il parametro ServerName, ad esempio dopo il parametro ServerRoot (modificare l'indirizzo IP con uno degliindirizzi): 

ServerName 10.0.0.2

Assicurarsi comunque che l'indirizzo IP indicato nel parametro ServerRoot (nel nostro esempio 10.0.0.2) sia associato all'hostname del server nel file /etc/hosts: 

192.168.2.1    hotspot.faberlibertatis.org hotspot

Fatto questo potremmo testare la configurazione riavviando il server Apache: 

$ sudo /etc/init.d/apache2 restart

Ora possiamo testare l'utente mysqltest creato precedentemente, collegando un computer alla rete LAN dei client dell'hotspot, 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/.

Nel caso non si dovesse aprire automaticamente la pagina Web di login visitare con l'indirizzo del sito appeno creato https://192.168.2.1/cgi-bin/hotspotlogin.cgi, oppure l'indirizzo http://192.168.2.1:3990/, che effettivamente effettuerà il redirect.

ezRadius

Dialup Admin è l'interfaccia di configurazione Web di FreeRadius, ma in questo How-To preferiamo presentare l'installazione di ezRadius, un'altra semplice interfaccia ispirata al più completo daloRADIUS.

Scaricare l'ultima versione stabile di ezRadius, dal sito http://sourceforge.net/projects/ezradius/: 

wget http://fastbull.dl.sourceforge.net/sourceforge/ezradius/ezradius-0.2.1.2stable.tar.gz

Scompattare l'archivio nella root directory del server Web: 

sudo tar xzvf ezradius-0.2.1.2stable.tar.gz -C /var/www

Accedere al seguente sito Web e autenticarsi con nome utente admin e password admin (sono predefiniti alla prima installazione): 

http://10.0.0.102/ezradius-intl/

Configurare l'interfaccia dal menù Tool->Config editor e inserire i segunti parametri:

  • Username: admin
  • Password: <una password per accedere a ezRadius>
  • MySQL Host: localhost
  • Database name: radius
  • MySQL Username: radius
  • MySQL Password: mysqlsecret

Creare a questo punto gli utenti con da menù Manage->Add new user, immettendo nome utente e password e abilitando la casella "Cleartext Password" (se non lo si fa non sarà possibile autenticarsi).

Per rendere accessibile l'interfaccia Web dalla rete 10.0.0.0/24 (non quella dei client dell'hotspot) sarà necessario aggiungere la seguente regola allo script /etc/chilli.ipup al di sotto di "$IPTABLES -A INPUT -i $EXTIF -p tcp -m tcp --dport 22 --syn -j ACCEPT": 

$IPTABLES -A INPUT -i $EXTIF -p tcp -m tcp --dport 80 --syn -j ACCEPT

Per renderlo subito attivo eseguire: 

sudo iptables -I INPUT 1 -i eth0 -p tcp -m tcp --dport 80 --syn -j ACCEPT

Firewalling e logging della connessione

L'idea è di usare iptables sia per fare firewalling sia per mantenere la traccia delle connessioni. Questo può essere fatto sia usando direttamente syslog che usando il demone esterno ulogd che permette di loggare in un altro luogo rispetto ai log di sistema.

Installiamo quindi ulogd 

sudo apt-get install ulogd

Riporto qui una configurazione del firewall funzionante basato sullo script di default di chillispot che può essere usata come ispirazione.

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.

Creiamo un file /etc/init.d/chilli.iptables con il nostro script e rendiamolo eseguibile all'avvio del sistema 

$ sudo chmod a+x /etc/init.d/chilli.iptables
$ sudo ln -s ../init.d/chilli.iptables /etc/rcS.d/S41chilli.iptables

Di seguito il contenuto del file /etc/init.d/chilli.iptables: 

#!/bin/sh
#
# Firewall script for ChilliSpot
# A Wireless LAN Access Point Controller
#
# Uses $EXTIF (eth0) as the external interface (Internet or intranet) and
# $INTIF (eth1) as the internal interface (access points).
#
#
# SUMMARY
# * All connections originating from chilli are allowed.
# * Only ssh is allowed in on external interface.
# * Nothing is allowed in on internal interface.
# * Forwarding is allowed to and from the external interface, but disallowed
#   to and from the internal interface.
# * NAT is enabled on the external interface.

IPTABLES="/sbin/iptables"
EXTIF="eth0"
INTIF="eth1"


#ACTION
actionLog="-j ULOG --ulog-prefix \"[firewall]\"";

#STATE
stateNew="-m state --state NEW";
stateEst="-m state --state ESTABLISHED,RELATED";
fromNet="-s 192.168.2.0/24";

#PROTOCOL
protoTCP="-p tcp -m tcp";
protoUDP="-p udp";

$IPTABLES -t nat -F
$IPTABLES -F 
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT

#security for spoofed connection
#$IPTABLES -A FORWARD $protoTCP $stateNew ! ---syn -j LOG --log-prefix "Spoofed packed detected: "
#$IPTABLES -A FORWARD $protoTCP $stateNew ! --syn -j DROP

#ssh for manteinance mode
$IPTABLES -A INPUT $protoTCP --dport 22 -j ACCEPT

#Allow related and established on all interfaces (input)
$IPTABLES -A INPUT $stateEst -j ACCEPT

#Allow releated, established and ssh on $EXTIF. Reject everything else.
$IPTABLES -A INPUT -i $EXTIF -p tcp -m tcp --dport 22 -j ACCEPT
$IPTABLES -A INPUT -i $EXTIF -j REJECT

#Allow related and established from $INTIF. Drop everything else.
$IPTABLES -A INPUT -i $INTIF -j DROP

#Allow http and https on other interfaces (input).
#This is only needed if authentication server is on same server as chilli
$IPTABLES -A INPUT -p tcp -m tcp --dport 80 $stateNew -j ACCEPT
$IPTABLES -A INPUT -p tcp -m tcp --dport 443 $stateNew -j ACCEPT

#Allow 3990 on other interfaces (input).
$IPTABLES -A INPUT -p tcp -m tcp --dport 3990 $stateNew -j ACCEPT

#Allow everything on loopback interface.
$IPTABLES -A INPUT -i lo -j ACCEPT

# Drop everything to and from $INTIF (forward)
# This means that access points can only be managed from ChilliSpot
$IPTABLES -A FORWARD -i $INTIF -j DROP
$IPTABLES -A FORWARD -o $INTIF -j DROP

#Enable NAT on output device
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE


#rules for port blocking (in according with policy DROP)
#------------------------
$IPTABLES -A FORWARD $stateEst -j ACCEPT

#dns
$IPTABLES -A FORWARD -p tcp $fromNet -d 192.168.0.0/24 --dport 53 -j ACCEPT
$IPTABLES -A FORWARD -p udp $fromNet -d 192.168.0.0/24 --dport 53 -j ACCEPT

#ssh
$IPTABLES -A FORWARD $protoTCP $fromNet -o $EXTIF --dport 22 $stateNew $actionLog
$IPTABLES -A FORWARD $protoTCP $fromNet -o $EXTIF --dport 22 -j ACCEPT


#web su squid
$IPTABLES -t nat -A PREROUTING $protoTCP --dport 80 $stateNew $actionLog
$IPTABLES -t nat -A PREROUTING $protoTCP --dport 80 -j REDIRECT --to-port 3128
$IPTABLES -A INPUT $protoTCP --dport 3128 -j ACCEPT

#web diretto con log
#$IPTABLES -t nat -A PREROUTING $protoTCP --dport 80 $stateNew $actionLog
#$IPTABLES -A FORWARD $protoTCP -o $EXTIF --dport 80 $stateNew -j ACCEPT


#web ssl con log
$IPTABLES -A FORWARD $protoTCP -o $EXTIF --dport 443 $stateNew $actionLog
$IPTABLES -A FORWARD $protoTCP -o $EXTIF --dport 443 $stateNew -j ACCEPT

#enable pop e pop ssl
$IPTABLES -A FORWARD $protoTCP -o $EXTIF --dport 110 $stateNew $actionLog
$IPTABLES -A FORWARD $protoTCP -o $EXTIF --dport 110 -j ACCEPT
$IPTABLES -A FORWARD $protoTCP -o $EXTIF --dport 995 $stateNew $actionLog
$IPTABLES -A FORWARD $protoTCP -o $EXTIF --dport 995 -j ACCEPT

#enable smtp
$IPTABLES -A FORWARD $protoTCP -o $EXTIF --dport 25 $stateNew $actionLog
$IPTABLES -A FORWARD $protoTCP -o $EXTIF --dport 25 -j ACCEPT

Alcuni commenti: La navigazione WEB viene rediretta verso squid. Nel caso in cui non si voglia implementare il filtraggio contenuti, commentare le relative righe e decommentare quelle relative all'accesso diretto. DNS è permesso per il solo dns del router 192.168.0.X che viene passato da chillispot con il dhcp per la connessione. ssh per la macchina in entrambe le interfaccie per fare assistenza remota e in loco. Conviene configurare ssh in modo solo chiavi e abbinarlo a fail2ban (vedere le note finali).

Avviamo quindi lo script /etc/inid.d/chilli.iptables e controlliamo il logging di ulogd sul file /var/log/ulod/sysemulog.log

Transparent Proxy e Dansguardian

Questo punto ha senso solo se si vu

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.


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`


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

note finali

ssh con chiavi e fail2ban

Estratto da "http://faberlibertatis.org/wiki/Hotspot_Ubuntu_Hardy_Server_HOWTO"