Conseils sur l'administration de MySQL/MariaDB sur Buster ?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Conseils sur l'administration de MySQL/MariaDB sur Buster ?

Olivier-2
Bonjour,

Je travaille sur une configuration de Freeradius avec une base de données pour Debian Buster.

Comme la documentation de Freeradius avec base de données se réfère massivement à MySQL, j'ai installé sur une VM, MySQL/MariaDB avec la commande apt-get install default-mysql-server suivie de mysql_secure_installation.

J'ai volontairement installé default-mysql-servercar dans mon cas, je suis indifférent au choix MySQL/MariaDB: je souhaite juste mettre au point une configuration qui fonctionnera quand Buster sera la version stable de Debian.

Ce faisant, j'ai été surpris de constater qu'après ces 2 commandes, la méthode d'accès à MySQL/MariaDB avait changé:

- l'utilisateur root peut se connecter sans mot de passe ou avec un mot de passe erroné
- un utilisateur lambda ne peut plus se connecter en tant qu'utilisateur MySQL/MariaDB root même en fournissant le bon mot de passe.

J'ai trouvé sur Internet vraiment très peu de doc sur l'administration de MySQL/MariaDBsous Buster.

Avez-vous des conseils sur ceci dans le cas où on a besoin d'exécuter des scripts de création-configuration de base de données MySQL ?

Faut-il installer MySQL plutôt que MariaDB ? Le contraire ?
Y-a-t-il une autre commande que mysql_secure_installation à exécuter ?
Peut-on sans état d'âme ignorer cette différence avec les versions de MySQL sous Jessie ou autre ?
Documentation ?

Slts


Reply | Threaded
Open this post in threaded view
|

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ?

BERTRAND Joël-2
Olivier a écrit :
> Bonjour,

        Bonjour,

> Je travaille sur une configuration de Freeradius avec une base de
> données pour Debian Buster.
>
> Comme la documentation de Freeradius avec base de données se réfère
> massivement à MySQL, j'ai installé sur une VM, MySQL/MariaDB avec la
> commande apt-get install default-mysql-server suivie de
> mysql_secure_installation.
>
> J'ai volontairement installé default-mysql-servercar dans mon cas, je
> suis indifférent au choix MySQL/MariaDB: je souhaite juste mettre au
> point une configuration qui fonctionnera quand Buster sera la version
> stable de Debian.
>
> Ce faisant, j'ai été surpris de constater qu'après ces 2 commandes, la
> méthode d'accès à MySQL/MariaDB avait changé:
>
> - l'utilisateur root peut se connecter sans mot de passe ou avec un mot
> de passe erroné

        Pas chez moi :

Root rayleigh:[~] > mysql -uroot -p
Enter password:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
password: YES)
Root rayleigh:[~] >

        Naturellement, si je fournis le bon mot de passe, ça fonctionne comme
attendu.

> - un utilisateur lambda ne peut plus se connecter en tant qu'utilisateur
> MySQL/MariaDB root même en fournissant le bon mot de passe.

        Pas chez moi :

rayleigh:[~] > mysql -uroot -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 10044
Server version: 10.3.13-MariaDB-1-log Debian buildd-unstable

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.

MariaDB [(none)]> quit
Bye
rayleigh:[~] > whoami
bertrand

        À mon avis, le problème est ailleurs ;-)

        Je commencerais pas jeter un oeil à la configuration de mariadb.

        Bien cordialement,

        JKB

Reply | Threaded
Open this post in threaded view
|

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ?

Alexandre Goethals

Bonjour,

pour la connexion au compte root sans mot de passe (en local), c'est parce que ce compte utilise le plugin unix socket:

SELECT host, user, password, plugin FROM mysql.user;

devrait donner quelque chose comme:
+-----------+------+--------------------------+-------------+
| host      | user | password                 | plugin      |
+-----------+------+--------------------------+-------------+
| localhost | root | <redacted_password_hash> | unix_socket |
+-----------+------+--------------------------+-------------+

Donc il faut faire:
UPDATE mysql.user SET plugin = '' WHERE user = 'root' AND host = 'localhost';
FLUSH PRIVILEGES;

redémarrer mariadb

source: https://stackoverflow.com/questions/7179894/how-to-disable-mysql-root-logins-when-no-password-is-supplied

Le 25/03/2019 à 12:19, BERTRAND Joël a écrit :
Olivier a écrit :
Bonjour,
	Bonjour,

Je travaille sur une configuration de Freeradius avec une base de
données pour Debian Buster.

Comme la documentation de Freeradius avec base de données se réfère
massivement à MySQL, j'ai installé sur une VM, MySQL/MariaDB avec la
commande apt-get install default-mysql-server suivie de
mysql_secure_installation.

J'ai volontairement installé default-mysql-servercar dans mon cas, je
suis indifférent au choix MySQL/MariaDB: je souhaite juste mettre au
point une configuration qui fonctionnera quand Buster sera la version
stable de Debian.

Ce faisant, j'ai été surpris de constater qu'après ces 2 commandes, la
méthode d'accès à MySQL/MariaDB avait changé:

- l'utilisateur root peut se connecter sans mot de passe ou avec un mot
de passe erroné
	Pas chez moi :

Root rayleigh:[~] > mysql -uroot -p
Enter password:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
password: YES)
Root rayleigh:[~] >

	Naturellement, si je fournis le bon mot de passe, ça fonctionne comme
attendu.

- un utilisateur lambda ne peut plus se connecter en tant qu'utilisateur
MySQL/MariaDB root même en fournissant le bon mot de passe.
	Pas chez moi :

rayleigh:[~] > mysql -uroot -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 10044
Server version: 10.3.13-MariaDB-1-log Debian buildd-unstable

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.

MariaDB [(none)]> quit
Bye
rayleigh:[~] > whoami
bertrand

	À mon avis, le problème est ailleurs ;-)

	Je commencerais pas jeter un oeil à la configuration de mariadb.

	Bien cordialement,

	JKB

Reply | Threaded
Open this post in threaded view
|

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

Olivier-2
In reply to this post by BERTRAND Joël-2


Le lun. 25 mars 2019 à 12:19, BERTRAND Joël <[hidden email]> a écrit :


        Pas chez moi :


@Joel:
Que donne 'SELECT host, user, password, plugin FROM mysql.user;' sur ta machine ?
Sur la mienne, j'ai bien le plugin unix_socket qu'Alexandre mentionne dans son message.

@Alexandre:
Merci pour ton lien: il explique bien le nouveau paramétrage.
Le lien [1] le détaille aussi.
Pour l'instant, je conserve ce nouveau fonctionnement en l'état.
Je marque néanmoins ce fil de discussion comme RESOLU car je pense qu'il pourra être utile à d'autres.

Merci à vous

Reply | Threaded
Open this post in threaded view
|

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

BERTRAND Joël-2
Olivier a écrit :

>
>
> Le lun. 25 mars 2019 à 12:19, BERTRAND Joël <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>
>
>             Pas chez moi :
>
>
> @Joel:
> Que donne 'SELECT host, user, password, plugin FROM mysql.user;' sur ta
> machine ?
> Sur la mienne, j'ai bien le plugin unix_socket qu'Alexandre mentionne
> dans son message.

        Je vire toujours la socket Unix.

MariaDB [(none)]> select host,user,password,plugin from mysql.user where
user='root';
+-----------+------+-------------------------------------------+--------+
| host      | user | password                                  | plugin |
+-----------+------+-------------------------------------------+--------+
| localhost | root | *8DD098CAB69587D2A67BE8E8A66010A99DF39A75 |        |
| rayleigh  | root | *8DD098CAB69587D2A67BE8E8A66010A99DF39A75 |        |
+-----------+------+-------------------------------------------+--------+
2 rows in set (0.000 sec)

        Je considère que ce n'est pas un trou de sécurité, mais une faille
délirante. root doit se connecter avec un mot de passe.

        JKB

Reply | Threaded
Open this post in threaded view
|

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

Daniel Caillibaud-5
Le 25/03/19 à 14:06, BERTRAND Joël <[hidden email]> a écrit :
> Je considère que ce n'est pas un trou de sécurité, mais une faille
> délirante. root doit se connecter avec un mot de passe.

???

Si t'es root sur la machine, tu as accès à tous les contenus de toutes les
bases, je vois pas ce que ça change coté sécurité qu'il puisse se connecter
sans mot de passe… (on parle localement, un root qui a déjà un shell sur la
machine).

--
Daniel

Il faut choisir, dans la vie, entre gagner de l'argent et le dépenser,
on n'a pas le temps de faire les deux.
Edouard Bourdet

Reply | Threaded
Open this post in threaded view
|

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

BERTRAND Joël-2
Daniel Caillibaud a écrit :

> Le 25/03/19 à 14:06, BERTRAND Joël <[hidden email]> a écrit :
>> Je considère que ce n'est pas un trou de sécurité, mais une faille
>> délirante. root doit se connecter avec un mot de passe.
>
> ???
>
> Si t'es root sur la machine, tu as accès à tous les contenus de toutes les
> bases, je vois pas ce que ça change coté sécurité qu'il puisse se connecter
> sans mot de passe… (on parle localement, un root qui a déjà un shell sur la
> machine).
>

        Le nombre de clients que j'ai déjà vus avoir des machines compromises
avec un accès root total parce que le mot de passe était trop compliqué
et qu'ils ont collé un mot de passe à la turc avec un accès ssh distant
possible pour root ne se comptent plus (et même sans ça, le plus beau
était un compte ftpuser/ftpuser avec un root/toor, sans accès distant à
root par ssh, durée de vie de la machine sur le grand terne, un week-end
!). Donc par défaut, l'accès à une base de données se fait chez moi avec
un mot de passe même en étant root. Ce truc m'a déjà sauvé la vie
plusieurs fois. Parce que lorsqu'une machine est compromise, ce n'est
jamais la faute du type qui a installé un service mal configuré, c'est
toujours de la faute du type qui a fournit l'installation. J'en suis
même arrivé dans mes CGV à indiquer brutalement que les GTR ne
s'appliquaient qu'en cas de configuration hard et soft non modifiée par
le client. Même mysqladmin demande un mot de passe :

root@hilbert:~# mysqladmin processlist
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost' (using password: NO)'

        Pour l'instant, je ne suis pas encore tombé sur un attaquant qui se
soit permis d'arrêter une base pour utiliser mysqladmin brutalement ou
qui soit passé outre le mot de passe administrateur de la base de
données, ils cherchent plutôt à récupérer des infos sans qu'on s'en
rende compte ou de corrompre des systèmes fonctionnels. En espérant que
ça ne change pas.

        Donc oui, le fait d'avoir un mot de passe sur l'accès à la base ne
protège pas de tout, loin de là, mais ça peut emmerder et ralentir
substantiellement l'attaquant.

        Bien cordialement,

        JKB

Reply | Threaded
Open this post in threaded view
|

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

Florian Blanc
In reply to this post by Daniel Caillibaud-5
Mwé,

root system et root db c'est pas vraiment pareil.
root db doit avoir un password différent de root system,
Et, allow root db connection only from localhost.

(il faudrait trouver un principe qui lock le login Shell from localhost après X logins fails & send mail. Il faudrait que ça soit intégré à mysql par contre).

Par contre, après tu peux déjà parse les logs et send mail après un login fail.
Ça te permettra de disconnect all root and change password for root sys.

Mais bon voilà voilà il faut penser à faire perdre du temps à l'attaquant pour que tu puisse l'expulser avant trop de dégâts.

Dans tous les cas si root corrompu, save tes data et formate. 🙏

On Tue, Mar 26, 2019, 10:01 Daniel Caillibaud <[hidden email]> wrote:
Le 25/03/19 à 14:06, BERTRAND Joël <[hidden email]> a écrit :
>       Je considère que ce n'est pas un trou de sécurité, mais une faille
> délirante. root doit se connecter avec un mot de passe.

???

Si t'es root sur la machine, tu as accès à tous les contenus de toutes les
bases, je vois pas ce que ça change coté sécurité qu'il puisse se connecter
sans mot de passe… (on parle localement, un root qui a déjà un shell sur la
machine).

--
Daniel

Il faut choisir, dans la vie, entre gagner de l'argent et le dépenser,
on n'a pas le temps de faire les deux.
Edouard Bourdet

Reply | Threaded
Open this post in threaded view
|

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

Florian Blanc
En même temps BERTRAND. 🙏 SOWY 

On Tue, Mar 26, 2019, 10:44 Florian Blanc <[hidden email]> wrote:
Mwé,

root system et root db c'est pas vraiment pareil.
root db doit avoir un password différent de root system,
Et, allow root db connection only from localhost.

(il faudrait trouver un principe qui lock le login Shell from localhost après X logins fails & send mail. Il faudrait que ça soit intégré à mysql par contre).

Par contre, après tu peux déjà parse les logs et send mail après un login fail.
Ça te permettra de disconnect all root and change password for root sys.

Mais bon voilà voilà il faut penser à faire perdre du temps à l'attaquant pour que tu puisse l'expulser avant trop de dégâts.

Dans tous les cas si root corrompu, save tes data et formate. 🙏

On Tue, Mar 26, 2019, 10:01 Daniel Caillibaud <[hidden email]> wrote:
Le 25/03/19 à 14:06, BERTRAND Joël <[hidden email]> a écrit :
>       Je considère que ce n'est pas un trou de sécurité, mais une faille
> délirante. root doit se connecter avec un mot de passe.

???

Si t'es root sur la machine, tu as accès à tous les contenus de toutes les
bases, je vois pas ce que ça change coté sécurité qu'il puisse se connecter
sans mot de passe… (on parle localement, un root qui a déjà un shell sur la
machine).

--
Daniel

Il faut choisir, dans la vie, entre gagner de l'argent et le dépenser,
on n'a pas le temps de faire les deux.
Edouard Bourdet

Reply | Threaded
Open this post in threaded view
|

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

Florian Blanc
Tous les root passwords de tes machines doivent être différents.
Alors perso je les notes sur un calepin.
Mais attention, je note pas tout.
Par exemple j'ai 3 password en tête un court, un mi-long et un long.
Ce ne sont pas des mots c'est vraiment illogique.
À partir de la sur mon calepin par exemple je note :
Machine.domaine Mysql root : L3ML/Cq
L c'est mon password long
ML c'est le mi long 
C le court

Voilà voilà pour ma petite astuce 😇🙏

On Tue, Mar 26, 2019, 10:48 Florian Blanc <[hidden email]> wrote:
En même temps BERTRAND. 🙏 SOWY 

On Tue, Mar 26, 2019, 10:44 Florian Blanc <[hidden email]> wrote:
Mwé,

root system et root db c'est pas vraiment pareil.
root db doit avoir un password différent de root system,
Et, allow root db connection only from localhost.

(il faudrait trouver un principe qui lock le login Shell from localhost après X logins fails & send mail. Il faudrait que ça soit intégré à mysql par contre).

Par contre, après tu peux déjà parse les logs et send mail après un login fail.
Ça te permettra de disconnect all root and change password for root sys.

Mais bon voilà voilà il faut penser à faire perdre du temps à l'attaquant pour que tu puisse l'expulser avant trop de dégâts.

Dans tous les cas si root corrompu, save tes data et formate. 🙏

On Tue, Mar 26, 2019, 10:01 Daniel Caillibaud <[hidden email]> wrote:
Le 25/03/19 à 14:06, BERTRAND Joël <[hidden email]> a écrit :
>       Je considère que ce n'est pas un trou de sécurité, mais une faille
> délirante. root doit se connecter avec un mot de passe.

???

Si t'es root sur la machine, tu as accès à tous les contenus de toutes les
bases, je vois pas ce que ça change coté sécurité qu'il puisse se connecter
sans mot de passe… (on parle localement, un root qui a déjà un shell sur la
machine).

--
Daniel

Il faut choisir, dans la vie, entre gagner de l'argent et le dépenser,
on n'a pas le temps de faire les deux.
Edouard Bourdet

Reply | Threaded
Open this post in threaded view
|

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

Daniel Caillibaud-5
In reply to this post by BERTRAND Joël-2
Le 26/03/19 à 10:36, BERTRAND Joël <[hidden email]> a écrit :
> Le nombre de clients que j'ai déjà vus avoir des machines
> compromises avec un accès root total parce que le mot de passe était trop
> compliqué

Des mdp root… Question sécurité ça commence mal, donc ensuite, pass mysql
ou pas…

> et qu'ils ont collé un mot de passe à la turc avec un accès ssh
> distant possible pour root ne se comptent plus (et même sans ça, le plus
> beau était un compte ftpuser/ftpuser avec un root/toor, sans accès
> distant à root par ssh, durée de vie de la machine sur le grand terne, un
> week-end !). Donc par défaut, l'accès à une base de données se fait chez
> moi avec un mot de passe même en étant root.

J'ai toujours pas compris ce que ça apportait question sécurité…

Avec un shell root tu change le pass du root db comme tu veux, donc le fait
qu'il ait un pass ne protège de rien du tout.

--
Daniel

L'esprit, c'est l'inverse de l'argent, moins on en a, plus on est heureux.
Voltaire

Reply | Threaded
Open this post in threaded view
|

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

Olivier-2
À mon sens, il y a deux aspects bien distincts:
1- empêcher les accès illégitimes
2- empêcher les conséquences néfastes d'un accès illégitime.

J'ai quand même l'impression que sur une machine Linux sur laquelle root a beaucoup (trop ?), le point 2 n'est vraiment pas facile à traiter.
Qui sait vraiment cloisonner une machine ?

Mon sentiment est que la majorité se focalise sur le point 1 en gardant pour plus tard le point 2, un jour ou on aura le temps ...

C'est sûr que si une société doit exposer une machine sur Internet et qu'en plus elle est susceptible d'attaques ciblées de la part de concurrents ou autres, prêts à investir pour la voler ou lui nuire ...


Le mar. 26 mars 2019 à 14:58, Daniel Caillibaud <[hidden email]> a écrit :
Le 26/03/19 à 10:36, BERTRAND Joël <[hidden email]> a écrit :
> Le nombre de clients que j'ai déjà vus avoir des machines
> compromises avec un accès root total parce que le mot de passe était trop
> compliqué

Des mdp root… Question sécurité ça commence mal, donc ensuite, pass mysql
ou pas…

> et qu'ils ont collé un mot de passe à la turc avec un accès ssh
> distant possible pour root ne se comptent plus (et même sans ça, le plus
> beau était un compte ftpuser/ftpuser avec un root/toor, sans accès
> distant à root par ssh, durée de vie de la machine sur le grand terne, un
> week-end !). Donc par défaut, l'accès à une base de données se fait chez
> moi avec un mot de passe même en étant root.

J'ai toujours pas compris ce que ça apportait question sécurité…

Avec un shell root tu change le pass du root db comme tu veux, donc le fait
qu'il ait un pass ne protège de rien du tout.

--
Daniel

L'esprit, c'est l'inverse de l'argent, moins on en a, plus on est heureux.
Voltaire

Reply | Threaded
Open this post in threaded view
|

Re: Conseils sur l'administration de MySQL/MariaDB sur Buster ? [RESOLU]

Erwann Le Bras


Le 26/03/2019 à 15:13, Olivier a écrit :
À mon sens, il y a deux aspects bien distincts:
1- empêcher les accès illégitimes
2- empêcher les conséquences néfastes d'un accès illégitime.

J'ai quand même l'impression que sur une machine Linux sur laquelle root a beaucoup (trop ?), le point 2 n'est vraiment pas facile à traiter.
Qui sait vraiment cloisonner une machine ?

Mon sentiment est que la majorité se focalise sur le point 1 en gardant pour plus tard le point 2, un jour ou on aura le temps ...


c'est pas facile...

chez "moi" les accès sont nominatifs et habilités derrière à acquérir du pouvoir par un "simple" sudo su - id, id étant root, oracle, ou qu'en sais-je encore.

les grands pouvoirs incluants de grandes responsabilités on n'est jamais à l'abri d'une mauvaise manipulation ayant de lourdes conséquences. Ces conséquences sont atténuées :

  • par de petits pouvoirs incluant de petits effets néfastes
  • des effets de masquage et réparations importants : sauvegarde, redondance, fermes de clusters...

mé bon chez "moi" c'est du gros...

root c'est dieu : seuls des sysadmins devraient y avoir accès, et donc eux seuls devraient avoir la possibilité (habilitation technique) d'effectuer des opérations sensibles. Pour le reste, l'éducation des utilisateurs, le traçage des actions et menace de tirages d'oreilles doivent cantonner les utilisateurs à leur simple rôle.