Configurer l'agent Linux

Chaque clé de /etc/reportedip-agent/config.yaml avec sa valeur par défaut et sa plage, les seuils de détection par source, l'escalade des bannissements, les limites de fonctionnement, le courrier qui arrive quand quelque chose ne va pas, et quel changement prend effet à la prochaine synchronisation, à un redémarrage, ou dans la minute.

Configuration

Un fichier, une liste blanche, un répertoire d'état. Ce que l'installateur écrit convient déjà à l'hôte ; la plupart des installations ne changent que deux choses, la valeur de mode et le fait que le blocage local soit actif ou non.

Chaque clé de config.yaml

Seul api_key est obligatoire. Chaque autre clé a la valeur par défaut indiquée, et une clé que vous omettez conserve cette valeur. Une valeur en dehors de sa plage est une erreur qui nomme la clé, jamais un écrêtage silencieux. Les points dans les noms ci-dessous marquent l'imbrication : ban.enabled est un enabled: indenté sous ban:.

Un fichier complet que l'analyseur accepte, avec chaque bloc qu'un hôte normal utilise :

# /etc/reportedip-agent/config.yaml   root:root 0600
api_key: "YOUR_API_KEY"
api_url: https://reportedip.com/wp-json/reportedip/v2

log_level: warn              # debug | info | warn | error
log_file: /var/log/reportedip-agent.log
log_max_mb: 10
log_keep: 3
auto_update: true

backend: auto                # auto | ipset | nftables
mode: drop                   # log | drop | off
confidence: 90               # the feed threshold
limit: 50000

lists:                       # ssh, edge and group are always on
  ssh:
    ports: [22]              # written by install from the real listener
  edge: {}
  mail: {}
  web: {}

min_entries:                 # below this many addresses a list is not applied
  ssh: 1000
  mail: 500
  web: 500
  ftp: 500
  edge: 1000

whitelist_file: /etc/reportedip-agent/whitelist.conf

min_hits: 5                  # the global detection pair
window_minutes: 10
web_min_hits: 50             # the web source uses its own
web_window_minutes: 120
dedup_hours: 6
queue_max: 5000
disk_min_mb: 200

sources:                     # detected at install time
  - type: sshd
  - type: web
    glob: /var/www/*/log/access.log
  - type: web-error
    path: /var/log/nginx/error.log
  - type: postfix
    path: /var/log/mail.log
  - type: dovecot
    path: /var/log/mail.log
  - type: scan               # the kernel log; adds the port scan rule

thresholds: {}               # per event source overrides, see below

ban:                         # block local finds, not only the feed
  enabled: true
  time_minutes: 30
  max_time_minutes: 10080
  escalate: 4
  memory_hours: 24

notify:
  email: ""                  # empty means no mail
  cooldown_hours: 24
  relay: true                # through reportedip.com, from Professional

Limites de détection, par source

Un seuil est un couple : combien d'occurrences, en combien de minutes. C'est la même idée que maxretry et findtime d'une jail fail2ban. Trois niveaux décident quel couple s'applique à une source d'événement, et le premier qui a une réponse gagne.

La clé sous thresholds est la source d'événement de cette table, pas le type de source de sources. Les deux nombres doivent valoir au moins 1. Un seul bloc thresholds, une entrée par source que vous voulez changer :

thresholds:
  # A resolver that sees a lot of refused queries: fewer minutes,
  # more hits.
  named:
    hits: 40
    window_minutes: 5
  # A mail server whose customers keep mistyping passwords: SASL a
  # little more forgiving, Dovecot untouched.
  postfix-sasl:
    hits: 6
    window_minutes: 60
  # An exposed SSH port, stricter than the global pair.
  sshd:
    hits: 3
    window_minutes: 10

Relever un seuil rend l'agent plus silencieux et laisse passer les attaquants lents. L'abaisser est la direction qui coûte quelque chose : en dessous d'environ trois occurrences par heure sur une source de courrier ou web, vous finirez par signaler un client dont le mot de passe est faux dans son logiciel de messagerie, et un signalement est public au sein de la communauté.

Une donnée n'est pas configurable. Une adresse avec un historique de bannissement a besoin de moins d'occurrences qu'une adresse inconnue : un bannissement antérieur compte une ligne double, deux la comptent triple, puis cinq et neuf. Le poids est plafonné au seuil de sa source d'événement, un dixième bannissement ne transforme donc pas une seule ligne en signalement.

Limites de bannissement

Cinq valeurs dans le bloc ban, chacune dans l'unité que nomme sa clé. Elles ne s'appliquent qu'aux adresses que l'agent a trouvées dans vos propres journaux. La liste communautaire n'a aucune durée de bannissement, elle est remplacée en entier à chaque passe du flux. Avec les valeurs par défaut, une adresse qui revient est bannie 30 minutes, puis 2 heures, 8 heures, 32 heures et 128 heures, ensuite pour le plafond de 7 jours.

# Careful: a short first ban, a low cap, a long memory.
ban:
  enabled: true
  time_minutes: 10
  max_time_minutes: 1440     # one day
  escalate: 3
  memory_hours: 72

# Strict: a long first ban and a hard escalation.
ban:
  enabled: true
  time_minutes: 60
  max_time_minutes: 43200    # thirty days
  escalate: 6
  memory_hours: 168          # a week

Limites de fonctionnement

Ces valeurs bornent ce que l'agent consomme lui-même. Ce ne sont pas des réglages de détection, et les deux qui valent la peine d'être changées sont la taille de la file et le plancher de disque.

Sous le plancher de disque, l'agent n'écrit plus de nouveaux signalements dans la file, enregistre l'état et l'envoie par courrier, et continue de détecter et de bloquer. Un /var plein est pire qu'un signalement manqué.

Les limites qui ne viennent pas du fichier

Quatre nombres ne sont pas des réglages sur l'hôte. Ils viennent de votre compte et l'agent les demande, ce qui fait qu'une montée en gamme prend effet sans que personne édite un fichier.

Un courrier quand quelque chose ne va pas

Ce qui est envoyé par courrier est un état et non un événement : un flux qui échoue toutes les heures fait un message et non vingt-quatre. L'agent suit onze états, retient quand chacun a été envoyé par courrier pour la dernière fois afin qu'un redémarrage ne reprenne pas à zéro, et envoie une levée d'alerte quand un état est terminé.

Le courrier porte le nom d'hôte, la version, le nom de l'état, une phrase courte avec des chiffres et la commande pour regarder. Jamais une ligne de journal, jamais une adresse IP, jamais un chemin. Au plus un courrier par état dans notify.cooldown_hours. Arrêter l'agent envoie exactement un courrier qui nomme ce que cet hôte cesse de faire ; un redémarrage de la machine et un redémarrage du service n'en envoient aucun, et c'est ce qui garde la mise à jour automatique silencieuse.

install écrit le bloc notify : l'adresse est donc une option au moment de l'installation et non une retouche ensuite. Une configuration existante n'est jamais modifiée, pas même par une mise à jour.

# Arm the mail while the host is being set up
sudo REPORTEDIP_KEY=<YOUR-KEY> reportedip-agent install --notify-email ops@example.org

# The same through the install script, so one line arms a whole
# rollout
curl -fsSL https://reportedip.com/agent/install.sh \
  | REPORTEDIP_ACCEPT_TERMS=1 REPORTEDIP_KEY=<YOUR-KEY> REPORTEDIP_NOTIFY_EMAIL=ops@example.org sh

Trois chemins de livraison, dans l'ordre où l'agent les essaie. Sans notify.email, aucun ne s'exécute.

# The default: out through the relay of reportedip.com, so this
# host needs no mail server of its own.
notify:
  email: "ops@example.org"
  cooldown_hours: 24
  relay: true

# Local delivery only, through postfix, exim or msmtp.
notify:
  email: "ops@example.org"
  cooldown_hours: 24
  relay: false

# No local MTA and no relay: your own SMTP.
notify:
  email: "ops@example.org"
  cooldown_hours: 12
  relay: false
  smtp:
    host: mail.example.org
    port: 587
    from: agent@example.org
    user: agent@example.org
    password: "..."
    starttls: true

Lancez reportedip-agent doctor après avoir configuré cela. Sa section mail dit si un courrier peut réellement quitter l'hôte, ce qui est une autre question que celle de savoir si la configuration est lisible. Un destinataire absent est nommé à chaque exécution et n'est pas compté comme une faute.

Quand une modification prend effet

L'agent lit sa configuration au démarrage, ne surveille pas le fichier et n'a pas de signal de rechargement. La commande dont vous avez besoin dépend de la partie que vous avez touchée.

# The safe sequence after any edit
reportedip-agent status >/dev/null; [ $? -ne 2 ] && echo "config parses"
reportedip-agent sync
systemctl restart reportedip-agent.service
systemctl status reportedip-agent.service --no-pager

Dernière mise à jour: 30. septembre 2026 · Maintenu par l’équipe ReportedIP