Trafic réseau anormal : remonter du lien au processus

Le réseau ralentit et la première proposition consiste à augmenter le débit. Pourtant, une sauvegarde hors planning, une synchronisation cloud, une boucle interne ou des transmissions répétées peuvent expliquer la situation. Avant d’acheter de la capacité, cherchons où la pression commence, où elle va et quelle activité la produit.

Cet article conduit l’enquête de la vue globale du réseau jusqu’à un processus précis. Les étapes opérationnelles et critères de décision sont nos recommandations éditoriales ; les capacités et limites des outils sont rapprochées de leur documentation primaire. Aucun exemple ne prétend rapporter un essai réalisé sur le réseau du lecteur.

Définir ce qui est réellement anormal

Un trafic élevé n’est pas automatiquement anormal. Un pic de sauvegarde attendu diffère d’un envoi continu pendant une période calme. Notez début, durée, direction, périmètre touché et effet sur les utilisateurs. Comparez des jours et horaires similaires, plutôt que les seules minutes calmes précédant l’incident.

Distinguez débit et volume transféré. Mbps exprime un débit ; GB, un volume. En unités décimales, 1 MB/s équivaut à 8 Mbps. La capacité effective du service peut également être inférieure à la vitesse négociée du port. Sur un lien full-duplex, comparez chaque sens à sa propre capacité : additionner trafic entrant et sortant ne prouve pas la saturation d’un sens donné.

Choisir un outil pour chaque question

1. Surveiller les interfaces avec PRTG ou Zabbix

Commencez par le WAN, les liaisons intersites, les uplinks et les interfaces liées au service touché. Entrant et sortant s’entendent du point de vue de l’interface observée. Dans PRTG, le capteur SNMP Traffic constitue un point de départ ; dans Zabbix, utilisez un modèle adapté et vérifiez les unités de sortie de l’élément.

Un compteur brut cumulatif d’octets doit être transformé en débit à partir de sa variation dans le temps. Dans Zabbix, cela passe par Change per second et la conversion d’unité appropriée. Ne répétez pas la conversion sur un élément dont le modèle fournit déjà des bit/s. Pour un compteur brut, la relation est :

bit/s = (counter_now - counter_previous) * 8 / elapsed_seconds

Utilisez des compteurs 64-bit lorsqu’ils sont pris en charge. Un intervalle de collecte long peut masquer une courte rafale dans la moyenne ; un intervalle très court a aussi un coût. Nous recommandons de conserver chaque sens avec les erreurs, rejets et débits de paquets. Un seuil universel ne remplace pas la référence propre à chaque liaison.

PRTG / SNMP · Zabbix / SNMP · Zabbix / Preprocessing

2. Identifier appareils et destinations avec NetFlow

Un graphique d’interface situe la congestion, mais ne nomme généralement pas son consommateur. Si l’équipement le permet, exportez NetFlow ou IPFIX depuis un point d’observation pertinent vers un collecteur compatible. Pendant la fenêtre de l’incident, classez sources et destinations par octets, puis examinez le sens. Compter seulement sessions ou paquets ne mesure pas le volume transféré.

Documentez exportateur, interface observée, position avant ou après NAT, échantillonnage et horodatage du collecteur. En environnement échantillonné, les paramètres du collecteur doivent correspondre à ceux de l’exportateur, et les résultats se lisent comme des estimations. Voir un flux à plusieurs endroits ne signifie pas que les données ont été générées plusieurs fois : additionner toutes les observations peut produire un double comptage.

Notre conseil pratique : reliez les principaux consommateurs aux responsables des appareils, aux données DHCP/IPAM et au rôle du service. Une adresse publique NAT ou un proxy peut représenter plusieurs utilisateurs. Les flux ne fournissent généralement pas le contenu déchiffré des requêtes ; attribuer la consommation à une activité précise exige aussi des preuves applicatives ou côté hôte.

Cisco / NetFlow · IPFIX · PRTG / Sampling

3. Examiner le trafic FortiGate avec FortiView

Dans FortiView, choisissez d’abord la bonne période, le bon appareil ou VDOM et le chemin concerné. Explorez sources, destinations, applications et règles selon les fonctions disponibles dans votre version. Trier par octets répond à une question de volume ; trier par bande passante répond à une question de débit.

Avant d’interpréter un graphique vide, vérifiez la couverture de journalisation et la source des données. Les vues historiques dépendent des journaux réellement conservés et de leur stockage : leur absence ne prouve pas celle du trafic. Un flux qui n’a jamais traversé ce pare-feu reste hors de sa vue. Interprétez une identification applicative selon la visibilité disponible.

Un nom d’application ou un pays de destination ne suffit pas à justifier un blocage. Nous recommandons de suivre la source fortement consommatrice jusqu’à la règle, la destination et le responsable du service, puis d’évaluer l’effet d’une restriction sur le travail nécessaire. Les menus diffèrent selon FortiOS ; cette section n’ordonne pas de modifier un pare-feu en production.

FortiView / Monitors · FortiView / Logging · FortiOS / Log settings

4. Analyser le transfert avec Wireshark

Une fois appareil et chemin identifiés, si la cause reste incertaine, réalisez une capture courte et ciblée. Le point d’observation doit réellement voir le trafic. Sur Ethernet commuté, le mode promiscuité d’un poste ordinaire ne révèle pas tous les unicasts des autres hôtes. Utilisez un emplacement approprié, un SPAN ou un TAP autorisé. Ce filtre de capture emploie une adresse de documentation :

host 192.0.2.25

Remplacez l’adresse par un terminal autorisé. Dans Statistics, examinez Conversations par octets et sens ; comparez les débits sur la même fenêtre dans I/O Graphs. Des bits sur un intervalle de 1 seconde facilitent la lecture du débit. Les lignes suivantes sont des filtres d’affichage distincts, pas le filtre de capture précédent :

ip.addr == 192.0.2.25
tcp.analysis.retransmission

Les octets capturés ne correspondent pas automatiquement aux données utiles applicatives ni au compteur WAN. Pertes de capture, duplications SPAN et emplacement peuvent fausser l’analyse ; un indicateur de retransmission ne prouve pas à lui seul un défaut du chemin. Observer tailles et profils de flux n’exige généralement pas de déchiffrer TLS. Limitez périmètre, durée et accès aux captures.

Wireshark / Capture · Conversations · I/O Graphs · Display filters · TCP analysis · Switched Ethernet

5. Identifier le processus Windows avec Resource Monitor

Si la source est un hôte Windows, ouvrez Resource Monitor et sélectionnez Network. Triez les processus ayant une activité réseau par Total, Send ou Receive, puis sélectionnez le processus et examinez ses destinations. B/sec est un débit en octets : ne le comparez pas directement aux Mbps du lien.

Relevez nom, PID, heure d’observation et destination. Cet exemple PowerShell associe un PID fictif à ses connexions TCP actuelles ; remplacez 4321. Il ne mesure pas le débit de chaque processus et ne constitue pas un inventaire complet du trafic UDP :

$trafficProcessId = 4321
Get-Process -Id $trafficProcessId
Get-NetTCPConnection -OwningProcess $trafficProcessId |
    Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State

Resource Monitor décrit cet hôte, pas l’usage internet de toute l’organisation ; le trafic LAN local peut également apparaître. TCPView complète la recherche avec les points de terminaison et leurs processus propriétaires. Identifiez le service et son travail avant toute fermeture. Les noms System ou svchost ne prouvent pas un logiciel malveillant et ne justifient pas seuls un arrêt.

Microsoft / Resource Monitor · Microsoft / TCPView · Get-NetTCPConnection

6. Distinguer boucles et diffusions des téléchargements

Si le LAN souffre fortement alors que le WAN n’explique pas les symptômes, examinez la couche liaison. Rapprochez topologie et débits entrants de paquets, de broadcast et de multicast sur les ports concernés. Le trafic interne peut ne jamais atteindre le pare-feu internet.

Changements de topologie et déplacements MAC sont des indices, pas une preuve du point de départ d’une boucle. Nous recommandons de suivre les débits entrants inattendus et les derniers raccordements physiques. Ne débranchez pas aveuglément un uplink inconnu : ne limitez qu’un segment vérifié, avec retour arrière prévu.

Cisco / Layer-2 loops

7. Relier la consommation aux sauvegardes et mises à jour

Comparez le début du trafic aux sauvegardes, réplications, synchronisations cloud, distributions logicielles et Windows Update. Un transfert autorisé peut affecter le service principal si son horaire ou son allocation de bande passante est inadapté.

Pour Delivery Optimization, utilisez les rapports et diagnostics Windows ; le seul nom d’un service partagé ne désigne pas l’activité exacte. Nous proposons de confirmer la tâche avec son responsable, puis de tester un ajustement ciblé de son horaire ou de son débit, plutôt que de désactiver durablement sauvegardes et mises à jour de sécurité.

Microsoft / Delivery Optimization

8. Rapprocher journaux applicatifs et preuves réseau

Si un service web ou une API figure parmi les gros consommateurs, comparez heures, chemins, statuts et tailles des réponses dans les journaux d’accès ou applicatifs. Dans NGINX, des variables comme $body_bytes_sent concernent le corps de la réponse ; le nombre de requêtes ne suffit pas à expliquer le volume.

Nous recommandons de ne recueillir que les métadonnées nécessaires et de chercher téléchargements répétés, nouvelles tentatives persistantes ou réponses anormalement grandes. Sans tenir compte de la compression et du point de mesure, le volume applicatif n’est pas interchangeable avec celui du lien. Avant de parler d’attaque, rapprochez données de flux, éléments du responsable et requêtes réelles.

NGINX / Access logs · NGINX / Variables

Cas hypothétique : les appels souffrent, les téléchargements passent

Supposons une connexion de service à 100 Mbps, un trafic sortant proche de 90 Mbps et des appels dégradés, alors que les téléchargements restent acceptables. Examinez d’abord capacité et sens sortants : une vitesse de port négociée plus élevée ne supprime pas la limite du service.

Dans ce scénario pédagogique, les flux placent l’hôte fictif 192.0.2.25 parmi les principaux consommateurs. FortiView confirme le trafic correspondant sur la même période. Sur l’hôte, processus de sauvegarde et journal de tâche coïncident avec l’incident. Avec l’accord du responsable, on réduit temporairement le débit de ce transfert, puis on reteste appels et graphique sortant. Une amélioration est un indice utile ; répétabilité et activités simultanées doivent encore être examinées pour conclure solidement.

Une démarche pratique pendant un incident

1. Consignez heure, fuseau, périmètre touché et mesure de l’impact utilisateur.
2. Identifiez interface et sens chargés à partir des débits, de la référence et des erreurs.
3. Suivez la même période dans les flux et le pare-feu, puis identifiez le responsable de l’appareil.
4. Si nécessaire, recueillez des preuves sur l’hôte ou une capture ciblée, puis effectuez un changement réversible.
5. Validez l’opération réelle de l’utilisateur et le retour des graphiques, puis attribuez responsabilité et prévention.

Conclusion : le plus gros consommateur n’est pas forcément fautif

Notre recommandation est de bâtir une chaîne de preuves plutôt que de poursuivre le chiffre le plus élevé : interface, appareil, destination, processus et activité réelle. Elle distingue un travail légitime mal planifié d’un transfert inattendu, d’un défaut réseau ou d’un comportement suspect.

À lire également

Serveurs sains, utilisateurs en attente : pourquoi la latence moyenne ne suffit pas