Connexions suspectes Nextcloud : détection et réponse en 2026

Une alerte Nextcloud Suspicious Login signale une connexion réussie que le modèle juge inhabituelle pour un compte et une adresse IP. Elle ne prouve pas qu’un attaquant a pris le contrôle du compte. Elle ne bloque pas non plus la session. Il faut donc distinguer un déplacement légitime, un changement de réseau, une erreur de proxy et une compromission réelle avant d’agir.

Ce guide explique ce que l’application observe, pourquoi elle a besoin d’une période d’apprentissage, comment vérifier son fonctionnement et quelle procédure appliquer après une alerte. Il complète le guide complet de Nextcloud sans reprendre l’ensemble du durcissement du serveur.

Que détecte Suspicious Login, et que ne fait-il pas ?

Suspicious Login est livrée avec Nextcloud Server depuis la version 25. Pour la branche stable 35 consultée le 30 octobre 2026, son manifeste déclare l’application en version 13.0.0, compatible avec Nextcloud 35. La présence du code dans l’installation ne suffit toutefois pas à prouver que l’application est activée ou qu’un modèle exploitable a déjà été entraîné.

L’application écoute les connexions réussies. Elle associe l’identifiant du compte à l’adresse IP vue par Nextcloud, puis compare ce couple au comportement appris. Si le modèle classe la connexion comme suspecte, l’application enregistre l’événement et déclenche une notification dans Nextcloud ainsi qu’un e-mail lorsque le compte possède une adresse et que le serveur sortant fonctionne.

Elle ne remplace pas les protections contre les essais de mot de passe. Chaque mécanisme intervient à une étape différente :

• Suspicious Login observe une connexion réussie inhabituelle et alerte le titulaire du compte.
• La protection anti-bruteforce de Nextcloud réagit aux échecs ou comportements suspects sur l’authentification en ralentissant les requêtes concernées.
• Fail2ban reconnaît des motifs dans les journaux et peut bloquer une adresse au niveau réseau.

Le guide Fail2ban avec Nextcloud traite donc une autre décision : bannir temporairement certaines sources d’échecs. Suspicious Login intervient après une authentification réussie et n’effectue aucune action automatique sur le compte. Le message officiel indique à l’utilisateur d’ignorer l’alerte si la connexion est légitime, ou de changer son mot de passe dans le cas contraire.

Comment l’application apprend-elle les connexions habituelles ?

À chaque connexion réussie, l’application collecte l’identifiant du compte, l’adresse IP et l’heure. Une tâche d’arrière-plan transforme ensuite les lignes brutes en données agrégées : première observation, dernière observation et nombre de passages pour chaque couple utilisateur et IP. Le code stable 35 planifie cette agrégation toutes les heures et supprime les lignes brutes une fois leur traitement effectué.

Les modèles IPv4 et IPv6 sont séparés. Deux tâches quotidiennes tentent de les entraîner. Si les données sont insuffisantes, aucun modèle n’est produit pour la famille d’adresses concernée. Le fichier de configuration du code fixe par défaut une fenêtre maximale de 60 jours et réserve les 7 jours les plus récents à la validation. Le README du projet avertit qu’une première période d’environ 60 jours peut être nécessaire avant le premier entraînement utile.

Une instance neuve peut donc collecter correctement les connexions sans générer immédiatement d’alertes. Lancer manuellement la commande ne crée pas artificiellement l’historique manquant :

sudo -u www-data php occ suspiciouslogin:train --stats --dry-run

L’option --stats affiche les mesures du modèle entraîné. --dry-run évite de le conserver. La commande peut consommer des ressources et renvoyer un manque de données. Utilisez-la pendant une fenêtre contrôlée, avec le compte système et le chemin occ adaptés à l’installation. Pour la planification générale, préférez cron à AJAX ou Webcron sur une instance utilisée en production.

Comment vérifier que Suspicious Login fonctionne ?

Commencez par vérifier l’activation de l’application :

sudo -u www-data php occ app:list --enabled | grep suspicious_login

Une ligne présente confirme l’activation, pas l’existence d’un modèle. Contrôlez ensuite ces cinq dépendances :

1. Cron s’exécute réellement : l’agrégation horaire et les entraînements quotidiens dépendent des tâches d’arrière-plan.
2. L’adresse cliente est correcte : Suspicious Login utilise l’adresse renvoyée par Nextcloud. Derrière un frontal, une mauvaise chaîne de confiance peut faire apprendre l’adresse du proxy à tous les comptes.
3. Le relais e-mail fonctionne : l’alerte intégrée peut exister alors que l’e-mail échoue, ou l’inverse selon le contexte de consultation.
4. Le compte possède une adresse e-mail : le code n’envoie rien par ce canal lorsqu’elle manque.
5. La période d’apprentissage est suffisante : une absence de modèle est normale tant que les données historiques et récentes ne répondent pas aux conditions d’entraînement.

Le tutoriel du reverse proxy Nextcloud détaille trusted_proxies, les en-têtes transférés et la vérification de l’adresse observée. Testez depuis deux réseaux distincts, puis confirmez que Nextcloud voit bien deux adresses clientes, sans exposer de journaux ou d’identifiants dans une capture publique.

Les connexions par jeton ne suivent pas le même chemin de classification qu’une connexion par mot de passe. Dans le code stable 35, un événement marqué comme connexion par jeton n’est pas classé comme suspect, même si la collecte de la connexion réussie est exécutée. Suspicious Login ne remplace donc pas la revue des appareils, des clients synchronisés et des mots de passe d’application.

Pourquoi une alerte peut-elle manquer ou se répéter ?

L’application limite les notifications afin d’éviter une avalanche de messages. Dans la version étudiée, une seconde détection pour le même compte et la même IP n’envoie pas de nouvelle alerte pendant la fenêtre de validation par défaut de 7 jours. Le code coupe aussi une notification supplémentaire lorsqu’il compte plus de 3 événements suspects pour le compte sur la dernière heure, ou plus de 10 sur les deux derniers jours.

Ces limites concernent l’envoi, pas la certitude du modèle. Un utilisateur ne doit donc pas conclure qu’aucune alerte signifie qu’aucune connexion inhabituelle n’a eu lieu. À l’inverse, plusieurs alertes peuvent révéler un déplacement fréquent, un proxy mal déclaré, une rotation rapide d’adresses ou un modèle encore peu représentatif des usages.

Par défaut, l’e-mail et la notification proposent un bouton vers iplookup.flagfox.net pour obtenir des informations sur l’adresse. Ce service est externe à l’instance. Si l’organisation ne souhaite pas présenter ce lien à ses utilisateurs, l’application permet de le retirer :

sudo -u www-data php occ config:app:set \
  --value 0 suspicious_login show_more_info_button

Cette modification retire le bouton d’information, pas la détection ni l’adresse affichée dans l’alerte. Une localisation IP reste approximative et ne permet pas d’identifier une personne avec certitude.

Que faire après une connexion suspecte Nextcloud ?

Appliquez une procédure courte depuis un appareil et un réseau de confiance. Ne commencez pas par supprimer les traces.

1. Vérifier si la connexion peut être légitime

Relevez l’heure, l’adresse IP et le compte concernés. Demandez au titulaire s’il vient de changer de réseau, de téléphone, de VPN ou de lieu de travail. Comparez avec les appareils et sessions connus. Si la connexion est confirmée, aucune action automatique de Suspicious Login n’est à annuler, car l’application n’a pas bloqué le compte.

2. Contenir un accès non reconnu

Si le titulaire ne reconnaît pas la connexion, changez le mot de passe depuis un appareil sain, révoquez les sessions inconnues et retirez les mots de passe d’application qui ne sont plus nécessaires. Vérifiez ensuite la double authentification, les codes de secours et l’adresse e-mail de récupération. Le guide de la double authentification Nextcloud décrit l’enrôlement, l’application par groupes et la récupération administrative.

Pour un compte relié à un annuaire ou à un fournisseur d’identité, corrigez aussi la source d’authentification. Changer seulement un secret local qui n’est pas utilisé par le compte ne contient pas l’incident.

3. Préserver et rapprocher les traces

Conservez la période utile de nextcloud.log, du frontal web et, s’il est activé, du journal admin_audit. Notez le fuseau horaire et la version de l’instance. Comparez l’adresse vue par Nextcloud à celle du proxy, puis recherchez les modifications de partages, groupes, fichiers et appareils autour de l’heure concernée. Le guide Nextcloud Activity et audit explique les limites de chaque source.

Une adresse IP et un user agent restent des indices. Ils peuvent être partagés, masqués ou falsifiés selon l’architecture. Ne présentez pas une correspondance géographique comme une preuve d’identité.

4. Corriger la voie d’entrée

Recherchez un mot de passe réutilisé, un poste compromis, une session laissée ouverte, un second facteur absent ou une mauvaise configuration du proxy. Réinitialisez les secrets concernés, mettez à jour les composants et contrôlez les droits du compte. Si des données sensibles ont pu être consultées ou modifiées, appliquez la procédure d’incident et les obligations adaptées au contexte de l’organisation.

Quelle recette réaliser avant de compter sur les alertes ?

Validez la chaîne complète avec des comptes et données de test :

1. confirmer que suspicious_login est activée ;
2. vérifier le passage régulier de cron ;
3. confirmer l’agrégation puis la présence d’un modèle après une période suffisante ;
4. comparer l’adresse cliente derrière chaque proxy ou répartiteur ;
5. tester l’envoi d’e-mail système indépendamment de l’application ;
6. vérifier qu’un utilisateur sait distinguer une connexion légitime d’un accès inconnu ;
7. documenter le changement de mot de passe, la révocation des sessions et la conservation des journaux ;
8. refaire la recette après une mise à niveau majeure ou une modification du frontal.

N’essayez pas de provoquer une alerte avec un compte réel ou une adresse client sensible. L’objectif n’est pas de faire confiance à un message isolé, mais de vérifier chaque maillon : collecte, entraînement, adresse cliente, notification et réponse.

Conclusion

Suspicious Login apporte un signal utile sur les connexions réussies inhabituelles, à condition de lui laisser un historique, d’exécuter cron et de fournir la bonne adresse cliente. L’application avertit, mais ne bloque pas et ne prouve pas une compromission. Préparez donc une procédure qui confirme le contexte, révoque les accès non reconnus, conserve les traces et corrige la cause. Pour utiliser Nextcloud sans administrer cette chaîne serveur, choisissez un service dont le périmètre d’exploitation et de support est explicite.

Découvrir l’offre Nextcloud GaprodEspace Nextcloud géré et hébergé en France

Sources officielles

• README de Suspicious Login, branche stable 35
• Manifeste de l’application Suspicious Login 13.0.0
• Collecte et classification des connexions réussies
• Enregistrement, limitation et notification des détections
• Configuration des fenêtres d’entraînement
• Tâches quotidiennes d’entraînement IPv4 et IPv6
• Contenu et bouton des notifications
• Configuration des tâches d’arrière-plan Nextcloud
• Configuration officielle des reverse proxies