Archivio

Posts Tagged ‘squid 3’

SquidClamav – The Antivirus for your Squid Proxy Server

Ciao a tutti, di recente in una consulenza un cliente mi ha chiesto se fosse possibile integrare, utilizzando sempre Linux,  nel Proxy Server in produzione (che gli avevo tirato su un anno fa con Debian & Squid 3) anche un controllo antivirus sfruttando sempre prodotti open.Era la prima volta, dopo i tentativi passati che avevo fatto con HAVP, (con il quale ho avuto dei problemi lato performance), che provavo nuovamente ad integrare squid con una soluzione AV open.

Ho googlato un pò e sono capitato sulla home del progetto SquidClamav che è arrivato ormai alla release 6 e che sfrutta un server c-icap come backend per interfacciarsi con squid e con clamav.

Effettivamente c-icap mi aveva già dato soddisfazioni in passato, e quindi ho deciso di provare con un altro tentativo incrociando le dita. Bè che dire … semplice l’installazione, semplice la configurazione, e un buon risultato (lato scansione antivirus) con delle performance accettabili anche in ambiente di produzione. Devo dire che anche clamav che non seguivo più da un pò, vanta oggi un euristica non male e delle definizioni per il phishing ben fornite; ed essendo un antivirus nato per il mondo linux non è male come punto di pattenza. Vediamo insieme l’installazione e la configurazione.

Installiamo clamav in versione daemon e facciamogli fare un update delle definitions (altrimenti vi da errore)

apt-get install clamav-daemon

freshclam

Installiamo altri pacchetti per poter procedere alla compilazione e installazione di squidclamav

apt-get install gcc make curl libcurl4-gnutls-dev c-icap libicapapi-dev

Scarichiamo e installiamo squidclamav

wget http://ftp.jaist.ac.jp/pub/sourceforge/s/project/sq/squidclamav/squidclamav/6.2/squidclamav-6.2.tar.gz

tar zxvf squidclamav-6.2.tar.gz

cd squidclamav-6.2

./configure –with-c-icap  && make && make install

Ora modifichiamo i files di configurazione per personalizzare l’installazione e modifichiamo la riga 17 e inseriamo l’URL della pagina di errore personalizzata.

http://nome-server/error.html (qualora vogliate farvi una semplice html di errore personalizzata)
 
Rendiamo il server c-icap avviabile come daemon al bootup
nano /etc/default/c-icap
# alla riga 6: modificate

START= yes

Editiamo il file di configurazione del server c-icap
nano /etc/c-icap/c-icap.conf
# riga 142: inserite l’indirizzo mail dell’amministratore
ServerAdmin tua-mail@gmail.com
#Riga 151 – Modificate l’hostname
ServerName fg-av-ux01.fg.local
# riga 499:  aggiungete
Service squidclamav squidclamav.so
 
Riavviamo il server c-icap con il comando
/etc/init.d/c-icap start
 
Ora modifichiamo squid per rendere la modifica attiva e aggiungiamo le seguenti direttive
icap_enable on
icap_send_client_ip on
icap_send_client_username on
icap_client_username_header X-Authenticated-User
icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav
adaptation_access service_req allow all
icap_service service_resp respmod_precache bypass=1 icap://127.0.0.1:1344/squidclamav
adaptation_access service_resp allow all
 
Riavviamo ora Squid con il comando /etc/init.d/squid3 restart e godiamoci il nostro nuovo Proxy con Antivirus. Se volete testare il tutto potete visitare il sito EICAR e da lì  scaricare un file di test e verificare che il  corretto funzionamento di squidclamav come da screenshot seguente che vi allego.
 
error_01
 
 
Rimango a disposizione qui sul blog qualora abbiate qualcosa da chiedere.
Ciauz
 

Squid 3 LDAP Groups

Eccomi di nuovo qui …

Su spunto di alcuni colleghi, che mi hanno scritto in questi ultimi giorni in merito all’autenticazione LDAP su Squid 3 con un Domain Controller Active Directory, è nata un’interessante discussione sull’utilità di far autenticare sulle workstation joinate al dominio tutti gli utenti presenti in AD ma di far navigare solamente gli utenti abilitati.

Questa necessità nasce dal fatto che in alcune realtà, sempre per ragioni di sicurezza, si vuole comunque rendere la navigazione fruibile solo agli utenti con mansioni particolari.

Bè chi pensava che il fido e potente Squid 3 non potesse fare ciò si sbagliava!!!

Ecco come ho implementato la cosa sul proxy di un cliente :

auth_param basic program /usr/lib/squid3/squid_ldap_auth -v 3 -R -b “dc=RAV3N,dc=HOME” -D “cn=Admin,cn=Users,dc=RAV3N,dc=HOME” -w passwordSegreta -f sAMAccountName=%s -h xxx.xxx.xxx.xxx:389

Ovviamente per il significato di questo quote vi rimando al post precedente, dove spiegavo come interfacciare via LDAP Squid 3 con Active Directory. Con l’helper LDAP eseguiamo l’autenticazione del singolo utente, ma se vogliamo concedere la navigazione solo agli utenti appartenenti ad un singolo gruppo dobbiamo integrare questo helper con le  external ACL di Squid come segue :

external_acl_type gruppo_ldap %LOGIN /usr/lib/squid3/squid_ldap_group -v 3 -R -K -b “dc=RAV3N,dc=HOME” -D “cn=Admin,cn=Users,dc=RAV3N,dc=HOME” -w “PasswordSegreta” -f “(&(objectclass=person)(sAMAccountName=%v)(memberof=cn=%a,cn=Users,dc=RAV3N,dc=HOME))” -h xxx.xxx.xxx.xxx:389

Il significato di questa ACL è il seguente:

  • richiamiamo l’helper squid_ldap_group
  • -v 3 indica di utilizzare il protocollo LDAP versione 3, come specificato nel post precedente perchè è quello più compatibile con un Domain Controller Windows Server 2008 R2
  • -R indica di non seguire i referal all’interno della foresta Active Directory
  • -b Indica il percorso DN base in cui eseguire la ricerca; io qui ho specificato tutta la foresta Active Directory
  • -D Indica il DN dell’utente che utilizzeremo per fare il bind con il Domain Controller; ovvero un utente abilitato alla lettura degli oggetti e dei loro attributi presenti nella foresta active directory
  • -w indica la password per effettuare il bind associata all’utenza indicata nel parametro -D
  • -f indica la query da eseguire sulla foresta Active Directory
  • -h indica l’indirizzo IP del Domain Controller
  • :389 indica la porta su cui il DC è in ascolto per poter accettare il bind e la richiesta da parte di Squid

Adesso vediamo nello specifico il significato della query, che è la parte più importante di tutto il procedimento per poter eseguire questo tipo di autenticazione basata su gruppi :

  • (objectclass=person) – Indica di ricercare e di verificare l’0ggetto persona o meglio l’oggetto utente
  • (sAMAccountName=%v) – Indica di parsare l’username che  l’utente ha passato all’helper squid_ldap_auth e che è già stato autenticato con successo tramite Active Directory (praticamente il quote precedente al punto sAMAccountName=%s)
  • (memberof=cn=%a,cn=Users,dc=RAV3N,dc=HOME) – Indica di verificare che l’utenza presente nella variabile d’ambiente %v deve far parte del gruppo %a che specificheremo noi nell’ACL ad HOC che vi mostro dopo. Praticamente se l’utente, che è già stato autenticato dall’helper squid_ldap_auth (e messo nella variabile %v) appartiene al gruppo oppure ai gruppi richiamati dalla variabile %a allora la connessione verrà passata.

Adesso non ci resta che specificare un’ACL per ogni gruppo che vogliamo abilitare alla navigazione ad Internet

acl navigazione-limitata external gruppo_ldap limitati
acl navigazione-illimitata external gruppo_ldap illimitati

Il significato, molto semplice devo dire, è il seguente:

  • navigazione-limitata è il nome che diamo all’ACL del gruppo
  • gruppo_ldap è il nome dell’ACL external che parsa l’utenza e ne verifica l’appartenenza al gruppo su AD
  • limitati indica il nome esatto del gruppo presente in AD al quale suddetta utenza deve appartenere

Quindi per concludere ci basterà creare delle direttive http_access come segue:

acl ldap-auth proxy_auth REQUIRED

http_access allow navigazione-limitata ldap-auth

http_access allow navigazione-illimitata ldap-auth

http_access deny all

Dove il significato è il seguente:

  • acl ldap-auth proxy_auth REQUIRED – Indica di forzare l’autenticazione della connessione (via ldap semplice)
  • http_access allow navigazione-limitata ldap-auth – Indica di consentire la navigazione agli utenti verificati sia dall’ACL navigazione-limitata che dall’ACL ldap-auth (che esegue l’autenticazione semplice)
  • Idem per l’acl navigazione-illimitata ldap-auth
  • http_access deny all – Indica di negare l’accesso a tutto il resto

Ovviamente poi potete anche  giocare un pò con le altre direttive relative all’autenticazione per esempio :

auth_param basic children 2
auth_param basic realm Web-Proxy della Rete RAV3N.HOME
auth_param basic credentialsttl 10 minutes
authenticate_ip_ttl 60 seconds
auth_param basic casesensitive on

Il significato delle varie direttive è abbastanza semplice, ed è quanto segue:

  • auth_param basic children 2 – Indica quanti processi dell’helper squid_ldap_auth devono essere attivate da squid
  • auth_param basic realm – Indica il messaggio da sparare all’utente nel pop-up di autenticazione
  • auth_param basic credentialsttl 10 minutes – Indica per quanti minuti vengono cachate le credenziali da squid
  • authenticate_ip_ttl 60 seconds – Indica il TTL dell’autenticazione per singolo IP (Time To Live)
  • auth_param basic casesensitive on – Indica se l’helper deve essere case sensitive oppure no nel parsare i dati passati dall’utente

Poi le possibilità sono veramente tante, ma per questo vi rimando al wiki di squid che è ben fornito e ben fatto 😉

Ecco … spero di essere stato utile e soprattutto di aver aiutato qualcuno che magari si sta cimentando con squid per la prima volta. In qualsiasi caso se avete dei consigli oppure delle integrazioni commentate pure 😉

Ciauz

Squid 3 and LDAP Auth

Ciao a tutti,

scrivo questo breve articolo in merito ad un argomento di cui si è discusso molto su alcune Mailing lists e su alcuni forum negli ultimi mesi. Rifacendomi al whitepaper da me scritto e che trovate anche qui su questo blog, relativo alla multilayered network security, uno strumento molto importante e utilizzato relativamente allo strato perimetral security è dettato proprio dal proxy di rete.

Perchè il proxy vi chiederete? Bè questo strumento permette di discriminare la navigazione, obbligare la navigazione ad essere autenticata e non più “selvaggia”, aiuta a risparmiare banda e permette di impostare ACL utili ai network admin per contenere i costi relativi al calo di produttività e allo spreco inutile di risorse di bandwith; oltre a ridurre i rischi di sicurezza  derivanti dalla navigazione irresponsabile degli utenti.

Su quanto riguarda i metodi di autenticazione, uno strumento open e flessibile come squid 3 ha tantissimi helper che ci permettono di scegliere il metodo che più ci aggrada. Sicuramente in una realtà enterprise dove convivono sistemi Windows e Linux, e  magari dove cè pure una backend Active Directory sicuramente l’helper LDAP è quello più utilizzato in quanto l’autenticazione ntlm non è supportata da tutti i prodotti (chrome per esempio ha ancora dei problemi con l’autenticazione ntlm).

Per autenticare gli utenti via LDAP, utilizzando una distro come debian squeeze con installato squid 3, basta impostare un’ACL come segue :

auth_param basic program /usr/lib/squid3/squid_ldap_auth -v 3 -R -b “dc=RAV3N,dc=HOME” -D “cn=Admin,cn=Users,dc=RAV3N,dc=HOME” -w passwordSegreta -f sAMAccountName=%s -h xxx.xxx.xxx.xxx:389
auth_param basic children 5
auth_param basic realm Web-Proxy della Rete RAV3N.HOME

La prima riga richiama l’helper squid_ldap_auth, e ora vederemo il significato di ognuno di essi :

  • -v 3 >> Indica di utilizzare la versione 3 del protocollo LDAP (Questo perchè utilizzo un DC Windows Server 2008 R2 come backend Active Directory e quindi era l’opzione maggiormente compatibile
  • -R indica di non seguire tutti i referal all’interno della struttura Active Directory
  • -b specifica il DN base della query; in questo caso io ho specificato tutta la forest Active Directory
  • -D Specifica il DN dell’utente abilitato alla lettura e all’estrazione degli attributi degli oggetti presenti nel catalogo AD
  • -w passa la password di autenticazione al dominio dell’utente utilizzato nel parametro -D
  • -f passa la condizione di match, e in questo caso sAMAccountName=%s indica che qualora l’utente sia matchato  venga accettata l’autenticazione della connessione
  • -h indica l’indirizzo ip del domain controller oppure del server LDAP contenente il database degli utenti
  • :389 indica la porta di default sulla quale il nostro DC Windows è in ascolto per queste interrogazioni – ATTENZIONE LA PORTA 389 NON SUPPORTA LA CRITTOGRAFIA SSL/TLS DELLA CONNESSIONE
  • children 5 indica di mantenere attivi 5 processi da parte dell’helper usato da squid per l’autenticazione
  • realm indica il messaggio da sparare all’utente quando comparirà il popup che richiederà di autenticarsi

In questo modo, indifferentemente dalla UO in cui l’oggetto utente sarà allocato, se l’username esiste e la password matcha con il valore dell’attributo password dell’utente presente nella base LDAP la connessione verrà autenticata con successo

Poi per la forzatura dell’autenticazione, e la specifica direttiva http_access da associare vi rimando al wiki di squid che è veramente ben fatto e ben fornito. Spero che questo post possa venire in aiuto a qualcuno che si sta cimentando in questo ambito

Ciauz