Newsgroup: it.comp.os.linux.sys
Titolo: Transparent Proxy & Autenticazione

Mi sta girando per la testa un pensierino per farli convivere.
Avvio squid due volte sulal stessa macchina con due configurazioni diverse, 
bindati su due porte diverse.
Il primo non fa caching, ha una configurazione minimale che permette giusto 
l'autenticazione.
Il secondo squid, quello che poi fara' da caching, content filtering etc.. 
e' in ascolto sfruttando icp sulla 3129.
Secondo voi e' fattibile? 


Io ho risolto usando squid + iptables evitando cosi 2 proxy sulla
stessa macchina.
Avevo bisogno di fare autenticazione via web + squid in modalita
trasparente.
La stessa cosa di nocat (quello per l'autenticazione degli utenti
wireless) però senza software aggiuntivo.
Se vuoi ti spiego in privato.

 Se vuoi ti spiego in privato.
Perche` in privato?!?

Se vuoi ti spiego in privato.
Senti... penso che l'argomento possa interessare tutti.
Ti invito a spiegare qui.
Ciao e grazie. 

 Ciao e grazie.
apache in ascolto sulla porta 81 con una semplice pagina di login in
php.
iptables gira la porta 80 sulla porta 81 forzando quindi la pagina di
login, mentre mette in drop tutti gli altri protocolli (ftp, ssh, etc
etc).
se il login va a buon fine, la pagina in php annulla il redirect di
iptables.
in tutto 4 righe di codice iptables + altre 4 di php.
Essendo su .sys (e non ho letto posto per aspiranti networker entrando)
non ci sono altre precisazioni da fare in quanto il redirect di una
porta ed il drop sono le *basi* di iptables.

 porta ed il drop sono le *basi* di iptables.
la ringraziamo per la sua disponibilita'.
ossequi.

 porta ed il drop sono le *basi* di iptables.
(brucia ancora? <g>)
in caso di squid sulk firewall...
iptables -t nat -A PREROUTING -p tcp -i $if_lan --dport 80 -j REDIRECT \
--to-ports 81
iptables -P FORWARD DROP
Per gli ip autorizzati, il codice dovrebbe premettere una riga del genere
in PREROUTING:
iptables -t nat -I PREROUTING -p tcp -i $if_lan --dport 80 -j REDIRECT \
--to-port 3128
Restano un po' di problemucci.
Primo: non basta un semplice REDIRECT di iptables: bisogna anche scrivere
un minimo di codice/configurazione di apache che consenta di redirigere
qualsiasi tipo di richiesta http ad una pagina di autenticazione (e questo
è tutto sommato ababstanza banale)
Secondo: gestire la permanenza delle regole di redirect verso squid, che
può già essere meno banale ed avere qualche implicazione di sicurezza.
Terzo: il codice php, per poter inserire on the fly regole di iptables,
deve quanto meno essere in grado di fare 'sudo iptables' o equivalenti, la
qual cosa non mi lascerebbe esattamente tranquillo.
In sintesi: mi pare un accrocco inutile e potenzialmente pericoloso: molto
meglio una delle classiche autenticazioni di squid, a questo punto.
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?

 meglio una delle classiche autenticazioni di squid, a questo punto.
Se la situazione lo permette, concordo..
-- 
Здрасти!
cat: .signature: No such file or directory

 meglio una delle classiche autenticazioni di squid, a questo punto.
Inutile secondo quale criterio scusa?
La parola inutile è relativa e tu come puoi giudicare?
Sicuramente dove lavori te e per le tue esigenze potrebbe essere
inutile, ma nel mio caso specifico (server multifunzione con portale
captivate stile noip) è pienamente funzionale e sicura (ne ho già
installati diversi, quindi neanche dire che è un esperimento mal
riuscito)
L'autenticazione di squid (sempre nel mio caso specifico) non andava
bene perchè:
1- non era possibile fare una pagina pubblicitaria durante il login
(non so se hai presente gli hotspot telecom o degli alberghi, sono
bombardati di pubblicità nella schermata di login)
2- come fai a fare autenticazione ncsa con transparent proxy?

 Se la situazione lo permette, concordo..
Ovviamente.


 riuscito)
Non prenderla come una cosa personale. :-)
Le mie erano considerazioni fatte al volo, sui problemi che mi venivano
in mente così, su due piedi.
Io autenticherei *prima*, personalmente.
Vlan separata per i supplicant ed openvpn, ad esempio (ciao, ouz...)


 Vlan separata per i supplicant ed openvpn, ad esempio (ciao, ouz...)
Spiegati meglio please....

 Spiegati meglio please....
Ho capito adesso cosa intendi....tu sai *a priori* chi deve navigare...
Insomma tu hai un server gateway/proxy/vpn_come_autenticazione e X
client.
Vuoi mettere in questi X client una vpn verso il gateway, in questo
modo hai una protezione fatta a livello di chiave che si può
utilizzare come autenticazione.
Se riescono ad accedere alla vpn (quindi chiave ok e quindi
autenticazione ok) allora c'è il forward della porta 80 proveniente
dal tunnel girato su squid.
Molto piu semplice (forse), molto piu sicuro, molto piu scomodo (in
alcuni casi).
Non fa al mio caso però.
Io devo fare l'area wireless dell'albergo, non posso dire al cliente:
Installa una vpn questa è la chiave. Posso dirgli apri internet
explorer metti il codice e naviga.
in questo modo qualunque client con wireless e dhcp (il 99.9% dei
clienti negli alberghi ha il dhcp sulla lan wireless) riesce a navigare
senza cambiare mezza impostazione o installare nulla...
Tu invece hai bisogno di avere su ogni client una vpn configurata adhoc
per quel server ed una chiave che corrisponda al server gateway. Ma se
gli utenti sono *dinamici* e non definiti come fai a configurare una
vpn e a dargli la chiave a tutti??c'è da diventare matti. (sempre nel
mio caso specifico)

 L'autenticazione di squid non funziona con il transparent proxy 
[cut]
Certo, hai esigenze particolari...io tendo a ragionare con la deformazione
di base della visione enterprise...


 Non fa al mio caso però.
Certo, dovresti far installare un client openvpn, innanzitutto, e gestire
una CA con revoca dei certificati "a tempo".
Mi rendo conto che non sarebbe esattamente agevole.


 Beh, per taluni avere un punto d'accesso anonimo può essere interessante...
A su questo non c'è dubbio ma per accedere o conoscono un mac attivo e
lo cambiano alla propria scheda di rete, oppure beccano user e pass che
viaggiano cifrate con ssl