Re: [FRnOG] [MISC] Problème de communication TCP/IP avec Free mobile
Bonjour à tous, Nous arrivons à reproduire avec un autre serveur (sur un réseau différent, un AS différent, etc), toujours avec free mobile. On dirait en effet qu'un équipement coté free mobile retravaille la couche TCP/IP. Cet équipement semble ne s'activer que sur le useragent d'un mobile, ce qui semblerait expliquer qu'on ait pas le soucis en tethering. Peut être un équipement de compression des flux, je ne sais pas. En tout cas, cela est assez génant (serveurs inaccessibles) et je ne vois pas comment résoudre ceci de notre coté. On va tenter de travailler directement avec free mobile pour trouver une solution. On vous tient au courant. Merci à tous pour vos réponses in et off liste. Bon week-end. :) Le 22 août 2013 21:00, Leslie-Alexandre DENIS m...@ladenis.fr a écrit : Tous les binaries (tcpdump-arm...) nécessaires sont disponibles pour les puces ARM (sous Android). Autant se mettre au plus proche du problème non ? Un audit sur le téléphone permettrait probablement de connaître la source. Le 22/08/2013 20:13, Silvère DENIS a écrit : Pourquoi pas tester depuis un ordi en se faisant passer pour un mobile pour vérifier l'origine du pb? --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] RFC 6984: Interoperability Report for ForCES
http://www.bortzmeyer.org/6984.html Auteur(s) du RFC: W. Wang (Zhejiang Gongshang University), K. Ogawa (NTT Corporation), E.H. Haleplidis (University of Patras), M. Gao (Hangzhou BAUD Networks), J. Hadi Salim (Mojatatu Networks) Un élément essentiel de la culture IETF est l'importance donnée aux programmes qui marchent : rough consensus and running code. D'où les fréquents tests d'*interopérabilité*, entre diverses mises en œuvre des protocoles IETF, afin de vérifier que, non seulement le code tourne mais qu'il peut interagir avec d'autres instances. Le groupe de travail ForCES http://tools.ietf.org/wg/forces, qui normalise des protocoles de communication *internes* aux routeurs, a ainsi procédé à deux ateliers de tests d'interopérabilité, ce RFC documentant le second. Le premier avait eu lieu en 2009 à l'université de Patras et avait été documenté dans le RFC 6053. Le second a eu lieu en février 2011 à l'ITL (Internet Technology Lab) à l'université de Zhejiang Gongshang. (Oui, je sais, c'est long, entre l'atelier et la publication du compte-rendu dans un RFC...) Rappelons ce que fait ForCES : il normalise la communication entre les éléments d'un routeur (ou autre engin du réseau : la norme parle de *NE* pour Network Element). Le but est de permettra la construction de routeurs en kit, en assemblant des parties d'origines différentes, mais parlant toutes ForCES. Le système ForCES est riche et complexe et cet atelier d'interopérabilité testait cinq composants : le protocole de communication entre *CE* (Control Element) et *FE* (Forwarding Element), normalisé dans le RFC 5810, le protocole de transport sous-jacent (RFC 5811), le modèle des FE (RFC 5812), la bibliothèque standard (RFC 6956) et le mécanisme de haute disponibilité (dont le RFC n'a pas encore été publié). Des CE et FE d'origines diverses ont été connectés entre eux, se sont parlé, la bonne compréhension a été vérifiée et tcpdump et Wireshark ont été utilisés pour un contrôle supplémentaire. Trois mises en œuvre de ForCES ont été testées, les mêmes qu'à l'atelier précédent (ForCES n'a pas pour l'instant suscité un intérêt massif) : celle de NTT, celle de l'université de Patras, et celle faite en commun entre l'université de Zhejiang Gongshang et la société BAUD Network. Les grecs n'ayant pu se déplacer, ils ont participé aux tests à distance, connectés via un VPN (dans la réalité, bien sûr, les FE et les CE seront toujours proches, souvent dans le même boîtier physique). Globalement, les tests ont été des succès, à part un problème embêtant avec l'encapsulation des données dans une réponse ForCES (voir les détails plus loin). Comme toujours, ces tests ont permis de découvrir des erreurs ou des approximations dans les RFC. Les communications utilisaient IPsec, puisque le RFC sur le transport de ForCES, RFC 5811, fait obligation à chaque mise en œuvre de ForCES d'avoir IPsec (mais pas forcément de l'activer par défaut : c'est sa disponibilité qui est obligatoire, pas son usage). Un exemple d'un des scénarios testés (section 3.4) : deux machines terminales sur deux réseaux locaux différents étaient connectées via deux routeurs OSPF. L'un était un routeur classique, l'autre une machine ForCES dont le CE (Control Element) parlait OSPF avec le routeur classique pendant que le FE (Forwarding Element) transmettait les paquets. Ce scénario nécessitait que le CE communique au FE les règles qu'il avait apprises en OSPF et testait la mise en œuvre correcte de plusieurs fonctions du RFC 6956. Une variante de ce test remplaçait le routeur classique par une autre machine ForCES : les deux CE se parlaient en OSPF et chacun disait ensuite à son FE ce qu'il devait faire des paquets IP. La section 4 donne les résultats complets des tests. Il y a une très grande majorité de succès mais aussi deux échecs, qui vont nécessiter du travail chez les programmeurs. Mais le principal problème de l'atelier a été un problème lors de la communication de tableaux (et pas de simples valeurs scalaires) entre deux programmes. Le problème est que ForCES permet plusieurs encodages possibles pour les données complexes (RFC 5810, section 6 et notamment 6.4). La règle est que chaque élément ForCES peut choisir librement parmi ces encodages (pas moins de trois possibilités légales, dans l'exemple discuté dans la section 5 de notre RFC). Mais un programme considérait que la réponse venait forcément dans l'encodage de la question, et plantait si ce n'était pas le cas. Bien qu'il soit clairement en tort, notre RFC considère qu'il vaut mieux en effet générer une réponse en utilisant le même encodage que la question ou la commande. Personnellement, je pense plutôt que c'était très gentil de donner un vaste choix aux CE et FE (par exemple pour optimiser le cas de grands tableaux ayant beaucoup de vide) mais que cela mène forcément à ce genre de problèmes.
Re: [BIZ] Logiciels de chiffrement pour stocker des mots de passe (was [FRnOG] [BIZ] OVH - incident de sécurité)
Bonjour Florent , C'est exactement ce qu'il me faut je vais le tester et te fera un retour off ou on liste . Merci Cordialement, Le lundi 19 août 2013, Florent Cottey a écrit : Salut Mikael, le logiciel SecretManager doit correspondre à tous tes besoin : http://sourceforge.net/projects/secretmanager/ Il est développé par un consultant en sécurité français qui en avait marre de voir ses clients gérer les mots de passe n'importe comment et qui ne trouvait pas de solution propre, alors il a fait son logiciel. Ce n'est pas un bastion type wallix donc l'admin aura le mot de passe et pourra l'écrire sur un papier s'il le souhaite... mais c'est déjà pas mal. Cordialement, Florent -- Mikael LELOUCH --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Au bord du suicide
Bonsoir, Bon, on est pas vendredi, mais je souhaitais faire un petit update de ce topicavant FRnOG 21. Pour information, nous avons reçu de l'aide, de la part de certains membres du FRnOG, qui ont fait preuve de beaucoup d'altruisme. Je les remercie chaleureusement pour leur dévouement, cette période sombre est pour l'instant stabilisée, et c'est grâce à la communautée du FRnOG(et à notre transitaire principal qui n'as plus beaucoup de cheveux et qui s'est démené pour nous aider). D'autres, plus enclin à la défaite ont bien entendu enfoncés le couteau, mais je n'en parlerais pas plusici (le beer event est là pour ça). La solution est multiple, je n'en indiquerais pas trop ici(ce n'est pas forcément le but), cependant, on m'as évoqué l'idée de présenter au prochain FRnOG l'historique et les solutions mises en place en dehors des hard/soft commerciaux existants, et je voudrais avant tout savoir si ce type de petite présentation (10mn) vous intéresse. C'est inscrit au planning mais je ne suis pas encore certain de la réaliser, étant très loin de prétendre à être aussi complet et précis techniquementque certains le souhaiterais. Des avis ? Cordialement, Jérémy Martin Le 18/06/2013 18:52, Jérémy Martin a écrit : Bonjour, Bon, je vais être pessimiste, mais je pense que ce message sera peut être un prélude à la mort annoncé d'un opérateur / hébergeur local qui essaye de tirer son épingle du jeu et qui le paye très cher. Nous sommes sous le coup d'attaques de type Amplification DNS, généralement supérieure à 2 Gb/s depuis plusieurs semaines. Et depuis cet après midi, c'est la farandole puisque c'est un /22 entier qui est visé avec une rotation aléatoire des IP cible. Aucune solution rapide à l'horizon, on parle bien d'upgrader sur du 10G Cogent mais ça va prendre du temps. Neo et Jaguar me proposent des solutions de Transit IP protégé via arbor avec tunnel GRE mais c'est relativement complexe à mettre en place, et surtout ça ne pourra se faire que sous 24/72h le temps de remuer tout le monde. Je suis au bord du suicide... Bonne nuit :( --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Ban d'IP par Google
Guido Pellizzari a écrit: Oui j'oubliais: au départ 90% des nos flux passaient par les proxies, tout comme avant que le ban se declenche. C'est là où a démarré notre analyse. Tes proxies sont le coupable le plus probable du ban initial, en effet. C'est ce que nous avons fait en premier, et qui n'a malheureusement rien mis en évidence. Nb de requêtes et volumes échangés sont uniformément répartis... Uniformément répartis venant de tes clients peut-être (ce qui veut donc dire que tu n'as pas de DDOS venant de dedans), mais en sortant? Google comme beaucoup d'autres fait du load-balancing par round-robin DNS qui varie dynamiquement en fonction de multiples facteurs. Name: www.google.fr Addresses: 74.125.239.159, 74.125.239.152, 74.125.239.151. Tu obtiens des résultats différents en fonction de là ou tu te trouves, de la charge, etc. As-tu vérifié que tes proxies utilisaient toutes les adresses que Google te donne, et que le cache DNS que tes proxies et tes clients utilisent est rafraîchi correctement? Si tu as plusieurs milliers de clients venant d'une seule IP et qui n'utilisent pour leurs requêtes qu'une seule des IP de Google et qu'elle ne change jamais, ça ressemble à du DDOS. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
