ecarlesso.org

Introduzione Recentemente mi son trovato nella spiacevole situazione di dover tirare un server che facesse da filtraggio web (si parla di una scuola), cache web ed autenticazione utenti contro l’Active Directory di un server windows 2003. Inoltre si voleva che il comportamento del filtro variasse a discrezione dell’utente corrente.

La soluzione implementativa che ho trovato può essere schematizzata nella seguente maniera:

Tradotto, la richiesta dell’utente va Squid (Auth), il primo elemento della nostra catena. Questa istanza di squid (che non fa alcun tipo di caching) si occupa dell’autenticazione dell’utente. Per autenticarsi contro l’Active Directory di Windows (afaik) si può operare in due metodi, dopo svariate prove in entrambi i metodi sono riuscito nell’intento con il modulo squid_ldap_auth (che fa parte del pacchetto squid, anche se non quello di default di Archlinux), seguirò quindi questa linea in questo howto. Una volta che l’autenticazione va a buon fine, Squid (Auth) inoltertà la richiesta a DansGuardian, il nostro secondo agente, modificando adeguatamente l’header della richiesta permettendo a quest’ultimo di filtrare i contentuti in base al livello di permesso dell’utente.

Se sia l’autenticazione di Squid (Auth) sia il filtraggio utente di DansGuardian vanno a buon fine, la richiesta corrente viene girata al nostro terzo agente, ad una seconda istanza squid che chiameremo Squid (Cache), che semplicemente lavora come web-cache, decidendo se restituire gli oggetti richiesti dalla cache o prelevandoli direttamente da internet.

Vediamo passo passo come realizzare questa struttura.

Squid (Auth) Questo è decisamente il componente più delicato di tutta la faccenda. Questa configurazione prevede di avere tutti i browser della rete configurati con proxy esplicito. Squid resterà quindi in ascolto sulla porta 3128 per tutte le connessioni. Non farà cache, ha il solo compito di fare autenticazione. L’autenticazione avverà grazie al modulo squid_ldap_auth, che chiederà la conferma delle credenziali al server windows. Partiamo da questo punto nevralgico.

[Archlinux specific topic] Per quanto voglia mantenere le guide che scrivo il più distro-indipendent possibile, faccio un piccolo inciso per venire incontro a chi come me utilizza Archlinux. Di default il pacchetto squid per arch non include il modulo squid_ldap_auth. Sperando che questa cosa venga aggiunta in future versioni del pacchetto, ricompilarsi il pacchetto è una cosa banalissima… Sfruttiamo abs per questo. Come tutti, ovviamente sconsiglio di effettuare le seguenti opererazioni da root, quindi una volta installato il pacchetto abs date gli accessi a /var/abs al vostro utente!

1. pacman -S abs
2. chown -R /var/abs Siamo ora pronti a scaricare il sorgente del pacchetto e modificarcelo: /assets/2010/12/10/squid-dansguardian-squid.png

$ abs extra/squid $ cd /var/abs/extra/squid/ Modifichiamo il PKGBUILD modificando la riga che seleziona gli helper da utilizzare:

—enable-basic-auth-helpers=”getpwnam,YP,NCSA,SMB,MSNT,PAM,multi-domain-NTLM” \ deve diventare

—enable-basic-auth-helpers=”getpwnam,YP,NCSA,SMB,MSNT,PAM,multi-domain-NTLM,LDAP” \ Salviamo e chiudiamo e diamo un bel pkgbuild. Alla fine della procedura (un paio di minuti) ci troverremo il nostro pacchetto. Andiamo ad installarlo (da root, of course):

1. pacman -U /var/abs/extra/squid/squid-2.7.STABLE7-1-i686.pkg.tar.gz Finalmente ci troviamo in /usr/lib/squid il nostro bel squid_ldap_auth. [/Archlinux specific topic]

La comodità di questo modulino è che è invocabile direttamente da riga di comando per verificarne le funzionalità, senza dover ogni volta ritestare/assets/2010/12/10/squid-dansguardian-squid.png squid e faticare come matti a verificarsi i log.

Ora necessitiamo di un account sull’Active directory per poter fare le richieste di autenticazione. Chiameremo l’utente USERNAME con la password PASSWORD.

Da quanto ho capito ci sono decine di maniere diverse per poter scrivere questa riga, per arrivare alla configurazione corretta e funzionante (nel mio caso, tenete conto che non ho alcuna esperienza con server Windows e tanto meno con Active Directory) ho fatto (esattamente) 77 test diversi…

Per scoprire le nostre credenziali, nel server Windows avviamo ldp.exe. Connettiamoci al localhost:

Ora diamo un Connection -> Bind inserendo le credenziali dell’utente preposto alle richieste di autenticazione. L’ultima riga della finestra di log ci dirà: Authenticated as dn:’USERNAME’. Ora clicchiamo su Browse -> Search, ci si presentrà una maschera simile a questa:

Vedete il primo campo di input, il vostro sarà leggermente diverso, a discrezione della configurazione del vostro Active Directory. Beh, prendetene nota!

Facciamo un primo test e dal nostro server linux diamo, ovviamente sostituendo i campi scovati in precedenza (AD_ID è l’ip del server Windows):

1. /usr/lib/squid/squid_ldap_auth -v 3 -b “cn=Users,dc=aaa,dc=bbb,dc=ccc” -D “USERNAME@aaa.bbb.ccc” -w PASSWORD -f sAMAccountName=%s -h AD_IP

A questo punto il programma resterà in ascolto per ricevere username e password da riga di comando. Proviamo ad iniserire una coppia username/password di un utente del nostro AD separata da uno spazio. Se il programma ci risponde:

squid_ldap_auth: WARNING, could not bind to binddn ‘Invalid credentials’ ERR Success allora abbiamo sbagliato qualcosa, significa che il server LDAP di Windows non ci permette di autenticarci… Verificate di aver inserito correttamente username e password e che questi dati siano effettivamente nell’Active Directory.

Se invece il modulo ci risponde semplicemente

ERR Successl significa che ci siamo autenticati ma che USERNAME e PASSWORD vengono rigettatti. Se li inseriamo corretti invece ci verrà risposto OK.

Se riusciamo a farci restitutire OK per gli utenti esistenti abbiamo fatto il grosso del lavoro. Almeno nel mio caso è stata la parte più complicata del procedimento.

Ora che siamo “a posto” possiamo procedere con la configurazione di squid. Teniamo presente che necessitiamo di due istanze di squid che girano. Per fare questo (è sempre una delle possiblità, ovviamente) ho fatto una copia di /etc/squid in /etc/squid_cache, utilizzando il percorso originale per Squid (Auth) ed il secondo path per Squid (Cache). Questo ci porterà a modificare gli script per lanciare squid, ma ci torneremo in seguito.

Passiamo alla configurazione di Squid (Auth), andando ad editare /etc/squid/squid.conf. Vi riporto la mia configurazione commentata

1. squid.conf – Autenticazione ###################

1. Written by Enrico Carlesso
2. 29 December 2009 #
3. Questa è la porta sulla quale resterà in ascolto squid, ovvero la porta del server proxy da
4. configurare sui client (via AD)

http_port 3128

1. La direttiva ACL ci permette di definire delle liste. Definiamo la direttiva ip_acl per per gli ip che appartengono
2. alla rete da monitorare.
3. Volendo possiamo già qui stabilire degli ip da non filtrare, ma va oltre lo scopo di questo howto,
4. e un paio di altre liste.

acl ip_acl src 172.16.0.0/24 acl allhttp proto HTTP acl QUERY urlpath_regex cgi-bin \? acl all src all

1. Con questa direttiva potete inserire la mail dell’amministratore. Per questa configurazione la pagina che
2. presenta questa
3. informazione non verrà mail visualizzata, ma può essere comodo anche per chi eventualmente prenderà in
4. mano il file di configurazione in futuro.

cache_mgr quello@chevi.pare

1. Questa impostazione decide per quanto tempo mettere in riposo squid prima di spegnerlo una volta ricevuto
2. un SIGTERM o un SIGHUP. Il valore di default è 30 secondi, ma per testarlo attendere così tanto potrebbe
3. diventare troppo frustrante…

shutdown_lifetime 2 seconds

1. Qui diciamo a quanto vorremmo limitare l’utilizzo di memoria di questa istanza di squid

cache_mem 8 MB

1. Il nome da utilizzare negli nei messaggi di errore. Default al valore di gethostname()

visible_hostname Squid-server

1. Questa opzione specifica il comportamento di questo squid. Noi vogliamo inoltrare la nostra
2. richiesta a DansGuardian che sarà in ascolto sulla porta 8080, ma vogliamo anche che venga passato
3. l’username autenticato di modo che DG possa effettuare le dovute operazioni di filtraggio

cache_peer 127.0.0.1 parent 8080 0 no-query login=d

1. La dimensione massima dell’oggetto da cachare. Abbastanza inutile qui, non cachamo nulla…

maximum_object_size 10 MB

1. Le seguenti direttive specificano appunto la nostra volontà di non cachare le acl in oggeto.

no_cache deny QUERY no_cache deny allhttp no_cache deny ip_acl

1. Configurazioni più o meno standard. Ricordate di evitare conflitti con l’altra configurazione di squid!

cache_dir ufs /var/cache/squid 8 16 256 read-only cache_log /var/squid/logs/access_authenticate.log access_log /var/log/squid/access.log squid cache_store_log /var/squid/logs/store_authenticate.log pid_filename /var/run/squid_authenticate.pid

1. L’autenticazione! Ovvero la righetta di prima che abbiamo fatto funzionare!
2. Questa è una riga sola, è spezzata per questioni di layout!

auth_param basic program /usr/lib/squid/squid_ldap_auth -v 3 -b “cn=Users,dc=aaa,dc=bbb,dc=ccc” -D “USERNAME@aaa.bbb.ccc” -w PASSWORD -f sAMAccountName=%s -h AD_IP

1. Parametri specifici per questo tipo di autenticazione.
2. Numero di istanze da far girare (ps aux | grep ldap vi farà capire di cosa si parla)

auth_param basic children 10

1. Parte del messaggio da far apparire nella maschera di richiesta login

auth_param basic realm Einaudi Web Access Control

1. Validità delle credenziali. Un’ora scolastica dura 50 minuti, quindi :)

auth_param basic credentialsttl 50 minutes

1. Specifica una nuova acl per coloro che sono stati autenticati e ne garantisce l’accesso, perlomeno
2. fino a DansGuardian…

acl ldap-auth proxy_auth REQUIRED http_access allow ldap-auth #######################################################

Come avete visto l’”uscita” di squid è “agganciata” a Dansguardian, per il filtraggio contenuti, sulla porta specificata. Passiamo ora al nostro secondo elemento.

DansGuardian Dobbiamo configurare DansGuardian di modo che resti in ascolto sula porta 8080. Questo software non richiede particolari configurazioni complicate, eviterò quindi di postarvi tutto il file di configurazione lasciandovi il “dovere” di darci una letta. Ci focalizzeremo solo sulle modifiche caratterizzanti.

Normalmente il file di configurazione lo trovate in /etc/dansguardian/dansguardian.conf

1. dansguardian.conf – Parte ###################

1. La direttiva language specifica in che lingua volete vengano scritti i messaggi di
2. DansGuardian all’utente
3. Trovate la lista delle lingue in (normalmente) /usr/share/dansguardian/languages

language = ‘italian’

1. Per logfileformat invece specifichiamo il formato dei file di log. Se volete avere i log in
2. stile squid per poterveli poi elaborare con SARG dovete inserire 3

logfileformat = 3

1. Vogliamo che DansGuardian si limiti a rispondere alla richieste provenienti da
2. Squid (Auth), ovvero dalla macchina locale.
3. Otteniamo questo con l’opzione filterip, con filterport ne specifichiamo la porta

filterip = 127.0.0.1 filterport = 8080

1. Dobbiamo ora dire a dasnguardian come contattare Squid (Cache),
2. la cui configurazione vedremo in seguito.
3. Per ora decidiamo solo su che porta faremo girare la seconda istanza di squid, che deve essere
4. diversa dalla prima (ovviamente). In questo caso ho scelto 3138

proxyip = 127.0.0.1 proxyport = 3138

1. Veniamo ora alla configurazione dei gruppi. In questo esempio utilizzeremo 4 gruppi così tipizzati:
2. Gruppo 1: Ogni richiesta viene bloccata
3. Gruppo 2: DansGuardian effettuerà un filtraggio “pesante”
4. Gruppo 3: DansGuardian effettuerà un filtraggio più rilassato
5. Gruppo 4: Nessun filtraggio applicato
6. Per fare ciò dobbiamo anzitutto dire a DansGuardian quanti gruppi vogliamo:

filtergroup = 4

1. e specificare il path del file con le associazioni utente/gruppo:

filtergroupslist = ’/etc/dansguardian/filtergroupslist’

1. Per permettere a DansGuardian di intercettare gli utenti passati da Squid (Auth)
2. dobbiamo utilizzare un plugin per
3. l’autenticazione. Nel nostro caso va benissimo il proxy-basic.conf authplugin = ’/etc/dansguardian/authplugins/proxy-basic.conf’ #######################################################

Le restanti opzioni, al valore di default, vanno bene. A vostra discrezione ovviamente modificare quel che più vi aggrada.

Abbiamo quindi detto a DG che abbiamo quattro gruppi. Automaticamente le policy per i quattro gruppi saranno lette da: Filtro per il gruppo 1 => /etc/dansguardian/dansguardianf1.conf Filtro per il gruppo 2 => /etc/dansguardian/dansguardianf2.conf Filtro per il gruppo 3 => /etc/dansguardian/dansguardianf3.conf Filtro per il gruppo 4 => /etc/dansguardian/dansguardianf4.conf

Per filtrare adeguatamente i vari gruppi, ho creato quattro cartelle copia della directory /etc/dansguardian/lists rispettivamente in fg1, fg2, fg3 e fg4. All’interno di ogni file di configurazione modificate i vari path di modo che puntino ai file corretti, per chi usasse vim una cosa del genere porta al risultato desiderato: %s/\/lists\//\/fgX\/ ovviamente con al posto di fgX la directory relativa a quel gruppo.

E’ buona norma dare un nome ad ogni gruppo, per aver più chiarezza nei log, con la riga groupname =

Come avevamo detto vorremmo che il gruppo 1 venga sempre bloccato, mentre il gruppo 4 sempre autorizzato. Per fare questo il procedimento è molto semplice, nei due file di configurazione relativi cerchiamo la riga

groupmode = 1 Come potrete leggere nei commenti del file di configurazione, se lo impostiamo a 0 banneremo, quindi bloccheremo, le richieste da questo gruppo, impostandolo a 2 invece il traffico non verrà filtrato. Impostiamo relativamente il gruppo 1 ed il gruppo 4 nelle due maniere.

Gli altri due gruppi invece vanno filtrati con pesi diversi, e potete tenere diverse liste, per esempio di url bloccati, e diversi pesi per gli algoritmi sul contenuto per i due gruppi diversi. Per queste configurazioni leggetevi il file di configurazione del gruppo che è più che esplicativo, e ricordate che abbiamo copiato tutti i file banned e exception* in cartelle a parte, dovete quindi editarle in quella posizione.

Nel file di configurazione abbiamo specificato su che porta DansGuardian contattera il terzo componente di questa nostra catena di agenti, Squid (Cache). Tenendocela a mente, proseguiamo con la configurazione dell’ultimo demone.

Squid (Cache) Passiamo ora alla configurazione del web-cache. Questa è probabilmente la configurazione di squid più elementare. Accetta connessioni solo da localhost, ovvero dansguardian, ed ha un comportamento elementare (almeno uno!).

Non posto nemmeno il file di configurazione, praticamente va bene quello standard, teniamo solo presente che dobbiamo limitare le connessioni a localhost e cambiare la porta di default, cosa che io ho fatto così:

http_port 3138 acl localhost src 127.0.0.1/32 acl all src all http_access allow localhost http_access deny al Prestate attenzione poi a dove salvate la cache e la dimensione che volete darle.

A questo punto tutti i nostri elementi sono al loro posto! Non ci resta che fare una copia dello script di avvio di squid modificando il file di configurazione da seguire ( -f /etc/squid_cache/squid.conf in questo caso), avviare i tre programmi e verificarne la funzionalità.

A questo punto se date ps aux | grep -i squid_ldap_auth vedrete il numero di sottoprocessi generati da squid per l’autenticazione. Dovrebbero essere tanti quanti il numero indicato in auth_param basic children 10.

Spero che questa guida possa essere di aiuto, io ci ho messo svariati giorni per riuscire a mettere assieme tutti gli elementi che mi servono, ed ora son ben contento del risultato.