[FRnOG] [ALERT] Vulnérabilité critique Checkpoint VPN - CVE-2024-24919

[Florent Daigniere via frnog]

Pour ceux qui sont trop distraits par les digressions du vendredi et qui
ont raté CVE-2024-24919

https://x.com/DevSecAS/status/1796145388581278065
https://support.checkpoint.com/results/sk/sk182336


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

Re: Re :Re: [FRnOG][MISC] Digression du Vendredi sur l'identité numérique

[Florent Daigniere via frnog]

On Sat, 2024-06-01 at 13:09 +0200, lm2 via frnog wrote:
> bonjour,
> 
> mais la récupération du colis avec sa CNI propre et originale, n'est
> elle simplement plus simple?
> 

Ce n'est pas la question: il y a bon nombre d'usagers qui ont toujours
un téléphone dans la poche mais n'ont pas leur papiers.

Le colis est un mauvais exemple: Il n'y a pas de besoin
d’authentification forte: le livreur se contre-fou d'où et à qui il le
donne.

> vous aurez compris que le commerce qui m'exige une appli sur
> smartphone, je lui exhibe mon 3310 pour ma défense :)
> 

Je n'ai aucun problème avec ça pour un colis.

> 
> à l'instar de prendre un ticket pour le train/métro (qui est largement
> possible sans téléphone), je pige pas pourquoi récupérer un colis
> dérogerait à la règle..
> 
> quid si le tel est volé?oublié?perdu?batterie hs?
> 
> pour moi il sert qu'à communiquer, surtout rien d'autre.. trop
> volatile!
> 

Certain usages requièrent une vérification de l'identité plus ou moins
approfondie. Pour rester dans l'exemple du bureau de poste, il y a
retirer un colis, retirer un recommandé, ouvrir un compte et souscrire
un prêt.

Il est pour l'instant accepté de montrer une CNI sans smartcard que le
postier/banquier n'a aucun moyen de vérifier (sans parler du cas où la
CNI n'est pas française)... ou d'utiliser l'identité numérique laposte
(à base de photos de documents, comme l'a fait Gael) mais il n'est pas
accepté d'utiliser France Identité sur son téléphone (qui lui permet
l'authentification forte). Chercher l'erreur...

Dans tous ces cas la solution est technologique et il faudrait que le
postier ait des outils adéquats. Penser que l'on peut former les
postiers de manière efficace pour identifier des faux est naif... et il
est évident que si on leur en donne la possibilité ils trouveront des
circonstances dans lesquelles ils s'affranchiront du contrôle.


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

Re: [FRnOG] [MISC] Digression du Vendredi sur l'identité numérique

[Florent Daigniere via frnog]

On Sat, 2024-06-01 at 12:13 +0200, Xavier Beaudouin via frnog wrote:
> > Je prêche que l'état devrait fournir un service de SSO utilisable
> > par de
> > tierces parties et qu'au lieu de forcer les prestataires à faire son
> > boulot (stocker des données sensibles "au cas où"), il devrait
> > forcer
> > ces prestataires à utiliser cette solution. Cela permettrai
> > d'améliorer
> > le modèle de sécurité, de simplifier les procédures (pour tout le
> > monde:
> > l'utilisateur, le prestataire et l'état) et d'être plus efficace.
> > 
> > C'est ma conviction intime, d'expert non-intéressé. Ma (petite)
> > boite
> > n'a rien à gagner dans cette histoire... mais en tant qu'individuel
> > je
> > pense que c'est la meilleure solution.
> 
> 
> Dans d'autres pays il y a des GIE pour ça... Exemple au Luxembourg,
> que je connais bien, il y a Luxtrust.
> 
> J'dis pas que ce sont les meilleurs, mais avec le token physique
> (hélas en voie de disparition), la carte d'identité Luxo, ou
> l'application mobile, se connecter/signer avec truc équivaut a une
> signature officielle de l'intéressé.
> 
> Comme d'habitude en France on fait n'importe quoi, chacun dans son
> silo, personne ne communique ensemble et chacun fait n'importe quoi
> avec les données.
> 
> Entre France Connect, France Connect+ (dafuq?), France Identité
> (évidement quand on a une vieille CNI on peux se brosser avec une
> brosse métallique), bref tout pour faire mal ce qu'on pourrais fait
> mieux. Et je ne parle pas de "truster" laposte avec les 1 TLD tous
> fais pour que tout le monde s'habitue au phishing industriel...
> 
> Xavier

Nous sommes d'accord. Il n'y a aucune vision stratégique et il semble
que toutes ces initiatives n'apprennent ni de leur erreurs ni de celles
des autres.

Pour qu'un tel système fonctionne il faut:
   - de l'authentification forte (on a déjà payé pour et on sait faire:
   des smartcards dans les papiers d'identité ou les secure-
   elements/TPMs)
   
   - que ce soit utilisable (features, contraintes de disponibilité,
   ...)
   
   - qu'il y ait une bonne raison de justifier le changement (de toutes
   les parties: ceux qui implémentent, les utilisateurs, ...)

Pour l'instant il n'y a aucune initiative qui traite du troisième point
alors que c'est le plus important. Les solutions c'est comme souvent la
carotte et le baton...

Prenons un exemple précis proche des problématiques que les lecteurs de
la liste rencontrent: pour vendre une carte SIM il faut connaître
l'identité du client. L'opérateur se contre-fou de à qui il la vend...
mais il est obligé de conserver des justificatifs d'identité. Si demain
l'état accouche de France Connect++, il n'y aura aucun intérêt pour
l'opérateur de l'implémenter (et de remplacer l'existant) si
l'obligation de conserver ces justificatifs perdure. Il y a bien entendu
la solution de l'y contraindre (on aime bien les obligations sans
sanctions en France) mais il serait beaucoup plus simple et sécurisé
pour tout le monde d'utiliser une solution de SSO. Le client pourrait
être pseudo-anonyme vis à vis de l'opérateur et souscrire plus
simplement/rapidement, l'opérateur pourrait réduire ses coûts et la
friction pour acquérir de nouveaux clients, l'état conserve la
possibilité de faire le lien (et de s'impliquer si besoin - y compris si
le client est un mauvais payeur).

J'ai pris l'exemple d'une carte SIM mais il y en a bien entendu d'autres
(identification des utilisateurs en WiFi, ...).


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

Re: [FRnOG] [MISC] Digression du Vendredi sur l'identité numérique

[Florent Daigniere via frnog]

On Sat, 2024-06-01 at 09:59 +0200, Laurent Barme wrote:
> 
> Le 01/06/2024 à 09:53, Florent Daigniere via frnog a écrit :
> 
> > Si tu cherches un argument d'autorité je peux t'en donner un aussi.
> > C'est mon métier: la boite pour laquelle je travaille fait des
> > prestations d'audit en sécurité (dont des audits de mot de passe)
> > depuis
> > des décennies et vends des produits
> 
> [pub]
> 
> > (une solution
> > pour Active Directory, toujours autour des mots de passe).
> > 
> > Je pense avoir une opinion éclairée sur le sujet.
> > 
> > 
> > 
> Ah d'accord, tu travailles dans le security business…
> 
> Je comprends mieux
> 

Au vu de tes insinuations, j'en doute.

Je prêche que l'état devrait fournir un service de SSO utilisable par de
tierces parties et qu'au lieu de forcer les prestataires à faire son
boulot (stocker des données sensibles "au cas où"), il devrait forcer
ces prestataires à utiliser cette solution. Cela permettrai d'améliorer
le modèle de sécurité, de simplifier les procédures (pour tout le monde:
l'utilisateur, le prestataire et l'état) et d'être plus efficace. 

C'est ma conviction intime, d'expert non-intéressé. Ma (petite) boite
n'a rien à gagner dans cette histoire... mais en tant qu'individuel je
pense que c'est la meilleure solution.

De toute façon le mouvement est déjà en route, la seule question est de
savoir si c'est un GAFAM qui remplira le role de l'état (au détriment de
tous) en étant le premier a fournir "un coffre fort numérique amélioré".



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

Re: [FRnOG] [MISC] Digression du Vendredi sur l'identité numérique

[Florent Daigniere via frnog]

On Fri, 2024-05-31 at 20:37 +0200, Laurent Barme wrote:
> 
> Le 31/05/2024 à 19:10, Florent Daigniere a écrit :
> …
> > par contre avoir des traitements non automatisés je n'imagine pas
> > comment cela pourrait fonctionner.
> > 
> Tu n'imagines pas comment cela fonctionnait il y a  une soixantaine
> d'année ?
> …

Très mal.

J'en veux pour preuve que dans ma famille nous avons perdu l'accent sur
notre nom et que Toussain semble avoir des problèmes similaires.

L'explication qui nous a été donnée c'est que l'accent grave ne se tape
pas bien à la machine à écrire... et que donc il a été perdu quand les
registres ont été dactylographiés (ce qui n'était pas un traitement
automatisé).

Deux générations plus tard, mon ancienne carte d'identité avait un
accent alors que mes passeports n'en ont jamais eu. Vive les traitements
non automatisés.

> > On ne doit pas vivre dans le même monde.
> Si mais manifestement pas avec la même perception.
> 
> > L'usurpation d'identité est un
> > vrai problème qui a pour source le fait que la loi impose aux
> > opérateurs
> > de services de stoker des données sensibles (dont ils n'ont pas
> > besoin
> > et qu'ils ne stockeraient pas si ils n'y étaient pas obligés) "au
> > cas
> > où".
> Ah bon.
> > 

Benh oui, le KYC a un coût tant du coté utilisateur que prestataire;
personne ne le fait pour le plaisir.

> > Si tes papiers fuient sur un service, ils seront réutilisés ailleurs
> > (donc il y a bien propagation d'incident) jusqu'à leur expiration
> > (qui
> > se mesure en décennie).
> > 
> > > > ... de partout et des utilisateurs qui réutilisent leur
> > > > mot de passe entre les services (credential stuffing).
> > > Justement, l'intérêt de mots de passe distincts par service est
> > > que si
> > > un problème survient sur un service, cela ne pollue pas les
> > > autres.
> > > 
> > Dans le vrai monde c'est le corollaire qui est vrai: les
> > utilisateurs
> > n'utilisent pas de mots de passe distincts
> Comment pourrais-tu le savoir ?
> > 

Regardes les données. Prends tous les DBIRs sur ces dernière années et
tu verras que le "top 2" c'est toujours (i) credential stuffing (ii)
social engineering/phishing (l'humain qui t'es très cher)
https://www.verizon.com/business/resources/reports/dbir/

Si tu cherches un argument d'autorité je peux t'en donner un aussi.
C'est mon métier: la boite pour laquelle je travaille fait des
prestations d'audit en sécurité (dont des audits de mot de passe) depuis
des décennies et vends des produits dont https://pwncheck.me (un
logiciel d'audit de mots de passe) et https://safepass.me (une solution
pour Active Directory, toujours autour des mots de passe).

Je pense avoir une opinion éclairée sur le sujet.


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

Re: [FRnOG] [MISC] Digression du Vendredi sur l'identité numérique

[Florent Daigniere via frnog]

On Fri, 2024-05-31 at 17:47 +0200, Laurent Barme wrote:
> 
> Le 31/05/2024 à 17:17, Florent Daigniere a écrit :
> > On Fri, 2024-05-31 at 16:51 +0200, Laurent Barme wrote:
> > > Heureusement, notre gouvernement actuel est garant d'une
> > > utilisation
> > > bienveillante de l'identité numérique. Mais demain, si un parti
> > > moins
> > > moral l'emportait…
> > C'est justement ça le vrai débat: si on ne fait pas confiance au
> > gouvernement pour l'IAM, on fait confiance à qui? un GAFAM
> > (passkeys,
> > ...)?
> On fait confiance à des humains, avec des possibilités de recours en
> cas de contestation de décision.
> 

"des humains", donc un sous traitant de GAFAM que l'on contacte par
téléphone et qui bosse dans un centre d'appel à l'étranger?

> Le problème c'est le traitement automatique d'un contrôle d'identité
> universel et omnipotent confié à un traitement informatique (c'est à
> dire buggé ou incapable de gérer les exceptions).
> 

Il peut tout a fait y avoir un opérateur unique (gouvernement ou non)
qui corrige ses bugs et gère les exceptions (avec ou sans humains)...
par contre avoir des traitements non automatisés je n'imagine pas
comment cela pourrait fonctionner.

> > La décentralisation (le modèle historique) cela a ses limites: on se
> > retrouve à disséminer tout ce qui peut servir pour
> > l'authentification à
> > trop d'intermédiaires qui ne sont ni de confiance, ni capable de
> > sécuriser les données (quand même le jeu en vaut la chandelle, ce
> > qui
> > est rarement le cas). L'état final étant l'existant ou l'on a X
> > copies
> > de ses papiers d'identité, ses justificatifs de domiciles, ses
> > identifiants,
> … et donc pas de propagation d'incident.
> 

On ne doit pas vivre dans le même monde. L'usurpation d'identité est un
vrai problème qui a pour source le fait que la loi impose aux opérateurs
de services de stoker des données sensibles (dont ils n'ont pas besoin
et qu'ils ne stockeraient pas si ils n'y étaient pas obligés) "au cas
où".

Si tes papiers fuient sur un service, ils seront réutilisés ailleurs
(donc il y a bien propagation d'incident) jusqu'à leur expiration (qui
se mesure en décennie).

> > ... de partout et des utilisateurs qui réutilisent leur
> > mot de passe entre les services (credential stuffing).
> Justement, l'intérêt de mots de passe distincts par service est que si
> un problème survient sur un service, cela ne pollue pas les autres.
> 

Dans le vrai monde c'est le corollaire qui est vrai: les utilisateurs
n'utilisent pas de mots de passe distincts et donc si l'un des services
tombe, tout tombe (sans possibilité de récupération rapide)... sans
parler du fait que les mécanismes de récupération finissent tous par
demander les même données.


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

Re: [FRnOG] [MISC] Digression du Vendredi sur l'identité numérique

[Florent Daigniere via frnog]

On Fri, 2024-05-31 at 16:51 +0200, Laurent Barme wrote:
> Heureusement, notre gouvernement actuel est garant d'une utilisation 
> bienveillante de l'identité numérique. Mais demain, si un parti moins
> moral l'emportait…

C'est justement ça le vrai débat: si on ne fait pas confiance au
gouvernement pour l'IAM, on fait confiance à qui? un GAFAM (passkeys,
...)?

La décentralisation (le modèle historique) cela a ses limites: on se
retrouve à disséminer tout ce qui peut servir pour l'authentification à
trop d'intermédiaires qui ne sont ni de confiance, ni capable de
sécuriser les données (quand même le jeu en vaut la chandelle, ce qui
est rarement le cas). L'état final étant l'existant ou l'on a X copies
de ses papiers d'identité, ses justificatifs de domiciles, ses
identifiants, ... de partout et des utilisateurs qui réutilisent leur
mot de passe entre les services (credential stuffing).



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

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: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] 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] 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  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] [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
> 
> , 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 
> > To: NANOG Group 
> > 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] [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." 
> 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]

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

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

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

[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