Come rendere sicuro Joomla contro attacchi degli hacker

[marco_g]

Joomla è uno strumento popolare ed apprezzato da migliaia di professionisti e dilettanti grazie alla sua semplicità, questo fa si che i malintenzionati tentino di bucare i siti realizzati con questo cms, aumentarne la sicurezza è possibile con poche operazioni ma di fondamentale importanza.

Link: http://www.joomla.it/articoli-della-community/3925-la-sicurezza-in-joomla.html

[chesslore]

Scusa ma rinominare il prefix non crea problemi con i successivi aggiornamenti di joomla?

[justvins]

Scusa ma rinominare il prefix non crea problemi con i successivi aggiornamenti di joomla?

no, tu aggiorni i files mica il db
e il configuration php non viene toccato durante i vari upgrade

[intimefantasie]

Ho effettuato la procedura descritta nell'articolo, per quanto riguarda il rinominare "admin" era quasi scontato, qualsiasi utente non alle prime armi sa che è un operazione che va fatta, su zencart ad esempio in uno degli ultimi aggiornamenti per la sicurezza viene completamente rinominata la cartella "administrator".........ma comunque procediamo

Il problema che ho riscontrato è stato nella versione 1.5.15 nel rinominare il suffisso jos_ del database, nell'articolo viene consigliato di operare prima su configuration.php sostituire con il nuovo suffisso jos, operare la sostituzione nel database del file .sql

Ora avendo più server e database ho provato su un portale il risultato è stato immendiato e perfetto.

Su un altro portale la sostituzione non è avvenuta ho dovuto cambiare prima l'estensione jos_ dal pannello administrato in joomla e poi successivamente dargli le nuove tabelle in Mysql.


Volevo farlo presente in quanto ci ho perso un po di tempo, ed è un operazione sconsigliata soprattutto dal pannello admin......
se andate in

- pannello di controllo
- cofigurazione globale
- server
leggerete a prefisso database un avviso con triangolo giallo "Non modificare prima di aver creato le nuove tabellecon il prefisso indicato nelle configurazioni"

be se vi dovesse capitare io ho risolto facendo l'esatto contrario.


Fatemi sapere se qualcuno riceve lo stesso problema.

[marco_g]

Scusa ma rinominare il prefix non crea problemi con i successivi aggiornamenti di joomla?

no, tu aggiorni i files mica il db
e il configuration php non viene toccato durante i vari upgrade

Quoto quanto gia detto da justvins

Ho effettuato la procedura descritta nell'articolo, per quanto riguarda il rinominare "admin" era quasi scontato, qualsiasi utente non alle prime armi sa che è un operazione che va fatta

Non va rinominato, "ma creare un nuovo superadministrator e non chiamarlo admin" di modo che prenda un'altro id, così "Di seguito cambiare le credenziali al vecchio superadministrator con ID 62 (trasformandolo in registred) per poterlo cancellare definitivamente."

Il problema che ho riscontrato è stato nella versione 1.5.15 nel rinominare il suffisso jos_ del database, nell'articolo viene consigliato di operare prima su configuration.php sostituire con il nuovo suffisso jos, operare la sostituzione nel database del file .sql

Ora avendo più server e database ho provato su un portale il risultato è stato immendiato e perfetto.

Su un altro portale la sostituzione non è avvenuta ho dovuto cambiare prima l'estensione jos_ dal pannello administrato in joomla e poi successivamente dargli le nuove tabelle in Mysql.

La procedura da me riportata è la seguente:

1)"Entrare in ftp e fare il download del file configuration.php, modificare la stringa"

2)"Ora aprite il vostro php myadmin e fate un export struttura e dati in formato sql del vostro database."

3)"Salvate l'export in un file di testo e con un semplice trova e sostituisci cercate jos_ e sostituitelo con new_"

3)"svuotate completamente il database e ripopolatelo con i files del documento che avete appena modificato."

4)In fine "rientrate in ftp e sovrascrivete il file configuration.php che avevate modificato in precedenza."

Ho ripetuto la procedura in diversi siti senza avere difficoltà, l'unico inconveniente è che "Per siti particolarmente grandi si consiglia di fare due export separati uno solo struttura e uno solo dati sempre in formato sql e procedere con le operazioni che seguono su entrambe i files. Questo fa si che nel ripristino possiamo prima importare le tabelle e poi i dati anche un po alla volta, per evitare un blocco del trasferimento"

Il prefisso del pannello amministrativo se non erro è lo stessto del file configuration.php ma per questioni di praticità è consigliabile lavorare direttamente sul file che sovrascriveremo soltanto dopo aver cambiato i suffissi dal myadmin.

L'unica cosa che mi può venire in mente che il tuo file configuration.php per qualche motivo non si sia sovrascritto.

[Fabrizio4All]

Non ho ancora testato... ma l'articolo è ottimo!!!!!

sono quei tips che valgono oro!!!!

[marco_g]

Bé c'è da ringraziare sopratutto Brian Teeman, se non erro, uno dei "papà" di Joomla ed al suo intervento al Joomla Day, io non ho fatto altro che seguire attentamente, documentarmi, testare e poi riportare nell'articolo l'esperienza.
Se qualcuno ha voglia e tempo di visionarla è disponibile la slide con altre chicche che non riguardano la sicurezza ma comunque interessanti

[intimefantasie]

Sul fatto che l'articolo sia ottimo non ci piove. Ve lo dice uno che da 3 settimane combatte con una "roba" allucinante.

Io ho usato termini impropri, ed ho errato quando si parla di programmazione, codice, php, mysql eccc.

Per l'admin siamo perfettamente daccordo l'utente va creato ex novo e non rinomina. MI SONO ESPRESSO MALE.

Il mio problema è venuto fuori seguendo la stessa procedura da te citata, io opero modificando direttamente i file via ftp, ovviamente è la stessa che scaricando e uppando su server e fin qui ci siamo. Solo che in un mio server ho avuto il problema che ho elencato sopra.

Seguendo la procedura elencata:

1)"Entrare in ftp e fare il download del file configuration.php, modificare la stringa"

2)"Ora aprite il vostro php myadmin e fate un export struttura e dati in formato sql del vostro database."

3)"Salvate l'export in un file di testo e con un semplice trova e sostituisci cercate jos_ e sostituitelo con new_"

3)"svuotate completamente il database e ripopolatelo con i files del documento che avete appena modificato."

4)In fine "rientrate in ftp e sovrascrivete il file configuration.php che avevate modificato in precedenza."

nell'accesso al front-end o back-end ricevevo un errore sul db ovvero il server mi dice che non puo' aprire le tabelle jos_

io ho rimendiato rinominando prima l'estensione jos_ con es. new_ da pannello joomla e poi effettuando la modifica alle tabelle de mysql.

Ti diro' di più se utilizzi questo metodo lasciando configuration.php inalterato funziona idem, almeno per questo mio server. 

Intendi il problema dove sta?

Sto su sgaragnao non penso che posssa essere riconducibile a questo, ma se vuoi reimposto il tutto per farti vedere il tipo di errore che mi produce la procedura sopra elencata.

[marco_g]

intimefantasie non ho testato la tua procedura, quindi non posso essere preciso, comunque non mi sento di consigliarla perchè nel pannello di amministrazione dove vai a cambiare il parametro, c'è un allert come in figura.

Comunque seguendo la sequenza
1)"Entrare in ftp e fare il download del file configuration.php, modificare la stringa"
4)In fine "rientrate in ftp e sovrascrivete il file configuration.php che avevate modificato in precedenza."

Non è la stessa cosa, perché nel mio caso il file configuration.php lo aggiorno dopo aver modificato le tabelle, come consiglia l'alert nel pannello di amministrazione.

"io opero modificando direttamente i file via ftp, ovviamente è la stessa che scaricando e uppando su server"

Comunque è pur vero che avendola testata tu potrebbe essere una valida alternativa, ma ti ripeto che non avendola testata non ne entro in merito.


[allegato vecchio più di un anno eliminato automaticamente]

[idroweb]

Scusate la procedura vale anche per la versione 1.0.15?

[falsinfab]

Ciao

Grazie per i consigli. Ma se creo un nuovo administrator e rimuovo quello vecchio poi perdo anche tutte le associazioni agli articoli e, soprattutto, hai messaggi del forum (Kunena) creati dal "vecchio" administrator, come si risolve questo problema? 

[marco_g]

Ovviamente la versione 1.0.15 andrebbe migrata alla 1.5.15 ultima versione stabile (prima regola dell'articolo).
Anche perché alla 1.5.15 sono state apportate delle modifiche al file htaccess che mettono al sicuro i files xml i quali svelano la versione di Joomla e dei suoi componenti.
Questa modifica non l'ho riportata nell'articolo in quanto rispettando la prima regola (fondamentale) questa ulteriore modifica non va apportata.

Non ho testato questa procedura sulla 1.0, quindi non mi sento di confermarti con sicurezza, ma a rigor di logica dovrebbe andare bene.
Comunque dopo aver effettuato il backup (che io consiglio nell'articolo) se non funziona qualcosa si può sempre tornare indietro.
Rimane sempre il fatto che non ottemperando alla prima regola, facciamo metà del lavoro che andrebbe fatto.

[marco_g]

Ciao

Grazie per i consigli. Ma se creo un nuovo administrator e rimuovo quello vecchio poi perdo anche tutte le associazioni agli articoli e, soprattutto, hai messaggi del forum (Kunena) creati dal "vecchio" administrator, come si risolve questo problema? 

E' vero, come si suol dire non tutte le ciambelle riescono con il buco, noi però il buco glie lo facciamo.

Io ho risolto facendo il solito export solo dati da myadmin, questa volta della tabella content.
Ho fatto il solito trova , 62, e sostituisci con , NEW-ID, dove new-id è il nuovo numero id preso dal superadministrator es. , 280, è consigliabile inserire le virgole per non andare a sostituire altri numeri che potrebbero non avere a che fare con il nostro id.
(Se qualcuno è al corrente di una sintassi sql più precisa da digitare direttamente nel myadmin è ben accetta.)
Quindi svuoti e ripopoli la tabella content con i nuovi dati.
Per quanto riguarda il forum, la procedura è la medesima, devi soltanto individuare la tabella sulla quale dovrai andare ad agire.

Se decidi di procedere, facci sapere qual'è la tabella di Kunena che si deve modificare, potrà essere utile a qualche altra persona.

[idroweb]

Ovviamente la versione 1.0.15 andrebbe migrata alla 1.5.15 ultima versione stabile (prima regola dell'articolo).
Anche perché alla 1.5.15 sono state apportate delle modifiche al file htaccess che mettono al sicuro i files xml i quali svelano la versione di Joomla e dei suoi componenti.
Questa modifica non l'ho riportata nell'articolo in quanto rispettando la prima regola (fondamentale) questa ulteriore modifica non va apportata.

Non ho testato questa procedura sulla 1.0, quindi non mi sento di confermarti con sicurezza, ma a rigor di logica dovrebbe andare bene.
Comunque dopo aver effettuato il backup (che io consiglio nell'articolo) se non funziona qualcosa si può sempre tornare indietro.
Rimane sempre il fatto che non ottemperando alla prima regola, facciamo metà del lavoro che andrebbe fatto.

Il sito in questione (sono affezionato) non l'ho migrato perchè ho effettuato diverse modifiche che perderei con la versione nuova....e tentare di renderlo simile è un lavoraccio.

Vorrei provare a fare la modifica sicurezza seppur di efficacia limitata come spieghi.

Gli altri 2 siti che ho sono invece fatti con la nuova versione e proverò la modifica.

Quando dici di esportare la struttura e i dati intendi il DB creato e quello information_schema?

Grazie

[marco_g]

Allego un'immagine del myadmin

Prima fleggare solo struttura
Poi fleggare solo dati

Per la 1.0 ti consiglio di apportare manualmente anche le modifiche al file htaccess descritte nello slide che ho linkato prima

[allegato vecchio più di un anno eliminato automaticamente]

[bigham]

Ciao marco_g

Bell'articolo!! 
Ma chiaramente l'argomento si può (e si deve) approfondire. Ci sono altri piccoli accorgimenti che possono essere presi per cercare di aumentare il livello di sicurezza di un sito realizzato in Joomla.

Per quanto riguarda la rinominazione delle tabelle un'altra soluzione possibile sarebbe quella di sfruttare la query DDL ALTER TABLE. Questa query permette di rinominare una tabella e ha la seguente sintassi:

Codice: [Seleziona]

ALTER TABLE nome_tabella RENAME nuovo_nome_tabella
Il problema adesso è ottenere la lista dei nomi delle tabelle e creare uno script sql da eseguire sul database

Per ottenere la lista delle tabelle:

• connettersi al database con phpmyadmin
• cliccare sul pulsante SQL (in alto). Verrà visualizzata la casella di testo per l'esecuzione diretta delle query sul database
• scrivere ed eseguire la seguente query:
  

Codice: [Seleziona]

SHOW TABLES IN nome_database LIKE 'jos_%'
verrà visualizzato l'elenco delle tabelle che iniziano con jos_ presenti nel database di nome 'nome_database' (ovviamente sarà il nome del db su cui stiamo lavorando)

• a questo punto creare un documento di testo con il notepad (o altro editor di testo) e con un pò di pazienza copiare e incollare la lista delle tabelle. Nel file di testo avremo una cosa del genere:

Codice: [Seleziona]

jos_banner
jos_bannerclient
jos_bannertrack
jos_categories
.... ecc.

Ottenuta la lista dei nomi delle tabelle dobbiamo, ancora con un pò di copia e incolla, trasformarla in una lista di query che rinominino ogni singola tabella.
Il risultato finale sarà il seguente:

Codice: [Seleziona]

ALETR TABLE jos_banner RENAME new_banner;
ALETR TABLE jos_bannerclient RENAME new_bannerclient;
ALETR TABLE jos_bannertrack RENAME new_bannertrack;
ALETR TABLE jos_categories RENAME new_categories;
.... ecc.

A questo punto non serve altro che copiare tutte le query incollarle della casella di testo destinata all'esecuzione diretta delle query sul database ed eseguirle.
Magari si possono copiare e incollare un pò per volta

Resta intesa la modifica al file configuration.php per dichiarare il nuovo prefisso delle tabelle.

[marco_g]

Ottimo bigham visto che sei così preparato, uno script per cambiare l'id autore nella Tabella content?

es. cambia id 62 in id 128 nella new_content

[idroweb]

Temo di aver fatto una boiata! ho provato a fare la modifica senza successo sulla versione 1.0.15, ho svuotato il DB e importato il file sql ma in realtà non ha caricato i file e allora ho avuto la brillante idea di eliminare le tabelle del DB!

Posso rimediare?

[marco_g]

Temo di aver fatto una boiata! ho provato a fare la modifica senza successo sulla versione 1.0.15, ho svuotato il DB e importato il file sql ma in realtà non ha caricato i file e allora ho avuto la brillante idea di eliminare le tabelle del DB!

Posso rimediare?

1 se hai fatto il backup prima di iniziare come ho consigliato nell'articolo, puoi ripristinare.

2 se hai estratto due file struttura e dati, quello è già un backup ripristini prima la struttura, (ossia le tabelle) e poi i dati

3 se hai estratto un solo file struttura e dati quello è già un backup.
se non riesci a ricaricarlo perché si blocca, dividi la parte struttura dalla parte dati manualmente, ripristini prima la struttura e poi i dati in tre, quattro riprese.
Riporto un'esempio allegato

[allegato vecchio più di un anno eliminato automaticamente]

[idroweb]

Il file da ripristinare è di solo 573 kb, struttura e dati ma mi da questo errore:

Errore

query SQL:

-- phpMyAdmin SQL Dump
-- version 2.8.0.2
-- http://www.phpmyadmin.net
--
-- Host: sql.miosito.it
-- Generato il: 02 Dic, 2009 at 03:33 PM
-- Versione MySQL: 5.0.20
-- Versione PHP: 4.3.10-22
--
-- Database: `ffff55555`
--
CREATE DATABASE `ffff55555` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;

Messaggio di MySQL: Documentazione
#1007 - Can't create database 'ffff55555'; database exists