Segue una lista di file e directory utilizzati da MySQL d'interesse per i nostri fini. La trattazione riguarda specificatamente la distribuzione Linux Debian/Ubuntu, anche se i concetti si estendono evidentemente ad ogni sistema operativo (*nix e non) utilizzato.
Posizione predefinita: /etc/mysql/my.cnf ed /etc/mysql/debian.cnf
Il file di configurazione principale (my.cnf) definisce comportamento ed organizzazione del filesystem del DBMS. Deve poter esser letto da tutti ma modificato solo da root; concordemente con questa logica, Debian definisce per my.cnf i seguenti permessi: nel caso siano stati modificati, si consiglia di riportarli in tale stato.
-rw-r--r-- [644] root root
Debian.cnf contiene username e password usati per l'utente amministrativo Debian debian-sys-maint. I suoi permessi devono rimanere come da default:
-rw------- [600] root root
L'utente di default con cui gira mysqld è mysql (gruppo mysql). Questo è un utente non privilegiato, senza possibilità di utilizzo della shell (la sua shell predefinita è /bin/false) e la sua directory home è /var/lib/mysql. Infatti:
ps aux | grep mysql root /bin/sh /usr/bin/mysqld_safe mysql /usr/sbin/mysqld -basedir=/usr [...]
Il processo padre, di proprietà di root, lancia all'avvio il server mysqld (attraverso lo script mysqld_safe) di cui appunto è proprietario mysql.
Posizione predefinita: /var/lib/mysql/
Directory (database) e file al loro interno (tabelle) devono esser di proprietà dell'utente mysql ed accessibili solo da questi; per ogni nuovo database creato dobbiamo assicurarci che la directory del database e tutti i file interni siano di proprietà di mysql:
chown -R mysql.mysql database/
tutti i file interni devono esser leggibili e scrivibili solo da mysql:
chmod -R 600 database/
la directory dev'esser però anche apribile (eseguibile) da mysql:
chmod 700 database
riavviare infine MySQL (che legge i permessi sulle directory solo al suo avvio):
/etc/init.d/mysql restart
L'eseguibile del server è posizionato in:
whereis mysqld mysqld: /usr/sbin/mysqld
ed ha permessi:
ls /usr/sbin/mysqld -rwxr-xr-x [755] root root
Impostazioni paranoiche prevedono di evitare a chiunque (tranne a mysql) di eseguire il server ed in special modo lo script mysqld_safe; principalmente però è d'importanza che esso non sia modificabile in scrittura da tutti. Il motivo? Poniamo venisse modificato da un aggressore: date un'occhiata all'utente con cui gira (!).
Il Pid file (memorizza l'id del processo del programma server) ed il file di socket hanno posizione predefinita nella directory /var/run/mysqld/. Il file di socket è un file "particolare" e non può esser eliminato facilmente; per mysqld.pid invece dobbiamo avere riguardi: evitare la modifica dei permessi rispetto a come riportato. Nel caso un file mancasse, riavviare MySQL (e fare un controllo sulla firma dell'eseguibile).
Tutti i file di log (in /var/logs/) devono essere ad accesso esclusivo per l'utente mysql (e root).
È buona norma abilitare, inoltre, il logging delle query lente, ovvero che impiegano "troppo" per esser eseguite: può aiutare ad evitare DoS del server voluto o accidentale (diciamo che non è "elegante" che un programma Web mal fatto crei un "auto-DoS" del server su cui gira) ed il log binario (log_bin) di cui si parlerà più avanti (conterrà ogni istruzione SQL impartita al server).
Nmap: tecniche per evadere un firewallVediamo come sfuggire ai controlli di un firewall utilizzando Nmap. |
Sfruttare vulnerabilità XSS con BeEFUsiamo BeEF per automatizzare lo sfruttamento di vulnerabilità Cross... |
Trojan Flashback: rimuoverlo da Mac OS XIndividuiamo e rimuoviamo il trojan Flashback da Mac OS X |
Individuare vulnerabilità in Joomla con JoomScanUsiamo JoomScan per verificare la sicurezza di Joomla e la presenza... |
XSS: attacchi avanzatiApprofondiamo le vulnerabilità Cross Site Scripting analizzando... |
Guida SQL Injection con SqlmapScopriamo se le nostre applicazioni web sono vulnerabili alle SQL... |
Guida sicurezza applicazioni WebLe tecniche di attacco più comuni, i metodi per verificare la... |
Guida Sicurezza wirelessQuali sono i pericoli di sicurezza di una rete senza filo e quali... |
Ogni lunedì, direttamente nella tua e-mail: approfondimenti e bollettini su virus, vulnerabilità e sicurezza informatica.
Iscriviti alla newsletter
|
|
Amministratore di Reti Windows Server 200811 Giugno 2012 a Milano |
|
Nessun corso previsto |