⚠️ Disclaimer

La méthode que je présente ici correspond à ma propre démarche d’apprentissage. Elle peut contenir des approximations ou des erreurs, car j’apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d’expérience personnel.

Bienvenue dans cette série d’articles dédiée à la mise en place d’une infrastructure de surveillance de niveau entreprise. À travers ce carnet de bord, je partage mes succès, mes échecs et surtout mes décisions techniques dans la construction d’une infrastructure basée sur Prometheus et Grafana.

L’approche hybride : pourquoi le tout-SNMP est une fausse bonne idée

Quand on commence à dessiner l’architecture réseau d’une infrastructure, on a souvent ce rêve d’unification. On se dit : “Je vais utiliser le protocole SNMP partout, c’est le standard depuis 30 ans, ça va être propre et centralisé.”

Spoiler : Ça ne se passe jamais comme prévu.

Le mur du SNMP (ou “l’épisode pfSense”)

Au départ, ma vision était “Agent-less”. Je voulais interroger mon routeur pfSense uniquement via SNMP. Sur le papier, c’est génial : pas d’installation tierce, on active le service et on “scrape”.

En pratique, j’ai eu des erreurs HTTP 400 (Bad Request) à répétition. Le SNMP se comporte comme un observateur distant. Il demande des infos à travers une porte entrouverte (les OID), mais si la MIB (Management Information Base) du constructeur est incomplète, on récupère des données tronquées.

En pratique, j’ai constaté plusieurs limites. La visibilité des disques est impossible : on ne peut pas avoir la température précise. La granularité CPU est insuffisante : on récupère une moyenne globale au lieu d’une vue par cœur.

Le Pivot : Node Exporter comme “Initié” du Système

Pour mes machines critiques (NAS Synology, Hyperviseur Proxmox, Routeur pfSense), j’ai installé Node Exporter. C’est un agent qui vit à l’intérieur de l’OS. Il voit tout ce que le système voit.

Pour déployer Node Exporter sur Proxmox (Debian) :

sudo apt update && sudo apt install prometheus-node-exporter -y

La commande apt update rafraîchit les sources, et install -y automatise l’installation pour éviter les interruptions.

Configuration du YAML Hybride

Voici comment je fais cohabiter ces deux mondes dans mon prometheus.yml :

scrape_configs:
  # LE COEUR SYSTÈME (NODE EXPORTER)
  - job_name: 'serveur-coeur-system'
    scrape_interval: 15s 
    static_configs:
      - targets: ['10.0.0.10:9100', '10.0.0.1:9100'] 
    labels:
      security_level: 'critical'

  # LE RÉSEAU PUR (SNMP)
  - job_name: 'switch-mikrotik'
    static_configs:
      - targets: ['10.0.0.254']
    metrics_path: /snmp
    params:
      auth: [public_v2]
      module: [if_mib]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - target_label: __address__
        replacement: 10.0.0.5:9116

L’Œil de l’Ingénieur Cyber

Pourquoi Node Exporter est-il plus “Cyber-Safe” ? En limitant l’écoute du port 9100 à mon seul serveur de monitoring via des ACLs, je réduis ma surface d’attaque par rapport à un SNMP v2c où les mots de passe circulent en clair sur le réseau.

Dompter le protocole SNMP : le défi MikroTik

L’ajout d’un équipement comme le MikroTik CRS310-8G+2S+ a été mon deuxième grand défi. Ici, pas de Node Exporter possible : on est “prisonnier” du SNMP constructeur.

Étape 1 : Préparer RouterOS

Avant que Prometheus ne puisse lire quoi que ce soit, il faut sécuriser l’accès sur le switch :

# Activation du SNMP
/snmp set enabled=yes contact="Clement-Admin" location="Homelab-Rack"

# Configuration d'une communauté sécurisée
/snmp community add name=MaCommunauteSecrete addresses=10.0.0.5/32 read-access=yes

Avec addresses=10.0.0.5/32, je restreins l’accès : seul mon serveur Prometheus peut interroger le switch. L’option read-access=yes interdit toute modification du switch via SNMP, un point de sécurité critique.

Le Casse-tête de l’Auth-Split

Depuis la version 0.23 de l’exporter SNMP, l’authentification est séparée des modules. Si vous utilisez un vieux tuto, vous aurez l’erreur "Unknown module". Mon fichier snmp.yml a été réécrit pour être “Hybride” :

auths:
  public_v2:
    community: MaCommunauteSecrete
    version: 2

modules:
  if_mib:
    walk: [1.3.6.1.2.1.2, 1.3.6.1.2.1.31.1.1]
    metrics:
      - name: ifHCInOctets
        oid: 1.3.6.1.2.1.31.1.1.1.6
        type: counter

Validation et Radar de Sécurité

Pour vérifier que la donnée est intègre, j’utilise toujours un curl de diagnostic :

curl -g "[http://10.0.0.5:9116/snmp?target=10.0.0.55&module=if_mib&auth=public_v2](http://10.0.0.5:9116/snmp?target=10.0.0.55&module=if_mib&auth=public_v2)" | grep ifHCInOctets

Si les chiffres remontent, mon radar est actif. En monitorant mon switch, j’ai pu observer des pics de trafic inhabituels la nuit, ce qui me permet d’identifier immédiatement une potentielle exfiltration de données.

À suivre

Les prochains articles traiteront du hardening de la stack avec des secrets Docker et des fichiers .env, ainsi que du dashboarding avancé pour créer des alertes basées sur les métriques d’écriture disque.