Résumé de l'épisode précédent
Lors de mon précédent billet sur l'installation et la configuration de phpMyAdmin sur CentOS 6, nous avions obtenu une installation fonctionnelle, mais perfectible. Nous allons voir ensemble comment rendre l'installation plus confortable et tenter de la sécuriser un peu.
Authentification par cookie
Lors de la connexion à phpMyAdmin, c'est une authentification de type HTTP qui est envoyée. Sachant que nous n'avons pas encore activé HTTPS, les identifiants circulent en clair sur le réseau. De plus, à chaque fois qu'on ferme la fenêtre ou l'onglet du navigateur, il faut s'authentifier à nouveau. Le cookie devrait donc aider. Pour activer ce mécanisme, éditons le fichier de configuration de phpMyAdmin :
[root@crashtest ~]# vi /etc/phpMyAdmin/config.inc.php
A la ligne 41, on trouvera l'expression suivante :
$cfg['Servers'][$i]['auth_type'] = 'http'; // Authentication method (config, http or cookie based)?
Il suffit donc de remplacer 'http' par 'cookie' puis d'enregistrer le fichier. Le paramètre 'config' est à manipuler avec la plus grande précaution, et nécessite de renseigner les identifiants dans les champs suivants, ce qui n'est pas du tout sécurisé à mon sens. Une fois la modification effectuée, une (jolie ?) page d'identification devrait apparaître en lieu et place de l'horrible notification du navigateur demandant le login et le mot de passe. En prime, il est possible de choisir la langue :-)
Maintenant, un message assez étrange risque d'apparaître lors de vos prochaines connexions, en bas de l'interface de phpMyAdmin : Vous devez ajouter dans le fichier de configuration une phrase de passe secrète (blowfish_secret).
Allons donc éditer de nouveau le fichier de configuration, à la ligne 14 :
$cfg['blowfish_secret'] = ''; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */
Et entre les guillemets simple, on insère une phrase de passe. Quelques exemples :
- je vois un gnou faire de la bicyclette
- je ne sais pas programmer en python (ou perl, java, c, ruby, ce que vous voulez)
- aieruhgpauOUGYVaerhg 07856qorieghg (oui, l'aléatoire fonctionne aussi)
Le but n'est pas de fournir une phrase intelligible ou facilement mémorisable, mais une suite de caractère assez longue pour chiffrer le mot de passe dans le cookie. Il ne sera pas nécessaire de réutiliser cette phrase de passe.
HTTPS
L'authentification par cookie apporte un mieux, mais celui-ci peut toujours être intercepté et rejoué par quelqu'un de malintentionné. De plus l'intercepteur pourra examiner le traffic et en retirer les commandes jouées, ou pourquoi pas le contenu des base de données. L'un des moyens d'empêcher cette interception est de chiffrer le trafic entre la machine cliente et le serveur hébergeant phpMyAdmin et MySQL. Pour cela nous allons activer mod_ssl dans Apache afin de naviguer en HTTPS dans phpMyAdmin.
Installons donc mod_ssl :
[root@crashtest ~]# yum install mod_ssl
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* epel: mirrors.ircam.fr
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package mod_ssl.x86_64 1:2.2.15-5.el6.centos set to be updated
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
mod_ssl x86_64 1:2.2.15-5.el6.centos base 85 k
Transaction Summary
================================================================================
Install 1 Package(s)
Upgrade 0 Package(s)
Total download size: 85 k
Installed size: 183 k
Is this ok [y/N]: y
Downloading Packages:
mod_ssl-2.2.15-5.el6.centos.x86_64.rpm | 85 kB 00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : 1:mod_ssl-2.2.15-5.el6.centos.x86_64 1/1
Installed:
mod_ssl.x86_64 1:2.2.15-5.el6.centos
Complete!
Relançons Apache :
[root@crashtest ~]# service httpd restart
Arrêt de httpd : [ OK ]
Démarrage de httpd : [ OK ]
Et rendons-nous sur phpMyAdmin, en HTTPS. Dans mon cas l'url est https://crashtest/phpmyadmin/ . Un message du navigateur signale alors que le certificat utilisé pour se connecter est auto-signé.
Il est courant d'accepter le certificat et de le mémoriser : à plus forte raison s'il s'agit d'une machine de tests ou de développement, il suffit de s'assurer que le certificat ne changera pas en le mémorisant dans le navigateur; si jamais ce message devait à nouveau s'afficher, soit vous avez réinstallé le serveur ou changé les certificats, soit un petit malin tente une attaque de type "homme du milieu" (man in the middle en anglais).
Il est aussi possible d'accepter le certificat sans pour autant le mémoriser, et (faire) créer les certificats adéquats, selon votre type d'organisation ; les grosses entreprises possèdent leur propre autorité de certification et la déploient sur leurs postes de travail. Si votre serveur est directement accessible depuis Internet, de nombreux prestataires proposent, gratuitement ou non, de générer un certificat qu'il vous faudra ensuite installer en lieu et place de ceux par défaut. Cela peut vous éviter de vérifier manuellement sur chaque nouvelle machine cliente qu'il s'agit du bon certificat.
La mise en œuvre détaillée d'un serveur HTTPS et d'une infrastructure de gestion de certificats SSL d'entreprise (appelée aussi PKI de l'anglais Public Key Infrastructure) ne fait pas partie des objectifs de ce billet, par conséquent elle est laissée en exercice au lecteur.
Notre serveur accepte donc les connexions HTTP en clair et les connexions HTTPS chiffrées.
Pare-feu
En plus de chiffrer des connexions, il est possible de les filtrer. Dans le précédent billet, nous avons vu qu'Apache peut interdire ou accepter certains clients suivant leur adresse IP. Il est possible, avec un pare-feu (firewall en anglais), de filtrer les connexions Apache comme MySQL ou SSH et d'effectuer un contrôle plus fin sur les connexions.
Sur un système GNU/Linux, en particulier CentOS, le pare-feu de référence est Netfilter (qui fournit entre autres la commande iptables). La plupart des autres projets de pare-feu pour GNU/Linux sont généralement des surcouches à Netfilter.
Attention ! il est très facile, lorsqu'on manipule des règles de filtrage de connexions réseau, de scier la branche sur laquelle on est assis. Si bloquer accidentellement les connexions réseau lorsqu'on est devant la machine n'est pas bien grave, couper la connexion SSH qu'on utilise oblige à se déplacer, couper le pare-feu une fois devant la machine, puis repartir à son poste et se reconnecter.
Pour éviter ce genre de désagrément, il est possible de planifier une tâche qui coupe le firewall, par exemple toutes les 10 minutes. Ainsi, dès qu'on se rend compte que la machine ne répond plus à rien sur le réseau, il ne reste qu'à attendre 10 minutes tout au plus pour que la machine soit à nouveau accessible. L'inconvénient est qu'il faut réussir à faire ses modifications en moins de 10 minutes ! Nous allons donc éditer la crontab
:
[root@crashtest ~]# crontab -e
Il est fort probable qu'elle soit vide, puisqu'il s'agit de la crontab de root et que la machine est fraîchement installée. Ajoutons la ligne suivante :
*/10 * * * * /etc/init.d/iptables stop > /dev/null 2>&1
Et voilà ! Toutes les 10 minutes, le pare-feu sera désactivé. Le temps d'effectuer une modification, et de la valider. Attention cependant, une fois que les changements seront validés, penser à effacer cette ligne, ou à la commenter. Pour plus d'information : la page de manuel. Une fois le garde-fou mis en place, passons aux choses sérieuses : définir les règles de filtrage à mettre en place, puis les mettre en place.
Afin de rester dans les clous de la distribution, nous n'allons pas créer un script de pare-feu personnalisé, mais utiliser le fichier déjà en place pour sauvegarder les règles. Ce fichier est /etc/sysconfig/iptables, mais comme indiqué en anglais en tête de ce fichier, il n'est pas recommandé de l'éditer manuellement. Nous allons donc lancer le pare-feu, ajouter des règles avec la commande iptables, vérifier leur bon fonctionnement, les sauvegarder, et vérifier la sauvegarde.
Lancement du pare-feu :
[root@crashtest ~]# service iptables start
iptables : Application des règles du pare-feu : [ OK ]
Vérification des règles actuellement activées :
[root@crashtest ~]# service iptables status
Table : filter
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
5 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:25
6 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
1 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
Et si on tente de se connecter à phpMyAdmin, cela ne fonctionne plus. Il faut donc accepter les connexions vers le port 80 (HTTP) et 443 (HTTPS). Nous allons insérer dans la chaine INPUT avant la règle numéro 5 (celle qui accepte le port 25 tcp) une règle acceptant le port 80 :
[root@crashtest ~]# iptables -I INPUT 5 -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
Si on se connecte à phpMyAdmin, cela fonctionne en HTTP, mais pas en HTTPS. Continuons, cette fois insérons notre règle avant la numéro 6 (décalage oblige du fait de notre insertion précédente) :
[root@crashtest ~]# iptables -I INPUT 6 -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
Voilà, maintenant nous accédons à phpMyAdmin en HTTPS. Vérifions les règles en mémoire pour comparaison avec la situation précédente :
[root@crashtest ~]# service iptables status
Table : filter
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
5 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
6 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443
7 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:25
8 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
1 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
A noter que la commande iptables -L -n donne le même résultat, et pourrait servir sur d'autres distributions Linux.
A présent, sauvegardons notre configuration :
[root@crashtest ~]# service iptables save
iptables : Sauvegarde des règles du pare-feu dans /etc/sysconfig/iptables : [ OK ]
Vérifions la sauvegarde :
[root@crashtest ~]# cat /etc/sysconfig/iptables
# Generated by iptables-save v1.4.7 on Thu Sep 22 20:34:19 2011
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1118:858094]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Thu Sep 22 20:34:19 2011
On peut donc voir que les règles acceptant les ports 80 sont bien sauvegardées. La règle autorisant le port 25 n'est pas utile, elle fut ajoutée en exemple lors du billet sur une installation minimaliste de CentOS 6. Le retrait de cette règle est laissé en exercice au lecteur ;-)
Une fois les règles en place donnant satisfaction, il faut penser à retirer le garde-fou en éditant la crontab : on peut alors supprimer la ligne désactivant iptables, ou la mettre en commentaire en place le caractère "#" devant. Après le retrait du garde-fou, on peut activer le pare-feu au démarrage :
[root@crashtest ~]# chkconfig --list iptables
iptables 0:arrêt 1:arrêt 2:arrêt 3:arrêt 4:arrêt 5:arrêt 6:arrêt
[root@crashtest ~]# chkconfig iptables on
[root@crashtest ~]# chkconfig --list iptables
iptables 0:arrêt 1:arrêt 2:marche 3:marche 4:marche 5:marche 6:arrêt
Base de données phpMyAdmin
phpMyAdmin est maintenant un outil complet avec de nombreux paramètres. Certains peuvent être utilisés via le fichier de configuration, mais pour d'autres, une base de données est nécessaire. D'ailleurs, selon le paquet phpMyAdmin installé (une version à jour est arrivée pendant l'écriture des deux billets), vous pouvez avoir le message suivant en bas de l'interface : Le stockage de configurations phpMyAdmin n'est pas complètement configuré, certaines fonctionnalités ont été désactivée. Pour en connaître la raison, cliquez ici.
Dans la version plus récente, cet avertissement a été retiré.
Utilisons phpMyAdmin pour créer un nouvel utilisateur dit de contrôle
(via l'onglet Privilèges
), et appelons-le tout simplement phpmyadmin
. Le paramètre client est Local
, et on génèrera le mot de passe aléatoirement. Pensez à copier ce mot de passe ailleurs, on va en avoir besoin un peu plus tard. Toujours dans l'interface de création de l'utilisateur, cochons l'option Créer une base portant son nom et donner à cet utilisateur tous les privilèges sur cette base
. Enfin, cliquons sur le bouton du bas : Créer un compte d'utilisateur
. Une autre manipulation est nécessaire car l'utilisateur de contrôle a besoin d'un peu plus de droits. Pour aller plus vite, rechargeons les privilèges puis cliquons sur l'onglet SQL
et entrons le texte suivant dans le champ (j'espère que vous avez bien copié le mot de passe généré de tout à l'heure ;-)):
GRANT USAGE ON mysql.* TO 'phpmyadmin'@'localhost' IDENTIFIED BY 'motdepassealeatoire';
GRANT SELECT (
Host, User, 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,
Show_db_priv, Super_priv, Create_tmp_table_priv, Lock_tables_priv,
Execute_priv, Repl_slave_priv, Repl_client_priv
) ON mysql.user TO 'phpmyadmin'@'localhost';
GRANT SELECT ON mysql.db TO 'phpmyadmin'@'localhost';
GRANT SELECT ON mysql.host TO 'phpmyadmin'@'localhost';
GRANT SELECT (Host, Db, User, Table_name, Table_priv, Column_priv)
ON mysql.tables_priv TO 'phpmyadmin'@'localhost';
Cliquons sur Exécuter
et on nous signale que MySQL a retourné des résultat vides. Pensons à recharger les privilèges (dans l'onglet Privilèges
Encore une chose. Il nous faut peupler la base de données créée pour phpMyAdmin. Pour cela, revenons dans le shell de notre serveur et utilisons le fichier SQL fourni par phpMyAdmin :
[root@crashtest ~]# mysql -u root -p < /usr/share/phpMyAdmin/scripts/create_tables.sql
Maintenant éditons à nouveau le fichier de configuration de phpMyAdmin :
[root@crashtest ~]# vi /etc/phpMyAdmin/config.inc.php
Et renseignons aux lignes 34 et 36 l'utilisateur de contrôle et son mot de passe :
$cfg['Servers'][$i]['controluser'] = 'phpmyadmin'; // MySQL control user settings
// (this user must have read-only
$cfg['Servers'][$i]['controlpass'] = 'motdepassealeatoire'; // access to the "mysql/user"
// and "mysql/db" tables).
// The controluser is also
// used for all relational
// features (pmadb)
Une fois le fichier enregistré et déconnecté puis reconnecté à phpMyAdmin, nous pouvons utiliser toutes les possibilités de cet outil !
SELinux
J'avoue ne pas être familier avec SELinux. Je me suis contenté d'éditer /etc/sysconfig/selinux et de passer le paramètre SELINUX à enforcing. Un reboot plus tard, SELinux est activé, httpd, mysqld sont lancés, et phpMyAdmin est accessible !