Corsipiratati.com recensione. Corsipiratati.com è una truffa. Corsi Pirata

ATTENZIONE: Questo articolo è un deterrente agli acquisti di corsi pirata online date le truffe di cui sono state vittime molti utenti di cui abbiamo voluto riportare una testimonianza reale e ben documentata. L’articolo non viola alcun marchio e/o copyright.

Al giorno d’oggi sappiamo che ci sono corsi di formazione online davvero molto costosi e non sempre spesso il gioco vale la candela non potendo valutare anticipatamente la bontà delle informazioni.

Ho voluto pertanto testare a mio rischio e pericolo il servizio su Corsipiratati.com che propone una serie di corsi online copiati illegalmente da numerosi formatori italiani che operano nelle più svariate branche. Dall’informatica, al marketing, all’advertising, alla fiscalità.

Il vantaggio (se così possiamo chiamarlo) è che ad esempio si può scaricare un corso da 9000 euro a sole 150 euro, o un corso da 1000 euro a sole 90 euro. Un risparmio minimo di 10 volte tanto in alcuni casi, un risparmio davvero molto importante.

Tuttavia, il sito essendo per sua natura un sito pirata e illegale, rivendendo corsi appunto piratati e violando dunque il diritto d’autore, non ha nessuna intestazione visibile, non ha nessun recapito telefonico, ed è nascosto dietro un servizio di anonimizzazione dei dati Whois, nonchè è nascosto dietro CloudFlare che ne tutela l’esposizione dell’indirizzo IP del server su cui risiede l’Hosting.

Anche i pagamenti sono anonimi, essendo fatti tramite un Gateway di pagamento BitCoin che rende di fatto impossibile conoscere l’identità sia del mittente che del ricevente.

Dunque, qualsiasi acquisto si faccia su quel sito è un salto nel buio e si basa solo ed esclusivamente sulla serietà delle persone che effettuano una compravendita nella classica ottica dare / avere.

Non potrete appellarvi a nessuna legge, a nessuna autorità se qualcosa va storto e avrete perso inevitabilmente la somma corrisposta dato che questi siti sono gestiti da veri TRUFFATORI PROFESSIONISTI, nonchè CRIMINALI.

Ho deciso pertanto di testare questo servizio cercando un download di un Corso inerente alla formazione finanziaria ad un costo di 89€ invece delle 990€ originale.

Ho effettuato l’ordine ed il relativo pagamento con la relativa transazione BitCoin di cui do prova allegando lo storico Coinbase di seguito.

Da lì, una volta completato l’ordine il browser reindirizzava co un redirect verso un link Mega.nz che aprendosi mi metteva a disposizione l’intero corso suddiviso in capitoli come nel corso originale.

Per chi non lo sapesse MEGA è un servizio di cloud storage e condivisione di cui era ex-proprietario Kim Dotcom, il fondatore di MegaUpload e MegaVideo. Nasce come successore di MegaUpload, che il 19 gennaio 2012 è stato oscurato dal Dipartimento di Giustizia americano, ma si distingue da quest’ultimo sotto vari aspetti.

Innanzitutto, è strutturato come un hard disk online, in modo simile a Dropbox, che consente di avere uno spazio d’archiviazione iniziale gratuito, per poi estenderlo a pagamento, se lo si ritiene opportuno. In secondo luogo, sfrutta una tecnologia di crittografia end-to-end basata su codici denominati “keys” (chiavi), che dovrebbe rendere impossibile il tracciamento dei dati.

 

Ecco, dunque, quello che mi compariva appena loggato, il video corso suddiviso in capitoli ed ogni capitolo i diversi video già pronti da visualizzare o scaricare.

Peccato che, come potete vedere dalla schermata sopra nessun file, (ingrandimento di seguito) può essere scaricato in quanto c’è una Violazione dei termini del servizio TOS di Mega che comunque non permette di caricare file protetti da diritto d’autore (o almeno lo permette fino a quando non arrivano reclami e dunque lo cancellano).

Al dunque cosa faccio avendo pagato in BitCoin 89€? Ovviamente contatto l’assistenza lasciando un messaggio Mail causa loro assenza nella LiveChat, ma non ottengo alcuna risposta nel fine settimana. Penso sia “relativamente normale” e che forse sabato e domenica non lavorano e non presidiano le richieste.

Lunedì mattina dunque decido di rivisitare il sito e vedendo la Live Chat con l’operatore online, faccio presente il problema.

Ovvero, di aver acquistato e pagato questo corso in BitCoin dando come riferimento anche il numero d’ordine e la data. Mi dicono di aspettare che avrebbero verificato e mi linkano una url Mega che pensavo fosse nuova e dunque con del contenuto scaricabile.

A testimonianza della truffa voglio condividere anche il Link incriminato (ove non ci sono più file scaricabili) in modo che vi rendiate conto che sono dei veri truffatori:

https://mega.nz/folder/JaAEhDBQ#oBUOwZd7K13u7JKBubQNXw/folder/0DYRGQ4a

AGGIORNAMENTO 31 MARZO ORE 18:28: Probabilmente questi criminali stanno leggendo il mio articolo e hanno pensato bene di eliminare i contenuti dalla url MEGA precedentemente linkata. Ecco come si presenta ora.

Invece era la stessa identica di prima e quando paleso l’impossibilità di scaricare i contenuti in quanto l’account Mega era segnalato per violazione dei termini TOS e Copyright, mi invita a CAMBIARE CORSO.

Come se un corso valga un altro (secondo questo troglodita dietro la tastiera), e che magari avrei potuto barattare un corso in Ottimizzazione Fiscale con un corso in Facebook Advertising o altro.

Nossignore, non avevo queste necessità e pertanto ho chiesto gentilmente se avessi potuto ottenere un rimborso, senza rancore, in fondo sono problemi che possono capitare.

La risposta è che loro non offrono rimborsi, al che ho palesato che scrivo su blog e testate e che avrei lasciato una recensione negativa.

Nemmeno il tempo di premere invio e mi trovo bannato dalla loro Chat con il Widget che mi scompare dal sito, ma che ricontatterò linkando questo articolo a testimonianza della loro malafede e truffa davvero senza eguali.

Morale della favola: corsipiratati.com vende corsi pirata che in molti casi non sono in loro possesso e una volta incassato il pagamento anonimo in Bitcoin se ne guardano bene nel rimborsare qualora reclamiate l’impossibilità di scaricare ciò che avete comprato e pagato.

AGGIORNAMENTO AL 31 MARZO: Leggendo i commenti arrivati in questi giorni, sembra che sia prassi comune e frequente truffare i loro clienti, consegnando corsi non scaricabili, link corrotti o versioni completamente differenti da quello acquistato e che in tutti questi casi non facciano il rimborso ne si adoperino a risolvere il problema.

Recensione Corsi Pirata e mentalità truffaldina.

A prescindere dall’attività illecita che hanno messo in piedi in palese contravvenzione delle leggi sul Copyright e diritto d’autore, viene anche da chiedersi quanto siano sciocchi nel gestire la cosa con questo modus operandi. Verosimilmente, immaginiamo che per questo acquisto non in loro possesso, vista l’impossibilità di fornire il corso mi avessero rimborsato.

Un domani, ad esempio, avrei potuto essere interessato ad un corso sul Management, su Facebook Advertising, sull’investimento immobiliare e avrei acquistato sicuramente con facilità e sicurezza sapendo che verrei sicuramente rimborsato considerando il precedente. In questo caso invece, anche qualora fossi interessato a comprare qualsiasi altro corso di formazione, di sicuro non mi azzarderei mai a comprarlo da loro, visto che l’esperienza mi ha insegnato che: non hanno i corsi disponibili, non si preoccupano di rimborsare i pagamenti nel caso non riescano a consegnare il prodotto e dunque sono dei truffatori a tutti gli effetti.

Questo ragionamento non dovrei essere il solo a farlo in un’ottica “imprenditoriale” per quanto illegale possa essere il business. In ogni business illegale, infatti, al di sopra delle regole di diritto chiamate leggi, ci sono gli accordi tra le parti, che possono essere anche solo verbali, o anche una stretta di mano e basato principalmente sul buon senso e il dare / avere.

Non hanno lungimiranza e intelligenza nel capire che un cliente contento e soddisfatto torna e fa buon passa parola, un cliente non contento e insoddisfatto (in questo caso truffato). non solo non torna ne comprerà mai più nulla da loro, ma si impegnerà a scrivere questo articolo e posizionarlo sui motori di ricerca affinché nessuno corra il rischio di essere truffato dai venditori di Corsi Pirata.

E gli altri siti che vengono Corsi Pirata come IlmercatodiRobinHood, Corsi del Professore e simili? Recensione.

Abbiamo notato che in molti siti (quasi tutti quelli che si trovano cercando su Google) che vendono corsi piratati, illegalmente ci troviamo di fronte alle stesse impostazioni per ciò che concerne il layout grafico, le funzionalità, i widget e addirittura le descrizioni prodotti.

È facile dunque supporre con pacifica certezza che i siti siano riconducibili alla stessa organizzazione criminale, e che operino allo stesso identico modo, con la stessa politica sui rimborsi e sulla mancanza di serietà e professionalità.

Per sicurezza dopo un’attenta analisi abbiamo visto che i seguenti siti fanno riferimento alla stessa associazione criminale e dunque sono da evitare come la peste:

hxxps://corsipiraxxti.com/
hxxps://corsipixxta.co/
hxxps://corsipiraxxti.org/
hxxps://corsigratis.org/
hxxps://corsipiratati.it/
hxxps://corsipirata.download/
hxxps://corsipiratax.com/
hxxps://downloadcorxx.com/
hxxps://downloadcorxx.org/
hxxps://recensxxxx.me/
hxxps://ilxxxxxxxxxdirobinhood.io/
hxxps://coxxxhack.com/
hxxps://bigpirata.io/
hxxps://bigpirata.com/
hxxps://corsixxxcoin.com/
hxxps://scaxxxxcorsi.com/

Vale sempre il concetto spiegato inizialmente, un’attività online che non ha riferimenti legali, e si nasconde dietro servizi di anonimizzazione dei dati del WHOIS (oltretutto usano gli stessi registrar come NameCheap e lo stesso servizio di Whois Shield) nonchè dietro CloudFlare CDN è un’attività che a prescindere può permettersi il lusso di rimanere anonima e non dare alcuna garanzia. Se si pensa che queste attività rimangono celate persino agli occhi delle forze dell’ordine, e del fisco, figuriamoci quanto può importargli di fregarvi soldi e fuggire col malloppo.

[root@marcomarcoaldi ~]# whois corsipiratati.com
[Querying whois.verisign-grs.com]
[Redirected to whois.namecheap.com]
[Querying whois.namecheap.com]
[whois.namecheap.com]
Domain name: corsipiratati.com
Registry Domain ID: 2550735312_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.namecheap.com
Registrar URL: http://www.namecheap.com
Updated Date: 2021-07-05T06:07:18.16Z
Creation Date: 2020-08-04T10:16:43.00Z
Registrar Registration Expiration Date: 2022-08-04T10:16:43.00Z
Registrar: NAMECHEAP INC
Registrar IANA ID: 1068
Registrar Abuse Contact Email: abuse@namecheap.com
Registrar Abuse Contact Phone: +1.9854014545
Reseller: NAMECHEAP INC
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Registry Registrant ID:
Registrant Name: Redacted for Privacy
Registrant Organization: Privacy service provided by Withheld for Privacy ehf
Registrant Street: Kalkofnsvegur 2
Registrant City: Reykjavik
Registrant State/Province: Capital Region
Registrant Postal Code: 101
Registrant Country: IS
Registrant Phone: +354.4212434
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: 683830dc319a42f6967c65a1a55435c7.protect@withheldforprivacy.com
Registry Admin ID:

Sempre consigliato non comprare dunque da queste attività (definirle aziende sarebbe improprio), visto che alla fine avrete a che fare con persone senza scrupoli che mirano non nel fornire un servizio ma esclusivamente a rubare i vostri soldi.

Volevo condividere pertanto questa esperienza con voi mettendoci la faccia, ben sapendo della bassezza morale del mio operato e del tentativo di violare copyright dell’interessato. Un’esperienza pagata a mie spese che mi ha insegnato a non fidarmi di tutti questi siti che vendono corsi pirata.

Accertatevi sempre quando comprate un corso che la società sia seria, identificabile su territorio europeo con nomi e cognomi, numeri di telefono e pagamenti possibilmente tramite PayPal che vi garantiscono la protezione degli acquirenti.

Come ho fatto dunque a comprare il corso che mi interessava? L’ho trovato originale su corsi.it ed ho comprato il corso originale.

Wordstress, uno scanner di vulnerabilità WordPress scritto in Ruby e tutto italiano.

Wordstress. Cos’è ?

Wordstress è uno scanner di sicurezza whitebox per i siti web wordpress .

I proprietari dei siti WordPress non vogliono perdere tempo nella lettura di rapporti di scansione di sicurezza blackbox complessi cercando di rimuovere i falsi positivi .

Uno strumento di sicurezza utile deve dare loro solo le vulnerabilità che interessano davvero plugin o temi installati, eliminando dunque falsi positivi e rimanendo molto attendibili.

Per raggiungere questo obiettivo , il plugin wordstress deve essere installato e configurato con una chiave di accesso unica sul sito web di destinazione. Lo scanner wordstress userà la chiave per accedere alle informazioni fornite dal plugin per individuare problemi di sicurezza .

Wordstress utilizza API al database di problemi di sicurezza fornito da wpvulndb.com

La pagina ufficiale del plugin la si può trovare qui : https://wordpress.org/plugins/wordstress/

L’autore, Paolo Perego, classe 1976 Milanese, può essere seguito e contattato su http://armoredcode.com/thesp0nge/ , specializzato in application security e sicurezza del Web è sicuramente indicato per gli interessati al settore.

 

TROVATE BACKDOOR IN DIVERSI ROUTER DI CISCO, LINKSYS, NETGEAR E BELKIN

RouterUn ricercatore francese ha trovato una backdoor attiva in molti router Wireless commercializzati anche in Italia.

Sta facendo molto discutere quando dichiarato dall’ex tecnico della CIA Edward Snowden al giornalista Glenn Greenwald, indicando che in molti router e server prodotti da Dell, Cisco, Samsung, Western Digital, Seagate, Maxtor ecc sono presenti delle backdoor richieste ai produttori dalla NSA (National Security Agency). Se per molti erano solo ipotesi, arriva la conferma da Eloi Vanderbeken, uno sviluppatore / ricercatore francese, che ha rilevato una Backdoor in diversi modelli di router Wireless.

A causa di una dimenticanza della password di amministrazione del proprio router, il ricercatore francese ha deciso di studiare per bene il proprio router fino ad arrivare ad una strana backdoor che consentiva da remoto di inviare senza alcuna autenticazione.
Segnalata la scoperta, alcuni sviluppatori hanno iniziato a controllare i propri router verificando che la backdoor è presente anche in molti router prodotti da Cisco, Watchguard, Belkin, Linkys e Netgear ecc rilasciando anche una lista aggiornata che possiamo consultare da questa pagina.

A quanto pare attualmente ci sono più di 2.500 modelli di router che in omaggio ci regalano una bellissima backdoor, e parliamo solo di router, è possibile che ci siano anche “porte nascoste” anche in server, smartphone, tablet ecc. Tengo a precisare che la scoperta delle backdoor nei router risale da diversi mesi, personalmente ne sono venuto a conoscenza solo poche ore fa grazie alla segnalazione di un nostro lettore.
C’è da preoccuparsi??

Incapsula, la nota CDN e Firewall ci svela i suoi progetti per il futuro.

incapsula-cdn-waf-expansion-plans-mapCome leggiamo dalla loro newsletter appena giunta per email, Incapsula la una nota CDN con funzioni di WAF (Web Application Firewall) e DDOS mitigation, già recensita QUI, ha dei seri piani per il futuro prossimo.

Dopo la recente acquisizione da parte di Imperva, (azienda leader nel settore Data protection e IT Security) infatti ha annunciato con notevole entusiasmo che aumenteranno datacenter e banda a disposizione fino a raggiungere cifre davvero considerevoli.

Ecco cosa scrivono su : http://www.incapsula.com/blog/cdn-expansion-plans-map.html

Incapsula e i 30 datacenter per la fine dell’anno.

E ‘ bello essere in grado di unire una organizzazione che si muove veloce come Incapsula. Oggi voglio discutere di questo slancio, condividendo i nostri piani di espansione della rete per il 2014.

Con il primo trimestre dietro di noi, e con tre nuovi datacenter già attivi, siamo entusiasti di annunciare il nostro impegno a raddoppiare le dimensioni della rete di Incapsula – espansione da 16 a 30 punti di presenza (POP) entro la fine dell’anno.

Con questi nuovi data center ci aspettiamo la capacità di rete complessiva di Incapsula di oltre 1,5 Tbp/s. Inoltre, ciascun POP di Incapsula sarà configurato per memorizzare nella cache ben 30 volte più della sua capacità attuale con l’aggiunta di una nuovi switch con una maggiore densità di porte.

Località dei nuovi Datacenter

Le posizioni dei nostri data center in arrivo sono stati accuratamente scelti per la connettività di rete ottimizzata e per la loro capacità di riflettere le reali esigenze dei nostri clienti, dunque aumentare la presenza della rete in regioni ad alta richiesta, oltre a fornire una copertura in nuove posizioni geografiche.

Ecco l’elenco di tutti i POP candidati nel loro ordine alfabetico:

Atlanta, USA
Auckland, Nuova Zelanda
Lima, Perù
Hong Kong, Cina
Madrid, Spagna
Milano, Italia
Città del Messico, Messico
Mumbai, India
Sao Paulo, Brasile
Seoul, Corea del Sud
Toronto, Canada
Vienna, Austria
Varsavia, Polonia

Anche mentre parliamo, alcuni di questi luoghi sono già in fase di implementazione iniziale, e pochi sono a pochi passi di distanza dall’attivazione ufficiale.  E’ anche possibile che una posizione di alcuni dei luoghi si sposterà, a seconda della disponibilità di risorse di rete locale.

Questo è come la nostra rete sarà simile entro la fine dell’anno:

global-cdn-expansion-map

2013 ottima annata ma solo un “riscaldamento”

Nel 2013 il numero di siti protetti da Incapsula è cresciuto di oltre il 600 per cento. Oggi, Incapsula è la piattaforma di Application Delivery scelta per decine di migliaia di organizzazioni, tra cui alcuni dei più grandi marchi del mondo di elettronica di consumo, rivenditori online, istituzioni finanziarie e società SaaS di spicco.

L’anno scorso, per accogliere la nostra crescita, siamo cresciuti la nostra capacità di rete a oltre 600Gbps, espandendolo di oltre il 500 per cento. Abbiamo anche introdotto una serie di importanti aggiornamenti di servizi, tra cui statistiche in tempo reale, nuovi controlli Cache , un sistema integrato di autenticazione a due fattori e una sfilza di altre caratteristiche.

Quest’anno continuiamo ad espandere la nostra lista di servizi, così come le nostre capacità di networking. Nel primo trimestre del 2014 abbiamo già aumentata capacità di sicurezza del Incapsula con le nostre nuove regole di firewalling per il nostro motore di filtering. Più di recente, abbiamo ampliato la nostra offerta con il nostro Layer 7 Load Balancer – primi a fornirlo  nel suo genere come soluzione di high avalaibility per i nostri clienti Enterprise.

WAF, Web Application Firewall e Proxy per mitigare attacchi DDoS

La nostra espansione della rete rapida non è solo alimentata dalla propria crescita di Incapsula, ma anche dalla crescita di attacchi DDoS volumetrici. Dall’inizio del 2013, abbiamo assistito ad un aumento senza precedenti del numero di grandi minacce DDoS al punto in cui uno ogni tre attacchi all’ora raggiunge oltre 20 Gbps e DDOS da oltre 100 Gbps non sono più rari.

Con diversi grandi DDoS  che si verificano su una base quotidiana, e con sempre più siti web in cerca di Incapsula per la protezione, sapevamo che era il momento di investire; non solo per la necessità di oggi, ma anche per gli obiettivi di domani.

DREAMSNET.IT e Incapsula. Servizi di consulenza e protezione DDOS

Come azienda abbiamo valutato, analizzato e già trattato le varie CDN che il mercato offre, rilevando in Incapsula attualmente la migliore soluzione per il Firewalling a livello di applicazioni Web, nonchè come protezione DDOS per utenti commerciali vittime di attacchi DDOS di notevole portata.

Effettiamo consulenza di DDOS Mitigation, nonchè configurazione e installazione di Incapsula come elemento vitale per la disponibilità dei servizi.

Usare Google Spreadsheet per sferrare un DDOS verso qualsiasi sito web.

google-docs-logowtitleGoogle utilizza il suo crawler FeedFetcher per il caching di tutto ciò che viene messo all’interno = image (“link”) in un foglio di calcolo.

Ad esempio:

Se mettiamo = image (“http://example.com/image.jpg”) in una delle celle di Google Spreadsheet, Google invierà il crawler FeedFetcher per recuperare l’immagine e salvarla nella cache per visualizzarla.

Tuttavia, si può aggiungere parametro di richiesta casuale al nome del file e dire a FeedFetcher di caricare lo stesso file più volte.

Si potrebbe caricare in un foglio di calcolo di Google Spreadsheet un link a un file PDF (ad esempio di 10 Megabyte) per 1000 volte di seguito e “obbligare” il crawler di Google il recupero “forzato” dello stesso file ben 1000 volte di seguito, causando in questo modo un traffico davvero elevato.

=image("http://targetname/file.pdf?r=0")
=image("http://targetname/file.pdf?r=1")
=image("http://targetname/file.pdf?r=2")
=image("http://targetname/file.pdf?r=3")...
=image("http://targetname/file.pdf?r=1000")

Aggiungendo il parametro casuale, ogni link viene trattato come diverso da Google che esegue la scansione più volte causando una perdita di traffico in uscita per il proprietario del sito. Così chiunque utilizzi un browser, con l’apertura di poche schede sul suo PC può inviare enorme HTTP GET flood ad un server web.


Qui, l’attaccante non necessita di una grande larghezza di banda. L’attaccante chiede a Google di inserire il link dell’immagine nel foglio di calcolo, Google recupera 10 MB di dati dal server, ma dal momento che è un file PDF (file non-immagine), l’attaccante non prende e non visualizza nulla da Google. Questo tipo di flusso di traffico permette chiaramente una pericolosissima e grandissima amplificazione e può essere un vero e proprio disastro per il sito web vittima dell’attacco DDOS.


Utilizzando un solo computer portatile con più schede aperte e limitandosi a copiare ed incollare più link ad un file di 10 mb, Google è riuscito a scaricare lo stesso file a 700 + mbps. Questa 600-700 mbps scaricati da Google è continuato per 30-45 min. e a quel punto ho messo down il server.

Facendo correttamente i conti, sono stati scaricati oltre 240 GB di dati in appena 45 minuti.

google-spreadheet-ddos

Con solo un po’ di più carico, penso che l’uscita raggiungerebbe il Gbps e il traffico in entrata raggiungerebbe almeno 50-100 mbps. Posso solo immaginare i numeri quando più attaccanti utilizzeranno questo stratagemma. Google utilizza più indirizzi IP per eseguire la scansione e, anche potendo bloccare la User Agent FeedFetcher per evitare questi attacchi, la vittima dovrà modificare la configurazione del server e, in molti casi potrebbe essere troppo tardi se questo attacco non viene anticipato passando inosservato. L’attacco DDOS potrebbe essere facilmente prolungato per ore ed ore solo a causa della sua facilità d’uso.

 

Usare Facebook Notes per un DDOS ad un qualsiasi sito Web.

Facebook Notes consente agli utenti di inserire i tag img. Ogni volta che viene utilizzato un tag , Facebook carica l’immagine dal server esterno e memorizza nella cache. Facebook caricherà in cache l’immagine una volta però utilizzando i parametri get casuali (random)  la cache può essere by-passata e la funzione può essere abusata per causare un enorme HTTP GET flood.

I passaggi per ricreare il bug come riportato a Facebook Bug Bounty il 03 marzo 2014.

Passo 1. Creare un elenco di unico tag img come un tag è sottoposto a scansione solo una volta.

<img src=http://targetname/file?r=1></img><imgsrc=http://targetname/file?r=1></img>
..
<img src=http://targetname/file?r=1000></img>

Passo 2. Usa m.facebook.com per creare le note. Si tronca in silenzio le note ad una lunghezza fissa.

Passo 3. Creare più note dallo stesso utente o utente diverso. Ogni nota è ora responsabile per oltre 1000 richieste http.

Passo 4. Visualizza tutte le note allo stesso tempo. Il server di destinazione sarà vittima di migliaia di HTTP GET flood. Migliaia di richiesta GET vengono inviati a un singolo server in un paio di secondi. Oltre 100 sono il numero totale di server di Facebook che accederanno in parallelo.

Dopo aver scambiato qualche e-mail mi è stato chiesto di dimostrare se l’impatto sarebbe elevato. Ho sparato su un bersaglio virtualizzato in cloud, e utilizzando solo i browser da tre computer portatili sono stato in grado di raggiungere 400 + Mbps traffico in uscita per 2-3 ore. Numero di Facebook Servers: 127

facebook-ddosNaturalmente, l’impatto potrebbe essere più di 400 Mbps come mi è stato solo utilizzando il browser per questo test ed è stato limitato dal numero di file caricabili del browser per ogni dominio. Ho creato uno script proof-of-concept che potrebbe causare impatto ancora maggiore.

Vedo anche un paio di altri problemi con questo tipo di abuso:

  • Uno scenario di traffico di amplificazione: quando l’immagine viene sostituito da un pdf o un video di dimensioni maggiori, Facebook dovrebbe caricare un file enorme, senza che l’utente si accorga di nulla.
  • Ogni nota supporta 1000 + collegamenti e blocchi di Facebook di un utente dopo la creazione di circa 100 Notes in un breve arco. Poiché non vi è alcun captcha per la creazione di note, tutto questo può essere automatizzato e un utente malintenzionato potrebbe facilmente preparare centinaia di note con più utenti fino al momento di attacco quando tutti loro viene visualizzato in una sola volta.

Anche se una sostenuta 400 Mbps potrebbe essere pericoloso, ho voluto provare per l’ultima volta per vedere se può effettivamente avere un impatto maggiore.
Per liberarsi dalle limitazione del browser ho utilizzato lo script ad hoc e sono stato in grado di ottenere ~ 900 Mbps. traffico in uscita.

facebook-ddos-1gbps

Stavo usando un normale file PDF di 13 MB che è stato prelevato da Facebook + 180.000 volte, il numero di server di Facebook coinvolti era 112 .

Possiamo vedere il grafico del traffico è quasi costante a 895 Mbps. Questo potrebbe essere a causa del traffico massimo imposto sulla mia VM, che sta usando una porta ethernet Gbps condivisa. Sembra che non vi è alcuna restrizione mettere sui server di Facebook e con così tanti server  possiamo solo immaginare quanto traffico si possa ottenere.

La combinazione di Google e Facebook, sembra che possiamo facilmente ottenere più Gbps di Flood GET.

Facebook crawler si mostra come facebookexternalhit. In questo momento sembra che non c’è altra scelta che quella di bloccarlo per evitare questo fastidio.

 

WordPress XMLRPC, più di 162.000 siti WordPress utilizzati per attacco DDOS

ddosGli attacchi DDOS stanno diventando una tendenza comune ultimamente, ed è una questione molto seria per ogni proprietario del sito. Oggi vi voglio parlare di un grande attacco DDOS che ha sfruttato migliaia di siti web WordPress ignari come vettori di amplificazione.

Qualsiasi sito WordPress con Pingback abilitato (che è attivata per impostazione predefinita) può essere utilizzato in attacchi DDOS contro altri siti.  Notare che XMLRPC viene utilizzato per pingbacks, trackback, l’accesso remoto tramite dispositivi mobili e molte altre caratteristiche è molto probabile che sia abilitato. Ma può anche essere pesantemente abusato come quello che stiamo vedendo.

I fatti

E ‘successo tutto nei confronti di un sito WordPress popolare che era andato giù per molte ore a causa di un DDOS. Poiché l’attacco è aumentato in termini di dimensioni, il loro hoster l’ha spento, e poi hanno deciso di chiedere aiuto a un proxy di tipo Cloudflare.

Una volta che il DNS è stato ripristinato siamo stati in grado di vedere cosa stava succedendo, era un grande attacco flood basato su  HTTP (layer 7) , inviare ovvero centinaia di richieste al secondo al server. La richiesta sembrava questa:

 
74.86.132.186 - - [09/Mar/2014:11:05:27 -0400] "GET /?4137049=6431829 HTTP/1.0" 403 0 "-" "WordPress/3.8; http://www.mtbgearreview.com"
121.127.254.2 - - [09/Mar/2014:11:05:27 -0400] "GET /?4758117=5073922 HTTP/1.0" 403 0 "-" "WordPress/3.4.2; http://www.kschunvmo.com" 
217.160.253.21 - - [09/Mar/2014:11:05:27 -0400] "GET /?7190851=6824134 HTTP/1.0" 403 0 "-" "WordPress/3.8.1; http://www.intoxzone.fr" 
193.197.34.216 - - [09/Mar/2014:11:05:27 -0400] "GET /?3162504=9747583 HTTP/1.0" 403 0 "-" "WordPress/2.9.2; http://www.verwaltungmodern.de" 
..

Se notate, tutte le query avevano un valore casuale (come “? 4.137.049 = 643.182”), che aggirato la loro cache e forzare una pagina di ricarica completa ogni volta. Si stava uccidendo il loro server abbastanza rapidamente.

Ma la parte più interessante è che tutte le richieste provenivano da siti WordPress validi e legittimi. Sì, gli altri siti WordPress mandavano che le richieste casuali portando il sito down.

WordPress che ha XMLRPC abilitato = Very Large Botnet

Proprio nel corso di poche ore, oltre 162.000 diverse e legittime siti WordPress cercato di attaccare il suo sito.Avremmo probabilmente abbiamo rilevato molto di più siti, ma abbiamo deciso che avevamo visto abbastanza e bloccato le richieste al firewall di confine, soprattutto per evitare di riempire i registri con spazzatura.

Riuscite a vedere quanto potente può essere? Un attaccante può usare migliaia di siti WordPress popolari e puliti per svolgere il loro attacco DDOS, pur essendo nascosto nell’ombra, e che tutto accade con un semplice ping torna richiesta al file XML-RPC:

$ Curl-D - "www.anywordpresssite.com / xmlrpc.php"-d '<methodCall><methodName>pingback.ping</methodName><params><param><value><string>http://victim.com</string></value></param><param><value><string>www.anywordpresssite.com/postchosen</string></value></param></params></methodCall>'

Il tuo sito attaccando gli altri?

Potrebbe essere e non avete idea. Per verificare, guardare attraverso i registri di eventuali richieste POST al file XML-RPC, simile a quello qui sotto. Se vedi un pingback a un URL casuale, sai che il tuo sito è attuato in modo abusivo.

93.174.93.72 - [09/Mar/2014: 20:11:34 -0400] "POST / xmlrpc.php HTTP/1.0" 403 4034 "-" "-" "PostRequest: <xml version = \ x221.0 \ x22 encoding=\x22iso-8859-1\x22?>\x0A<methodCall>\x0A<methodName>pingback.ping</methodName>\x0A<params>\x0A  <param> \ x0A <valore> \ x0A <string> http://fastbet99.com/?1698491=8940641 </ string> \ x0A </ value> \ x0A </ param> \ x0A <param> \ x0A <valore > \ x0A <string> yoursite.com </ string> \ x0A </ value> \ x0A </ param> \ x0A </ params> \ x0A </ methodCall> \ x0A "
 
 94.102.63.238 - [09/Mar/2014: 23:21:01 -0400] "POST / xmlrpc.php HTTP/1.0" 403 4034 "-" "-" "PostRequest:   \ X0A   \ X0A   pingback.ping   \ X0A   \ X0A   \ X0A   \ X0A   http://www.guttercleanerlondon.co.uk/?7964015=3863899   \ X0A   \ X0A   \ X0A   \ X0A   \ X0A   yoursite.com   \ X0A   \ X0A   \ X0A   \ X0A   \ X0A "

Per interrompere il vostro sito WordPress da uso improprio, è necessario disattivare la funzionalità XML-RPC (pingback) sul tuo sito.

Un modo migliore per bloccarlo è quello di aggiungere al file functions.php del tema attuale, aggiungendo il seguente filtro:

add_filter( ‘xmlrpc_methods’, function( $methods ) {
unset( $methods[‘pingback.ping’] );
return $methods;
} );

Provatelo e fare la vostra parte per rendere Internet un luogo più sicuro per tutti.

CloudFlare vs Incapsula vs ModSecurity. Analisi comparativa su quale scegliere e perchè.

Tutti amano le comparazioni non è vero? Ancora di più se a confronto ci sono CloudFlare vs Incapsula vs ModSecurity, 3 nomi che conosci sicuramente, messi a dura prova da Zero Science Lab, un team di ricercatori macedoni, attivi nel campo della sicurezza informatica e della ricerca di vulnerabilità all’interno dei software. Se hai sempre desiderato una comparazione tra CloudFlare, Incapsula e ModSecurity è arrivato il momento di leggere con attenzione questo post.

CloudFlare, Incapsula e ModSecurity sono tre prodotti completamente differenti. Dico quasi perchè visto dall’esterno ModSecurity ad esempio non ha nulla da spartire con CloudFlare ed Incapsula, data la sua natura di WAF puro. Cos’è un WAF? La nocciola non c’entra nulla, e neanche i wafer. Un WAF è un acronimo che sta per Web Application Firewall, un software che ha il compito di fare Virtual Patching. Quanti paroloni! Ma cercherò di rendere la cosa più semplice anche per i novizi.

WAF e Virtual Patching

Hai presente le patch? Le pezze, quelle che devi applicare ad un software di tanto in tanto. Ci sono patch per WordPress, ci sono patch per Joomla. Le patch chiudono dei buchi, delle debolezze del codice che possono essere sfruttate per danneggiare un sito web. Il patching classico prevede che il produttore rilasci un aggiornamento del codice che tu dovrai applicare sul tuo sito web. Non sempre questi aggiornamenti però vengono rilasciati con tempestività. Dalla scoperta di una vulnerabilità fino al rilascio della patch potrebbero passare svariate settimane, se non mesi. Questo a causa delle tempistiche che ha ogni rilascio del codice. Oppure in quel momento potresti trovarti nella situazione di non poter aggiornare il sito perchè il codice è troppo personalizzato e rischieresti di rompere qualcosa. Il virtual patching invece permette di mettere una “pezza sulla pezza”. Il virtual patching è una patch virtuale che può essere applicata ad uno strato diverso da quello su cui vive il codice.

ModSecurity è un firewall per applicazioni web che opera a livello HTTP e fa un lavoro di patching virtuale, bloccando le minacce prima che raggiungano il codice vulnerabile.

In tutto questo CloudFlare e Incapsula si differenziano da ModSecurity perchè oltre alla funzione di WAF includono anche e soprattutto delle funzioni per velocizzare i siti web che fanno uso di essi. Si parla e si scrive veramente tanto di CloudFlare e Incapsula ma i dati ed i vantaggi reali sono ancora abbastanza nebulosi e si va quasi sempre per sentito dire. Zero Science Lab ha voluto fare un pò di luce sull’efficacia e sull’utilità di CloudFlare, Incapsula e ModSecurity svelando alcuni dettagli che ti lasceranno sicuramente molto sorpreso. Posso comunque anticiparti che CloudFlare esce come sconfitto illustre nel confronto con Incapsula e ModSecurity.

Zero Science Lab ha messo a confronto i piani più costosi: la versione Business di CloudFlare (200 dollari al mese!), la versione Business di Incapsula (59 dollari al mese). ModSecurity invece è free, distribuito gratuitamente. L’azienda che lo sviluppa, TrustWave Lab offre comunque delle regole commerciali a pagamento. Le regole sono in parole povere lo scheletro di funzionamento di ModSecurity. Per ogni minaccia esiste una regola che se fatta scattare blocca l’attacco. Un insieme di regole gratuite sono liberamente disponibili per il download.

CloudFlare vs Incapsula vs ModSecurity: l’installazione

Nel report di Zero Science Lab il confronto tra i prodotti inizia con una panoramica sulle modalità di installazione.
Posso dirti che sia Incapsula, sia CloudFlare non richiedono un intervento fisico sul server, nè sul sito web. L’attivazione di questi prodotti avviene quasi esclusivamente via browser. L’azione richiesta è la modifica dei record DNS ed NS del sito web che stai per proteggere, in modalità leggermente differenti per Incapsula e CloudFlare, ma abbastanza simili.

L’installazione di ModSecurity richiede invece un intervento fisico sul server all’interno del quale deve essere attivato. L’ultima installazione di cui mi sono occupato ad esempio è stata per un cliente con grossi problemi su Joomla. Tra vecchie versioni e l’impossibilità di aggiornare in tempi brevi l’unica alternativa tra deface e problemi continui è stata quella di installare ModSecurity.
Il setup di Mod Security non è alla portata di tutti e richiede delle competenze specifiche, soprattutto nella gestione delle regole. Un WAF configurato male è quasi come non averlo mai installato.

CloudFlare vs Incapsula vs ModSecurity:  l’efficacia

Qui iniziano le vere sorprese. Credo che un’immagine in questo caso possa valere più di mille considerazioni:

cloudflare-incapsula-modsecurity

Efficacia di CloudFlare come WAF : QUASI NULLA
Efficacia di Mod Security come WAF: OTTIMA
Efficacia di Incapsula come WAF: OTTIMA

Veniamo ai numeri.

Su 54 iniezioni SQL CloudFlare ne blocca 0. Incapsula ne blocca 53, ModSecurity ne blocca 54.
Su 46 attacchi XSS CloudFlare ne blocca 0. Incapsula ne blocca 43, ModSecurity ne blocca 46.
Su 23 attacchi LFI/RFI CloudFlare ne blocca 0. Incapsula ne blocca 19, ModSecurity ne blocca 21.

I numeri parlano da soli ! Zero Science dice a riguardo che “Though CloudFlare is presented as, besides other things, a very proficient web application firewall, we concluded that’s just a marketing sales point and nothing more“. Nonostante CloudFlare venga presentato tra le altre cose come un buon WAF, nella realtà si tratta solo di una trovata pubblicitaria e nient’altro.

Tra l’altro per quanto riguarda gli attacchi di test andati a buon fine a causa di alcuni difetti nelle regole anti intrusione, sia ModSecurity che Incapsula hanno risposto prontamente rilasciando degli aggiustamenti al codice delle rules. Nessun commento invece (almeno così mi sembra) da parte di CloudFlare.

Ci tengo a ribadire che CloudFlare, Incapsula e ModSecurity sono tre software molto diversi l’uno dall’altro. La principale caratteristica in comune è la funzione di WAF, web application firewall. A giudicare dai risultati del confronto ModSecurity non ha rivali.
CloudFlare e Incapsula si distinguono rispetto a ModSecurity per le funzionalità avanzate di acceleratore per siti web e di protezione contro gli attacchi DoS e DDOS. Nel confronto questi aspetti specifici non sono stati presi in considerazione ma posso assicurarti che per quanto riguarda l’accelerazione dei siti web sia Incapsula che CloudFlare svolgono un ottimo lavoro. Per quanto riguarda la capacità di difesa contro gli attacchi DoS l’efficacia è buona. Ti ricordo inoltre che Mod Security non ha compiti di accelerazione web, nè funzioni di difesa contro i DoS e DDOS.

CloudFlare vs Incapsula vs ModSecurity: configurazione ed opzioni

Incapsula offre una gestione più approfondita rispetto a CloudFlare mentre Mod Security non ha un pannello di controllo. Per quest’ultimo infatti la possibilità di intervenire sulle regole e sui registri è limitata alla sola interfaccia da console, via SSH (tranne ovviamente per le soluzioni a pagamento come ASL).

CloudFlare viene criticato dai più esperti per le scarse informazioni che il prodotto fornisce al cliente: poche info sulle minacce bloccate. Forse alla luce di questo pentesting risulta un pò più chiaro il perchè.

Incapsula invece offre buone possibilità di controllo delle regole di sicurezza, notifiche per le allerte di attacco ed uno storico dettagliato.

CloudFlare vs Incapsula vs ModSecurity: il responso

Il responso di questo pentesting vede fallire clamorosamente CloudFlare, almeno sotto il punto di vista dell’application firewall.
Incapsula si difende bene ma per scelta della compagnia le regole che dovrebbero bloccare gli attacchi sono volutamente non troppo aggressive per poter bilanciare la sicurezza con l’usabilità. Uno dei problemi maggiori dei WAF infatti sono i falsi positivi. Quei blocchi cioè che fermano anche le richieste HTTP lecite. ModSecurity sotto questo punto di vista è abbastanza aggressivo e questo forse è il suo unico difetto.

Conclusioni

E’ veramente molto difficile comparare. E chiunque potrà sollevare un’eccezione appellandosi al fatto che non è possibile mettere a confronto dei prodotti che sono molto differenti l’uno dall’altro. In questo caso però credo che il lavoro di Zero Science sia stato encomiabile, se non altro perchè sono state messe in luce delle (presunte) gravi carenze su un prodotto come CloudFlare che fa dell’application firewall uno dei suoi cavalli di battaglia. Le risposte al come ed al se queste mancanze siano reali o meno viene a mio parere proprio dal fatto che sia Incapsula sia ModSecurity hanno preparato degli aggiustamenti per quelle regole di sicurezza che durante il pentesting non hanno funzionato. Sarebbe stato interessante conoscere la replica di CloudFlare al whitepaper di Zero Science.

Per il momento alla luce delle analisi di Zero Science la realtà è una sola: se stai cercando un WAF non scegliere CloudFlare.

Riferimenti: CloudFlare Versus Incapsula Versus ModSecurity:

http://packetstormsecurity.com/files/120407/wafreport2013.pdf

Come implementare e configurare correttamente le DNSBL (o RBL) sul nostro server di posta onde evitare falsi positivi.

spam_dnsbl_rmiozioneUno dei problemi maggiori da sempre riguardo il servizio email è lo SPAM.

Negli svariati anni sono state ideate diverse soluzioni (più o meno efficaci) per arginare il problema, tutte con i relativi pro e i relativi contro.
Ciò che si cerca di raggiungere è l’identificazione ed eliminazione dello SPAM totale, avendo cura di non eliminare nemmeno una mail legittima (o considerata tale).

Ovviamente bilanciare l’obiettivo risulta estremamente complesso, nell’ottica che cestinare una mail legittima, sia ben più grave che lasciar passare 2 email di SPAM.

Per questo, è bene tenere sempre a mente che non si possono scegliere soluzioni drastiche, ma sopratutto che la sicurezza è un processo e non un prodotto.

Ovvero, non ci si può affidare solamente di un software specifico, ma bisogna coordinare diverse tecnologie che lavorino in sinergia tra loro.

Noi ad esempio nel nostro stack antispam utilizziamo :

  • Postgrey
  • SPF
  • Amavisd
  • Clamd
  • Spamassassin
  • RBL (configurate su Spamassassin)
  • Pyzor

e possiamo vantarci di avere un ottimo rapporto SPAM ricevuto / fasi positivi, laddove i falsi positivi sono praticamente nulli, e lo SPAM ridotto al minimo (nella caselle info@dreamsnet.it ieri ne ho ricevute 3).

Da anni che lavoro nel settore, come sistemista e amministratore di server mail, posso fermamente affermare che un mailserver che non riceve nemmeno una mail di SPAM saltuariamente è un mailserver che filtra troppo (anche quello che non dovrebbe filtrare).

Una delle configurazioni più classiche (ed errate) che ho trovato implementate in diversi server mail (anche di importanti società di hosting e internet service provider) è quella di implementare RBL a livello assoluto direttamente sul mail server.

Cos’è RBL ?

Una DNS-based Blackhole List (anche DNSBL, Real-time Blackhole List o RBL) è un mezzo attraverso il quale è possibile pubblicare una lista di indirizzi IP, in un apposito formato facilmente “interrogabile” tramite la rete Internet. Come suggerisce il nome, il meccanismo di funzionamento è basato sul DNS (Domain Name System).
Le DNSBL sono principalmente utilizzate per la pubblicazione di indirizzi IP legati in qualche modo a spammer. La maggior parte dei mail server possono essere configurati per rifiutare o contrassegnare messaggi inviati da host presenti in una o più liste.
Questi servizi offerti gratuitamente agli utenti e sistemisti di tutto il mondo, permettono realmente di decimare l’invio di SPAM, nonchè la ricezione, contribuendo a una funzione realmente utile all’utente finale.

spamhaus_dnsbl_basic

 

Brevemente funziona così :

  1. Il mail server del mittente ci invia una mail.
  2. Il mailserver del destinatario (il nostro) farà una richiesta di tipo DNS a una delle liste DNSBL che abbiamo implementato.
  3. La lista DNSBL ci risponderà che è in blacklist o che non lo è.
  4. Se lo è rifiutamo di accettare il messaggio segnalando con un errore e informando il nostro mittente che è presente in una lista antispam.
  5. Se non è in SPAM accettiamo il messaggio.

 

Fino a qui tutto bene, sembra una meraviglia. Si potrebbe tranquillamente dire che si può eliminare lo SPAM alla frontiera, senza accettare il messaggio e dunque risparmiando preziose risorse sul mailserver.

Una meraviglia in effetti se non fosse che bisogna mettere in discussione la precisione della tecnologia RBL, e del suo insindacabile giudizio.

Come avrebbe detto un famoso conduttore televisivo : “La domanda nasce spontanea !”, ovvero :

Essere segnalati in una lista RBL significa che siamo veramente degli SPAMMER ?

La risposta è NO.

Vediamo ad esempio alcuni scenari per cui noi legittimi mittenti e non spammer ci vediamo ritrovati in una blacklist, e il nostro fidato e amico destinatario vedrà rifiutarsi la consegna del messaggio a causa della configurazione errata del suo mail server.

  1. Sono col dominio dominiotizio.it e sullo stesso mailserver (con lo stesso IP) ci sono ospitati altri 500 domini per un totale di 2500 caselle email gestite.
    Una casella email viene violata, e nel giro di un ora uno spammer riesce a consegnare 10000 email a indirizzi email random sui classici yahoo.com.
    L’amministratore se ne accorge, limita il danno disabilitando l’account … ma nel frattempo viene inserito in dnsbl.sorbs.net (una nota ed usatissima RBL).
    Da li in poi per diverse ore (anche giorni), l’IP del mail server risulterà come SPAMMER.
  2. Gli stessi presupposti dello scenario 1, con la differenza che siamo finiti in altre liste (questa volta a pagamento). Come riportato qui https://www.dreamsnet.it/2013/06/mailserver-blacklist-dnsbl-e-spam-uscire-dalle-liste-e-vivere-serenamente/ a volte per rimuoversi da liste RBL in tempi accettabili (poche ore), alcune liste pretendono un pagamento variabile tra 40 e 100 dollari per effettuare la rimozione dell’indirizzo “nell’immediato”.Nessun amministratore di server mail accetterà mai di cedere a tale spesa (o meglio ricatto), per cui è possibile che invece di essere in liste DNSBL per qualche ora o giorno, possiate rimanerci per 7 giorni fino alla rimozione automatica.
  3. Siamo sempre listati nelle liste di SPAM. Basti pensare e molti provider italiani, Libero.it su tutti, ma anche i vari Telecom e Fastweb che col loro alto numero di utenti e di mail server sono spessissimo (Libero lo è quasi sempre) listato in una o pià liste RBL.

 

In tutti e 3 i casi ci troviamo di fronte a situazioni in cui sebbene la mail venga inviata da un mailserver possa essere in liste antispam perchè precedentemente (o anche attualmente) usato da spammer, il contenuto della mail e la mail stessa risulta legittima e gradita, dunque non SPAM.

Arrivare a conclusioni del tipo “sei in una lista antispam per cui sei uno spammer, allora non accetto la mail” non ha senso in un contesto reale dove la mail diventa uno strumento di lavoro e la non ricezione può comportare gravissimi problemi.

Tornando all’introduzione precedente, oggi molti amministratori di sistema implementano i filtri direttamente sul mailserver in questo modo (esempio su mailserver postfix) :

reject_rbl_client zen.spamhaus.org,
reject_rbl_client list.dsbl.org,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client bl.spamcop.net,
permit

 

Ciò significa che il nostro mailserver rifiuterà di accettare il messaggio se l’IP del mailserver del mittente è listato in una delle 4 liste elencate. E sia ben chiaro, che per essere rifiutato basterà che sia presente in ALMENO UNA DELLE 4.

Approccio completamente assurdo e sbagliato. Nel caso in cui le liste fossero ipoteticamente 20 (teoricamente possibile, in pratica ne vengono configurate 3 o 4 normalmente), essere presente in 1 sola su 20 dovrebbe essere sinonimo di “essere in regola”, in questo caso invece 1 su 20, o su 100 significa essere SPAMMER.

Ciò è errato. Profondamente errato.

Il sistema RBL deve essere uno strumento in più, non l’unico atto a discriminare la bontà o meno di una mail. Deve indicare, ma non provare. Deve essere testimone e non giudice. Deve fornire prove, ma non emettere sentenze.

Ecco perchè un uso sensato delle RBL è quello di toglierlo immediatamente dai file di configurazione di postfix (o del vostro mailserver) e di utilizzarlo insieme ad un filtro bayesano come Spamassassin e poi eventualmente eliminato da Amavis.

Un filtro bayesiano (dal nome del noto matematico Bayes vissuto nel XVIII secolo) è una forma di filtraggio dello spam che si basa sull’analisi del contenuto delle email. Questa tecnica è complementare (e di grande efficacia) ai sistemi di blocco basati su indirizzo IP, le cosiddette blacklist.
Il filtro bayesiano applica all’analisi delle email un teorema, espresso per l’appunto da Bayes, secondo il quale ogni evento cui è attribuita una probabilità è valutabile in base all’analisi degli eventi già verificatisi. Nel caso dell’analisi antispam, se in un numero n delle mail analizzate in precedenza l’utente ha marcato come spam quelle che contenevano la parola “sesso”, il filtro ne dedurrà che la presenza di quella parola innalza la probabilità che le mail seguenti contenenti quella parola siano a loro volta spam.
In questo modo, il sistema è in grado di adattarsi in maniera dinamica e veloce alle nuove tipologie di spam.

Brevemente ora funzionerebbe così :

  1. Mi mandano una mail
  2. La accetto
  3. Faccio il controllo sull’IP del mittente. Se presente nella prima lista aggiungo 1 al punteggio
  4. Faccio il controllo sull’IP del mittente. Se presente nella seconda lista aggiungo 1 al punteggio
  5. Faccio il controllo sull’IP del mittente. Se presente nella terza lista aggiungo 1 al punteggio
  6. Faccio il controllo sull’IP del mittente. Se presente nella quarta lista aggiungo 1 al punteggio
  7. Faccio gli altri controlli Bayesani sull’oggetto, sul contenuto … e per ogni violazione aggiungo un punteggio specifico.Se alla fine di tutti i controlli di SPAMASSASSIN il punteggio finale della Email è 5, significa che questa mail è SPAM, altrimenti è legittima e la consegno.

 

Facile capire che una mail legittima, pur essendo in ben 4 liste antispam (a livello di IP) verrà comunque consegnata, come è altrettanto facile capire che una mail che non è presente in nessuna blacklist ma viola innumerevoli regole a livello di contenuto, viene comunque non marcata come SPAM e dunque consegnata.

Abilitare RBL su SpamAssassin è questione di 1 minuto, basta infatti editare il file /etc/mail/spamassassin/local.cf e aggiungere :

skip_rbl_checks 1
rbl_timeout 3
score RCVD_IN_SORBS_DUL 1
score RCVD_IN_SORBS_WEB 1
score RCVD_IN_SORBS_SMTP 1
score RCVD_IN_SORBS_HTTP 1
score RCVD_IN_XBL 1

ed avere cura poi di settare il punteggio di “taglio” di amavisd a 5 … o 6 (per essere meno ferrei e un po’ più elastici).