Newsgroup: it.comp.os.linux.sys
Titolo: forzare utilizzo di squid

Ciao a tutti,
nella mia lan ho un server che fa da gateway verso internet e sul quale ho
installato squid. E' possibile impedire ai vari client (win/linux) di
accedere al web senza passare da squid?
-- 
Filippo Santovito


devi agire in ogni caso sul gateway (o per fare un redirect o per 
bloccare tutti tranne la macchina con squid)
Se non puoi agire sul gateway devi usare le policy di windows.
--
Massimiliano.

Filippo Santovito wrote:

beh, è uno dei punti di forza di squid fare quello che chiedi sperando di
non aver frainteso.
se nei browser/client imposti la porta del server proxy loro puntano li e
devono sottostare alle acl impostate e quindi puoi decidere chi/dove/quando
può uscire su internet.
Essendo però facile per un qualsiasi utente mezzo smalizziato togliere le
impostazioni dal browser e saltare squid, allora devi impostare in modalità
transparent in modo che senza impostare nulla sui browser, le chiamate
verso la porta http 80 vengano automagicamente redirette verso la porta di
squid e far in modo che l'utente malintenzionato si dia delle zappate sugli
zebbedei...
Il tutto mi funziona perfettamente con squid su slackware. 
Ciao 

 accedere al web senza passare da squid?
si, col transparent proxy. Scrivi una regola che dice al kernel di
indirizzare tutto il traffico diretto verso tutte le porte 80, alla
porta in cui sta girando squid (con iptables)
Devi anche mettere delle direttive in squid.conf per il transparent
proxy.
Se fai una breve ricerca trovi entrambe le cose.
Ovvaimente sui vari client web non devi mettere nulla nel campo di
settaggio del proxy, dal loro punto di vista il proxy non c'e'.
-- 
| Ciao Cacciavite          Linux Registered User #297089
| Powered by *Debian GNU/Linux 3.0* on  PentiumII 400Mhz
| E-mail:            caccia...@TOGLIQUESTOtiscali.it

 Il tutto mi funziona perfettamente con squid su slackware.
Sembra quello che cerco. Cercherò informazioni a riguardo. Grazie 1k ;)
-- 
Filippo Santovito

 di accedere al web senza passare da squid?
Non fai il routing ip verso internet, con o senza nat che sia. Chi vuol
uscire deve configurare il proprio host (a manina o con script) in modo
da usare esplicitamente il proxy. IMHO e' l'unico modo serio d'operare.
Fabio

 porta in cui sta girando squid (con iptables)
mmhh non credo che la domanda fosse quella. Non e' stato specificato se 
linux e' o meno il gateway (e mi pare di capire di no).
I suoi client possono impostarsi il gateway che vogliono e uscire: 
questo era il punto.
--
Massimiliano.

 Non fai il routing ip verso internet, con o senza nat che sia. Chi vuol
Grazie per la tua rispota ma "a naso" penso che il trasparent proxy sia piu
utile... magari mi ricrederò ;)
-- 
Filippo Santovito

 questo era il punto.
Se ho ben capito col trasparent proxy in questo caso non potranno farlo.
-- 
Filippo Santovito

 
Il transparent proxy è un accrocchio che crea più problemi di quanti ne 
risolva e che toglie a squid alcune feature estremamente utili.
Se non rientra in un preciso schema progettuale è da evitare.

 Cosa intendi con "utile"?
Un cosa è utile quando il suo funzionamento risolve piu problemi di quanti
ne crea IMHO.
-- 
Filippo Santovito


Cosa intendi con "utile"?
Fabio

 non ho specificato ma mi sembrava un po ovvio su icols ;)
scusami ma allora il tuo post e' veramente scontato e ovvio.
La risposta e' quella che ti hanno dato gli altri:
blocchi il gateway per i client e usi il transparent proxy.
Il trasparent proxy dovresti poterlo fare anche con apache! Ma se vuoi 
roba piu' sofisticata userai squid.
--
Massimiliano.

 risolva e che toglie a squid alcune feature estremamente utili.
Sto leggendo questo:
http://www.opennet.ru/docs/HOWTO/mini/TransparentProxy-2.html
E non mi sembra così malvagio. Ma non avendo esperienza diretta non so cosa
"c'è dietro". Puoi motivare le tue affermazioni per rendermi il quadro piu
chiaro?
Grazie per la tua disponibilità.
-- 
Filippo Santovito


il tuo naso non funziona bene ;)
Il trasparent proxy come ti dicevo lo puoi fare anche con apache. Ma sia 
con apache, sia con squid avrai pochissime funzionalita'.
--
Massimiliano.

 problemi di quanti ne crea IMHO.
Tutto si riduce a definire quali sono i "problemi". Pensa 
a quali problemi devi risolvere e a come le due soluzioni
si comportano. Pensa anche agli spetti gestionali nei due
casi e a quali problemi _non_ risolvono.
Dal mio punto di vista il transparent proxy e' funzionale 
alla soluzione del problema "risparmio della banda quando
non si ha il controllo sui singoli host che accedono alle
risorse web". Quando i "problemi" sono la sicurezza ed il
controllo degli accessi, la situazione e' diversa. Sempre
IMHO.
Fabio

 chiaro?
dimenticati feature quali implementazioni ldap, autenticazioni 
particolari, tipo se un account e su un ip non puo' essere su un altro 
IP e cosi' via (onestamente non avendoci lavorato non nemmeno se si puo' 
gestire una autenticazion base).
Lo vuoi un bel software che fa per te? --> 
www.delegate.org
  eheh, tieni 
pero' ben presente che si tratta, a mio avviso, forse del software piu' 
complesso per linux che io abbia mai visto.
--
Massimiliano.



Sì.
iptables -t nat -A PREROUTING -i $internal_if -p tcp --dport 80 \
-j  REDIRECT --to-ports 3128
iptables -A INPUT -i $internal_if  -p tcp --dport 3128 -j ACCEPT
iptables -A FORWARD -i $internal_if -p tcp --dport 80 -j DROP
-- 
Per non dimenticare:
http://snipurl.com/SdC_ed_il_vino
Le sigarette a volte danno buoni consigli:
http://snipurl.com/sigarette

 ne crea IMHO.
Eliminare il routing se la gente deve andare solo in http è tutto
fuorchè creare problemi, anzi.


 chiaro?
Perdi qualsiasi possibilità di effettuare una autenticazione della 
sessione HTTP, salvo uso di accrocchi quale captive portal o simili (che 
però, strettamente parlando, non autenticano la sessione o l'utente 
quanto il mac-address), tanto per dire, il che non mi pare cosa da poco.
Se la navigazione effettuata sull'utente può essere un plus-ultra, 
aggiungiamo che se vuoi applicare differenti profili di utilizzo 
per-utente (content filtering con whitelist personalizzate, piuttosto 
che diversi livelli di "apertura", ecc) ti diviene decisamente difficile 
fare qualcosa senza avere possibiltà di discernere un utente da un altro 
(e se non autentichi voglio ben vedere), e da qui si apre una bella 
lista di possibilità in cascata.
Infine, il concetto stesso di transparent proxying è di per sè un 
accrocchio, poichè il client si connette a qualcosa che crede essere il 
server ma non lo è (sia a livello di stack tcp/ip, che a livello 
applicativo) e questo in alcuni casi può dare i suoi problemi.
Dal lato opposto, l'unico vantaggio *vero* offerto è "non
configuri i client". Tale vantaggio diviene significativo IMHO solo in 
ambienti molto grandi, dove i client sono molti veramente. Tuttavia, 
qualunque ambiente di *grosse* dimensioni che si rispetti dovrebbe già 
prevedere dei meccanismi di policy enforcing che permettano di gestire 
tali configurazioni in push.
Quindi l'effettiva utilità è su ambienti particolari, ove non vi sia 
centralizzazione della gestione, ad esempio estremamente eterogenei dal 
punto di vista degli OS installati, oppure liddove ci sia una 
frammentazione organizzativa ad impedirlo.
Infine, mi permetto di aggiungere che realizzare un manuale operativo da 
far seguire al singolo utente (per stupido che sia) e che lo guidi 
finestra per finestra nella configurazione del proxy sulla propria 
macchina richiede minuti 5 al più. Mandi il manuale a tutti, notificando 
di effettuare le variazioni entro un tempo limite, scaduto il quale 
chiudi il routing di tutto l'http. Perdi meno tempo così che a 
smadonnare sul transparent proxying, IMHO...
Aloha!

 Fabio
e i servizi che non usano HTTP? si attaccano?
ciao,
Francesco

 automaticamente con il dhcpd) o non si va da nessuna parte.
Quale option del dhcpd.conf usi per settare il proxy nei client?
-- 
Filippo Santovito

 e i servizi che non usano HTTP? si attaccano?
Con proxy, relay o permettendo il routing in modo mirato per ip src, ip dst
e porta, per esempio, dove e quando consentito. Mi ripeto: perche' si vuole
fare passare tutto il traffico per il proxy? Le scelte dipendono da come si
risponde a questa domanda, prima di tutto. Senza info e senza conoscere gli
altri dettagli della realta' specifica, mi sembra che la risposta sopra sia
quella di valenza piu' generale.
Fabio

 frammentazione organizzativa ad impedirlo.
supponendo di sistemare il server per fornire servizio di
autoconfigurazione del proxy (mi pare con apache?) i browser poi si
arrangiano a trovare il proxy in una installazione di default? o bisogna
sempre configurarli a manina? oltre a un windows + exploder installato di
default come se la caverebbero i vari firefox, mozilla ecc...?

 default come se la caverebbero i vari firefox, mozilla ecc...?
Tiran dritti e tanti saluti.
Però mettere in piedi uno script che editi prefs.js e aggiunga la 
locazione del .pac non dovrebbe essere affatto difficile, nel caso...

 uniq|wc -l
     43
Questo e' il numero di porte per cui avrei dovuto fare REDIRECT, tra lunedi'
e oggi, per fare passare _tutto_ il traffico web dal proxy. Banale problema,
volendo, se confrontato con altri gia' citati.
Fabio

 roba piu' sofisticata userai squid.
Oh mamma...
ma te di scrivere cazzate non ti stufi mai? 


guarda non dico niente.
Ti do solo in pasto questo qui:
http://www.wede.de/sw/mod_proxy/
Mi inchino profondamente di fronta alla vostra bravura.
--
Massimiliano.

 Mi inchino profondamente di fronta alla vostra bravura.
adamo, perche' non stai un pochino zitto?
ci fai piu' bella figura sai?
oppure, perche' non torni a rompere le palle su icod, li almeno c'era
qualcuno che ti sopportava.

 qualcuno che ti sopportava.
Mi spighi che cazzo vuoi?
--
Massimiliano.

 Mi inchino profondamente di fronta alla vostra bravura.
Attento a non inchinarti troppo, che l'istinto di piantartelo ripetutamente 
nel culo sta facendo breccia. 

 *astute* soluzioni travestita da cagata.
sei comletamente cretino o cosa?
Ma di che stiamo parlando?
Io non ho consigliato nessuna soluzione. Io ho scritto che se vuole lo 
puo' fare anche con Apache. FINE.
"The cool thing about Apache, though, is that it's not just a Web 
server. It can do lots of other things too - and of its more interesting 
(though less well-known) capabilities includes the ability to act as a 
proxy server for both HTTP and FTP connections over a network."
basta. fine della discussione. Non sto di cosa stiamo discutendo.
--
Massimiliano.

...

in effetti se forzi i luser ad usare un proxy mettendolo transparent č
quasi *certo* che non debbano usare poi tanti servizi diversi dal web.
e una porta ftp o ssh la puoi sempre aprire se serve ;-)
perň come dici tu dovremmo saperne di piů...
saluti
Francesco

 trovato) non e` particolarmente illuminante
Probabilmente per il tuo problema hai gia` risolto. A me e` stato 
sufficiente aggiungere alla riga di comando l'opzione -user-net per 
avere un networking funzionante seppur con le limitazioni che comporta.  
Il device tun/tap non sono riuscito ad usarlo correttamente, ma ammetto 
di averci perso davvero poco tempo e per ora non mi serve.
Ho pero` un altro problema che mi sta creando problemi. Dovrei usare una 
periferica esterna via seriale del pc da dentro qemu, ed ovviamente non 
ci riesco.  :)
Nella documentazione c'e` solo un accenno:
QEMU emulates the following PC peripherials:
--- cut ---
    * Serial port
Ma oltre a questo non ho trovato nient'altro di utile.
Qemu mi da a disposizione una seriale. Ovviamente ho provato ad usare 
entrambe le seriali presenti sul mio pc ma sembra che non funzionino.
-- 
| Massimo ;-) -> 
http://maq.altervista.org
        |       (o_        |
|- BABYLON 5  -> 
http://babylon5.altervista.org
   |  (o-  //\   -o)  |
|- STARGATE   -> 
http://sg1screw.altervista.org
   |  (/)_ V_/_ _(\)  |
|- USSTRIBOLO -> 
http://usstribolo.altervista.org
 | POWERED BY LINUX |