Mise en forme du trafic avec iptables et tc

Résumé

Le mois dernier, j'ai reçu une alerte automatique signalant une consommation excessive de bande passante, d'habitude le signe d'un problème. Dans ce cas, il faut suivre une procédure d'incident standard : essayer d'isoler la source du trafic avant de la couper. Mais la cause de cet incident n'était pas celle que j'attendais... et demandait un autre type de parade qu'un simple blocage.

Texte intégral

Alerte de bande passante excessive

Quand tu gères des serveurs, tu remarques que le trafic internet suit généralement des schémas prévisibles. Comme la circulation sur les routes, il y a des moments réguliers où ça bouge beaucoup et d'autres où c'est calme.

Ce schéma prévisible permet de détecter automatiquement les anomalies. Comme un embouteillage sur l'autoroute à une heure inhabituelle peut être le résultat d'un accident, des variations inattendues du trafic internet peuvent indiquer un incident dans le cyberespace.

Isoler la source

La première chose à faire est de trouver la source du problème. Pour cela, analyse l'anomalie en :

• Déterminant si le trafic supplémentaire est entrant ou sortant (envoi ou réception ?)
• Déterminant les adresses IP source et cible associées (quel serveur est touché ? D'où vient le trafic, où va-t-il ?)
• Déterminant le type de trafic (e-mail, web ou autre chose ?)

Pour cela, examine les graphiques de trafic, qui distinguent généralement l'entrée et la sortie. Ensuite, essaie de trouver les adresses IP concernées. Cela peut passer par d'autres graphiques (par serveur) et des statistiques dans les switches, routeurs et serveurs. Regarde ensuite l'utilisation du CPU et les fichiers journaux pour déterminer quelle application est touchée, comme le courrier ou le web. Plus l'anomalie est grosse, plus elle est facile à trouver.

Tu seras peut-être tenté de tuer l'anomalie dès que tu l'as trouvée, en arrêtant immédiatement le trafic associé. Mais il vaut mieux la laisser vivre (un peu plus longtemps au moins) pour en apprendre un maximum.

Utilise un outil comme iftop pour voir en temps réel la consommation de bande passante par adresse IP connectée. C'est très utile pour comprendre ce qui se passe, surtout avec les fichiers journaux (qui relient l'adresse IP à des comptes individuels).

Une cause inhabituelle

Le serveur qui produisait cette consommation excessive était un serveur de messagerie. Ils sont souvent visés par des pirates qui veulent en faire des relais de spam. Cela peut se passer de diverses façons, le plus souvent quand les spammeurs récupèrent un identifiant valide. Il en résulte beaucoup de trafic sortant, car les spammeurs envoient énormément d'e-mails. Si une campagne de spam passe par ton serveur, tu le vois probablement dans les journaux, car les messages de spam rebondissent souvent et les files d'attente se remplissent vite. Ça devient vite le bazar, mais sur ce serveur, rien de tel : juste une consommation de bande passante très inhabituelle.

Le courrier (et le spam) s'envoie avec le protocole SMTP, mais le trafic sur le port SMTP de ce serveur était tout à fait normal. C'était très étrange : cela signifiait que le trafic excessif venait d'ailleurs. Mais d'où ? Après avoir analysé divers fichiers journaux du serveur de messagerie, j'ai établi que le protocole en cause était IMAP. D'une manière ou d'une autre, un client connecté au serveur par IMAP générait d'énormes quantités de trafic réseau. IMAP sert à lire le courrier, pas à l'envoyer, ce qui rend les anomalies liées à IMAP très rares.

En analysant le journal du serveur de messagerie, j'ai trouvé l'utilisateur précis à l'origine du trafic. J'ai contacté ce client pour lui demander s'il avait remarqué quelque chose de bizarre de son côté. Sans surprise, il avait remarqué que son ordinateur était un peu lent ces derniers temps.

Boucle de synchronisation de Microsoft Outlook

Après quelques essais par téléphone, nous avons établi que quelque chose poussait Microsoft Outlook à synchroniser les dossiers IMAP en boucle. Son ordinateur téléchargeait donc encore et encore tout le contenu de sa boîte e-mail ! Comme sa boîte dépassait 40 gigaoctets, cela générait un trafic considérable. Apparemment, c'est dû à un bug de Microsoft Outlook, et il n'existe malheureusement pas de solution simple.

Parade : la mise en forme du trafic

J'étais face à un choix difficile : bloquer ce client (normal, légitime, payant) ou laisser le trafic excessif continuer (avec de gros coûts pour le fournisseur réseau). Bloquer des utilisateurs légitimes qui font tourner leur entreprise par e-mail est une très mauvaise idée, mais laisser continuer le trafic excessif en est une aussi. Heureusement, j'ai trouvé une autre façon de réduire ce trafic tout en laissant le client accéder à son courrier (avec son appli Outlook fidèle, mais défectueuse).

Mise en forme du trafic (traffic shaping)

Comme technique de gestion de la bande passante, la mise en forme du trafic permet de retarder certains paquets de données (ou tous) pour les faire entrer dans un profil de trafic souhaité. Appliquée, elle façonne, au sens propre, les courbes du trafic, d'où son nom.

Cette technique n'est pas sans controverse, car elle est tout le contraire du principe, souvent célébré, de la « neutralité_du_net ». Avec elle, on peut volontairement bloquer ou ralentir (ou faire payer en plus) certains types de trafic. Par principe, je suis contre tout ce qui nuit à la neutralité du net, mais dans cette situation précise, je n'avais pas d'alternative réaliste. Je devais ralentir fortement le trafic e-mail de ce client, en réduisant sa bande passante tout en continuant à lui donner accès à son compte.

Mettre en place la mise en forme du trafic

Pour façonner le trafic, il faut deux choses :

• marquer le trafic : tu ne veux affecter qu'un trafic réseau particulier, ici l'accès IMAP d'un client donné. Le reste ne doit pas être touché. On le fait en marquant les paquets qui correspondent à certaines caractéristiques, comme l'IP du client ou des numéros de port
• appliquer la règle de mise en forme : avec des outils de contrôle du trafic comme « tc », tu appliques ensuite la règle au trafic marqué. Il y a plusieurs façons de le faire, mais l'une des plus courantes consiste à utiliser des « Hierarchy Token Buckets », ou HTB.

Hierarchy Token Buckets (HTB)

En principe, un token bucket ressemble au fait de limiter le nombre de passagers d'un train en ne distribuant qu'un nombre fixe de jetons. Quand des passagers (ou des paquets de données) montent dans le train (ou le réseau), ils prennent un jeton. Quand ils descendent (ou atteignent leur destination), le jeton est rendu. Avec ce principe, tu contrôles la quantité de trafic simultané dans un système.

Tu peux mettre ce principe en œuvre avec les outils réseau « tc » (pour traffic control) en combinaison avec « iptables ». Un script permet de définir les règles de marquage et d'application. On trouve plusieurs exemples en ligne, j'ai utilisé celui-ci de Julien Vehent.

Conclusion

Parfois, les anomalies réseau ne sont pas ce que tu attends : prends donc toujours le temps de les examiner ! Bloquer le trafic à l'aveugle est brutal, parfois il faut affiner ses méthodes pour résoudre les problèmes.

Appliquer des techniques de filtrage peu orthodoxes n'est pas ce que je préfère, mais parfois c'est le seul moyen d'y arriver. Savoir ce que tu fais et pourquoi tu le fais est très important !