Atrilya
Toute la documentation

Documentation

Dépannage & FAQ

Questions fréquentes et vérifications à faire depuis la console lorsqu’un comportement inattendu survient, souvent un état volontaire ou un agent temporairement injoignable.

Cette page regroupe les questions fréquentes et les vérifications à faire lorsqu’un comportement inattendu survient. Dans la plupart des cas, la cause tient à un état volontaire (mode simulation actif) ou à un agent temporairement injoignable.

En clair

  • La majorité des « problèmes » sont en réalité des états attendus : un mode simulation encore actif, ou un agent qui vient de redémarrer.
  • Chaque section ci-dessous donne la vérification à faire depuis la console, sans intervention technique sur le serveur.
  • En cas de doute, le journal d’audit (onglet Système) retrace qui a changé quoi.

L’agent apparaît hors-ligne

Symptôme : l’état de connexion de l’agent est rouge/orange dans la console.

L’agent envoie régulièrement un heartbeat (battement de cœur). La console le considère comme à jour si ce signal est récent ; au-delà d’un délai, l’agent est signalé hors-ligne et certaines validations (features, AppSec) sont mises en pause par sécurité.

À vérifier :

  1. Utilisez le bouton Tester la connexion dans l’onglet Système.
  2. Un agent venant de redémarrer peut mettre quelques minutes à réémettre son heartbeat, attendez le prochain cycle.
  3. Vérifiez que le serveur hébergeant l’agent est en marche et joignable.
  4. Si l’état ne revient pas au vert après plusieurs cycles, contactez le support.

La protection ne bloque rien

Symptôme : du trafic manifestement hostile n’est pas bloqué.

Cause la plus fréquente : le mode simulation est actif. En simulation, les décisions sont journalisées et ne sont pas appliquées.

À vérifier, dans l’ordre :

  1. Mode simulation : un bandeau ambre est-il affiché en haut de la console ? Si oui, la protection est en observation seule. Désactivez la simulation pour passer en application réelle.
  2. Désarmement d’urgence : l’agent a-t-il été désarmé ? Le désarmement met la protection en surveillance seule. Réarmez-le depuis l’onglet Système.
  3. Mode panique : il soumet le trafic à une vérification. Déclenchement manuel. Désactivez-le une fois l’incident résolu.
  4. IP de confiance : l’IP concernée figure-t-elle dans la liste de confiance ? Une IP de confiance contourne les règles HAProxy du bundle (voir section faux positif ci-dessous).
  5. Niveau d’offre : certaines protections dépendent du niveau souscrit. Vérifiez que la capacité attendue est bien disponible à votre palier (Référence de configuration).

Un visiteur légitime est bloqué (faux positif)

Symptôme : un client, un prestataire ou un outil interne est bloqué à tort.

Solution : ajoutez son IP à la liste de confiance. Elle contourne les règles HAProxy du bundle. Pour une décision déjà posée, levez-la depuis la console.

Marche à suivre :

  1. Identifiez l’IP concernée, l’onglet Réponse permet la recherche et l’enquête par IP.
  2. Ajoutez-la depuis l’onglet Système (portée agent pour une machine, équipe pour toute l’organisation), avec un commentaire de justification.
  3. Vérifiez l’aperçu effectif pour confirmer sa prise en compte.

Pour un faux positif récurrent sur un endpoint précis, une règle personnalisée en log_only permet d’observer sans bloquer avant d’ajuster.

Une IP de confiance est refusée à la saisie

Symptôme : un message d’erreur apparaît à l’ajout d’une IP de confiance.

La saisie est validée par une règle centrale. Les refus courants :

  • Format invalide : la valeur n’est pas une IP ou un CIDR valide (IPv4/IPv6).
  • Préfixe trop large : la plage dépasse le plancher autorisé (au moins /16 en IPv4). Restreignez la plage.
  • Doublon : l’entrée existe déjà dans la même portée.
  • Plafond atteint : la limite dépend de votre niveau d’offre.
  • Commentaire manquant : la justification (3 à 255 caractères) est obligatoire.

Système d’exploitation

Confirmez avec nous votre version de Debian avant l’installation.

L’agent s’appuie sur rsyslog, installé avec le paquet.

Une règle personnalisée « ne fait rien »

Symptôme : une règle est créée mais sans effet visible.

À vérifier :

  • La règle est-elle activée ? Une règle désactivée n’est pas appliquée.
  • L’action est-elle log_only ? Dans ce cas, la règle observe et journalise sans agir sur le trafic, c’est le comportement attendu.
  • L’action score_boost n’entraîne pas un blocage direct : elle augmente un score et peut rester sans effet visible.
  • Le mode simulation est-il actif ? Le cas échéant, aucune règle n’est appliquée réellement.

Après une modification, rien ne change côté agent

Les changements de configuration (IP de confiance, règles, désarmement) sont appliqués via le paquet signé descendu vers l’agent, ou via un déclenchement immédiat de synchronisation. Un court délai est normal.

  • Attendez le prochain cycle de synchronisation de l’agent.
  • Vérifiez l’état de connexion : un agent hors-ligne ne reçoit pas sa nouvelle configuration tant qu’il n’a pas rétabli le contact.
  • Le journal d’audit confirme que la modification a bien été enregistrée côté console.

Le cycle de vie de l’agent (installation, mises à jour, désinstallation) suit le processus standard des paquets Debian (apt).

Où trouver plus d’aide

  • Portée de la protection et ce qu’AtriShield ne couvre pas : Sécurité & divulgation.
  • Signaler une vulnérabilité : voir la politique de divulgation responsable.
  • Pour tout autre blocage, contactez le support AtriShield.