Durcir Nextcloud au-delà du scan intégré : posture, intégrité des fichiers, alertes rançongiciel

Pourquoi le contrôle externe ne suffit pas

Si vous faites tourner Nextcloud, vous connaissez sans doute le scan de sécurité officiel qui examine votre instance depuis internet et signale ce qu'un inconnu peut voir : en-têtes, TLS, version exposée. La vue d'ensemble d'administration fait aussi sa part. Nextcloud gère déjà la limitation de débit, le hachage des mots de passe, les en-têtes, la 2FA, les signatures d'intégrité, etc., et il le fait bien.

Ce qu'aucun des deux ne voit, c'est l'état qui s'accumule pendant qu'un serveur est réellement utilisé. Le compte qui peut encore se connecter avec un mot de passe seul. Le mot de passe d'application d'un client de synchronisation retiré depuis des mois, qui fonctionnerait encore aujourd'hui. Le fichier de l'installation qui a changé alors que personne n'y a touché. Le fichier de configuration que votre serveur web remet à quiconque le demande. C'est ce vide que comble Sentinel : un contrôle de sécurité continu, hébergé dans votre Nextcloud, qui prévient une personne dès que l'un de ces points change.

Ce tutoriel déroule une séance pratique de durcissement Nextcloud avec lui, de la première référence jusqu'à une entrée cron hebdomadaire.

Prérequis

• Nextcloud 34 et PHP 8.4 ou plus récent. Rien d'ancien, volontairement.
• Les tâches de fond (Cron) de Nextcloud en fonctionnement, pour les surveillances et le résumé quotidien.
• Les paramètres de messagerie de Nextcloud configurés, si vous voulez des alertes par e-mail.
• Facultatif : le démon EDR (Linux 4.20+, Python 3.9+, root et systemd) et, éventuellement, ClamAV via sa socket clamd.

L'installation elle-même est courte. Téléchargez l'archive depuis votre compte MediaLab Works sous Licenses, extrayez-la dans apps/ (ou custom_apps/) avec le propriétaire de l'utilisateur du serveur web, activez-la, puis collez votre clé de licence sous Administration settings → Sentinel → License. Les étapes complètes figurent dans le guide.

Étape 1 : prendre la référence avant de changer quoi que ce soit

Faites-le une fois que l'installation est dans l'état où elle doit être :

sudo -u www-data php occ sentinel:baseline take

La référence enregistre le code de l'installation — lib, core, apps, 3rdparty, config, themes — à cet instant. Elle ne couvre jamais les fichiers des utilisateurs. Dès lors, seuls les changements survenus depuis cet instant sont signalés.

Après chaque mise à jour de Nextcloud ou d'une application, approuvez une fois les fichiers modifiés, avec une note que vous comprendrez plus tard :

sudo -u www-data php occ sentinel:baseline accept --all --note "Nextcloud 34.0.4"

Un correctif volontaire reçoit le même traitement. Ce qui reste ensuite n'est que le changement inexpliqué — exactement ce que vous voulez examiner. Sous The files, vous pouvez ajuster les parties de l'installation couvertes par la référence, les types de fichiers, les exclusions, la limite de taille et le hachage.

Étape 2 : lire la page de posture, du plus grave au moins grave

La page de posture liste les constats avec, à côté de chacun, le motif et la solution. En pratique, vous verrez notamment :

• des comptes qui peuvent se connecter avec un mot de passe seul ;
• des mots de passe d'application obsolètes ;
• des sessions inactives ;
• des administrateurs dormants ;
• l'expiration de certificat ;
• si quelque chose est journalisé, tout simplement.

Descendez la liste. Chaque constat indique ce qu'il signifie et ce qui se passe si vous l'ignorez, et propose l'action (expirer, révoquer, supprimer) sur place. Les seuils pour « trop ancien » sont les vôtres, à régler sous What counts as too old : mots de passe d'application obsolètes, sessions inactives, administrateurs dormants et liens sans expiration.

Étape 3 : sonder ce que votre serveur web sert réellement

L'auto-sonde demande à votre propre serveur web, en visiteur anonyme, des fichiers qui ne doivent jamais être servis : la configuration, le journal, les répertoires .git. Tout ce qui revient est signalé.

Vous pouvez aussi la lancer depuis le terminal :

sudo -u www-data php occ sentinel:check --probe

Sous Asking the server what it serves, vous activez ou désactivez la sonde, ajoutez des chemins supplémentaires qui vous importent, et fixez le nombre de jours d'avertissement souhaités avant l'expiration du certificat.

Étape 4 : surveiller les voies d'entrée

L'inventaire liste chaque voie d'entrée dans votre instance : liens publics, sessions, mots de passe d'application, appartenance à des groupes — avec, à côté de chacune, expirer, révoquer ou supprimer. Combinez-le avec les surveillances, qui vous alertent quand quelque chose change : un compte qui devient administrateur, la 2FA désactivée, un nouveau compte, une adresse utilisée par plusieurs comptes, un administrateur qui se connecte depuis un nouveau réseau, des applications activées ou désactivées, des domaines de confiance ou des proxys modifiés, ou un lien ouvert par une foule à laquelle il n'a jamais été envoyé.

Les connexions sont mémorisées par le réseau utilisé par un compte, pas par l'adresse exacte, et les domaines de confiance et proxys ne sont stockés que sous forme d'empreintes. Sous Where people sign in from, vous décidez si les réseaux sont mémorisés du tout, si les nouveaux vous avertissent, quelle est la précision d'un réseau et quels comptes ignorer. Sous Public links, vous réglez la surveillance de l'usage des liens, la taille de foule qui mérite une mention, l'écart au-dessus du propre relevé du lien, et le nombre de tentatives de mot de passe refusées à partir duquel on parle de devinette.

Étape 5 : repérer les changements de type rançongiciel

Sentinel ne juge pas sur le seul débit. Il détecte un rançongiciel sur un portable synchronisé grâce aux fichiers qui cessent d'être ce que leur nom annonce, aux notes de rançon et aux renommages massifs. Les réglages se trouvent sous Files changing very fast : la fenêtre, le nombre de réécritures, de suppressions ou de renommages vers une même extension, et le choix entre alerter seulement ou désactiver le compte et mettre fin à ses sessions.

Ce dernier point est désactivé par défaut, et je le laisserais ainsi tant que vous ne faites pas confiance aux seuils sur vos propres données. Sentinel ne change rien de lui-même sauf si vous le lui demandez.

Étape 6 : s'assurer que les alertes atteignent un humain

Sous Being told, choisissez à partir de quelle gravité la cloche et l'e-mail sont utilisés, ajoutez une adresse supplémentaire — idéalement une qui atteint un téléphone —, fixez l'heure du résumé quotidien, puis appuyez sur Send a test message. Lisez ensuite la vue d'ensemble : dans quel état est le serveur, ce qui est surveillé et ce qui ne l'est pas, et si les alertes atteindraient quelqu'un.

Étape 7 : placer un contrôle hebdomadaire dans cron

occ sentinel:check affiche le rapport et se termine avec un code non nul quand quelque chose demande attention, ce qui fait d'une entrée cron hebdomadaire qui n'envoie un courriel qu'en cas d'échec une seule ligne :

sudo -u www-data php occ sentinel:check --quiet-when-clean

Elle accepte aussi --inventory et --json quand vous voulez envoyer la sortie ailleurs.

Facultatif : démon EDR et ClamAV

Si vous voulez savoir quel programme écrit dans le répertoire de données, le démon EDR fourni dans apps/sentinel/edr/ tourne en root hors de Nextcloud et peut suspendre le processus fautif :

cd /var/www/nextcloud/apps/sentinel/edr
sudo sh install.sh
sudoedit /etc/sentinel-edr/config.ini    # at minimum data_dir
sudo sh install.sh                       # again, to grant the paths it needs
sudo systemctl enable --now sentinel-edr

Sous Which program is writing, vous indiquez à Sentinel si le démon est attendu et où il dépose ses rapports. Séparément, A scanner to ask vous permet de le pointer vers ClamAV : la socket et la quantité d'un fichier à envoyer. ClamAV analyse les fichiers qui ont déjà l'air suspects.

Astuces et dépannage

• La section d'intégrité liste beaucoup de fichiers modifiés juste après l'installation. Aucune référence n'a encore été prise, ou une mise à jour n'a pas été approuvée. Prenez la référence, ou lancez occ sentinel:baseline accept --all --note "..." après vérification.
• Rien n'est surveillé alors que l'application est activée. Les tâches de fond doivent tourner (Cron). Après une désactivation puis une réactivation, ouvrez une fois la page Sentinel : les tâches sont remises en place et le contrôle de configuration le signale.
• Les alertes par e-mail n'arrivent pas. Vérifiez les paramètres du serveur de messagerie de Nextcloud et utilisez Send a test message. Les administrateurs sans adresse e-mail ne reçoivent que la cloche.
• Vous l'avez retiré avec occ app:remove et des tables sont restées. Retirez-le depuis l'application ou avec occ sentinel:remove à la place. Les comptes désactivés par Sentinel restent désactivés jusqu'à leur libération (--release-accounts), et le démon EDR continue de tourner jusqu'à ce que vous l'arrêtiez avec systemctl disable --now sentinel-edr.
• Mettre en pause ou retirer. Vous pouvez mettre la surveillance en pause, désactiver l'application en gardant tout (occ app:disable sentinel), ou la retirer avec tous les enregistrements qu'elle a écrits (occ sentinel:remove).
• Confidentialité. Aucune télémétrie ni compte cloud. La seule connexion sortante est le contrôle de licence quotidien vers medialab.works, qui envoie la clé d'abonnement, l'identifiant de l'instance, une empreinte matérielle hachée, la version de l'application et une somme de contrôle des fichiers propres de l'application — rien sur vos utilisateurs, leurs fichiers, leurs connexions ou les événements. Tout est conservé dans quatre tables : référence, événements, réseaux connus et usage quotidien des liens.

Pour conclure

Prenez la référence, lisez la page de posture, sondez ce que votre serveur sert, et laissez les surveillances et le résumé quotidien vous prévenir quand quelque chose bouge. C'est la moitié intérieure du durcissement Nextcloud, et c'est celle qu'un scan distant ne verra jamais. Si vous bloquez, le guide contient la référence complète, le changelog suit ce qui a changé, et la base de connaissances et la FAQ couvrent le reste.