Re: [FRnOG] [MISC] dgfip refusé par gmail
Hello, _spf1-meo.microsoft.com. 3600 IN TXT "v=spf1 ip4:52.165.175.144 > ip4:52.247.53.144 ip4:157.55.254.216 ip4:13.74.143.28 ip4:104.214.25.77 > ip4:207.46.225.107 ip4:51.137.58.21 ip4:138.91.172.26 ip4:52.250.107.196 > ip4:13.92.31.129 ip4:51.144.100.179 ip4:52.160.39.140 ip4:52.244.206.214 > ip4:13.72." "50.45 ip4:20.118.139.208/30 ip4:20.98.194.68/30 ip4: > 20.83.222.104/30 ip4:20.88.157.184/30 ip4:20.59.80.4/30 ip4:20.51.6.32/30 > ip4:20.97.34.220/30 ip4:20.107.239.64/30 ip4:20.105.209.76/30 ip4: > 20.98.148.156/30 ip4:20.69.8.108/30 ~all » > > (l’IPv4 sur la seconde ligne coupée au milieu par des « « ) > C'est parce que la taille max d'une string dans un TXT est 255 caractères mais il peut y avoir plusieurs strings pour un RR. DIG présente ainsi ces multiples strings. Le RFC 4408 spécifie clairement que c'est au client SPF de réassembler. https://datatracker.ietf.org/doc/html/rfc4408#section-3.1.3 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] dgfip refusé par gmail
Hello, > pour information, les messages de la dgfip refusés par gmail (DKIM) > comme indiqué ci dessous > A mon avis c'est plutôt parce que le SPF ne contient que de l'IPv4 et qu'ils causent à Google en IPv6. (arrivée un peu en avance du vendredi IPv6) > > Feb 28 15:43:35 localhost postfix/smtp[909495]: 6C8E460817CF: > to=, > relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c00::1a]:25, delay=9.3, > delays=0.32/0/0.11/8.9, dsn=5.7.26, status=bounced (host > gmail-smtp-in.l.google.com[2a00:1450:400c:c00::1a] said: 550-5.7.26 This > mail has been blocked because the sender is unauthenticated. 550-5.7.26 > Gmail requires all senders to authenticate with either SPF or DKIM. > 550-5.7.26 550-5.7.26 Authentication results: 550-5.7.26 DKIM = did > not pass 550-5.7.26 SPF [dgfip.finances.gouv.fr] with ip: [] = > 550-5.7.26 did not pass 550-5.7.26 550-5.7.26 For instructions on > setting up authentication, go to 550 5.7.26 > https://support.google.com/mail/answer/81126#authentication > a7-20020a05600c348700b004126fb66bbcsi943998wmq.221 - gsmtp (in reply to > end of DATA command)) > > Confirmé par > > > https://mxtoolbox.com/SuperTool.aspx?action=dkim%3adgfip.finances.gouv.fr%3aemail=toolpage > > Ça montre juste qu'il n'y a pas de DKIM avec ce sélecteur "email" ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Les cabinets comptables & la cyber
Bonjour, - Quels sont les sous-réseaux, leur IP et leur fonction ? > - Quels sont les outils (logiciels) mis en place pour la connexion à > distance pour le télétravail ? > Je vous conseille d'en dire le moins possible, car au fil des ans ils en demandent de plus en plus tout en comprenant de moins en moins. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Mieux que l'HADOPI, Free !
Hello, Le téléphone doit être accessible par SIP. Par contre, impossible d'obtenir la télévision à ce que je sache. Bref : si vous voulez contourner le filtrage de free, il y a plus simple que de changer de box. Il suffit de changer de DNS ;) Jusqu'à la prochaine étape qui arrivera probablement : intercepter toutes les requêtes DNS passant par la box et les passer à dnsmaq (principe évidemment déjà appliqué un peu partout, par exemple par les portails captifs). Tout ceci est bien inquiétant. Il y a un autre modèle évidemment : augmenter l'abonnement. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Décret sur les contrôles de sécurité par l'ANSSI
On 11/21/2012 03:51 PM, Paul Rolland (ポール・ロラン) wrote: Donc, en hebergeant mon serveur de mails a la maison, tant que l'usage en est offert au cercle famillial : non operateur Mais si j'heberge un jour une mailling-list dessus, je deviens operateur ? Petit aparté: il y a des opérateurs qui s'ignorent. La déclaration est obligatoire, mais tous ne sont pas déclarés. C'est l'article 32 qui définit ce qu'est un opérateur, pas la déclaration. Si ma comprehension est bonne, deja nos amis gestionnaires des machines qui hebergent cette liste ? Pourquoi pas, mais on trouve dans l'article 1 du décret : « Art. R. 9-8.-Le contrôle prévu à l'article L. 33-10 a pour objet d'évaluer les mesures prises par l'opérateur en application des dispositions du a du I de l'article L. 33-1 et notamment celles prises pour assurer la sécurité de son réseau et de ses services à un niveau adapté au risque existant, pour assurer l'intégrité de son réseau et garantir la continuité des services fournis. Il y a une notion de risque là dedans, et aussi de public dans la définition de l'opérateur rappelée par Eric. Je ne crois pas que frnog soit généralement ouvert au public, et qu'il existe un risque pour le pays lié à sa compromission. Bref évidemment après on peut imaginer que la loi et le décret soient contournés par le méchant État méchant, mais après tout, le Conseil d'Etat doit être là en recours, non ? Evidemment si on a basculé dans une dictature ou que l'on soit en état de guerre, on peut tout imaginer mais franchement ce sera le dernier de nos soucis. On voit quand même bien à qui s'adresse ce décret : les gros qui maintiennent des infrastructures jugées critiques, qu'ils soient opérateurs ou hébergeurs. Ce qui est plus franchement embêtant et qui n'a fait visiblement tiquer personne ici, c'est que l'ANSI puisse quand elle le veut prendre le steak des consultants en sécurité, y compris pour auditer des sociétés privées ... (enfin l'ANSSI les a bientôt tous embauchés donc il faut bien leur donner du travail ... oui c'est vendredi). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Apres la fin du dernier /8 ipv4
On 10/01/2012 04:59 PM, Clement Cavadore wrote: On Mon, 2012-10-01 at 16:56 +0200, Pascal Rullier wrote: A quoi ça sert alors ? en interne ? c'est une sorte de rfc1918 mais avec blocs publics uniques Il existe également une sorte d'internet parallelle (réseau monétique/financier), ayant besoin d'adressage IP unique (les blocs RFC1918 n'étant d'une part pas suffisants pour couvrir les besoins d'adressage, et n'étant d'autre part pas découpables administrativement...) Y a aussi le GRX pour l'itinérance données des opérateurs mobiles (ils ont aussi leur racine DNS ...) . --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Detecter DDos outils et null-router sur quagga
On 09/06/2012 02:43 PM, Stephane Bortzmeyer wrote: Sur un routeur linux quagga, comment vous faites pour null-router une IP qui est méchante iptables -A INPUT -s mé.ch.an.t -j DROP Sur un routeur comme demandé c'est plutot -A FORWARD , non ? 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. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Problème sur le réseau mobile?
On 07/09/2012 09:24 AM, Stephane Bortzmeyer wrote: On Sat, Jul 07, 2012 at 11:12:54AM +0200, Alain Thivillona...@rominet.net wrote a message of 44 lines which said: Comme toute base de donnés, ben quand ça foire c'est la grosse M..., meme avec tous les mécanismes de réplication et de failover du monde. S'il faut remonter des backups, ben c'est long, dangereux, etc... Mais pourquoi restaurer des sauvegardes ? Si je comprends bien, les données dans le HLR sont uniquement de type « cache ». Euh non dans le HLR il y a aussi les secrets de ta SIM, ton type d'abonnement, les renvois éventuels, etc. C'est extremement dynamique, et accédé aussi en écriture par le SI, par exemple pour provisionner (prepaid) ou bloquer/débloquer les IMSI en cas de vol. C'est aussi pour ça que dire comme lu ici on a qu'a perdre 1h de données plutot qu'avoir une sync parfaite est pas très tenable, il faut expliquer ça aux gens qui rechargent leur mobicarte ou aux services de police ... Elles sont transitoires et, si on les perd, on peut les reconstituer et les mobiles se ré-enregistrent. Ca c'est le VLR qui contient aussi les datas des mobiles en roaming (ceux de freemobile par exemple) et qui a un effectivement un cache de certaines données. Eux n'étaient pas en cause visiblement, puisque les mobiles Free marchaient relativement bien (meme s'ils ont eu des soucis liés à l'avalanche probablement). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
On 07/09/2012 06:21 PM, Guillaume Barrot wrote: Avant de pouvoir envoyer un SMS, encore faut-il arriver à s'enregistrer sur le réseau. http://en.wikipedia.org/wiki/Network_switching_subsystem#Home_location_register_.28HLR.29 A noter aussi qu'en France, au moins chez SFR et Orange en 2G, le réseau impose une réauthentification du mobile à chaque utilisation de ressource (SMS, Appel, ouverture d'un PDP= ou appel entrant (ce qui n'est pas obligatoire si l'on suit la norme). Ca évite quelques attaques. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
On 07/07/2012 03:21 AM, François-xavier wrote: Avec une durée d'incident de pratiquement 10h, je suis curieux de savoir qu'est-ce qui tombé en panne et pourquoi ils ont mis aussi longtemps à réparer ? Dans un réseau mobile, il y a le réseau (BTS, MSC en 2G, NodeB, RNC en 3G, SGSN, GGSN, SMSC pour les deux) et puis il y a un instrument critique qui sait ou est l'utilisateur, ce qu'il a le droit de faire et comment l'authentifier : le HLR : Home Location Register. C'est une base de données accédée via les protocoles télécoms, avec comme clés d'index l'IMSI et le MSISDN de l'abonné. Comme toute base de donnés, ben quand ça foire c'est la grosse M..., meme avec tous les mécanismes de réplication et de failover du monde. S'il faut remonter des backups, ben c'est long, dangereux, etc... Si les HLR sont en panne, plus d'authentification, plus d'appels, plus de SMS, plus de data parce que le SGSN ne peut plus vérifier le provisionning de l'abonné, plus rien. Les mobiles enregistrés peuvent rester sur le réseau sans s'apercevoir de rien, mais dès qu'ils feront un appel, plouf. Apres quand le HLR revient il y a un rush de demandes depuis les mobiles pour se réenregistrer, un rush de demandes depuis les SMSC pour délivrer ce qui est en file, etc... D'ou probablement une remise en route partielle, par morceaux, d'abord 2G, etc ... Je ne travaille pas chez orange et je n'ai aucune idée de ce qui s'est passé, mais ils parlent d'un incident logiciel majeur, et le HLR est le seul composant qu'on ne peut pas remplacer par un autre en quelques minutes. A noter que Bouygues Telecom a eu une panne similaire en 2004 (octobre si je me rappelle bien) avec 10h de coupure aussi. Dans le même registre, le plantage régulier des super-supernodes de Skype provoque exactement les mêmes effets : quand on ne sait plus localiser l'abonné, c'est mort. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Vous avez perdu le mot de passe de votre F5 BIG-IP ?
On 06/11/2012 04:57 PM, Stephane Bortzmeyer wrote: Pas de problème pour le récupérer :-) http://www.exploit-db.com/exploits/19064/ La question étant quand même, comment ont ils récupéré la clé privée ? Volée sur le laptop d'un consultant F5 ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Vous avez perdu le mot de passe de votre F5 BIG-IP ?
On 06/11/2012 05:31 PM, Florent Daigniere wrote: T'as mal lu: la clef est sur toute les appliances! Ah oui oups. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Fuite possible de password de Linkedin
On 06/06/2012 04:18 PM, Anthony Arciero wrote: Bonjour, Avis à ceux qui ont un compte sur LinkedIn Un hackeur russe aurait réussi à récuperer 6,5M de mots de passes dont la pluspart sont de linkedIn. A noter qu'il a fourni les 6.5 millions de hashes sur un forum, mais pas les logins ^^ . C'est du sha1 non salté et certains y ont trouvé leur mot de passe effectivement. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Fuite possible de password de Linkedin
On 06/06/2012 04:27 PM, Anthony Arciero wrote: Oui il est bon de le souligner. N’empêche Le couple login/pass aurait fait grand bruit :) Il ne fait aucun doute aussi : - que lui a les emails/login - qu'il en beaucoup plus, les hashs leakés sur le forum en question n'étant pas completement triviaux, et c'est statistiquement significatif ... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Solution 3G à l'étranger
On 05/02/2012 04:03 PM, Pierre-Yves Maunier wrote: Il y a plein de ports filtrés dans les MacDo que j'ai testé. Pas de SSH ni VPN. Mais ils sont franchisés donc pas tous sur le même réseau… Je me connecte toujours à un VPN SSL OpenVPN qui tourne sur le port 443 pour ça et jusqu'à présent c'est toujours passé. Le problème d'OpenVPN sur le port 443 en utilisant des certificats X509, c'est que ce n'est justement pas du SSL :-) Après en faisant de l'analyse sur la taille de paquets, comportement du trafic etc il doit être possible de savoir que ce n'est pas du https qui passe mais je pense que les déploiements pour filtrer ce genre d'usages sont rares. Il suffit de regarder le premier paquet et de voir qu'il ne contient pas de ClientHello SSL. Pour SSH sur le port 443, c'est encore plus simple puisque dans ce cas c'est le serveur qui émet le premier paquet de données. Si on veut faire du VPN sur le port 443 partout, il vaut mieux utiliser stunnel, SSLTunnel (un vieux truc à moi chez hsc.fr) ou le truc Microsoft SSTP. Tout ça fera du vrai SSL difficile à filtrer sauf analyse statistique (mais avec les Googleries genre SPDY, difficile de s'appuyer la dessus). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Incident éléctrique TH2
On 04/11/2012 12:07 PM, Oceanet - Cédric BASSAGET wrote: Bonjour à tous, Quelqu'un sait un peu plus précisément ce qu'il se passe à TH2 ? Il semble que ce soit un problème électrique selon les infos que j'ai. Tous nos liens xDSL porte nationale ainsi que notre transit AXIONE sont HS depuis 10:20. Il semble aussi que free soit impacté : http://www.universfreebox.com/article16979.html Comme cette liste qui vient de repartir après de longs fsck, désolés ... Pour le moment l'explication un client a fait tout disjoncter ! (tout = les 3/4 du 1er étage). Huhu. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Mitigating DNS Denial of Service Attacks
Bonjour, On 03/31/2012 11:32 AM, jehan procaccia wrote: J'ai un vague souvenir d'un outil de mesure temps reel de l'activité des root servers qq'un peut-il indiquer l'URL où cela se trouve ? Je ne crois pas qu'il y ait d'URL globale mais certains ont des statistiques : http://k.root-servers.org/ http://h.root-servers.org/ http://dns.icann.org/cgi-bin/dsc-grapher.pl?binsize=60window=86400plot=bynodeserver=L-root en ce qui me concerne, j'ai pour l'occasion activé un graph cacti sur l'activité d'un de nos serveurs DNS il y a eu cette nuit un pic a minuit, puis une activité anormalement haute (proche de 100K queries /5mn) entre 1H et 5H AM . peut-etre un épiphénomene qui n'a rien a voir avec l'evenement annoncé, mais curieux quand meme ! Sur L et K on voit un petit sursaut cette nuit effectivement, mais presque anodin. Le monitoring du RIPE ne montre rien de significatif en terme de qualité de service, par exemple http://dnsmon.ripe.net/dns-servmon/server/?server=k.root-servers.netaf=ipv4show=SHOW --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Question mise à jour DNS pour les internautes numericable
Christophe t...@stuxnet.org écrivait (wrote) : Raphael Mazelier a écrit : J'aurais tendance à l???écarter car je suis chez NC sans box (cable modem simple) et j'ai le même résultat. Effectivement curieux ... Il y a probablement plusieurs caches derriere la même adresse chez NC, qui ne donnent pas la même chose. En interrogeant 89.2.0.2 on tombe sur au moins trois TTLs différents: % dig s4.noelshack.com @89.2.0.2 ... s4.noelshack.com. 10196 IN A 176.31.102.193 % dig s4.noelshack.com @89.2.0.2 ... s4.noelshack.com. 60670 IN A 176.31.102.193 % dig s4.noelshack.com @89.2.0.2 ... s4.noelshack.com. 80688 IN A 176.31.102.193 D'autre part, il ne faut pas oublier que dans .COM, il y a 2J de TTL pour les NS, et donc qu'un des caches a encore peut être l'adresse des anciens NS (même si il était question une semaine): % dig @a.gtld-servers.net noelshack.com ns ; DiG 9.7.3 @a.gtld-servers.net noelshack.com ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 38392 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;noelshack.com. IN NS ;; AUTHORITY SECTION: noelshack.com. 172800 IN NS ns-01.odysseeinteractive.com. noelshack.com. 172800 IN NS ns-02.odysseeinteractive.fr. Pour être de bien migrer, il faut : - réduire les TTLs une semaine avant - installer la nouvelle zone sur les nouveaux NS - installer la nouvelle zone sur les anciens NS, en mettant les nouveaux enregistrements NS en plus des anciens ... - changer dans .com Faire des chancgements à la foi des NS et du contenu de la zone est tjrs un peu casse gueule ... A part ça, ça ne choque personne que les caches de NC soient récursifs depuis n'importe ou ? :) -- --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Des petits malins chez SFR ?
Le 19 novembre 2009 16:01, Jérôme Nicolle jer...@ceriz.fr a écrit : A priori non puisque la femtocell va (en tout cas devrait) se connecter via un tunnel dédié (et fortement chiffré). Quid du roaming entre femtocell et réseau mobile ? les HLR et MSC sont les mêmes ? Quid du chiffrement du tunnel ? Et si on montait un sniffer transparent entre une femtocell et sa box pour savoir exactement de quoi il retourne ? Je ne serais pas surpris d'y voir de belles portes d'entrée sur du hijacking UMTS, le retour du phreaking en somme... On peut imaginer que chez SFR il ne manque pas d'intelligence, que tout ça a sans douté été pris en compte. Ce modèle de transporter le GSM dans IP est désormais bien connu et bénéficie de quelques années d'expérience, que ce soit avec les NanoCell/FemtoCell ou en utilisant une technologie différente comme UMA. -- --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Panne electrique a Equinix St Denis
2009/7/2 David CHANIAL david...@euro-web.fr: Le Thursday 02 July 2009 11:38:07 David CHANIAL, vous avez écrit : De notre coté une coupure electrique sur de nombreuses arrivées electriques à été constaté. Visiblement une erreur humaine d'un sous-traitant d'Equinix lors d'une maintenance electrique. Il aurait été étonnant que ce soit pas la faute d'un gueux d'un sous traitant ! Peut etre meme c'était un stagiaire ! Damn; Chez Equinix, les clients forment un écosystème vital dans lequel leurs actifs informatiques critiques sont protégés et connectés Bref pipo pipo pipo comme partout quoi ... -- We're not lost, Private... We're in Normandy. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] free.fr + IPv6
Yves-Alexis Perez [EMAIL PROTECTED] écrivait (wrote) : On lun, 2007-11-05 at 18:32 -0800, Michel Py wrote: La v??rit?? toute nue c'est qu'IPv6 ca ne fait rien de mieux que v4 pour mr-tout-le-monde. Pourquoi d??penser des sous tant que tes clients ne le demandent pas? Aucun gain, rien que des emmerdes. ?? mon sens, le gain d'IPv6 (hormis pour les geeks) se situe justement au niveau de l'architecture r??seau, histoire de simplifier tout ??a (disparition du NAT, mipv6, ipsec...). Que des trucs pas forc??ments visibles pour le end user mais qui sont moins complexes en IPv6 qu'en IPv4. Quand même dire que MIPV6 est moins complexe qu'un sale VPN a secrets partages, pour finalement le même usage : se connecter au réseau de ma boite, hum, tu es sur de toi la ? En théorie tout ça est tres bien c'est sur ... En pratique les gens ont deja du mal a faire un pauvre VPN IPSEC site à site avec certificats 10 ans apres que ça ait été inventé, alors aller faire du mipv6 avec des routeurs coopérants, des routing headers vachement sioux et des certificats partout ... Quand à dire ipv6 c bien y a IPSEC c'est typiquement un langage d'informaticien : IPSEC de bout en bout est un échec grave, les mecs qui ont spécifié doivent se retourner dans leur tombes quand on voit l'usage courant qui en est fait (l'utilisation la plus populaire d'ipsec dans le monde c'est de faire du L2TP dedans avec auth par secret partagé, une grosse bidouille bien imonde comme MS sait en faire), tout le monde a bien abandonné l'idée de faire des montées de SA anonymes. Alors que ce soit en V4 ou V6, je ne vois en rien ce qui change. Je suis vieux, j'ai commencé IP en 1987 et Internet en 1994. Deja à cette époque on nous parlait de IP-NG. 13 ans plus tard j'ai cessé de croire que ça avait encore un sens. --- Liste de diffusion du FRnOG http://www.frnog.org/
