Manuel d'utilisation d'AccessScope

Ce manuel explique comment utiliser l'outil de diagnostic qui repère les tentatives d'attaque dans les journaux d'accès d'un serveur, en indiquant à chaque fois les lignes de journal qui servent de preuve. Il commence par les étapes du diagnostic dans l'interface, et l'utilisation en ligne de commande est regroupée au chapitre 8.

1. À propos d'AccessScope

AccessScope est un outil de diagnostic qui lit les journaux que votre serveur web et votre serveur SSH écrivent déjà, et qui y cherche des tentatives d'attaque. Pour chaque élément trouvé, il affiche les lignes de journal sur lesquelles il repose. Il convient si vous gérez vous-même un serveur et voulez vérifier que les journaux ne contiennent pas d'accès suspects.

Les journaux sont uniquement lus. AccessScope ne les modifie pas, ne les supprime pas, ne bloque aucune communication et n'élève aucun privilège. Le diagnostic lui-même n'utilise ni LLM ni réseau.

Sur Mac, AccessScope est inclus dans le DMG de RoamSwitch, et sur Linux dans les paquets deb, rpm et tarball de RoamSwitch. C'est un outil distinct de RoamSwitch, sous licence Apache License 2.0. Pour le lancer, choisissez l'icône de l'application sur Mac, ou « AccessScope » dans la liste des applications sur Linux.

Fichiers enregistrés

AccessScope enregistre automatiquement les réglages, la liste des journaux trouvés, les règles d'exclusion et l'enregistrement servant à la comparaison avec l'exécution précédente. Tout se trouve sous ~/.config/accessscope/, avec des droits de lecture et d'écriture réservés à vous seul.

Mises à jour

Sur Mac, la connexion à lafine.net n'a lieu que lorsque vous cliquez sur « Rechercher des mises à jour » dans « Mises à jour » des réglages. Aucune information sur cet appareil ni sur les journaux n'est envoyée, et le fichier téléchargé n'est installé qu'après vérification de sa signature. Sous Linux, l'application n'a pas de mise à jour intégrée, et vous mettez à jour par les paquets.

2. Votre premier diagnostic

1. Choisissez les journaux. Le plus simple est « Rechercher les journaux sur cet appareil ». Il cherche automatiquement les journaux de nginx, d'Apache, de SSH et d'autres, et les liste sous « Journaux trouvés sur cet appareil ». Si vous connaissez l'emplacement, choisissez-le avec « Choisir des fichiers » ou « Choisir un dossier », ou déposez des fichiers ou des dossiers sur la fenêtre.
2. Choisissez la « Période ». La valeur par défaut est « 7 derniers jours », et vous pouvez aussi prendre « Dernières 24 heures », « 30 derniers jours » ou « Tout ». La période se compte à partir de maintenant, donc pour diagnostiquer d'anciens journaux, choisissez « Tout ».
3. Cliquez sur « Lancer le diagnostic ». La progression s'affiche avec « Lecture des journaux » puis « Analyse en cours », et le résultat s'ouvre à la fin.

3. Journaux lisibles et où les chercher

Le type de journal est reconnu automatiquement d'après son contenu. Les journaux archivés et compressés avec gzip se lisent aussi tels quels. Si vous choisissez un dossier, tous les fichiers qui ressemblent à des journaux sont lus ensemble.

« Rechercher les journaux sur cet appareil » examine les emplacements standard et les emplacements de journaux indiqués par les fichiers de configuration du serveur web. Seuls les journaux dont la lisibilité a été confirmée sont listés.

Conteneurs Docker

Si vous cochez « Vérifier aussi les conteneurs Docker », les journaux Docker de cet appareil sont aussi pris en compte. Avant le diagnostic, un écran de confirmation affiche la commande exécutée et les conteneurs visés, et la lecture n'a lieu que si vous cliquez sur « Accepter et diagnostiquer ». C'est de la lecture seule, sans élévation de privilèges.

Chercher les journaux avec un LLM (facultatif)

Si rien n'est trouvé, vous pouvez cliquer sur « Chercher aussi avec un LLM » pour que le LLM cherche les emplacements. On ne lui transmet que des faits sur l'environnement, comme les noms des serveurs en cours d'exécution et les noms des fichiers présents dans /var/log, jamais le contenu des fichiers. Les suggestions sont d'abord vérifiées comme lisibles, puis présentées avec la case décochée. Pour les réglages, voyez le chapitre 7.

4. Lire les résultats

Une fois le diagnostic terminé, vous pouvez consulter les résultats dans quatre onglets.

Comprendre une détection

Une détection s'affiche avec son nom, par exemple « Tentatives d'injection SQL », et porte une gravité (Élevée, Moyenne, Faible) ainsi qu'une confiance. La confiance indique jusqu'où le journal seul permet de conclure.

• Confirmé signifie que le journal seul permet de l'affirmer.
• Probable signifie que la tentative a très probablement eu lieu.
• Hypothèse signifie que le journal seul ne permet pas de le vérifier.

Si vous ouvrez les « Lignes de preuve », vous voyez telles quelles les lignes de journal à l'origine de la détection. Elles sont repliées par défaut. Lisez d'abord le nom et la raison, puis n'ouvrez que ce qui vous intrigue.

Le risque global (de 0 à 100) est un indicateur pondéré par la gravité et la confiance. Il n'augmente pas simplement parce que les occurrences sont nombreuses, et il ne passe pas à « Élevé » tant qu'il n'y a aucune détection de gravité élevée. Ce n'est pas une probabilité, prenez-le comme un repère.

5. Réduire le nombre de résultats à examiner

Règles d'exclusion

Les détections que vous savez normales, comme l'IP de votre bureau, la surveillance de disponibilité ou vos propres analyses de vulnérabilités, peuvent être retirées du rapport. Les détections exclues ne sont pas jetées, leur nombre est conservé avec la raison.

1. Dans l'onglet « Détections », cliquez sur « Exclure cette IP… » à côté de l'IP d'une détection.
2. Saisissez une raison, puis cliquez sur « Ajouter aux règles d'exclusion ». La raison reste dans le rapport.
3. Vérifiez le contenu dans la boîte de dialogue de confirmation, puis validez. La règle s'applique dès le prochain diagnostic.

Dans les réglages, « Règles d'exclusion » liste les règles actuellement actives. C'est un affichage seul, on ne peut pas les modifier à cet endroit. Les règles aux conditions plus fines s'écrivent dans un fichier du dossier des réglages (suppress.toml), dont la syntaxe est décrite au chapitre 8. Les détections de gravité « Élevée » ne sont pas retirées, même exclues, et restent dans le rapport.

Comparaison avec l'exécution précédente

Quand vous diagnostiquez plusieurs fois de suite la même combinaison de journaux, le résultat est comparé à l'enregistrement précédent, et les détections apparues depuis portent la marque « Nouvelle ». En cochant « Nouvelles seulement » dans l'onglet « Détections », vous n'affichez que les nouvelles. Au premier diagnostic, tout est considéré comme nouveau. L'enregistrement ne contient que l'empreinte (hachage) de la détection, son type, sa gravité, son nombre et l'heure, jamais de texte issu des journaux.

6. Exporter les résultats

Les boutons situés en haut de l'écran des résultats permettent d'emporter les résultats.

Avec « Exporter… », vous pouvez choisir pour la liste de blocage les formats fail2ban-ip, nftables, ipset, nginx-deny, apache-require et csv. La liste des détections s'exporte en CSV, SARIF ou JSON.

Pour la liste de blocage, la condition « À inclure » se choisit entre « Par défaut », « plus strict » et « plus large », et le nombre d'IP exportées est affiché avant l'enregistrement. Les IP des robots d'indexation officiels et celles couvertes par une règle d'exclusion ne sont jamais incluses.

7. Analyse par un LLM (facultative)

Cette fonction fait résumer par un LLM les résultats du diagnostic. Elle est désactivée par défaut. Pour l'utiliser, cochez « Activer l'analyse par un LLM » dans « Intégration LLM » des réglages, choisissez le « LLM à utiliser », puis cliquez sur « Enregistrer ». Le choix se fait parmi claude, opencode, codex et agy, ceux dont la commande est installée sur l'appareil.

Ce qui est envoyé

• Les journaux bruts ne sont pas envoyés. On envoie des statistiques et les faits des détections, avec pour chaque détection jusqu'à 3 lignes de journal comme preuve (300 caractères au maximum par ligne).
• Les secrets comme les clés, les jetons et les mots de passe, ainsi que les adresses e-mail, sont masqués avant l'envoi.
• Les IP sont transmises sous une forme neutralisée, comme 203[.]0[.]113[.]9. Si vous cochez « Ne pas envoyer les vraies IP (utiliser des pseudonymes) », elles sont remplacées par des pseudonymes comme ip-001.

En cliquant sur « Afficher exactement ce qui sera envoyé » dans l'onglet « Analyser avec un LLM », vous voyez le texte complet qui serait envoyé. Cette action n'envoie rien. L'envoi n'a lieu que lorsque vous cliquez sur « Analyser avec un LLM ».

• Le contenu d'un journal peut être écrit par un attaquant. AccessScope signale comme détection les chaînes qui ressemblent à des instructions destinées à une IA, et affiche la sortie du LLM comme une citation non fiable. Un LLM peut aussi juger une détection plus grave qu'elle ne l'est, donc vérifiez toujours les conclusions avec les lignes de journal qui servent de preuve.
• AccessScope lance claude et opencode avec leurs outils désactivés (exécution de commandes et lecture de fichiers). Pour codex et agy, les outils ne peuvent pas être désactivés, vous devez donc cocher la confirmation qui apparaît dans les réglages. L'analyse par LLM peut aussi être utilisée en tant que root, mais le LLM s'exécute alors avec les droits root ; un utilisateur sans privilèges est recommandé (une remarque s'affiche dans les réglages tant que l'app s'exécute en root).

8. Utilisation en ligne de commande

Dans un environnement sans interface comme la Server Edition, ou pour une exécution régulière avec cron, utilisez la commande accessscope. Elle repose sur le même moteur que l'interface, donc les détections trouvées sont les mêmes.

accessscope discover
accessscope scan --auto --since 7d --report report.md
accessscope scan /var/log/nginx/access.log /var/log/auth.log

Exécution quotidienne avec cron

accessscope scan --auto --since 24h --since-last --new-only --fail-on medium

N'affiche que les détections absentes de l'exécution précédente, et ne se termine avec le code de sortie 3 que si les nouvelles détections sont de gravité moyenne ou plus. Le diagnostic sans --llm fonctionne aussi en root.

Écrire suppress.toml

Les règles d'exclusion s'écrivent dans ~/.config/accessscope/suppress.toml. Si ce fichier existe, il est lu automatiquement.

[[rule]]
reason  = "office"
ip      = ["203.0.113.0/28"]
expires = 2027-03-31

[[rule]]
reason      = "uptime monitor"
ua_prefix   = ["Mozilla/5.0 (compatible; UptimeRobot"]
path_prefix = ["/healthz"]

• Une règle s'applique aux requêtes qui correspondent à tous les éléments écrits. reason est obligatoire et apparaît dans tous les rapports. Une règle dont expires est dépassé ne s'applique plus.
• Une détection de gravité « Élevée » n'est exclue que si la règle contient allow_high = true.
• Le User-Agent et le chemin sont des valeurs que le client peut écrire. Une règle qui les utilise seuls, sans IP, ne peut pas exclure les détections d'attaque, d'authentification ou de web shell.

9. Ce qui n'est pas possible

• On ne voit que les faits restés dans les journaux. Le corps des requêtes, le contenu des réponses, l'état interne des applications et les périodes disparues avec la rotation restent inconnus. L'absence de détection ne prouve pas que tout est sûr.
• Une détection signifie qu'il y a eu une tentative, pas qu'elle a réussi. Le User-Agent est déclaratif et peut être falsifié.
• Les enchaînements entre plusieurs journaux reposent uniquement sur le fait que l'adresse est la même. Derrière un NAT ou un proxy, des personnes sans rapport apparaissent sous la même adresse. Les adresses internes (un reverse proxy ou une passerelle Docker) représentent de nombreux clients à la fois ; elles n'entrent donc pas dans un enchaînement. Un enchaînement sans signe de réussite reçoit la gravité « faible ».
• « Connexions depuis une source inhabituelle » veut dire inhabituelle pour ce journal, et pas forcément frauduleuse. « Écarts par rapport à l'habituel » montre seulement un changement, qui n'est pas forcément une attaque.
• Les journaux AWS ALB et CloudFront ont été testés avec des lignes construites d'après les définitions de la documentation AWS, et non avec de vraies sorties AWS.

10. En cas de problème

Un élément apparaît dans « Journaux illisibles pour le moment »

C'est l'affichage en cas de droits insuffisants. AccessScope ne lit pas en élevant les privilèges. Procédez de l'une des façons suivantes.

• Pour les journaux sous forme de fichiers, lancez AccessScope avec un utilisateur qui a les droits, ou choisissez une copie du journal avec « Choisir des fichiers ».
• Pour journald sous Linux, lancez AccessScope en root ou avec un utilisateur des groupes adm, systemd-journal ou wheel.
• Pour le journal unifié de macOS, lancez AccessScope avec un utilisateur du groupe admin.

« Aucun journal diagnosticable n'a été trouvé sur cet appareil » s'affiche

La raison s'affiche sous forme de phrase, par exemple « Il n'y a aucun journal de serveur web (Apache, nginx, etc.) ». Sur Mac, s'il n'y a pas d'enregistrements SSH, on lit « La connexion à distance (SSH) est peut-être désactivée ». Avec « Choisir des fichiers », « Chercher avec un LLM » et « Indiquer un autre emplacement » qui s'affichent, vous pouvez tenter l'étape suivante. Pour savoir où la recherche a eu lieu, ouvrez le « Résultat détaillé de la recherche », replié par défaut.

« Les journaux Docker n'ont pas pu être lus » s'affiche

Soit Docker n'est pas en cours d'exécution, soit Docker est introuvable, soit les droits manquent, soit Docker a renvoyé une erreur. Si les droits manquent, lancez AccessScope avec un utilisateur autorisé à utiliser Docker. AccessScope ne relit pas en élevant les privilèges, et il ne demande ni ne conseille de rejoindre le groupe docker, car les droits du groupe docker équivalent à ceux de root sur l'hôte.

« Illisible comme journal » s'affiche

Cet affichage apparaît quand aucune ligne du fichier choisi n'a pu être analysée. Le fichier n'est pas diagnostiqué et n'est envoyé nulle part. Vérifiez qu'il s'agit d'un type de journal pris en charge, puis choisissez-le de nouveau.

Impossible de cliquer sur « Analyser avec un LLM »

La raison s'affiche près du bouton. Si l'on lit « L'intégration du LLM est désactivée », activez-la dans les réglages. Si l'on lit « Aucun LLM n'est sélectionné », choisissez-en un dans les réglages. La fonction est aussi indisponible quand vous avez lancé l'application en root, ou quand la commande du LLM à utiliser n'est pas installée sur l'appareil.

Les sources d'accès sont uniquement des IP de proxy

Dans les journaux situés derrière un reverse proxy ou un CDN, la source d'accès peut être l'IP du proxy. Avec la valeur par défaut « Automatique », l'IP du client est déterminée à partir de X-Forwarded-For uniquement pour les lignes dont la source enregistrée est une adresse interne, comme un reverse proxy ou une passerelle Docker. Les lignes venues directement de l'extérieur gardent la source enregistrée. L'en-tête pouvant être falsifié, une IP déterminée ainsi n'est jamais traitée comme un robot d'indexation vérifié. Pour désactiver cela, choisissez « Ne pas utiliser » dans « Analyse » des réglages. Vous pouvez aussi choisir la première adresse en partant de la droite qui n'est pas un proxy de confiance, ou l'adresse la plus à gauche ; le client pouvant modifier cette valeur, ne les utilisez que derrière un relais de confiance que vous gérez. Elle prend effet au prochain diagnostic.