Lolokai – Supervision, systèmes, réseaux, base de données…

14

Controlez votre bande passante avec Filtokai

Loic FONTAINE 17 décembre 2012

Introduction

Cela fait un moment que je n’ai pas bloggué : emploi du temps chargé, pas vraiment de temps (ou pas pris le temps). Bref, souffler ça fait du bien de temps à autre ;). Mais je reviens avec encore plus de vigueur et surtout un nouveau projet à vous présenter. Ce projet est actuellement encore au stade de test et de développement mais j’espère pouvoir le partager très bientôt.

Le projet

Il est 8h30 du matin un beau lundi, vous êtes administrateur système et réseau d’une société composé d’une centaine d’employés. Et comme tous les lundis matin vous consultez les mails que vous avez reçu ainsi que les tweets sympas la page Facebook de votre société pour voir les dernières nouvelles. Et là ….. vous mettez 20 secondes à ouvrir une page google et environ le triple pour ouvrir la page de login Facebook. Deux possibilités :

  • Vous êtes en 56k
  • Un de vos utilisateurs télécharge (encore et toujours….)

On va opter pour la seconde possibilité qui est la plus courante, deux solutions :

  • Eclater la personne qui télécharge : ça risque de vous couter cher et encore faut-il la trouver
  • Utiliser … Filtokai

Filtokai est un système qui permet d’attribuer un quota aux utilisateurs présents sur le réseau (il a par exemple 300 Mo pour une journée), une fois que ce quota est dépassé …. SALUT ==> Cet utilisateur n’a plus accès à internet. L’accès à internet se fait via une interface web.

Par conséquent, je profite de ce billet pour annoncer la création de ce projet Open Source (quand même), j’espère pouvoir le livrer début janvier 2013 et compter sur des contributeurs.

Conclusion

Filtokai semble être une solution viable pour éviter les téléchargements intempestifs qui pourrissent beaucoup de connexions. Actuellement cette solution tourne (malgré les quelques premiers bugs rencontrés) nickel sur un réseau utilisé par 80 personnes du lundi au vendredi. Au jour d’aujourd’hui, il me reste uniquement à la généraliser (c’est à dire l’adapter pour tous les réseaux et non un seul) et à l’améliorer quelques peu. De plus, la rédaction d’une documentation est en cours. Rendez-vous début 2013 pour une version téléchargeable :).

Que pensez-vous de ce projet ? Avez-vous des suggestions à faire ?

 Loic FONTAINE

Comments (14)

    • Les utilisateurs sont pour le moment dans une base de données MySQL.
      Comme pour la proposition ci-dessus j’envisage une authentification LDAP dans une version 1.1.
      Les étapes de la connexion :
      – L’utilisateur se connecte sur l’interface web
      – L’accès internet est débloqué et son quota augmente au fur et à mesure de ses échanges de données
      – Quand son quota est dépassé, il est banni
      Pour le moment, un serveur est dédié à cet usage et doit être placé entre le réseau local et la passerelle internet.

      Répondre
  1. OK, donc un portail captif, comme celui que propose squid ?
    ET je n’ai peut etre pas bien vu, mais le projet est déjà démarré? on peut tester une beta pour remonter les bugs éventuels ?

    Répondre
    • Je publierai la béta début 2013 (comme tu l’as dit ;)). Pour le moment, ma première version Béta fonctionne à merveille sur un réseau assez costaud et qui fait passer beaucoup de trafic par jour. Après, le projet manque peut être d’un peu de recul je ne dis pas :) Il faudra sans aucun doute optimiser le code :).

      Répondre
  2. Salut,

    Dans une entreprise, l’informaticien ne fait pas ce qu’il veut. Si tu bloques la connexion d’un utilisateur, tu vas vite recevoir un coup de fil du directeur t’ordonnant de remédier à cela immédiatement.

    Portail captif ou proxy avec filtrage des sites inappropriés pour le travail me semble plus adéquat.

    Répondre
    • C’est vrai, cette solution est peut être un peu extrême mais néanmoins efficace quand un administrateur a pleinement la main sur son réseau. Elle peut aussi être adaptée pour des organismes comme les universités et autres qui se plaignent souvent de soucis de bande passante.

      Mais comme je l’ai dit au dessus, une version avec bridage de connexion pour ceux qui ont dépassés le quota devrait voir également le jour j’espère courant 2013 ;).

      Merci pour ton avis.

      Répondre
      • Vous ne faites que décaler le problème.
        C’est ce que reflète la solution 1.
        Vous vous douter que les ralentissements sont liés à des utilisateurs qui téléchargents sauvagements, mais vous n’êtes pas en mesure de les trouver, même en ayant « pleinement la main sur votre réseau ».

        De plus, vous imposer un portail captif sur l’ensemble des utilisateurs à cause de ceci. (ouvrir son navigateur et être accueillis par un portail captif est acceptable quand on utilise un réseau en tant que visiteur – sinon c’est une nuisance)

        La première chose à faire est de trouver le/les coupables et d’instaurer des mécanismes permettant de détecter ce type d’usages. Par exemple un IDS comme snort, voir plus simplement, modifier votre script pour qu’il enregistre la consommation de bande passante de chaque utilisateur en fonction du temps. Ceux qui ont les « meilleures notes » sont susceptibles d’être fautif ce qui vous permet d’investiger ensuite …
        La solution snort peut nécessiter un investissement de temps plus important pour être mise en place, mais on a l’avantage d’avoir des alertes instantanément lors de l’utilisation de P2P / infections par un malware (il faut bien entendu prévoir du temps pour mettre à jour les définitions de detections)

        Pour minimiser l’impact du problème quand il advient, la mise en place d’une politique de QoS est très utile (cf paulez). Un squid (+squidGuard) permet de filtrer l’accès à certains sites et eventuellement maintenir un cache pour les sites visités régulièrement. (ce qui colle très bien avec un serveur dédié situé entre le LAN et la gateway. le serveur fait alors du bridging sachant que squid peut fonctionner en mode transparent => donc pas besoin de configurer chaque poste pour utiliser le proxy!)

        Répondre
        • Bonjour,

          Effectivement snort semble être une excellente solution pour détecter quels sont les utilisateurs qui téléchargent.
          Pouvez-vous me dire comment snort détecte les utilisateurs qui font passer un paquet ?

          Il me semble que squid fonctionne en transparent uniquement via le port 80 le covered-channel permet aisément de bypasser ce type de protection.

          Filtokai n’est pas une solution universelle pour contrer ce type de problème c’est uniquement une solution que je propose ;). De plus, elle permettra à terme (surement dans une seconde version) de gérer la priorité des paquets en fonction des utilisateurs qui téléchargent ou non.

          L’exemple est peut être mal choisi, mais adapté à une université qui accueillent X étudiants qui téléchargent en longueur de journée elle peut être une solution viable ;).

          Répondre
  3. Bonjour,

    je pense qu’une meilleure approche que les quotas est le partage équitable de la bande passante entre chaque connexion, et voire en plus de faire de la QOS selon le type de flux. Cela permet d’avoir une connexion fluide en permanence, sans être aussi contraignant que les quotas.

    C’est faisable assez aisément avec une passerelle Linux, comme expliqué dans le chapitre 9 du fameux LARTC (http://www.inetdoc.net/guides/lartc/lartc.qdisc.html).

    Pour ne pas me compliquer la vie je fais ça avec Shorewall, mais il doit exister des distributions dédiées qui intègrent ce type de solution déjà pré-configurée.

    Répondre

Laisser un commentaire

Login to your account

Can't remember your Password ?

Register for this site!