RE: [FRnOG] Firewall HTTP
NETASQ est aussi une solution capable d'agréger plusieurs liens (routé ou en point à point), de faire de la QoS et surtout de l'analyse protocolaire pour des prix très abordables. De mémoire le prix du matériel Netasq est assez élevé ou alors les équipements les moins sont très bridés en fonctionnalités. Pour information, on trouve des Fortinet entrées de gamme à 250/300 euros et qui sont déjà bien placés en termes de puissance et fonctions. Petit point supplémentaire, concernant toujours le coût, ils fonctionnent sur une alimentation 12V ce qui fait faire quelques économies de courant sur le long terme par rapport à un serveur double alimentation sur lequel on installe un Linux/BSD. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Il y a dix ans, on disait qu'il était moins cher d'acheter des tuyaux plus gros, que de s’embêter à faire de la QoS. Je ne sais pas si cette maxime est toujours vrai aujourd'hui. Et la QoS inter-opérateurs, on sait faire? - Mail Original - De: Rémy Sanchez remy.sanc...@hyperthese.net À: frnog@FRnOG.org Envoyé: Jeudi 25 Novembre 2010 20h01:47 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [FRnOG] Firewall HTTP On 11/25/2010 03:29 PM, Pierre Chapuis wrote: On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez remy.sanc...@hyperthese.net wrote: Bon et finalement, est-ce que la QoS sert à quelquechose ? Par ce que si on résume, la QoS ne sert à rien quand on a assez de bande passante, et elle n'est pas assez efficace quand y'a pas assez de bande passante... Bien résumé. Encore plus court : la QoS sur un réseau IP ne sert à rien et est même néfaste. Je sais que tu ne veux pas en parler mais j'ai été exactement dans le même cas que toi avec ta résidence étudiante. Si tu ne peux pas limiter la taille du tuyau, la solution est de compter les paquets et/ou les octets qui passent dedans pour chaque utilisateur et de faire en sorte que la somme totale ne dépasse pas ton débit maximal. Pas besoin de regarder dans les paquets. Ça n'est pas de la QoS, c'est du best effort. Si tu commences à faire de la QoS, tu vas avoir deux profils d'utilisateurs : les geeks qui vont comprendre ce qui passe et tunneler dedans, et les gens normaux qui vont se faire avoir. En pratique, une simple limite en upload et en download par jour, semaine et/ou mois suffit dans ce genre de contexte. Après, tu es plus ou moins obligé de regarder dans les paquets IP quand même si tu es relié à un réseau du type Renater, mais c'est un autre problème... Donc le DiffServ co c'est une vaste fumisterie ? On s'est amusé à utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne fait de QoS ? Je voudrais pas faire le mec relou qui met du temps à comprendre (même si à priori cette discussion gonfle tout le monde :/), mais j'ai du mal à me mettre en tête que tout ça ait été inventé pour rien... C'est quand même pas des clowns à l'IETF non ? -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Le 1 décembre 2010 13:36, guillaume.monne...@free.fr a écrit : Il y a dix ans, on disait qu'il était moins cher d'acheter des tuyaux plus gros, que de s’embêter à faire de la QoS. Je ne sais pas si cette maxime est toujours vrai aujourd'hui. Et la QoS inter-opérateurs, on sait faire? Si c'est ton réseau que tu utilises via plusieurs opérateurs (VPN) tu as le CSC (Carrier Supporting Carrier) qui existe mais je ne sais pas s'il est utilisé le problèmes politiques que ca implique ne sont sans doute pas neutre :) - Mail Original - De: Rémy Sanchez remy.sanc...@hyperthese.net À: frnog@FRnOG.org Envoyé: Jeudi 25 Novembre 2010 20h01:47 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [FRnOG] Firewall HTTP On 11/25/2010 03:29 PM, Pierre Chapuis wrote: On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez remy.sanc...@hyperthese.net wrote: Bon et finalement, est-ce que la QoS sert à quelquechose ? Par ce que si on résume, la QoS ne sert à rien quand on a assez de bande passante, et elle n'est pas assez efficace quand y'a pas assez de bande passante... Bien résumé. Encore plus court : la QoS sur un réseau IP ne sert à rien et est même néfaste. Je sais que tu ne veux pas en parler mais j'ai été exactement dans le même cas que toi avec ta résidence étudiante. Si tu ne peux pas limiter la taille du tuyau, la solution est de compter les paquets et/ou les octets qui passent dedans pour chaque utilisateur et de faire en sorte que la somme totale ne dépasse pas ton débit maximal. Pas besoin de regarder dans les paquets. Ça n'est pas de la QoS, c'est du best effort. Si tu commences à faire de la QoS, tu vas avoir deux profils d'utilisateurs : les geeks qui vont comprendre ce qui passe et tunneler dedans, et les gens normaux qui vont se faire avoir. En pratique, une simple limite en upload et en download par jour, semaine et/ou mois suffit dans ce genre de contexte. Après, tu es plus ou moins obligé de regarder dans les paquets IP quand même si tu es relié à un réseau du type Renater, mais c'est un autre problème... Donc le DiffServ co c'est une vaste fumisterie ? On s'est amusé à utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne fait de QoS ? Je voudrais pas faire le mec relou qui met du temps à comprendre (même si à priori cette discussion gonfle tout le monde :/), mais j'ai du mal à me mettre en tête que tout ça ait été inventé pour rien... C'est quand même pas des clowns à l'IETF non ? -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/ -- David Ramahefason r...@netfacile.net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Hello, j'ai lu avec passion l'ensemble des interventions de ce thread. Tout d'abord pour répondre a ta question, tu peux le developper le firewall HTTP mais en fait iptables avec la partie l7 et une base de signature protocolaire doit pouvoir faire ça. Y a plus qu'a creer un projet sur sourceforge et commencer a faire une IHM. Sinon, il existe des produits commerciaux faisant cela tres bien, par exemple les Fortigate font de l'analyse protocolaire et te permettent de faire de la prioritisation de flux, du shapping global et/ou per-ip sur un sous-ensemble du HTTP. ca reconnait pas mal de produit merdeux qui s'encapsulent dans le HTTP et tu peux meme creer toi-meme des signatures supplementaires. Ensuite pour répondre a ton probleme de BP : Acheter des tuyaux au sens ISP du terme c'est souvent non realisable (4 mois de GC) et toujours hors de portée du budget surtout si tu n'as pas le budget d'un petit pays... Si tu fonctionne deja avec des liaisons grand pubic type machinbox a 30E, tu peux raccorder plusieurs de celle-ci a un Fortigate et faire ensuite de la repartition automatique ou pas de tes users sur les differents liens. Faire de la repartition par protocole aussi. Ok mon discours fait la part belle a cette marque mais je n'en connais pas beaucoup qui rivalise a ce niveau de prix, fonctionnalités, facilité d'emploi. Pour ceux qui liront, oui c'est absolument pas compliant avec la neutralité du net mais dans le monde actuel (les bisounours tournent sur une broche dans la cheminée des chefs d'états) le pragmatisme l'emporte souvent sur l'idealisme. My 2 cents sous la neige... Cordialement Le 24 novembre 2010 14:51, Rémy Sanchez remy.sanc...@hyperthese.net a écrit : Bonjour à tous, Les dernières tendances en terme de n'importe quoi consistent à faire passer à peu près tout ce qu'on peut par du HTTP, à tel point qu'on a pratiquement remplacé le TCP. Après tout, toutes les applications web passent par du HTTP, or c'est plutôt vaste : distribution de contenu, messagerie instantanée, flux vidéo, traitement de texte, ... Sans oublier toutes les applications qui utilisent le HTTP (par exemple MSN) pour faire passer leur protocole en environnement restreint, ou carrément les tunnels. En bref, le port 80 est toujours ouvert, soit directement, soit à travers un proxy. Et c'est la porte ouverte à toutes les fenêtres... En fin de compte, serait-il cohérent d'imaginer une application analogue à un firewall, qui au lieu de s'en prendre au TCP s'attaque directement au HTTP ? Ça y est je vois déjà tous les canons pointés en ma direction pour me signaler qu'on a déjà des proxys, IDS et tout un tas de trucs dans le genre. C'est d'ailleurs pour ça que je demande si l'idée est cohérente ou si c'est du grand n'importe quoi. Cependant, je pense à des fonctionnalités qui m'ont l'air difficile à configurer dans les outils pré-cités, comme par exemple différencier les types de flux pour y assigner des priorités (long poll et dérivées, page standard, gros fichier, accélérateur de téléchargements, ...), reconnaître les sous protocoles (comme au dessus, MSN), reconnaître les tunnels, s'en prendre aussi au HTTPS, ... En bref, pouvoir traiter tout ce qui passe par du HTTP comme un flux TCP/IP avec un numéro de protocole et un tag pour la QoS. Les outils que j'ai rencontré jusque là ne permettent pas de faire ça simplement (Squid, pf, iptables pour ceux que j'ai vraiment utilisé), après étant relativement novice en réseau j'ai assez peu touché aux autres outils et aux appliances proprio, donc mon panorama est restreint. Donc qu'en pensez vous, lecteurs avisés de FRnOG ? Un tel outil serait-il utile ? Pour qui ? Qu'y verriez vous à l'intérieur ? Est-ce que j'ai complètement fumé la moquette ? NDLR : l'idée ici est de débattre des fonctionnalités d'un tel produit, non de la manière dont on pourrait les implémenter... Allez c'est parti pour une après midi à prendre des baffes :) -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Thu, Nov 25, 2010 at 08:01:47PM +0100, Rémy Sanchez wrote: Donc le DiffServ co c'est une vaste fumisterie ? On s'est amusé à utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne fait de QoS ? Moi je l'ai utilisé lorsque j'avais encore un ADSL avec un upload à 16 Ko/s. Un envoi de fichier faisait ramer ma session SSH. Du coup j'ai utilisé mon packet filter pour mettre de priorité sur certains flux : OpenSSH met un ToS différent selon que ce soit de l'interactif ou du transfert de fichier par exemple. Le DNS passait en priorité aussi. Mais c'était pour le réseau chez moi, donc les règles étaient facile à déterminer et à appliquer :-). Quand je suis passé chez Free avec un upload à 128 Ko/s (à l'époque, maintenant c'est limité à 100), je n'ai plus eu le problème. Cette modeste expérience prouve pour moi que les personnes qui disent qu'il te manque de la bande passante ont raison. Mais d'un autre côté, s'il te manque des moyens pour l'augmenter, ta question initiale pour catégoriser le traffic HTTP est parfaitement légitime pour pouvoir faire de la QoS efficacement, puisque les ports n'ont plus de sens. Pour le download, avec FreeBSD, tu peux faire du ALTQ. Ca permet de faire du Random Early Drop, permettant à TCP d'ajuster sa bande passante avant « qu'il ne soit trop tard ». En plus de cela, tu peux configurer un partage de bande passante équitable entre tes utilisateurs avec la notion d'emprunt : lorsqu'un utilisateur n'utilise pas toute la bande passante qui lui est réservée. Plutôt efficace. -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Rémy Sanchez remy.sanc...@hyperthese.net a écrit : Donc le DiffServ co c'est une vaste fumisterie ? On s'est amusé à utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne fait de QoS ? Je n'ai jamais trop compris l'intérêt de DiffServ, il a les mêmes inconvénients que ToS a priori. Je vois 3 possibilités : - c'est l'expéditeur qui choisit la valeur (ie. je veux que mon paquet aille lentement...) ; - c'est un routeur qui le fait en connaissant le contenu du paquet (DPI) mais dans ce cas il y a souvent des mécanismes non-IP plus efficaces) ; - c'est un routeur qui le fait uniquement en fonction de la source (mais comme au-dessus). Si on ne suppose pas que l'utilisateur est un bisounours, où est vraiment l'intérêt ? (Disclaimer : je n'ai pas lu la RFC et je n'y ai jamais touché en vrai...) -- Pierre 'catwell' Chapuis --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Rémy Sanchez a écrit : Bon, avant toute chose j'aimerais préciser que dans mon mail de base je ne parlais absolument pas d'optimiser mon cas particulier, mais bien de lancer le débat sur l'intérêt de considérer le HTTP comme un protocole de transport dans les firewalls, par ce que le web change toussa, Sur ce point ça me rappelle étrangement que la NSA enguirlandait les français de peur de voir des lois débiles contournées systématiquement par des tunnels chiffrés. Effectivement plus on pousse les gens à contourner des mesures restrictives débiles, plus ils le font et plus on se met soi-même en situation de devoir 1°) gérer une sécurité inutile, 2°) passer pour un con qui applique des mesures débiles et 3°) voir le problème ressurgir, mais encore plus complexe qu'avant. Donc dans la perspective où la restriction vient du fournisseur de l'accès, l'intérêt du DPI sur HTTP serait nul si on ouvrait tout simplement les ports normaux pour que les gens utilisent internet normalement. C'est vrai dans les entreprises qui voient leurs salariés comme des ennemis (et qui, le temps de la journée de travail, sont leur FAI), et c'est vrai en téléphonie mobile chez les opérateurs qui vendent à leurs clients du pas-internet (naté, filtré, et firewallé). Il y a aussi, en seconde lecture, dans ta question initiale, le pb que ce sont les éditeurs de services qui font passer n'importe quoi. Ben là, on a un problème technique mais la réponse peut effectivement passer par la priorisation correcte des services. On s'en fout si des abrutis font passer de la voix dans HTTP, du moment que la vraie voix est mieux priorisée sur les bons canaux, la voix sur HTTP sera juste toute pourrie, et ce sera tant pis pour elle. Donc pourquoi tout simplement laisser les gens utiliser les bons outils ou les mauvais, et en déduire ce qui marche et ce qui ne marche pas ? Pourquoi aller déglinguer les réseaux dans le sens des usages, s'il sont techniquement mauvais ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Michel Py wrote: un jour ou l'autre quelqu'un avec un téléphone 2G 1/2 ou 3G va ouvrir une des pages en question a coté d'un de ses potes qui a un téléphone 4G, ça va ramer, et ce n'est pas le QOS qui va faire le réseau 3G afficher la page remplie de merdasse sous HTTP à la vitesse du 4G. Si je vous dis que la QoS, c'est exactement la même chose que Wall-Street, pas une imitation, un vrai Wall-Street en vrai, et ce qui se vend et s'echange en temps reel, se sont ces places dans les files d'attente d'acces aux interfaces du réseaux, est-ce que vous ne changez pas d'avis ? Vous ne pensez pas qu'avec une QoS, genre Wall-Street, vous ne trouverez pas client pour acheter vos premieres places dans vos files d'attente au bon prix ? Et que pour ceux qui auront acheté ces places, est-ce que cette merdasse http ne peut pas arriver plus vite sur un 3G, qu'un vulgaire abonné en queue file d'attente avec son télephone 4G ? Je reconnais que gerer un Wall Street QoS sur un réseau entier, avec des millions d'utilisateurs, sur des milliers de destinations, ce n'est pas le même type d'applications à gérer que BGP ou un IGP. Il y a des SAN, des machines dans tous les sens, qui observent le trafic, et agissent le cas échéant pour etre sûre que chaque client, est _servi_ selon son rang de client. Et qu'il n'abuse pas. Les opérateurs mobiles gerent déja une application vraiment temps reel qui maintient le niveau 2 entre le mobile et le reseau et qui marche bien. Ce serait dommage pour eux d'en sacrifier le résultat à une politique archaïque digne d'une épicerie soviétique, puisqu'en faisant un éffort (certain), ils peuvent s'offrir un Wall-Street. Le corollaire, c'est que la Quality of Service des uns, est bien la Quality of Famine des autres, mais, on ne devrait pas en faire un drame, puisse que dans le monde réel, il a vraiment des gens sur Terre qui ne mange pas à leur faim, alors de la famine réseau, cela devrait être tout à fait acceptable. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Le 27/11/10, Stéphane Le Menle...@neptune.fr a écrit : Michel Py wrote: un jour ou l'autre quelqu'un avec un téléphone 2G 1/2 ou 3G va ouvrir une des pages en question a coté d'un de ses potes qui a un téléphone 4G, ça va ramer, et ce n'est pas le QOS qui va faire le réseau 3G afficher la page remplie de merdasse sous HTTP à la vitesse du 4G. Si je vous dis que la QoS, c'est exactement la même chose que Wall-Street, pas une imitation, un vrai Wall-Street en vrai, et ce qui se vend et s'echange en temps reel, se sont ces places dans les files d'attente d'acces aux interfaces du réseaux, est-ce que vous ne changez pas d'avis ? Vous ne pensez pas qu'avec une QoS, genre Wall-Street, vous ne trouverez pas client pour acheter vos premieres places dans vos files d'attente au bon prix ? L'idée est très bonne. L'opérateur peut parfaitement prendre en compte la qualité de service demandée par l'utilisateur, même si on n'est pas dans le monde des bisounours, à condition de facturer cette QoS. Vous avez 1 Go/mois prioritaire, le reste illimité n'est pas prioritaire. Vous pouvez acheter des Go prioritaires en supplément. À l'utilisateur de décider s'il veut que ce soit sa VoIP ou son torrent qui soit prioritaire, c'est lui qui marque les paquets. Rémi. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] Firewall HTTP
Stéphane Le Men a écrit: Vous ne pensez pas qu'avec une QoS, genre Wall-Street, vous ne trouverez pas client pour acheter vos premieres places dans vos files d'attente au bon prix ? Tu n'es pas le premier à y penser; c'est une bonne idée, mais le client n'est généralement pas assez sophistiqué pour comprendre QOS. C'est beaucoup plus facile de vendre un service en disant moi j'ai 5 mégabits et mon concurrent il en a que 2 que de vendre du QOS. N'oublies pas que tu t'adresses à des bœufs qui n'y comprennent rien, bas au bidouilleur dans l'âme qui lit la liste du FRnOG. Et puis c'est plus facile à expliquer aux copains, aussi. Moi, j'ai ai une plus grosse que toi :-D Bande passante, bien sûr. Et que pour ceux qui auront acheté ces places, est-ce que cette merdasse http ne peut pas arriver plus vite sur un 3G, qu'un vulgaire abonné en queue file d'attente avec son télephone 4G ? Non. Tu peux faire tout ce que tu veux avec QOS, une page avec des photos partout et de la vidéo qui joue sans le son pour les pub, ça marchera toujours plus vite avec un plus gros tuyau. Je reconnais que gerer un Wall Street QoS sur un réseau entier, avec des millions d'utilisateurs, sur des milliers de destinations, ce n'est pas le même type d'applications à gérer que BGP ou un IGP. Il y a des SAN, des machines dans tous les sens, qui observent le trafic, et agissent le cas échéant pour etre sûre que chaque client, est _servi_ selon son rang de client. Et qu'il n'abuse pas. C'est bien là ou est le problème: c'est une usine à gaz, et c'est un investissement. Vu la durée de vie relativement faible des réseaux mobiles (dès que 4G commence à décoller tu peux être sûr que tout le monde travaillera déjà sur 5G), l'opérateur se trouve plus ou moins dans la position de faire un choix entre investir dans une infra qui est déjà sur le départ et investir dans une nouvelle infra qui a des tuyaux plus gros. C'est la course à l'armement, ça fait marcher le commerce donc ça va continuer. C'est un peu la même chose pour FTTH: AMHA, si tu de déploies pas GigE aujourd'hui, dans 5 ans tu vas de faire bouffer tout cru par ceux qui le font. Et pareil pour WiFi: pourquoi se décarcasser à optimiser un 802.11b à 11mbps? Si tu as 100 utilisateurs sur 11mpbs ça commence à coincer, vaut mieux remplacer par du 802.11g à 54mbps. Ou même du 802.11N, quite à remplacer le matos autant mettre une nouvelle antenne pendant que tu es sur site. Le corollaire, c'est que la Quality of Service des uns, est bien la Quality of Famine des autres, mais, on ne devrait pas en faire un drame, puisse que dans le monde réel, il a vraiment des gens sur Terre qui ne mange pas à leur faim, alors de la famine réseau, cela devrait être tout à fait acceptable. Cette partie n'a jamais été un problème. C'est entièrement une histoire de gros sous; tout le monde n'est pas convaincu que QOS ça peut rapporter plus que ça ne coûte, à long terme, et l'investissement dans le gros tuyau a moins d'incertitudes. Le QOS c'est super quand ton temps n'est pas facturable et que tu récupères gratos le Cisco ou le Juniper du bureau (ou que tu l'achètes sur eBay pour pas cher). Rémi Bouhl a écrit: À l'utilisateur de décider s'il veut que ce soit sa VoIP ou son torrent qui soit prioritaire, c'est lui qui marque les paquets. La je trouve que tu rêves un peu, peut-être que certains de tes étudiants vont faire ça, mais pas Mme Michu. Sylvain Vallerot a écrit: [snip] Très bien écrit, le reste de ta contrib. Donc pourquoi tout simplement laisser les gens utiliser les bons outils ou les mauvais, et en déduire ce qui marche et ce qui ne marche pas ? Parce que a) la plupart n'y comprennent rien et b) même si ils comprenaient, il y a bien des fois ou tu ne peux rien faire. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Le 27/11/10, Michel Pymic...@arneill-py.sacramento.ca.us a écrit : Rémi Bouhl a écrit: À l'utilisateur de décider s'il veut que ce soit sa VoIP ou son torrent qui soit prioritaire, c'est lui qui marque les paquets. La je trouve que tu rêves un peu, peut-être que certains de tes étudiants vont faire ça, mais pas Mme Michu. Sa machinbox va le faire toute seule, et il pourra régler. Comme tout le bordel que fait une machinbox (NAT, VoIP, TVoIP, redirection de port..) qu'un geek sait faire tout seul, mais que la machinbox fait avec des réglages par défaut qui vont à tout le monde et une interface Web pour le bidouilleur du dimanche. On marque la priorité sur les quelques protocoles qui nécessitent vraiment de la vitesse (jeux vidéos, vidéoconférence) et basta. Et tu vends le tout sous le nom d'offre spécial joueur, un peu comme le mode patate chez Free, l'instabilité en moins. Avec une option à cliquer je gère la QoS moi-même pour les barbus. Non? Rémi. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On 11/25/10 20:01, Rémy Sanchez wrote: Donc le DiffServ co c'est une vaste fumisterie ? On s'est amusé à utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne fait de QoS ? Cela m'étonnerait fortement. L'utilisation du champs TOS des en-têtes IP pour effectuer un marquage DSCP des paquets issus de plate-formes de téléphonie/voix sur IP et de diffusion vidéo est un must dans tous les réseaux IP d'opérateurs. Les routeurs et commutateurs utilisent cette information pour assigner les paquets dans des files d'attentes prioritaire par rapport au traffic best effort (Youtube/Youporn/Faceplook.) -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On 11/26/2010 12:56 PM, e-t172 wrote: Mon opinion, qui n'engage que moi, est que tu te trompes de problème. Ton problème n'est pas que tes utilisateurs ne peuvent pas faire de la VoIP pendant qu'ils ont Rapidshare qui tourne à plein régime. Ton problème c'est que tes utilisateurs puissent se marcher sur les pieds, c'est-à-dire que quelqu'un qui fait du DDL puisse faire chier son voisin qui lui n'a rien demandé et ne demande qu'à faire son entretien d'embauche via VoIP. Autrement dit, tu veux nous parler de différenciation par service, moi je veux te parler de différenciation par utilisateur. Pour moi, la meilleure solution à ton problème consiste à rétablir la « justice » (Fair Queuing) entre les utilisateurs. C'est-à-dire quelqu'un qui ouvre 1000 téléchargements ne puisse pas mettre tous les autres à genoux sous la congestion. Ça devrait même être une règle élémentaire de sécurité : un individu qui empêche tous les autres d'utiliser le réseau, on appelle ça un Denial of Service, non ? La solution est simple : au lieu de faire des queues par type de service (ToS), tu fais des queues par utilisateur (IP source). C'est possible sous Linux avec ESFQ, je ne sais pas pour les autres plateformes. Avec cette solution, tu as la garantie que la bande passante est découpée de manière équitable entre les différents hôtes de ton réseau. Imaginons que ton tuyau fait 10 Mbits, et que deux utilisateurs font du DDL. Eh bien les deux auront 5 Mbits chacun, même si l'un ouvre 100 connexions et l'autre 2. Plus intéressant : si quelqu'un fait du DDL et qu'un autre veut faire de la VoIP, la VoIP aura toujours priorité par rapport au DDL car elle consomme beaucoup moins de bande passante et n'atteindra donc jamais le quota. La VoIP passera donc comme sur des roulettes, et toute la bande passante nécessaire sera prise sur le téléchargement du voisin (qui l'aura bien cherché). Dans tous les cas l'utilisation du tuyau est optimale : par exemple le téléchargeur aura 9 Mbits et la VoIP en aura 1, car elle ne demande pas plus. Par contre, le point important ici, c'est que ces 1 Mbits sont *garantis* par le système. Le principal avantage est qu'il est impossible de tricher : l'utilisateur aura beau tenter de tunelliser ou de forger les champs ToS de ses paquets IP, ça ne changera strictement rien car tout est basé sur son adresse IP, qu'il est impossible de falsifier (enfin, j'espère). Un problème persiste cependant : si tu es vraiment fauché au niveau de la taille de ton tuyau, tu pourrais te retrouver avec 100 téléchargeurs sur un tuyau de 1 Mbits, ce qui fait que chaque personne se retrouve avec 10 kbits… et là, c'est l'horreur et même la VoIP ne passe plus. Comme cela a déjà été dit sur ce fil la vraie solution est d'augmenter la taille du tuyau, mais si ce n'est pas une option, je suggèrerais d'ajouter un burst qui permettrait à chaque utilisateur de dépasser son quota à condition qu'il ne le fasse pas trop longtemps. Ainsi les téléchargeurs auraient le burst épuisé en permanence car ils pompent en continu, mais par contre ceux qui font autre chose auraient du burst en réserve et gagneraient donc la priorité sur les téléchargeurs, jusqu'à un certain point. Par exemple avec un burst de 50 Mo, c'est plus que suffisant pour y caser une longue conversation en VoIP, qui passera comme sur des roulettes même avec 1 téléchargeurs fous à côté. En d'autres termes, le système « punit » automatiquement ceux qui pompent en continu sur le tuyau. Bon, avant toute chose j'aimerais préciser que dans mon mail de base je ne parlais absolument pas d'optimiser mon cas particulier, mais bien de lancer le débat sur l'intérêt de considérer le HTTP comme un protocole de transport dans les firewalls, par ce que le web change toussa, et mon cas particulier de débit trop faible n'était là que pour expliquer d'où me venait l'idée, que j'ai considérablement élargie depuis. Bref je l'ai dit assez de fois. Je suis entièrement d'accord avec le fait qu'il faille limiter la bande passante par utilisateur et non par connexion ! Et merci beaucoup pour tes arguments ainsi que tes informations, car c'est bien plus développé que ce que j'ai trouvé jusqu'à présent, ça va m'aider à avancer :) . @Rémi: oui nos utilisateurs sont authentifiés, donc on a une IP (enfin un subnet) par utilisateur. -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
RE: [FRnOG] Firewall HTTP
Michel Py a écrit : un large réseau interne ou tout est permis; en tant que FAI les données des clients sont privées, mais en tant qu'opérateur d'entreprise (ici) le réseau est le tien, pas besoin de demander d'autorisation pour sniffer le trafic des employés. Christophe Baegert a écrit: En es-tu bien sûr ? Gaël Martinez a écrit: En general ici aux Etats-Unis (je pense que Michel fait reference a ca) quand tu te connectes a un systeme (corporate, gouvernement ou autre ) tu recois toujours une banniere (motd) t'informant que tu es surveille, et que tu renonces a ton droit de vivre quand tu te connectes :) D'un point de vue audit et legal, cette banniere est super important et est strictement regulee et auditee. Absolument. A noter que la bannière n'est pas ce qui t'enlèves le droit de vivre, c'est uniquement pour couper le sifflet aux petits malins qui auraient des envies de jouer le moi je n'étais pas au courant pendant un procès. En général on te fait aussi signer une addition au contrat de travail qui précise ça aussi: le système informatique de l'entreprise appartient à l'entreprise et donc par le simple fait de l'utiliser tu reconnais le droit de l'entreprise de regarder ce que tu fais. C'est totalement gonflant, d'ailleurs: sniffer le trafic d'un employé qui surfe au lieu de bosser pour le virer, c'est un problème de RH pas d'ingénierie de réseau. Comme si j'avais que ça à faire, faut aussi que je change de casquette pour mettre un képi, je m'en serais passé. Pour les FAI ce n'est pas pareil, ton FAI ne peut pas sniffer tes données ; d'après ce que je comprends, les statistiques anonymes sont généralement autorisées. Michel Py a écrit: Non il y a des utilisations valides, mais une chose est certaine: ni QOS ni rien d'autre ne vont transformer un petit tuyau en un tuyau plus gros. [..] Stéphane Le Men a écrit: Aussi surprenant que cela puisse être, les opérateurs mobiles comptent bien réaliser cette prouesse, de faire grossir les petits tuyaux radios, en déployant RHOC (rfc5795 et autres) pour la partie voix, et avoir un réseau tout ip. C'est par le calcul distribué, et la surveillance de l'activité des utilisateurs que les opérateurs mobiles maximiseront l'utilisation des ressources du réseau, et donc leur ROI. Je suis un peu sceptique pour la partie IP, et voici pourquoi: la nature ayant horreur du vide, les radios 4G vont provoquer la création de pages web mobile pour les gros tuyaux (avec, sans aucun doute, un tas de cochonneries, vidéos et autres applets encapsulés dans HTTP); un jour ou l'autre quelqu'un avec un téléphone 2G 1/2 ou 3G va ouvrir une des pages en question a coté d'un de ses potes qui a un téléphone 4G, ça va ramer, et ce n'est pas le QOS qui va faire le réseau 3G afficher la page remplie de merdasse sous HTTP à la vitesse du 4G. Eh c'est vendredi! Et ici c'est un vendredi spécial: Black Friday. Après s'être gavé de dinde hier pour Thanksgiving, le bon américain va faire ses courses. Une télé HD 1080p DLP de 152 cm (60) pour $597 (451 euros): http://www.frys.com/ShopCartServlet?purchase=6294340 Qui dit mieux! Michel --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Hé, moi j'ai une solution ! Un serveur, meme un vieux Pentium 75 devrait suffire, 4 Mo de ram, ca tournera nickel. Apres, un squid, un peu de poudre verte, et voilà. On dit merci qui ? ... Merci la poudre verte ! --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Le 25/11/10, Françoisaifs...@gmail.com a écrit : Pour revenir au sujet, puisque l'on parlait de voip et de skype, je crois savoir que skype peut utiliser le port 80 mais pas HTTP. et seulement en cas de filtrage sur d'autres ports. Skype est conçu pour contourner à peu près tout ce qui est contournable, et AMHA il est capable de s'encapsuler de façon à passer par un proxy HTTP sans problèmes. Ce truc n'est pas fair-play vis à vis du réseau, c'est un soft vraiment vicieux, et par ce qu'il fait sur le réseau, et par ce qu'il fait sur le poste où il est installé. Bref il faut peut-être éduquer les utilisateurs pour dire que le proxy n'est là que pour sortir en http. (après on peut effectivement se poser la question de l'utilité du proxy dans ce cas, mais c'est un autre débat). Le proxy sert de cache donc évite de re-télécharger plusieurs fois les mêmes contenus, tout simplement? Bon, avec le Web 2.0 c'est moins utile. Rémi. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez remy.sanc...@hyperthese.net wrote: Bon et finalement, est-ce que la QoS sert à quelquechose ? Par ce que si on résume, la QoS ne sert à rien quand on a assez de bande passante, et elle n'est pas assez efficace quand y'a pas assez de bande passante... Bien résumé. Encore plus court : la QoS sur un réseau IP ne sert à rien et est même néfaste. Je sais que tu ne veux pas en parler mais j'ai été exactement dans le même cas que toi avec ta résidence étudiante. Si tu ne peux pas limiter la taille du tuyau, la solution est de compter les paquets et/ou les octets qui passent dedans pour chaque utilisateur et de faire en sorte que la somme totale ne dépasse pas ton débit maximal. Pas besoin de regarder dans les paquets. Ça n'est pas de la QoS, c'est du best effort. Si tu commences à faire de la QoS, tu vas avoir deux profils d'utilisateurs : les geeks qui vont comprendre ce qui passe et tunneler dedans, et les gens normaux qui vont se faire avoir. En pratique, une simple limite en upload et en download par jour, semaine et/ou mois suffit dans ce genre de contexte. Après, tu es plus ou moins obligé de regarder dans les paquets IP quand même si tu es relié à un réseau du type Renater, mais c'est un autre problème... -- Pierre 'catwell' Chapuis --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Pour ne pas gérer la congestion, on évite la congestion. Gérer la congestion est une solution onéreuse et complexe. a+ On Thu, 25 Nov 2010 15:29:34 +0100, Pierre Chapuis catw...@archlinux.us wrote: On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez remy.sanc...@hyperthese.net wrote: Bon et finalement, est-ce que la QoS sert à quelquechose ? Par ce que si on résume, la QoS ne sert à rien quand on a assez de bande passante, et elle n'est pas assez efficace quand y'a pas assez de bande passante... Bien résumé. Encore plus court : la QoS sur un réseau IP ne sert à rien et est même néfaste. Je sais que tu ne veux pas en parler mais j'ai été exactement dans le même cas que toi avec ta résidence étudiante. Si tu ne peux pas limiter la taille du tuyau, la solution est de compter les paquets et/ou les octets qui passent dedans pour chaque utilisateur et de faire en sorte que la somme totale ne dépasse pas ton débit maximal. Pas besoin de regarder dans les paquets. Ça n'est pas de la QoS, c'est du best effort. Si tu commences à faire de la QoS, tu vas avoir deux profils d'utilisateurs : les geeks qui vont comprendre ce qui passe et tunneler dedans, et les gens normaux qui vont se faire avoir. En pratique, une simple limite en upload et en download par jour, semaine et/ou mois suffit dans ce genre de contexte. Après, tu es plus ou moins obligé de regarder dans les paquets IP quand même si tu es relié à un réseau du type Renater, mais c'est un autre problème... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Selon Rémi Bouhl remibo...@gmail.com: Le proxy sert de cache donc évite de re-télécharger plusieurs fois les mêmes contenus, tout simplement? Bon, avec le Web 2.0 c'est moins utile. On en reparle quand les protocoles de streaming à base de chunk seront un peu plus répandus :-) Et sinon, cette discussion hors sujet est bientôt finie ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On 11/25/2010 11:20 AM, Guillaume Esnault wrote: Cette discussion me met mal à l'aise. Ce genre d'outil relève de l'écoute sur le contenu ou le langage (Layer7). C'est comme si nous faisions des écoutes téléphoniques automatiques. Selon ce qui est dit il serait fait certaines actions. Certain organismes comme la NSA (Echelon) le pratiquent à grande échelle. Ce n'est pas légal et c'est dangereux. (cpdt, il n'y a pas encore de jurisprudence, il me semble) Il est certain que chez Digicube nous ne pratiquerons jamais ce genre de chose. L'usage d'un proxy tu classes ça comment alors ? Quand tu mets un proxy pour le cache c'est le même topo, sauf qu'en plus tu gardes les données... Et quand tu met un proxy pour bloquer les accès à certains sites, c'est encore pire (même si très franchement ne n'adhère pas du tout avec cette pratique là). C'est pas un peu extrême de comparer d'un côté la prioritarisation de certains flux pour améliorer le service qu'ils rendent et de l'autre côté Echelon ?... -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Firewall HTTP
On 11/25/2010 11:52 AM, Rémi Bouhl wrote: Le proxy sert de cache donc évite de re-télécharger plusieurs fois les mêmes contenus, tout simplement? Bon, avec le Web 2.0 c'est moins utile. Même pas, vu qu'avec le web 2.0 tout le monde va sur les^Wle même site (ça commence par face et ça finit par book), et qu'en plus tout le monde regarde le même contenu, et que tout ça est stocké sur un CDN, on se retrouve avec pas mal de contenu à mettre en cache vu par tout le monde. -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Firewall HTTP
On 11/25/2010 03:29 PM, Pierre Chapuis wrote: On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez remy.sanc...@hyperthese.net wrote: Bon et finalement, est-ce que la QoS sert à quelquechose ? Par ce que si on résume, la QoS ne sert à rien quand on a assez de bande passante, et elle n'est pas assez efficace quand y'a pas assez de bande passante... Bien résumé. Encore plus court : la QoS sur un réseau IP ne sert à rien et est même néfaste. Je sais que tu ne veux pas en parler mais j'ai été exactement dans le même cas que toi avec ta résidence étudiante. Si tu ne peux pas limiter la taille du tuyau, la solution est de compter les paquets et/ou les octets qui passent dedans pour chaque utilisateur et de faire en sorte que la somme totale ne dépasse pas ton débit maximal. Pas besoin de regarder dans les paquets. Ça n'est pas de la QoS, c'est du best effort. Si tu commences à faire de la QoS, tu vas avoir deux profils d'utilisateurs : les geeks qui vont comprendre ce qui passe et tunneler dedans, et les gens normaux qui vont se faire avoir. En pratique, une simple limite en upload et en download par jour, semaine et/ou mois suffit dans ce genre de contexte. Après, tu es plus ou moins obligé de regarder dans les paquets IP quand même si tu es relié à un réseau du type Renater, mais c'est un autre problème... Donc le DiffServ co c'est une vaste fumisterie ? On s'est amusé à utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne fait de QoS ? Je voudrais pas faire le mec relou qui met du temps à comprendre (même si à priori cette discussion gonfle tout le monde :/), mais j'ai du mal à me mettre en tête que tout ça ait été inventé pour rien... C'est quand même pas des clowns à l'IETF non ? -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
RE: [FRnOG] Firewall HTTP
Guillaume Esnault a écrit: Cette discussion me met mal à l'aise. Grandis. C'est une liste de FAI, l'interception et l'analyse des flux, même si c'est souvent une Albanerie, ça fait partie du boulot. Et la requête originale, même si tout le monde pense plus ou moins que ça ne servirait pas à grand-chose, était fondée sur des bonnes intentions. En plus, nombre de lecteurs opèrent un large réseau interne ou tout est permis; en tant que FAI les données des clients sont privées, mais en tant qu'opérateur d'entreprise (ici) le réseau est le tien, pas besoin de demander d'autorisation pour sniffer le trafic des employés. Ce genre d'outil relève de l'écoute sur le contenu ou le langage (Layer7). C'est comme si nous faisions des écoutes téléphoniques automatiques. Selon ce qui est dit il serait fait certaines actions. Il y a des fois ou c'est nécessaire et où des décisions doivent être prises. Par exemple, si j'ai à choisir entre le film de cul de Bob et la série à l'eau de rose d'Alice, je choisis Bob :-D Rémy Sanchez a écrit: Bon et finalement, est-ce que la QoS sert à quelque chose? Par ce que si on résume, la QoS ne sert à rien quand on a assez de bande passante, et elle n'est pas assez efficace quand y'a pas assez de bande passante... Pas 100% vrai mais néanmoins très souvent vrai. Très, très souvent. Pierre Chapuis a écrit: Bien résumé. Encore plus court : la QoS sur un réseau IP ne sert à rien et est même néfaste. Je n'irais pas aussi loin que Pierre ceci dit; quand on transporte de la voix la QOS est nécessaire, si il y a suffisamment de BP. Contrairement à ce que beaucoup de gens pensent, non pas pour préserver la qualité de la voix (ce qui peut se faire en réservant la BP) mais pour maximiser la part allouée aux données quand la voix n'est pas en service. Si tu commences à faire de la QoS, tu vas avoir deux profils d'utilisateurs: les geeks qui vont comprendre ce qui passe et tunneler dedans, et les gens normaux qui vont se faire avoir. C'est souvent le cas, en effet. Ceci dit si tu limites une certaine BP par utilisateur ce n'est pas la solution non plus: jamais rapide. Donc le DiffServ co c'est une vaste fumisterie ? On s'est amusé à utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne fait de QoS ? Je voudrais pas faire le mec relou qui met du temps à comprendre (même si à priori cette discussion gonfle tout le monde :/), mais j'ai du mal à me mettre en tête que tout ça ait été inventé pour rien... Non il y a des utilisations valides, mais une chose est certaine: ni QOS ni rien d'autre ne vont transformer un petit tuyau en un tuyau plus gros. QOS, c'est la cerise sur le gâteau QUAND tu as suffisamment de BP. Quand le tuyau n'est pas assez gros, ne rien faire est souvent la meilleure des solutions: quoi que tu fasses, ça ne va pas changer le fait que tu as besoin d'un plus gros tuyau, donc ce que tu fais c'est déshabiller Pierre pour habiller Paul et au bout du compte tu as déplacé le problème mais pas résolu et tu as perdu beaucoup de temps et d'énergie pour revenir à la case départ sans toucher les $200. C'est quand même pas des clowns à l'IETF non ? Euh non mais il y en a un petit nombre qui devraient arrêter de fumer la moquette, ceci dit. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Bonjour, Le 25/11/2010 23:30, Michel Py a écrit : un large réseau interne ou tout est permis; en tant que FAI les données des clients sont privées, mais en tant qu'opérateur d'entreprise (ici) le réseau est le tien, pas besoin de demander d'autorisation pour sniffer le trafic des employés. En es-tu bien sûr ? Cordialement, Christophe --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
2010/11/25 Christophe Baegert c.baegert-lis...@lixium.fr Bonjour, Le 25/11/2010 23:30, Michel Py a écrit : un large réseau interne ou tout est permis; en tant que FAI les données des clients sont privées, mais en tant qu'opérateur d'entreprise (ici) le réseau est le tien, pas besoin de demander d'autorisation pour sniffer le trafic des employés. En es-tu bien sûr ? Cordialement, Christophe --- Liste de diffusion du FRnOG http://www.frnog.org/ En general ici aux Etats-Unis (je pense que Michel fait reference a ca) quand tu te connectes a un systeme (corporate, gouvernement ou autre ) tu recois toujours une banniere (motd) t'informant que tu es surveille, et que tu renonces a ton droit de vivre quand tu te connectes :) D'un point de vue audit et legal, cette banniere est super important et est strictement regulee et auditee. Cordialement -- Gaël Martinez
Re: [FRnOG] Firewall HTTP
2010/11/25 Rémy Sanchez remy.sanc...@hyperthese.net: C'est quand même pas des clowns à l'IETF non ? IPv6 ? -- Mattieu Baptiste /earth is 102% full ... please delete anyone you can. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Bonjour, Ce que tu cherches, n'est-il pas du filtrage de niv 7 ? L'idée est de déterminée selon un pattern le flux, de le tagger et ensuite appliquer les régles que tu souhaites (filtrages, QoS ...). Cordialement, Mathias Le mercredi 24 novembre 2010 à 14:51 +0100, Rémy Sanchez a écrit : Bonjour à tous, Les dernières tendances en terme de n'importe quoi consistent à faire passer à peu près tout ce qu'on peut par du HTTP, à tel point qu'on a pratiquement remplacé le TCP. Après tout, toutes les applications web passent par du HTTP, or c'est plutôt vaste : distribution de contenu, messagerie instantanée, flux vidéo, traitement de texte, ... Sans oublier toutes les applications qui utilisent le HTTP (par exemple MSN) pour faire passer leur protocole en environnement restreint, ou carrément les tunnels. En bref, le port 80 est toujours ouvert, soit directement, soit à travers un proxy. Et c'est la porte ouverte à toutes les fenêtres... En fin de compte, serait-il cohérent d'imaginer une application analogue à un firewall, qui au lieu de s'en prendre au TCP s'attaque directement au HTTP ? Ça y est je vois déjà tous les canons pointés en ma direction pour me signaler qu'on a déjà des proxys, IDS et tout un tas de trucs dans le genre. C'est d'ailleurs pour ça que je demande si l'idée est cohérente ou si c'est du grand n'importe quoi. Cependant, je pense à des fonctionnalités qui m'ont l'air difficile à configurer dans les outils pré-cités, comme par exemple différencier les types de flux pour y assigner des priorités (long poll et dérivées, page standard, gros fichier, accélérateur de téléchargements, ...), reconnaître les sous protocoles (comme au dessus, MSN), reconnaître les tunnels, s'en prendre aussi au HTTPS, ... En bref, pouvoir traiter tout ce qui passe par du HTTP comme un flux TCP/IP avec un numéro de protocole et un tag pour la QoS. Les outils que j'ai rencontré jusque là ne permettent pas de faire ça simplement (Squid, pf, iptables pour ceux que j'ai vraiment utilisé), après étant relativement novice en réseau j'ai assez peu touché aux autres outils et aux appliances proprio, donc mon panorama est restreint. Donc qu'en pensez vous, lecteurs avisés de FRnOG ? Un tel outil serait-il utile ? Pour qui ? Qu'y verriez vous à l'intérieur ? Est-ce que j'ai complètement fumé la moquette ? NDLR : l'idée ici est de débattre des fonctionnalités d'un tel produit, non de la manière dont on pourrait les implémenter... Allez c'est parti pour une après midi à prendre des baffes :) -- Mathias WOLFF Directeur Associé WM Networks Adresse : 149 Avenue du Maine 75014 PARIS GSM : 06.79.59.43.32 Opérateur d'opérateurs. smime.p7s Description: S/MIME cryptographic signature
Re: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 14:57:56 +0100, Mathias WMN m.wo...@wm-networks.fr wrote: Bonjour, Ce que tu cherches, n'est-il pas du filtrage de niv 7 ? L'idée est de déterminée selon un pattern le flux, de le tagger et ensuite appliquer les régles que tu souhaites (filtrages, QoS ...). Cordialement, Probablement que ça rentre dans cette catégorie, mais ce que je veux surtout c'est pouvoir considérer le HTTP comme un protocole de niveau 4. Le nombre d'applications web et/ou passant par du HTTP est devenu tellement important que je pense qu'on a plutôt intérêt se mettre à la vitesse supérieure et considérer ce qui passe dans le HTTP comme des protocoles à part entière. Sinon avec quoi tu ferais ton filtrage de niveau 7 ? Une recherche rapide me donne ce genre de résultats : http://firewalls.smile.fr/L-offre-open-source-en-matiere-de-filtrage/Filtrage-niveau-7, qui préconise l'usage de Squid, ce qui comme je le disais dans le mail précédent n'est pas vraiment adapté à ce genre d'usages... (ou alors, j'ai raté un épisode :) ) -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Si nous etiames vendreday, j'irions plus loin... Après la concentration de tous les protocoles au dessus de TCP (ce qui était deja une hérésie), puis de HTTP (n'en parlons pas)... Bienvenue vers la concentration vers deux fqdn : www.google.com et www.facebook.com Je remarque en effet, que 1/ De plus en plus de marketeux rafolent des www.facebook.com/x à la place d'un site. C'est pratique, car ça permet de profiler et FB est accessible via les pseudos acces web des téléphones mobile. 2/ Et de plus en plus de collègues utilisent les *...@gmail.com car c'est le webmail le moins filtré en entreprise... - Mail Original - De: Rémy Sanchez remy.sanc...@hyperthese.net À: frnog@frnog.org Envoyé: Mercredi 24 Novembre 2010 14h51:56 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: [FRnOG] Firewall HTTP Bonjour à tous, Les dernières tendances en terme de n'importe quoi consistent à faire passer à peu près tout ce qu'on peut par du HTTP, à tel point qu'on a pratiquement remplacé le TCP. Après tout, toutes les applications web passent par du HTTP, or c'est plutôt vaste : distribution de contenu, messagerie instantanée, flux vidéo, traitement de texte, ... Sans oublier toutes les applications qui utilisent le HTTP (par exemple MSN) pour faire passer leur protocole en environnement restreint, ou carrément les tunnels. En bref, le port 80 est toujours ouvert, soit directement, soit à travers un proxy. Et c'est la porte ouverte à toutes les fenêtres... En fin de compte, serait-il cohérent d'imaginer une application analogue à un firewall, qui au lieu de s'en prendre au TCP s'attaque directement au HTTP ? Ça y est je vois déjà tous les canons pointés en ma direction pour me signaler qu'on a déjà des proxys, IDS et tout un tas de trucs dans le genre. C'est d'ailleurs pour ça que je demande si l'idée est cohérente ou si c'est du grand n'importe quoi. Cependant, je pense à des fonctionnalités qui m'ont l'air difficile à configurer dans les outils pré-cités, comme par exemple différencier les types de flux pour y assigner des priorités (long poll et dérivées, page standard, gros fichier, accélérateur de téléchargements, ...), reconnaître les sous protocoles (comme au dessus, MSN), reconnaître les tunnels, s'en prendre aussi au HTTPS, ... En bref, pouvoir traiter tout ce qui passe par du HTTP comme un flux TCP/IP avec un numéro de protocole et un tag pour la QoS. Les outils que j'ai rencontré jusque là ne permettent pas de faire ça simplement (Squid, pf, iptables pour ceux que j'ai vraiment utilisé), après étant relativement novice en réseau j'ai assez peu touché aux autres outils et aux appliances proprio, donc mon panorama est restreint. Donc qu'en pensez vous, lecteurs avisés de FRnOG ? Un tel outil serait-il utile ? Pour qui ? Qu'y verriez vous à l'intérieur ? Est-ce que j'ai complètement fumé la moquette ? NDLR : l'idée ici est de débattre des fonctionnalités d'un tel produit, non de la manière dont on pourrait les implémenter... Allez c'est parti pour une après midi à prendre des baffes :) -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Ce qui me gêne un peu plus c'est que c'est une des briques du grand firewall Chinois/Iranien/Français (inutile de rayer la mention inutile : la Loi LOPSSI nous prépare des choses sympa dans ce domaine...). Pas besoin d'aller si loin, tous votre trafic http sur mobile passe par un Firewall http, mais il fire pas la police, juste la facture --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Le 24/11/10, Rémy Sanchezremy.sanc...@hyperthese.net a écrit : Après, vu à quel point les numéros de contorsioniste par HTTP se démocratisent, laisser le HTTP sans aucun filtrage donne l'impression de laisser tous les ports ouvert. Il y a 10 ans: Laisser les ports ouverts en sortie sans aucun filtrage me donne l'impression qu'on pourra me pirater. Ça donne la situation actuelle dont tu es insatisfait (tout le monde fait n'importe quoi via HTTP). Donc tu vas rajouter une couche. Prépare-toi, dans 10 ans, à devoir lutter contre les accès HTTP qui font semblant d'être du vrai surf mais en fait si on met un quad-core pour faire du DPI on se rend compte que c'est du VPN encapsulé dans des pseudo-pages Web. Du coup je propose la solution couillue: ouvrir les vannes sur les autres ports. Laisser sortir ce qui était encapsulé en HTTP, afin qu'HTTP redevienne ce qu'il n'aurait pas du cesser d'être. Oyez braves utilisateurs, vous pouvez sortir en SSH, en VPN et en RDP, inutile de faire des tunnels HTTP. Rémi. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 2010-11-24 at 15:55 +0100, Rémi Bouhl wrote: Prépare-toi, dans 10 ans, à devoir lutter contre les accès HTTP qui font semblant d'être du vrai surf mais en fait si on met un quad-core pour faire du DPI on se rend compte que c'est du VPN encapsulé dans des pseudo-pages Web. pas la peine d'attendre 10 ans, au vu des multiples process http-tunnel qui semblent tourner sur les machines dédiées aux étudiants par ici --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 24/11/2010 15:47, guillaume.monne...@free.fr a écrit : Après la concentration de tous les protocoles au dessus de TCP (ce qui était deja une hérésie) Sur ce point j'aimerais que tu développe un peu, je ne comprend pas bien. C'est peut-être dû à mon jeune âge, mais on m'a toujours appris que sur Internet la couche transport du modèle OSI était fournie par TCP ou UDP selon les besoins. Une explication ? Yves Dubromelle -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkztKxYACgkQ8IhKGszP0SoGRAD/Qwohzn+tWqisCz6wMDRdiR2c 0DMROC7GZZKAqpMH/YIA/1zaHnEXBd9iJRdTZLXxkewbgpOmi74CDAu9jqzuq79g =avO1 -END PGP SIGNATURE- --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 2010-11-24 at 16:10 +0100, Rémy Sanchez wrote: Pour situer mon contexte et l'origine de mon idée : je m'occupe du réseau dans une résidence étudiante, avec un débit très limité par rapport au nombre d'utilisateurs. ne faudrait il pas commencer par la ? genre, augmenter le débit disponible de maniere substantielle, plutot que d'essayer de gerer la rareté de maniere sous-optimale ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Pour situer mon contexte et l'origine de mon idée : je m'occupe du réseau dans une résidence étudiante, avec un débit très limité par rapport au nombre d'utilisateurs. Et on ne peut pas dire que tout soit bloqué sur le réseau, on ouvre les ports à la demande. Seulement, j'aimerais que le débile de base qui télécharge 10 trucs en même temps n'empêche pas le type qui a entretient d'embauche de faire de la VoIP (le problème n'existe plus au fait, on a trouvé des solutions quand même). Après en partant de ce constat, on remarque qu'il y a pas mal d'usages différent du HTTP, qu'on pourrait regrouper en familles avec des priorités différentes. Et il y a aussi des protocoles de tunnel que j'ai pas envie de voir passer par ce que je préfère le protocole en direct géré proprement plutôt qu'une horreur par HTTP. Bref, le but du jeu est de mieux contrôler les priorités pour améliorer le service rendu. Ce qui est donc à priori possible avec des trucs commerciaux, mais à mon avis ils servent plus à taper bêtement sur les utilisateurs qu'à vraiment travailler la qualité de service... Et puis bon, les trucs commerciaux c'est pas libre, et le dernier truc que j'ai envie de faire c'est de mettre une nœud aussi important de mon réseau sous des verrons (bien que des fois on n'ai pas le choix). Si ton problème est juste d'avoir assez de BP pour tous tout le temps, et non de savoir exactement ce que font tes usagers, qu'ils utilisent HTTP ou non, pourquoi ne pas mettre en place des règles de Qos/Shaping qui brident le fou de Download quand il n'est pas tout seul sur les tuyaux et le laisse faire quand tout le monde dort ? -- David Ramahefason r...@netfacile.net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 16:13:36 +0100, Raphaël Jacquot sxp...@sxpert.org wrote: On Wed, 2010-11-24 at 16:10 +0100, Rémy Sanchez wrote: Pour situer mon contexte et l'origine de mon idée : je m'occupe du réseau dans une résidence étudiante, avec un débit très limité par rapport au nombre d'utilisateurs. ne faudrait il pas commencer par la ? genre, augmenter le débit disponible de maniere substantielle, plutot que d'essayer de gerer la rareté de maniere sous-optimale ? On accepte les dons mensuels en virement, chèque ou espèce si tu veux :) Plus sérieusement, on fait ce qu'on peut, car on a des ressource matérielles et humaines limitées. Mais c'est pas du tout de ça que je voulais parler, en fait. L'idée me vient de là, mais dans mon cas précis on a pratiquement réglé tous nos problèmes. Le constat est que tout passe dans un énorme tuyau qu'est le HTTP et que peut être qu'il faudrait y mettre plus de contrôle à l'intérieur, avec des nouveaux outils plus adaptés que ce qu'on a aujourd'hui. -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Le constat est que tout passe dans un énorme tuyau qu'est le HTTP et que peut être qu'il faudrait y mettre plus de contrôle à l'intérieur, avec des nouveaux outils plus adaptés que ce qu'on a aujourd'hui. http://en.wikipedia.org/wiki/Multilayer_switch Et ça fait aussi avec des linux --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 15:47:48 +0100 (CET), guillaume.monne...@free.fr wrote: Si nous etiames vendreday, j'irions plus loin... Après la concentration de tous les protocoles au dessus de TCP (ce qui était deja une hérésie), puis de HTTP (n'en parlons pas)... Bienvenue vers la concentration vers deux fqdn : www.google.com et www.facebook.com Je remarque en effet, que 1/ De plus en plus de marketeux rafolent des www.facebook.com/x à la place d'un site. C'est pratique, car ça permet de profiler et FB est accessible via les pseudos acces web des téléphones mobile. 2/ Et de plus en plus de collègues utilisent les *...@gmail.com car c'est le webmail le moins filtré en entreprise... Fort heureusement, mon webmail perso n'est jamais filtré. Quoique, à un moment, le mot webmail avait été banni des URL accessibles chez un ancien employeur... (oui oui, meme pour aller faire des recherches, ou lire des articles sur le sujet...) - Mail Original - De: Rémy Sanchez remy.sanc...@hyperthese.net À: frnog@frnog.org Envoyé: Mercredi 24 Novembre 2010 14h51:56 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: [FRnOG] Firewall HTTP Bonjour à tous, Les dernières tendances en terme de n'importe quoi consistent à faire passer à peu près tout ce qu'on peut par du HTTP, à tel point qu'on a pratiquement remplacé le TCP. Après tout, toutes les applications web passent par du HTTP, or c'est plutôt vaste : distribution de contenu, messagerie instantanée, flux vidéo, traitement de texte, ... Sans oublier toutes les applications qui utilisent le HTTP (par exemple MSN) pour faire passer leur protocole en environnement restreint, ou carrément les tunnels. En bref, le port 80 est toujours ouvert, soit directement, soit à travers un proxy. Et c'est la porte ouverte à toutes les fenêtres... En fin de compte, serait-il cohérent d'imaginer une application analogue à un firewall, qui au lieu de s'en prendre au TCP s'attaque directement au HTTP ? Ça y est je vois déjà tous les canons pointés en ma direction pour me signaler qu'on a déjà des proxys, IDS et tout un tas de trucs dans le genre. C'est d'ailleurs pour ça que je demande si l'idée est cohérente ou si c'est du grand n'importe quoi. Cependant, je pense à des fonctionnalités qui m'ont l'air difficile à configurer dans les outils pré-cités, comme par exemple différencier les types de flux pour y assigner des priorités (long poll et dérivées, page standard, gros fichier, accélérateur de téléchargements, ...), reconnaître les sous protocoles (comme au dessus, MSN), reconnaître les tunnels, s'en prendre aussi au HTTPS, ... En bref, pouvoir traiter tout ce qui passe par du HTTP comme un flux TCP/IP avec un numéro de protocole et un tag pour la QoS. Les outils que j'ai rencontré jusque là ne permettent pas de faire ça simplement (Squid, pf, iptables pour ceux que j'ai vraiment utilisé), après étant relativement novice en réseau j'ai assez peu touché aux autres outils et aux appliances proprio, donc mon panorama est restreint. Donc qu'en pensez vous, lecteurs avisés de FRnOG ? Un tel outil serait-il utile ? Pour qui ? Qu'y verriez vous à l'intérieur ? Est-ce que j'ai complètement fumé la moquette ? NDLR : l'idée ici est de débattre des fonctionnalités d'un tel produit, non de la manière dont on pourrait les implémenter... Allez c'est parti pour une après midi à prendre des baffes :) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Le 24 novembre 2010 16:10, Rémy Sanchez remy.sanc...@hyperthese.net a écrit : Pour situer mon contexte et l'origine de mon idée : je m'occupe du réseau dans une résidence étudiante, avec un débit très limité par rapport au nombre d'utilisateurs. Et on ne peut pas dire que tout soit bloqué sur le réseau, on ouvre les ports à la demande. Seulement, j'aimerais que le débile de base qui télécharge 10 trucs en même temps n'empêche pas le type qui a entretient d'embauche de faire de la VoIP (le problème n'existe plus au fait, on a trouvé des solutions quand même). Comment tu prends la décision que - la conversation en voip est importante (entretien d'embauche ou teamspeak pendant un WoW ?) - le download n'est pas important (divX méchant illégale ou dossier important ?) Normalement la réponse est donc : - on fait de la Qos pour répartir au mieux le débit (et donc ne pas avantager celui qui ouvre 10 flux avec un download manager) - mais on ne regarde pas ce qu'il fait car 1- il fait ce qu'il veut 2- même avec de la bonne volonté tu n'arriveras jamais à savoir si c'est vraiment important ou pas sans te tromper
Re: [FRnOG] Firewall HTTP
Le 24/11/10, David Ramahefasonr...@netfacile.net a écrit : Si ton problème est juste d'avoir assez de BP pour tous tout le temps, et non de savoir exactement ce que font tes usagers, qu'ils utilisent HTTP ou non, pourquoi ne pas mettre en place des règles de Qos/Shaping qui brident le fou de Download quand il n'est pas tout seul sur les tuyaux et le laisse faire quand tout le monde dort ? Je plussoie l'idée. Inutile d'aller chercher au niveau de la couche 7 ce que les gens font vraiment (et, à tout prendre, ce n'est pas à l'admin de décider de ce qui est prioritaire, même en faisant preuve de bon sens). Une répartition équitable en garantissant un minimum à chaque utilisateur, et le tour est joué :) Rémi --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 2010-11-24 at 16:59 +0100, Rémi Bouhl wrote: Le 24/11/10, David Ramahefasonr...@netfacile.net a écrit : Si ton problème est juste d'avoir assez de BP pour tous tout le temps, et non de savoir exactement ce que font tes usagers, qu'ils utilisent HTTP ou non, pourquoi ne pas mettre en place des règles de Qos/Shaping qui brident le fou de Download quand il n'est pas tout seul sur les tuyaux et le laisse faire quand tout le monde dort ? Je plussoie l'idée. Inutile d'aller chercher au niveau de la couche 7 ce que les gens font vraiment (et, à tout prendre, ce n'est pas à l'admin de décider de ce qui est prioritaire, même en faisant preuve de bon sens). Une répartition équitable en garantissant un minimum à chaque utilisateur, et le tour est joué :) ca et chercher a augmenter la bande passante disponible, ce qui n'est pas forcément cher... (par exemple, en évitant d'avoir a se coltiner 5km de ligne de cuivre pourries) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 16:57:50 +0100, Julien Richer jul...@ywigo.fr wrote: Le 24 novembre 2010 16:10, Rémy Sanchez a écrit : Pour situer mon contexte et l'origine de mon idée : je m'occupe du réseau dans une résidence étudiante, avec un débit très limité par rapport au nombre d'utilisateurs. Et on ne peut pas dire que tout soit bloqué sur le réseau, on ouvre les ports à la demande. Seulement, j'aimerais que le débile de base qui télécharge 10 trucs en même temps n'empêche pas le type qui a entretient d'embauche de faire de la VoIP (le problème n'existe plus au fait, on a trouvé des solutions quand même). Comment tu prends la décision que - la conversation en voip est importante (entretien d'embauche ou teamspeak pendant un WoW ?) - le download n'est pas important (divX méchant illégale ou dossier important ?) Normalement la réponse est donc : - on fait de la Qos pour répartir au mieux le débit (et donc ne pas avantager celui qui ouvre 10 flux avec un download manager) - mais on ne regarde pas ce qu'il fait car 1- il fait ce qu'il veut 2- même avec de la bonne volonté tu n'arriveras jamais à savoir si c'est vraiment important ou pas sans te tromper Bien sûr qu'on n'écoute pas le contenu des conversations pour juger si elles sont importantes. C'était un exemple, pour illustrer un peu... Par contre en règle générale on veut que la VoIP aille vite alors que de lancer 10 connexions HTTP pour un même fichier c'est carrément pas fair play. Et si ça t'intéresse, des retours qu'on a eu, les gens font surtout de la VoIP pour WoW, un peu pour téléphoner à leurs parents, et de temps en temps pour un entretient d'embauche. Quand aux téléchargements c'est très souvent illégal mais on a eu des cas où des gens ont eu un service trop lent pour télécharger un fichier qui était important pour leur stage. Mais encore une fois, j'aimerais ne pas parler de ce problème en particulier. Plutôt, je viens ici pour savoir si quelqu'un voit une utilité ou une cohérence quelconque à un outil capable de comprendre le HTTP et les protocoles qui y circulent à l'intérieur, dans le but principal de faire de la QoS ? (et pourquoi pas bloquer les tunnels, bien que sur ce point je pense que la réponse soit assez claire). -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 16:59:47 +0100, Rémi Bouhl remibo...@gmail.com wrote: Je plussoie l'idée. Inutile d'aller chercher au niveau de la couche 7 ce que les gens font vraiment (et, à tout prendre, ce n'est pas à l'admin de décider de ce qui est prioritaire, même en faisant preuve de bon sens). Une répartition équitable en garantissant un minimum à chaque utilisateur, et le tour est joué :) Mes utilisateurs vont être content avec leur 100kbps par personne tiens :) Je ne parle pas de décider que tel ou tel site soit plus important, mais on a bien inventé la QoS pour une raison non ? Par exemple, pour que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Bon maintenant si la VoIP et le gros fichier passent tous les deux par le HTTP, tu fais quoi ? Kif kif comme si y'avait pas de QoS ? C'est malheureux mais beaucoup de protocoles convergent vers le HTTP. Je veux pouvoir les distinguer pour avoir une qualité de service appropriée. Pas décider que les films de cul de Bob valent plus que les séries à l'eau de rose d'Alice. -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] Firewall HTTP
Rémi Bouhl Du coup je propose la solution couillue: ouvrir les vannes sur les autres ports. Laisser sortir ce qui était encapsulé en HTTP, afin qu'HTTP redevienne ce qu'il n'aurait pas du cesser d'être. Oyez braves utilisateurs, vous pouvez sortir en SSH, en VPN et en RDP, inutile de faire des tunnels HTTP. +1 Chaque fois qu'on rajoute une couche, quelqu'un invente une bidouille pour la contourner. A force, pour accéder à sa propre bécane à quelques kilomètres on va se retrouver avec une usine à gaz qui consomme la moitié de la bande passante en encapsulations successives et envoie le trafic en Suède via le Srilanka. Michel --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 24/11/2010 17:23, Rémy Sanchez a écrit : Je ne parle pas de décider que tel ou tel site soit plus important, mais on a bien inventé la QoS pour une raison non ? Par exemple, pour que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Bon maintenant si la VoIP et le gros fichier passent tous les deux par le HTTP, tu fais quoi ? Kif kif comme si y'avait pas de QoS ? La vraie question, c'est de savoir pourquoi les utilisateurs de ton réseau utilisent de la VoIP sur HTTP. Si effectivement tu considère que la VoIP est importante au point de vouloir la prioriser par de la QoS, à ce compte là pourquoi ne pas ouvrir le port qui va bien pour qu'ils l'utilisent ? Je ne comprend vraiment pas la logique. C'est malheureux mais beaucoup de protocoles convergent vers le HTTP. Je veux pouvoir les distinguer pour avoir une qualité de service appropriée. Pas décider que les films de cul de Bob valent plus que les séries à l'eau de rose d'Alice. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAkztPSoACgkQ8IhKGszP0SozHgD9EnLaxGpOd0le57Blr0bTkWpC gsgjmLgr58jL9y4i0xIBAI1FHijZcULzsgoTWlKODhF1X//325Q7X5Mqxp+CRdoz =+JU6 -END PGP SIGNATURE- --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Le 24/11/10, Rémy Sanchezremy.sanc...@hyperthese.net a écrit : Je ne parle pas de décider que tel ou tel site soit plus important, mais on a bien inventé la QoS pour une raison non ? Par exemple, pour que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Bon maintenant si la VoIP et le gros fichier passent tous les deux par le HTTP, tu fais quoi ? Kif kif comme si y'avait pas de QoS ? Pas exactement. Tu garantis à Bob et Alice leurs 100 ko/s. Celui qui veut faire de la VoIP il coupe ou il ralentit son FTP/HTTP/Torrent/whatever, ou il fait de la QoS tout seul comme un grand (y'a des softs pour ça, y compris sous Windows). Et si ça l'amuse il freine sa VoIP pour échapper à une discussion chiante avec sa belle mère et il booste son DDL depuis Rapidshare parce qu'un couillon de son groupe de travail a pensé que c'était une bonne plateforme pour héberger un dossier sérieux. Rémi. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Salut, Je ne parle pas de décider que tel ou tel site soit plus important, mais on a bien inventé la QoS pour une raison non ? Par exemple, pour que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Ben ouais la QoS c'est pour ça, mais pas besoin de monter au niveau 7 pour garantir ça... Bon maintenant si la VoIP et le gros fichier passent tous les deux par le HTTP, tu fais quoi ? L'erreur est là : pourquoi tes utilisateurs font de la VOIP en HTTP ? Parler de Qualité de Service et VOIP over HTTP dans la même phrase c'est possible ??? Si l'utilisateur ne veut pas utiliser autre chose que HTTP, tant pis pour lui :-) C'est malheureux mais beaucoup de protocoles convergent vers le HTTP. Je veux pouvoir les distinguer pour avoir une qualité de service appropriée. T'as des exemples réels ? Parceque à part la VOIP que t'as ressorti plusieurs fois, c'est quoi ces fameux protocoles au dessus d'HTTP qui méritent tant d'attention ? Mehdi --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 08:25:14 -0800, Michel Py mic...@arneill-py.sacramento.ca.us wrote: Rémi Bouhl Du coup je propose la solution couillue: ouvrir les vannes sur les autres ports. Laisser sortir ce qui était encapsulé en HTTP, afin qu'HTTP redevienne ce qu'il n'aurait pas du cesser d'être. Oyez braves utilisateurs, vous pouvez sortir en SSH, en VPN et en RDP, inutile de faire des tunnels HTTP. +1 Chaque fois qu'on rajoute une couche, quelqu'un invente une bidouille pour la contourner. A force, pour accéder à sa propre bécane à quelques kilomètres on va se retrouver avec une usine à gaz qui consomme la moitié de la bande passante en encapsulations successives et envoie le trafic en Suède via le Srilanka. +1 aussi J'suis le premier à vouloir faire ce que je veux du réseau. Et le premier à faire des tunnels. J'ai compris que le blocage des tunnels, c'est une mauvaise idée, et en fait c'est pas vraiment utile, donc sur ce point là c'est clair. Mais le fait est que là 95% du flux de données passe par du HTTP, et qu'on commence vraiment à avoir des types d'applications variées qui se distingues. Comme ce qu'on avait en TCP/UDP avant, mais remonté de quelques couches. J'y peux rien si Internet vire au n'importe quoi, mais j'ai envie de proposer des solutions pour garder un service de qualité :) . -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Le 24/11/2010 17:23, Rémy Sanchez a écrit : Mes utilisateurs vont être content avec leur 100kbps par personne tiens :) S'il utilisent tous le tuyau en même temps, c'est normal. Après c'est plus la taille du tuyau, le problème, pas la QoS. Je ne parle pas de décider que tel ou tel site soit plus important, mais on a bien inventé la QoS pour une raison non ? Par exemple, pour que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Bon maintenant si la VoIP et le gros fichier passent tous les deux par le HTTP, tu fais quoi ? Kif kif comme si y'avait pas de QoS ? Pourquoi passent-il par HTTP ? La VoIP en UDP/RTP est filtrée sur ton réseau ? -- Simon. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 2010-11-24 at 17:26 +0100, Simon Morvan wrote: Le 24/11/2010 17:23, Rémy Sanchez a écrit : Mes utilisateurs vont être content avec leur 100kbps par personne tiens :) S'il utilisent tous le tuyau en même temps, c'est normal. Après c'est plus la taille du tuyau, le problème, pas la QoS. comme je disais... tuyau trop petit, augmenter tuyau ;) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, November 24, 2010 16:59, Rémi Bouhl wrote: Le 24/11/10, David Ramahefasonr...@netfacile.net a écrit : Si ton problÚme est juste d'avoir assez de BP pour tous tout le temps, et non de savoir exactement ce que font tes usagers, qu'ils utilisent HTTP ou non, pourquoi ne pas mettre en place des rÚgles de Qos/Shaping qui brident le fou de Download quand il n'est pas tout seul sur les tuyaux et le laisse faire quand tout le monde dort ? Je plussoie l'idée. Inutile d'aller chercher au niveau de la couche 7 ce que les gens font vraiment (et, à tout prendre, ce n'est pas à l'admin de décider de ce qui est prioritaire, même en faisant preuve de bon sens). Une répartition équitable en garantissant un minimum à chaque utilisateur, et le tour est joué :) Virgin Media (câble opérateur UK) a un système différent qui me semble pas trop bête : pendant les périodes de forte activité réseau, la quantité de données échangée par utilisateur est comptabilisée et si un dépassement de quota est constaté (upload ou download), le débit est réduit pendant une durée de 12h. Tu regardes pas le contenu des paquets, tu regardes juste si l'utilisateur n'abuse pas au détriment des copains... http://shop.virginmedia.com/help/traffic-management/traffic-management-policy.html Rémi --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 2010-11-24 at 17:35 +0100, Stephen wrote: Virgin Media (câble opérateur UK) a un système différent qui me semble pas trop bête : pendant les périodes de forte activité réseau, la quantité de données échangée par utilisateur est comptabilisée et si un dépassement de quota est constaté (upload ou download), le débit est réduit pendant une durée de 12h. Tu regardes pas le contenu des paquets, tu regardes juste si l'utilisateur n'abuse pas au détriment des copains... l'art et la maniere d'éviter d'investir... va savoir ou vont les bénéfices ;) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 17:29:37 +0100, Mehdi AMINI joker@gmail.com wrote: Salut, Je ne parle pas de décider que tel ou tel site soit plus important, mais on a bien inventé la QoS pour une raison non ? Par exemple, pour que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Ben ouais la QoS c'est pour ça, mais pas besoin de monter au niveau 7 pour garantir ça... Bon maintenant si la VoIP et le gros fichier passent tous les deux par le HTTP, tu fais quoi ? L'erreur est là : pourquoi tes utilisateurs font de la VOIP en HTTP ? Parler de Qualité de Service et VOIP over HTTP dans la même phrase c'est possible ??? Si l'utilisateur ne veut pas utiliser autre chose que HTTP, tant pis pour lui :-) C'est malheureux mais beaucoup de protocoles convergent vers le HTTP. Je veux pouvoir les distinguer pour avoir une qualité de service appropriée. T'as des exemples réels ? Parceque à part la VOIP que t'as ressorti plusieurs fois, c'est quoi ces fameux protocoles au dessus d'HTTP qui méritent tant d'attention ? Ok j'avoue la VoIP c'était assez extrême, et y'a pas grand monde qui fait ça (voire, personne (sauf Skype ? je sais plus)). De toute façon ça serait débile, on leur ouvre toujours les ports de leur TS aux utilisateurs :) Pour moi, y'a plusieurs familles de (plus ou moins) protocoles qui émergent : * Le bon vieux HTTP standard, avec téléchargement de petits fichiers un par un. * Le HTTP toujours standard, mais avec du téléchargement de gros fichiers avec potentiellement des abus à l'aide d'accélérateurs de téléchargements. * Les protocoles internes aux applications, avec des micro-requêtes en Ajax. * Les long poll, comet et autres techniques de PUSH HTTP. En somme, pourquoi l'accès à un traitement de texte en ligne devrait être traité avec la même priorité qu'un téléchargement de masse ? Ce sont deux services totalement différents, avec des besoins totalement différents aussi. De la même manière qu'on va faire passer le SSH avant le FTP, la communication évènementielle de la dernière appli à la mode devrait passer avant un téléchargement sur megaupload. Pour répondre en diagonale aux autres messages : oui les utilisateurs qui font tout passer en HTTP sont débiles, mais en fait c'est le cas de n'importe qui surfant sur le web. C'est largement suboptimal, mais tout tend à tourner dans le navigateur. Et encore une fois je ne dis pas que c'est impossible à gérer avec ce qui existe (variante: oui il y a des solutions à mes problèmes, et oui je les utilises). Je suggère juste la création d'un outil adapté, qui au lieu de demander des heures à concevoir et tuner une config, permettra d'avoir une config par défaut qui marche directement, sans avoir à détourner les fonctionalités du logiciel. J'veux dire par là, oui on peut faire un proxy avec nfqueue, bash, wget, rsync et 2 ou 3 autres, mais c'est carrément pas aussi adapté que Squid. Je veux différencier les flux HTTP, mais Squid n'est pas adapté pour ça. -- Rémy Sanchez --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Le 24 novembre 2010 17:15, Rémy Sanchez remy.sanc...@hyperthese.net a écrit : Mais encore une fois, j'aimerais ne pas parler de ce problème en particulier. Plutôt, je viens ici pour savoir si quelqu'un voit une utilité ou une cohérence quelconque à un outil capable de comprendre le HTTP et les protocoles qui y circulent à l'intérieur, dans le but principal de faire de la QoS ? (et pourquoi pas bloquer les tunnels, bien que sur ce point je pense que la réponse soit assez claire). L'utilité/besoin est sans doute là vue que des produits commerciaux existent depuis longtemps pour celà: Bluequote / Allott par exemple (comme dit plus haut). Après je ne sais pas si c'est la cohérence qu'il faut chercher mais plutôt des besoins commerciaux et/ou sécuritaires plus que le manque de BP car comme dit plus haut cette ressource n'est souvent plus un problème. Dans une ancienne vie on utilisait ce genre de boites pour facturer nos clients hébergés en ferme, j'ai aussi travaillé pour un opérateur sur une archi à base d'allot pour limiter tout ce qui relevait du traffic P2PCo dès que le trafic n'était pas on-net. Dans les deux cas il n'a jamais été question de regarder ce qui était échangé. Le blocage de tel ou tel protocole ensuite relève de ta politique de sécurité, qui de ce que je comprend diffèrerait dans ce cas de celle d'un FAI/Opérateur (pour l'instant, quoique :)) -- David Ramahefason r...@netfacile.net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 16:26:22 +0100, Rémy Sanchez remy.sanc...@hyperthese.net said: Le constat est que tout passe dans un énorme tuyau qu'est le HTTP et que peut être qu'il faudrait y mettre plus de contrôle à l'intérieur, avec des nouveaux outils plus adaptés que ce qu'on a aujourd'hui. Pourquoi ? On a pas encore appris les lecons du controle au nieveaux 3 et 4 ? Faut imperativement faire les memes erreurs au niveau 7 ? -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] Firewall HTTP
Radu-Adrian Feurdean a écrit: et certains elus moins cons contre cette loi. A rajouter dans la lettre au Père Noël, définitivement. Des politiciens moins cons que leurs prédécesseurs! :-D Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 17:23:37 +0100, Rémy Sanchez remy.sanc...@hyperthese.net said: que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Bon maintenant si la VoIP et le gros fichier passent tous les deux par le Ca ca marche en entreprise, ou la prioritisation de tel ou tel protocole/destination/ se fait sur decision venue d'en haut (peu importe l'impact sur les utilisateurs). Quand la connectivite est un service offert (contre $$$ ou non), le contenu des paquets que tu tranpostes n'est plus ton probleme. Ton boulot dois s'arreter au plus proche du niveau 3. Je veux pouvoir les distinguer pour avoir une qualité de service appropriée. Pas décider que les films de cul de Bob valent plus que les séries à l'eau de rose d'Alice. Mais c'est exactement ce que tu demandes. Tu veux faire de la qualite de service, fais-la par client. En effet c'est ca la neutralite -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 17:25:44 +0100, Rémy Sanchez remy.sanc...@hyperthese.net said: Attention piège : on a un proxy donc c'est uniquement lui que la passerelle va voir. Et limiter le nombre de connexions par IP au niveau du proxy c'est pas possible à cause des long polls précédemment évoqués. Tu peux aussi revoir legerement ton architecture. -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 17:33:16 +0100, Rémy Sanchez remy.sanc...@hyperthese.net said: Mais le fait est que là 95% du flux de données passe par du HTTP, et qu'on commence vraiment à avoir des types d'applications variées qui se distingues. Comme ce qu'on avait en TCP/UDP avant, mais remonté de quelques couches. J'y peux rien si Internet vire au n'importe quoi, mais j'ai envie de proposer des solutions pour garder un service de qualité Pour la n-ieme fois, le rappel (en anglais cette fois): We're network admins. To us, data is just a protocol-overhead. Oublie tout ce qui depasse le niveau 3 !!! Tu peux encore faire du QoS nu niveau 3, faut juste revoir ton facon de voir les choses. -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On 11/24/2010 07:04 PM, Radu-Adrian Feurdean wrote: Pourquoi ? Pour qu'un service qui a besoin d'une bonne réactivité mais de peu de débit ne soit pas pénalisé par un service qui se fiche de la réactivité mais mange du débit à fond ? On a pas encore appris les lecons du controle au nieveaux 3 et 4 ? Faut imperativement faire les memes erreurs au niveau 7 ? Pas moi en tout cas, quelles sont-elles ? On m'a toujours vendu la QoS en disant que c'est trop cool, mais je suis curieux d'entendre des contre-arguments. -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Firewall HTTP
On 11/24/2010 07:19 PM, Radu-Adrian Feurdean wrote: Tu peux aussi revoir legerement ton architecture. Tu suggères ? -- Rémy Sanchez http://hyperthese.net signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Firewall HTTP
On 11/24/2010 07:26 PM, Radu-Adrian Feurdean wrote: Pour la n-ieme fois, le rappel (en anglais cette fois): We're network admins. To us, data is just a protocol-overhead. Oublie tout ce qui depasse le niveau 3 !!! Tu peux encore faire du QoS nu niveau 3, faut juste revoir ton facon de voir les choses. Moi j'veux bien faire du DiffServ, mais à un moment faut qu'on me mette les champs à la bonne valeur. À ma connaissance, les navigateurs ne savent pas faire ça, et il n'existe pas d'outil (libre, vu que dans le commerce ça a l'air d'exister) pour différencier facilement les flux assez finement. D'où le problème initial de coder une application capable de faire de la QoS là dessus (ça peut juste vouloir dire qu'on met le DSCP à la bonne valeur). -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Firewall HTTP
2010/11/24 Rémy Sanchez remy.sanc...@hyperthese.net: Moi j'veux bien faire du DiffServ, mais à un moment faut qu'on me mette les champs à la bonne valeur. À ma connaissance, les navigateurs ne savent pas faire ça, et il n'existe pas d'outil (libre, vu que dans le commerce ça a l'air d'exister) pour différencier facilement les flux assez finement. D'où le problème initial de coder une application capable de faire de la QoS là dessus (ça peut juste vouloir dire qu'on met le DSCP à la bonne valeur). Je me permets de répondre parce que je connais particulièrement bien la résidence dont tu parles ;) Tout ce que tu penses être tes problèmes sont des non-problèmes. Par contre, tu en as un vrai de problème : TU MANQUES DE BANDE PASSANTE. Tu te plains que tout le monde peut faire ce qu'il veut dans HTTP ? Ouvre avec modération le trafic que tu souhaites ne plus voir passer dans du HTTP... euh... mais je crois savoir que c'est déjà ce que tu fais actuellement... Tu te plains que tout le monde peut mettre tout ce qu'il veut dans HTTP donc il faudrait un outil top cool moumoutte pour filtrer (et faire je ne sais quels calculs magiques dont toi même tu ne sais expliquer, pour catégoriser les services qui passent dans HTTP) ? Et tu feras quoi quand un mec utilisera son propre outil non connu par l'outil top cool moumoutte, pour faire un VPN qui mettra son flux dans des balises normales HTML, ressemblant à du contenu normal... et que ce mec pompera l'intégralité de la bande passante... Tu n'es pas satisfait de squid ? De toute façon votre histoire de proxy ce n'est que du bullshit. Vous maintenez des stats sur l'utilisation du cache de votre proxy ? Vous avez des stats réels de l'utilisation avec/sans proxy à la longue ? Avec le *profil* de tes utilisateurs, le proxy sera inutile pour plusieurs raisons : - Sur facebook/youtube/WTF, les utilisateurs ne consultent que ce qui les intéressent eux, - De très nombreux sites ont une politique de cache ultra restrictive, - HTTPS ? Le cache... aujourd'hui il est dans le navigateur. Mis à part l'image du jour google et quelques conneries, le proxy ne sert à rien. La QoS (celle que tu entends) n'existe pas ? Eh oui... bienvenue dans le monde réel. Ta QoS tu la fait sur du niveau 3/4. Pour en faire dans HTTP, voir le cas d'utilisation d'un outil inconnu, top cool moumoutte, qui fait du VPN. Je vais encore le répéter, tu as un problème : la bande passante. Quelles que soient les bidouilles que tu arriveras à trouver, on reviendra au même problème initiale. Tu veux résoudre tes problèmes : UPGRADE. Enfin... comme le disent les autres réponses précédentes, ta tâche elle s'arrête au niveau 3/4. Au dessus, les utilisateurs font ce qu'ils veulent (et si ce n'est pas le cas, ils trouveront de toute façon une manière de faire ce qu'ils veulent). Tu as des abus réguliers ? Tu souhaites t'en débarrasser ? 1 C'est ton boulot quotidien d'admin. 2 A toi d'éduquer (aussi durement que tu le souhaites) les utilisateurs pour plus que ça ne se reproduise. 3 Un réseau en pilote automatique, je n'ai pas encore sorti ma boule de cristal, mais je te mets au défi de le trouver. -- Mattieu Baptiste /earth is 102% full ... please delete anyone you can. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Le 24/11/2010 17:47, Raphaël Jacquot a écrit : On Wed, 2010-11-24 at 17:35 +0100, Stephen wrote: Virgin Media (câble opérateur UK) a un système différent qui me semble pas trop bête : pendant les périodes de forte activité réseau, la quantité de données échangée par utilisateur est comptabilisée et si un dépassement de quota est constaté (upload ou download), le débit est réduit pendant une durée de 12h. Tu regardes pas le contenu des paquets, tu regardes juste si l'utilisateur n'abuse pas au détriment des copains... l'art et la maniere d'éviter d'investir... va savoir ou vont les bénéfices ;) Dans la poche des actionnaires pardi... Cdt, -- Pascal, --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Salut Rémy, (...) Le 24 nov. 2010 à 17:56, Rémy Sanchez a écrit : En somme, pourquoi l'accès à un traitement de texte en ligne devrait être traité avec la même priorité qu'un téléchargement de masse ? Ce sont deux services totalement différents, avec des besoins totalement différents aussi. De la même manière qu'on va faire passer le SSH avant le FTP, la communication évènementielle de la dernière appli à la mode devrait passer avant un téléchargement sur megaupload. Moi pour le téléchargements de masse j'avais réglé (enfin j'avais) le pb autrement : répertoire /tmpfs de l'antivirus faisais 50M... tout téléchargement a 50Mo devais passer par les admin... C'étais une règle... pratique... :) Pour répondre en diagonale aux autres messages : oui les utilisateurs qui font tout passer en HTTP sont débiles, mais en fait c'est le cas de n'importe qui surfant sur le web. C'est largement suboptimal, mais tout tend à tourner dans le navigateur. C'est sûr.. Je vais te donner un exemple, dans le cadre de mon taf j'ai un KVM IP qui lance un Java... Pas de pb... Sauf que ce truc passe par VNC... Evidement bloqué par des gens paranoïaques qui bloquent absolument tout ce qui sort y compris icmp (et pan pmtud - dtc, je parle pas non plus de l'IPv6 qui ne sera jamais prêt de fonctionner chez eux mais tant pis). Résultat on avais commencé de faire des trucs avec des bidouilles genre novnc par exemple... On a laissé tomber car il faillais une usine a gaz et un centrale de calcul pour couper le protocole VNC en morceaux de HTTP. Résultat... encore une encapsulation de merde de plus a gérer pour les firewall corporate gérés par des gens pour qui TCP/IP se résume au minitel... (ok je vais loin, mais..). Et encore une fois je ne dis pas que c'est impossible à gérer avec ce qui existe (variante: oui il y a des solutions à mes problèmes, et oui je les utilises). Je suggère juste la création d'un outil adapté, qui au lieu de demander des heures à concevoir et tuner une config, permettra d'avoir une config par défaut qui marche directement, sans avoir à détourner les fonctionalités du logiciel. J'veux dire par là, oui on peut faire un proxy avec nfqueue, bash, wget, rsync et 2 ou 3 autres, mais c'est carrément pas aussi adapté que Squid. Je veux différencier les flux HTTP, mais Squid n'est pas adapté pour ça. Y a un truc que tu peux faire avec squid c'est différencier les objets courts (ajax / traitement de texte / chat [ok je sors]) et les téléchargements lourds... Bon c'est du tweak de conf mais ça se fait. /Xavier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On 11/24/2010 09:05 PM, Mattieu Baptiste wrote: 2010/11/24 Rémy Sanchez remy.sanc...@hyperthese.net: Moi j'veux bien faire du DiffServ, mais à un moment faut qu'on me mette les champs à la bonne valeur. À ma connaissance, les navigateurs ne savent pas faire ça, et il n'existe pas d'outil (libre, vu que dans le commerce ça a l'air d'exister) pour différencier facilement les flux assez finement. D'où le problème initial de coder une application capable de faire de la QoS là dessus (ça peut juste vouloir dire qu'on met le DSCP à la bonne valeur). Je me permets de répondre parce que je connais particulièrement bien la résidence dont tu parles ;) Tout ce que tu penses être tes problèmes sont des non-problèmes. Par contre, tu en as un vrai de problème : TU MANQUES DE BANDE PASSANTE. Tu te plains que tout le monde peut faire ce qu'il veut dans HTTP ? Ouvre avec modération le trafic que tu souhaites ne plus voir passer dans du HTTP... euh... mais je crois savoir que c'est déjà ce que tu fais actuellement... Tu te plains que tout le monde peut mettre tout ce qu'il veut dans HTTP donc il faudrait un outil top cool moumoutte pour filtrer (et faire je ne sais quels calculs magiques dont toi même tu ne sais expliquer, pour catégoriser les services qui passent dans HTTP) ? Et tu feras quoi quand un mec utilisera son propre outil non connu par l'outil top cool moumoutte, pour faire un VPN qui mettra son flux dans des balises normales HTML, ressemblant à du contenu normal... et que ce mec pompera l'intégralité de la bande passante... Tu n'es pas satisfait de squid ? De toute façon votre histoire de proxy ce n'est que du bullshit. Vous maintenez des stats sur l'utilisation du cache de votre proxy ? Vous avez des stats réels de l'utilisation avec/sans proxy à la longue ? Avec le *profil* de tes utilisateurs, le proxy sera inutile pour plusieurs raisons : - Sur facebook/youtube/WTF, les utilisateurs ne consultent que ce qui les intéressent eux, - De très nombreux sites ont une politique de cache ultra restrictive, - HTTPS ? Le cache... aujourd'hui il est dans le navigateur. Mis à part l'image du jour google et quelques conneries, le proxy ne sert à rien. La QoS (celle que tu entends) n'existe pas ? Eh oui... bienvenue dans le monde réel. Ta QoS tu la fait sur du niveau 3/4. Pour en faire dans HTTP, voir le cas d'utilisation d'un outil inconnu, top cool moumoutte, qui fait du VPN. Je vais encore le répéter, tu as un problème : la bande passante. Quelles que soient les bidouilles que tu arriveras à trouver, on reviendra au même problème initiale. Tu veux résoudre tes problèmes : UPGRADE. Enfin... comme le disent les autres réponses précédentes, ta tâche elle s'arrête au niveau 3/4. Au dessus, les utilisateurs font ce qu'ils veulent (et si ce n'est pas le cas, ils trouveront de toute façon une manière de faire ce qu'ils veulent). Tu as des abus réguliers ? Tu souhaites t'en débarrasser ? 1 C'est ton boulot quotidien d'admin. 2 A toi d'éduquer (aussi durement que tu le souhaites) les utilisateurs pour plus que ça ne se reproduise. 3 Un réseau en pilote automatique, je n'ai pas encore sorti ma boule de cristal, mais je te mets au défi de le trouver. Je voulais justement pas ramener la résidence en question sur le tapis par ce que je sais très bien que les problèmes viennent de la bande passante, et tu sais comme moi à quel point on n'a pas de budget. Donc c'est un peu une impasse. Quand à éduquer les utilisateurs... Déjà ils lisent pas les papiers/mails qu'on leur donne aussi court soient-ils, et en plus ils changent tous les ans. M'enfin, c'est pas le problème, ce troll là on l'a déjà assez souvent pour éviter de le ramener ici. La question était bel et bien générique, à savoir est-ce qu'un tel logiciel peut être intéressant dans un nombre suffisant de cas ? Je me demande si, étant donné que la quasi exclusivité du trafic est du HTTP, est-ce que ça a du sens d'essayer de le considérer administrativement comme un protocole de transport ? Bon et finalement, est-ce que la QoS sert à quelquechose ? Par ce que si on résume, la QoS ne sert à rien quand on a assez de bande passante, et elle n'est pas assez efficace quand y'a pas assez de bande passante... -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Firewall HTTP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bonjour, Le 24/11/2010 19:39, Rémy Sanchez a écrit : On 11/24/2010 07:04 PM, Radu-Adrian Feurdean wrote: Pourquoi ? Pour qu'un service qui a besoin d'une bonne réactivité mais de peu de débit ne soit pas pénalisé par un service qui se fiche de la réactivité mais mange du débit à fond ? Simple : faire une réservation de BP par utilisateur/@IP. Le reste de BP étant mangée par qui veut/en a besoin. (Faut peut être mettre les mains dans le cambouis pour y arriver) On a pas encore appris les leçons du contrôle au niveaux 3 et 4 ? Faut impérativement faire les mêmes erreurs au niveau 7 ? Pas moi en tout cas, quelles sont-elles ? - - Que c'est aux applications elles même et au système final de faire ce contrôle de flux - - Que gérer les contrôles de flux en cœur de réseau provoquait des effets de bords non désirés (oscillations de trafic sur des liens identiques, latence inexpliquée, On m'a toujours vendu la QoS en disant que c'est trop cool, mais je suis curieux d'entendre des contre-arguments. De mon coté, on m'a appris que la QoS c'est trouver une règle pour dropper/ralentir des paquets suivant une règle définie par l'admin. Et donc que les marchands de contenus trouvaient ça bien car c'est leur(s) service qui est mis en valeur (au détriment d'autres services forcément). Le souci majeur avec la QoS dans les grands système est la diversité des utilisateurs. Tous n'ont pas les mêmes besoins. Untel a besoin de ses résultats de simulation sur le calculateur de la boîte (Big file), tel autre a besoin de récupérer les tonnes de PDF de ses mails. Un autre encore va passer ses journées à balancer/récupérer des chaines de mails avec la dernière blagounette. On peut même envisager une équipe de développeurs qui publieraient leurs applications en torrent pour limiter la BP. Dis autrement, les protocoles ne sont pas représentatif de l'usage, ni des attentes de l'utilisateur, et encore moins de leurs besoins. Accessoirement, gérer de la QoS sur des tunnels encapsulés dans du HTTP, risque de rapidement transformer le réseau en un champ de bataille avec d'un coté le(s) gens qui veulent filtrer et les utilisateurs qui *contourneront* le système de filtrage. (Toute ressemblance avec une loi finissant par I relève du hasard) Jean-Pierre -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkztiMcACgkQcPNeJG1THnNoMwCglYBRUBjMEfTicRsKjVekP10X W8sAoJDHDDiXA/l03FRkF/EenicG2mj4 =G5XX -END PGP SIGNATURE- --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez remy.sanc...@hyperthese.net said: par ce que je sais très bien que les problèmes viennent de la bande passante, et tu sais comme moi à quel point on n'a pas de budget. Donc T'as un probleme de bande passante, t'as de utilisateurs qui veulent de la bande passant ? 1. Augmente tes prix 2. Cree des services premium, plus chers, pour ceux qui veulent plus, qui te permettent de financer ta bande passante Et enfin, la BP est chere uniquement sur la boucle locale. Des que tu arrives dans un DC, ca coute presque rien (si jamais t'as encore de probleme en DC, tu prononce le mot magique Cogent et tout le monde rentre dans les rangs). -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On 11/24/2010 11:05 PM, Radu-Adrian Feurdean wrote: On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez remy.sanc...@hyperthese.net said: par ce que je sais très bien que les problèmes viennent de la bande passante, et tu sais comme moi à quel point on n'a pas de budget. Donc T'as un probleme de bande passante, t'as de utilisateurs qui veulent de la bande passant ? 1. Augmente tes prix 2. Cree des services premium, plus chers, pour ceux qui veulent plus, qui te permettent de financer ta bande passante Et enfin, la BP est chere uniquement sur la boucle locale. Des que tu arrives dans un DC, ca coute presque rien (si jamais t'as encore de probleme en DC, tu prononce le mot magique Cogent et tout le monde rentre dans les rangs). On étudie la liaison IPoAC pour arriver au point de présence de Cogent le plus proche :) Y'a pas moyen d'avoir un centime de budget supplémentaire, pour l'instant on est bien parti pour rester sur le modèle actuel (y compris la facturation etc). C'est vraiment une petite échelle (~150 étudiants), donc rien de trop faisable à ce niveau. Mais s'il vous plaît, est-ce qu'on pourrait arrêter de parler de cette résidence ? Même si c'est un problème rencontré là bas qui m'a poussé à me poser la question, le but du jeu n'était pas de trouver un moyen magique de faire rentrer plus de choses dans le même tuyau. C'était juste une interrogation générique, que j'ai formulé et re-formulé 1 mail sur 2, donc je vais éviter de le refaire ici. En tout cas, merci à tous pour vos réponses :) -- Rémy Sanchez signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Firewall HTTP
Le 24 novembre 2010 23:19, Rémy Sanchez remy.sanc...@hyperthese.net a écrit : Mais s'il vous plaît, est-ce qu'on pourrait arrêter de parler de cette résidence ? Même si c'est un problème rencontré là bas qui m'a poussé à me poser la question, le but du jeu n'était pas de trouver un moyen magique de faire rentrer plus de choses dans le même tuyau. C'était juste une interrogation générique, que j'ai formulé et re-formulé 1 mail sur 2, donc je vais éviter de le refaire ici. Je ne te comprend pas trop tu expose un problème précis mais tu ne veux pas qu'on se focalise dessus. Tu voulais discuter de quoi exactement ?? Savoir s'il était possible de faire de la classification de paquets en L7 ?? La réponse est oui, cela existe depuis plus de dix ans (Packeteer / Allot et sans doute des solutions Open Source). Sinon tu as a ta disposition tout plein de tricks pour jouer avec la Qos sur tes équipements et la solution à la Virgin me semble est la plus intéressante pour toi. -- David Ramahefason r...@netfacile.net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
Le 25/11/10, Rémy Sanchezremy.sanc...@hyperthese.net a écrit : J'ai enfin réussi à bien expliquer ma question ? J'peux recommencer sinon j'suis plus à ça près -_- Tout le monde a compris le problème (plein de gens, font des trucs très différents en HTTP, pas assez de BP pour tous). C'est juste que la solution fouiller au niveau 7 n'a pas l'air d'être la seule réponse, ni même la meilleure. L'idée plusieurs fois évoquée de partager la BP équitablement (pour être précis: de garantir un minimum à chaque utilisateur, en toutes circonstances) est plus simple à mettre en place, plus propre éthiquement et techniquement, et garantit en toutes circonstances un équilibre entre les usages. Pourquoi ne pas l'envisager? Rémi. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On 25/11/10 00:04, Rémy Sanchez wrote: snip La question porte donc sur les capacités des logiciels actuels en L7 : sont-ils capable de différencier les différentes applications et de prendre en compte leurs spécificités ? J'ai vu quelques produits capables de différencier les parties messageries, photos et chat d'un réseau social bien connu. Idem pour les wikis : différenciations entre consultation et édition. Une autre fonction intéressante, était de prioriser les différentes requêtes HTTP, en fonction du contenu (js, image, gros paquets / petits paquets). Est-ce que çà a une utilité ? Pour ma boîte probablement pas, on doit probablement réserver une certaine quantité de bande passante pour quelques sites publics très utilisé et pros (genre pagesjaunes). Les flux métiers passent à coté sur des liaisons dédiées. Le problème qu'il peut éventuellement se poser, c'est le SSL. Mais là encore, on peut très bien terminer le flux sur un boitier puis resigner pour l'utilisateur. Dans une entreprise, c'est potentiellement assez simple puis qu'il y a une charte d'utilisation, on peut même envisager des exceptions (consultation à la CPAM, banque ...). -- Antoine Musso --- Liste de diffusion du FRnOG http://www.frnog.org/
