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

Le
Olivier
--00000000000096ae6e0584e8b8ed
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 com=
mandes, 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'administr=
ation de
MySQL/MariaDBsous Buster.

Avez-vous des conseils sur ceci dans le cas où on a besoin d'exéc=
uter 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écu=
ter ?
Peut-on sans état d'âme ignorer cette différence avec les ve=
rsions de MySQL
sous Jessie ou autre ?
Documentation ?

Slts

--00000000000096ae6e0584e8b8ed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div dir="ltr"><div>Bonjour,</div><div><br></div><div>Je=
travaille sur une configuration de Freeradius avec une base de donnée=
s pour Debian Buster.</div><div><br></div><div>Comme la documentation de Fr=
eeradius avec base de données se réfère massivement à M=
ySQL, j&#39;ai installé sur une VM, MySQL/MariaDB avec la commande apt=
-get install default-mysql-server suivie de mysql_secure_installation.</div=
><div><br></div><div>J&#39;ai volontairement installé default-mysql-se=
rvercar dans mon cas, je suis indifférent au choix MySQL/MariaDB: je s=
ouhaite juste mettre au point une configuration qui fonctionnera quand Bust=
er sera la version stable de Debian.<br></div><div><br></div><div>Ce faisan=
t, j&#39;ai été surpris de constater qu&#39;après ces 2 comm=
andes, la méthode d&#39;accès à MySQL/MariaDB avait chang=
:</div><div><br></div><div>- l&#39;utilisateur root peut se connecter sa=
ns mot de passe ou avec un mot de passe erroné<br></div><div>- un util=
isateur lambda ne peut plus se connecter en tant qu&#39;utilisateur MySQL/M=
ariaDB root même en fournissant le bon mot de passe.</div><div><br></d=
iv><div>J&#39;ai trouvé sur Internet vraiment très peu de doc sur=
l&#39;administration de MySQL/MariaDBsous Buster.</div><div><br></div><div=
>Avez-vous des conseils sur ceci dans le cas où on a besoin d&#39;ex=
écuter des scripts de création-configuration de base de donn=
es MySQL ?</div><div><br></div><div>Faut-il installer MySQL plutôt =
que MariaDB ? Le contraire ?</div><div>Y-a-t-il une autre commande que mysq=
l_secure_installation à exécuter ?</div><div>Peut-on sans ét=
at d&#39;âme ignorer cette différence avec les versions de MySQL =
sous Jessie ou autre ?</div><div>Documentation ?</div><div><br></div><div>S=
lts<br></div><div><br></div><div><br></div></div></div>

--00000000000096ae6e0584e8b8ed--
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
BERTRAND Jo=c3=abl
Le #26512956
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
Olivier
Le #26512972
--000000000000c4f3230584eabf5c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le lun. 25 mars 2019 à 12:19, BERTRAND Joël é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
[1] https://mariadb.com/kb/en/library/authentication-plugin-unix-socket/
--000000000000c4f3230584eabf5c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<br>
        Pas chez moi :<br>
--000000000000c4f3230584eabf5c--
BERTRAND Jo=c3=abl
Le #26512977
Olivier a écrit :
Le lun. 25 mars 2019 à 12:19, BERTRAND Joël

        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
BERTRAND Jo=c3=abl
Le #26513053
Daniel Caillibaud a écrit :
Le 25/03/19 à 14:06, BERTRAND Joël
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 :
:~# 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
Publicité
Poster une réponse
Anonyme