Plugin per bloccare spam e altro (progetto Honey Pot)

[linuxpac]

Da quando uso Joomla 1.5, ho sempre utilizzato con soddisfazione l'utilissimo plugin "HttpBL", di Michiel Bijland, che permette di bloccare una parte di attacchi (spam, harvester ecc.) basandosi sul cosiddetto "Project Honey Pot" (https://www.projecthoneypot.org/).

Purtroppo questo plugin mi risulta da tempo abbandonato dall'autore (non è nemmeno presente nella directory delle estensioni di Joomla) e allora ho tentato di convertirlo.
Pare che ora effettivamente giri anche in Joomla 2.5, ma - non conoscendo bene Joomla, dal punto di vista dello sviluppo delle sue estensioni, e avendo nozioni limitate di PHP - non sono ancora sicuro al 100% che tutto funzioni a dovere.

Per questo motivo, se qualcuno vuole sperimentarlo e magari sistemare le eventuali magagne, allego entrambe le versioni di questo plugin: quella originale, perfettamente funzionante su Joomla 1.5 (file plg_httpbl_latest_J1.5.zip), e quella da me modificata per Joomla 2.5 (file plg_httpbl_J2.5.zip).

Attendo eventuali pareri e, se vorrete, contributi.
Grazie e un saluto a tutti.

NOTA - Essendo, il mio, una sorte di esperimento da inesperto, declino ovviamente ogni responsabilità sul funzionamento di entrambe le versioni del plugin e invito a provarle su installazioni sperimentali di Joomla.

[allegato eliminato da un amministratore essendo vecchio più di un anno]

[mau_develop]

come bloccherebbe lo spam questo plugin?

M.

[linuxpac]

Forse non è del tutto esatto parlare di "blocco" dello spam, si può però dire che questo plugin lo prevenga.
Infatti, questa estensione è un'implementazione dell'API messa a disposizione dal "Project Honey Pot" (vedere anche qui: http://www.projecthoneypot.org/httpbl_api.php) che consente, quando viene aperta una pagina web, di interrogare il database del progetto (una sorta di "black list") dove sono catalogati indirizzi IP che sono risultati fonte di spam (spambot) e di raccolta degli indirizzi email (harvester) eventualmente elencati nel sito stesso (ma mi risulta vengano catalogati anche quelli che sono fonte di attacchi, generalmente basati su "dizionari", mirati a scoprire le credenziali d'accesso all'area riservata di un sito).
Gli IP sono anche valutati in termini di pericolosità e in base alla durata della stessa (il sito del progetto mette anche a disposizione svariati dettagli in merito).
Quando il plugin trova una corrispondenza tra l'IP di un visitatore e i dati contenuti nel database del progetto, l'ospite potenzialmente indesiderato (perché non sono infatti esclusi eventuali falsi allarmi) viene bloccato ed eventualmente dirottato su di una pagina alternativa, con avviso personalizzato, o su di un "honeypot" (cioè una pagina, appositamente creata attraverso un'utilità che si trova sul sito del progetto stesso, che permette al progetto di individuare anche nuovi IP "maligni"). Contemporaneamente, nella directory "log" di Joomla, viene popolato un file di log nominato httpbl.php, che può quindi essere scaricato, tramite FTP, per essere consultato.
Quindi, per utilizzare il plugin occorre essere iscritti al progetto (è completamente gratis) per ottenere l'apposita "key" necessaria all'API stessa per funzionare.

Personalmente sono almeno 2 anni che utilizzo questo plugin, anche su siti di clienti che hanno centinaia di visite giornaliere, e ho potuto riscontrare un effettivo calo sia di attacchi sia di spam, con migliaia di indirizzi IP "maligni" bloccati e pochissimi falsi positivi.

Per ulteriori informazioni, consiglio di visitare il sito del progetto (https://www.projecthoneypot.org/).

[mau_develop]

il progetto lo conosco, è anni che esiste, così come ne esistono tanti altri, basterebbe appoggiarsi a qualche blacklist ufficiale.
Credo valga molto per la raccolta di dati dai quali si può studiare come "interrompere" qualche catena di server ed è il lavoro che quotidianamente fa chi opera in qs settore.

Credo valga poco in termini di spam, ovvero su un sito non deve essere possibile inviare spam altrimenti c'è qualcosa che non va e su quello si interviene.
Lo spam dai moduli si previene con il token e il captcha che dalla 2.5 è diventato parte di Joomla per cui direi che è impossibile registrarsi con tools e inviare post e se invece viene fatto manualmente il discorso del blocco ip non vale più perchè passo da proxi.

Lo spam dalle mail è un po' più problematico perchè quelle le grabbi in vari modi.

Insomma, lo spam, se non è mirato a danneggiarti in qualche modo o eccessivo è endemico come la pubblicità nella cassetta della posta, gli unici che riescono a limitarlo sono quelli che hanno una portinaia "Human"; paragonato al mondo virtuale, come lo chiamano i giovani , è il lavoro di un webmaster o comunque una figura che gestisce QUOTIDIANAMENTE il sito se il sito è importante... altrimenti che mandino pure quello che vogliono. .... tutto imho... come sempre.

M.

M.

[linuxpac]

Sono sostanzialmente d'accordo con te, Mau_develop.
Ma, oltre a quel che giustamente hai detto, c'è comunque da considerare che il plugin aiuta molto anche a tener lontane una parte di quelle "macchine" che non sono solo spambot, ma che fanno parte di "botnet" atte a scovare e sfruttare eventuali vulnerabilità di un CMS per inserire codice maligno o effettuare altre operazioni illecite.
Considerate quindi le possibili "falle" di gioventù di Joomla 2.5 (confermate da svariati aggiornamenti recenti), ritengo questo plugin un ottimo aiuto aggiuntivo.

[mau_develop]

Una soluzione di sicurezza non può mai essere universale a meno che non si occupi chessò della correttezza dell'url inserito.

aiuta molto anche a tener lontane una parte di quelle "macchine"
--------------------------------------------------------------------------------------
questa è una cosa da valutare caso per caso. L'esempio topico è chi ha un sito di divulgazione o meglio (peggio) di scambio/commercio/frequentazione da paesi extraeuropei e soprattutto orientali o balcanici.

La situazione di quei server e relativi ip è talmente dinamica che ciò che fino a un mese fa era in una blacklist oggi potrebbe appartenere ad un prezioso potenziale utente.
Inoltre (mi è sempre parso di capire) quel "sistema" colleziona e quindi marchia come cattivi certi ip ma non li riabilita... per assurdo tra 10 anni possiede tutti gli ip esistenti.

Poi ribadisco il concetto che esistono i proxi proprio per evitare di essere riconosciuti da buoni e cattivi, e qs sono difficili da bloccare...

Un esempio è l'utilizzo di pandora o server simili, ma anche nel piccolo, avevo fatto un piccolo script di proxi e messo sul mio sito in una pagina riservata per dare la possibilità ad una mia amica di visitare dall'azienda ip che venivano bloccati.

botnet" atte a scovare e sfruttare eventuali vulnerabilità di un CMS
-------------------------------------------------------------------------------------------
no, non ce ne devono essere. Poi l'aggiornamento degli script di una botnet ha una latenza che ti permette abbondantemente di aggiornare la versione.
Poi le botnet lanciano un treno di request... un anti flood e stanno lì due giorni...

Considerate quindi le possibili "falle"
--------------------------------------------------
se consideri le possibili falle puoi anche considerare che ne hanno dieci volte tanto i servizi usati su un server e altrettante quelle dei browser.

M.

[linuxpac]

(...) Inoltre (mi è sempre parso di capire) quel "sistema" colleziona e quindi marchia come cattivi certi ip ma non li riabilita... per assurdo tra 10 anni possiede tutti gli ip esistenti. (...)

A me questa cosa non risulta, perché nel criterio di valutazione di pericolosità si considera anche da quanto tempo un indirizzo IP è una minaccia e da quanto tempo potrebbe non esserlo più. Vedi anche questo esempio: http://www.projecthoneypot.org/ip_41.203.64.253
Inoltre io stesso posso testimoniare che i "falsi positivi" sono un numero abbastanza limitato. Ecco perché ritengo serio questo sistema, oltre che un valido strumento (non è il solo, ovviamente) per aumentare la protezione di un sito. D'altra parte, se non lo fosse stato, il Project Honey Pot non sarebbe stato utilizzato anche per valutare la bontà di applicazioni di sicurezza come gli antivirus.

[mau_develop]

beh non te l'ho venduta come certezza poichè non avevo mai approfondito... adesso so una cosa in più.
Così come sto solamente discutendo, non pretendo di aver ragione...
Inoltre non ho nulla contro quel progetto che anch'io considero valido per tante cose ma non per un "universale sicurezza" dei siti.
Parto dal principio che la mia applicazione non deve essere vulnerabile e basta, poi se mi visita (come capita) un bot con malevoli intenzioni.. stà lì... prova... mi consuma un po' di banda che il mio hoster mi offre come me la occuperebbe col quel tool.
poi, ribadisco il concetto, la quasi totalità dei siti web sono su hosting condiviso quindi "fare sicurezza" è già un eufemismo

ma più in generale sono estremamente contrario a qualsiasi tool di sicurezza che non sia costruito ad hoc per una situazione, tranne quello di mmleoni perchè semplicemente fa un analisi di request non appropriate quindi può essere un buon filtro generale.

M.

[dipietro]

Salve ragazzi,
stavo leggendo questo vecchio post perché ho un problema e cercando sul forum mi sono imbattuto qui.
Ho un sito molto visitato che ultimamente è attaccato da malevoli ddos.
Il sito si pianta spesso e manda in pappa il server dove sta il mysql.
Ho la versione joomla 1.5.26.
Ho installato anche i firewall RSfirewall e JFirewall.
Mi bloccano vari indirizzi ip, ma lo stesso non riescono a proteggere il sito da visitatori malevoli che generano traffico in stile attacco ddos e mi piantano tutto.
Ogni volta devo creare un index.html, poi devo cancellare l'index.php, devo aspettare un po' di tempo e dopo una ventina di minuti tutto torna normale. Solo a situazione normalizzata, riporto tutto come prima.
Questa tarantella va avanti da 1 mese e il provider mi vuol cacciare perché gli mando in tilt uno dei server.
Un amico mi ha consigliato di spostare il sito intero in una sotto cartella /web/ e di lasciare nella root solo il file index.html con il bottone "accedi alsito" che rimanda a /web/index.php . e poi di proteggere il sito mediante htaccess, creare un files. htaccess che impedisca direttamente l'accesso in  visualizzazione a tutta la cartella creata che contiene il dominio  reindirizzando sempre alla pagina all'home page .HTML : solo chi preme  sul pulsante presente nella pagina HTML dovrà accedere alla  visualizzazione del dominio dentro la nuova cartella che avrà creato.
Stavo pensando: sarà una soluzione buona?
Voi avete della altre idee o alternative?
Non so, un software che blocca gli ip malevoli dopo 5 o 10 tentativi di connessione al sito in un minuto?
Questo progetto  http://www.projecthoneypot.org/ può essere tuile al mio caso?
Mi era venuta un'altra idea, tipo fare in modo che per accedere alle pagine del sito si deve per forza inserire un codice chaptca.
Ma sono nel buio più totale.
Potete aiutarmi?
Grazie.

[mau_develop]

Ho un sito molto visitato che ultimamente è attaccato da malevoli ddos.
---------------------------------------------------------------------------------------------
..?! ... esempio di un attacco ddos al sito?

Il sito si pianta spesso e manda in pappa il server dove sta il mysql.
-----------------------------------------------------------------------------------------
... semmai l'inverso....

Ho la versione joomla 1.5.26.
-------------------------------------------
quindi obsoleta

Questo progetto  http://www.projecthoneypot.org/ può essere tuile al mio caso?
-----------------------------------------------------------------------------------------------------------
sai cos'è un honeypot e qual'è la strategia o le strategie per cui viene usato un honeypot?
Se sei invaso dalle api l'ultima cosa da fare è metterti in casa un vasetto di miele

prima di pensare di mobilitare la nato prova a leggere l'articolo di Alex in "Notizie"

[dipietro]

Grazie per la replica.
Mi spiego meglio, ma non posso scendere nei dettagli per via di una indagine della PP in corso.
Il mio sito ha sempre registrato circa trentamila visitatori al giorno, con una media di mille o duemila visitatori anche simultaneamente.
Fin qui ci siamo, penso.
Nell'ultimo mese riceve degli attacchi Dos / Ddos, come confermato sia dal provider che mi ospita che dalle Aoturità preposte, le quali mi hanno contattato per informarmi della cosa e per invitarmi a sporgere anche denuncia al fine di indagare.
Cosa accade?
Utenti delinquenti utilizzano tecniche note per generare traffico da migliaia di IP (troll, spam, ecc) convogliandolo simultaneamente sul mio sito.
Questo cosa causa (lo scrivo non per te, ma casomai per altri lettori neofiti che dovessero leggere il post)?
Essendo Joomla in php, un traffico del genere sovraccarica il server che ospita il sito e quindi il sito stesso risulta inaccessibile e crea problemi anche al provider che mi ospita.
La versione di Joomla è aggiornata alla 1.5.26 ma è dotata anche di Jfirewall e di RSFirewall (lo dico per i neofiti) che sono software che si integrano nel sito e proteggono da molti attacchi (RSFirewall fa un buon lavoro anche contro gli attacchi Dos).
Il sito è stato completamente testa in locale, in provvisoria, con scansione di 2 antivirus a pagamento, e risulta pulito. Idem il Database.
Le eventuali vulenrabilità sono state corrette grazie all'uso di RSFirewall che ha un potente motore di scansione e di segnalazione di eventuali bug presenti.
Il sito è stato epurato di qualsiasi estensione vecchia o non più aggiornabile.
Stamane ho anche installato e configurato il plugin http://www.projecthoneypot.org/  consigliato da linuxpac (che ringrazio per l'ottima segnalazione).
Alla luce di quello che ho scritto, hai altri consigli?
Capisco quello che scrivi e capisco anche la battuta "non mobilitare la nato", però mettiti nei miei panni. Cosa faresti al posto mio?
Grazie.
 

[linuxpac]

...........................
Questo progetto  http://www.projecthoneypot.org/ può essere tuile al mio caso?
-----------------------------------------------------------------------------------------------------------
sai cos'è un honeypot e qual'è la strategia o le strategie per cui viene usato un honeypot?
Se sei invaso dalle api l'ultima cosa da fare è metterti in casa un vasetto di miele

prima di pensare di mobilitare la nato prova a leggere l'articolo di Alex in "Notizie"

Perdonami Mau_develop, non è per fare polemica, ma questa tua affermazione dimostra che non conosci affatto il progetto in questione. 
Infatti, i "vasetti di miele" del progetto si basano sull'inserimento all'interno di un sito di link nascosti che portano a pagine appositamente create (situate anche su domini diversi) attraverso gli strumenti che ti mette a disposizione il "Project Honey Pot". Questi link sono invisibili ai normali visitatori, ma vengono però inevitabilmente seguiti dai sistemi automatizzati che vengono utilizzati per gli attacchi di varia natura. In questo modo, l'IP attaccante viene tracciato e catalogato.
 

[mau_develop]

. In questo modo, l'IP attaccante viene tracciato e catalogato.
----------------------------------------------------------------------------------
bravo.... e ora mi spieghi cosa serve a uno che gli bloccano un servizio per le troppe query?
Se io invece di girare per i form gli chiamo 1000 volte l'hp ha lo stesso problema.
sei su un hosting condiviso tene fai nulla e non blocchi nessuno ne con honeypot ne con jail

Un bot non può nulla se usi un recaptcha e a livello applicazione è assurdo cercare di porre pezze che competono ad un sysadmin

[linuxpac]

Mau_develop, la mia risposta non era volta a dare una soluzione specifica alle "troppe query", ma serviva a chiarire che la tua precedente affermazione era fondamentalmente errata se riferita al progetto in questione.

Aggiungo comunque che i link di cui sopra sono "opzionali", nel senso che si può decidere anche di non inserirli nel proprio sito, ma sono consigliati proprio per contribuire al "progetto".
In ogni caso il plugin che ho segnalato funziona indipendentemente dall'inserimento degli stessi.

[mau_develop]

ma sono consigliati proprio per contribuire al "progetto"
---------------------------------------------------------------------------
allora, cerchiamo di chiarire una volta per tutte...
1) non ho nulla contro quel progetto che conosco da molto tempo...
2) per contribuire al progetto se vuoi il link lo metto anche nei miei siti...
4) Se lo ritrovo su webarchive (perchè il forum nn esiste più da parecchio) ti linko un articolo che avevo fatto anni fa sul progetto honeypot... così forse ti convinci che non sto facendo la guerra ne a te ne a qs progetto
3) i miei più che dubbi sono solo relativi alla risoluzione di qualsivoglia problema che può avere un user Joomla (visto che è l'argomento del forum) che è pari a 0 ...
4) Non c'è bisogno di profilare nulla. Perchè un normale user deve diventare per forza un esperto di sicurezza? L'articolo di Alex in "Notizie" spiega chiaramente cosa bisogna fare e ti assicuro che se segui quelle parole alla lettera gli unici problemi li può avere il tuo hosting (tranne nuove vuln)

[dipietro]

Potresti indicarmi il link dove trovo questo articolo di Alex in "Notizie"?
Sarà la stanchezza da lavoro ma non riesco a trovarlo.
Grazie.

[dipietro]

Questo:
 
http://www.joomla.it/notizie/6983-la-vera-sicurezza-per-il-tuo-sito-joomla-e-il-tuo-atteggiamento.html

[mau_develop]

yesss!  ... il problema è che la maggior parte delle cose andava fatta prima... ora, se non sei almeno uno smanettone, è difficile.
Se vuoi ti sintetizzo, ma non vado oltre visto che sono cose ampiamente spiegate in "sicurezza"

1) Devi essere sicuro di non avere la macchina infetta.
2) devi scaricare da ftp senza visitarlo con browser il tuo sito
3) Con un buon editor tipo netbeans, quanta etc devi vedere oltre il core cosa hai installato
4) scaricare un nuovo pacchetto stessa versione del compromesso e tutte le estensioni che ritrovi nel tuo sito
5) unzippare tutto e ricostruire due siti uguali
6) fare un compare dei files e vedere cosa sono i files in "avanzo"... potrebbero essere shell/backdoor
7) Usare il nuovo pacchetto o sovrascrivere con il nuovo sito/pacchetto quello vecchio
8 ) riallineare il configuration
9) testare in locale scaricando il db e quando funziona..
10) riaprire lo spazio con ftp e piallare tutto
11) riuppare tutto dopo aver aggiornato e risolto i probabili problemi in locale
12) buttare il vecchio sito scaricato

[linuxpac]

Mau_develop, i "link/vasetti" relativi al "Project Honey Pot" di fatto non costituiscono una "calamita" per le "api", come invece potrebbe sembrare leggendo la tua frase "Se sei invaso dalle api l'ultima cosa da fare è metterti in casa un vasetto di miele". Ecco perché ho ritenuto opportuno fare le dovute precisazioni.

Che poi il plugin da me segnalato non sia la soluzione a tutti i problemi, sono più che d'accordo.

Venendo alla questione sollevata da Dipietro, oltre ai preziosi consigli di Alexred e alle utili istruzioni di Mau_develop, posso solo suggerire di valutare (cosa che ancora non sono personalmente riuscito a fare) il componente "Admin Tools" (https://www.akeebabackup.com/products/admin-tools.html) le cui funzionalità di protezione sono però attivabili solo se si acquista la versione "Professional" (vedere anche qui: https://www.akeebabackup.com/products/46-software/860-admin-tools-core-vs-professional.html). Con questo componente non vi è la necessità del plugin che ho messo a disposizione su questo forum perché tale funzionalità è già presente tra quelle attivabili ("Integration with Project Honeypot's HTTP:BL..."). Allo stesso modo si dovrà accertare che non vi siano interferenze anche con gli altri componenti di protezione che si sono installati.

[mau_develop]

Confermo la mia affermazione.(*)
L'honeypot era concepito proprio come vasetto di miele, ovvero un facile abbocco per chi cercava servizi aperti su un server.
Se io ti faccio trovare un succulento servizio dietro una porta e ti simulo pure una probabile vulnerabilità tu butti un mare di tempo in quella cosa e mi lasci stare altro.
Funzionano anche come trappole nel senso che spesso non tutto reagisce come ti aspetti e finisci per farti loggare qualcosa senza più la possibilità di arrivare a cancellarla (Jail)
Quel projectHoneypot è un po' la stessa cosa che aveva fatto Raoul Chiesa con il suo profiling hackers nel lontano 2003, se cerchi ci sono anche parecchi studi e tesi sul quel progetto.
In fondo un vasetto di miele  lo puoi ottenere in mille modi, è un concetto abbastanza astratto per poter dire l"honeypot" è queto.... diciamo che è un mezzo informatico/software (no social) per attirare qualcuno/qualcosa... quello che poi ci fai, fatti tuoi

(*) cmq nel caso specifico non è nocivo

cmq, opinioni a parte, che fai tu per qs progetto? ... curiosità

[linuxpac]

Non sono del tutto d'accordo.
Se si vuole essere precisi, nello specifico caso del "Project Honey Pot" il vasetto di miele è un link ad una pagina che, tra l'altro, di attraente non ha proprio nulla, ma che contiene del codice PHP atto a raccogliere informazioni sull'IP che ha seguito quel link.
Link che, ribadisco, può essere seguito in pratica solo da sistemi automatici che comunque hanno l'attitudine ad inseguire tutti i link contenuti in un sito, alla ricerca di vulnerabilità.
Quindi non costituisce, di per sé, qualcosa atto ad attrarre più spambot sul sito che contiene questi link rispetto ad un altro che ne sia privo.

Relativamente alla tua domanda, personalmente - già da alcuni anni - semplicemente sfrutto e contemporaneamente contribuisco con link al progetto.

AGGIORNAMENTO
Scusami per quel "Non sono del tutto d'accordo", ma ho visto solo ora il tuo "asterisco" che conferma come il "vasetto di miele" di questo progetto sia - di fatto - innocuo.

[bertoandrea86]

Una cosa voglio precisare. I plugin di sicurezza di joomla bloccano gli ip e attacchi contro chi li effettua sul sito e pagine in joomla. Se vi è anche una sola pagina non joomla i plugin sono inutili, cosi come attacchi ddos. Quando si parla di ddos non può reggere nessun plugin joomla e non vi è una sicurezza. L'unica cosa è che sia il provider a filtrare gli ip e capire da dove vengano le richieste con il loro firewall. Al massimo si può bloccare degli ip con l htaccess, ma ovviamente si può fare poco e niente, perchè se si parla di centinaia o migliaia di ip che inviano dei ping di massa al proprio sito (ip), joomla può solo stare a guardare e subire.

[mau_develop]

non confondere un dos con un flood..

[bertoandrea86]

Che io sappia il DOS racchiude vari tipi di flood.
Che differenza c'è tra dos, ddos e flood?

[mau_develop]

il dos è prettamente rivolto a servizi della macchina quindi ad un sistema e non ad un'applicazione.
se il servizio attaccato è quello dove dietro c'è la tua app bene ma potrebbe non essere quello il servizio dossato.
Il risultato del dos è appunto la negazione del servizio o dei servizi, il server può crashare o no.
Può crashare o no perchè la negazione del servizio può essere decisa anche come politica dei thread rilasciati, finiti i thread.. finito il servizio.
Il dos non ha come esclusiva un treno immenso di richieste, velocità spaziali o chissà quali moltitudini di attacker alle spalle.
Prova a guardare come funziona slowloris, ... già dal nome non pare veloce ne particolarmente aggressivo... eppure ha dossato i server iraniani.

Il flood è invece è più genericamente un intasamento di richieste che solitamente non è volto al crash, anzi, tutt'altro.
Quando usi un tool di scansione facilmente avviene un flood.

Tornando al problema in oggetto.
Mi sembra assurdo usufruire di servizi che pongono limiti alle query o limiti orari di query... poi con joomla dove tutto sta nel db.... Hanno cercato di mettere pezze con il caching... ma non credo sia la soluzione.
Se fai semplicemente una sitemap... hai finito le query a metà del lavoro.
Sarà anche una scelta di sicurezza o solo commerciale, secondo me è stupida e basta... ti suicidi per non farti uccidere strana sicurezza.

riassumendo la risposta:

un dos è un attaccante che costringe il sistema a non essere più capace di rispondere e di offrire un servizio
un ddos sono più attaccanti per la stessa cosa
un dos o un ddos non sono necessariamente flood
un flood è un "treno di richieste" molto veloci, susseguenti e/o parallele

[bertoandrea86]

Thanks Mau, come sempre chiaro e preciso