Un pare-feu applicatif ajoute l'adresse d'un attaquant à une liste de blocage. Les connexions qu'il avait déjà ouvertes poursuivent leur travail jusqu'à ce qu'il décide lui-même de les fermer.
Cette nuance a des conséquences concrètes. Un scanner n'ouvre pas une connexion par requête : il en établit une et y fait transiter des centaines de requêtes, en s'appuyant sur le mécanisme keep-alive du protocole HTTP. Au moment où le blocage s'applique, le canal est déjà en place. Seules les nouvelles connexions sont refusées.
Horus est le bouclier applicatif que nous avons développé pour traiter ce cas. Nous l'exploitons sur notre propre infrastructure et chez les clients dont nous assurons l'exploitation.
Une décision en plusieurs étages
Horus n'applique pas une règle unique. Chaque étage correspond à un niveau de certitude différent, et détermine la conduite à tenir si un visiteur conteste un blocage.
Étage 0 — coupure des flux établis. Lorsqu'une adresse est bloquée, ses connexions en cours sont interrompues immédiatement, avant la table de suivi de connexions. C'est précisément le point que nous cherchions à traiter, en complément du filtrage réseau classique.
Étage 1 — décision réflexe. Volumétrie d'erreurs, saturation de la limite de débit, signature d'outil d'attaque connu. Cet étage décide seul, en continu, et pose des blocages à durée limitée. Il traite le balayage automatisé permanent auquel est soumise toute infrastructure exposée.
Étage 1bis — modèle de détection. Il identifie des comportements présentant une similarité avec ceux observés lors d'attaques, sans correspondance avec une règle écrite. Ses décisions sont temporaires et expirent d'elles-mêmes : un modèle établit une ressemblance, pas une certitude.
Étages 2 et 2bis — corroboration externe. Réputation d'adresse confirmée par des sources tierces, et nœuds de sortie du réseau Tor.
Étage 3 — décision humaine. Permanente, versionnée, tracée, prise par un analyste d'Altrion et notifiée au client.
Mesures relevées en exploitation
Les chiffres ci-dessous proviennent de notre propre infrastructure, sur une journée de septembre 2026 sans incident particulier.
| Indicateur | Relevé sur 24 h |
|---|---|
| Adresses bloquées | 4 |
| Connexions établies interrompues | 22 |
| Décisions ayant déclenché l'étage 0 | 4 sur 4 |
| Alertes transmises au client | 1 |
Un blocage isolé a interrompu seize connexions déjà ouvertes au moment de la décision. Avec un filtrage classique, ces seize sessions auraient poursuivi leur activité.
Limites de ces mesures. Elles portent sur une seule infrastructure et une seule journée d'observation. Elles illustrent le mécanisme ; elles ne constituent pas une statistique représentative du trafic hostile reçu par une infrastructure quelconque. Le volume et la nature des tentatives varient fortement selon l'exposition, les technologies employées et le secteur d'activité.
Le ratio entre décisions et alertes n'est pas accidentel. Le balayage automatisé constitue un bruit de fond permanent : une alerte par blocage produirait un canal que le destinataire cesserait de lire en quelques jours. Seuls sont notifiés les blocages ayant interrompu des sessions établies et les décisions humaines.
Périmètre et garanties d'architecture
Horus opère à la couche applicative, sur le trafic web. Il complète le filtrage réseau et la protection des postes ; il ne s'y substitue pas.
La protection s'exécute chez vous. L'agent est déployé sur votre infrastructure et décide localement. Le portail Altrion observe et restitue : il ne comporte aucune commande de blocage. Cette absence est délibérée et constitue une garantie — la compromission éventuelle du portail ne donnerait aucun moyen d'agir sur les infrastructures de nos clients.
Chaque décision est restituable. L'espace client indique, pour toute adresse bloquée, l'étage déclencheur, le motif en français, les éléments observés et la durée du blocage. Vous disposez ainsi des éléments nécessaires pour répondre à un visiteur légitime qui contesterait un blocage, et pour nous adresser une demande de levée que nous instruisons.
Le paramétrage reste confidentiel. Les seuils de déclenchement et les règles appliquées sont propres à chaque client et ne sont pas publiés : un paramétrage connu se contourne.
Mise en service
Le déploiement débute systématiquement en mode détection. Horus journalise l'intégralité des décisions qu'il appliquerait, sans en appliquer aucune.
Cette phase, généralement de deux semaines, poursuit deux objectifs. Elle établit le volume et la nature réels du trafic hostile reçu par votre infrastructure — une donnée dont peu d'organisations disposent. Elle vérifie surtout qu'aucun flux légitime ne serait interrompu : certaines applications métier, en particulier d'anciens connecteurs, produisent des signatures proches de celles d'un outil d'analyse.
Le passage en mode blocage intervient sur votre validation explicite. Le retour en mode détection s'effectue par une commande unique, sans interruption de service.
Disponibilité
Horus est intégré à nos prestations d'infogérance et de supervision. Nous ne le commercialisons pas de façon autonome : un dispositif de détection sans exploitation associée ne produit pas de valeur.
Nous intervenons auprès des PME, collectivités et associations du Loir-et-Cher et du Centre-Val de Loire, et à distance sur l'ensemble du territoire. Une phase d'observation de deux semaines suffit à établir un état des lieux du trafic hostile reçu par votre infrastructure.