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

Bonjour,

La V16.0.3 intègre déjà quelques correctifs qui bloquent principalement la deuxième partie de l’attaque, qui permettait de prendre le contrôle du serveur.
Par contre, le script d’install est toujours vulnérable sans install.lock.

Bonjour à tous
Une bonne pratique serait d’ajouter un fichier .htaccess pour n’autoriser le dossier install qu’à certaines adresses ip. Certes c’est pas natif Dolibarr mais ça sécurise dur !

# Restriction des adresses IP
# Ordre de priorité des instructions : refuser puis autoriser
Order Deny,Allow
# On n’autorise personne à accéder au site…
Deny from all
# …Sauf l’adresse IP x.x.x.x
Allow from x.x.x.x

A noter que tout intégrateur doit se poser la question de la sécurité sans faire une confiance à Dolibarr. La faille peut venir du serveur aussi, des droits…
Quand je vois l’état de certaines installations « maison » ça fait peur !
@+

@Philazerty attention, je viens d’apprendre que nginx ne tient pas compte du htaccess…

voir aussi ce module Maintenance Mode
(peut-être qu’il génère un htaccess)

Oui c’est vrai, il faut importer le .htaccess dans le nginx.conf il me semble.

Après l’installation il suffit de supprimer le dossier htdocs/install et il n’y a plus de problème d’accès à ce dossier.

Non car certaine tables sont creer à l’activation des modules (comme le module ticket) et les fichiers de création sont dans htdocs/install. Et aprés comment vous faites les mise a jour de Dolibarr ?

Pour une mise à jour il y a un nouveau dossier install de créé qui provient de la nouvelle version.
Quand à l’installation des modules, une fois dolibarr configuré ce n’est pas une opération qu’on fait tous les jours, rien n’empêche de remettre en place le dossier provisoirement en cas de besoin.
Le maillon faible étant le dossier install, il est logique pour moi de le supprimer une fois qu’il n’est plus nécessaire.

Mais comme déjà évoqué si Dolibarr n’est utilisé que par un nombre de personnes restreint, on passe sur un réseau privé avec wireguard et on est tranquille.

je me cite,

Il faut toujours apprendre de ce que font les autres, j’ai installé un wordpress et tenté de relancer l’installation pour créer un nouveau compte admin, cela est naturellement impossible.
A titre d’info dans les principes de déclaration de faille, il n’est pas expressément notifié qu’il faille ajouter ce fichier.
Je vais donc voir comment empêcher la création d’un nouveau compte admin si il y en a déjà un en activité, même si le fichier install.lock (et le fichier conf.php) est déjà présent.

Il n’y a rien besoin de plus…

1 « J'aime »

ce n’est pas le seul problème; dans l’absolu il faudrait pouvoir avoir un écran (?) qui permette de basculer en mode maintenance en indiquant une IP autorisée ou un système équivalent qui marche aussi bien avec Apache que nginx.
Parce que sinon, il faut prier que personne n’essaye d’accéder à Dolibarr au milieu d’une migration…
(bien sûr les geeks comme nous vont jouer sur le htaccess ou le paramétrage de nginx pour faire cela, mais ce n’est pas donné à tout le monde… et il faut ne pas oublier de le faire)

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 ?