12 mag
Posted by: Andrea Lanfranchi in: Mondo IT
Sappiamo tutti quanto stia diventando intrusiva la pubblicità che troviamo inserita a forza nelle pagine dei siti internet durante la normale navigazione. Ma se il singolo utente la considera più una seccatura (alla stregua della pubblicità che interrompe il programma televisivo preferito), per gli amministratori di rete diventa anche un problema tecnico: le pagine richieste dagli utenti della rete, con le loro continue inclusioni di banner, script ed immagini di varia natura, succhiano banda riducendo, per tutti, le risorse disponibili. Senza contare che, in genere, gli utenti, sapendo di essere protetti da un gateway aziendale, cliccano qua e là senza curarsi troppo della sicurezza e della miriade di informazioni di profilazione che vengono raccolte. Insomma, attivare una linea di difesa contro l’intrusione della pubblicità, aumenta non solo la sicurezza ma anche la velocità complessiva di navigazione.
Intendiamoci : non mi ritengo un integralista che ha deciso di abbattere il modello di revenue più diffuso sul web e, parimenti, sono convinto del fatto che per molte iniziative sia forse l’unico modello di sostentamento possibile. Ma certamente alcuni siti esagerano davvero esprimendo contenuti originali che, in rapporto alla pubblicità, stanno a 10Kb contro 200Kb o più. Animazioni, spesso ridondanti, pop-up automatici, immagini a tutto schermo ecc.
Esistono diversi motivi per approcciare la soluzione del problema: da quelli squisitamente personali (un esempio ne è l’eccellente AdBlock Plus per Mozilla Firefox) fino a sistemi di protezione a livello di gateway aziendale.
In questo articolo vedremo come configurare SQUID in modo che possa validamente aiutarci in questo scopo. Alla data di scrittura di questo documento ci occuperemo di come configurare Squid 2.6 su una distribuzione CentOS 5.4 (ovviamente do per scontato che già tutti i client della vostra rete possano navigare solo per il tramite del proxy).
Probabilmente già molti di voi sono a conoscenza del fatto che tra le moltissime direttive offerte dal file di configurazione di Squid è possibile impostare delle ACL (Access Control List) che, con opportuni filtri basati su espressioni regolari, ci consentono di creare dei divieti (deny) allo scaricamento di contenuti provenienti da specifici indirizzi (URL). Il rovescio della medaglia di questa tecnica è che, una volta individuate le origini dei contenuti da bloccare, chi naviga può vedersi comporre delle pagine con diversi riquadri che riportano informazioni di errore. Ed ecco che entra in gioco una eccellente caratteristica di Squid: la caratteristica di redirection delle richeste.
La redirection (o rewrite se preferite) utilizza uno script che dice a Squid di tenere d’occhio degli specifici indirizzi (URL) nelle richieste che riceve (per esempio ad.doubleclick.com). Quando un browser della rete inoltra una richiesta con questo URL a Squid, lo script reindirizza la richiesta ad un file locale, come ad esempio una immagine gif che contiene solo un pixel trasparente. E siccome questa richiesta in realtà non esce mai dalla rete locale, l’intera navigazione risulterà estremamente veloce oltre all’indubbio beneficio dato dal fatto che là dove ci si aspetta di trovare un bel banner animato, non vedremo (o meglio, gli utenti non vedranno) assolutamente nulla.
Ma come fare tutto questo ? E’ molto semplice … avete bisogno di tre cose :
Ecco come procedere all’installazione :
mkdir ~/squid.redir [Enter]wget http://taz.net.au/block/squid-redir.tar.gz [Enter]
tar -xzvf squid.redir.tar.gz [Enter]
closeme.html, do_nothing.js, dot.gif, gen.squid.redir, Makefile, README, redirrm -f gen.squid.redir [Enter]
wget http://www.anlan.com/upload/gen.squid.redir [Enter]
cp Makefile /usr/lib/squid
cp gen.squid.redir /usr/lib/squid
cp redir /usr/lib/squid
In pratica funziona così: squid riceve una richiesta da un browser della rete, passa la richiesta al programma di reindirizzamento che stiamo preparando, e quest’ultimo lo confronta con le espressioni regolari inserite. Se trova una corrispondenza ritornerà a squid l’URL “corretto” in modo che non venga inviata una richiesta ad internet ma solo una richiesta al web server per recuperare il file “fantasma”.
url_rewrite_program /usr/lib/squid/squid.redirOkay … ora provate a navigare utilizzando il vostro squid come proxy. Probabilmente non vi accorgerete di nessuna variazione nelle pagine web visitate. E’ molto probabile: infatti le regular expressions fornite come standard in questo redirector sono piuttosto obsolete e riferite in massima parte a procedure di advertising di server americani. Vi servirà un po’ di analisi del file access.log di squid per capire cosa dovete reindirizzare.
Un aiuto ? Bene … supponiamo di NON voler mai far scaricare ai browser dei nostri utenti di rete dei javascript che abbiamo individuato provenire sempre da http://www.qualcuno.com/scripts/pippo.js . Come fare ? Semplice :
La lotta allo spam è una lotta senza quartiere. Tutti contro tutti. E accade spesso che aziende serie vedono la loro posta finire regolarmente nello spam degli utenti a cui cercano di inviare comunicazioni email. Perchè ?
E’ presto detto: le mail che inviano queste aziende vengono inviate con mezzi di dubbia affidabilità.
Cercerò di spiegarmi meglio : tutti sanno che uno dei modi per filtrare lo spam è analizzare il contenuto del messaggio e filtrarlo in base a specifiche parole chiave. Per esempio è facile capire che si vorrà segnare come spam qualsiasi messaggio che contenga la parola “Cialis”. Combinazioni complesse di queste parole chiave, organizzate in veri e propri dizionari, concorrono a formare quello che si chiama un filtro bayesiano. Ma questo è solo un modo per tenere pulita la posta. I server che ricevono la posta fanno molti altri controlli ancora prima di leggere il contenuto del messaggio e, sulla base dell’esito positivo o negativo, marcano immediatamente come spam (oppure rifiutano direttamente) il messaggio ancora prima di sapere cosa c’è scritto dentro.
Uno di questi controlli è quello che verifica la validità del SPF ovvero Sender Policy Framework: si tratta di una serie di informazioni che il proprietario del dominio mittente, dovrà inserire nel proprio DNS, per informare i server destinatari, quali sono gli indirizzi ip o i server di posta che sono autorizzati ad inviare posta originata dal dominio in questione.
Per esempio : il dominio taldeitali.com (che genera posta nella forma nome@taldeitali.com) avrà sicuramente configurato, nel proprio DNS, uno o più record MX per la ricezione della posta. Ma se vuole anche informare i propri corrispondenti (o meglio i server che ricevono la posta dei corrispondenti) su quali siano i server di posta che inviano la posta con quel dominio, dovrà dotarsi anche, sempre nel DNS, di un record TXT di tipo SPF. Ovvero dovrà iscrivere una istruzione che, grossomodo, dice : “quando ricevete della posta da @taldeitali.com, se la ricevete da questo IP, o da questo, o da questo allora l’abbiamo proprio inviata noi, altrimenti l’ha mandata qualcun altro facendo finta di essere noi, quindi quasi al 100% è spam.”
La direttiva SPF risolve efficacemente uno dei grossi problemi della posta elettronica, ovvero l’attendibilità del mittente. Infatti quando si riceve una mail, siamo in grado di vedere l’indirizzo del mittente, ma non possiamo essere sicuri che effettivamente la mail sia stata scritta dalla persona che è effettivamente titolare di quell’indirizzo email. Tanto è vero che, spesso, vi arriva spam originato addirittura dal vostro indirizzo di posta: e mandarsi lo spam da soli … sarebbe sciocco.
L’implementazione di un record SPF è, a mio modo di vedere, ormai doverosa … se non addirittura obbligatoria, proprio per evitare che la propria posta in uscita (legittima) non venga bloccata dal server del destinatario e marchiata a fuoco come SPAM. E questa necessità è tanto più forte quanto più le aziende (o meglio i loro domini) utilizzano una molteplicità di server per la gestione della posta: per esempio nel caso in cui un server viene dedicato alla ricezione ed un altro all’invio.
Cosa succede se non implemento questo tipo di direttiva ? E’ molto semplice : il server ricevente che effettua controlli sul record SPF tenterà di attribuirvene uno in automatico secondo questa regola: la mail che si sta cercando di recapitare viene consegnata da un server che ha lo stesso indirizzo IP di uno o più dei record MX del dominio ? Se si … Ok. Se no … l’indirizzo IP che sta cercando di recapitare la mail è uno di quelli indicati nel record A del dominio ? Se si … Ok. Se no … Soft-Fail ovvero la mail non passa.
A valle del controllo SPF verranno poi effettuati altri controlli come ad esempio la validità di un record PTR … ma di questo dirò un’altra volta.
Per informazioni dettagliate sul record SPF e per crearne uno … visita www.openspf.org.
Nella mia carriera ho testato diverse soluzioni server per cercare, almeno, di ridurre sensibilmente il numero di email non richieste che quotidianamente intasano le nostre caselle email e quelle dei nostri clienti. E devo dire che tra tutte, molte delle quali a pagamento – anche molto care -, nessuna arriva alla efficacia ed alla flessibilità offerta da ASSP (Anti Spam SMTP Proxy) : una soluzione completamente open, gratuita, multipiattaforma e dalle non eccessive richieste di risorse. Il “core” dell’intera applicazione è un unico file Perl (1Mb in totale) che sfrutta diversi moduli standard dei repository Perl.
Non si tratta certamente, come nella più pura filosofia FOSS, di una applicazione Setup->Config->Run: per essere implementata a dovere richiede una discreta conoscenza di base, la capacità di sapersi barcamenare tra versioni di Perl diverse (o ActivePerl per chi ha intenzione di utilizzarlo su un server Windows), una buona conoscenza delle regole RFC per il protocollo SMTP (molte impostazioni fanno esplicito riferimento a regole RFC per la loro comprensione), una buona dimestichezza con le Regular Expressions e, infine una forte pianificazione di come gestire il flusso delle email in ingresso ed in uscita.
A parte tutto questo (che non è poco – la conoscenza di per se è un valore conquistato al costo di tante ore di studio e di prove), questo software apparentemente modesto racchiude gli strumenti di controllo contro lo SPAM più sofisticati e completi che abbia mai visto: tra tutti il classico filtro bayesiano è proprio l’ultima ruota del carro. Ed è giusto che sia così. Classificare lo SPAM in base al contenuto dei messaggi è molto poco efficiente: prima di tutto perchè il messaggio (o meglio dire le migliaia di messaggi) sono comunque stati ricevuti (al costo della vostra banda) ed in secondo luogo perchè l’efficacia dei filtri basati su parole chiave è sempre più spesso messa in crisi dalle tecniche degli spammatori che inseriscono volutamente nei loro messaggi combinazioni di parole che, a puro titolo di esempio, nulla hanno a che vedere con il Viagra, ma hanno il preciso intento di far diminuire lo score del messaggio per farlo apparire legittimo.
Ecco allora che con ASSP potrete facilmente rafforzare la vostra barriera di controllo ampliando lo spettro dei test più verso il mittente che verso il contenuto del messaggio. Controlli sulla presenza dell’IP mittente nelle più utilizzate blacklist, verifica dell’”insistenza” con cui un determinato IP cerca di connettersi, ban degli IP che tentano di consegnare posta a troppi indirizzi inesistenti, verifica delle forme corrette negli HELO, controllo sulla corretta sequenza degli header, degli ID di messaggio, verifiche dei record MX/A nei domini mittenti ecc. Il tutto sintetizzato in uno schema di punteggi a soglia, superata la quale, le connessioni da determinate sorgenti di SPAM vengono subito bloccate prima ancora di ricevere i primi dati. Ovviamente è sempre possibile integrare i controlli con whitelist ad apprendimento automatico e, infine, effettuare controlli bayesiani sul “corpus”.
Con impostazioni discretamente aggressive, su un server dedicato a questo scopo, dei circa 95mila tentativi di consegna di posta al giorno, ne blocchiamo sul nascere oltre il 94%. I benefici in termini di banda risparmiata sono notevoli: non solo limitiamo i consumi in ingresso, ma riduciamo anche quelli in uscita in quanto i clienti che scaricano la posta in POP si trovano un numero molto minore di dati da scaricare.
Ci si accorge presto tuttavia che non sono tutte rose e fiori : purtroppo anche moltissime email legittime non riescono a superare i ferrei controlli che il rispetto delle regole RFC imporrebbero. Improvvisati sistemisti configurano server di posta interni per piccole lan locali dimenticandosi di configurare in modo opportuno i DNS, di richiedere l’iscrizione di un corretto PTR, oppure abusano delle loro connessioni per mandare in giro newsletter, o lasciano i relay aperti (cosa che immediatamente li fa entrare nelle blacklist tipo spamhaus), o, ancora, utilizzano word come editor html dei messaggi per il loro Outlook (il che genera un tale casino nel testo del messaggio che è impossibile classificarlo come legittimo per parole chiave). E mille altri casi.
Alto quindi il rischio di perdere email importanti, inviate da emeriti ignoranti: anche qui, tuttavia, ASSP aiuta nella eliminazione di questo pericolo. L’iscrizione di determinati indirizzi (o interi domini) negli elenchi degli SPAMLOVERS permette di far comunque arrivare (opzionalmente taggati) tutti i messaggi a loro destinati, o, in alternativa, è possibile far generare ad ASSP un rapporto dettagliato delle email bloccate in modo che il proprietario della casella “protetta” possa richiedere l’iscrizione in white-list dei corrispondenti che gli interessano. In alcuni casi è anche possibile chiedere che venga forzato il recapito del messaggio bloccato.
Insomma, davvero un coltellino svizzero, che permette un fine-tuning delle vostre esigenze antispam a livello di server di posta.
L’ultima release stabile è la 1.5.1 ma da quello che vedo sul loro sito è in cantiere una beta della 2.0 che promette nuove caratteristiche tra cui il multithreading.
ASSP Rocks.
| L | M | M | G | V | S | D |
|---|---|---|---|---|---|---|
| « lug | ||||||
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | |||||