Securité Dolibarr : le fichier install.lock ne doit pas être considéré comme optionnel sur vos installations

Pour ma part je rajouterai un test sur une variable pour l’action de création de compte utilisateur.
Mais oui, il faut que Dolibarr soit sécurisé de base et que si l’on souhaite réaliser des opérations qui ouvre des « portes » que ce soit clairement explicité et de la responsabilité de l’administrateur, pas l’inverse.
Une fois de plus, il n’est pas normal de pouvoir relancer les étapes de mise à jour et créer un utilisateur admin si il y en a déjà un existant !!!

2 « J'aime »

Ainsi qu’avec Caddy, lighttpd et tous les autres…

1 « J'aime »

Pas mal comme idée, mais si on va jusquau bout, il faudrait que la maj puisse se lancer depuis l’interface utilisateur par un user-admin. A ce moment, une fois lancée, seule l’ordinateur lié devrait pouvoir agir sur le script d’install (CSRF token, limitation ip ou mac adress ?)

A la fin de la mise à jour, il conviendrait dafficher la liste des modification effectuée en bdd mais aussi letat de la bdd en ce qui concerne les users-admin voire tous les user.

1 « J'aime »

Dolibarr integre déjà un mode maintenance qui pour ma par marche tres bien car je l’active pour restrindre les acces des utilisateur a celui du super admin uniquement en ensuite je demare la mise à jour.

Ah bon ? Où ça ?

la constante MAIN_ONLY_LOGIN_ALLOWED

1 « J'aime »

Merci @FHenry
@altatof c’est dans le wiki * MAIN_ONLY_LOGIN_ALLOWED ► Only the specified login is allowed to log in Dolibarr (maintenance mode).

Ce n’est pas cela qui va empêcher quiconque d’accéder à l’installation.

3 « J'aime »

Bonjour,

Je m’immisce dans ce thread pour un point de vue utilisateur assez frustrant qui concerne effectivement la sécurité. J’avais réussi à être conforme sur tous les points en suivant les recommandations de ce fil :

Puis passage en V15, et là, rebelote…

et là, la dynamique du thread me fait penser que soit tout le monde sait gérer la sécurité de son dolibarr et pif paf pouf en trois chmod a une installation clean… Soit c’est trop complexe et on passe vite à autre chose en fermant les yeux et en croisant les doigts. (Sans connaître réellement les risques objectifs la plupart du temps).

Le fichier install.lock, puisque c’est l’objet principal de l’OP n’est clairement pas le plus compliqué à créer pour un utilisateur lambda, que ce soit depuis un explorateur de fichier sur cpanel ou en local ou même en ligne de commande. Le fait qu’il soit créé automatiquement serait une bonne chose, mais cela reste un élément de sécurité parmi d’autres pour l’utilisateur lambda.

Imaginez moi derrière mon ordi:

*"wouuuhouu j’ai créé mon fichier install.lock, je suis trop fort, mais… c’est quoi tous les autres :

warning pcntl_alarm, pcntl_fork, pcntl_waitpid, pcntl_wait, pcntl_wifexited, pcntl_wifstopped, pcntl_wifsignaled, pcntl_wifcontinued, pcntl_wexitstatus, pcntl_wtermsig, pcntl_wstopsig, pcntl_signal, pcntl_signal_get_handler, pcntl_signal_dispatch, pcntl_get_last_error, pcntl_strerror, pcntl_sigprocmask, pcntl_sigwaitinfo, pcntl_sigtimedwait, pcntl_exec, pcntl_getpriority, pcntl_setpriority, pcntl_async_signals, pcntl_wifstopped, pcntl_signal, pcntl_sigprocmask, pcntl_async_signals, passthru, shell_exec, system, proc_open, popen, shell_exec"*

Ok, bon je verrai plus tard :thinking:, machin m’a demandé un devis! :money_mouth_face:

Je sais que tous ici êtes bénévoles, je connais la philosophie du libre. C’est juste un point de vue. Si je savais aider sur ce point je le ferai, je n’ai tout simplement pas les compétences, comme beaucoup de vos utilisateurs à priori.

Bonjour @KPBLS et merci de nous faire part de votre frustration.
Quelles sont vos attentes ou vos conseils pour y remédier ?

Bonjour @altatof,

Pour venir de temps en temps sur le forum, il est assez facile d’identifier qui fait quoi. Bien que bénévoles, vous avez tous vos domaines de prédilection, c’est assez facile à identifier entre les contributeurs au core, les contributeurs de modules complémentaires, les spécialistes des questions de compta (opendsi) etc… Il y a un noyau dur (et tant mieux!) et c’est en allant sur github que l’on peut voir qui est réellement investi sur le projet.

Par contre, je ne suis pas en mesure de dire qui s’occupe des questions de sécurité, qui vous en conviendrez, ont une priorité intrinsèque.

Alors bien sur, les vrais problèmes de sécurité peuvent être remontés sur github, outre le fait que c’est en anglais et plutôt jargonneux, ce n’est pas très compliqué à faire. Mais encore une fois, pour l’utilisateur lambda ce n’est pas toujours facile de savoir ce qui relève du bug, ou de la faille de sécurité ou ce qui relève de la configuration. Et combien de vos utilisateurs lambdas connaissent github?

Même entre vous, les dev, vous vous apprenez mutuellement des choses : pas plus tard qu’hier, j’ai lu un dev dire à un autre que la constante MAIN_JE_SAIS_PLUS_QUOI n’était pas nécessaire et qu’il valait mieux cocher la case « faire la même chose » dans l’écran de configuration du module en question.

Enfin, je vois souvent passer des threads très fournis de réponses pour de nouvelles fonctionnalités le plus souvent via des modules externes, plus rarement du core, très intéressantes au demeurant car cela démontre la maturité et le dynamisme du projet. Mais il s’agit, la plupart du temps, de discussion de développeur à développeur, de eoxia à opendsi, de eldy à ksar, de defrance à ptibogxiv de PM17 à philazerty… (Tous ne sont peut être pas développeurs, mais tous sont des utilisateurs avisés du forum)

A mon sens donc, sur le forum les dev parlent aux dev et cela se vérifie, sur le site dolibarr.org - forums - sujets top -depuis toujours, vous retrouverez majoritairement les personnes que j’ai cité de mémoire 5 lignes plus haut. Peut etre suis-je le seul utilisateur à avoir ce ressenti, mais je ne pense pas.

D’ou je parle?

Avant de venir sur dolibarr, je ne connaissais pas le libre ou plutôt vaguement. Mon premier logiciel de compta était celui d’une grooooooôôsse boite américaine pas libre du tout et plutôt cher (Quickb…ks) qui malgré tout ce qu’on peut en penser, quickb**ks à très vite su prendre en compte l’expérience de leurs nouveaux utilisateurs français. Trois fois je suis allé, sur invitation (entre 2015 et 2018), à Paris à la journée dans un grand hôtel, rencontrer l’équipe, participer à des entretiens sur l’expérience utilisateur.

Ok, c’est incomparable en termes de moyens. Et ça tombe bien car vous avez entre les mains un outil bien supérieur à ce que j’ai connu avant, beaucoup plus complet et complexe parfois. De plus, il est tout à fait possible de faire la même chose sans forcément aller dans un grand hôtel, ni même se déplacer de chez soi/du bureau.

Il y a aussi chez moi une certaine expérience en tant que formateur (dans le sport) qui consiste justement à prendre en considération le point de vue de l’utilisateur en contexte, je vous épargne les théories des actions situées et du courant théorique et méthodologique du cours d’action même si Lucy Suchman à déjà abordé en 1987 le dialogue entre l’homme novice et la machine intelligente : c’est justement ça, le point de départ des actions situées.

Ce que je suggère

« Tout formulaire informatique est une maltraitance »

Dixit Benjamin Bayard, (FFDN) s’appelant lui même volontiers « le vieux c*n des internets », personnage forcément connu par un grand nombre d’entre vous.

Certains connaissent bien sur son exemple sur le ministre délégué au numérique d’une époque récente, Olivier Ô, bien embêté pour saisir les trois premiers caractères de son nom de famille dans un champ déroulant… (video thinkerview sur youtube pour les curieux)

Globalement, dolibarr manque de documentation, ce n’est un secret pour personne, vous en êtes tous déjà très conscients. Cela concerne la sécurité puisque c’est le sujet de ce thread, les modules core, les bonnes pratiques, les flux de travail, bref l’expérience utilisateur.

Des choses qui vont dans le bon sens fleurissent à gauche à droite, comme cette série de vidéos très bien faite sur dolibarr, tellement bien faites qu’elles complètent désormais les articles du wiki il me semble. C’est bien avec cette série de vidéo que j’ai fini par comprendre que les « extrafields » c’était bête comme chou! MAIS… Elles n’existent que depuis un an, ce qui est peu par rapport à la longévité de dolibarr.

Je veux bien contribuer, mais en fait c’est ce que je fais déjà à l’instant même, je suis sur que plein de gens sont prêts à contribuer, mais c’est à vous les développeurs de créer le cadre le moins « maltraitant » possible et pour cela c’est aussi à vous d’aller à la pêche aux expériences utilisateurs.

Cela fait deux ans que je passe 5h par jour sur dolibarr, j’ai pas encore tout compris. En deux ans, a bidouiller sur les projets, les taches, les temps consommés, je viens juste de réaliser (ces jours ci) que je pouvais créer une intervention depuis un temps consommé en cochant une case d’action globale en face d’une ligne de temps consommés. Alors peut être que c’est nouveau en V16? Mais Peut être que ça a toujours été là, bien caché tant qu’on a pas coché une seule case…

Hier soir, je me suis dit que c’était beaucoup plus pertinent de n’utiliser les modèles de factures récurrentes UNIQUEMENT pour les contrats/abonnements, dans le sens ou X services sur un temps donné, = X factures souvent identiques et donc que la récurrence était paramétrable en fonction de la durée et récurrence des services de ce même contrat.

Bref, c’est ce que dans mon jargon a moi on appelle de « l’utilisabilité en contexte », soit l’outil est une prothèse, soit il est transparent, il devient incarné. Dolibarr n’est pas transparent pour l’utilisateur même si je sais que je ne trouverai pas mieux ailleurs. (Et comme dit plus haut, un logiciel quel qu’il soit sera toujours une prothèse, ou une maltraitance selon les termes de B.bayard, mais plus ou moins grande. L’ergonomie ne concerne pas que les objets matériels en somme.)

Pour en revenir à la sécurité, ma réponse c’est documentez! documentez!

exemple :

PHP disable_functions =
Vous devriez désactiver les fonctions PHP: pcntl_alarm, pcntl_fork, blah blah…

Pour vous c’est une infobulle qui dit

« ajoutez ce qui suit à la fin de votre fichier php.ini et faites un sudo systemctl restart phpd »

Pour l’utilisateur qui débute son auto-hébergement cela peut-être des heures de recherche web, pour un dev, c’est … une ligne dans un fichier, non? (oui, ok, multiplié par x infobulles, … )

un tel petit guide de paramétrage existe par exemple sur le module compta avancé… Un exemple ailleurs, libreoffice ouvre sur un « le saviez vous? »

Que dire de plus? Comme beaucoup de monde, je ne pose jamais de questions quand j’ai déjà la réponse et les devs c’est vous, vous connaissez la solution et si vous ne la connaissez pas encore, vous êtes aussi des spécialistes de l’intelligence collective.

Pour conclure, dolibarr est le meilleur outil que je connaisse à ce jour, et va le rester car je n’ai pas envie d’aller voir ailleurs. les fonctionnalités sont suffisantes voire trop importantes pour une grande majorité d’utilisateurs (ma main à couper!).

ET oui, je suis prêt à m’investir, comme vous, quand je peux (compétences : J’ai appris a comprendre un mot sur trois sur une ligne de code, par la force des choses, mais je suis incapable d’écrire la moindre ligne moi-même. ) et quand j’ai le temps (bénévolat)

Par conséquent, sur un forum ou les développeurs semblent parler aux développeurs je ne sais pas quelle est ma place aujourd’hui, mais je peux imaginer celle que les developpeurs ouvriront aux utilisateurs demain. :wink:

2 « J'aime »

Bonjour,

Je ne vais aborder que l’aspect sécurité.

Je n’y connais rien en mécanique auto, et il ne me viendrais jamais à l’idée de mettre la sécurité de ma voiture en jeu en essayant de changer moi-même les plaquettes de freins. Je confie le travail à un professionnel qualifié.

Il en va de même quand il s’agit de vouloir héberger une application web quelle qu’elle soit. Si l’on n’est pas qualifié pour en assurer la sécurité on confie le travail à un professionnel ou on choisit une solution Saas comme dolicloud par exemple.

Je pense que peut de gens sont conscients du niveau actuel d’attaques qu’il y a sur les serveurs. Je vous partage un graphe qui représente juste le nombre d’adresses ip bloquées par jour par fail2ban sur un de mes serveurs (ces graphes sont tous semblables sur l’ensemble de mes serveurs, et tous les admins sys que je connais constatent les mêmes évolutions).

Grosso modo jusqu’à fin février 2022 le niveau est normal, le nombre de tentatives d’intrusions a été multiplié par cinq dès le début de la guerre en Ukraine, et sur décembre ça a encore grimpé en flèche avec des pics à plus de 20 fois le volume moyen qui semblait « normal » il y a un an.

Bonjour @pascal_z,

Je vais juste prendre le temps de vous répondre, en tant qu’utilisateur encore une fois, parce qu’en fait, nos points de vue ne sont pas opposés, ils sont complémentaires. Mais promis, je ne vais pas jeter un pavé (dans la mare comme tout à l’heure, j’ai l’impression) ou pavé tout court.

Je comprends parfaitement votre point de vue et je vous donne raison sur cette thématique de la sécurité des serveurs. Maintenant ce qui est vrai pour le libre est vrai pour les logiciels propriétaires, et c’est vrai pour des grands groupes, des administrations, des régions, des hôpitaux.

L’actualité de cette fin 2022 regorge d’exemples : hopital de Cahors, de Versailles, Région normandie pour les derniers mois.

En 2021: Microsoft exchange, axa partners, acer…

et je ne parle pas d’attaque de type denial of service, il y a aussi des vols de données dans la plupart des cas.

Bref, celui qui veut trouver la faille, la trouve, car je suppose que toutes ses entreprises, surtout les exemples de 2021 ont une équipe informatique aux petits oignons.

Alors après, reste à savoir ce que ,philosophiquement, un projet comme dolibarr et d’autres veulent promouvoir… Et à priori ils ne sont pas là pour promouvoir des solutions alternatives comme dolicloud, qui est certainement tout aussi excellent que dolibarr vu que c’est la même personne qui est le lead des deux entités, qui, administrativement est certainement beaucoup plus simple qu’une solution auto hébergée, mais ne m’apparaît objectivement ni plus sécurisé, ni moins sécurisé… que…

  • Microsoft exchange…

  • axa partners…

  • ou acer…

voir : 10 cyberattaques qui ont marqué 2021

Après, tout est question de cible, personnellement, je ne suis pas persuadé que mon projet intéresse le hacker russe, alors j’ai choisi de m’auto-héberger. Et j’adhère à la philosophie du libre pour que mes données m’appartiennent, sur un serveur qui m’appartient, en france, conforme au RGPD, qui éventuellement ne se monétise pas sur mes données personnelles.

Du coup, @pascal_z je vais me lancer dans la paraphrase : Quels sont vos conseils pour y remédier ? Il semblerait que dolibarr soit en recherche de solutions pour se démocratiser en tant que logiciel libre.

Peu importe la réponse en fait, j’ai presque envie de m’excuser d’avoir donné un avis. Je laisse le post de l’OP reprendre son cours normal, même si, je ne suis peut être pas si illégitime que ça…

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.

1 « J'aime »

Vous faites erreur. Vous n’êtes pas ciblé par intérêt, vous êtes ciblé parce que vous avez un hébergement qui est potentiellement vulnérable. Le logiciel qui parcours le web à la recherche de machines vulnérables ne sait pas qui vous êtes ni si votre hébergement présente un quelconque intérêt.

Quand à mon conseil je l’ai déjà donné sur ce fil, mais je vais le répéter : quand on héberge une application web destiné à un nombre restreint d’utilisateurs, on ne la laisse pas accessible sur le réseau public. On met en place un réseau privé (VPN) pour ne permettre l’accès au serveur qu’à partir des machines qui font partie de ce réseau privé.

2 « J'aime »

J’accepte de faire erreur sur tous les points ou je peux potentiellement apprendre à mieux faire. Je peux comprendre qu’un bot ne fera pas la différence entre ma machine et celle d’un grand groupe.

En l’occurrence, je ne suis pas ciblé dans le cas d’espèce du fichier install.lock car je sais faire un touch install.lock lors de mon installation, je l’ai toujours fait je suis même de ceux qui cherchent à sécuriser au maximum leur installation. Même si le risque existe qu’un bot scanne mon installation au moment d’un upgrade, mais dans ce cas, TOUS les utilisateurs de dolibarr sont dans le même cas, pas que moi et c’est bien l’objet du post de l’OP et des discussions suivantes. Autrement dit, ceux qui sont en train de se pencher sur la question, sont à l’heure actuelle tout aussi exposés que moi à quelques exceptions près.

Rappelons au passage qu’il y a peu il était encore suggéré de mettre MAIN_REMOVE_INSTALL_WARNING (je dis bien suggéré, pas recommandé) ou de mettre à jour les droits et de créer le fichier install.lock. Sauf que, laisser le choix, c’est déjà permettre une faille de sécurité évidente à moins d’expliquer que l’un peut avoir du sens en local uniquement, mais surtout pas sur un site exposé sur le web.

Mais comme indiqué plus haut, je ne suis pas l’OP, je n’ai pas envie de flooder la discussion et la faire dévier vers autre chose que dolibarr, en l’occurrence mon cas personnel et mon installation.

Je reste cependant preneur de conseils, mon installation est sur ovh en public cloud. Je peux migrer sur un réseau soit complètement privé, soit exposé à Internet en utilisant les services Gateway ou Load Balancer avec des IP flottantes.

Si vous avez de recommandations à ce sujet, je suis preneur et disponible en MP.

Pour ce qui est de mon intention originelle, c’était de suggérer, dans la discussion, que la création d’un install.lock n’est pas le plus difficile à faire et que d’autres recommandations de sécurité sont quand à elles beaucoup moins évidentes à résoudre, et pour autant certainement aussi sensibles. Je parlais de pédagogie plus haut : mais en fait, pour le MAIN_REMOVE_INSTALL_WARNING ça devrait être clairement mentionné : NE FAITES PAS CA sur une installation exposée au web. Allez plutôt :

cd /var/www/dolibarr/documents
touch install.lock.

Et pourquoi c’est plus facile de créer un install.lock que pour les PHP disable_functions pour un utilisateur lambda? Bah justement parce que c’est contextualisé :

quel fichier : install.lock
ou: documents

versus :

Vous devriez désactiver les fonctions PHP: pcntl_alarm, pcntl_fork, pcntl_waitpid, …

quel fichier : :face_with_raised_eyebrow:
ou: :thinking: Ah si! en haut de la page : /etc/php/php.ini

Et parce que même si on sait, on peut oublier! C’est ce qui est arrivé à @defrance en lisant son post sur la V15. Et c’est la ou je suggère que les développeurs forcent les éléments de sécurité qui ont besoin d’être forcés, comme le fait de recréer le fichier install.lock après un upgrade et ils m’ont pas attendu pour y penser, sauf que c’est encore optionnel par contre. Et c’est pour ça aussi que je peux suggérer des fenêtres contextuelles de type "le saviez vous ? / conseil de sécurité / avez vous pensé à "… Après c’est pas a moi de dire ou et quand elles doivent apparaitre, c’est une suggestion.

Comme dit aussi @defrance il me semble, regardez ce qu’il se fait ailleurs, sur wordpress je me fais des « notes à moi même » avec les admin notices. Parfois juste pour me rappeler que telle page fonctionne avec tel plugin dans tel contexte : admin_notices | Hook | WordPress Developer Resources

Et ça c’est un allègement cognitif, ça c’est de l’utilisabilité en contexte.

Personne n’est à l’abri, je pense l’avoir montré. Demander à tout le monde d’avoir un install.lock sur des install non sécurisées par défaut en fonction des exclusions dans le php.ini ne résout qu’une partie du problème. Je suis de ceux qui ont suivi les recommandations quand elles sont apparues sur le forum pour la V14. Je suis de ceux qui ont relancé pour conserver une installation sécurisé en V15.

Après, excusez mon ignorance, mais les droits des fichiers sur linux c’est pas forcément ce qu’il y a de plus évident. Je laisse la discussion reprendre son cours normal, j’ai déjà l’impression d’avoir plus posté que vous tous réunis et j’ai pas envie de passer pour le chieur. Je reste dispo en MP pour ceux qui voudraient réagir, ou bien sur le post relatifs aux droits en V15.

Bonne soirée à tous et bravo pour le magnifique travail que vous faites pour la communauté.

1 « J'aime »

Je trouve ton intervention pertinente, même s’il y a quand même une bonne raison de se focaliser plus sur install.lock que sur d’autres recommandations : la vulnérabilité représentée par un install.lock manquant est majeure et a déjà été exploitée, alors que je n’ai pas connaissance d’attaques déjà menées sur des Dolibarr de production et exploitant des défauts de sécurisation des permissions sur les fichiers.

Attention, ça ne veut absolument pas dire que ces défauts sont minimes (déjà, je n’ai « pas connaissance » d’attaques pratiques, ça ne veut pas dire qu’il n’y en a pas eu et ça ne veut absolument pas dire qu’il n’y en aura pas). Je trouve simplement que ça justifie le fait d’épingler le sujet consacré à install.lock et de bien insister dessus.

Sur le reste, ton constat est parfaitement juste, Dolibarr gagnerait à offrir plus d’aide contextuelle sur les pages liées à la sécurité. Il y a cependant beaucoup de freins à ça : le premier, c’est le temps que chacun a pour s’en occuper¹. Le second, c’est qu’une bonne partie de la sécurisation passe par de l’administration système (donc hors du périmètre de Dolibarr lui-même, bien que Dolibarr soit directement concerné), et que Dolibarr peut tourner sur une myriade de plate-formes différentes qui ne pourront jamais faire l’objet d’une « recette » unique.

¹) le « budget temps » pour la sécurité est souvent plus réduit avant les attaques concrètes qu’après, c’est humain, et encore, l’association a quand même lancé les campagnes de bug bounty qui ont permis de boucher énormément de trous, donc on ne peut pas lui reprocher d’être passive.

2 « J'aime »

Bonjour
Peut etre un peu tard par rapport aux reflexions actuelles, mais pourquoi pas simplement un token envoyé par mail à l’admin pour activer la possibilite de mise a jour

l’admin se connecte, active la mise a jour, recoit un token, lance la mise a jour possible qu’avec le bon token…

par exemple c’est ce que j’ai fait dans virtualtimezone pour que le module patch les fichiers core de dolibarr.

ps il y a un défaut dans ma config, le token est visible dans les paramètres d’infos de dolibarr de la session (peut etre une option pour cacher les variables de session par defaut, il me semble que j’avais écrit quelque chose il y a un moment…) mais si tu es déjà connecte en admin pour avoir accès au token pas non plus besoin de passer par la faille d’install.lock

my 2 cents…


Plus précisément : transposer les règles dans le vHost nginx (c’est pas la même syntaxe que pour Apache)

Pourquoi ne pas avoir un répertoire d’install/update avec un nom aléatoire (et non public).
Un peu comme pour Prestashop qui a son dashboard avec une URL secrète.

2 « J'aime »

Non ce n’est pas la même syntaxe effectivement.
Pour Ngninx

deny all; allow 1.2.3.4;

Un outil pour « dégrossir » : htaccess to nginx converter
@+