Benvenuti sul nostro
BLOG Informativo HOSTING
News, Faq, Guide
Payday loans
www.

«
»


Mod_security e regolette

Inserito il Apr 20, 2010 Condividi

Giornalmente, a livello mondiale, centinaia di siti vengono defacciati sempre per il solito motivo: far vedere quanto si è bravi e belli, sui tanti siti di notifica, dove è possibile vedere il nome del “Bravo Ragazzo” di turno, i siti defacciati, il metodo utilizzato e anche la classifica!!!!! Vi sono anche siti italiani dove tramite forum questi “Bravi Ragazzi” notificano il loro operato. Lo notificano se pur precisano che non lo fanno a scopo lamer ma scopo didattico.

Fino a qualche tempo fà (2004-2005) i siti defacciati erano qualche migliaio al giorno poi, grazie ad alcune sicurezze implementate sui server e lo studio approfondito delle problematiche dei popolarissimi CMS, hanno fatto in modo che il numero dei siti crakkati diminuisse…….però di poco Solo oggi son stati notificati 2800 defacciamenti e negli ultimi 16gg circa 68000.

Questo mini articolo non vuol essere nè una guida, nè un memorandum di cosa è la sicurezza vuol solo dare alcune piccole informazioni su cosa accade nel web…una sorta di faq. Uno dei metodi più utilizzati per defacciare i siti è l’uso di espressioni/link inserite nelle url sfruttando i bug dei più noti CMS.

Molte volte non vengono usati i bug del cms stesso bensì i bug presenti nei plugin dei medesimi CMS, quei plugin utilissimi ma allo stesso modo delicati. Il metodo molto utilizzato per protegger, in parte, i siti dei clienti da questi tentativi è il mod_security.
Senza entrare nel tecnico cerchiamo di spiegare in modo molto semplice come funziona il mod_security.
Utente apre un link, aggiunge nel medesimo qualche bella parolina chiave oppure inserisce un post in un forum sempre con certe paroline oppure, il più classico, apre il link del sito aggiungendo un link ad un file esterno utile per iniziare il lavoro.
A
questo punto il mod_security và a cercare all’interno di files ben precisi installati sul server, se le stringhe richiamate sono simili ai tentativi di defacciamento . Se nel link, nel post, nell’url esterna, trova conformità con le regole, apache restituisce un errore 403 o 406 limitando poi l’accesso al server dall’ip che stà “tentando” di defacciare il sito

Questi file richiamati dal mod_security sono fatti da centinaia di stringhe studiate nel corso degli anni da “GURU” del settore, i quali studiano i defacciamenti, studiano gli script e poi mandano in aggiornamento i files con le loro stringhe, stringhe complicate da interpretare.

Problemi: gestendo qualche area admin del sito, scrivendo su un forum, può capitare che si riscontrino falsi positivi scontrandosi con errori 403 e 406.
All’apparire degli errori si pensa subito che il server non funziona, che vi sia qualche errore di configurazione, che si stà perdendo tempo per errori dell’hoster. I falsi positivi possono nascere per un plugin non aggiornato e non ancora conforme alle nuove regole di sicurezza, per esagerata sicurezza di una stringa o anche “errore” di chi ha creato le stringhe di sicurezza del mod_sec.

Sicuramente questi noiosi errori, falsi positivi, creano perdita di tempo, problemi temporanei di blocco lavoro…..tutti ne sono a conoscenza.
La perdita di tempo è anche da parte dell’hoster in quanto deve prodigarsi a sbannare gli ip, cercare la regola che ha creato il problema, segnalare la regola a chi di competenza….
..Pensiamo però ad una cosa: se fosse il “Bravo Ragazzo” a cercar realmente di entrare nel sito e sul medesimo non vi è quella sicurezza (stringa)? Quali problemi si avrebbero? Il tempo perso al ripristino quanto sarebbe? e la perdita di immagine del sito a seguito del defacciamento?. Regole noiose ma utili? Forse utilissime anche se non in grado di bloccare del tutto i problemi di defacciamento.
Quando accade un errore 403 o 406 non continuamo a provare a inserire l’articolo o il post. Contattate l’hoster chiedendo quale regola fà “esplodere” l’errore e nel mentre che attendiamo la risposta dell’hoster, andiamo sul sito del plugin o del cms a cercare se vi è un aggiornamento e se qualcuno ha avuto i soliti problemi con il mod_security.
A volte può bastare un aggiornamento, la modifica di una stringa dello script e il gioco è fatto senza dover richiedere l’inibizione della regola sito.
La cancellazione di quella regola di sicurezza sul dominio è utile per lavorare ma utile anche ad aprire una porta verso il possibile “bravo ragazzo”
Giornalmente sui ns server blocchiamo circa 800 tentativi (media) di accesso non consono su url. Il valore varia molto in base alla popolarità dei siti presenti su un server e la quantità di CMS presenti sul medesimo.
Altro fattore è la longevità del CMS presenti. Sicuramente alcuni di questi accessi sono falsi positivi.
In base a segnalazione dei clienti circa 5/10 al giorno sono “falsi positivi”.
In questi giorni, in cui abbiamo disabilitato ad un sito alcune stringhe di sicurezza per dar modo di aggiornare lo script, abbiamo ricevuto questa domanda: ma non è possibile avere CMS+sicurezza+funzionalità? Non è semplice rispondere.
Proviamo anche se l’esempio è un pò banale. “Pensiamo ad un server.”
Per poter sfruttare un server al 100% senza problemi quale è l’unico modo? Togliere il firewall e le sicurezze.
In questo modo non si avranno problemi di numero invio email, di sbagliare 100 volte password, di mettere password a 2 cifre, di inviare email senza autenticazione, di venir bannati se faccio degli scan, etc, etc.
Sicuramente si potrebbero fare altri esempi più concreti ma anche questo esempio banale aiuta a capire che per lavorare con un minimo di sicurezza si deve usare gli strumenti che la rete ci mette a disposizione, soprattutto regole che sono studiate appositamente sui defacciamenti di siti altrui.

NB: ovviamente non tutte le regole sono create e inviate in tempo reale.
Come per ogni problema, la soluzione viene fuori sempre dopo che è stato riscontrato il BUG, pertanto non affidateVi solo a queste regole lato server, ma cercate anche Voi, gestori di CMS e non CMS, di tenere sempre aggiornato lo script, limitare accessi in aree riservate, cambiare spesso password di amministrazione, inserire password importanti e non “nomedominio” “nomeblog” “nomepersona”, cercare di modificare il nome dei link alle aree di amministrazione.

Inserisci Commento/Domanda/Risposta

You must be logged in to post a comment.