Sécuriser un serveur MySQL
(version béta)

  1. Après l'installation

    1. Les bases

    2. Les comptes d'accès

  2. Pour utiliser phpMyAdmin

    1. Authentification en mode configuration

    2. Authentification en mode http

    3. Authentification en mode cookies

  1. Après l'installation  Haut de page

    1. Les bases  Haut de page

      2. Virer la base de test.

    2. Les comptes d'accès  Haut de page

      3. Ces comptes sont enregistrés dans la table user de la base mysql. On peut utiliser la commande grant pour administrer les droits MySQL. Je ne le ferai pas pour mieux expliciter comment fonctionne le jeu de droits MySQL. Pour l'utilisation de grant, se reporter à la documentation MySQL. Pour une autre page sur les droits MySQL voir ici (en attendant que ces pages soient intégrées à la présente documentation).

      1. Si vous administrez depuis la machine elle-même, supprimez toutes les lignes de la table user de la base mysql sauf celle concernant la connexion root depuis localhost.
        Host User
        localhost root

      2. Sinon conservez une seconde ligne en restreignant autant que possible les machines d'accès.

        Exemples :

        Host User
        localhost root
        192.168.0.33 root

        Ci-dessus on ne peut accéder que depuis la machine 192.168.0.33 en plus de localhost.

        Host User
        localhost root
        192.168.0.* root

        Ci-dessus on ne peut accéder que depuis le réseau 192.168.0.0/24 en plus de localhost.

  2. Pour utiliser phpMyAdmin  Haut de page

    3. Si vous utilisez un outil comme phpMyAdmin, il est judicieux de configurer un compte particulier pour l'accès au serveur MySQL.

    La nature des droits nécessités par ce compte (que nous appellerons phpmyadmin, par exmple) est étrpoitement dépendante du mode d'authentification utilisé par phpMyAdmin.

    1. Authentification en mode configuration  Haut de page

      2. C'est le fichier de configuration de phpMyAdmin qui contient (en clair) le compte et le mot de passe utilisés pour se connecter au serveur MySQL. Ce mode ne doit donc être utilisé que dans deux types de cas :

      1. L'accès aux scripts phpMyAdmin eux-mêmes est sévèrement contrôlé (authentification forte pour accéder aux pages)
      2. Les droits concédés à phpMyAdmin sont très restreints, en particulier aucun droit général ni aucun droits sur la base mysql, elle-même.

      Toute personne connaissant le moyen d'accès "1." dispose ipso facto de tous les droits attribués en "2." dans le fichier de configuration.

    2. Authentification en mode http  Haut de page

      3. Cette fois c'est le serveur web dont l'accès aux pages de phpMyAdmin est contrôlé qui demande une authentification au navigateur. Cette authentification est ensuite récupérée par phpMyAdmin. Hélas cette méthode n'est pas portable ; elle fonctionne bien sous Apache (sous Unix/Linux, je n'ai pas testé avec Apache Windows) mais pas sous IIS ou PWS, par exemple.

      En fonction de cette authentification fournie, phpMyAdmin affichera ou non les bases auquel l'utilisateur est censé avoir accès et accèdera à ces mêmes bases avec ce nom. Pour pouvoir lister les bases auxquelles l'utilisateur a droit, phpMyAdmin doit d'abord démarrer avec un compte particulier qui lui permette cette exploration (phpmyadmin, par exemple). Ce compte doit avoir le moins de droits possible.

      Pour déterminer ce minimum il faut comprendre ce que fait phpMyAdmin pour rechercher la liste des bases autorisées. En fait, il effectue une requête de ce type :
      select Db from db where User='http_loged_user' and Select_priv='Y'

      L'utilisateur phpmyadmin a donc besoin d'un droit de lecture (select et clause where) sur ces trois champs. Ce droit de lecture s'exprime par l'octroi du privilège "Select_priv" sur ces .trois champs de la table db de la base mysql. Si on veut faire aussi fin eh bien c'est un peu  long et assez subtile. Si on n'a pas le courage, il faut donner le droit select sur toute la table db mais c'est excessif.

      Méthode paresseuse

      table user
      HostUserPasswordSelect_priv Insert_privUpdate_privDelete_priv Create_privDrop_privReload_priv Shutdown_privProcess_privFile_priv Grant_privReferences_privIndex_priv Alter_priv
      localhost phpmyadmin 48f7047f77f045c5 N N N N N N N N N N N N N N
      table table_priv
      Host Db User Table_name Grantor Timestamp Table_priv Column_priv
      localhost mysql phpmyadmin db   20021212003501  Select

      Méthode subtile

      table user
      Host User Password Select_priv Insert_priv Update_priv Delete_priv Create_priv Drop_priv Reload_priv Shutdown_priv Process_priv File_priv Grant_priv References_priv Index_priv Alter_priv
      localhost phpmyadmin 48f7047f77f045c5 N N N N N N N N N N N N N N
      table table_priv
      Host Db User Table_name Grantor Timestamp Table_priv Column_priv
      localhost mysql phpmyadmin db   20021212003501   Select

      Noter que le droit "select" est mis dans le champ Column_priv et non pas dans Table_priv, sinon il concernerait tous les champs de la table comme plus haut. Le Select dans Column_priv annonce simplement qu'il y a des autorisation de Select à aller chercher dans la table columns_priv.

      table columns_priv
      Host Db User Table_name Column_name Timestamp Column_priv
      localhost mysql dbwebadmin db User 20021212004003 Select
      localhost mysql phpmyadmin db Db 20021212004113 Select
      localhost mysql phpmyadmin db Select_priv 20021212004151 Select

      Voilà. C'est un peu long mais si quelqu'un vous pique votre fichier de configuration de phpMyAdmin, il ne pourra que lister les champs User, Db et Select_priv de la table db (c'est déjà pas mal mais ça limite la casse).

      Souvent le serveur web est différent de la machine de bases de données et il est plus sensible aux attaques car plus exposé que le serveur MySQL. Le fichier de configuration de phpmyadmin est donc un fichier sensible. Il doit être protégé sous IIS comme sous Apache ou autre. Pour cela, le répertoire des scripts phpmyadmin ne doit jamais être accessible par les requêtes de lecture faites au serveur.

      Sous IIS cela s'obtient en décochant, pour ce répertoire, tous les accès autres qu'exécution (lecture, écriture, accès au source du script, indexation, etc). N'oubliez pas de remettre le droit de lecture (et enlever celui d'exécution) sur le sous-répertoire "images".

      Et notez qu'à cause de leur mauvais emplacement vous n'aurez pas accès au fichier html de doc ni au fichier de traduction, si vous faites cela.

      Si vous êtes bidouilleur, vous pouvez modifier leur extension en ".php" ou les déplacer dans le répertoire images et modifier en conséquence la page d'accueil.

      		Je suis encore trop mauvais pour vous donner des leçons sur Apache vous pouvez donc soit vous servir de fichiers .htaccess dans le répertoire en question soit régler le problème carrément au niveau du fichier de configuration d'Apache httpd.conf).
      Ecran admin IIS Une solution entre autres pour sécuriser tous les fichiers portant un nom donné, dans la config d'Apache : 
      <Files config.inc.php>
    Order allow,deny
    Deny from all
</Files>
      On peut toutjours dire que ce n'est pas un problème, que ce fichier ne retourne rien comme info, en temps normal. Sauf qu'il arrive, de temps en temps (constaté souvent en naviguant sur internet) qu'Apache renvoie le source du script php au lieu de le faire exécuter même sur un serveur configuré correctement et qui, au refresh de la page, vous donne le résultat attendu, d'ailleurs. En interdisant l'accès direct à ce fichier cela résoud le problème.

    3. Authentification en mode cookies  Haut de page

      4. Ce mode d'authentification est assimilable au mode http avec un gros avantage et deux gros inconvénients.

      L'avantage est la portabilité. Cela marche avec  n'importe quel navigateur et OS acceptant les cookies.

      Le premier inconvénient pourrait être que sur une machine partagée entre plusieurs personnes, on peut toujours craindre qu'un nouvel arrivant bénéficie d'un cookie non encore expiré de l'utilisateur précédent, même si ce dernier a bien refermé toutes ses fenêtre de navigation, pour peu qu'il n'ait pas quitté l'application proprement en signifiant qu'il se déconnectait. Cependant le mode d'emploi de phpmyadmin (2.4.0) précise que normalement le cookie est écrit dans un mode tel que le navigateur ne devrait pas l'enregistrer sur disque. Donc pensez à refermer vos fenêtres de navigation surtout.

      L'autre inconvénient se manifeste lorsqu'on est développeur et que l'on veut tester simultanément un accès privilégié et un autre avec phpmyadmin, sans refermer le premier navigateur. On a beau faire on se trouve directement identifié avec la première identité. On est donc bine obligé à chaque changement d'identité de tout refermer et rouvrir... usant !

      Par ailleurs, cela milite une fois de plus en faveur de systèmes sécurisés où chacun ne peut accéder qu'à ses propres cookies. S'il referme bien sa session (au sens réseau et/ou O.S. du terme), ses cookies ne peuvent être utilisés par l'utilisateur suivant même s'ils sont encore valides.

    Ecrire à Etienne Durup
    E. Durup - Dernière mise à jour : 22.02.2004
    Valid CSS!