Per comprendere meglio le modifiche che dobbiamo implementare installiamo una macchina virtuale dove poter emulare un Virtual Private Server, una soluzione alternativa al classico hosting che lascia la piena libertà ed il totale controllo della macchina (oneri ed onori, bada bene) e dei servizi che permettono al nostro sito di girare.
Una precisazione doverosa va fatta subito, perchè in molti si staranno già chiedendo come mai non ho optato subito per utilizzare MAMP, l'ambiente di sviluppo per eccellenza.
Perchè con MAMP non possiamo effettuare determinate operazioni come la modifica della porta del servizio SSH, trasferire file tramite sFTP e via dicendo.
Utilizzare un Virtual Private Server implica oltre la manutenzione di Wordpress anche la sicurezza del Sistema Operativo, e non è cosa da poco conto, perchè i pericoli si allargano a macchia d'olio.
In questo modo possiamo comprendere bene il processo di hardening di MySQL e Apache, capire cosa succede realmente per poter mettere in pratica le nozioni seguenti.
La macchina virtuale diventerà quindi a tutti gli effetti il posto dove collaudare le nostre modifiche, prima di passarle sul nostro dominio.
Saremo quindi al riparo da errori, pagine bianche o peggio indisponibilità del blog. In questo ambiente abbiamo inoltre la possibilità di testare l'aggiornamento dei plugin e dei temi in tutta tranquillità.
La scelta del sistema operativo è del tutto soggettiva, chiariamo subito il concetto che non esiste una distribuzione Linux migliore di un’altra, più o meno potente, esiste quella che sappiamo utilizzare meglio.
Se ci sentiamo più confidenti con Ubuntu Server andiamo tranquilli, se preferiamo la CentOS perché la utilizziamo in ambiente Enterprise tanto di guadagnato.
Durante l’installazione e le configurazione dei prodotti vedremo insieme tutte e due le possibilità. Le versioni dei sistemi operativi più utilizzati in ambito VPS sono attualmente Centos 6 ed Ubuntu 14.02(oppure 03) LTS.
Procurati le ISO ed il software per l'emulazione dei sistemi operativi per l’installazione:
CentOS http://isoredirect.centos.org/centos/6/isos/x86_64/
Ubuntu http://www.ubuntu.com/download/server
Il software utilizzato per la virtualizzazione è VirtualBox, scaricabile gratuitamente all’indirizzo
https://www.virtualbox.org/ per Windows, OS X e Linux.
Una volta installato lanciamolo ed all’avvio abbiamo la classica Home Page del prodotto.
Clicchiamo su Nuova nel menu in alto a sinistra ed iniziamo a creare la prima macchina virtuale
con CentOS.
Dai un nome alla macchina virtuale e seleziona Red/Hat come Versione del Sistema.
Assegna una memoria pari a 2048 MB (due giga) per ottenere prestazioni ottimali, ma questo dipende molto da quanta memoria ha il tuo pc. Se hai almeno 8 GB di RAM, vai tranquillo con i 2 GB. Se il tuo pc ne ha 4 scala a 1GB per la macchina virtuale. Se ne hai di meno scala in proporzione di un quarto della memoria totale disponibile, la differenza darà una macchina viruale più o meno veloce nell'esecuzione.
Per il disco fisso diamo un valore di 40 GB, è la capienza dell’hard disk disponibile sulla macchina virtuale, ma il consumo reale sull’hard disk del pc sarà solo quello effettivamente occupato dalla VM.
Le dimensioni del disco sono la capacità massima che la macchina virtuale può sostenere (devi lasciare il valore di default Allocato Dinamicamente).
Ora il software ci riporta alla Home dove troviamo la VM CentOS che abbiamo appena creato.
Ripetiamo le stesse operazioni per Ubuntu se è la nostra scelta come Sistema Operativo, scegliendo Ubuntu nella tipologia.
Per fare questo clicchiamo nuovamente su Nuova, sempre nel menu in alto a sinistra.
La tipologia consiste in un set di configurazioni predefinte create ad hoc per il sistema scelto.
Ora la lista di Virtual Box comprende tutte e due le macchine virtuali create.
Non facciamo partire nulla, dobbiamo ancora impostare la rete e farlo puntare alla ISO per il setup. La ISO è l’immagine del sistema operativo che vogliamo installare.
Emula un DVD di installazione vero e proprio, da montare nel lettore virtuale della Virtual Machine.
"> CentOS
Selezioniamo la CentOS nella lista e clicchiamo su Impostazioni per accedere al menu della VM. Come appena riferito, dobbiamo far puntare la ISO che abbiamo scaricato ed inserirla come fosse un lettore ottico e farlo avviare all’accensione.
Chi conosce Virtual Box sa che è possibile configurare ogni aspetto della macchina virtuale, un vero e proprio assemblaggio di un pc virtuale.
Possiamo avere due o più hard disk sulla stessa macchina, due o più lettori DVD, più schede di rete.
Questo ci permette la creazione di sistemi complessi, di condividere cartelle fra due o più macchine o fra la VM (chiamata Guest) ed il PC fisico (l’Host)
Portiamoci su Archiviazione e negli attributi del Lettore ottico, nel menu a tendina, tramite l’icone del CD-ROM, optiamo per Scegli un file di disco ottico virtuale, che ci permetterà di selezionare l’immagine ISO.
Identificata la ISO corretta clicchiamo su OK ed avviamo finalmente la macchina virtuale CentOS.
Durante l’installazione andranno inserite informazioni come la password dell’utenza di root, il partizionamento dei dischi e via dicendo. Scegli le impostazioni di default e dai una password all’amministratore del sistema per un’installazione veloce.
In ambiente VPS non abbiamo facoltà di scegliere le modalità di installazione perché il fornitore generalmente fornisce template già pronti, il massimo a cui puoi aspirare è la formattazione, quindi partendo dall’installazione base provvederemo a tutte le modifiche del caso, per essere più vicini possibili alla realtà di tutti i giorni.
Durante l’installazione andranno inserite informazioni come la password dell’utenza di root, il partizionamento dei dischi e via dicendo. Scegli le impostazioni di default e dai una password all’amministratore del sistema per un’installazione veloce.
In ambiente VPS non abbiamo facoltà di scegliere le modalità di installazione perché il fornitore generalmente fornisce template già pronti, il massimo a cui puoi aspirare è la formattazione, quindi partendo dall’installazione base provvederemo a tutte le modifiche del caso, per essere più vicini possibili alla realtà di tutti i giorni.
Root Login
Il primo passo da compiere su un server VPS è sicuramente quello di non utilizzare l’utenza di root per l’ordinaria amministrazione, ma di creare un’utenza ad hoc e disabilitare l’accesso in ssh del root.
Questo mette al riparo il nostro VPS da tentativi ripetuti di attacco tramite brute force. Se sentiamo la necessità di utilizzare il root, possiamo farlo una volta autenticati all’interno del server.
La prima volta che ho gestito un VPS ho riscontrato circa 60 mila tentativi di tentativi di accesso falliti. Panico totale…
Il primo accesso va comunque effettuato con il root, e se il nostro fornitore ha delle password preimpostate cambiamola subito con una robusta.
Questo mette al riparo il nostro VPS da tentativi ripetuti di attacco tramite brute force. Se sentiamo la necessità di utilizzare il root, possiamo farlo una volta autenticati all’interno del server.
La prima volta che ho gestito un VPS ho riscontrato circa 60 mila tentativi di tentativi di accesso falliti. Panico totale…
Il primo accesso va comunque effettuato con il root, e se il nostro fornitore ha delle password preimpostate cambiamola subito con una robusta.
passwd
Tramite questo comando ci verrà chiesto di inserire per due volte la nuova password e da questo istante la nuova entrerà in azione.
Un nuovo utente
E’Il nostro utente, quello che deve accedere quotidianamente al server per le operazioni di manutenzione. Creiamolo insieme, diamogli una buona password ed i privilegi di amminstrazione.
Per aggiungere un nuovo utente digitiamo nel terminale
/usr/sbin/adduser nomeutente
Diamogli una password
passwd nomeutente
Per utilizzare comandi che richiedono privilegi di amministrazione, bisogna ricorrere al comando sudo seguito dal comando che intendiamo lanciare. Il sistema verifica se l’utente appartiene al gruppo sudoers e ne autorizza/nega la richiesta.
passwd nomeutente
Per utilizzare comandi che richiedono privilegi di amministrazione, bisogna ricorrere al comando sudo seguito dal comando che intendiamo lanciare. Il sistema verifica se l’utente appartiene al gruppo sudoers e ne autorizza/nega la richiesta.
Di default, i nuovi utenti non appartengono al gruppo sudoers, quindi ora che siamo root ed abbiamo creato il nostro utente nomeutente, andiamolo ad aggiungere nel file che contiene gl utenti autorizzati.
vi /usr/sbin/visudo
Troviamo nel file la riga “User privilege specification”, che nella sua forma originale si presenta cosi:
# User privilege specification
root ALL=(ALL) ALL
Aggiungiamo il nostro utente subito dopo
# User privilege specification
root ALL=(ALL) ALL
nomeutente ALL=(ALL) ALL
Per uscire dall’editor e salvare la configurazione digitare in sequenza i tasti Esc : w q !
Facciamo subito una prova. Usciamo dalla sessione di root ed entriamo con il nostro utente.
Proviamo a lanciare il nostro primo comando insieme al sudo.
sudo yum update
Questo comando, nei sistemi basati su Red Hat, consente di verificare ed aggiornare il sistema operativo. Se il nostro utente ha la facoltà di lanciarlo abbiamo configurato correttamente i privilegi, altrimenti dobbiamo ripetere l’operazione (potresti non aver salvato il file visudo)
Una nuova porta
Quando ci colleghiamo ad un server VPS utilizziamo un software che sia in grado di stabilire una connessione protetta tra noi e l’host, solitamente facendo uso di Putty su Windows (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html ), direttamente dal terminale se abbiamo OS X o Linux.
Chi usa un VPS lo sa, e la porta di default (la 22) viene scandagliata quotidianamente e bombardata da fake login alla ricerca della combinazione giusta.
Per ridurre del 90 per cento questi tentativi basta cambiare la porta dove è esposto il servizio sshd.
Volendo lavorare ancora più di fino è possibile autorizzare solo il nostro utente ad accedere tramite il servizio.
Vediamo finalmente l’utenza che abbiamo creato innalzare i propri privilegi per la modifica di un file di configurazione del sistema.
sudo vi /etc/ssh/sshd_config
Come è facilmente intuibile dal nome, stiamo modificando la configurazione del servizio ssh. Il nostro obiettivo è quello di cambiare la porta dove è in ascolto il servizio, disabilitare l’accesso per l’utente root ed autorizzare solamente il nostro utente per l’accesso.
Localizziamo all’interno del file le due voci che ci interessano
Port 19999
Il valore di default è 22. E’ possibile scegliere un numero compreso tra 1025 (le prime 1024 sono destinate ai servizi del sistema) e 65535.
Prima di uscire dalla sessione corrente assicurati aprendo un’altra finestra del terminale che il servizio ssh risponda su quella porta.
In caso di esito negativo hai inserito una porta già in uso da un altro servizio.
Per verificarlo utilizza il comando
netstat –an | grep numeroporta
Di default impostato a yes, se valorizzato a no l’utenza di root non avrà più accesso diretto al server in ssh ma solo localmente. Se abbiamo necessità di utilizzare il root, entriamo con il nostro utente e digitiamo su root, inserendo la password di root. Se è presenta il carattere # all’inizio della riga cancellalo altrimenti non verrà considerata la modifica (il carattere # serve ad ignorare la direttiva).
Abilitiamo il nostro utente all’accesso in ssh. Se non inseriamo questa riga non riusciremo più ad accedere al server in ssh. Salviamo sempre con : w q ! e ricarichiamo il servizio ssh.
service sshd reload
L’utente root non ha più accesso in ssh, il nostro utente si, la porta dove il servizio è in ascolto non è più la 22 ma la 19999 (o quella che hai scelto tu)
LAMP Server
Per installare Wordpress abbiamo bisogno di un LAMP Server. LAMP, per chi non lo sapesse, indica Linux (sistema operativo), Apache(il web server), MySQL (il database dove vengono inseriti i dati) e PHP (Il linguaggio di programmazione utilizzato nella piattaforma).
I fornitori di Hosting adottano questa soluzione per fornirci lo spazio e gli strumenti necessari a costruire i nostri blog/siti web.
Esistono varianti (ad esempio LEMP), dove cambia il web server, per il resto la struttura è la stessa ovunque, diversa nelle versioni di PHP e MySQL.
Su molte installazioni VPS il web server è già installato. Chi non lo avesse può utilizzare per installare Apache
sudo yum install httpd
Per chi gestisce un Virtual Private Server è molto importante definire quali sono I processi che devono avviarsi automaticamente in caso di reboot del server.
Per abilitare Apache all’avvio automatico si fa riferimento a chkconfig impostandolo con
sudo chkconfig httpd on
Se tutto è andato bene il servizio è attivo e digitando l’indirizzo IP della macchina virtuale (ifconfig per saperlo) nel vostro browser vedrete la pagina di benvenuto di Apache.
Se avete installato la versione desktop (con l’interfaccia grafica), aprite Firefox (della macchina virtuale) e digitate nella barra degli indirizzi http://localhost

Questa pagina verrà cambiata in seguito con la index del vostro sito.
Ora dobbiamo installare il secondo pezzo del puzzle, il database che conterrà i nostri dati.
sudo yum install mysql-server
Dobbiamo effettuare subito alcune accortezze e per farlo dobbiamo avviarlo.
sudo service mysqld start
Partirà la creazione del database di default, il servizio è in ascolto sulla porta di deafault 3306.
sudo /usr/bin/mysql_secure_installation
Questo script ci permette di impostare la password per il root di MySQL (a te che sei l’anello debole, deve essere differente dal root del Sistema operativo!!!), ci chiederà se togliere la possibilità di accedere con utenza anonima per la consultazione dei db (ovvio che si), rimuovere il database di test e soprattutto se disabilitare la connessione come root del database da remoto.
Questa opzione è fondamentale, perche abilitare il root remoto può permettere (indovinando la password) di far manomettere a chiunque riesca ad accedere i dati contenuti nei database. L’utenza di root di mysql deve accedere solamente in locale (accedo in ssh con il mio utente e mi connetto a mysql come root).
Al termine rispondiamo Yes per ricaricare i privilegi e rendere effettive le modifiche.
By default, a MySQL installation has an anonymous user, allowing anyone
to log into MySQL without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.
Remove anonymous users? [Y/n] y
... Success!
Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.
Disallow root login remotely? [Y/n] y
... Success!
By default, MySQL comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.
Remove test database and access to it? [Y/n] y
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!
Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.
Reload privilege tables now? [Y/n] y
... Success!
Cleaning up...
All done! If you've completed all of the above steps, your MySQL
installation should now be secure.
Thanks for using MySQL!
Come per Apache, andiamo ad abilitare l’avvio automatico in caso di reboot.
sudo chkconfig mysqld on
sudo service mysqld start
Partirà la creazione del database di default, il servizio è in ascolto sulla porta di deafault 3306.
sudo /usr/bin/mysql_secure_installation
Questo script ci permette di impostare la password per il root di MySQL (a te che sei l’anello debole, deve essere differente dal root del Sistema operativo!!!), ci chiederà se togliere la possibilità di accedere con utenza anonima per la consultazione dei db (ovvio che si), rimuovere il database di test e soprattutto se disabilitare la connessione come root del database da remoto.
Questa opzione è fondamentale, perche abilitare il root remoto può permettere (indovinando la password) di far manomettere a chiunque riesca ad accedere i dati contenuti nei database. L’utenza di root di mysql deve accedere solamente in locale (accedo in ssh con il mio utente e mi connetto a mysql come root).
Al termine rispondiamo Yes per ricaricare i privilegi e rendere effettive le modifiche.
By default, a MySQL installation has an anonymous user, allowing anyone
to log into MySQL without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.
Remove anonymous users? [Y/n] y
... Success!
Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.
Disallow root login remotely? [Y/n] y
... Success!
By default, MySQL comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.
Remove test database and access to it? [Y/n] y
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!
Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.
Reload privilege tables now? [Y/n] y
... Success!
Cleaning up...
All done! If you've completed all of the above steps, your MySQL
installation should now be secure.
Thanks for using MySQL!
Come per Apache, andiamo ad abilitare l’avvio automatico in caso di reboot.
sudo chkconfig mysqld on
Per completare l’installazione abbiamo bisogno del PHP, un linguaggio di programmazione che interpreta pagine dinamiche.
sudo yum install php php-mysql
PHP mette a disposizione dell’utente una serie di moduli per incrementare le funzionalità e le prestazioni del web server.
Installa solo quello che serve realmente, altrimenti corri il rischio di esporre il VPS a vulnerabilità inutili, senza aver bisogno realmente di “nmila” moduli. Se installi un plugin e questo ha la necessità di un modulo in particolare( mai visto fino ad ora), lo troverai espressamente scritto nelle istruzioni di installazione.
Purtroppo su un hosting condiviso non abbiamo il controllo dei moduli, possiamo farcene un’idea creando la classica pagina di info dove ci vengono elencate le estensioni installate.
In caso di vulnerabilità possiamo sempre far presente al fornitore di hosting di adeguarsi.
Se non sai come creare la pagina info.php ecco un esempio
sudo vi /var/www/html/info.php
Inserisci nella pagina vuota (premi i per inserire con vi)
<?php
phpinfo();
?>
Se ora tramite il browser della tua VM digiti http://localhost/info.php vedrai la pagina PHP con la lista dei moduli e delle estensioni installate, la versione di PHP installata, etc.
Se vuoi ottenere solo info sui moduli installati puoi cambiare il codice in
<?php
phpinfo(INFO_MODULES);
?>
Non te lo devo dire io che una pagina del genere non può essere caricata suol tuo hosting, perché daresti una visione globale della configurazione del web server, che oltre ad essere la tua è anche quella di qualche centinaia di utenti (hosting condiviso).
Se hai la curiosità di vedere le informazioni caricala, consultala, ma toglila subito dopo.
E’ una delle pagine più ricercate da chi vuole tentare un attacco. In un colpo solo ha accesso ad un mucchio di informazioni.
Forse non ti sei accorto che abbiamo già effettuato un piccolo hardening di MySQL, quando abbiamo disabilitato le opzioni di accesso del root e rimosso il database di test.
Non è un’operazione scontata, ricordatela sempre.
Dopo aver ripetuto i passi effettuati in CentOS nelle impostazioni di Virtual Box per far puntare la macchina virtuale all’immagine ISO di Ubuntu Server scaricata in precedenza, partiamo con l’installazione vera e propria.
sudo yum install php php-mysql
PHP mette a disposizione dell’utente una serie di moduli per incrementare le funzionalità e le prestazioni del web server.
Installa solo quello che serve realmente, altrimenti corri il rischio di esporre il VPS a vulnerabilità inutili, senza aver bisogno realmente di “nmila” moduli. Se installi un plugin e questo ha la necessità di un modulo in particolare( mai visto fino ad ora), lo troverai espressamente scritto nelle istruzioni di installazione.
Purtroppo su un hosting condiviso non abbiamo il controllo dei moduli, possiamo farcene un’idea creando la classica pagina di info dove ci vengono elencate le estensioni installate.
In caso di vulnerabilità possiamo sempre far presente al fornitore di hosting di adeguarsi.
Se non sai come creare la pagina info.php ecco un esempio
sudo vi /var/www/html/info.php
Inserisci nella pagina vuota (premi i per inserire con vi)
<?php
phpinfo();
?>
Se ora tramite il browser della tua VM digiti http://localhost/info.php vedrai la pagina PHP con la lista dei moduli e delle estensioni installate, la versione di PHP installata, etc.
Se vuoi ottenere solo info sui moduli installati puoi cambiare il codice in
<?php
phpinfo(INFO_MODULES);
?>
Non te lo devo dire io che una pagina del genere non può essere caricata suol tuo hosting, perché daresti una visione globale della configurazione del web server, che oltre ad essere la tua è anche quella di qualche centinaia di utenti (hosting condiviso).
Se hai la curiosità di vedere le informazioni caricala, consultala, ma toglila subito dopo.
E’ una delle pagine più ricercate da chi vuole tentare un attacco. In un colpo solo ha accesso ad un mucchio di informazioni.
Forse non ti sei accorto che abbiamo già effettuato un piccolo hardening di MySQL, quando abbiamo disabilitato le opzioni di accesso del root e rimosso il database di test.
Non è un’operazione scontata, ricordatela sempre.
Primo Hardening
Volendo difendere ancora meglio il servizio MySQL possiamo modificare la porta dove il servizio è in ascolto, dirgli di accettare connessioni solamamente dal server dove è installato (presupponendo che Apache e Wordpress siano installati sullo stesso server, altrimenti le direttive vanno indicate).
Il file di configurazione di MySQL è /etc/mysql/my.cnf.
Vediamo le implentazioni che possiamo effettuare:
Da terminale quindi
sudo vi /etc/mysql/my.cnf
ed andiamo ad inserire nel file
#accetta connessione solo da localhost
bind-address = 127.0.0.1
La prossima mossa è impedire agli utenti non autorizzati l’accesso al filesystem nel path dove MySQL salva i suoi dati. Se un utente senza permessi prova ad accedere alla cartella mysql con l’intenzione di caricare file all’interno di essa riceverà un Permission Denied dal sistema.
#senza privilegi non si accede e non si caricano file
local-infile=0
Ultimo, ma non certo per importanza è rinominare l’utenza di root in un nome di nostra preferenza (magari evitiamo admin, superamin o superoot, vedi Anello debole della catena…)
Per farlo dobbiamo accedere a MySQL
mysql –u root –p
Digitiamo la password e siamo in MySQL.
rename user 'root'@'localhost' to 'nuovonome'@'localhost';
FLUSH PRIVILEGES;
Apri una nuova finestra del terminale ed accedi al servizio MySQL con il nome che hai scelto.
mysql –u nuovoutente –p
Non dimenticare il nome che hai scelto, perché da questo momento in poi è l’utenza che dovrai utilizzare per tutti i task che richiedono privilegi elevati all’interno del software.
Prima di passare all’hardening, cioè a mettere in sicurezza MySQL in senso specifico per Wordpress e Apache (con il PHP), ripetiamo gli stessi passi per Ubuntu Server. Cambia il modo di gestire le installazioni ma la strada è sempre quella.
Il file di configurazione di MySQL è /etc/mysql/my.cnf.
Vediamo le implentazioni che possiamo effettuare:
Da terminale quindi
sudo vi /etc/mysql/my.cnf
ed andiamo ad inserire nel file
#accetta connessione solo da localhost
bind-address = 127.0.0.1
La prossima mossa è impedire agli utenti non autorizzati l’accesso al filesystem nel path dove MySQL salva i suoi dati. Se un utente senza permessi prova ad accedere alla cartella mysql con l’intenzione di caricare file all’interno di essa riceverà un Permission Denied dal sistema.
#senza privilegi non si accede e non si caricano file
local-infile=0
Ultimo, ma non certo per importanza è rinominare l’utenza di root in un nome di nostra preferenza (magari evitiamo admin, superamin o superoot, vedi Anello debole della catena…)
Per farlo dobbiamo accedere a MySQL
mysql –u root –p
Digitiamo la password e siamo in MySQL.
rename user 'root'@'localhost' to 'nuovonome'@'localhost';
FLUSH PRIVILEGES;
Apri una nuova finestra del terminale ed accedi al servizio MySQL con il nome che hai scelto.
mysql –u nuovoutente –p
Non dimenticare il nome che hai scelto, perché da questo momento in poi è l’utenza che dovrai utilizzare per tutti i task che richiedono privilegi elevati all’interno del software.
Prima di passare all’hardening, cioè a mettere in sicurezza MySQL in senso specifico per Wordpress e Apache (con il PHP), ripetiamo gli stessi passi per Ubuntu Server. Cambia il modo di gestire le installazioni ma la strada è sempre quella.
Ubuntu
Dopo aver ripetuto i passi effettuati in CentOS nelle impostazioni di Virtual Box per far puntare la macchina virtuale all’immagine ISO di Ubuntu Server scaricata in precedenza, partiamo con l’installazione vera e propria.
A differenza di CentOS, Ubuntu server non dispone di un’interfaccia grafica per l’installazione ma testuale, possiamo selezionare le opzioni che vogliamo spostandoci con il tasto TAB e le frecce direzionali.
Per selezionare una voce si utilizza la barra spaziatrice, per andare avanti e confermare il tasto INVIO.
Per comodità e semplicità d’suo installeremo anche l’interfaccia grafica del sistema operativo, per essere allineati alla CentOS, ma è bene sapere che nella vita reale se dobbiamo gestire un server VPS avremo a disposizione solo la shell (a meno che, in casi particolari, non dobbiate utilizzare tramite VNC il desktop remoto, ma questa è un’altra storia…)
La prima differenza che notiamo tra CentOS e Ubuntu è l’utenza di amministrazione. Mentre CentOS ci obbliga ad inserire la password per il root, Ubuntu ci fa inserire il nome utente e la relativa password.
In Ubuntu di default l’utenza di root non è abilitata per questione di sicurezza.
Purtroppo sulla quasi totalità dei Virtual Private Server ho notato che nel loro template è l’utenza di root ad esistere di default, mentre l’utenza nominale va creata.
Andiamo a ricreare la stessa situazione per poi disabilitare il login tramite ssh del root come abbiamo fatto per CentOS.
Andate sempre avanti nell’installazione, non è fondamentale ai fini della dimostrazione cosa installare e cosa no, a noi serve una versione minimale per poi procedere manualmente nell’installazione dei pacchetti.
Utilizza tutto lo spazio su disco, scegli la lingua e la tastiera che preferisci fino a terminare l’installazione.
Al primo avvio dobbiamo inserire user e password scelti in fase di installazione, per poi successivamente abilitare l’utenza di root. Ricordi il comando passwd utilizzato per cambiare la password in CentOS?
Se si dispone di un’utenza con i privilegi di amministrazione è possibile assegnare una password ad un’utenza diversa. Per abilitare il root quindi, è necessario impostargli una password.
sudo passwd root
Inserisci confermando una seconda volta la password scelta, poi sblocca l’account con
sudo passwd -u root
Se si dispone di un’utenza con i privilegi di amministrazione è possibile assegnare una password ad un’utenza diversa. Per abilitare il root quindi, è necessario impostargli una password.
sudo passwd root
Inserisci confermando una seconda volta la password scelta, poi sblocca l’account con
sudo passwd -u root
Il Sistema, risponderà con
passwd: password expiry information changed
Ora è possibile utilizzare l’utenza di root. Per portarci alla pari dell’installazione fatta con CentOS dobbiamo installare un’interfaccia grafica, minimale, per non consumare troppe risorse. La scelta ricade quindi su Lubuntu Desktop, leggera e con il necessario per amministrare un server (anche se ripeto, per mia opinione personale, un server non dovrebbe avere l’interfaccia grafica).
sudo apt-get install lubuntu-desktop
sudo apt-get install lubuntu-desktop
Al termine dell’installazione riavvia la macchina virtuale e vedrai la pagina di login.
Ora che abbiamo allineato le due installazioni, procediamo con i primi quattro step anche per Ubuntu.
Root Login
Come visto in CentOS, Il primo passo da compiere su un server VPS è sicuramente quello di non utilizzare l’utenza di root per l’ordinaria amministrazione, ma di creare un utenza ad hoc e disabilitare l’accesso in ssh del root.
Questo mette al riparo il nostro VPS da tentativi ripetuti di attacco tramite brute force. Se sentiamo la necessità di utilizzare il root, possiamo farlo una volta autenticati all’interno del server.
Il primo accesso va comunque effettuato con il root, e se il nostro fornitore ha delle password preimpostate cambiamola subito con una robusta. Nella nostra macchina virtuale la password l’abbiamo già impostata, ma per un breve recap:
passwd
Tramite questo comando ci verrà chiesto di inserire per due volte la nuova password.
Un nuovo utente
Bisogna creare l’utenza che vogliamo utilizzare per l’uso quotidiano. Facciamolo insieme, ignorando l’utenza inserita in fase di installazione, diamogli una buona password ed i privilegi di amministrazione.
Per aggiungere un nuovo utente
adduser nomeutente
Inserire due volte la password e le informazioni del nuovo utente (se vogliamo, ovvio).
Per utilizzare comandi che richiedono privilegi di amministrazione, bisogna ricorrere al sudo seguito dal comando che intendiamo lanciare. Il sistema verifica se l’utente appartiene al gruppo sudoers e ne autorizza/nega la richiesta.
Ora non resta che assegnare al nuovo utente i privilegi di amministrazione utilizzando gpasswd con l’opzione sudo.
gpasswd -a nomeutente sudo
Bene, il nostro utente ha i privilegi necessari, possiamo disabilitare l’accesso in ssh per l’utente root, per poi usarlo, al bisogno, una volta autenticati nel server. Se si ha intenzione di amministare un server VPS è bene imparare questi comandi e le loro caratteristiche.
Per ulteriori informazioni, la community di Ubuntu (http://www.ubuntu-it.org/ ) ha una risposta pronta a tutte le domande.
Il file di configurazione del servizio ssh (sshd_config ) in Ubuntu Server lo troviamo nel path /etc/ssh/
Editiamolo per modificare la porta dove il servizio deve essere in ascolto, non permettere il login come root e per dichiarare quale utente avrà il permesso di accedere in ssh.
vi /etc/ssh/sshd_config
Port 22
Il valore di default è 22. E’ possibile scegliere un numero compreso tra 1025 (le prime 1024 sono destinate ai servizi del sistema) e 65535. Verifica prima di inserire un valore che non vi sia qualche servizio che la utilizza già, o non avrai la possibilità di collegarti in ssh.
PermitRootLogin yes
Di default impostato a yes, se valorizzato a no l’utenza di root non avrà più accesso in ssh ma solo localmente. Se abbiamo necessità di utilizzare il root, entriamo con il nostro utente e digitiamo su root, inserendo la password di root. Se è presenta il carattere # all’inizio della riga cancellalo altrimenti non verrà considerata la modifica (il # serve a disabilitare la riga, come fosse un commento).
Il file dovrà quindi essere così composto:
Port 19999
PermitRootLogin no
Volendo effettuare proprio tutti gli stessi step della CentOS abilitiamo solo il nostro utente ad accedere in ssh
AllowUsers nomeutente
Salviamo, sempre con : w q ! e ricarichiamo il servizio ssh.
sudo service ssh restart
L’utente root non ha più accesso in ssh, il nostro utente si, la porta dove il servizio è in ascolto non è più la 22 ma la 19999 (o quella che hai scelto tu)
Per utilizzare comandi che richiedono privilegi di amministrazione, bisogna ricorrere al sudo seguito dal comando che intendiamo lanciare. Il sistema verifica se l’utente appartiene al gruppo sudoers e ne autorizza/nega la richiesta.
Ora non resta che assegnare al nuovo utente i privilegi di amministrazione utilizzando gpasswd con l’opzione sudo.
gpasswd -a nomeutente sudo
Bene, il nostro utente ha i privilegi necessari, possiamo disabilitare l’accesso in ssh per l’utente root, per poi usarlo, al bisogno, una volta autenticati nel server. Se si ha intenzione di amministare un server VPS è bene imparare questi comandi e le loro caratteristiche.
Per ulteriori informazioni, la community di Ubuntu (http://www.ubuntu-it.org/ ) ha una risposta pronta a tutte le domande.
Una nuova porta
Il file di configurazione del servizio ssh (sshd_config ) in Ubuntu Server lo troviamo nel path /etc/ssh/
Editiamolo per modificare la porta dove il servizio deve essere in ascolto, non permettere il login come root e per dichiarare quale utente avrà il permesso di accedere in ssh.
vi /etc/ssh/sshd_config
Port 22
Il valore di default è 22. E’ possibile scegliere un numero compreso tra 1025 (le prime 1024 sono destinate ai servizi del sistema) e 65535. Verifica prima di inserire un valore che non vi sia qualche servizio che la utilizza già, o non avrai la possibilità di collegarti in ssh.
PermitRootLogin yes
Di default impostato a yes, se valorizzato a no l’utenza di root non avrà più accesso in ssh ma solo localmente. Se abbiamo necessità di utilizzare il root, entriamo con il nostro utente e digitiamo su root, inserendo la password di root. Se è presenta il carattere # all’inizio della riga cancellalo altrimenti non verrà considerata la modifica (il # serve a disabilitare la riga, come fosse un commento).
Il file dovrà quindi essere così composto:
Port 19999
PermitRootLogin no
Volendo effettuare proprio tutti gli stessi step della CentOS abilitiamo solo il nostro utente ad accedere in ssh
AllowUsers nomeutente
Salviamo, sempre con : w q ! e ricarichiamo il servizio ssh.
sudo service ssh restart
L’utente root non ha più accesso in ssh, il nostro utente si, la porta dove il servizio è in ascolto non è più la 22 ma la 19999 (o quella che hai scelto tu)
LAMP Server
Ripetiamo per l’ennesima volta che per installare Wordpress abbiamo bisogno di un LAMP Server.
LAMP, per chi non lo ha capito, indica Linux (sistema operativo), Apache (il web server), MySQL (il database dove vengono inseriti i dati) e PHP (Il linguaggio di programmazione utilizzato nella piattaforma).
I fornitori di Hosting adottano questa soluzione per fornirci lo spazio e gli strumenti necessari a costruire i nostri blog/siti web.
Esistono varianti (ad esempio LEMP), dove cambia il web server, per il resto la struttura è la stessa ovunque, diversa nelle versioni di PHP e MySQL.
Su molte installazioni VPS il web server è già installato. Per chi non lo ha di default installarlo con
sudo apt-get update
sudo apt-get install apache2
Se vogliamo imparare a gestire al meglio un VPS questi comandi dobbiamo memorizzarli e scolpirli nella nostra mente.
Possono differire a seconda della tipologia di sistema operativo utlizzato, ma sintatticamanete sono gli stessi.
Parole come service, restart, stop, start, sudo dobbiamo farle nostre, il tempo dobbiamo utilizzarlo per il nostro blog, business o quello che vuoi, e non a smanettare sul server (a parte chi vuole imparare a gestire un server linux, ma non è questa la guida adatta)
Al termine dell’installazione il web server è pronto all’uso.
Possono differire a seconda della tipologia di sistema operativo utlizzato, ma sintatticamanete sono gli stessi.
Parole come service, restart, stop, start, sudo dobbiamo farle nostre, il tempo dobbiamo utilizzarlo per il nostro blog, business o quello che vuoi, e non a smanettare sul server (a parte chi vuole imparare a gestire un server linux, ma non è questa la guida adatta)
Al termine dell’installazione il web server è pronto all’uso.
Per testarlo, apri il browser della macchina virtuale (abbiamo installato la versione desktop di Lubuntu, quindi in basso a sinistra clicca sul logo e naviga nel menu Internet -->Firefox) e digita l’indirizzo http://localhost per vedere la pagina di benvenuto di default di Apache.
Procediamo con MySQL, il database dove risiederanno i nostri dati, e la libreria che permetterà di far interagire il web server, php ed il database.
sudo apt-get install mysql-server php5-mysql
Possiamo notare che a differenza di CentOS ci viene chiesto di inserire subito la password di root (del MySQL, non del server!). Annotiamo bene quella che scegliamo, inseriamola due volte ed andiamo avanti.
Abbiamo installato il servizio e le librerie MySQL, non la base dati. Per completare l’installazione dobbiamo compiere ancora alcuni passi. Partiamo con il database vero e proprio.
sudo mysql_install_db
L’installazione del database porterà in pancia anche funzionalità che per motivi di sicurezza andremo a rimuovere subito dopo.
Passiamo dunque alla prima vera fase di hardening di MySQL, rimuovendo il database di test, la possibilità di far loggare il root di MySQL da remoto e non permettendo accessi anonimi con
sudo mysql_secure_installation
sudo mysql_install_db
L’installazione del database porterà in pancia anche funzionalità che per motivi di sicurezza andremo a rimuovere subito dopo.
Passiamo dunque alla prima vera fase di hardening di MySQL, rimuovendo il database di test, la possibilità di far loggare il root di MySQL da remoto e non permettendo accessi anonimi con
sudo mysql_secure_installation
Per ora abbiamo terminato con MySQL, ci torneremo sopra più tardi, quando parleremo di Wordpress nello specifico. Se vuoi aggiungere ulteriore sicurezza al database, rivedi i passaggi effettuati qui.
Per ultimare l’installazione del LAMP Server manca l’ultimo pezzo, il PHP, e le librerie per farlo interagire con Apache e Wordpress.
sudo apt-get install php5 libapache2-mod-php5 php5-mcrypt
Per rendere effettivi I cambiamenti ed abilitare il PHP in Apache riavviamo il web server con
sudo service apache2 restart
Ripetiamo per chi avesse saltato la sezione dedicata a CentOS che PHP mette a disposizione dell’utente una serie di moduli per incrementare le funzionalità del web server.
Installa solo quello che serve realmente, altrimenti corri il rischio di esporre il VPS a vulnerabilità inutili,senza aver bisogno realmente di un dato modulo.
sudo service apache2 restart
Ripetiamo per chi avesse saltato la sezione dedicata a CentOS che PHP mette a disposizione dell’utente una serie di moduli per incrementare le funzionalità del web server.
Installa solo quello che serve realmente, altrimenti corri il rischio di esporre il VPS a vulnerabilità inutili,senza aver bisogno realmente di un dato modulo.
Se installi un plugin per Wordpress e questo ha la necessità di un modulo in particolare, lo troverai espressamente scritto nelle istruzioni di installazione (ma è un’ipotesi molto rara).
Purtroppo su un hosting condiviso non abbiamo il controllo dei moduli, possiamo farcene un’idea creando la classica pagina di info (da rimuovere subito dopo!) dove ci vengono elencate le estensioni installate.
In caso di vulnerabilità possiamo sempre far presente al fornitore di hosting di adeguarsi.
Se non sai come creare la pagina info.php ecco un esempio
sudo vi /var/www/html/info.php
Inserisci nella pagina vuota (premi i per inserire caratteri con vi)
<?php
phpinfo();
?>
Ora che abbiamo realmente allineato le due macchine virtuali possiamo passare all’hardening di Apache, MySQL per Wordpress e PHP, ovvero nel mettere in atto una serie di accorgimenti per rendere più sicuro il nostro server.
Se la scelta è quella di amministrare Wordpress tramite VPS, l’hardening non è un’opzione ma una necessità.
Personalmente consiglio sempre di adottare la scelta di un VPS se si ha bene in mente cosa comporta, soprattutto in termini di tempo da dedicare (oltre alle configurazioni iniziali bisogna essere sempre aggiornati sulle nuove vulnerabilità per poi effettuarne il patching).
Le prestazioni che puoi raggiungere con un VPS non lo avrai nemmeno con il miglior fornitore di Hosting al mondo.
L'Hardening di Apache
Apache, come tutti i prodotti che si installano su una distribuzione linux, ha il suo file di configurazione dove è possibile agire per modificare le impostazioni di default.
Su un servizio di hosting, non potendo intervinire direttamente sul file di configurazione è possibile (anche se in maniera un po’ limitata) intervenire con il file .htaccess, un file che permette di estendere la configurazione del web server, ideale quando il servizio viene condiviso tra due o più utenti o configurazioni (hosting condiviso).
Su CentOS il file di configurazione si trova al percorso /etc/httpd/conf/httpd.conf, più il file ssl.conf della directory conf.d se intendiamo utilizzare l’SSL, mentre per Ubuntu le modifiche vanno fatte al file /etc/apache2/apache2.conf, più la directory conf.d per l’utilizzo dell’SSL.
Cambiano i nomi tra una distrubuzione e l'altra, ma non la sostanza.
Il file .htaccess e le sue modifiche dipendono dalla libertà che viene concessa dal file di configuazone generale.
Andiamo ad implementare le modifiche.
E’ molto importante eseguirne alla volta, se ne facciamo troppe insieme e qualcosa va storto sarà più difficile risalire alla causa del problema.
Se la modifica avviene sul file .htaccess non è necessario riavviare il webserver, le nuove istruzioni sono istantanee, mentre le modifiche fatte al file di configurazione principale richiedono il riavvio del servizio.
Ora si inizia a fare sul serio, e per poter amministrare un server è obbligatorio saper leggere i file di log.
Questi file contengono informazioni su tutto ciò che accade all’interno del prodotto, e per quanto riguarda Apache vedremo chi fa cosa ed in che modo, se può farlo o se è intervenuta una regola di sicurezza che abbiamo implementato. Su qualsiasi distribuzione linux attraverso il terminale o la shell in ssh che puoi aprire con Putty se utilizzi Windows, utilizzando il comando tail –f nomefiledilog (ad esempio il file dei log del webserver) abbiamo in tempo reale tutto ciò che sta accadendo su Apache.
ServerSignature
La prima informazione che non dobbiamo dare è la tipologia e la versione del Web Server che utilizziamo ed il sistema operativo in uso.
Tramite questa informazione è possibile verificare le vulnerabilità note del web server e di conseguenza studiare l’attacco da portare a termine. Apache ha l’opzione ServerSignature con la quale firma le pagine di errore e le risposte alle chiamate telnet.
Tramite questa informazione è possibile verificare le vulnerabilità note del web server e di conseguenza studiare l’attacco da portare a termine. Apache ha l’opzione ServerSignature con la quale firma le pagine di errore e le risposte alle chiamate telnet.
Vediamo in pratica due esempi, la correttiva da effettuare ed il risultato finale. Dalla macchina virtuale apriamo il terminale e digitiamo (l’esempio si rifersice alla macchina virtuale CentOS)
telnet localhost 80
Se il comando telnet non è installato
sudo yum install telnet
Alla nostra chiamata il server risponderà
Trying ::1...
Connected to localhost.
Escape character is '^]'.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>501 Method Not Implemented</title>
</head><body>
<h1>Method Not Implemented</h1>
<p>^ to / not supported.<br />
</p>
<hr>
<address>Apache/2.2.15 (CentOS) Server at localhost.localdomain Port
80</address>
</body></html>
Connection closed by foreign host.
Connected to localhost.
Escape character is '^]'.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>501 Method Not Implemented</title>
</head><body>
<h1>Method Not Implemented</h1>
<p>^ to / not supported.<br />
</p>
<hr>
<address>Apache/2.2.15 (CentOS) Server at localhost.localdomain Port
80</address>
</body></html>
Connection closed by foreign host.
Con un banalissimo comando abbiamo trovato informazioni sul tipo di web server (Apache), la versione (2.2.15) ed il sistema operativo in uso (CentOS).
Queste informazioni non vanno mai date. Chi sta progettando un attacco ha ricevuto informazioni preziose, va alla ricerca delle vulnerabilità note per quelle specifiche versione ed agisce di conseguenza.
Modifichiamo il ServerSignature nella configurazione di Apache da
ServerSignature On
a
ServerSignature Off
Salviamo e riavviamo il servizio, per CentOS
sudo yum service httpd restart
mentre per Ubuntu
sudo service apache2 restart
Il risultato che ci aspettiamo è l’eliminazione della firma del server
<address>Apache/2.2.15 (CentOS) Server at localhost.localdomain Port 80</address>
Proviamo ad effettuare nuovamente la chiamata in telnet, ma stavolta il risulto sarà diverso:
Trying ::1...
Connected to localhost.
Escape character is '^]'.
^
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>501 Method Not Implemented</title>
</head><body>
<h1>Method Not Implemented</h1>
<p>^ to / not supported.<br />
</p>
</body></html>
Connection closed by foreign host.
Su hosting condiviso lo stesso risultato lo possiamo ottenere inserendo all’interno del file .htaccess (lo possiamo creare noi se non c'è)
# Disabilito la firma del Server in caso di errore
ServerSignature Off
Il file .htaccess
Abbiamo accennato all’utilizzo del file .htaccess, ma a cosa serve veramente e perché vieneutilizzato?
In alcune circostanze può essere necessario limitare l'accesso ad una o più sottodirectory del nostro sito o impartire particolari direttive da far rispettare al web server.
Per gestire tali limitazioni di accesso possiamo intervenire sulle singole directory mediante il file .htaccess.
Nel tempo sono state elaborate configurazioni ad hoc per Wordpress, che all’interno della sua cartella di installazione fa utilizzo di questo file.
Il perché sia così utilizzato lo dobbiamo proprio all’espandersi dei servizi di hosting che non permettono di configurare il web server, perché condiviso con altri utenti (hosting condiviso), lasciando la possibilità, seppur limitata, a chi ne abbia le capacità di poter configurare un file ad hoc. (le limitazioni si hanno quando con una direttiva nel file .htaccess proviamo ad inserire una configurazione che interviene a livello globale)
Vediamo alcune configurazioni tipiche, con la spiegazione e l’effetto che avrà sul web server.
Prima di iniziare però, dobbiamo metterci alla pari di chi utlizza un servizio di hosting.
Per poter utilizzare il file .htaccess dobbiamo modificare l’impostazione AllowOverride nel file di configurazione di Apache, andando a modificare
<Directory "/var/www/html">
AllowOverride None
con
<Directory "/var/www/html">
#utilizziamo il file .htaccess
AllowOverride All
Riavviamo il web server ed iniziamo. Da questo momento in poi non sarà più necessario riavviare il
servizio, perché è un’operazione che su hosting non si può fare e noi il servizio di hosting stiamo cercando di emulare.
Le modifiche al file .htaccess sono istantanee non appena il file viene salvato.
servizio, perché è un’operazione che su hosting non si può fare e noi il servizio di hosting stiamo cercando di emulare.
Le modifiche al file .htaccess sono istantanee non appena il file viene salvato.
Mi raccomando, una modifica per volta, perché in caso di errore sarà più facile effettuare un’analisi sulle problematiche.
La prima da provare è sicuramente proteggere il file .htaccess da se stesso, impedendo a chiunque lo richiami nel browser con la speranza di aver accesso alle informazioni contenute in esso.
Il risultato dovrà essere un errore 403 Forbidden, alias stai accedendo ad una risorsa di cui non ne possiedi l’autorizzazione.
Nessuno deve aver il permesso di chiamarlo tramite browser, neanche tu, quindi neghiamo a tutti la possibilità di invocarlo.
Noi, quando abbiamo una nuova versione del file da caricare sul server lo faremo tramite sFTP.
# Vogliamo impedire l’accesso al file .htaccess
<Files .htaccess> #La regola vale solo per questo file
order allow,deny #Regola che definisce l’autorizzazione o la negazione
deny from all #Dichiarazione di negazione di accesso da parte di chiunque
</Files> #Tag di chiusura della regola
<Files .htaccess> #La regola vale solo per questo file
order allow,deny #Regola che definisce l’autorizzazione o la negazione
deny from all #Dichiarazione di negazione di accesso da parte di chiunque
</Files> #Tag di chiusura della regola
Come appena visto, per negare l’accesso ad un file in particolare la regola generale è
# Nego l’accesso al file
<Files nomefile.estensione> #può essere qualsiasi file, .html, .php, .jpg,.doc e cosi via
order allow,deny
deny from all
</Files>
Impedire il directory listing
Un’altra direttiva da inserire nel file .htaccess è l’impossibilità di effettuare il Directory Listing di una cartella, visualizzare cioè i file e le cartelle presenti nel percorso inserito e poterli sfogliare direttamente dal browser.
Questo è possibile se dove si trova la cartella non è presente nessun file index.html o index.php.
Prova a creare una cartella all’interno del path /var/www/html e un file vuoto dentro di essa.
Da riga di comando, sia su Ubuntu che su CentOS
sudo mkdir /var/www/html/cartella
sudo touch /var/www/html/cartella/file.txt
Ora sul browser della macchina virtuale digitiamo
Questo è il risultato:
Ora scriviamo qualcosa nel file di testo
vi /var/www/html/cartella/file.txt
Ora clicchiamo su file.txt nel browser
Di default Apache ha il directory listing abilitato.
Se siamo su un hosting probabilmente l’opzione è già disabilitata, se così non fosse vuol dire che è possibile esplorare tutte le cartelle dove non sia presente un file di indice (wp-includes/ per farvi un esempio banale in Wordpress).
Vediamo come non permettere tutto questo.
Inseriamo nel file .htaccess la direttiva
# Disabilitare il Directory Listing
Options All –Indexes
Questo dovrebbe già bastare.
Se dopo questa modifica, sul vostro hosting, non riuscite a disabilitare il directory browsing, non disperiamo.
Questa soluzione, sebbene possa sembrare un po’ rimediata, in alcuni casi è l’ultima spiaggia, e per fortuna funzionante, perché non sempre si può avere il controllo totale sul prodotto.
Se dopo questa modifica, sul vostro hosting, non riuscite a disabilitare il directory browsing, non disperiamo.
Questa soluzione, sebbene possa sembrare un po’ rimediata, in alcuni casi è l’ultima spiaggia, e per fortuna funzionante, perché non sempre si può avere il controllo totale sul prodotto.
Creiamo un file index.php vuoto ed abbiamo disabilitato la funzionalità non voluta.
Il risultato di un file vuoto di nome index.php è una pagina bianca che non consente di andare oltre.
Ripetilo per tutte le cartelle dove non è presente un file di tipo index.
Pagine di Errore Custom
E’possibile personalizzare le pagine di errore che il server deve mostrare al verificarsi di un evento.
La più famosa, che ha spinto i Designer a scatenare la propria fantasia, è la pagina 404, quella che viene mostrata all’utente che effettua una ricerca su una risorsa non presente.
Utilizzare la stessa pagina per tutti gli errori (o crearne diverse che non diano immediatamente percezione dell’errore, è un buon deterrente per la maggior parte dei curiosi (anche se poi è la più facile da trovare).
Facendo uso del file .htaccess è possibile inserire
# le mie pagine di errore
ErrorDocument 400 /custom/400.html
ErrorDocument 401 /custom/401.html
ErrorDocument 403 /custom/403.html
ErrorDocument 404 /custom/404.html
ErrorDocument 500 /custom/500.html
ed il nostro webserver mostrerà le pagine indicate.
Andiamo a creare quindi la cartella custom, le pagine custom ed inseriamo anche un file index.php per evitare il directory browsing
mkdir /var/www/html/custom
touch /var/www/html/custom/401.html
touch /var/www/html/custom/401.html
touch /var/www/html/custom/402.html
touch /var/www/html/custom/403.html
touch /var/www/html/custom/404.html
touch /var/www/html/custom/404.html
touch /var/www/html/custom/index.php
touch /var/www/html/custom/401.html
touch /var/www/html/custom/401.html
touch /var/www/html/custom/402.html
touch /var/www/html/custom/403.html
touch /var/www/html/custom/404.html
touch /var/www/html/custom/404.html
touch /var/www/html/custom/index.php
Qui lavoriamo con la fantasia....io non troppo....modifichiamo l’html dei file, lascio a te la fantasia e la creatività,
Verifica il risultato chiamando /custom/pagina.html nel browser all’indirizzo localhost.
Posto per comodità un esempio banale, e copierò poi la pagina rinominadolo con le altre pagine di errore.Il risultato sarà lo stesso per tutti gli errori, in modo da non far avere all’utente la reale percezione dell’errore.
Verifica il risultato chiamando /custom/pagina.html nel browser all’indirizzo localhost.
Posto per comodità un esempio banale, e copierò poi la pagina rinominadolo con le altre pagine di errore.Il risultato sarà lo stesso per tutti gli errori, in modo da non far avere all’utente la reale percezione dell’errore.
<HTML>
<HEAD>
<TITLE>Uh oh</TITLE>
</HEAD>
<BODY BGCOLOR="ffffff">
<center><H1><font color="000000">Qualcosa non va</font></H1></center>
</br>
</br>
<p><font color="000000">Lorem Ipsum è un testo segnaposto utilizzato nel
settore della tipografia e della stampa. Lorem Ipsum è considerato il testo
segnaposto standard sin dal sedicesimo secolo, quando un anonimo tipografo
prese una cassetta di caratteri e li assemblò per preparare un testo
campione. È sopravvissuto non solo a più di cinque secoli, ma anche al
passaggio alla videoimpaginazione, pervenendoci sostanzialmente inalterato.
Fu reso popolare, negli anni ’60, con la diffusione dei fogli di caratteri
trasferibili “Letraset”, che contenevano passaggi del Lorem Ipsum, e più
recentemente da software di impaginazione come Aldus PageMaker, che
includeva versioni del Lorem Ipsum.</font></p>
</BODY>
</HTML>
Server Tokens
Il ServerTokens della configurazione di Apache indica quante e quali informazioni vengono inviate dal server nell'header (analogamente al Server Signature, ma piú approfondito).
Può essere utile modificare il valore di default per una questione di sicurezza: abbiamo giá detto in precedenza che meno informazioni forniamo sul nostro server, sulla versione di Apache e sui moduli installati, e meno facile sarà trovare una vulnerabilità per entrare dentro.
Può essere utile modificare il valore di default per una questione di sicurezza: abbiamo giá detto in precedenza che meno informazioni forniamo sul nostro server, sulla versione di Apache e sui moduli installati, e meno facile sarà trovare una vulnerabilità per entrare dentro.
Molti servizi di hosting non permettono di configurare il ServerTokens tramite file .htaccess, perché tenta di sovrascrivere la configurazione globale.
Fai un test, se dopo averlo inserito il tuo sito risponde con un errore 503 (errore server), toglilo.
Verifica che il server token non sia impostato a Full, altrimenti puoi sempre segnalarlo al tuo fornitore.
Se utilizzi un Virtual Private Server, queste sono le configurazioni possibili, con le risposte fornite dal server:
ServerTokens Full
Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny3 with Suhosin-Patch Server at localhost
Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny3 with Suhosin-Patch Server at localhost
ServerTokens OS
Apache/2.2.9 (Debian) Server
Apache/2.2.9 (Debian) Server
ServerTokens Minimal
Apache/2.2.9 Server
Apache/2.2.9 Server
ServerTokens Minor
Apache/2.2 Server
Apache/2.2 Server
ServerTokens Major
Apache/2 Server
Apache/2 Server
ServerTokens Prod
Apache Server
Apache Server
Vedremo piú avanti come Wordpress utilizza il file .htaccess per i suoi scopi, per ora abbiamo fatto buona parte del lavoro ottimizzando il web server, parliamo del tuning del database in relazione a Wordpress.
MySQL Hardening per Wordpress
In realta non parleremo ora dell'hardening vero e proprio perchè ancora non abbiamo installato Wordpress e perchè verrà dedicato un post a parte, essendo questo già lungo di suo.
Durante l’installazione di MySQL abbiamo giá effettuato le prime ottimizzazioni, impostando una buona password per l’utenza di root, rimuovendo il database di test e l’accesso tramite utente anonimo.
Quando lavoriamo su un VPS queste operazioni vanno sempre fatte, é imperativo per non correre rischi inutili.
Quando lavoriamo su un VPS queste operazioni vanno sempre fatte, é imperativo per non correre rischi inutili.
Su un servizio di hosting il nostro fornitore ha giá ottimizzato l’installazione e tramite una interfaccia grafica (solitamente nel nostro pannello di controllo abbiamo a disposizione phpMyAdmin o software similari) ci permette di amministrare i nostri database.
Per usufruire dell’interfaccia di amministrazione ci viene fornita un’utenza che avrá i permessi per creare database, inserire utenze privilegiate al’interno di essi per delineare iI confine di dove un’utenza inizia a comandare su un database e dove questo potere finisce.
Cosa possiamo fare ancora per aumentare la sicurezza del nostro MySQL?
Possiamo progettare e non buttarci a capofitto nelle installazioni, perché una buona pianificazione potrá farci risparmiare tempo nella gestione futura.
Per poter memorizzare questa scaletta nelle future installazioni, armati di carta e penna, tra un po’di tempo avrai ben chiara la situazione e non dovrai tornare a leggere di nuovo.
Stai per creare la tua metodologia alla difesa di Wordpress.
Non usare un database per gestire piú di un’installazione. Metteresti a rischio due blog/siti invece che uno, perché come vedremo tra poco, temi e plugin sono soggetti a vulnerabilitá.
La prima faccenda da sbigare é decidere quale sará il suffisso delle tabelle che wordpress andrá ad installare.
Tutte le tabelle per default usano wp_ come suffisso seguito dal nome della tabella.
I tools che permettono di scandagliare le installazioni di Wordpress come prima cosa vanno
proprio a cercare le tabelle wp_ , quindi inizieremo proprio da qui, visto che durante l’installazione ci verrá chiesto se vogliamo modificare questo valore.
Il secondo passo, ancora piú importante, é la definizione degli utenti che amministrano Wordpress.
Mi capita spesso di vedere installazioni dove l’amministratore di Wordpress é lo stesso autore dei post. Mai scelta fu piú sbagliata. Wordpress tramite una query nella barra degli indirizzi del browser ci puó fornire indicazioni sull’identità dell'amministratore di Wordpress.
Su un database ogni voce ha un suo Id, identificativo che lo rende univoco rispetto alle altre voci contenute nella tabella. Il valore Id degli utenti é autoincrementale, quindi se creo due utenti nella tabella users il primo creato in fase di installazione ha valore uguale ad 1, mentre il secondo avrà 2.
I tools che permettono di scandagliare le installazioni di Wordpress come prima cosa vanno
proprio a cercare le tabelle wp_ , quindi inizieremo proprio da qui, visto che durante l’installazione ci verrá chiesto se vogliamo modificare questo valore.
Il secondo passo, ancora piú importante, é la definizione degli utenti che amministrano Wordpress.
Mi capita spesso di vedere installazioni dove l’amministratore di Wordpress é lo stesso autore dei post. Mai scelta fu piú sbagliata. Wordpress tramite una query nella barra degli indirizzi del browser ci puó fornire indicazioni sull’identità dell'amministratore di Wordpress.
Su un database ogni voce ha un suo Id, identificativo che lo rende univoco rispetto alle altre voci contenute nella tabella. Il valore Id degli utenti é autoincrementale, quindi se creo due utenti nella tabella users il primo creato in fase di installazione ha valore uguale ad 1, mentre il secondo avrà 2.
Fai un test su un’installazione che giá hai a disposizione (non quello di altri...) e prova a digitare nella barra degli indirizzi del browser
Analizziamo la composizione dell’indirizzo.
http://tuosito.it è l’indirizzo del sito e fin qui tutto normale.
Il punto interrogativo in un indirizzo web divide la richiesta della visualizzazione del sito da un inserimento, una query, ovvero una ricerca che viene inviata al server premendo invio. In questo caso stiamo chiedendo al sito di restituirci la pagina dell’autore che ha come identificativo 1.
Ci fa piacere che qualcuno ci cerchi e voglia saperne di più su di noi, peccato che l’Id uguale ad uno equivale all’utente che ha installato Wordpress, e di conseguenza siamo certi che è un’amministratore di Wordpress.
Il tuo nome utente è anche il nome che utilizzi per accedere alla console di amministrazione di Wordpress.
Per un attacco brute force hai fornito il 50% delle informazioni, l’attaccante si dovrá concentrare solo sulla password(sempre tu, anello debole della catena, se hai scelto Password.1 come password come ti senti adesso?).
Il nostro hardening provvederá a modificare l’Id dell’utente amministratore con un numero ma non solo...
Vogliamo che tutti gli utenti che verranno creati in futuro abbiano un Id incrementale rispetto alla nostra utenza, cosí da eliminare query sugli altri autori con Id 2,3 e cosi via.
So che l’idea ti sta piacendo e mi fa piacere.
Sicurezza come vedi non sempre è sinonimo di paranoia, per fare bene tutto quello che c’è scritto in questo blog ti basteranno due giorni quando avrai appreso i concetti, e credimi, sono due giorni ben investiti.
Nel post dove parleremo di WAF (Web Aplication Firewall) potremo anche disabilitare la query sugli autori in un colpo solo.
Subito dopo aver creato la nostra seconda utenza (perché lo hai fatto vero, o stai continuando ad usare l’utente con cui hai installato ed amministri Wordpress per scrivere gli articoli?), definiamo come gli utenti devono interagire con noi.
Abbiamo bisogno di utenti attivi sul nostro blog?
La risposta è ovviamente si, altrimenti il nostro sito non avrebbe ragione di esistere.
Ma abbiamo bisogno di averli definiti nel nostro database perché devono accedere ad aree riservate agli iscritti o devono semplicemente commentare i nostri articoli?
Devono poter scrivere articoli sul nostro blog oppure no?
Questa differenza è mostruosa. Datti le risposte a queste domande, perché nel caso in cui gli utenti hanno accesso al blog con una propria utenza dovrai educarli all’utilizzo di una buona password.
Si, proprio la password, perché le persone sono pigre, e per paura di dimenticare la password ne inseriscono una molto banale mettendo a repentaglio la sicurezza dell’intero blog.
Come fare ad educarli?
Costruendo una Password Policy ad hoc, e su Wordpress lo potrai fare tramite un plugin dedicato.
Una password policy puó essere vista come un insieme di regole che l’utente deve rispettare per poterne avere una password valida.
Gli amministratori di Wordpress, nel caso in cui fossero piú di uno, devono essere sempre soggetti ad un Password Policy.
Ora, per poter procedere con l’hardening non ci resta che installare il prodotto.
Il tuning di MySQL relativo a Wordpress avrá ampio spazio in un post dedicato...
Installiamo Wordpress
Finalmente tocchiamo con mano Wordpress e procediamo con l’installazione. Procuriamoci il setup della versione italiana all’indirizzo https://it.wordpress.org/ e salviamo il file zippato.
Ora dobbiamo decidere come caricare sul nostro server tutto l’occorrente.
La prima differenza la fa la tipologia di ambiente in uso, dato che su VPS possiamo effettuare una chiamata wget per scaricare il file direttamente sul server tramite connessione in ssh con il commando
wget https://it.wordpress.org/wordpress-4-3-1.it_IT.zip
( è l’ultima versione disponibile al momento della scrittura del post), per goderci il download del file sul server senza ricorrere al trasferimento dei file.
Su hosting abbiamo altre possibilitá, visto che tutti oramai offrono un servizio di autoinstaller (ottimo per i principianti, anche se a volte non é proprio l’ultima versione, quindi neanche partiti bisogna provvedere agli aggiornamenti), o scaricare in locale sul proprio pc per poi trasferire tramite sFTP
(articolo dedicato a parte,servirà a capire la differenza tra FTP ed sFTP).
Le nostre macchine virtuali simuleranno un VPS, e ricordati che saranno ottime compagne per lo sviluppo del blog, anche se utilizzi un servizio di hosting.
Qui potrai fare tutte le modifiche che vuoi prima di passarle sul blog che hai online, senza avere paura di aggiornamenti o installazioni di plugin.
Scompattiamo il file scaricato con il commando
unzip worpdress-4-3-1-it_IT.zip
e rinominiamo la cartella in blog
mv worpdress blog
Infine, dobbiamo copiarla dentro la directory /var/www/html con
cp –R blog /var/www/html
L’opzione –R serve per copiare tutto il contenuto delle varie cartelle di Wordpress, non dimenticarlo o le cartelle risulteranno vuote.
Rimane un ultimo passaggio, molto importante. Dobbiamo assegnare ad Apache i permessi e la proprietá della cartella blog.
Tutti i file che risiedono all’interno della directory /var/www/html sono pubblicati su internet, mostrano quindi tutto quello che noi pubblichiamo all’interno di questo percorso. Il web server Apache deve sempre avviare il suo servizio con un’utenza dedicata e facente parte di un gruppo con limiitazioni ben precise che in CentOS é chiamata apache, mentre su Ubuntu www-
data.
Rimane un ultimo passaggio, molto importante. Dobbiamo assegnare ad Apache i permessi e la proprietá della cartella blog.
Tutti i file che risiedono all’interno della directory /var/www/html sono pubblicati su internet, mostrano quindi tutto quello che noi pubblichiamo all’interno di questo percorso. Il web server Apache deve sempre avviare il suo servizio con un’utenza dedicata e facente parte di un gruppo con limiitazioni ben precise che in CentOS é chiamata apache, mentre su Ubuntu www-
data.
Quindi, prima di cimentarsi nell’installazione di Wordpress su CentOS digitiamo nel terminale della shell
sudo chown –R apache:apache /var/www/html/blog
mentre su Ubuntu
sudo chown –R www-data:www-data /var/www/html/blog
Siamo finalmente pronti per l’installazione, andiamo a creare il database che successivamente saráoggetto di tuning.
L’obiettivo é creare un database ed un’utenza che abbia i privilegi per scrivere all’interno di esso.
Se utilizzi PhpMyAdmin basterá collegarti all’interfaccia di amministrazione, se invece sei su VPS e non hai instalato il software (saggia decisione), dovrai collegarti in shh al server, utilizzare il client di MySQL digitando
Se utilizzi PhpMyAdmin basterá collegarti all’interfaccia di amministrazione, se invece sei su VPS e non hai instalato il software (saggia decisione), dovrai collegarti in shh al server, utilizzare il client di MySQL digitando
mysql –u root –p
e inserire la password di amministrazione di MySQL che hai inserito in fase di installazione.
Ricordati di cambiare root con il nome utente specifico se lo hai rinominato.
Ora, su PhpMyAdmin spostati sul tab SQL, mentre su VPS sei giá pronto per inserire la query
Ricordati di cambiare root con il nome utente specifico se lo hai rinominato.
Ora, su PhpMyAdmin spostati sul tab SQL, mentre su VPS sei giá pronto per inserire la query
Inseriamo la query per creare il database e l’utenza ammnistratrice. Ad ogni query premi Esegui per effettuarla.
create database mioblog;
La risposta deve essere
Ora volutamente commetterò qualche piccolo sbaglio per farti vedere i problemi più comuni in fase di installazione e come porre rimedio per raggiungere il nostro scopo, installare Wordpress.
La seconda query serve a creare l’utenza myblogdbuser, dargli la password Sekurity@2015 ed assegnare all’utenza i privilegi di amministrazione del database myblog.
grant all privileges on mioblog.* to 'myblogdbuser' identified by
'Sekurity@2015' with grant option;
L’ultima query ci permette di rendere effettive da subito le modifiche che abbiamo effettuato, ricaricando il database ed I relative privilegi.
flush privileges;
Ora queste informazioni andranno inserite nel file wp-config.php di Wordpress, perché consentiranno al software di stabilire la connessione tra l’applicazione che impartirá le istruzioni e il database, dove queste informazioni saranno salvate.
Riprendendo il nostro discorso sull’hardening di Wordpress andiamo subito ad eliminare i file che non sono necessari per il funzionamento e che possono dare informazioni importanti in merito al prodotto che utilizziamo e la sua versione in uso.
Riprendendo il nostro discorso sull’hardening di Wordpress andiamo subito ad eliminare i file che non sono necessari per il funzionamento e che possono dare informazioni importanti in merito al prodotto che utilizziamo e la sua versione in uso.
Da cancellare, subito, I file LEGGIMI.txt,license.txt,licenza.html e readme.html.
Per dovere di cronaca, se chiamate l’indirizzo http://localhost/blog/readme.html questo é lo scenario che ti si propone....
Questa pagina é raggiungibile anche dopo aver installato Wordpress, quindi queste operazioni di smaltimento é meglio farle subito, o rischiamo di incappare in un clamoroso autogol.
Come vedi fornisce la versione di Wordpress in uso. Matt, ti ringraziamo, ma ti dobbiamo cancellare...
Come vedi fornisce la versione di Wordpress in uso. Matt, ti ringraziamo, ma ti dobbiamo cancellare...
Giuro che stavolta iniziamo veramente.
Per i meno esperti (ma anche per i piú) é buona cosa tenere il file wp-config-sample.php intatto, farne una copia da rinominare in wp-config.php e tenerlo fino a quando non abbiamo terminato con l’installazione.
Se qualcosa va storto abbiamo sempre una via di fuga per poter ricominciare.
Questo file é molto importante e piú andremo avanti con l’ottimizzazione di Wordpress piú sará necessario effettuarne un backup prima dell’ennesima modifica.
Se qualcosa va storto abbiamo sempre una via di fuga per poter ricominciare.
Questo file é molto importante e piú andremo avanti con l’ottimizzazione di Wordpress piú sará necessario effettuarne un backup prima dell’ennesima modifica.
Al backup é dedicato un post dedicato, ma é bene entrare da subito nell’ottica delle copie di sicurezza come processo attivo all’interno delle nostre attivitá.
In questo modo possiamo sovrascrivere il file in caso di errore, senza dovre rifare tutto dall’inizio.
In questo modo possiamo sovrascrivere il file in caso di errore, senza dovre rifare tutto dall’inizio.
Da dove cominciamo? Dobbiamo stabilire la connessione tra l’applicazione ed il database, inserendo all’interno del file wp-config.php:
// ** Impostazioni MySQL - È possibile ottenere queste informazioni dal
proprio fornitore di hosting ** //
/** Il nome del database di WordPress */
define('DB_NAME', 'nome_del_database_qui');
/** Nome utente del database MySQL */
define('DB_USER', 'nome_utente_qui');
/** Password del database MySQL */
define('DB_PASSWORD', 'password_qui');
/** Hostname MySQL
*/
define('DB_HOST', 'localhost');
Seguendo le installazioni che abbiamo fatto insieme per noi sará (fai attenzione con il copia ed incolla con gli apici)
// ** Impostazioni MySQL - È possibile ottenere queste informazioni dal
proprio fornitore di hosting ** //
/** Il nome del database di WordPress */
define('DB_NAME', 'mioblog');
/** Nome utente del database MySQL */
define('DB_USER', 'myblogdbuser');
/** Password del database MySQL */
define('DB_PASSWORD', 'Sekurity@2015');
/** Hostname MySQL
*/
define('DB_HOST', 'localhost');
Salviamo ed andiamo sul browser all’indirizzo http://locahost/blog per avviare l’installazione.
Se invece vedi questo messaggio di errore, ricontrolla le informazioni che hai inserito perché qualcosa impedisce all’applicazione di connettersi con il database (tra poco mi odierai).
Se invece vedi questo messaggio di errore, ricontrolla le informazioni che hai inserito perché qualcosa impedisce all’applicazione di connettersi con il database (tra poco mi odierai).
Se ancora non riesci a stabilire una connessione con il database non disperare, c’é sempre una via di fuga. Cancella il file wp-config.php creato in precedenza e Wordpress non trovandolo ti aiuterá a configurarlo tramite il browser.
Te lo potevo dire prima?
No, dobbiamo imparare a maneggiare i file di Wordpress, quindi era necessario. Apriamo nuovamente il browser all’indirizzo http://localhost/blog e seguiamo le istruzioni a video.
Oltre alle informazioni che abbiamo inserito nel file wp_config, vediamo il primo passo di hardening materializzarsi, il suffisso da dare alle tabelle create da Wordpress.
Potevamo farlo anche nel file di configurazione, ma ho aspettato questo momento per allineare le installazioni tra hosting e VPS.
Te lo potevo dire prima?
No, dobbiamo imparare a maneggiare i file di Wordpress, quindi era necessario. Apriamo nuovamente il browser all’indirizzo http://localhost/blog e seguiamo le istruzioni a video.
Oltre alle informazioni che abbiamo inserito nel file wp_config, vediamo il primo passo di hardening materializzarsi, il suffisso da dare alle tabelle create da Wordpress.
Potevamo farlo anche nel file di configurazione, ma ho aspettato questo momento per allineare le installazioni tra hosting e VPS.
Ora che abbiamo tutto a portata di mano finalmente procediamo con il setup.
Il suffisso che ho scelto per la demo sono tutte le consonanti della parola mioblog.
Vediamo se tutto stavolta procede per il meglio.(ora mi odierai ancora di più)
Ancora non ci siamo.E sai perché? I piú esperti hanno giá capito e corretto l’errore, spieghiamo anche a chi non fa di web server e database il suo pane quotidiano cosa sta accaddendo.
MySQL fa distinzione tra utenti che possono accedere in remoto al db ed utenti che possono accedere al database solo in locale, sul server dove é installato il servizio (localhost)
Se abbiamo piú di un VPS e il database si trova su un server diverso dal web server dove verrá installato Wordpress la configurazione é gia funzionante.
Su hosting bisogna verificare a quale tipo di configurazione corrisponde il nostro pacchetto.
Se ci vengono fornite informazioni specifiche sul database vuol dire che si trova su un server diverso rispetto a dove si trova Apache (o chi per lui).
Se invece si trova tutto sulla stesso server (come nella nostra macchina virtuale), dobbiamo rimettere mano al MySQL, tramite PhpMyAdmin o tramite ssh per VPS, ed aggiungere l’utente che deve avere accesso in localhost al database mioblog.
Se abbiamo piú di un VPS e il database si trova su un server diverso dal web server dove verrá installato Wordpress la configurazione é gia funzionante.
Su hosting bisogna verificare a quale tipo di configurazione corrisponde il nostro pacchetto.
Se ci vengono fornite informazioni specifiche sul database vuol dire che si trova su un server diverso rispetto a dove si trova Apache (o chi per lui).
Se invece si trova tutto sulla stesso server (come nella nostra macchina virtuale), dobbiamo rimettere mano al MySQL, tramite PhpMyAdmin o tramite ssh per VPS, ed aggiungere l’utente che deve avere accesso in localhost al database mioblog.
Da shell quindi
mysql –u root -p
use mioblog;
grant all privileges on mioblog.* to 'myblogdbuser'@'localhost' identified
by 'Sekurity@2015' with grant option;
by 'Sekurity@2015' with grant option;
flush privileges;
Invece da PhpMyAdmin, seleziona il database mioblog e nel tab SQL inserisci la query riportata sopra.
Eseguila e vedrai il messaggio per l’operazione andata a buon fine.
Eseguila e vedrai il messaggio per l’operazione andata a buon fine.
Ripeti il passaggio dell’installazione (tramite web, cosí vedremo cosa succede) e se hai svolto bene i compiti, questa sará la schermata dove il file di configurazione ha passato tutti i test.
Sempre per completezza di informazioni, il suffisso delle tabelle nel file di configurazione si trova
in
in
/**
* Prefisso Tabella del Database WordPress.
*
* È possibile avere installazioni multiple su di un unico database
* fornendo a ciascuna installazione un prefisso univoco.
* Solo numeri, lettere e sottolineatura!
*/
$table_prefix
= 'mblg_';
* Prefisso Tabella del Database WordPress.
*
* È possibile avere installazioni multiple su di un unico database
* fornendo a ciascuna installazione un prefisso univoco.
* Solo numeri, lettere e sottolineatura!
*/
$table_prefix
= 'mblg_';
Andiamo avanti con l’installazione e definiamo subito un concetto importante: l’utenza amministratrice di Wordpress.
Non puó e non deve essere l’utenza che dovrá scrivere gli articoli
del nostro blog, ma deve essere esclusivamente utilizzata per le operazioni straordinarie, come l’installazione di nuovi plugin e temi, procedure di backup e via dicendo.
del nostro blog, ma deve essere esclusivamente utilizzata per le operazioni straordinarie, come l’installazione di nuovi plugin e temi, procedure di backup e via dicendo.
Piú avanti dobbiamo effettuare l’hardening del database con l’identificativo dell’utente amministratore (piú altro), per essere tutti allineati definiamo come amminstratore l’utente baelfire (omaggio ad Once Upon a Time, per chi non l’ha visto serie TV consigliata) con password Ova1gam!2015 (oggi voglio andare un giorno al mare, non vuol dire nulla ma non é facilmente rintracciabile), mail e privacy fai come vuoi, sulla macchina virtuale non é importante, sul VPS direi
proprio di si.
proprio di si.
Inserisci un indirizzo mail che utilizzi spesso perché é qui che arriveranno tutte le notifiche sui
commenti, nuovi utenti, utenti bloccati, mailing list e via dicendo.
Come direbbe qualcuno che seguo con affetto inserisci “La tua migliore mail” (chi ha capito farà un sorriso...)
Ok, siamo pronti, é ora di fare la differenza.
E' stato un post molto lungo, come forse non mi capiterà mai più di scrivere, quindi ritengo doveroso inserire un sommario, diviso per argomenti di tutto quello che abbiamo visto per permettere di navigare rapidamente all'interno dell'articolo se hai bisogno di rivedere determinati passaggi.
- Installazione della macchina virtuale CentOS;
- il login come root;
- creazione di un nuovo utente;
- modifica della porta del servizo ssh;
- installazione LAMP server;
- primo hardening.
- Installazione della macchina virtuale Ubuntu;
- il login come root;
- creazione di un nuovo utente;
- modifica della porta del servizo ssh;
- installazione LAMP server.
- Server Signature;
- il file .htaccess;
- Server Tokens.
- Introduzione al tuning di MySQL specifico per Wordpress.
- Installazione di Wordpress e risoluzione problemi comuni in fase di installazione.
Se vuoi contribuire alla crescita di questo Blog e le informazioni contenute in esso ti sono state utili condivilo con i tuoi amici!
arulajeh.id Situs Berita Terbaru Dan Terbaik






























Tambahkan Komentar