Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Florent Daigniere via frnog]

On Mon, 2024-01-22 at 13:48 +0100, David Ponzone wrote:
> 
> Mais y a-t-il encore du traffic UDP qui mérite d’être loggué ?
> 

HTTP/3 - rfc9114



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Besoin d'avis sur l'usage d'IP privée dans les DNS publics

[Florent Daigniere]

On Wed, 2022-09-21 at 13:28 +, gaetan-fr...@pignouf.fr wrote:
> > En gros, ta bécane (laptop, serveur, ...) a le 1.1.1.1 en resolver
> > DNS et
> > quand elle recherche www.google.com, elle récupère 216.58.214.163.
> > Par
> > contre sur une recherche du genre "mon-serveur-
> > interne.monentreprise.fr" et
> > bien le serveur DNS répond 192.168.0.100.
> > 
> > Techniquement, ça marche.
> 
> Oui plutôt pas mal, sauf avec les résolveurs de certains FAI qui
> veulent ton bien en répondant un NXDOMAIN (pas sur) quand c'est une IP
> RFC1918 (Coucou Free et Numericable).

C'est pas un bug c'est une feature, cf 
https://en.wikipedia.org/wiki/DNS_rebinding

Il est bien entendu possible d'avoir une liste blanche de domaines pour
lesquelles la protection ne doit pas s'appliquer.

Florent


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] MIkrotik + r11e-lte

[Florent Daigniere]

On Wed, 2018-04-25 at 10:24 +0200, Olivier Lange wrote:
> Le 25 avril 2018 à 09:52, Julien Escario  a
> écrit :
> 
> > Le 25/04/2018 à 09:08, Olivier Lange a écrit :
> > > Hello,
> > > 
> > > Comme je sais qu'il y a des spécialistes Mikrotik dans le coin, je
> > > tente.
> > > 
> > > Est-ce que vous avez une conf spéciale avec les modems 4G r11e-lte 
> > > de
> > > Mikrotik? Je suis en train d'en tester un, sur un RB912UAG. Il
> > > monte, pas
> > > de soucis, ca fonctionne. Par contre je suis un peu surpris des
> > > débits,
> > 
> > car
> > > je plafonne à 16mbps en dl et 4mbps en up. Alors que si je fais le
> > > même
> > > test de perf depuis un samasung S7 (meme puce bouygue ou Orange),
> > > je
> > 
> > monte
> > > à 30mbps symétrique.
> > 
> > Y'a pas une histoire d'émulation ppp vs lte ? Il me semble avoir lu
> > un truc
> > comme ça sur les forums krotik.
> > 
> 
> Si, il y a ca, qui permets de passer en ppp et pas en lte. Ce qui
> induit
> une perte de vitesse. Mais pour le coup, je suis bien en LTE
> directement,
> donc en pci.
> 
> 
> > 
> > Tu as aussi des ports PCIe qui sont raccordés au système via un port
> > USB
> > émulé.
> > 
> > Et pour finir, je me suis heurté à une blague sur le port PCIe
> > embarqué sur
> > lequel il fallait noircir des pins de la carte pour qu'elle soit
> > reconnue.
> > Je
> > n'arrive plus à retrouver l'info. Mais là, ce n'était pas un
> > problème de
> > débit
> > mais de non-détection de la carte, tout simplement.
> > 
> 
> Pas mal celle la :D.
> 
> Par contre, y a des trucs que je n'arrive pas a comprendre... Du coup,
> j'ai
> fais des tests complémentaire, et j'ai mis ma carte SIM dans un
> teltonika.
> Et la, j'ai les même débits que sur Mikrotik ( à 10% prêt). Soit
> toujours
> 50% moins rapide qu'une samsung S7!
> 
> Est-ce qu'il y aurait un bridage lié au matériel? 

duh!

Tu compares un modem classe 4
https://mikrotik.com/product/r11e_lte_us

avec un telephone classe 9...

https://fr.wikipedia.org/wiki/LTE_Advanced#Cat%C3%A9gories_de_terminaux_mobiles

Florent

signature.asc
Description: This is a digitally signed message part

Re: [FRnOG] [TECH] Fwd: L'un d'entre vous connait ils les serveurs NTP+GPS de Galleon ?

[Florent Daigniere]

On Thu, 2016-08-04 at 14:20 +0200, Pierre Emeriaud wrote:
> Le 4 août 2016 à 10:27, Benoît Grangé  a
> écrit :
> > 
> > 
> > Dans ce cas je sais bien qu'il y a une dépendance avec le GPS US,
> > mais je
> > ne crois pas qu'il y ai déjà des équipement NTP utilisant Galliléo.
> 
> Il n'y a pas que les satellites pour avoir une base de temps. Le
> DCF77
> de Mainflingen ou le signal France Inter (TDF) à 162kHz diffusent un
> signal d'horloge très précis. Il y a des récepteurs DCF77 chez
> Meinberg, ça doit être également possible d'avoir la même chose pour
> l'émetteur d'Allouis (attention toutefois à la pérennité du 162, il
> est -était ?- prévu de l'éteindre en fin d'année).
> 

Ou plus simplement, https://en.wikipedia.org/wiki/NITZ (ou son
successeur en 3g/4g s'il y a besoin de précision).

Florent

signature.asc
Description: This is a digitally signed message part

Re: [FRnOG] [MISC]Hotspot

[Florent Daigniere]

Je suis curieux de savoir "comment" ca marche en pratique; En
particulier:

1) comment tu geres le grey-listing?
2) comment tu fais pour t'assurer que ton portail "marche"? 90% des
portails que j'ai vu deployes ne marchent pas.

Les causes du "ca marche pas" varient mais les plus courantes:
 - le client essaie de faire une verification du certificat via OSCP
 - le certificat est auto-signe/expire/pas valide

Florent

On Tue, 2015-12-15 at 11:32 +0100, David Ponzone wrote:
> Xavier,
> 
> t’es un puriste :)
> J’ai ça en prod dans plusieurs restos/bars, et ça se passe bien.
> 
> Dans 99% des cas au moins, l’email arrive dans les …disons 1 minute ?
> Pour les 1% qui restent, tant pis pour eux, ils n’avaient qu’à
> prendre un fournisseur qui n’utilise plus UUCP.
> 
> Le plus gros fail, c’est pas le mail qui arrive après 5 min.
> C’est l’utilisateur qui est pas foutu de taper son mail sans faire de
> faute :)
> D’ailleurs, mention spéciale pour les touristes étrangers: ils ont
> vraiment du mal avec ça, je sais pas pourquoi :)
> 
> > Le 15 déc. 2015 à 11:24, Xavier Beaudouin  a écrit :
> > 
> > Hello,
> > 
> > > Il y a quand même des portails qui vérifient l’email en
> > > t’envoyant ton mot de
> > > passe dessus (et ils laissent le portail ouvert pendant 5 min
> > > pour te laisser
> > > le temps de le récupérer).
> > > Mais avec la facilité pour ouvrir un mail bidon mais qui marche,
> > > ça sert de
> > > toute façon à rien pour contrer les méchants.
> > 
> > Heu 5 minutes? Encore de la pure stratégie de l'échec. Depuis quand
> > on est garantit qu'un mail arrive dans les 5 minutes ?
> > AFAIK il n'y a aucune RFC garantissant que le mail arrive dans les
> > 5 minutes. Surtout que le mail est store and forward, donc il peux
> > aussi bien arriver dans la minute que dans 5 jours.
> > 
> > Encore une fois, une autre méthode pour perdre des clients... 
> > 
> > > On va y arriver au passeport numérique obligatoire pour accéder à
> > > Internet.
> > > Oui je sais, ça ne sera plus l’Internet libre et tout ça
> > 
> > Déjà un passeport numérique obligatoire pour l'administration d'un
> > serveur de mail et ça ferait de l'air pour virer les rigolos qui
> > font n'imp avec le mail...
> > 
> > Xavier
> > 
> > 
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

signature.asc
Description: This is a digitally signed message part

Re: [FRnOG] [MISC] Message ANSSI

[Florent Daigniere]

On Fri, 2015-01-16 at 01:48 +0100, Emmanuel Thierry wrote:
 Le 15 janv. 2015 à 14:11, Florent Daigniere a écrit :
 
  On Thu, 2015-01-15 at 13:38 +0100, Swali 13 wrote:
  Bonjour,
  
  L'ANSSI vous parle
  
  http://www.ssi.gouv.fr/fr/guides-et-bonnes-pratiques/recommandations-et-guides/securite-des-applications-web/recommandations-pour-la-securisation-des-sites-web.html
  ---
  
  La question c'est de savoir si ça vaut la peine de les écouter :)
  Certaines des recommandations tombent sous le sens.. d'autre sont
  complètement farfelues
 
 Au contraire ça me parait très équilibré, avec une approche aussi bien sur 
 l'hébergement que sur le code en lui même.
 Le seul problème que je vois est qu'il ne sera probablement jamais lu par les 
 gens qui en ont vraiment besoin...
 

ça frustre les spécialistes et ça n'aide pas les gens qui n'y
connaissent rien.

Les recommendations devraient être plus simple:
R19 - Les identifiants de session doivent être imprévisibles
aléatoires il faut des notions de statistiques pour comprendre
entropie il faut des notions de théorie de l'information

R20 - TLS de partout

  
  Exemples :
  
  R19
  Les identifiants de session doivent être aléatoires et d’une entropie
  d’au moins 128 bits.
  
  - 128bits pour une attaque en ligne... c'est beaucoup et complètement
  arbitraire
 
 Il faut bien placer une limite, qui par ailleurs soit durable dans le temps. 
 En même temps 128bits d'entropie ce n'est pas vraiment compliqué à générer.
 

Là n'est pas la question; quand on est aussi précis que ça dans une
recommendation, qu'il y ait une bonne raison derrière. Là il n'y en a
pas et le vocabulaire utilisé est un vocabulaire de spécialiste.

Le bon contrôle contre les identifiants de session trop courts c'est de
limiter la durée de vie de celle ci.

 
  
  R20
  Il faut recourir à chaque fois que c’est possible au protocole HTTPS dès
  lors que l’on associe une session à des privilèges particuliers.
  
  - ce n'est pas réducteur du tout comme approche. C'est bien connu,
  l'authentification ça ne sert que dans un sens ;)
 
 L'idée dans ce cas est surtout de protéger les credentials de l'utilisateur 
 et la confidentialité des informations.


Et c'est bien ce que je reproche a cette recommendation.

TLS ça sert avant tout a authentifier le site auquel on est connecte.

TLS ça se déploie sur tout le site, pas uniquement post-authentification
(pour la raison mentionnée au dessus)

 Je crois que c'est clair dans le texte :
 En chiffrant les communications au moyen de TLS, on empêche un attaquant qui 
 « écoute » le réseau d’apprendre les identifiants de sessions. Certains sites 
 ont recours à TLS uniquement pour la page d’authentification. Cela protège 
 certes le mot de passe mais pas l’identifiant de session.
 
 Par ailleurs ils parlent des certificats client en R4, mais pour 
 l'administration seulement, parce que ça parait compliqué de faire installer 
 par chaque utilisateur un certificat.
 
 Cordialement
 Emmanuel Thierry




signature.asc
Description: This is a digitally signed message part

Re: [FRnOG] [MISC] Message ANSSI

[Florent Daigniere]

On Thu, 2015-01-15 at 13:38 +0100, Swali 13 wrote:
 Bonjour,
 
 L'ANSSI vous parle
 
 http://www.ssi.gouv.fr/fr/guides-et-bonnes-pratiques/recommandations-et-guides/securite-des-applications-web/recommandations-pour-la-securisation-des-sites-web.html
 ---

La question c'est de savoir si ça vaut la peine de les écouter :)
Certaines des recommandations tombent sous le sens.. d'autre sont
complètement farfelues

Exemples :

R19
Les identifiants de session doivent être aléatoires et d’une entropie
d’au moins 128 bits.

- 128bits pour une attaque en ligne... c'est beaucoup et complètement
arbitraire

R20
Il faut recourir à chaque fois que c’est possible au protocole HTTPS dès
lors que l’on associe une session à des privilèges particuliers.

- ce n'est pas réducteur du tout comme approche. C'est bien connu,
l'authentification ça ne sert que dans un sens ;)

R24
Pour les actions sensibles, mettre en place des mécanismes permettant de
s’assurer de la légitimité de la requête.

- on parle de click-jacking, ... mais pas d'anti-CSRF



signature.asc
Description: This is a digitally signed message part

Re: [FRnOG] [BIZ] Société pour tests d'intrusion sur accès Internet

[Florent Daigniere]

A Matta c'est notre coeur de metier depuis 1998. On ne travaille qu'en anglais 
par contre...

https://www.trustmatta.com 


On Mon, 2014-10-27 at 17:28 +0100, Julien Schafer wrote:
 Bonjour la liste
 
 Un de nos clients recherche une entreprise spécialisée dans les tests de ce 
 type.
 
 Ils veulent éprouver leur plateforme d'accès à Internet. Ceci signifie que le 
 prestataire doit chercher à rentrer par tous les moyens possibles en essayant 
 de trouver des failles sur tous les services « visibles ». Bien évidemment il 
 y aura un rapport à remettre à la fin sur tous les « trous » identifiés.
 
 Si vous avez besoin de plus d'infos n'hésitez pas à me MP.
 
 Je suis preneur de vos retours si vous avez connaissance de prestataires 
 honnêtes et sérieux en la matière. En l'occurrence on recherche surtout de la 
 compétence technique, le blabla et les powerpoint on peut oublier.
 
 Merci d'avance.
 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Attaques par amplification NTP

[Florent Daigniere]

On Fri, 2014-01-17 at 01:17 -0800, Michel Py wrote:
  Jérémy Martin a écrit:
  A ceux qui n'ont pas peur de limiter les attaques en SORTIE de leur 
  réseau, n'oubliez pas d'intégrer un petit shapping sur vos routeurs 
  pour le port 123 UDP, vous rendrez service à plein de petits réseaux 
  (80% des AS).
 
 +1, à condition que ça ne devienne pas un trou noir pour des jours. Un client 
 NTP qui perd un paquet, c'est pas important. Par contre, faut pas que ça dure 
 éternellement, donc lire les traps.
 
 
  Rémi Bouhl a écrit:
  Ou BCP38 : http://tools.ietf.org/html/bcp38 pour ceux
  qui hébergent à leur insu les machines attaquantes, non ?
 
 BCP38 c'est bien sympa, mais c'est un de ces paratonnerres à emmerdes: ca 
 suppose que le client n'est pas con, et qu'il ne fait jamais d'erreurs. C'est 
 doublement faux: 1. Les clients cons, on les garde tant qu'ils paient et 2. 
 Quand ils arrivent aux stade j'en connais juste assez pour être dangereux 
 c'est encore pire. Tu leurs vends du transit, ils ont le droit de d'utiliser 
 comme route par défaut même venant d'un préfixe qu'ils ne t'annoncent pas.
 
 Le client que tu bloques au nom de BCP38 et qui perd des paquets parce qu'il 
 a merdé une route-map, il est perdu à jamais. Dans la moitié des cas, il ne 
 t'annonce plus le préfixe parce qu'il veut troubleshooter quelque chose, 
 l'autre moitié c'est qu'il est 3 heures du mat et qu'il a plus important à 
 penser. Dans les deux cas, tu aggraves son problème. Même si il a merdé dans 
 sa config, en le bloquant tu amplifies ses emmerdes, et comme il te paie ça 
 devient les tiennes.
 
 Michel.
 

T'as raison; appliques la logique jusqu'au bout... le transit que tu lui
vends (et qui est utilise pour une attaque, vu que tu n'es pas
regardant) il n'est plus a vendre.

CQFD.

Florent


signature.asc
Description: This is a digitally signed message part

Re: [FRnOG] [TECH] Attaques par amplification NTP

[Florent Daigniere]

On Fri, 2014-01-17 at 01:46 -0800, Michel Py wrote:
  Michel Py a écrit:
  Le client que tu bloques au nom de BCP38 et qui perd des paquets parce 
  qu'il
  a merdé une route-map, il est perdu à jamais. Dans la moitié des cas, il ne
  t'annonce plus le préfixe parce qu'il veut troubleshooter quelque chose,
  l'autre moitié c'est qu'il est 3 heures du mat et qu'il a plus important à
  penser. Dans les deux cas, tu aggraves son problème. Même si il a merdé
  dans sa config, en le bloquant tu amplifies ses emmerdes, et comme il te
  paie ça devient les tiennes.
 
  Florent Daigniere a écrit:
  T'as raison; appliques la logique jusqu'au bout... le transit que
  tu lui vends (et qui est utilise pour une attaque, vu que tu n'es
  pas regardant) il n'est plus a vendre.
 
 Ah pardon, il est déjà vendu. Dans le cas typique ou tu factures à 95% tile, 
 plus le client héberges des attaqueurs plus tu gagnes du pognon.

La logique est la même dans l'autre sens: plus t'héberges de gens qui se
font attaquer plus tu gagnes du pognon... donc attaques = pognon.

  Comme tu veux garder le client, tu as l'appeler et lui dire que si il arrête 
 pas la connerie ça va lui coûter la peau des glaouis, mais là tu deviens le 
 héro qui le prévient qu'il a un problème, au lieu du monkey script qui bloque.

Heuh, appeler le client ça veut dire passer du temps a faire quelque
chose qui va limiter l'entrée de pognon... alors que c'est du temps que
tu pourrait passer a démarcher de nouveaux clients.

  Le problème de BCP38 c'est que c'est trop automatisé. Personne n'appelle le 
 client pour lui dire qu'on bloque son trafic parce qu'il a merdé quelque 
 chose dans sa config.
 

J'ai raté une étape là... c'est trop ou pas assez automatisé?

 Le client est roi. Si tu le fais chier un jour ou il n'y a aucune attaque en 
 cours, tes concurrents te remercient.
 

Si tu ne fais rien tes concurrents te remercient aussi. Ils sont dans le
même business que toi: attaque = pognon. Ca reste vrai que tu sois la
source ou la destination.

Florent


signature.asc
Description: This is a digitally signed message part

Re: [FRnOG] [TECH] Chassons le résolveur DNS ouvert

[Florent Daigniere]

Bonjour Stephane,

Fermer les resolveurs ouverts ne résout pas le problème des DDoS
amplifiés par DNS. Le jour où il n'y aura plus de serveur récursifs sur
Internet (et ce n'est pas demain la veille), les attaques se feront sur
les serveurs autoritaires.

Il est plus facile de construire une liste de serveurs autoritaires que
d'open-resolvers!

La bonne solution c'est BCP-38 (rfc3704).

Cordialement,
Florent
PS:
Fermer les resolveurs ouverts, oui; mais pour différentes raisons:
- least privilege
- cache poisoning
- cache snooping


On Sun, 2013-04-07 at 21:59 +0200, Stephane Bortzmeyer wrote:
 Compte-tenu du danger de ces résolveurs ouverts, dénoncé depuis
 longtemps
 http://www.bortzmeyer.org/fermer-les-recursifs-ouverts.html
 http://www.rfc-editor.org/rfc/rfc5358.txt, et récemment illustré par
 l'attaque contre Spamhaus/Cloudflare, ce travail est l'occasion de se
 livre à une chasse aux résolveurs DNS ouverts sur votre
 réseau. Indiquez votre numéro d'AS à l'auteur et il vous indiquera les
 adresses dangereuses chez vous.
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 MHTML Document attachment (Open Resolver Dataset Update)
   Forwarded Message 
  From: Jared Mauch ja...@puck.nether.net
  To: NANOG Group na...@nanog.org
  Subject: Open Resolver Dataset Update
  Date: Sun, 7 Apr 2013 13:46:14 -0400
  
  I've continued to update my dataset originally posted about two weeks ago.  
  Please take a moment and review your CIDRs which may be running an open 
  resolver.
  
  I've exposed one additional bit in the user-interface that may be helpful.  
  Some DNS servers will respond with RCODE=0 (OK) but not provide recursion.  
  nearly 90% of the servers in the database provide recursion.
  
  Some raw stats are also available via the 'breakdown' link on the main site.
  
  If you operate a DNS server, or have an internal group that does, please 
  take a moment and review your networks.
  
  If you email me in private from a corporate address for your ASN, I can 
  give you access to a per-ASN report.
  
  Due to a change in methodology, I have increased the number of servers 
  observed from 27.2 million to 30.2 million hosts.
  
  2013-04-07 results
  
  30269218 servers responded to our udp/53 probe
  731040 servers responded from a different IP than probed
  25298074 gave the 'correct' answer to my A? for the DNS name queried.
  13840790 responded from a source port other than udp/53
  27145699 responses had recursion-available bit set.
  2761869 returned REFUSED
  
  In addition, please do continue to deploy BCP-38 to prevent spoofing 
  wherever possible.  I know at $dayjob we have been auditing this and 
  increased the number of customer interfaces that can not spoof.
  
  - Jared



signature.asc
Description: This is a digitally signed message part

Re: [FRnOG] Re: [TECH] Chassons le résolveur DNS ouvert

[Florent Daigniere]

On Mon, 2013-04-08 at 10:19 +0200, Stephane Bortzmeyer wrote:
 On Mon, Apr 08, 2013 at 09:03:48AM +0100,
  Florent Daigniere florent.daigni...@trustmatta.com wrote 
  a message of 100 lines which said:
 
  Fermer les resolveurs ouverts ne résout pas le problème des DDoS
  amplifiés par DNS.
 
 En sécurité (ou en santé publique, domaine qui a beaucoup de points
 communs avec la sécurité de l'Internet) aucune mesure ne « résoud »
 les problèmes. On les minimise, c'est tout.
 
  Le jour où il n'y aura plus de serveur récursifs sur Internet (et ce
  n'est pas demain la veille),
 
 On peut dire cela (« ça va prendre des siècles ») de toutes les
 campagnes d'hygiène informatique (exemple de BCP 38 cité plus
 bas). C'est plutôt pour moi une raison pour commencer tout de suite.
 
  les attaques se feront sur les serveurs autoritaires.
 
 Je prends ma casquette de nazi grammairien deux secondes : un adjudant
 est autoritaire. Un serveur DNS fait autorité.
 
 Ensuite, je repasse à la technique : il y a déjà eu des attaques sur
 les serveurs faisant autorité. Comme toujours en sécurité (ou en santé
 publique), la question n'est pas trouver LA bonne technique. Il
 n'existe pas de balle en argent (comme disent les compatriotes de
 Stephenie Meyer). Il faut fermer les résolveurs ouverts *et* il faut
 sécuriser les serveurs faisant autorité.
 

Un problème peut avoir une solution ultime. Dans ce cas précis, si le
problème est: Les attaques DDoS par amplification DNS, la solution
c'est d'empêcher le spoofing à la source; pas de changer la
configuration des serveurs DNS.

 Ceci dit, si les serveurs faisant autorité présentent quelques
 avantages pour les attaquants (grosses machines bien connectées), ils
 ont aussi des inconvénients (contrairement aux résolveurs ouverts, ce
 sont en général des machines gérées, donc surveillées et avec
 déploiement de contre-mesures - comme la limitation de trafic).
 
  Il est plus facile de construire une liste de serveurs autoritaires
  que d'open-resolvers!
 
 Comme le montre le travail cité au début de ce fil, construire une
 liste de serveurs résolveurs ouverts est possible (et pas spécialement
 difficile, sans vouloir dire du mal de l'excellent travail de Jared
 Mauch).
 
  La bonne solution c'est BCP-38 (rfc3704).
 
 Mais c'est quoi cettte obsession de LA bonne et vraie solution ? Dans
 le monde réel, cela n'existe jamais. Si les geeks voulaient bien
 sortir de l'informatique et étudier les domaines qui ont ce genre de
 problème depuis des siècles (lutte contre la délinquance, santé
 publique), ils sauraient qu'il n'y a pas de solution magique, qu'il
 faut attaquer sur plusieurs fronts à la fois. 
  

Si BCP-38 était implémenté, cela résoudrait toute une famille d'attaques
par amplification - DNS, mais aussi smurfing, ...
https://en.wikipedia.org/wiki/Smurf_attack

 Se demander s'il faut déployer BCP 38 OU BIEN fermer les résolveurs
 ouverts, c'est aussi à côté des pompes que de se demander s'il vaut se
 laver les mains OU BIEN développer des antibiotiques. IL FAUT LES DEUX.
 

Je ne suis pas d'accord. Ni sur le fond, ni sur le choix de la
métaphore. C'est un cas classique: Donner des solutions sans formuler
le problème.

Le problème c'est vous qui l'avez formulé: premier paragraphe sur votre
blog:
Suite, notamment, à une nouvelle attaque

  - cache poisoning
  - cache snooping
 
 Ces deux problèmes ne gènent que les utilisateurs du résolveur
 ouvert. Les attaques par amplification gênent tout l'Internet.
 

On est d'accord sur ce point.


signature.asc
Description: This is a digitally signed message part

Re: [FRnOG] [MISC] [MICHU] Trolldi / phénomène étrange Orange end-user

[Florent Daigniere]

On Fri, 2012-11-16 at 15:17 +0100, Solarus wrote:
 On Fri, 16 Nov 2012 15:12:15 +0100, Fabien V. list-fr...@beufa.net
 wrote:
  On est d'accord, mais ca reste aussi dégueu' que du CGN / NAT444 !
 
 Pas du tout.
 
 Contrairement au CGN, tu as un IPv4 publique propre à ta connexion,
 avec 65535 ports utilisables en sortie et en entrée.

65536 (2^16)

Florent


signature.asc
Description: This is a digitally signed message part

Re: [FRnOG] [TECH] Vous avez perdu le mot de passe de votre F5 BIG-IP ?

[Florent Daigniere]

T'as mal lu: la clef est sur toute les appliances!

Florent

On Mon, 2012-06-11 at 17:20 +0200, Alain Thivillon wrote:
 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/



signature.asc
Description: This is a digitally signed message part

Re: [FRnOG] [TECH] Vous avez perdu le mot de passe de votre F5 BIG-IP ?

[Florent Daigniere]

Je ne suis pas sur de comprendre ce que tu suggeres...

Que le constructeur n'a pas reagi assez vite? Que le constructeur n'a
pas donne assez de temps a ses clients pour corriger le bug? Autre
chose?

L'annonce originale:
https://www.trustmatta.com/advisories/MATTA-2012-002.txt

Florent
PS: c'est moi qui ai tue le bug 

On Mon, 2012-06-11 at 17:52 +0200, Guillaume Barrot wrote:
 Le pire dans l'histoire  c'est que la faille est decouverte en fevrier,
 mais que le constructeur commence a prevenir ses clients fin mai pour une
 annonce publique en juin...
 Le 11 juin 2012 16:57, Stephane Bortzmeyer bortzme...@nic.fr a écrit :
 
  Pas de problème pour le récupérer :-)
 
  http://www.exploit-db.com/exploits/19064/
 
 
  ---
  Liste de diffusion du FRnOG
  http://www.frnog.org/
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/



signature.asc
Description: This is a digitally signed message part

Re: [FRnOG] [TECH] Vous avez perdu le mot de passe de votre F5 BIG-IP ?

[Florent Daigniere]

Bof, c'est mieux que la moyenne. Ce bug affecte 3-4 versions majeures,
XX branches, ... perso je trouve qu'ils ne s'en sortent pas mal.

Au moins eux ils corrigent leur bugs...

http://www.zerodayinitiative.com/advisories/upcoming/
http://www.slideshare.net/denimgroup/remediation-statistics-what-does-fixing-application-vulnerabilities-cost

Florent

On Mon, 2012-06-11 at 18:55 +0200, Jérôme Nicolle wrote:
 Le 11/06/12 18:47, Florent Daigniere a écrit :
  Que le constructeur n'a pas reagi assez vite?
 
 Objectivement, 3 mois pour corriger et prévenir sur une faille aussi
 critique, ça fait un peu long, non ?
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/



signature.asc
Description: This is a digitally signed message part

[FRnOG] [MISC] contact chez dyn.com

[Florent Daigniere]

Salut,

Est-ce que quelqu'un a un contact chez dyn.com?
Une sombre histoire d'abuse... urgente

Amicalement,
Florent


signature.asc
Description: This is a digitally signed message part