Re: [FRnOG] [MISC] Demande de contact hors-list ALTITUDE TELECOM
En fait il faut distinguer deux choses très différentes : A) la prestation de gestion des adresses PI B) la prestation de routage de ces adresses PI La prestation A correspond à un cadre juridique entre le RIPE, le client final (vous), et un LIR représentant le client final auprès du RIPE. Le RIPE oblige effectivement à avoir un tel cadre juridique et donc cette prestation. Il n'y a bien évidement aucune obligation de lier cette prestation avec celle de routage (la prestation B). Une erreur communément faite est justement de changer simultanément d'opérateur pour la prestation A et la prestation B. C'est généralement une grosse erreur car : - vous pouvez très bien router vos PI via plusieurs opérateurs (transitaires de niveau 1 ou +), n'ayant probablement aucun rapport avec le LIR dépositaire de la prestation A - le changement de prestataire oblige à la resignature d'une convention tri-partite et d'un changement de délégation sur la prestation A : paperasserie administrative et juridique assez inutile et perte de temps assurée - dans le cadre de la prestation A, le LIR a l'obligation de faire toute modification nécessaire demandées par le client, et donc il n'y a aucun obstacle à un changement ou une modification de routage ou de délégation des adresses inverses, ni aucune raison de lier cela à un autre cadre contactuel. En cas de mauvaise volonté du LIR, il vous faut remonter auprès du RIPE pour lui indiquer le dysfonctionnement (le cas échéant le RIPE est à même de faire les modifications en cas de conflit avec le LIR). Mes conseils : - ne changer pas de LIR pour la prestation A a chaque changement de routage, surtout que cette prestation doit normalement faire l'objet d'une facturation séparée et modique (100€/an ?) - si vous avez fait une demande de changement de LIR, rappeler au titulaire en cours qu'il a une obligation d'assurer cette prestation sans la lier à une autre et ce jusqu'à ce que le transfert soit effectif, et dans l'intervalle, il a l'obligation de faire les modifs nécessaires. A défaut vous avez la possibilité de vous plaindre auprès du RIPE. Cordialement, Alain RICHARD Le 29 févr. 2012 à 12:01, Julien BREVIERE a écrit : Bonjour, je me permet de polluer quelques instants, car je suis plutôt tombé des nues lorsque, quittant ALTITUDE TELECOM on m'affirme que pour récupérer mon bloc d'IP pourtant attribué en 'Provider Independant' (PI) je devrais attendre la résiliation effective (alors que le RIPE a le dossier depuis Janvier, et Altitude la demande émanant du RIPE depuis près de 10 jours) et que, je cite, les IPs redeviendront disponibles a la résiliation effective du service ... meme pour un nom de domaine on agit pas de la sorte il me semble .. je m'étonne donc de la réponse qui m'a été faite. D'une façon générale je suis interessé par tout retour d'expérience du meme type ... pour moi ce qui est logique c'est que cela puisse se passer exactement comme lorsque j'ai quitté mon opérateur précédent pour rejoindre Altitude, à savoir un transfert de gestion/routage/objet RIPE un peu avant la fin de la fin à l'opérateur entrant. PS: j'espere que j'ai bien visé pour [MISC] PPS: désolé si j'ai pollué .. je le referai probablement que dans plusieurs années donc inutile de modifier le reglement des la liste pour moi :) cordialement, -- *Julien BREVIERE* Direction des Services d'Information /Dufresne Corrigan Scarlett / Maison De La Communication 114, rue Chaptal - 92300 - Levallois-Perret/ Tel.:+33141054303 Fax:+33146170928 __ Checked by MailScanner : OK --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 Applications client/serveur, ingénierie réseau et Linux --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Un datacenter autonome en énergie
Les datacenters sont toujours montrés du doigt au niveau consommation et gaspillage énergétique. Mais en fait aujourd'hui la plupart des acteurs sérieux s'orientent vers la concentration des données (SANs) et la virtualisation non ? Un des effets immédiat au niveau des entreprises est donc la consolidation des données et des serveurs, ce qui permet facilement de diviser par 5 ou 10 le nombre de serveurs physiques, unités de sauvegardes et autres unités disques externes. Sans compter que cela permet de remplacer des machines de génération très énergivore par des machines plus récentes et plus raisonnables en conso (intel a cesser la course au GHz depuis plus de 3 ans maintenant, mai s il n'est pas rare de voir des serveurs de 5 à 10 ans d'âge en circulation). Pour les nuages grand public, cela doit être aussi le cas (par exemple faire du Dropbox au lieu d'utiliser un disque externe, voir même passer à la tablette au lieu du PC). Donc globalement les datacenters, même si ils consommes pratiquement autant pour refroidir que pour alimenter les CPUs, et produisent donc une grosse empreinte CO2, le bilan globale si on enlève l'équivalent de ce qu'ils remplacent doit donc bien être nettement positif non ? Bien évidement cela n'empêche pas de rechercher les énergies et/ou lieu les plus adaptés aux datacenters. On pourrait peut-être les mettre dans les hautes vallées alpines, là ou il est peut probable que la température extérieur dépasse les 25° au plus chaud de l'été et où l'électricité hydraulique revient moins cher tout en étant moins polluante à produire... A+ -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Carrier Grade NAT, nous y voilà
Oui, effectivement free active l'IPv6, mais ne donne aucun moyen à l'utilisateur de faire du firewalling ou de la sécurité de base (RFC6092). Etant donné que depuis 4 ans free n'avance pas sur ce sujet, un grand nombre d'utilisateurs conscients des enjeux de sécurité désactivent donc l'IPv6 de la freebox alors même qu'ils seraient content d'utiliser IPv6... Cordialement, Le 15 janv. 2013 à 17:35, Frédéric GANDER fgan...@corp.free.fr a écrit : ipv6 activé par défaut sur toute les box v6 depuis janvier 2011 d'ailleurs c'est pas une atteinte à la net neutralité ca ? de forcer l'utilisateur un choix de protocol pour surfer sur l'int[er|ra]net ? --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Carrier Grade NAT, nous y voilà
Il n'est pas question ici de débattre si le NAT est ou n'est pas une sécurisation. Lisez la RFC6092 : Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service et arrêter d'incendier le monde avec la position extrême disant qu'IPv6 ne doit faire que du routage transparent, c'est une des raisons principales qui a freiné l'adoption d'IPv6. A+ Merci de lire la RFC6092 Le 22 janv. 2013 à 10:39, Frédéric GANDER fgan...@corp.free.fr a écrit : euh car le nat c'est de la securite ? et bientot on va me dire qu'un firewall regle les pb de securite ? nb : un des premier but d'ipv6 c'était de garantir une connectivite end to end sans passer par des machines qui triturent les paquets et la tout le monde veux remettre du statefull firewall ? bon ba on va faire du nat alors ;) -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Carrier Grade NAT, nous y voilà
ou autrement dit, la sécurité globale d'un site repose sur la sécurité de l'ensemble des périphériques utilisant le réseau. A l'époque du BYOD, on n'est donc pas prêt de voir les responsables sécurité faire confiance à tous les machins IP (PC, Macs, imprimantes, photocopieurs, tablettes, téléphones, machines à café, ...) !!! Donc le déploiement d'un firewall en entreprise n'est pas une option, c'est obligatoire. Ensuite, si les box à la maison n'implémentent pas une sécurité minimum, je vous dis pas la joie du BYOD lorsque l'utilisateur retourne dans l'entreprise... A+ Le 22 janv. 2013 à 11:15, sxpert sxp...@sxpert.org a écrit : la box n'est qu'un routeur. le firewalling est a faire dans les feuilles, c'est à dire les machines connectées, ou dans un firewall intermédiaire si vous préférez cette méthode. -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Carrier Grade NAT, nous y voilà
Le 22 janv. 2013 à 16:38, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net a écrit : On Tue, Jan 22, 2013, at 15:51, Alain Richard wrote: ou autrement dit, la sécurité globale d'un site repose sur la sécurité de l'ensemble des périphériques utilisant le réseau. Apart le fait d'etre ingerable dans la plupart des cas, c'est pas une mauvaise idee heu désolé, mais je crois que tu n'as pas compris que ma remarque était ironique : c'est effectivement assez inepte de penser que la securité peut être maitrisée sur les feuilles. A l'époque du BYOD, on n'est donc pas prêt de voir les responsables sécurité faire confiance à tous les machins IP (PC, Macs, imprimantes, photocopieurs, tablettes, téléphones, machines à café, ...) !!! Your device, your security. Dans un cotexte BYOD c'est meme pas mal comme concept. Mais ca reste ingerable/difficilement gerable. Je sais pas toi, mais moi je n'accepte pas qu'on deploie de politiques de securite a la con sur *mon* *device* (ma propriete perso). Ils veulent de la secu, ils me filent leur device. Ouais, la réalité aujourd'hui en entreprise est qu'un nombre important de personnes ont des iBidule ou autres AndroMachin, et qu'ils se connectent au réseau via généralement le wifi. C'est une réalité aujourd'hui en entreprises, poussée au départ par les utilisateurs, et parfois même par l'entreprise elle-même pour ses utilisateurs non sédentaires. Je ne parle même pas des imprimantes et photocopieurs qui désormais se payent le luxe d'ouvrir des ports en UPNP et de se mettre à jour automatiquement sur internet. Donc le problème n'est pas de savoir si on veut ou pas du BYOD, et si oui d'uniformiser celui-ci sur un seul modèle de périphérique. Le BYOD existe déjà, et par nature, va continuer à croitre dans la plus parfaite hétérogénéité. Donc le déploiement d'un firewall en entreprise n'est pas une option, c'est obligatoire. Un firewall pour proteger entre eux des devices sur le meme subnet on-link ?!?!?!?!?!?!?!?! Le premier travail d'un firewall est d'empêcher les sessions entrant ou sortante non souhaitée entre internet et les LANs. Ensuite dans une entreprise avec un firewall, il est rare que toutes les machines soit sur le même LAN, donc il y a un possible passage par le firewall entre LANs. Enfin au sein d'un même LAN, il existe des technologies de limitation également en on-link (Wifi Guest avec isolation des postes entre eux, appliance de contrôe Wifi, ou technologies NAC 802.1X). Je n'ai donc jamais dis qu'il ne fallait pas gérer de la sécurité au niveau du device, mais qu'il en faut au niveau de l'accès internet (firewall) + politique de sécurité au niveau des devices, compléter par une éventuelle politique de sécurité plus poussée (802.1X, VLAN wifi isolé, DMZ, ...). Mon propos est juste de dire que se basé uniquement sur une politique de sécurité au niveau device me semble une inepsie. Le minimum étant plutôt au niveau firewall + device. Ensuite, si les box à la maison n'implémentent pas une sécurité minimum, je vous dis pas la joie du BYOD lorsque l'utilisateur retourne dans l'entreprise... T'a pas du voir l'etat dans lequel se trouvent pas mal de machines de non-techniques. Tu decris exactement le raison pour lequel la securite *par* *device* a un sens. Dommage que c'est aussi difficilement gerable (le cas ou je ne l'ai pas dit sufisamment de fois). Ingérable, on est d'accord, donc une politique de sécurité basée sur ce principe est également ingérable, ce qui n'est pas loin de signifier inexistante... Cordialement, -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco et CELAN France Telecom
Le 28 janv. 2013 à 11:36, Sebastien Lesimple s.lesim...@b-and-c.net a écrit : OK, je dois avoir un vieux mail d'FT concernant l'EFM et la config modem qqe part. Je retrouve ca et je transmet. Seb. Je suis confronté a exactement la même problématique. La config est relativement simple : controller SHDSL 0 dsl-group pairs 0, 1, 2, 3 efm-bond shdsl annex B-G (ou shdsl annex G) int e0 ip address ... et cela ne fonctionne pas (alors que ça fonctionne très bien avec d'autres opérateurs que FT). Bien évidement la synchro est correcte et le port e0 est up : equationgw2#sh controllers shDSL brief Controller SHDSL 0 is UP Capabilities: EFM, 2-wire, Annex A, B, F G, CPE termination cdb=0x85B81EF8, ds=0x85B82048 Vendor: Conexant, Chipset: CX98124 Firmware file: System, Firmware version: G115.1.10 Number of pairs: 4, number of groups configured: 1 Group info: Type: EFM bond g.shdsl, status: Up Interface: Ethernet0, hwidb: 0x85BA326C Configured/active num links: 4/4, bit map: 0xF/0xF Line termination: CPE, Annex: G Line coding: AUTO-TCPAM group data rate is 4608 kbps Loopback type: None Dying Gasp: Present Mode: Fixed SHDSL wire-pair (0) is in DSL UP state LOSW Defect alarm: none CRC per second alarm: none SHDSL wire-pair (1) is in DSL UP state LOSW Defect alarm: none CRC per second alarm: none SHDSL wire-pair (2) is in DSL UP state LOSW Defect alarm: none CRC per second alarm: none SHDSL wire-pair (3) is in DSL UP state LOSW Defect alarm: none CRC per second alarm: none Suite aux messages précedents, j'ai bien essayé un truc du genre : int e0 no ip addr in e0.100 encapsulation dot1Q ip address ... Avec = le numéro de VLAN de livraison, mais ceci ne donne pas plus de résultat. Un tech FT m'a dit que tous leur rad étaient configuré en VLAN 2950, mais cela ne marche pas non plus. Bien évidement il n'y a rien dans les STAS FT sur la question. Si quelqu'un a plus d'infos ou une config fonctionnelle ? Cordialement, -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] C'est vendredi, et pas n'importe lequel
Alors ça dors sur frnog ? Vous ne saviez pas qu'on n'a pas besoin d'IPV6 ? http://packetlife.net/blog/2011/apr/1/alternative-ipv6-works/ -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr
Re: [FRnOG] Choix de techno de stockage SAN
Le 13 avr. 2011 à 22:49, Jérémy RIZZOLI a écrit : Mais plutôt qu'un PoC peut être que simplement d'autres personnes sur la mailing liste ou dans vos DSI respectives ont déjà expérimenté du stockage de VM sur des SAN en SATA. .. on n'est probablement pas les premiers à s'interroger sur le bien fondé du SAS et de ses prix excessifs.. Pour plusieurs projets, j'ai utilisé du SAS et du SATA pour divers projets de virtualisation. J'ai fait les constatations suivantes : - le temps d'accès moyen du SAS et nettement meilleur que celui du SATA. C'est un point particulièrement important même pour des VMs faisant peu d'E/S, car effectivement il suffit que deux VMs fassent des E/S chacune sur une section différente du même espace disque pour voir les performances se dégrader très vite. - la fiabilité du SATA est très en dessous du SAS. Généralement les disques SATA sont prévus pour du Desktop, on un MTBF beaucoup plus faible, voir même une fiabilité globale beaucoup plus faible compensée par un espace de relocation de bad blocks plus important, mais donc avec une efficacité qui décroit avec le temps. J'ai eu plusieurs baies sur lesquelles j'ai du changer l'ensemble des disques tous les 3 ans. - pour pallier à la fiabilité SATA, il existe désormais des disques SATA dits NS et destiné effectivement à l'usage 24h/24 dans un SAN/NAS. Ils sont beaucoup plus fiables et donc fortement recommandés pour l'usage SAN, mais par contre ils n'améliorent généralement que marginalement les temps moyen d'accès (le déplacement de tête et la vitesse de rotation). - Pour pallier au moins bon temps d'accès, il est préférable de faire du RAID10, ou mieux (mais plus difficile à gérer au niveau espace disque) plusieurs RAID1 de façon à répartir les E/S sur plusieurs axes disques indépendants. - Les SAN/NAS uniquement SATA sont généralement moins performant au niveau de leur conception (contrôleurs RAID, E/S d'attacheement, Cache et optimisation des E/S). - On peut également pallier à la moins bonne performance en multipliant les SANs et/ou les espaces disques indépendant, mais la encore on multiplie les points de pannes potentielle (les MTBF se combinent) - Les SAS ont des vitesses de rotation 10K ou 15K, et des performances d'accès (seek time) nettement meilleures. - Les SAS ont généralement des capacité nettement inférieures aux SATA. C'est donc un inconvénient supplémentaire à leur surcout. La raison est principalement que par conception, les constructeurs ont choisi des densités nettement inférieures, ce qui permet d'obtenir de meilleures MTBF, moins de relocation de bad blocks et probablement permet l'augmentation de vitesse de rotation (15K) - Les SSDs sont très chers, et surtout ont une durée de vie potentielle qui est difficilement compatible avec un usage SAN. - Peut-être les architectures mixant du SSD/SATA ou SSD/SAS seront une solution à terme, mais pour l'instant elles sont encore plus cher que les solutions SAS. Donc globalement il n'y a pas de solution magique, SAS est meilleur mais de 3x à 10x plus cher à capacité égale que du SATA. Par contre les SANs en architecture SAS sont généralement de plus haut niveau et proposent des fonctionnalités plus avancées (maintenance sur site en 2h, réplication, snap shots, aggrégations, outils d'intégration avec l'hyperviseur, ...). Le vrai choix dépend en fait de la prise en compte ou non des indisponibilités potentielles d'une part et de la croissance maitrisée ou non des E/S d'autre part. De notre coté, la tendance est nettement d'aller vers les SAS actuellement. Cordialement, -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr
Re: [FRnOG] Routeur BGP et Ram
Le 14 avr. 2011 à 18:38, Sylvain Donnet a écrit : Question naïve : pour des besoins plus petits, qu'est-ce qu'il y a en dessous d'un ASR1001, et en moins cher ? Il y les 7301, 7200, voire même des ISR G2 en fonction des performances de routages souhaitées : http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf Cordialement, -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 Applications client/serveur, ingénierie réseau et Linux
[FRnOG] Re: [FRnOG] Soirée Configuration d'ipv6 dans votre reseau / IPv6 REAL Working Group
Le 27 juin 2011 à 12:20, Rémi Bouhl a écrit : La bonne nouvelle c'est que le RIPE envisage de faire mentionner la taille du sous-réseau attribué à chaque end-user: http://permalink.gmane.org/gmane.org.operators.frnog/12803 L'idéal ce serait que cette pratique soit universelle sur Internet: on arriverait à une équivalence avec IPv4 (un sous réseau Ipv6 = une IPv4) donc avec une problématique que les bases de réputation savent déjà gérer. L'autre solution serait d'attribuer à tout le monde un /48 ;) Et pour ceux qui doutent de son existence: le spam IPv6 existe, je l'ai rencontré \o/ (Plus précisément, envoyé chez moi en IPv6 par un serveur en open-relay qui l'a reçu d'un zombie IPv4). Rémi. A priori tous les utilisateurs devraient se voir attribuer des adresses en /48. Certains ISP peuvent faire le choix de mettre du /64 pour les box ADSL, ou du /60 voir +. Je ne vois pas bien l'intérêt de connaitre la taille, sauf éventuellement de se dire c'est un /64, donc un petit utilisateur, donc je le blacklist !! C'est un peu discriminatoire non ? Une RBL ipv6 pose le problème qu'une machine peut changer 2^64 fois d'adresse avant d'être vraiment blacklistée, mais ce type de comportement est difficile à cacher sur un serveur rootkité. Une RBL ipv6 qui bloquerait uniquement une adresse ipv6 (équivalent donc au comportement ipv4) et qui escaladerait à tout le bloc correspondant lorsqu'il voit de nombreuses adresses dans le bloc ayant le même comportement, mais cela est difficile à réaliser car il n'y a pas encore de façon de connaitre ce bloc quel que soit le RIR, l'ISP ou l'utilisateur. Le grey listing est généralement une très bonne approche, mais évidement avec les inconvénients qui vont avec. A+ -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr
[FRnOG] Re: [FRnOG] Re: [FRnOG] Soirée Configuration d'ipv6 dans votre reseau / IPv6 REAL Working Group
Le 27 juin 2011 à 14:53, Francois Petillon a écrit : On 06/27/2011 01:32 PM, Alain RICHARD wrote: Je ne vois pas bien l'intérêt de connaitre la taille, sauf éventuellement de se dire c'est un /64, donc un petit utilisateur, donc je le blacklist !! C'est un peu discriminatoire non ? Non, l'interet de connaitre la taille, c'est de pouvoir aggréger les résultats par utilisateur (maintenant, à partir du moment où c'est l'opérateur que annonce la taille, le principe me parait inexploitable). sauf que même si le RIPE propose cette info, quid des autres RIR ? Et de toute façon si un opérateur donne une zone /48 à un client, celui-ci peut très bien subnetter 65536 fois et n'a ni la compétence, ni l'envie de documenter la base RIPE... J'ai cru lire de plus que le RIPE n'oblige pas pour l'instant le LIR de déclarer les allocations ipv6 de ses clients. donc à priori il me semble que ce soit bien illusoire. Une RBL ipv6 pose le problème qu'une machine peut changer 2^64 fois d'adresse avant d'être vraiment blacklistée À votre avis, après 2^64 IPs différentes, dans quel état est votre base de réputation ? La j'ai du oublier un :-) pour me faire comprendre... , mais ce type de comportement est difficile à cacher sur un serveur rootkité. Pourquoi difficile à cacher ? On met l'interface en mode promiscuous et on balance des connexions avec des IPs aléatoires. Difficile à cacher ne veut pas dire difficile à faire. Difficile à cacher veut juste dire qu'une machine sur laquelle on constate des centaines ou millier d'adresses IPv6 sera plus vite identifiée comme rootkittée. Cordialement, -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr
Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation
Le 30 juin 2011 à 22:34, Stephane Bortzmeyer a écrit : Personne ne veut mettre du NAT66 sur ses boxes ? :-) http://www.bortzmeyer.org/6296.html Ces problèmes d'adressage me semble un gros frein au déploiement d'IPv6. Si j'ai bien compris les concepts d'IPv6 (je mets pas les :-) de rigueur, ne pas prendre au 1er degré !) : 1 - IPv6 a été conçu dans l'idée que la moindre ampoule électrique peut avoir sa propre adresse IP 2 - NAT44 et RFC1918 sont des technologies ayant été inventée en IPv4 uniquement pour adresser le manque d'adresses IPv4 3 - NAT66 est donc une technologie inutile 4 - en IPv6, tout doit être routé et c'est les firewalls qui assurent la sécurité 5 - le prefix réseau est fourni par le(s) routeur(s) (par exemple le CPE internet) 6 - l'autoconfiguration s'occupe de tout : le routeur donne le prefix aux postes du réseau La réalité des usages actuels d'IPv4 : a - IPv4 est déployé en interne en RFC1918 et un NAT44 est utilisé pour l'accès internet b - Beaucoup d'entreprises, y compris de petite taille, ont plusieurs accès internet c - Beaucoup d'entreprises, y compris de petite taille, ont un VPN IP pour gérer le multi-site (VPN IP, pas forcément IPSec) d - Dans les entreprises multi-sites, il n'est rare de sortir par l'accès internet centralisé e - Des utilisateurs mobiles remontent sur l'intranet via une connexion internet quelconque et une tech +/- sécurisée (ipsec, L2TP, PPTP, ...) f - La plupart des petits utilisateurs s'appuient sur le NAT44 pour sécuriser leur accès On rencontre pratiquement tous ces usages chez tous les utilisateurs : - particuliers via sa DSL BOX - petite entreprise - PME - grosses entreprises Le problème est le manque de visibilité sur la démarche recommandée pour un déploiement IPv6. Par exemple, pour le particulier : - l'activation d'IPv6 est une option de certains fournisseurs, dois-je le faire ou non ? - dois-je m'inquiéter que mon adresse est trackable ou pas ? (les windows récents utilisent des adresses temporaires, mais les anciens windows ? Mac OS X ne le fait pas, un iPhone ? un android phone ? ) - j'ai l'habitude que mon abonnement IPv4 est +/- sécurisé par défaut (via le NAT44, d'ou les +/-), c'est normal docteur que depuis que j'ai activé mon IPv6 je pollue toute la planète (je trouve particulièrement stupide et dangereux de la part de free que la box ne fasse pas au minimum du firewalling statfull). Pour l'entreprise : - est-ce normal docteur que mes postes aient une adresse publique ? - si je change de provider sur un site, je dois revoir tout mon routage VPN inter sites et/ou avec les nomades ? - si j'utilise des adresses ULA, mes postes doivent avoir en sus les adresses du prefix internet ? - si j'ai plusieurs adresses sur un poste, c'est donc le poste qui décide de la meilleure adresse source à utiliser ? avec quel critère ? - si j'ai plusieurs accès internets, comment gérer du policy routing sans NAT ou NPT ? dois-je forcément alors mettre en oeuvre une usine à gaz de multi-homing et/ou faire du BGP ? Le monde IPv6 serait tellement plus simple si on avait un consensus pour adresser notamment : - l'adressage de base (ULA ou prefix internet ?) - la sécurité de base, surtout pour la TPE et le particulier - le multi-homing simple (genre qu'ai un SDSL pour le VPN et une ADSL pour le surf) sans BGP ou autre technoligie inaccessible pour la PME - une technologie permettant d'utiliser Internet IPv4 à partir d'un accès IPV6 (NAT64 +DNS 64 semblent prometteurs) Ces questions de bases sont le vrai frein au déploiement d'IPv6 actuellement. Qu'en pensez-vous ? Alain -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 Applications client/serveur, ingénierie réseau et Linux
Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation
Le 1 juil. 2011 à 13:30, Mathieu Goessens a écrit : On Fri, 01 Jul 2011 09:53:49 +0200, Raphaël Jacquot sxp...@sxpert.org wrote: j'ai un peu de mal a voir ce que ce genre de bricolages apporte par rapport a du routage entre les 2 sous réseaux. Fallait lire le RFC ou l'article de Stéphane :-) Cela peut permettre de faire du multihoming du pauvre, d'avoir un réseau avec un adressage privé (ULA) en interne et un adressage publique en externe que l'on change très facilement, typiquement, si on change d'ISP, ou à la volée si on fait du policy routing. Ainsi tu peux avoir: Réseau +- ISP1 2001:0db8:1::/64 Interne--[ Routeur + NAT66 ]---+ fdxx:xx... +- ISP2 2001:0db8:2::/64 oui, c'est ce qui me semble très positif dans cette RFC 6296 : on peut faire du multi-homing sans avoir besoin de BGP et/ou d'adresses PI. Reste plus qu'à trouver un CPE pas trop cher ou un linux implémentant ce RFC. Plus que 2-3 ans à attendre :-( j'y vois au moins trois inconvénients * ca casse la transparence de bout en bout * ca bouffe éminemment plus de ressources dans le CPE * ca ne sécurise pas mieux que le NAT en v4 * Ça ne casse pas la transparence de bout en bout, sauf pour les protocoles qui embarques l'adresse IP (SIP, FTP..) * Ça ne bouffe quasiment pas de ressource. Pas d'état sur le CPE. Juste un préfixe à recalculer (ou un checksum si on veut avoir PRFX1::1 PRFX2::1 mais cela diverge du RFC). * Ça n'a pas pour but d'apporter de la sécu. Oui, c'est une très bonne idée de ne pas appeler ça NAT66 mais NPT car il s'agit bien que d'une moitié du problème (l'adressage), l'autre moitié étant évidement un firewall statfull permettant d'implémenter une sécurité de base (genre je laisse tout sortir et j'empeche de rentrer tout trafic n'ayant pas été initié depuis l'intérieur). Pour ce qui est des protocoles nécessitant un ALG, on sait depuis bientôt 20 ans qu'ils sont défaillants par conception et qu'il serait temps de les rendre obsolètes. A propos, qu'en est-il de ftp sur ipv6 : le mode actif est-il supporté ? A+ -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 Applications client/serveur, ingénierie réseau et Linux
Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation
Le 2 juil. 2011 à 23:03, Guillaume Leclanche a écrit : Avoir naturellement plusieurs adresses sur la même iface est une différence essentielle entre IPv6 et IPv4 et je suis d'accord avec cette approche du multihoming pour internet. Les deux préfixes sont valables et routés proprement, donc peu importe lequel on utilise. D'ailleurs, il n'y aurait éventuellement même pas besoin de 2 vlans (faut juste éviter que chaque routeur écoute les RAs de l'autre :) En outre, pour la communication LAN-LAN locale, il est recommandé d'utiliser des ULAs. Guillaume Oui mais dans ce cas, comment mon ampoule sait laquelle de ses deux adresses (ou n adresses) elle doit utiliser pour sortir sur internet ? A+ -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr
Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation
Le 3 juil. 2011 à 10:01, Yoann Gini a écrit : Bah justement, c’est que je disais, sans le NAT je suis incapable de refaire cette config qui marche très bien en IPv4 et qui est utilisé par beaucoup de monde… et oui, c'est bien pourquoi ce NPT me semble intéressant. La solution idéale serait des adresses PI et du multi-homming, sauf que je vois mal les FAI accepter ça sur de l’ADSL grand publique d’une part, et d’autre part les clients ne comprendront pas pourquoi IPv6 fait « moins bien » qu’IPv4 et ne voudront pas faire la migration. et puis ça va être dur d'expliquer à M. Michu (pas de sexisme primaire !) qu'il faut payer pour un routeur BPG et une journée d'ingériéring pour le mettre en place correctement ! À mon avis il y a un vrai marché à prendre ici. Une offre packagé ADSL + SDSL (avec si possible des DSLAM différents) sur un bloc d’IPv6 identique et du load balacing / traffic selection entre les deux sans pour autant ruiner le client. Chez un même FAI, y'a pas de problème, je te le propose quand tu veux (en BGP). Même pas besoin d'adresses PI. Mais bon la redondance ADSL + SDSL est quand même bien illusoire quand on sait que l'on passe par le même chemin de cuivre... Cordialement, -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr
Re: [FRnOG] Re: RFC 6296: IPv6-to-IPv6 Network Prefix Translation
Le 4 juil. 2011 à 08:37, Radu-Adrian Feurdean a écrit : Parce qu'en v6 on peut toujours scanner tout l'espace d'addressage plusieurs fois par mois, comme en v4 ? si tu veux une adresse fiable, il te suffit de faire un spam avec une belle image : le client se fera un plaisir de venir chez toi chercher la belle image et te donner au passage une adresse ipv6 fiable... Bon d'accord, avec des adresses temporaires (RFC 3041), les adresses récupérées ont une durée de vie limitée (quand même une semaine), mais cela est bien suffisant pour une attaque. La sécurité par offuscation n'est pas, et n'a jamais été, une solution de sécurisation, et ce n'est pas les 2^64 adresses d'IPV6 qui vont changer ça. Cordialement, -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr
Re: [FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation
Le 4 juil. 2011 à 16:38, Rémy Sanchez a écrit : On Monday 04 July 2011 11:35:50 Alain RICHARD wrote: Oui mais dans ce cas, comment mon ampoule sait laquelle de ses deux adresses (ou n adresses) elle doit utiliser pour sortir sur internet ? Cf le mail de Yves-Alexis Perez qui renvoie à la RFC kivabien http://www.mail-archive.com/frnog@frnog.org/msg15322.html -- Rémy Sanchez Oui, mais je suppose que ça dépend également de la capacité ou volonté du fabriquant de l'ampoule de lire les RFCs jusqu'au bout. De toute façon, même si la RFC est respectée, je subodore que l'OS restreint de mon ampoule soit dur à paramétrer pour lui permettre de renvoyer sa consommation instantanée à la centrale électrique via le bon accès internet. Si il faut prendre en comptes tous les périphériques IP, chacun de leurs OS et spécificités éventuels, cela va être comique ! Il me semble que reporter toute l'intelligence du policy routing en ipv6 sur chaque noeud ne soit pas la meilleure solution pour rendre un réseau gérable... Le NPT, permet justement de reporter la policy-routing sur les éléments de routages, qui sont incidemment justement fait pour faire du routage et le cas échéant du policy-routing, et permettra donc enfin de déployer IPv6 en utilisant des adresses ULA en interne sans trop de soucis. Avoir appeler cette fonction NPT, en la dissociant d'une éventuelle fonction de sécurisation, est également une très bonne idée car ces deux fonctions sont complètement dissociable en ipv6 (on peut faire du NPT sans aucun filtrage par exemple). Cordialement, -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr
[FRnOG] Le FTTH, une impasse ?
Depuis maintenant pas mal de temps, j'ai tendance à considérer que la fibre jusqu'à l'appartement est une grosse bêtise : - pour obtenir au final un 100 mb/s même pas symétrique, je ne voit pas du tout l'intérêt de la fibre - la fibre est par définition une technologie fragile, pas facile à déployer physiquement (coudures, soudures, réparations) - les éléments actifs sont encore un peu cher - je ne connais pas encore d'usages grand publique justifiant un usage 100 mb/s - même en entreprise, où le giga est possible depuis longtemps à des coûts relativement faibles en cuivre, l'usage du gb/s n'est que marginal au niveau du poste client - la rentabilité d'un telle infra de fibre jusqu'à l'appartement reste à prouvé - le corolaire de la rentabilité est qu'en plus cela ne concerne que les zone à forte densité (immeubles essentiellement, au détriment des maisons individuelles et des zones peu denses ou rurales) Je viens de lire que free commençait à changer son fusil d'épaule, et veut dorénavent privilégier le VDSL2. Il me semble que OVH est sur la même longueur d'ondes (mais eux ils n'ont pas de plan fibre, donc c'est plus logique). AMHA, le seul intérêt de la fibre pour les opérateurs grand public est d'arriver le premier sur un immeuble, et donc de pouvoir potentiellement agréger une population captive… Mais bon, une fibre dans la rue avec un mini DSLAM VDSL2 à moins de 500m des appartements devrait apporter le même type de résultat qu'une FTTH. Sans compter en plus que le FTTH/GPON est une techno un peu bâtarde ou 30 appartements reçoivent simultanément le même signal, mais seul le destinataire est sensé avoir la clef de décodage… Qu'en pensez-vous ? -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 Applications client/serveur, ingénierie réseau et Linux
[FRnOG] [TECH] Info sur offres Completel Completude Max ?
Bonjour, je viens de tomber sur un client ayant une offre Complétel Completude Max. Je ne trouve aucune spécifications précise de cette offre, et les specs marketing indiquent du 100 mb/s symétrique sur fibre optique dont 7 mb/s sont dédiés à du trunk SIP et le reste pour de l'accès Internet. Il semble qu'en fait il y ait en arrivée un seul brin fibre, arrivant sur un RAD EtherAccess ETX-102 sur lequel sont livrés deux ports fast ethernet 100 mb/s. Savez-vous quelle est la solution technique sous-jacente ? Est-ce que l'on a effectivement un débit symétrique sur une telle construction qui ne peut être à priori que half duplex ? Est-ce de l'accès internet grand public type Numericable ? A+ -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Devenir LIR et récupérer nos ressources
Le 11 avr. 2013 à 17:07, frede...@perrod.org a écrit : Bonjour, Que se passe t-il quand un LIR arrête d'être LIR? Il perd ses allocations et ses clients perdent leurs assignements? J'ai trouvé ça en bas de la page https://www.ripe.net/ripe/docs/ripe-582#Closing-LIR-by-the-RIPE-NCC, mais c'est pas clair dans mon esprit :( 11.0 Closing an LIR by the RIPE NCC The RIPE NCC may close an LIR for any of the following reasons: the LIR does not pay money owed to the RIPE NCC the LIR cannot be contacted by the RIPE NCC for a significant period of time the LIR consistently violates the RIPE community’s policies The RIPE NCC takes on responsibility for address space held by closing LIRs. Merci pour vos éclairages, Cordialement, Fred La dernière petite phrase The RIPE NCC takes on responsibility for address space held by closing LIRs. veut dire que le RIPE prend à sa charge la gestion de l'espace d'adresse correspondant, ce qui veut tout et rien dire ! Comme le RIPE n'a pas vocation a gérer les clients finaux en direct (sauf pour certains cas de PI, mais même la c'est en dernier recours), il est probable qu'ils passent la zone en question en mode PA et n'y touchent plus. Mais au pire, ils peuvent très bien enlever les plages IP des tables de routage BGP et de DNS inverse et laisser les clients de débrouiller avec le LIR indélicat... De toute façon un opérateur qui perdrait son status de LIR sans reprise correcte du cadre de gestion des adresses IP est un opérateur mort à court terme. -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Le Marais
, the letter actually doesn’t say anything that wasn’t already known. The letter acknowledges that address assignments are of value, but doesn’t actually specify what rights to them parties received (nor even what precisely “address assignments” are) The concern has never been about ARIN unilaterally reclaiming number resources; it has been about changes to the number resources in the registry and whether such changes must comply with community policy. The letter further does not address in the least ARIN’s operation of the registry, despite any assertions you make to the contrary, and ARIN continues to abide the principles by which we were founded of self-governance for the number resources. l'ARIN: Nous sommes l'autorité de fait, nous representons la communauté, c'est comme cà maintenant... Cordialement. --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL http://www.e-liance.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.
Oui, il n'est pas envisageable de pouvoir absorber une charge importante si chaque message doit passer par des analyses de contenu (filtres bayésiens, OCR sur les images, etc.). Pour les grosses volumétries, deux aspects essentiels : 1) Il faut détecter les courriers indésirables pendant la session SMTP pour refuser de les prendre en charge à ce moment là. C'est ce que j'appelle le problème de la patate chaude. Cf. http://clx.anet.fr/spip/article.php3?id_article=238 (c'est un peu ancien mais toujours d'actualité). J'aime bien embarrasser les files d'attente des hébergeurs peu scrupuleux ou peu consciencieux. Un produit tel que MIMEDefang (déjà cité dans ce fil) est l'idéal. 2) Il faut épuiser tous les tests possibles (DNSBL, listes grises, SPF, DKIM, conformance, etc.) avant de se résoudre à regarder le contenu d'un message. En fait, la plus grosse partie des messages indésirables doivent être repérés avant la phase DATA de la sessions SMTP. Ainsi, par exemple, les anti-virus de nos relais de messagerie détectent très peu de virus car ils sont interceptés avant d'arriver à l'anti-virus. En se basant sur ces principes, nous avons des cas où nous arrivons à traiter 1 million de sessions SMTP entrantes par jour sur un simple Dell d'entrée de gamme d'il y a 3 ans. Bon WE à tous, -- Sébastien Namèche Société Netensia --- Liste de diffusion du FRnOG http://www.frnog.org/ Nous mettons en place couramment des solution Open Sources basées sur Sendmail + DNSRBL + MimeDefang + DCCD + razor + pyzor + SpamAssassin + GreyListing + clamav + généralement un anti-virus commercial (par exemple Kaspersky). Ces solutions permettent effectivement de gérer très très convenablement le problème de SPAM. Notamment la seule solution greylisting arrête généralement plus de 98% du SPAM et est quasiment incoutournable par les Spammeurs. Elle permet de plus de ne soumettre aux moteurs anti-spam et anti-virus que les messages restant, ce qui est très grosse économie de CPU. Le seul problème de cette solution est qu'il est très difficile d'avoir une interface utilisateur digne de ce nom, et c'est généralement là que les produits commerciaux gagnent, surtout que ceux qui achètent les produits sont rarement ceux qui les exploitent... Cordialement, -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 Applications client/serveur, ingénierie réseau et Linux
Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.
Le 29 juil. 2010 à 16:14, Benjamin Billon a écrit : Le seul problème de cette solution est qu'il est très difficile d'avoir une interface utilisateur digne de ce nom, et c'est généralement là que les produits commerciaux gagnent, surtout que ceux qui achètent les produits sont rarement ceux qui les exploitent... Ca c'est un problème pour l'admin. Pas tout à fait : dans une PME de taille moyenne (50-500 personnes), l'admin peut très bien passer son temps à répondre à des questions genre pourquoi mon mail n'est pas arrivé ? pourquoi mon mail est marqué comme spam ? pourquoi mon mail n'est pas détecté comme spam ? En générale l'entreprise ne dédie que très rarement un poste à temps plein pour adresser ce genre de demande... Certains produits, comme MailInBlack (dont j'exècre le principe c'est très contre productif), reporte le problème à l'utilisateur lui-même, ce qui est une bonne idée probablement. L'admin ne passe normalement pas son temps devant l'interface utilisateur du moteur de filtrage, il peut donc se satisfaire d'une interface relativement pauvre. Par principe, le greylisting est une hérésie qui mérite d'être bannie de tout organisme digne de ce nom, repousser de 15 voire même de 5 minutes l'arrivée d'un message attendu étant universellement contre-productif. Mouiais, à mon humble avis, les gens qui utilisent le mail comme un moyen d'acheminement temps réel n'ont pas tout compris au film, ce sont souvent les mêmes qui se pleignent de ne pas pouvoir envoyer leur dernier PowerPoint de 100Mo pas mail :-). Sur un moteur grey-listing et avec une bonne configuration du moteurs et de ses interaction, on peut très fortement diminuer cet inconvénient par divers moyens (construction de listes de white-listing automatique, retarder uniquement d'une minutes, informer les utilisateurs, réemission d'un message lorsqu'il est nécessaire de le recevoir immédiatement, ...). D'expérience, en entreprise les messages attendus en instantanés représentent moins de 0,1% des mails sollicités. Les spammeurs savent depuis longtemps qu'il suffit, en cas de greylisting, d'insister un peu plus longtemps que d'habitude, et dans la mesure où ce sont les ressources cpu/réseau de machines infectées et non les leurs qui sont ralenties/impactées par le procédé, rien ne les décourage de contourner cette solution. Et dans l'idéal, c'est non du greylisting mais du traffic shaping qu'il faudrait mettre en place, avec des latences plus ou moins prononcées en fonction de la réputation de l'expéditeur. Bien évidement si le spammeur est un bon élève, alors il re-essaiera, mais alors généralement c'est plutôt un message type commercial avec possibilité de désinscription et serveur bien identifié comme valide. La volumétrie du spam est plutôt constituée de moteurs sur des machines compromises et qui utilisent des bases de données de spam avec des centaines de millions d'emails, dont probablement plus de 80% sont faux ou inactifs. Ces moteurs ont une durée de vie très limités sur internet (quelques dizaines d'heures au maximum) avant d'être blacklistées dans des RBLs ou arrêtés par le propriétaire de la liaison ou son ISP. De par leur nature et la nature de leur base d'emails, ces moteurs n'ont aucune velléité de gérer des spools pour les emails blockés par le grey-listing. C'est pourquoi, du moins dans notre expérience depuis plusieurs années, le grey-listing est la seule technologie qui a significativement fait diminuer le spam sans augmenter les faux positif. Quant à la mise en oeuvre de trafic shaping, c'est peut-être une idée à creuser, mais il me semble difficile de le faire au niveau du destinataire car le spam est imlportant mais généralement faible une fois divisé par le nombre de sources non ? Cordialement, -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 Applications client/serveur, ingénierie réseau et Linux
Re: Suggestion pour les attachements lourds (was:Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.)
Le 30 juil. 2010 à 11:44, Jérôme Nicolle a écrit : J'ai tenté (mais pas fini) de poser un bout de code qui dissocie les pièces jointes pour les acheminer vers un dépôt accessible en HTTP, et ce automatiquement à l'envoi du mail, par le relai SMTP local. Je n'ai pas trouvé de code tout fait et je n'ai pas eu le temps de finir le mien, vous savez si ça existe ? Dans l'idée : - Si la taille du mail dépasse 5Mo - Si des attachements dépassent 1ko (pour laisser les images des signatures et ces conneries là) - Les attachements de plus de 100ko sont détachés, hashés et envoyés sur un dl.free.fr-like interne, associé au mail-id - Le contenu du mail est altéré pour ajouter _en début de mail_ le lien de téléchargement - Le code coté httpd retourne par mail un accusé de téléchargement des pièces jointes à l'expéditeur Ca devrait être adaptable pour pas mal de cas d'utilisation, et le fait de hasher les fichiers et de les envoyer sur un canal distinct permet de dédupliquer et/ou compresser le contenu. Qu'en dites vous ? Ca vaudrait le coup de finir de développer ce merdier ? -- Jérôme Nicolle Personnellement je considère que le mail n'est PAS un serveur de fichiers. Je préfère donc essayer d'évangéliser les utilisateurs en limitant la taille sur le serveur SMTP pour qu'ils changent leur mauvaise habitude. Même si techniquement il doit effectivement être possible de finaliser ce dév, il me semble que cela poserait plusieurs problèmes : - encourager à la diffusion de messages lourds par email. - devenir dépendant d'un services externe qui ne garanti aucunement la confidentialité ni la sécurité des informations - les services genre dl.free.fr ont généralement une politique d'expiration des données non maitrisée par l'émetteur de l'email - les messages contenant des gros fichiers sont généralement échanger entre deux utilisateurs intranet, ce serait domage de les externaliser - c'est incompatible avec les technologies de signature électronique des messages Perso je ne pense pas que j'utiliserais une telle architecture, ou du moins pas si elle dépend d'un site web externe. Cordialement, -- Alain RICHARD mailto:alain.rich...@equation.fr EQUATION SA http://www.equation.fr/ Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 Applications client/serveur, ingénierie réseau et Linux
Re: [FRnOG] [TECH] Occupation vers notre tranche SDA OBS depuis mobiles SFR
En règle général, c’est à l’opérateur chez qui les numéros sont portés qui doit faire la démarche auprès des autres opérateurs. Donc si actuellement c’est OBS qui présentent les numéros sur vos T2, c’est à Orange de s’assurer que la déclaration globale est bien respectée chez d’autres opérateurs, dans votre cas chez SFR. Cordialement, > Le 13 mai 2016 à 11:17, Denis VINCIGUERRA <de...@vinciguerra.fr> a écrit : > > Bonjour, > > Depuis ce matin (à priori), tous les numéros de notre tranche SDA sont > injoignables depuis des mobiles SFR (l'appel est raccroché immédiatement). > Aucun soucis n'est détecté depuis les autres opérateurs. > > Ces numéros arrivent sur des T2 OBS. Le support front OBS a du mal à > comprendre le problème et nous dit que les appelants doivent ouvrir des > tickets chez SFR: comme si on allait demander aux clients de contacter leur > support grand public pour ouvrir des tickets ! > > Nous ne sommes pas clients SFR, sauriez vous comment faire dans ces > situations (hormis harceler OBS) ? > > Merci par avance, > Denis > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ — Alain RICHARD <mailto:alain.rich...@equation.fr <mailto:alain.rich...@equation.fr>> EQUATION <http://www.equation.fr/ <http://www.equation.fr/>> Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 E-Liance, Opérateur des entreprises et collectivités, Liaisons Fibre optique, SDSL et ADSL <http://www.e-liance.fr <http://www.e-liance.fr/>> --- Liste de diffusion du FRnOG http://www.frnog.org/
