Sapreste dirmi cosa vogliono?

[56francesco]

  nome a dominio /index.php?option=com_ckforms&controller=ckdata&view=ckformsdata&layout=detail&task=detail&fid=-1+union+select+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,32,33,group_concat(0x3C6B65793E,versi

nome di una pagina esitente//.//.//.html
(qui la serie di sbarrette si allunga con altri link quasi ad infinito)

oppure una chiamata ad un calendario per i giorni  dall'anteguerra ad infinito    (componente che c'era ma è stato cancellato)

trovato nel componente redirect 
mi chiedo ancora cosa vogliono e come difendersi da questi spammer  di m,   con joomla   (premesso che cambiano ip ogni minuto) 

ma se fosse ot ditelo che cerco altrove, mica la sicurezza deve essere un optional.

[mmleoni]

è un attacco di tipo sqli, ce ne sono a bizzeffe.

io uso questo:
http://extensions.joomla.org/extensions/access-a-security/site-security/site-protection/12731

ciao

[56francesco]

è un attacco di tipo sqli,

sarebbe a dire che chiamando url senza senso ma verosimili  ottengono una pagina 403 e in più sfruttando quasiasi compontente che registri gli url sbagliati vanno a far inserire delle righe nel database, giusto?
basta quindi disabilitare il plugin redirect e resta solo il disturbo delle miliaia di connessioni aperte da chiudere con un lavoro del firewall, giusto anche questo?
diversamente usando uno di quei plugin vado a scendere di livello e consumerà probabilmente molta ram e faccio schizzare il processore verso l'incandescenza con il rischio conseguente..

davvero non riesco a capire come risolvere senza  andare ad attivare un qualche servizio antiddos  come si deve, che operi a livello dns  perchè a scendere di livello, dal vps addirittura al sitarello  si aggrava tutto e non si risolve niente.

ok, questo è il massimo, giusto?

[56francesco]

giusto per la cronaca:

ho cambiato servizio DNS  con un altro,  ho cambiato il puntamento di  alcuni DNS di siti solamente ospitati e non attivi,  ho eliminato una decina di redirect,  ho bannato a livello vps  diversi ip anche cinesi, francesi, americani ecc...   
e il consumo osservato in un paio di giorni  di ram è diminuito da 1.2 giga circa a .6 giga circa
se continuasse  così proverò pure a riattivare il dominio che ho dovuto sospendere ora che ha un servizio dns spero migliore.
niente di voluminoso, intendiamoci,  ma per scoprirlo ho impiegato quasi un anno.

joomla in se non aiuta molto l'utente, anzi, da alcune versioni pare si sia scelto di stare dalla parte dei cattivi ed è peggiorato il supporto per l'utente e risparmio gli esempi, al contrario altri cms hanno funzioni di sicurezza molto migliori, ad esempio  da pannello gestione si visualizzano le intrusioni e si bannano senza forzo i relativi ip.   (ovvio si corre il rischio di bannare anche lo stesso google, occore prestare attenzione)

mi chiedo che interessi possano avere ad impiegare tante risorse per intasare la rete di monnezza,  sono evidentemente incidenti che presuppongono volumi di affari imponenti, basti pensare a quanti lamentano  che manca la banda larga,  se si eliminassero tutti questi spammer  monnezzai  chissà che  non bastasse ed avanzasse quella attuale?     

non sarà che la risposta alla mia stupidissima domanda sia di quelle che scoperchiano i pentononi di mafie e camorre varie?
secondo me si.
a presto, vi tengo aggiornati e spero di essere utile a qualcuno con lo stesso dilemma.

[jk4nik]

l'ottimo componente di marco, come molti altri,  operano in joomla e dunque anche se la vulnerabilità è già stata eliminata dal tuo sito, esegue una miriade di operazioni (ad ogni link ricevuto) prima di capire che è una minaccia, e anche quando lo ha capito comunque ti satura il vps, se invece operi dal .htaccess con un deny costruito ad arte risolvi i problemi di ddos su specifici componenti.

[56francesco]

e anche quando lo ha capito comunque ti satura il vps, se invece operi dal .htaccess con un deny costruito ad arte risolvi i problemi di ddos su specifici componenti.

Ciao, jk4nick

il problema è che ciascuno di quegli errori finisce oltre che nel database anche nei logs del vps e quindi i logs delle minacce serie si confondono tra giga e giga di dati e dati e milioni di righe.

c'è poi il problema del consumo di banda, di consumo di ram e di processore.
tutto ciò quei plugin non lo risolvono, semmai lo aggravano perchè aumenta il numero di processi da gestire, serviranno per altri non lo metto in dubbio, ma se si cominciano a trovare quelle righe nel redirect  le misure da adottare sono ben altre.

altrove ho scritto che non avrei mai risolto  (e non avrebbero mai risolto neanche gli altri che mi assistono)  SE  non avessi trovato una certa risposta sul forum di centos, 
la risposta era che i controlli vanno effettuati nei livelli superiori al vps e non con i firewall virtuali del vps,
e quali sarebbero i controlli superiori?  sono quelli a livello di dns e per far quello servono dei firewall fisici potenti, anzi potentissimi che non sono alla portata di tutti.
nel mio caso è stata sufficiente la mitigazione di default  (ma sempre con i dns del sito più attaccato che puntano altrove)  oltre a qualche altra correzione al vps e al pannello di gestione.

PS
aggiungo che casualmente ho trovato una pagina di una iniziativa americana che per il 20 settembre aveva organizzato una enorme iniziativa di protesta in rete, non ho letto che di sfuggita ma mi era parso  (non ne sono certo) che gli utenti usa protestavano contro l'inquinamento della rete,  e ma ripeto non ne sono certo si riferivano e si riferiscono proprio a questa tipologia di rumore, quindi la domanda resta, ma chi sono questi soggetti inutili oltre che nocivi? che vogliono?

[jk4nik]

ciao 56francescko,

giga e giga di log di un sito? ma che hai il sito della nasa? diminuisci i numeri sennò io faccio una strage (la sai la barzelletta no?)

secondo me ti stai facendo le seghe mentali e combatti contro i mulini a vento, poi ugnuno è libero di pensarla e fare quello che vuole...

[56francesco]

ho scritto altrove e lo ripeto.
che in soli due giorni  (1,5 per la precisione)  il file access.log  e il file error.logs del dominio forum-consulenza  pesavano rispettivamente  4 e 6 gica circa,  per un totale di quasi 10 giga.

oppure una chiamata ad un calendario per i giorni  dall'anteguerra ad infinito    (componente che c'era ma è stato cancellato)

PS
ciò le copie dei logs nel discone esterno, se ti va di diverti a leggerli te lo spedisco con il corriere

[tomtomeight]

Ma gli access log possono configurarsi per dimensioni e per numero, cioè li fai ruotare e non crescono più.

[56francesco]

Ma gli access log possono configurarsi per dimensioni e per numero, cioè li fai ruotare e non crescono più.

ovvio, soluzione valutata e scartata da un sysadmin che con tono indignato ha appena sussurrato:

i logs sono la bibbia, il vangelo e non si cancellano le sacre scritture

non so se è vero che sono sacri, ma a forza di cancellarli / limitarli   per anni mi sono trovato a dover buttare il nome a dominio meglio inserito nei motori di ricerca.

[mmleoni]

ho scritto altrove e lo ripeto.

anche io: ids + fail2ban
solo con il secondo i log sono al massimo di 10 righe, e con un
-s 1.2.3.4 -j DROP
in iptables vi assicuro che non ho mai visto andare giù un server...

[56francesco]

mmeloni  se avessi voluto bannare  i nove decimi pianeta  ed impedire la registrazione dei log  degli errori interni al sito risolvevo (forse)  la dimensione dei file logs error e logs access, mi sarei tenuto tutto il disturbo  ovviamente.

ma allora il sito che lo pubblico a fare?  per raggiungere l'altro decimo del pianeta mi bastano i social e uno spazio su g+  e non ho problemi.
io invece voglio che  i disturbatori  me li tolga di torno il servizio dns  mentre invece tutto il resto del pianeta possa passare indisturbato.

non è difficile arrivarci, sai?

[mmleoni]

giga e giga di dati, milioni di righe, nove decimi [del] pianeta: spari numeri a caso.
cortesemente, se la cosa non riguarda joomla non è argomento per questo forum: grazie.

[56francesco]

lo avevo premesso:

ma se fosse ot ditelo che cerco altrove,

e comunque si, riguarda joomla perchè ne è stato vittima un sito costruito in 1.5 poi subito 1.6.0  e via via cresciuto con diversi componenti  tutti joomla fino alla 2.5.27