{"id":4441,"date":"2020-03-27T11:43:54","date_gmt":"2020-03-27T09:43:54","guid":{"rendered":"http:\/\/www.laurentmarot.fr\/wordpress\/?p=4441"},"modified":"2021-04-27T17:03:27","modified_gmt":"2021-04-27T15:03:27","slug":"data-in-transit-encryption","status":"publish","type":"post","link":"https:\/\/www.laurentmarot.fr\/wordpress\/?p=4441","title":{"rendered":"Data-in-Transit Encryption with MariaDB"},"content":{"rendered":"

S\u00e9curiser les donn\u00e9es au repos<\/a> c’est important, mais s\u00e9curiser les flux l’est tout autant.<\/p>\n

Donc, apr\u00e8s une petite synth\u00e8se sur Data-at-Rest Encryption<\/a> avec Transparent Data Encryption, voyons comment mettre un peu de confidentialit\u00e9 dans le transport.<\/p>\n

Un peu de cuisine pour commencer … En ces temps de confinement, cet article servira de support \u00e0 un TP que nous jouerons avec les LP DLIS de l’IUT de Vannes semaine prochaine.<\/p>\n

On va ouvrir un acc\u00e8s sur une base MariaDB expos\u00e9e sur Internet … ouais, on des fous \ud83d\ude42<\/p>\n

Bon, on va quand m\u00eame avant toute chose activer les logs sur le fameux SGBD histoire de voir qui attaque sans passer par un proxy. Attention malgr\u00e9 tout car dans les fameux fichiers de logs on retrouve aussi en particulier, les requ\u00eates de cr\u00e9ation de comptes avec si on n’y prends pas garde le mot de passe en clair (et accessoirement toutes les commandes pourries)\u00a0 :<\/p>\n

\"logs<\/a>

logs mariaDB<\/p><\/div>\n

root@vpsxxxxxx:\/etc\/mysql\/mariadb.conf.d# ls \/var\/log\/mysql\/mysql.log -lart
\n-rw-rw—- 1 mysql adm 182 Mar 27 11:56 \/var\/log\/mysql\/mysql.log<\/p>\n

 <\/p>\n

 <\/p>\n

Pour faire les choses un petit peu s\u00e9rieusement, on n’ouvrira qu’une base sur internet avec un seul compte d\u00e9di\u00e9 cr\u00e9\u00e9 pour l’occasion, histoire d’avoir un peu de cloisonnement.<\/p>\n

Forc\u00e9ment et heureusement, dans un premier temps \u00e7a ne passe pas. Il faut modifier la configuration par d\u00e9faut qui n’autorise que les connexions depuis le poste local.<\/p>\n

\"can't<\/a>

can’t connect to mariaDB<\/p><\/div>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

Et puis, apr\u00e8s quelques efforts, la connexion peut enfin \u00eatre \u00e9tablie…<\/p>\n

\"mysql<\/a>

mysql from everywher for everyone<\/p><\/div>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

Faudrait pas croire que votre mot de passe circule en clair (contrairement au trafic suivant l’authentification) .<\/p>\n

Il se dit que le mot de passe suivrait\u00a0 le m\u00e9canisme de chiffrement d\u00e9taill\u00e9 ici\u00a0 :<\/p>\n

https:\/\/dev.mysql.com\/doc\/dev\/mysql-server\/latest\/page_protocol_connection_phase_authentication_methods_native_password_authentication.html<\/a><\/p>\n

Malheureusement, \u00e0 cet instant (20200329151524) je n’arrive pas \u00e0 retrouver dans mon pcap les 20 octets de nonce (on nous ment ?)<\/p>\n

\"Scramble<\/a>

Scramble data<\/p><\/div>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

Bref, quoi, qu’il en soit et au del\u00e0 de la v\u00e9rification de l’impl\u00e9mentation de ce m\u00e9canisme, revenons au chiffrement du flux …<\/p>\n

Etape 1 \u2013 Cr\u00e9er le certificat racine de l’autorit\u00e9 de certification (CA)<\/h2>\n

 <\/p>\n

Cr\u00e9ons un dossier tls dans le r\u00e9pertoire \/etc\/mysql\/\u00a0 (parce que ssl c’est tellement vingti\u00e8me si\u00e8cle):<\/p>\n

$ cd \/etc\/mysql
\n$ sudo mkdir tls
\n$ cd tls<\/code><\/p>\n

<\/code><\/p>\n

Note<\/strong>: La valeur du Common Name (CN) utilis\u00e9e pour les certificats serveur MariaDB et le client doivent \u00eatre diff\u00e9rents du Common Name utilis\u00e9 pour le certificat racine de l’autorit\u00e9 de certification. Pour \u00e9viter tour probl\u00e8me, j’ai utilis\u00e9 les valeurs suivantes :
\nCommon Name de la CA : MariaDB admin<\/strong>
\nCommon Name du serveur : MariaDB server<\/strong>
\nCommon Name du client : MariaDB client<\/strong><\/p>\n

Dans la vraie vie, la CA serait h\u00e9berg\u00e9e sur une autre machine.<\/p>\n

G\u00e9n\u00e9ration de la paire de clefs RSA
\n<\/strong><\/p>\n

$ sudo openssl genrsa 2048 > BZHITSCA-key.pem<\/code><\/p>\n

G\u00e9n\u00e9ration du certificat de la clef publique<\/strong> ( tip : pour \u00eatre tr\u00e8s pr\u00e9cis, on parle donc de certificat DE<\/strong> clef publique)<\/p>\n

$ sudo openssl req -new -x509 -nodes -days 365000 -key BZHITSCA-key.pem -out BZHITSCA-cert.pem<\/code><\/p>\n

On lui donne une validit\u00e9 de 1 000 ans, ce qui nous donnera le temps de jouer.<\/p>\n

 <\/p>\n

Par abus de langage on associe souvent la commande pr\u00e9c\u00e9dente \u00e0 une simple g\u00e9n\u00e9ration de clef priv\u00e9e. Mais en fait le fichier .pem produit permet aussi d’exporter la clef publique.<\/p>\n

$ sudo openssl rsa -in BZHITSCA-key.pem -pubout -out BZHITSCA-pubkey.pem<\/code><\/p>\n

<\/h2>\n

Etape 2 \u2013 Cr\u00e9er le certificat du serveur MariaDB<\/h2>\n

G\u00e9n\u00e9ration de la clef et de la Certificate Signing Request<\/strong><\/p>\n

$ sudo openssl req -newkey rsa:2048 -days 365 -nodes -keyout SERVER-key.pem -out SERVER-req.pem<\/code><\/p>\n

Le deuxi\u00e8me objet cr\u00e9\u00e9 est la requ\u00eate de demande de signature de certificat (Certificate Signing Request = CSR). Donc, g\u00e9n\u00e9ralement on peut dire qu’un certificat c’est un fichier contenant des \u00ab\u00a0informations\u00a0\u00bb relatives \u00e0 une entit\u00e9 et la clef publique de cette m\u00eame entit\u00e9 ayant subi une signature num\u00e9rique par l’autorit\u00e9 de certification (qui certifie donc que la clef publique repr\u00e9sente bien l’entit\u00e9 en question). Capito ?<\/p>\n

Export de la clef RSA
\n<\/strong><\/p>\n

$ sudo openssl rsa -in SERVER-key.pem -out SERVER-key.pem<\/code><\/p>\n

Signature du certificat du serveur<\/strong><\/p>\n

$ sudo openssl x509 -req -in SERVER-req.pem -days 365000 -CA BZHITSCA-cert.pem -CAkey BZHITSCA-key.pem -set_serial 01 -out SERVER-cert.pem<\/code><\/p>\n

Etape 3 \u2013 G\u00e9n\u00e9rer les certificats du client<\/h2>\n

G\u00e9n\u00e9ration de la clef et de la Certificate Signing Request<\/strong><\/p>\n

<\/code><\/pre>\n
$ sudo openssl req -newkey rsa:2048 -days 365 -nodes -keyout SERVER-key.pem -out SERVER-req.pem<\/code><\/p>\n
<\/code><\/pre>\n
Le deuxi\u00e8me objet cr\u00e9\u00e9 est la requ\u00eate de demande de signature de certificat (Certificate Signing Request = CSR). Donc, g\u00e9n\u00e9ralement on peut dire qu’un certificat c’est un fichier contenant des \u00ab\u00a0informations\u00a0\u00bb relatives \u00e0 une entit\u00e9 et la clef publique de cette m\u00eame entit\u00e9 ayant subi une signature num\u00e9rique par l’autorit\u00e9 de certification (qui certifie donc que la clef publique repr\u00e9sente bien l’entit\u00e9 en question). Capito ?<\/p>\n
<\/code><\/pre>\n
Export de la clef RSA
\n<\/strong><\/p>\n
<\/code><\/pre>\n
$ sudo openssl rsa -in SERVER-key.pem -out SERVER-key.pem<\/code><\/p>\n
<\/code><\/pre>\n
Signature du certificat du serveur<\/strong><\/p>\n
<\/code><\/pre>\n
$ sudo openssl x509 -req -in SERVER-req.pem -days 365000 -CA BZHITSCA-cert.pem -CAkey BZHITSCA-key.pem -set_serial 01 -out SERVER-cert.pem<\/code><\/p>\n
<\/code><\/pre>\n
Etape 4 \u2013 Copier les certificats sur le client<\/h2>\n
Configuration du client<\/strong><\/p>\n
mkdir \/etc\/mysql\/client-ssl && cd<\/span> \/etc\/mysql\/client-ssl\r\n\r\n# Copy the following files: CLIENT-cert.pem, CLIENT-key.pem and BZHITSCA-cert.pem<\/span>\r\nscp root@REMOTE_SERVER_IP:~\/cert\/{client-cert.pem,client-key.pem,ca-cert.pem} .\/\r\n\r\nchmod -R 700 \/etc\/mysql\/client-ssl\r\n<\/code><\/pre>\n
Editer my.cnf<\/code> pour configurer les chemins vers les certificats:<\/p>\n
nano \/etc\/mysql\/my.cnf<\/code><\/pre>\n
et ajouter:<\/p>\n
[client]\r\nssl-ca =   \/etc\/my<\/span>sql\/client-ssl\/ca-cert.pem\r\nssl-cert = \/etc\/my<\/span>sql\/client-ssl\/client-cert.pem\r\nssl-key =  \/etc\/my<\/span>sql\/client-ssl\/client-key.pem\r\n<\/code><\/pre>\n
 <\/p>\n
<\/h2>\n
Etape 5 \u2013 Configurer le serveur MariaDB<\/h2>\n
Editer\u00a0 le fichier \/etc\/mysql\/mariadb.conf.d\/50-server.cnf ou bien \/etc\/mysql\/mariadb.cnf comme suit:<\/p>\n
$ sudo vi \/etc\/mysql\/mariadb.conf.d\/50-server.cnf<\/code><\/p>\n
Ajouter dans le bloc [mysqld]:<\/p>\n
\n\n\n\n
\n
### MySQL Server ###\r\n## Securing the Database with ssl option and certificates ##\r\n## There is no control over the protocol level used. ##\r\n##  mariadb will use TLSv1.0 or better.  ##\r\nssl\r\nssl-ca=\/etc\/mysql\/ssl\/ca-cert.pem\r\nssl-cert=\/etc\/mysql\/ssl\/server-cert.pem\r\nssl-key=\/etc\/mysql\/ssl\/server-key.pem<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
Savegarder le fichier etred\u00e9marrer mariadb :
\n$ sudo \/etc\/init.d\/mysql restart<\/code><\/p>\n
<\/h2>\n
Etape 6 \u2013 Cr\u00e9er un nouvel utilisateur et se connecter<\/h2>\n
 <\/p>\n
CREATE<\/span> USER<\/span> 'secure_user'<\/span>@'%'<\/span> IDENTIFIED<\/span> BY<\/span> 'my_password'<\/span>;\r\nGRANT<\/span> ALL PRIVILEGES<\/span> ON<\/span> votre_base.* TO<\/span> securee_user@'%'<\/span> REQUIRE SSL;\r\nFLUSH<\/span> PRIVILEGES<\/span>;\r\n<\/code><\/pre>\n
 <\/p>\n
Vous pouvez alors en principe vous connecter avec TLS:<\/p>\n
mysql -h REMOTE_SERVER_IP -u remote_user -p\"my_password\"\r\nWelcome to the MariaDB monitor.  Commands end<\/span> with<\/span> ; or \\g.\r\nYour MariaDB connection id is 5\r\nServer version: 10.1.26-MariaDB-0+deb9u1 Debian 9.1\r\n\r\nCopyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.\r\n\r\nType 'help<\/span>;' or '\\h' for help. Type<\/span> '\\c'<\/span> to<\/span> clear<\/span> the current<\/span> input<\/span> statement.\r\n\r\nMariaDB [(none<\/span>)]> Bye\r\n<\/code><\/pre>\n
 <\/p>\n
Pour m\u00e9moire (pas mal de liens qui m’ont permis de comprendre) :<\/p>\n
https:\/\/stackoverflow.com\/questions\/38167587\/how-to-use-wireshark-to-capture-mysql-query-sql-clearly<\/p>\n
How to get the network packets between MySQL client and server?<\/a><\/p><\/blockquote>\n