Les exemples ci-dessous ajoutent uniquement l'action de reporting. Ils supposent que la distribution fournit déjà les filtres Fail2ban adaptés et que les chemins de logs ont été vérifiés localement.
Ne copiez pas aveuglément les logpath ou regex d'une autre distribution. Les noms de filtres, le backend (systemd, fichiers classiques) et les formats de logs peuvent varier.
SSH / sshd
Cas recommandé : reporter le ban d'une jail sshd existante.
[sshd]
enabled = true
action = %(action_)s
blocklist-report[category=ssh_bruteforce,services="tcp:22"]
Si SSH écoute sur 2222 :
action = %(action_)s
blocklist-report[category=ssh_bruteforce,services="tcp:2222"]
Payload produit : réseau attaquant, catégorie ssh_bruteforce, service TCP/22 ou port réel, jail, nombre d'échecs et durée de ban en métadonnées.
Apache HTTP Server
Pour une jail d'authentification HTTP :
[apache-auth]
enabled = true
action = %(action_)s
blocklist-report[category=credential_stuffing,services="tcp:80,tcp:443"]
Pour une jail de scanners / requêtes malveillantes :
[apache-badbots]
enabled = true
action = %(action_)s
blocklist-report[category=web_scan,services="tcp:80,tcp:443"]
Adaptez les ports si l'application n'expose qu'HTTP ou qu'HTTPS.
Nginx
Même principe pour les jails Nginx déjà en place :
[nginx-http-auth]
enabled = true
action = %(action_)s
blocklist-report[category=credential_stuffing,services="tcp:80,tcp:443"]
Pour des bots/scanners :
[nginx-botsearch]
enabled = true
action = %(action_)s
blocklist-report[category=web_scan,services="tcp:80,tcp:443"]
SIP / Asterisk
Les logs SIP varient fortement selon Asterisk, PJSIP/chan_sip et la politique de journalisation. Réutilisez une jail Asterisk déjà testée localement.
Exemple :
[asterisk]
enabled = true
action = %(action_)s
blocklist-report[category=credential_stuffing,services="udp:5060,tcp:5060,tcp:5061"]
- UDP/5060 : SIP classique fréquent ;
- TCP/5060 : SIP TCP si activé ;
- TCP/5061 : souvent SIP TLS.
N'annoncez que les transports réellement exposés. Si votre plateforme utilise un autre port, remplacez la liste.
Pour un comportement plus générique (scan SIP sans authentification), vous pouvez utiliser abuse ou une catégorie personnalisée conforme à la syntaxe, par exemple sip_scan.
FreeSWITCH
Les détections peuvent venir des logs Sofia ou d'une jail spécifique au déploiement. L'action de report reste identique :
action = %(action_)s
blocklist-report[category=credential_stuffing,services="udp:5060,tcp:5060,tcp:5061"]
La documentation de l'application ne fournit pas de filtre FreeSWITCH ; ce guide ne prétend donc pas imposer une regex universelle.
Postfix / SMTP AUTH
Pour les échecs SASL :
[postfix-sasl]
enabled = true
action = %(action_)s
blocklist-report[category=credential_stuffing,services="tcp:25,tcp:465,tcp:587"]
Adaptez aux ports réellement actifs :
- 25 : SMTP ;
- 465 : submissions implicite TLS ;
- 587 : submission.
Pour une jail visant surtout le spam ou des comportements SMTP abusifs :
action = %(action_)s
blocklist-report[category=spam,services="tcp:25,tcp:465,tcp:587"]
Exim
Exim peut être intégré de la même manière dès lors qu'une jail fiable existe :
[exim]
enabled = true
action = %(action_)s
blocklist-report[category=credential_stuffing,services="tcp:25,tcp:465,tcp:587"]
Les noms de jails et filtres Exim varient selon distribution. Vérifiez avec :
fail2ban-client status
ls /etc/fail2ban/filter.d | grep -i exim
Dovecot — IMAP/POP3
[dovecot]
enabled = true
action = %(action_)s
blocklist-report[category=credential_stuffing,services="tcp:110,tcp:143,tcp:993,tcp:995"]
Retirez les ports non utilisés :
- 110 : POP3 ;
- 143 : IMAP ;
- 993 : IMAPS ;
- 995 : POP3S.
Plusieurs jails sur un même serveur
Chaque ban produit un rapport distinct. C'est cohérent avec le modèle actuel, qui conserve un historique et ne déduplique pas les POST.
Si une même IP déclenche SSH puis HTTP puis IMAP, trois reports séparés peuvent donc exister, avec des services et catégories différents.
Application ID : faut-il le renseigner ?
Le reporter fourni n'envoie pas application_id. Cela laisse le serveur rechercher le service par protocole/port.
Comportement documenté :
- une correspondance unique : réutilisée ;
- aucune : création d'un service sans application ;
- plusieurs correspondances : HTTP 422.
Si votre catalogue comporte plusieurs services pour un même couple protocole/port, il faudra faire évoluer le helper pour permettre un application_id explicite ou null. Ne remplacez pas l'ID par le texte ssh ou smtp : l'API attend un entier.
Test par jail
Vérifiez d'abord le filtre sans bannir :
fail2ban-regex /chemin/du/log /etc/fail2ban/filter.d/nom-du-filtre.conf
Puis testez la configuration :
fail2ban-client -t
Enfin, déclenchez un événement depuis un environnement de test et confirmez que le bannissement local et le report sont tous deux visibles.