Menu Chiudi

Squid > 2.5.10: Come forzare la reidentificazione e possibili problemi

Dalla versione 2.5.10 di Squid (il sw proxy più usato sui sistemi Linux) è stata introdotta una particolare caratteristica nella composizione delle Access Control List, per permettere di forzare l’identificazione degli utenti con credenziali diverse. Per quanto utile, questo comportamento può essere insidioso in alcune circostanze.


Dalla versione 2.5.10 di Squid (il sw proxy più usato sui sistemi Linux) è stata introdotta una particolare caratteristica nella composizione delle Access Control List, per permettere di forzare l’identificazione degli utenti con credenziali diverse. Per quanto utile, questo comportamento può essere insidioso in alcune circostanze.


Forzare la reidentificazione.

Normalmente quando un utente è identificato da Squid (tramite una acl di tipo proxy_auth) non è possibile per l’utente utilizzare credenziali diverse se non chiudendo il browser e riavviandolo. Con la versione 2.5.10, è stata aggiunta la possibilità, tramite un particolare accorgimento, di forzare la re-identificazione; supponiamo ad esempio di voler concedere l’accesso a Google solo ad alcuni particolari utenti (gli esempi sono tratti dal wiki di squid ) :

acl my_auth proxy_auth REQUIRED
acl google_users proxyauth user1 user2 user3
acl google dstdomain .google.com
http_access deny google !google_users
http_access allow my_auth
http_access deny all

A qualsiasi utente è richiesta l’identificazione per poter navigare (prima riga http_access), ma cosa succede se si punta il browser al dominio google.com? Si potrebbe presumere che solo user1, user2, user3 possano raggiungere la pagina, e che gli altri siano semplicemente respinti. In realtà invece agli utenti diversi da user1, user2, user3 viene riproposto il pop-up per inserire utente e password (se si usa un meccanismo di autenticazione basic ).

Il criterio è il seguente: se l’accesso è negato da un acl legata all’autenticazione (attenzione, per negare l’accesso l’acl deve essere l’ultima della riga, si dice che l’acl “matches“), viene richiesta nuovamente l’autenticazione. Quindi, se si vuole evitare questo comportamento, basta riscrivere la prima riga http_access come segue:

http_access deny !google_users google

Ora è l’acl google che “matches“, ed essendo una acl non legata all’identificazione, l’autorizzazione viene negata direttamente.

Problemi.

Sorgono nel caso in cui (sperimentato personalmente), si incorra nel cosiddetto authentication loop, ad esempio quando si voglia discriminare l’autorizzazione in base all’appartenenza degli utenti a specifici gruppi:

acl ldapgroup-allowed external LDAP_group PROXY_ALLOWED

http_access deny !ldapgroup-allowed
http_access allow all

Questo causa una continua richiesta di utente e password; nel caso si usi solo ntlm come meccanismo di identificazione, la cosa è ancora peggiore, dato che l’identificazione viene passata dal browser in modo trasparente. La soluzione è introdurre una acl statica di comodo, sempre vera, e inserirla come ultima della riga:

acl ldapgroup-allowed external LDAP_group PROXY_ALLOWED
acl dummy src 0.0.0.0/0.0.0.0

http_access deny !ldapgroup-allowed dummy
http_access allow all

WordPress Appliance - Powered by TurnKey Linux