Newsgroup: it.comp.os.linux.sys
Titolo: Hardening mysql

Ciao a tutti.
Ho un utente mysql che può accedere solamente da un dato IP (quello del 
server web) che però ha i privilegi di grant e di create database.
Mi serve per automatizzare alcune procedure di creazione database.
Ovviamente è un insulto alla sicurezza.
Mysql è raggiungibile solo tramite phpmyadmin o via PHP (da fuori è 
segato via a colpi di iptables su più livelli).
Phpmyadmin è già stato patchato per non permettere il login tramite 
questo mio utente. (a colpi di "if $utente == 'abc'" etc etc)
Resta comunque il fatto che se un cliente in hosting dovesse scoprire 
user e pass di tale utente ci fa fritto tutto tramite una semplice 
connessione al db via PHP.
Qualche hint su come mettere in sicurezza tale procedura?

 Qualche hint su come mettere in sicurezza tale procedura?
Uhm... proposta stupida ma non si sa mai:
e dedicare un server mysql solo all'utente "che può tutto"? Al limite così 
potrà creare e distruggere db ma solo su quel server e lasci al sicuro i db 
degli altri clienti in hosting.

 Mi serve per automatizzare alcune procedure di creazione database.
I clienti sul server web cosa possono fare esattamente?
Perchè non assegnare un altro IP al tuo server che utilizzi solo tu e regoli
l'accesso per quell'utente mysql solo da quell'IP?
-- 
Vide

 Qualche hint su come mettere in sicurezza tale procedura?
Non sono un esperto ma non capisco il problema.
Se, ad esempio, hai un host remoto a cui vuoi accedere via SSH, se
qualcuno scopre le password sei comunque fritto.
Semplicemente puoi fare:
- creazione account che ha i privilegi di GRANT e creazione database.
  Questo account può collegarsi al database solo via SSL con certificati
- tutti gli account limitati possono collegarsi solo in locale, magari su
  socket unix (in questo modo sono accessibili tramite phpmyadmin)
Con PostgreSQL la cosa è possibile, spero lo sia anche con MySQL.
Saluti  Manlio Perillo

 degli altri clienti in hosting.
Deve creare db degli utenti in hosting. E' questo il punto.

 l'accesso per quell'utente mysql solo da quell'IP?
Spiega un po cosa intendi?

   socket unix (in questo modo sono accessibili tramite phpmyadmin)
phpmyadmin è sul server web e non sul server mysql.
Successivamente sarà piazzato sul server mysql quindi gli utenti saranno 
tutti locali (e così facendo posso chiudere gli accessi mysql a tutto il 
mondo eccetto il mio server web) ma fino ad allora non so come mettere 
in sicurezza la procedura.

 del loro.
Provo con un'altra ipotesi:
Apri la porta di MySQL (dal firewall) solo nei confronti di un IP.  Poi in 
MySQL associ l'utente solo a quell'IP (cosě se quell'utente viene utilizzato 
da localhost o da un altro IP non va comunque). E infine al "tipo che fa i 
db" fai usare qualcosa tipo MySQL-Front dal suo IP.

 
vabbè, è lo stesso discorso di dire "assegno login e password per leggere la 
posta ma un altro potrebbe beccarne uno esistente e leggere le email 
dell'altra persona" :-)
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
DeVries's Dilemma:
	If you hit two keys on the typewriter, the one you don't want
hits the paper.

 da una semplice password mysql e poi vedi...
Non per tirarmi sfiga addosso, ma a me non č mai successo che qualcuno abbia 
"beccato" la password di MySQL (ovviamente non č banale e l'utente root non 
esiste piů, č stato sostituito con uno meno "di default").

 dell'altra persona" :-)
Si però:
1- non me ne frega niente se un utente lascia la sua password di posta
facile facile. In questo caso son problemi suoi, dato che la posta è
la sua. Le password generate da noi sono tipo "f43tgg" poi se uno la
cambia e mette qualcosa tipo "ciao" son affari suoi.
2- beccare questo mio superutente singnifica aver la possibilità di
demolire tutto il server in un colpo solo ed in questo caso è un
problema mio perchè l'utente con password era il mio e serviva a me.

 db" fai usare qualcosa tipo MySQL-Front dal suo IP.
Ma quale tipo che fa i db e quale mysqlfront.
I db vengono creati tramite procedura automatica via web da php.
Quindi niente mysqlfront e niente tipo che crea i db.
P.S: di soluzioni aggiungendo schede di rete o vlan ce ne sono. ma non
posso ne creare vlan ne aggiungere reti per amministrazioni.
Ho bisogno di una soluzione 'software'.

 
Ok.
Ma non hai detto di aver patchato phpmyadmi in modo che non accetti login
sul tuo super utente?
Saluti  Manlio Perillo

 Ho bisogno di una soluzione 'software'.
Assegna alla scheda che hai un IP nuovo della stessa subnet e che sia
disponibile, configuri l'Apache su cui gira il PHP che crea sti database
con un virtualhost che si colleghi a quest'altra IP (e lo utilizzerai solo
e soltanto tu sto VH) e accetti connessioni a mysql solo da questo IP. O ti
crea altri problemi?
-- 
Vide

 sul tuo super utente?
Si, infatti da li non possono accedere.
Però un programmatore PHP e ne ho parecchi in hosting potrebbe fare
(direttamente da php e no da phpmyadmin) qualcosa tipo "SHOW
DATABASES" e i rispettivi drop.
Non mi preoccupa affatto phpmyadmin, ma mi preoccupa il php scritto a
mano. O eventuali phpmyadmin installati manualmente dal cliente senza
passare per il mio.
Credo che la soluzione più semplice sia quella di aggiungere un server
per la mia amministrazione (è già stato pianificato il nuovo server,
ma per metterlo in funzione ci vuole un bel po di tempo) connesso a
mysql tramite vlan dedicata. In questo modo il mio superutente mysql
sarebbe limitato ad accedere solo dal mio ip riservato in vlan.

 crea altri problemi?
In questo modo il php esce tramite l'ip del virtualhost di apache
giusto?
Ottimo. E' questa la soluzione. Non sapevo in che modo uscisse il
virtualhost.
Stavo appunto cercando di fare proprio questa cosa qui.

 limitato ad accedere solo dal mio ip riservato in vlan.
L'applicazione web, come detto, la potresti mettere sullo stesso server
dove risiede MySQL, magari usando un web server leggero come lighttpd o
nginx che comunicano con PHP via fastcgi.
Meglio comunque un server dedicato, tanto per stare sul sicuro e se ne hai
la possibilità.
Saluti  Manlio Perillo

 virtualhost.
Può darsi che tu debba giocare anche un po' col routing (meglio con ip che
con route)
-- 
Vide

 con route)
Anzi, mi sa che è l'unica soluzione e che quella del virualhost era una
boiata... però sei punto a capo.
-- 
Vide

Vide ha scritto:

Ok, supponiamo un caso dimostrativo:
ip server: 111.222.333.444
ip2 server: 222.333.444.555
virtualhost tutti su 111.222.333.444
quando da php faccio una file_get_contents lui mi esce tramite il 
default gw o tramite 111.222.333.444 nel caso il file fosse nella stessa 
subnet.
altro virtualhost dedicato su 222.333.444.555
ora se faccio una file_get_content ad un file che sta su 
222.333.444.666, lui dovrebbe uscire da 222.333.444.555 in teoria.
Non ho avuto modo di provare. Qualcuno ha mai fatto un test simile?



Non credo conti il virtual host di Apache o del web server in generale.
Conta a che indirizzo IP ti colleghi con PHP per avere l'accesso al
database.
Questo significa (a meno che non stia dicendo castronerie) che in ogni caso
non puoi limitare l'accesso ai tuoi utenti. L'applicazione web di
amministrazione deve stare su una macchina separata.
Saluti  Manlio Perillo

 Non ho avuto modo di provare. Qualcuno ha mai fatto un test simile?
Da dove esce lo vedi con ip route.
Esempio:
172.22.55.0/24
 dev eth2  proto kernel  scope link  src 172.22.55.254
Sempre con ip o con iptables puoi alterare il comportamento, se necessario.
-- 
Words are very unnecessary
They can only do harm


Come pensavo di fare infatti.
Credo sia l'unica. IP con virtualhost dedicato e faccio uscire le
connessioni da quel dato ip piuttosto che quello principale.



E non può fare lo stesso un qualsiasi altro utente?
Leggendo la documentazione relativa ai socket ho notato l'opzione
SO_BINDTODEVICE, che permette di ignorare il routing di sistema.
Saluti  Manlio Perillo

 SO_BINDTODEVICE, che permette di ignorare il routing di sistema.
Da PHP???

 Da PHP???
Non dirmi che da PHP non è permesso, è una semplice setsockopt!
Tale opzione è settabile solo con privilegi di root (così gli altri
utenti non possono farlo).
Dovresti quindi usare fastcgi, eseguendo il processo PHP con privilegi di
root, giusto il tempo per fare le operazione che richiedono tali
privilegi.
Saluti  Manlio Perillo

 utenti non possono farlo).
Dubito fortemente PHP possa fare quello che dici tu.
Inoltre, ho php come moudlo ed in quanto tale, viene eseguito da apache 
e non da root quindi...