cerhu > linux.debian.user.french

Olivier (25/03/2019, 12h40)
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 avecla
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
BERTRAND Joël (25/03/2019, 13h20)
Olivier a écrit :
> Bonjour,


Bonjour,

[..]
> 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 (25/03/2019, 15h00)
Le lun. 25 mars 2019 à 12:19, BERTRAND Joël <joel.bertrand> 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

[1] [..]
BERTRAND Joël (25/03/2019, 15h10)
Olivier a écrit :
> <mailto:joel.bertrand>> a écrit :
>         Pas chez moi :
> 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
Daniel Caillibaud (26/03/2019, 11h10)
Le 25/03/19 à 14:06, BERTRAND Joël <joel.bertrand> 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'ilpuisse se connecter
sans mot de passe? (on parle localement, un root qui a déjà un shell sur la
machine).
BERTRAND Joël (26/03/2019, 11h40)
Daniel Caillibaud a écrit :
> Le 25/03/19 à 14:06, BERTRAND Joël <joel.bertrand> a écrit :
> ???
> 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
Florian Blanc (26/03/2019, 11h50)
En même temps BERTRAND. ? SOWY

On Tue, Mar 26, 2019, 10:44 Florian Blanc <florian.blanc.adm>
wrote:
[..]
Florian Blanc (26/03/2019, 11h50)
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 <ml> wrote:
[..]
Florian Blanc (26/03/2019, 12h10)
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 <florian.blanc.adm>
wrote:
[..]
Daniel Caillibaud (26/03/2019, 16h00)
Le 26/03/19 à 10:36, BERTRAND Joël <joel.bertrand> 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 grandterne, 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.
Olivier (26/03/2019, 16h20)
À 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 concurrentsou
autres, prêts à investir pour la voler ou lui nuire ...

Le mar. 26 mars 2019 à 14:58, Daniel Caillibaud <ml> a
écrit :
[..]
Erwann Le Bras (27/03/2019, 12h00)
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.
Discussions similaires
MariaDB / Mysql

regénérer le mot de passe de secours "admin" Mysql (mariadb)

Remplacer Mysql par Mariadb

OpenSolaris, pourquoi pas kOpenSolaris ? / MySQL et MariaDB, travail en cours ?


Fuseau horaire GMT +2. Il est actuellement 22h32. | Privacy Policy