A tous les intégrateurs, développeurs (voire utilisateurs.trices auto-didactes de l’installation auto hébergé) qui avez des Dolibarr accessibles depuis internet, veillez bien à mettre/créer un fichier install.lock dans votre dossier document. (Où il est ce dossier ? lors de l’installation vous l’avez choisi, sinon regarder dans votre fichier conf/conf.php)
Une exploitation, documentée sur les sites spécialisés, permet une exécution de code arbitraire sur votre serveur. Cette exploitation à déjà eu lieu sur certains Dolibarr « mal » installés.
Exécution de code arbitraire => le hackeur pourra faire ce qu’il veut sur votre serveur, le chiffrer, récupérer votre base de données, spammer, vous avez votre boutique en ligne ou votre site internet sur le même serveur, pareil…, bref tout ce qu’on peut faire avec un serveur sur internet
Ce n’est pas une faille de sécurité à proprement parler de Dolibarr, car cela relève des bonnes pratiques et Dolibarr vous le dit quand vous ne l’avez pas fait (sur la page d’accueil).
Si on laisse les clefs sur la porte alors qu’on vous dit de pas le faire…
Totalement Lié, ce serait bien que l’on prenne au sérieux les remontés de faille de sécurité au lieu de simplement dire « c’est la faute de l’installateur qui n’a pas fait correctement son job », à un moment une installation par défaut ne devrait pas permettre ce genre de problème et la fameuse constante dont parle @aspangaro-Easya devrait être active par défaut et pas l’inverse.
Y a quand même quelque chose qui à mon sens devrais être changer.
Dissocier les warning car si on cache celui pour les droits du fichier config on cache également celui pour le fichier install.lock qui ne me semble pas être lié.
Surtout que de mon côté j’installe mes instance Dolibarr en PHP fpm avec un utilisateur dédié donc pas le choix de laisser les droits sur le fichier de config.
Je pense qu’on ne peut pas exclure que des bots essayent de façon répétée d’exploiter l’absence d’install.lock sur des instances accessibles depuis l’extérieur.
Autrement dit, supprimer le fichier, même une minute (le temps de faire une montée de version par exemple) est dangereux.
Il faudrait envisager d’appeler les scripts d’update (update.php et update2.php) uniquement depuis la ligne de commande et d’ajouter une exception à la vérification du install.lock lorsque le script est appelé en cli dans inc.php :
D’autres solutions sont possibles et il y en a probablement de meilleures (celle que je propose ne peut pas fonctionner pour des gens qui n’ont pas d’accès SSH au serveur d’install, notamment)… Qu’en pensez-vous ?
J’ai travaillé plusieurs années avec le CMS TYPO3 et voilà l’approche qu’ils avaient :
Leur « Install Tool » était accessible par mot de passe spécifique uniquement à l’« Install Tool » et défini lors de l’installation initiale (comme pour les identifiants de base de données). Sans saisie de mot de passe, pas possible d’accéder à l’Install Tool.
Pour pouvoir accéder à la page de saisie de mot de passe et débloquer l’Install Tool, il faut aussi créer un fichier ENABLE_INSTALL_TOOL dans le sous répertoire typo3conf. Ce fichier doit être inscriptible (droits en écriture par le serveur Web).
Lorsque le fichier est créé et que la personne accède à l’URL de l’install tool, si le fichier ENABLE_INSTALL_TOOL existe dans le répertoire typo3conf et est inscriptible par le serveur web, alors le formulaire de saisie de mot de passe de l’install tool est affiché à l’utilisateur et TYPO3 inscrit le timestamp d’accès dans le fichier.
Si l’utilisateur saisi un mauvais mot de passe, la valeur haché/salée saisie par l’utilisateur est affichée afin de pouvoir facilement « redéfinir » le mot de passe en modifiant la variable de configuration dans le fichier de configuration principal de TYPO3.
A chaque chargement de TYPO3, dans la routine d’initialisation, la présence du fichier ENABLE_INSTALL_TOOL est vérifiée et si le timestamp présent à l’intérieur est supérieur à une certaine durée (il me semble de mémoire que c’était 15 minutes), le fichier est supprimé automatiquement.
Ce process me semble relativement réfléchi et sécurisé.
Est-ce qu’ajouter un fichier « install.delock » (par exemple) avec une ligne par adresse IP (MAC serait mieux) autorisée à lancer plutôt le script ne serait pas plus simple que d’ajouter/enlever un fichier install.lock ?
L’avantage, c’est que l’absence du fichier protège l’infrastructure. Ça peut par exemple éviter de prolonger cette faille de sécurité inutilement, typiquement lorsque le script s’interrompt avant la fin du process (et que donc il ne crée pas le fichier d’install.lock) ou même un problème d’attaque déni de service sur l’hébergeur (et donc la console) pendant une maj.
En plus, le changement de paradigme (absence = secure au lieu de presence = secure) facilite la sécurisation de tous les sites lors de la mise à niveau.
En général, je suis pour simplifier, plutôt que compliquer, mais comme je suis pas un expert de ces questions, je ne sais pas si ma proposition est réaliste et si elle ouvre d’autres portes.
Oui, c’est une partie de la solution décrite ci-dessus.
Après le fait de whitlister des IPs n’est pas forcément une bonne idée car beaucoup de personnes ne disposent pas forcément d’IP fixes (IP flotantes attribuées par certains FAI, connexion depuis 4G dans certains cas aussi).
Toute la difficulté dans l’ensemble mais cela vaut pour toutes les problématiques de sécurité, c’est de trouver un équilibre entre sécurité et praticité/simplicité de mise en oeuvre.
Oui, mais cela suppose d’indiquer ton adresse IP quelque part (par exemple dans le fichier conf.php) pour pouvoir lancer l’installeur.
Pourquoi pas, mais ça ne règle pas le problème des réseaux d’entreprise qui ont une IP de sortie identique pour tous les postes de l’entreprise (dans ce cas, n’importe quel employé pourrait lancer l’installation/mise à jour). La problématique est la même pour une association par exemple qui a plusieurs postes dans ses bureaux utilisant une même connexion Internet et la solution de l’adresse physique Mac me paraît trop compliquée pour les utilisateur plus néophytes.
D’une manière générale, la solution (à minima) d’un mot de passe pour exécuter l’installeur me parait finalement la plus simple pour l’utilisateur et permet de s’assurer qu’uniquement les personnes connaissant le mot de passe puisse lancer l’outil.
Bonjour à tous,
La solution du mot de passe est bonne.
De mon point de vue, depuis une page installation / mise à jour, j’afficherais un tableau avec des coordonnées aléatoires et je demanderais à l’utilisateur qui lance une installation ou une mise à jour de donner le code en E4 / C3 / A6 etc… ce qui fait qu’il n’y a pas de mot de passe supplémentaire à gérer au final
Si on a un nombre restreint de personnes qui doivent accéder à une application en ligne, c’est l’idéal. On crée un réseau privé, et on configure le serveur en ligne pour n’accepter que des connexions de ce réseau privé.
