remix_tj

IPSec e Group VPN Sonicwall... che stori

Sat, 26 Dec 2009 12:11:56 GMT

Di recente ho dovuto riconfigurare un netbook Samsung NC10 che mi e' stato dato in ufficio. Ho installato ubuntu karmic senza nessun problema, tutto l'hw rilevato subito, solo qualche problema per la riconfigurazione del modem umts integrato (risolto con un fix trovato su launchpad) e i pulsanti Fn-* (risolto con un repository ppa)

La mia battaglia e' sempre, invece, con la mancanza di un client sonicwall per linux che funzioni senza tante storie. Nei miei precedenti post avevo utilizzato sia racoon che openswan. Ho provato con racoon, ma non ho capito come farlo funzionare e dopo 20 minuti l'ho scartato subito in favore di openswan, che ero gia' riuscito a farlo funzionare su linux.

Il mio problema e' che ho bisogno di una configurazione altamente dinamica poiche' potrei collegarmi attraverso una qualsiasi rete (eth0, wlan0, ppp0) e avere ovviamente un qualsiasi ip.
In precedenza la configurazione che avevo fatto andava bene solo per un pc come il mio di casa che ha ip statico ed e' sempre collegato via eth0.

Dopo una battaglia infinita con google sono riuscito a scrivere una configurazione che ricalcasse le mie esigenze :-)

ipsec.conf:


version 2.0

config setup
	nat_traversal=yes
	nhelpers=1
	interfaces=%defaultroute
	protostack=netkey
	oe=off

conn provincialan
	type=tunnel
	leftid=@GroupVPN
	left=%defaultroute
	leftsubnet=10.250.0.1/32
	leftsourceip=10.250.0.1
	leftxauthclient=yes
	right=aa.bb.cc.dd
	rightid=@0006B1033F00
	rightsubnet=10.100.0.0/16
	rightxauthserver=yes
	authby=secret
	auto=add
	auth=esp
	esp=3des-sha1
	ike=3des-sha1-modp1024
	pfs=no
	keyingtries=0
	aggrmode=yes
	keyexchange=ike

Le modifiche rispetto alla precedente configurazione sono essenzialmente 2:

%defaultroute: nella riga interfaces dice a ipsec di usare l'interfaccia che ha la default route, mentre su left indica che l'ip dal nostro lato e' quello dell'interfaccia che va su internet. Unica cosa e' che l'interfaccia deve essere gia' attiva al momento dell'avvio di ipsec. Se la connessione viene attivata in un secondo momento basta dare:


sudo invoke-rc.d ipsec restart

leftsourceip=10.250.0.1: indica un ip "virtuale" da utilizzare sull'interfaccia che viene utilizzata per ipsec, per evitare di presentarsi con il proprio ip indicato su left

La connessione viene poi attivata con:


sudo ipsec auto --up provincialan

e disattivata con


sudo ipsec auto --down provincialan

Finalmente sono riuscito ad ottenere una configurazione "universale" che si puo' usare ovunque vi sia installato openswan :-)

[Annuncio] END SUMMER CAMP 2K09

Sat, 18 Jul 2009 10:14:33 GMT

_________________________SM4X_______________________

________________________presenta_____________________

___________________________

__________________END SUMMER CAMP 2K09_____________

____________________28-30 agosto 2009________________

_____________________FORTE BAZZERA_________________

___________________via Bazzera, +∞_____________

_________________Venezia-Tessera (VENEZIA)____________

[COSA] ESC � un incontro di persone interessate al Software Libero e
alla Conoscenza Libera, a Entrata Libera Il contenuto dell'evento �
in continua evoluzione e viene creato dai suoi partecipanti.

[COME] Secondo la formula MUD (Miscere Utile Dulci). Sono previsti
Seminari e Talk su vari argomenti/livelli, e momenti decisamente pi�
"ludici": Campeggio, Grigliata, LAN Party, etc.

[DOVE] ESC si svolge a Venezia-Tessera presso Forte Bazzera, ex
polveriera della Prima Guerra Mondiale non lontana dall'Aeroporto Marco
Polo. Planet Earth, 45�29'52''N - 12�19'51''E

[PERCHE'] Per creare un momento di aggregazione, uno scambio di
conoscenze ed esperienze tra persone che vivono il Software Libero nelle
sue diverse forme.

http://www.endsummercamp.org

Peccato, io non potro' esserci... pero' tutto promette bene in questa nuova, fighissima sede!

"Everything's Happening under the KEY..."

Sonicwall Global vpn client windows... e

Fri, 24 Apr 2009 19:45:06 GMT

Si perche' non e' la stessa cosa che su linux!

Mac OS X e' uno UNIX BSD e non e' quindi dotato degli stessi strumenti di Linux con cui in precedenza ero riuscito a far andare tutto.

Su MacOS X (e in genere ho visto anche su FreeBSD e OpenBSD) esiste un programma denominato racoon che si occupa delle connessioni IPSec, in abbinata con altri programmi come setkey che svolgono funzioni specifiche.

Attraverso il tool network, pero', non e' possibile configurare connessioni IPSec standard, solamente L2TP su IPSec, che non e' pero' pienamente supportato dal Sonicwall 4060 che ho a lavoro.

Ho scelto quindi di utilizzare IPSecuritas, un programma freeware, che permette di gestire le connessioni ipsec con una semplice interfaccina grafica.

L'impresa non e' stata semplice, stavo per desistere molte volte e cedere alla spesa dei 120 euro di VPN Tracker di Equinux, che si era rivelato funzionante al primo colpo... ma oggi ci sono riuscito!

La mia configurazione di ipsecuritas per usare la connessione IPSec GroupVPN del SonicWall e':

Generale
Dispositivo IPSec: ip.sonicwall.remoto.lavoro
Lato Locale: Modalita' Host, Indirizzo IP lasciato vuoto
Lato Remoto: Modalita' Rete, Indirizzo di Rete 10.0.0.0/16

Fase 1
Tempo di vita: 28800 Secondi
Gruppo DH: 1024 (2)
Criptazione: 3DES
Autenticazione: SHA-1
Exchange Mode: Aggressive
Proposal Check: Claim
Nonce Size: 16

Fase 2
Tempo di vita: 28800 Secondi
Gruppo PFS: Nessuno
Crittografia: 3DES
Autenticazione: HMAC SHA-1

ID
Identificativo: Indirizzo
Identificativo: FQDN 0006B1XXXXXX <- Lo trovate nella scheda VPN -> Settings -> Unique Firewall Identifier
Metodo di: XAuth PSK
Chiave Prescambiata: quella che trovate nella configurazione della WAN GroupVPN -> Security Policy -> Shared Secret
Username: il vostro username (anche vuoto, vi verra' chiesto alla connessione)

DNS

Se volete qui potete configurare i DNS per la vostra rete di lavoro

Opzioni
Qui viene la parte piu' complicata su cui mi sono giocato tutto:
Selezionate:

IPSec DOI
SIT_IDENTITY_ONLY
Contatto Iniziale
Supporta Proxy
Richiedi Certificato
Verifica Certificato
Spedisci Certificato
SA Unici
Frammentazione IKE
NAT-T: Disattiva

Per chi volesse usare invece racoon da solo (tipo su FreeBSD) puo' usare questa configurazione:


log notify;
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

padding
{
        maximum_length 20;
        randomize on;
        strict_check off;
        exclusive_tail on;
}

timer
{
        counter 5;
        interval 5 seconds;
        persend 1;
        phase1 15 seconds;
        phase2 15 seconds;
}

# Connection "SonicWall"
remote ip.sonicwall.remoto.lavoro
{
        verify_cert on;
        verify_identifier off;
        initial_contact on;
        passive off;
        support_proxy on;
        generate_policy off;
        verify_cert on;
        send_cert on;
        send_cr on;
        mode_cfg off;
        ike_frag on;
        doi ipsec_doi;
        situation identity_only;
        nat_traversal off;
        exchange_mode aggressive;
        proposal_check claim;
        nonce_size 16;
        my_identifier address;
        peers_identifier fqdn "0006B1XXXXXX";
        xauth_login "nomeutente";
        proposal
        {
                lifetime time 28800 seconds;
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method xauth_psk_client;
                dh_group modp1024;
        }
}

sainfo subnet 192.168.1.14/32 any subnet 10.0.0.0/16 any
{
        lifetime time 28800 seconds;
        encryption_algorithm 3des;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
}

listen
{
        isakmp 192.168.1.14 [500];
        isakmp_natt 192.168.1.14 [4500];
        adminsock "/tmp/admin.sock";

}

Alla facciazza dei 100 e passa euro di VPN Tracker!

Perche' abbandonare i formati proprietar

Fri, 06 Feb 2009 08:40:30 GMT

In questi giorni mi sono scontrato con delle persone che non capivano perche' non si dovrebbero utilizzare dei formati proprietari per i propri dati. Dopo aver spiegato e motivato ampliamente i vantaggi del formato ODF (Metodo ragionevole con buonsenso), ho scritto questo documento che espone problemi e buchi del formato proprietario di Microsoft Office (Metodo Strategia del Terrore).

Il documento si trova all'url http://www.dancetj.net/file-vari/perche-abbandonare-i-formati-proprietari.pdf/download
Se avete critiche, correzioni o modifiche da proporre contattatemi all'email che e' contenuta nel documento

The Book Meme

Wed, 12 Nov 2008 21:25:09 GMT

I file possono essere a formato libero (ad esempio i file di testo), o possono essere formattati rigidamente (ad esempio campi fissi)

A.Silbershatz, P.B. Galvin, G. Gagne - Sistemi operativi con esempio per l'uso in java

Cedo anche io a questa cosa molto divertente del book meme. E lo scrivo da casa, perche' nessuno dei libretti di istruzioni che invadono la mia scrivania a lavoro supera pagina 56 :-D Comunque, per chi non avesse capito sto preparando l'esame di Sistemi Operativi...

Contribuite alla conoscenza libraia! Fatelo anche voi:
* Prendete il libro a voi pi� vicino
* Apritelo a pagina 56
* Trovate la quinta frase
* Scrivetela nel vostro blog assieme a queste istruzioni
* Prendete il libro pi� vicino! Non quello pi� bello o quello intellettuale!

Crisi finanziaria

Wed, 01 Oct 2008 20:12:10 GMT

http://www.funfreepages.com/flash/black_dude_falling.php#

Non vi sembra simile all'andamento annuale di banca unicredit?

Fun, isn't it?

TPB vs Italian DNS: a lot of fun!

Sun, 07 Sep 2008 20:37:02 GMT

Dopo tutto il tam tam che si e' scatenato in rete sul blocco di thepiratebay.org (e chiss� quanti altri siti) oggi, gironzolando con tranquillit� sulle pagine del mio vecchio-ma-nuovo router adsl, incappo nei dns che telecom mi �invia�... Volevo verificare se era ancora disponibile quel blocco di TPB che punta verso il server della federazione dei discografici ma... A LOT OF FUN!

Faccio un po' di verifiche con i DNS che ho a disposizione e mi compare questo carinissimo risultato (nell'ordine i 2 dns di alice e quello di infostrada):


Macintosh:~ remix_tj$ dig @85.37.17.43 thepiratebay.org

; <<>> DiG 9.4.2-P1 <<>> @85.37.17.43 thepiratebay.org
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51174
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;thepiratebay.org.		IN	A

;; ANSWER SECTION:
thepiratebay.org.	28800	IN	A	127.0.0.1

;; Query time: 85 msec
;; SERVER: 85.37.17.43#53(85.37.17.43)
;; WHEN: Sun Sep  7 21:40:14 2008
;; MSG SIZE  rcvd: 50

Macintosh:~ remix_tj$ dig @85.38.28.96 thepiratebay.org

; <<>> DiG 9.4.2-P1 <<>> @85.38.28.96 thepiratebay.org
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 983
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;thepiratebay.org.		IN	A

;; ANSWER SECTION:
thepiratebay.org.	28800	IN	A	127.0.0.1

;; Query time: 47 msec
;; SERVER: 85.38.28.96#53(85.38.28.96)
;; WHEN: Sun Sep  7 21:40:17 2008
;; MSG SIZE  rcvd: 50

Macintosh:~ remix_tj$ dig @dns.wind.it thepiratebay.org

; <<>> DiG 9.4.2-P1 <<>> @dns.wind.it thepiratebay.org
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26148
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;thepiratebay.org.		IN	A

;; ANSWER SECTION:
thepiratebay.org.	86400	IN	A	127.0.0.1

;; AUTHORITY SECTION:
thepiratebay.org.	86400	IN	NS	dns.wind.it.

;; ADDITIONAL SECTION:
dns.wind.it.		86400	IN	A	212.245.255.2

;; Query time: 90 msec
;; SERVER: 212.245.255.2#53(212.245.255.2)
;; WHEN: Sun Sep  7 21:40:19 2008
;; MSG SIZE  rcvd: 91

Macintosh:~ remix_tj$

EHI! TPB NON E' SUL MIO COMPUTER LOCALE!

Pero' boh, puo' essere un mio problema locale (non ricordo mai se ho forzato i dns...)

mah.

Allora chiedo ad un po' di amici se e' cosi' e mi arriva questa risposta:

ciao, l'avevo notato anche io qualche giorno fa, il comportamento dei
DNS di infostrada � lo stesso

user@host:~$ dig @193.70.152.15 thepiratebay.org labaia.org
thepiratebay.org. 86400 IN A 127.0.0.1
labaia.org. 86400 IN A 127.0.0.1

Al che mi torna in mente una cosa che il mio caro amico ascii di www.ush.it mi aveva mostrato tanto tempo fa e che lui aveva etichettato in una sua slide con il nome:
"Web disservices: lazy admincripples same origin policy"

Spiego semplicemente come funziona questa configurazione (che puo' rivelarsi a posteriori un problema).

In genere una persona comune, quindi circa il 90% dell'utenza italiana, non ha un servizio in locale che ascolta sulla porta 80. Avviene quindi che una persona che tenta di collegarsi ai siti che risolvono con 127.0.0.1 si trova davanti una bella pagina di connessione rifiutata. Come e' giusto che sia, non c'e' niente su 127.0.0.1 porta 80.
Il restante 10% dell'utenza vedra' il proprio sitarello web locale... Ma tanto di solito il 10% in oggetto e' utenza sgamata e usa altri dns :-D

L'idea e' molto buona in se' e anche vecchiotta. Il cambio di risoluzione del dns e' una tecnica che si usa in molti posti per bloccare i siti, per esempio la uso anche io facendo si che certi siti risolvano con l'ip del server con la pagina di cortesia.
Ma si porta dietro un bel problema. Bello grosso.

Immaginiamo di avere un sito considerato "attendibile", che usiamo spesso e di cui ci fidiamo (e che magari, se usiamo su internet explorer, compare nella lista "siti attendibili" ) , che viene per qualche motivo bloccato dal nostro dns con la tecnica citata in precedenza. Ci troviamo quindi nella situazione che sitomoltoattentibile.it risolve 127.0.0.1.
Succede per qualche motivo che un software malevolo si installi sul nostro computer e si metta in ascolto sulla porta 80. Non fa niente di male, finche' se ne sta solo li' in ascolto. Infatti quando noi andremmo a collegarci al sito www.sitoattendibile.it ci troviamo che invece di fare richieste al server legittimo, effettuiamo una richiesta al software malevolo (che non aspettava altro).

Quello che puo' il software malevolo? Bah, iniettarvi altro software malevolo, farvi incartare il browser o piu' semplicemente.... RUBARE I VOSTRI DATI PERSONALI DEL BROWSER!

Oppure ancora meglio se esiste un software locale che rende disponibile un servizio http su qualche porta (quindi niente software malevolo) e per qualche motivo le pagine che ci rende disponibii hanno la possibilita' di essere alterate al fine di compiere un XSS che in qualche modo vi spara da qualche parte o effettua qualche operazione che puo farvi fare chissa' quale schifezza...

AHH! PANIC! MY PRIVACY!

Volete una soluzione?

Davvero?

No, OpenDNS non e' la soluzione.

bind9 is the way.

Credits: per lo spunto iniziale e per la versione con XSS del problema ascii e giogio di www.ush.it

Sonicwall Global vpn client windows... e

Fri, 01 Aug 2008 21:05:34 GMT

ATTENZIONE: questo non e' un post ctrl-c ctrl-v (o cmd-c cmd-v se usi Mac OS)! Prima di funzionare ha bisogno di qualche modifica!

"eh, per linux non c'e'". Questo mi sono sentito dire da un genio di tecnico che ha venduto un SonicWall PRO4060 all'ente per cui lavoro.

Ma scusatemi. Secondo voi questi cicci di Sonicwall si sono inventati un protocollo vpn per i cavolacci loro? nah. non ci credo. Sono mica cisco systems!

E vai con google!

Scopro, rovistando su google, che e' una normalissima connessione ipsec, ma con dei parametri "astrusetti".

Tutto sta nel avere un po' di dati dal gestore del firewall (per fortuna a lavoro lo gestisco io), installare OpenSwan

Una soluzione completa su google non l'ho trovata; ho lavorato tutta la sera per riuscire a montare i vari pezzetti, ma ci sono riuscito.

Su linux ora mi posso collegare alla mia intranet di lavoro!

Per i piu' curiosi ecco la mia ipsec.conf:


version 2.0 # conforms to second version of ipsec.conf specification

config setup
	nat_traversal=yes
	nhelpers=1
	interfaces="ipsec0=eth0"

conn provincia
	type=tunnel
	leftid=@GroupVPN
	left=192.168.1.2 <- ip di eth0
	leftsubnet=0.0.0.0/0.0.0.0
	leftxauthclient=yes
	right=XXX.XXX.XXX.XXX <- ip remoto del sonicwall
	rightsubnet=10.100.0.0/16 <- subnet remota
	rightxauthserver=yes
	rightid=@0006XXXXXXXX <- id univoco del sonicwall remoto, e' il mac address
	authby=secret
	auto=add
	auth=esp
	esp=3des-sha1
	ike=3des-sha1-modp1024 <- -modp1024 = Group 2
	xauth=yes
	pfs=no
	keyingtries=1
	aggrmode=yes
	keyexchange=ike

e ipsec.secret:


@GroupVPN @0006XXXXXXXX : PSK "cippalippasharedkey"

Sono proprio contento. Ora posso riprenderemi anche quei 4 giga di windows che usavo SOLO per questo.

E quando mi torna il macbook metto su tutto anche li'! WOOT!

Ps: chi scopre per quale ente lavoro vince la versione unveiled della conf

Dedica

Tue, 13 May 2008 13:33:21 GMT

ATTENZIONE! Questo e' un post che potrebbe farti passare la voglia di lavorare gingillandoti con delle cose inutili da passare ai tuoi amici via IM/IRC!

Ultimamente ho letto un po' di log e documenti relativi a degli screzi sorti nelle cose in cui sono impegnato (chi sa sa) e per questo volevo, con simpatia, affetto e soprattutto un grandissimo sorrisone in faccia (e perche' no, un PROT) dedicare una cosa a MefistoRQ.

[more=Leggi tutto il post]

Premetto che non ho niente in contrario a Remo, con cui ho avuto l'opportunita' di scherzare piu' di qualche volta.

Pero', in base a tutte le informazioni che sono in mio possesso, questa se l'e' guadagnata:

Ecco il link a lui dedicato!

Ripeto che non ho nessun tipo di conto in sospeso con MefistoRQ, ma forse ora lui ne avra' uno con me

Buon resto di giornata!

Squid proxy in cascata

Thu, 17 May 2007 12:45:34 GMT

Il nostro captive portal all'itis planck aggiunge una complicazione alla configurazione di Squid. Ci si trova di fronte ad una configurazione di proxy in cascata in cui le modifiche proposte precedentemente non funzionano.

Prima di tutto bisogna far notare che non e' possibile utilizzare un transparent proxy con il protocollo HTTPS: Squid non puo' reindirizzare connessioni https transparentemente perche' le richieste (GET POST ecc ecc) sono cifrati da dopo il momento dell'handshaking SSL.

[more=Read more]

Poi i proxy in cascata: se il proxy del captive portal non e' informato di dover rivolgersi ad un proxy superiore riceveremo un "Invalid URL".
La richiesta che fara' infatti il nostro proxy sara'


GET / HTTP/1.1

poiche' non e' a conoscenza del secondo proxy che deve passare. Il secondo proxy, ricevendo una richiesta simile dira': "A che sito devo inoltrare la richiesta? boh, URL non valido".

Per evitare questo problema configuriamo un Upstream Proxy in Squid. Prima di tutto devo dire che non e' una cosa molto semplice, come invece e' in altri proxy che con una righettina se la cavano.


cache_peer 172.16.200.251 parent 80 0 no-query default proxy-only

Questa prima riga informa il nostro squid della presenza di un proxy a lui superiore (parent) che ascolta sulla porta 80 di 172.16.200.251.
Le opzioni no-query,default,proxy-only indicano rispettivamente di non mandare query ICP (Internet cache protocol) al nodo di cache (cache_peer), che questa e' proxy di default da usare anche come ultima risorsa e di non salvare localmente gli oggetti in cache.

La seconda e ultima modifica consiste nel aggiungere


never_direct allow all

per fare in modo che le richieste non siano richieste dirette (es: GET / HTTP/1.1) agli host che si vogliono visitare. Le richieste, quindi, al loro interno conterranno anche il nome dell'host che si vuole visitare (es: GET www.remixtj.net/ HTTP/1.1).

Detto questo possiamo passare alla parte di monitoraggio delle connessioni.

I problemi non sono mai a sufficienza -

Fri, 27 Apr 2007 21:10:13 GMT

Dopo aver completato per intero il progetto qui a casa e aver montato tutto allo STESSO IDENTICO modo a scuola, qualcosa (ovviamente) non ha funzionato.

Il problema non e' dovuto al progetto, ma bensi' alla struttura della rete scolastica che prevede che tutte le macchine debbano AUTENTICARSI al proxy su serlinux1.
Da un attenta analisi (troppa rottura di balle autenticarsi due volte) abbiamo deciso che il traffico web proveniente dal nostro server centralizzato del wireless e diretto verso il mondo esterno non debba necessitare di autenticazione. In fondo, ogni utente viene gia' autorizzato con nome utente e password per usare l'hotspot, non dovrebbe bastare?

[more=Leggi il testo completo dell'articolo]

Pensavamo bastasse utilizzare squid in cache_peer, ma non c'e' stato modo di farlo andare. Lo abbiamo sostituito temporaneamente allora con tinyproxy, che e' un semplice transparent proxy che per fare le cose in 2 secondi va benissimo. Ma non c'e' stato modo di togliere l'autenticazione, nessun proxy a noi noto permette di impostare al suo interno username e password con cui comunicare con un upstream proxy.

E qui comincia la saga (troppe saghe non fanno male, cit.) dal titolo "Please remove this f*****d AUTH". I protagonisti siamo io e il professor Ferroni, che mi segue nella creazione del progetto (in quanto root@maxplanck). Non sto qui a raccontarvi passo passo cosa abbiamo fatto pero' vi elenco in linea di massima 4 probabili soluzioni che abbiamo provato e che si sono rivelate non funzionanti:

aggiungere una acl per serlinux7 e relativa http_access prima della voce http_access deny !password (vieta l'accesso al www senza password)
```
acl serlinux7 172.16.200.157
(....)
http_access allow serlinux7
http_access deny !password
```
modifica dell'http_access dicendo di permettere l'accesso a serlinux7 senza password
```
http_access allow serlinux7 !password
http_access deny !password
```
cambio del deny !password con un allow password (permetti a quelli con password) seguito da un deny all (nega a tutti gli altri)
```
http_access allow serlinux7 !password
http_access allow password
http_access deny all
```

rimozione dell'http access delle password


http_access allow serlinux7
http_access allow all

Naturalmente, NESSUNA DI QUESTE HA FUNZIONATO

La soluzione, che e' piu' scema del solito, era proprio dietro l'angolo e MI e' balenata alla mente grazie a questa parte dello SquidBook:

quando viene impostata un qualsiasi tipo di ACL del tipo proxy_auth tramite le regole http_access, tutte le ACL successive alla regola proxy_auth non verranno pi� considerate da Squid in quanto o l'accesso sar� stato consentito oppure verr� generato un errore di acceso negato alla cache. Se si deve configurare un proxy in maniera granulare � quindi necessario portare molta attenzione nell'applicazione delle regole http_access. In buona sostanza, una volta che ci si � autenticati su un sistema Squid � tutto permesso tranne quello che � stato esplicitamente negato nelle regole http_access precedenti alla regola http_access proxy_auth

Insomma la soluzione si e' rivelata piu' stupida del normale:
prima di


acl password proxy_auth REQUIRED

ho inserito


acl serlinux7 172.16.200.157
http_access allow serlinux7

Questa regola, trovandosi prima del proxy auth fa si che non sia richiesta l'autenticazione quando ci si connette.

Semplice no? In fondo quanto piu' grave e' il problema, quanto piu' stupida e' la soluzione.

Configurazione dei servizi di contorno

Sun, 15 Apr 2007 10:32:44 GMT

Per il completamento dell'hotspot sono necessari dei servizi "di contorno", fondamentali per la migliore gestione degli accessi:

FreeRadius: Servizio fondamentale perche' viene usato come database delle credenziali di tutti gli utenti.
Apache: Attraverso apache sara' possibile accedere alla pagina di autenticazione dell'hotspot
Squid Proxy: viene usato per fare la registrazione delle pagine web visitate dagli utenti (per aderire al DECRETO-LEGGE 27 luglio 2005, n.144 "Misure urgenti per il contrasto del terrorismo internazionale", articolo 6)

Ah, non dimentichiamo la configurazione di iptables, fondamentale per far funzionare tutto.

[more=Leggi l'articolo completo]

Freeradius

Fortunatamente la configurazione di freeradius e' veramente minima. In primis dobbiamo modificare il file /etc/freeradius/clients.conf in modo da avere una parte come questa:


client 127.0.0.1 {
      secret = theradiussecret
      shortname = localhost
      nastype = other
}

ovviamente potete modificare sia l'ip del client (nel nostro caso a scuola sara' anche 172.16.200.157, l'ip del server chillispot).

Salviamo e riavviamo il servizio

Apache

Apache ha bisogno di una configurazione veramente minima: basta creare un virtualhost con SSL e riavviare. Mi raccomando: obbligatoriamente SSL altrimenti il login manager non funzionera' (e ha ragione).

Squid Proxy

Squid richiede un po' di piu' di conoscenze del servizio. Faccio notare che non e' fondamentale per il funzionamento di tutto, pero' e' richiesto per legge se l'hotspot e' pubblico.
Il file interessato alla modifica e' /etc/squid/squid.conf, l'unico file di configurazione del servizio.
Prima di tutto e' necessaria la configurazione come transparent proxy e bisogna agganciarlo solo all'ip di eth1:


http_port 192.168.10.73:3128 transparent

Poi e' necessario definire una ACL per fare in modo che sia possibile utilizzare il proxy da un certo ip. Nel nostro caso l'ip sara' quello di eth1, poiche' con le regole di nat del firewall per obbligare il passaggio per il proxy, dobbiamo alterare l'ip di provenienza dei pacchetti con DNAT (Destination Network Addres Translation).
La acl e' la seguente:

acl localmachine src 192.168.10.73
http_access allow localmachine

In fine, per far funzionare correttamente il transparent proxy (ho incontrato dei problemi nell'utilizzo del caching) aggiungiamo questa riga:


always_direct allow localmachine

Salviamo il file e riavviamo il proxy.

IpTables
Le regole di iptables per far funzionare tutto sono 4, piu' una modifica del sistema con sysctl per abilitare il forwarding dei pacchetti.

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.10.0/24 
-j MASQUERADE

Questa prima regola si occupa di fare in modo che i pacchetti che provengono dalla rete degli access point appaiano con l'ip dell'hotspot.

iptables -t nat -A POSTROUTING -o eth0 -s 192.168.182.0/24 
-j MASQUERADE

Questa seconda e' del tutto uguale alla prima solo che altera i pacchetti provenienti dalla rete virtuale creata da chillispot.


iptables -A PREROUTING -t nat -i eth1 -p tcp --dport 80 
-j REDIRECT --to-port 3128
iptables -A PREROUTING -t nat -i eth1 -p tcp --dport 443 
-j REDIRECT --to-port 3128

Queste ultime 2 regole, invece, si occupano di spedire tutto il traffico destinato alle porte 80 (http) e 443 (https) a SQUID, in modo che il traffico possa essere registrato.

L'ultimo comando necessario per completare il tutto e':


sysctl -w net.ipv4.ip_forward=1

che permette l'inoltro di pacchetti tra un interfaccia e l'altra.

Arrivederci Toni

Sat, 03 Mar 2007 18:22:27 GMT

Il 27 Febbraio e' scomparso una persona che mi e' stata guida per anni, Toni Simionato. Volevo Con questo Post ricordarlo, ricordare la guida che per anni ci ha portato ad amare le montagne, la pace e la bellezza di quei luoghi. Sempre gioioso e disponibile, abbiamo riso per tantissime ore con lui. Ora lui ci ha lasciato, cadendo da una scarpata tornando dal monte Pizzocco.
Potete avere maggiori informazioni sull'accaduto qui
http://www.adnkronos.com/3Level.php?cat=Veneto&loid=1.0.741226296

Lui, uomo a che amava il canto e che cantava in vari cori, i suoi amici del Coro Voci del Sile gli hanno dedicato questo canto:

Signore delle Cime

Dio del cielo,
Signore delle cime,
un nostro amico
hai chiesto
alla montagna.
Ma Ti preghiamo:
Su nel paradiso,
lascialo andare
per le tue montagne.

Santa Maria,
Signora della neve,
copri col bianco,
soffice mantello
il nostro amico,
il nostro fratello.
Su nel paradiso,
lascialo andare
per le tue montagne

Esecuzione del Coro della Brigata Alpina Cadore

Decoding Authentication Client

Tue, 30 Jan 2007 21:28:02 GMT

Se c'e' una cosa per molto tempo mi ha dato fastidio era aver acquistato quella enciclopedia (che giace ancora nuova sulla mia scrivania) corredata di enciclopedia onlne. Pensavo fosse qualcosa di serio, in finale si e' rivelata la solita porcheria per portare via soldi alla gente.
Il punto sta proprio nell'enciclopedia online.

L'accesso all'enciclopedia e' possibile solo utilizzando un programma che loro ti danno, denominato Motta Autentication Client (d'ora in poi MAC). Non dovrei scriverlo, perche' e' cosi' ovvio, ma il programma e' solo per sistemi Microsoft Windows. Quindi tagliamo fuori dall'accesso al sito tutti gli utenti Apple e gli utenti di altri sistemi.

Io ovviamente non ci sto. L'accesso alla conoscienza deve essere per tutti, specialmente se ho pagato. Allora ho cominciato ad analizzare come portare il MAC su linux. Prima di tutto ho pensato a wine, ottimo tool che permette di eseguire i programmi compilati per windows su ambiente linux. Allora ho analizzato il funzionamento e possiamo schematizzare principalmente in 3 fasi:

Consultazione del registro di sistema per recuperare username, password e questo MAGIC che viene fornito durante la registrazione
Connessione ad un servizio apposito detto Authentication Server dove attraverso una serie di comandi si ottiene una stringa alfanumerica di 32 caratteri
Apertura di un browser (con wine mi si e' aperto Firefox!) puntato verso il sito della loro banca dati, passando in GET la stringa alfanumerica ricevuta dall'autentication server.

3 passi semplcissimi che permettono l'accesso al sito. Pensando con ascii cosa poteva essere, abbiamo supposto che sia un ID di sessione (infatti il messaggio e' lungo 32 caratteri come gli id di sessione normali) temporanea (infatti scade dopo qualche tempo, circa 5/10 minuti).

Quindi se per accedere al sito e' necessario quell'id, e' necessario analizzare come ci viene assegnato.

Le chiavi sul registro di sistema

Wine cosi' me le ha salvate sul file ~/.wine/system.reg


[Software\Motta] 1108497969
"Auth"="server.di.autenticazione.com"
"Home"="http://sito.della.enciclopedia.online.com/index.php"
"Magic"="thisisthemagicaverylongstring"
"Password"="**********"
"Port"="2002"
"Remember"="1"
"UserName"="user1234"

quindi ecco come possiamo tirarci fuori i dati occorrenti.

Analisi della fase 2

Lanciato il MAC e aperto Wireshark in ascolto su eth0 (la interfaccia attraverso la quale accedo alla Rete) ho filtrato i messaggi destinati al server di autenticazione e quelli che riceviamo. Il risultato e' questo:


RDY  Motta Authentication Server Ready! version 2.0 beta 2
.USER user1234
+OK  Welcome user. Please send your password.
.PASS **********
+OK  Password received. Please send your magic!
.MAGICthisisthemagicaverylongstring
+OK  Now register or authenticate!
.AUTH 
.+OK  Authenticated! Interactive mode started.
.UPDT 
.+OK  
.+MSG .
GETID
.+OK  
.+MSG GQ10pv7BW5AzPB6wY8y94aSrG6DzE6q0
QUIT 
.+OK  
.

Devo dire che per ora abbiamo tirato fuori abbastanza da poter scrivere un programmino (che penso faro') che faccia tutto questo senza problemi e senza dover usare wine.

Beh, bel lavoretto di analisi. Non so quanto contenti saranno...

Installazione e configurazione ChilliSpo

Fri, 22 Dec 2006 08:57:16 GMT

Prima di tutto e' necessario scaricare chillispot da http://www.chillispot.org/download/. L'ultima release disponibile al momento della stesura e' la 1.1.0.

L'installazione prosegue normalmente come tutti i pacchetti sorgenti con


$ ./configure
$ make
$ su -c "make install"

Poi si prosegue alla modifica del file /etc/chilli.conf, contentente la configurazione che noi abbiamo scelto.

Qui al planck la configurazione e' la seguente


radiusserver1 172.16.200.253
radiusserver2 127.0.0.1
radiussecret ********************
net 192.168.176.0/21
dns1 172.16.200.251
dhcpif eth1
uamallowed 192.168.176.1,192.168.1.73,172.16.200.251
uamserver https://192.168.1.73/hotspot.php
uamhomepage https://192.168.1.73/welcome.html
uamsecret ************

Ovviamente le secret sono state opportunamente offuscate

Passiamo alla descrizione delle varie opzioni usate

radiusserver1: server radius dove verificare i dati dell'accredditamento
radiusserver2: server radius di backup
radiussecret: la password per l'accesso al server radius
net: la classe di ip che il server dhcp di Chillispot deve dare ai client
dns1: server dns inviato ai client come configurazione
dhcpif: interfaccia dove bindare il server dhcp
uamallowed: ip/domini a cui e' permesso l'accesso dai client senza autenticarsi
uamserver: pagina dove indirizzare le richieste di autenticazione
uamhomepage: pagina in cui si va a finire nel caso si cerchi di navigare un sito non listato negli uamallowed senza essere autenticati
uamsecret: la password di cifratura utilizzata dai dati di autenticazione.