Journaux de pare-feu, Prometheus et VictoriaMetrics
voir l'attaque

Un pare-feu qui ne parle pas ne sert à rien

Un pare-feu bloque, compte et journalise. La troisième fonction est celle qu'on oublie, et c'est celle qui permet de comprendre une attaque. Un équipement dont les journaux restent dans sa mémoire locale est un équipement muet : au premier redémarrage, l'histoire disparaît.

La chaîne que nous déployons tient en quatre maillons, et le maillon faible est toujours le même, le transport.

La chaîne, du pare-feu au tableau de bord

1. 1
   L'émissionLe pare-feu ou le serveur écrit en syslog. En clair sur UDP 514 par défaut : c'est le réglage qui marche tout de suite et qui perd des messages dès que le réseau tousse.
2. 2
   Le transport chiffréUn tunnel TLS entre la machine et le collecteur, sur le port 6514. Indispensable dès que les journaux traversent Internet, et le point de panne numéro un : un service qui redémarre en mode « arrière-plan » face à un binaire qui reste au premier plan ne se relance jamais.
3. 3
   Le stockageUn agrégateur qui indexe par étiquettes (hôte, service, type) puis un magasin de journaux. Deux familles d'outils : les indexeurs type Loki, et les bases de journaux orientées colonnes type VictoriaLogs.
4. 4
   Les métriquesEn parallèle des journaux, des compteurs : nombre de connexions refusées, volume par règle, disponibilité des liens. C'est ce qui permet d'alerter, alors qu'un journal ne sert qu'à enquêter.

Journaux et métriques ne répondent pas à la même question

C'est pourquoi un pipeline sérieux fait les deux, et relie l'un à l'autre : on transforme certains motifs de journaux en compteurs. « Tentatives SSH échouées » n'a pas besoin d'exister en 400 000 lignes ; un compteur par heure suffit à voir la montée, et le journal permet de retrouver l'adresse source quand on en a besoin.

VictoriaMetrics et Prometheus : deux moteurs, un même langage

Prometheus collecte et stocke ; VictoriaMetrics fait la même chose avec une empreinte mémoire nettement plus basse et un langage de requête compatible. Dans une architecture hybride, la répartition qui fonctionne est simple :

• Prometheus pour la collecte et l'alerte locale, sur un périmètre stable, ses règles d'alerte et ses tableaux de bord sont un standard de fait.
• VictoriaMetrics pour la conservation longue et les gros volumes, avec ingestion par un agent qui pousse en remote write.
• VictoriaLogs quand le volume de journaux dépasse ce qu'un indexeur supporte à budget constant, c'est une base orientée colonnes, pas un index de texte.

Le point qui compte n'est pas le choix du moteur, c'est la rétention : combien de temps on garde, et à quel pas. Une métrique à 15 secondes pendant deux ans coûte plus cher que la même à une minute.

Lire une attaque dans les journaux

Un pare-feu bien journalisé raconte une attaque en trois temps :

• Le balayage beaucoup de paquets refusés, peu de sources, toutes les destinations. Le compteur « refus par règle » monte, et le reste ne bouge pas.
• La tentative ciblée une seule destination, une seule règle, un volume qui augmente lentement. C'est le moment où l'alerte doit partir, pas après.
• L'usurpation des paquets avec une adresse source interne arrivant de l'extérieur. Sans filtrage anti-usurpation en amont, ils sont légitimes pour le pare-feu : le journal montre alors un trafic interne qui ne devrait pas exister.

Trois indicateurs suffisent à couvrir 90 % des cas : refus par règle et par heure, nombre d'adresses sources distinctes, et ratio refus/acceptations. Un quatrième, plus subtil, révèle les attaques lentes : la durée moyenne des sessions une connexion qui dure des heures sans rien transporter n'est pas du télétravail.

Et la panne la plus grave est celle du surveillant

Nous avons vécu le cas sur un parc réel : la moitié des cibles en échec, et la console de tableaux de bord, avec son gestionnaire d'alertes, injoignable. Les métriques continuaient d'arriver ; aucune alerte ne pouvait partir. Panne parfaitement silencieuse, découverte par hasard.

Trois contrôles à automatiser : le nombre de cibles en échec (avec un seuil), l'état du service d'alerte, et l'âge de la dernière métrique reçue par source. Si une source n'a rien envoyé depuis une heure, ce n'est pas « calme » : c'est muet.