Auteur Sujet: BCP-162: logs, CGNat et cybercriminalité  (Lu 6414 fois)

0 Membres et 1 Invité sur ce sujet

Stilnox

  • Profil non complété
  • ***
  • Messages: 58
BCP-162: logs, CGNat et cybercriminalité
« Réponse #12 le: 15 septembre 2019 à 21:19:28 »
Comme tu l'as dit cloudflare c'est 0$/mois ... Pourquoi développer en plus un truc (qui doit intéresser 1/100 000 webmaster) sur un service "gratuit" qui fonctionne plutôt bien ?
Sans compter que pour Cloudflare c'est peut être pas si simple que çà de faire une modif sur l'infra en place.
Pour ma part si je leur ai demandé d'implèmenter ça c'est tout simplement parce que l'OCLCTIC m'ont à moitié gueulé dessus car j'enregistre pas les ports sources (c'est sûr que ça doit compliquer le travail et mener à des recherches sur plusieurs IP comme a expliqué vivien), Cloudflare m'ont dit que ce sera implèmenté uniquement si c'est un membre "d'état" (donc du gouvernement français si j'ai bien compris) qui en fait la requête. Ils envoient bien un header CF-Connecting-IP avec l'IP source forwardée, donc pourquoi pas le port source ? Après certes c'est un service gratuit, ils n'y gagneraient probablement pas grand chose.

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 816
  • 73
BCP-162: logs, CGNat et cybercriminalité
« Réponse #13 le: 15 septembre 2019 à 23:03:16 »
Pour ma part si je leur ai demandé d'implèmenter ça c'est tout simplement parce que l'OCLCTIC m'ont à moitié gueulé dessus car j'enregistre pas les ports sources (c'est sûr que ça doit compliquer le travail et mener à des recherches sur plusieurs IP comme a expliqué vivien), Cloudflare m'ont dit que ce sera implèmenté uniquement si c'est un membre "d'état" (donc du gouvernement français si j'ai bien compris) qui en fait la requête. Ils envoient bien un header CF-Connecting-IP avec l'IP source forwardée, donc pourquoi pas le port source ? Après certes c'est un service gratuit, ils n'y gagneraient probablement pas grand chose.

Solutions simples :
  • Mets l'OCLCTIC en contact avec CloudFlare et roulez jeunesse.
  • Essaie d'utiliser l'API WebRTC (en JavaScript client) pour récupérer un port source public de l'utilisateur : normalement, tu n'as rien à implèmenter côté serveur : cherche un code d'exemple qui implèmente l'API Data Channels (transfert de données en pair à par via UDP) mais ne garde que le début du code ; à un moment donné, le code JS va te retourner un bloc de données SDP (métadonnées en texte brut qui exposent notamment des informations inférées à propos de la connexion de l'utilisateur, dont son IP:port local ainsi que son IP:port public) que tu seras censé échanger avec un autre pair par tes propres moyens si tu souhaites faire du pair à pair ; plutôt que d'essayer de faire réellement du pair à pair, parse juste ce bloc de données avec une regex et tu devrais pouvoir obtenir le port source de l'utilisateur sans rien implèmenter côté serveur. Ensuite, transfère l'information IP:port obtenue en parsant les données SDP à ton serveur via un endpoint Ajax, puis logge-le (associé à un pseudo et un horodatage par exemple) dans la base de données de ton choix.
  • Créé un serveur secondaire (par exemple un VPS à moins de 2 € par mois voire un éventuel hébergement gratuit) qui ne sert qu'à recevoir un pixel invisible / une requête Ajax / une connexion Websocket et à récolter des statistiques (par exemple dans une base légère en mémoire comme un Redis puis insertion en batch vers du relationnel) pour lequel tu n'utilises pas l'intermédiation de Cloudflare. Mets éventuellement un nom de domaine banal qui utilise un DynDNS gratuit et/ou rappelle un service d'analytics, voire pas de nom de domaine du tout. Si quelqu'un effectue une attaque DDoS vers ce serveur, il ne t'embêtera pas beaucoup.

Fyr

  • Abonné Free fibre
  • *
  • Messages: 511
  • Talissieu 01
BCP-162: logs, CGNat et cybercriminalité
« Réponse #14 le: 16 septembre 2019 à 00:23:07 »
Pour ma part si je leur ai demandé d'implèmenter ça c'est tout simplement parce que l'OCLCTIC m'ont à moitié gueulé dessus car j'enregistre pas les ports sources (c'est sûr que ça doit compliquer le travail et mener à des recherches sur plusieurs IP comme a expliqué vivien), Cloudflare m'ont dit que ce sera implèmenté uniquement si c'est un membre "d'état" (donc du gouvernement français si j'ai bien compris) qui en fait la requête. Ils envoient bien un header CF-Connecting-IP avec l'IP source forwardée, donc pourquoi pas le port source ? Après certes c'est un service gratuit, ils n'y gagneraient probablement pas grand chose.


Bah si c'est une comm rogatoire y a pas plus officiel. 2 choix :
1 - tu renvoies ta réponse à la comm rogatoire en expliquant que tenu compte de ton archi il n'y a pas de réponse à la question, et que si réponse il y a elle serait chez Cloudflare en ce qui concerne les ports permettant d'avancer. Tu peux te conformer à leur demande de loguer les ports ils n'ont pas exigé qu'ils soient pertinents.
2 - tu transmets la comm rogatoire à Clouflare en leur demandant les infos. Qu'ils ont probablement pas devant la volumétrie des logs et de l'emmerdement apporté par l'existence de ces logs à gérer les commissions rogatoires ou des capacités de l'infras à pondre du log. Et te faire bouler une fois de plus.
2 bis : vous chopez le cyberprefet pour lui demander de monter une réunion avec les ingés de cloudflare et un des services de l'Intérieur compétent, vu que ca intéresse un peu "ses services" d'avoir une réponse aux comm rogatoires pour avancer sur les enquêtes. Et vous lui expliquez que dans l'attente : comm rogatoire et victimes -> poubelle.

En même temps c'est super cool de la part de Cloudflare si on est dans le camps des méchants : on s'abonne à leur services gratos et HOP plus d'inquiétude on peut faire du cybercrime occulté derrière du CG-NAT. Et vue de l'OCLCTIC vous êtes un délinquant qui essaye d'échapper ou de couvrir, pour ça qu'ils couinent. Pour l'instant ils sont pas agacés au point d'aller saisir vos serveurs, mais à 10 comm rogatoire/jour ca devient un métier là et super pas passionnant pour vous.

vivien

  • Administrateur
  • *
  • Messages: 43 568
    • Twitter LaFibre.info
BCP-162: logs, CGNat et cybercriminalité
« Réponse #15 le: 16 septembre 2019 à 10:05:24 »
Mets l'OCLCTIC en contact avec CloudFlare et roulez jeunesse.
Je pense que c'est la bonne solution.

Optix

  • AS41114 - Expert OrneTHD
  • Abonné Orne THD
  • *
  • Messages: 4 012
  • WOOHOO !
    • OrneTHD
BCP-162: logs, CGNat et cybercriminalité
« Réponse #16 le: 16 septembre 2019 à 11:19:16 »
En même temps c'est super cool de la part de Cloudflare si on est dans le camps des méchants : on s'abonne à leur services gratos et HOP plus d'inquiétude on peut faire du cybercrime occulté derrière du CG-NAT. Et vue de l'OCLCTIC vous êtes un délinquant qui essaye d'échapper ou de couvrir, pour ça qu'ils couinent. Pour l'instant ils sont pas agacés au point d'aller saisir vos serveurs, mais à 10 comm rogatoire/jour ca devient un métier là et super pas passionnant pour vous.
Non, ça ne marche pas comme ça.

Les forces de l'ordre se focalisent beaucoup sur le nom de domaine, car le bureau d'enregistrement détient des informations plus intéressantes : qui a déposé (zut un nom bidon), quelle carte bancaire a servi (et chez qui a-t-elle encore servi ? Online, bah tiens), quelles IP se sont enregistrées (zut un VPN, on va demander au presta de VPN (et TOUS répondent)). En gros, ils évitent de demander à CF, ça sert pas à grand chose selon eux. La connerie qui te fera tomber, tu l'as déjà faite avant de paramétrer ton proxy. :)

En l'espèce, si "R." est incapable de fournir les infos, c'est évidemment pour sa tronche. C'est sa décision d'avoir mis du CF devant, personne ne l'a obligé à cela, et il sait que ça occulte certaines infos importantes, et sachant cela, il persiste à l'utiliser.

Stilnox

  • Profil non complété
  • ***
  • Messages: 58
BCP-162: logs, CGNat et cybercriminalité
« Réponse #17 le: 16 septembre 2019 à 13:03:06 »
"personne ne l'a obligé à cela" -> disons qu'un acharné qui s'amuse à DDoS des journées ça m'a bien obligé à un moment à faire appel à un service d'anti-DDoS, et je pense que Cloudflare sont un des plus connus. A la base le site était hébergé sur une instance Scaleway accessible directement sans proxy comme CF.
Dans tous les cas le site est hébergé en France et les données whois sont toutes legit, la PJ (donc au dessus de l'OCLCTIC) m'ont carrèment dit que ce forum leur est utile car il leur fait office "d'honeypot", on nous a plus ou moins expliqué que c'est pour ça qu'il n'est pas fermé.

Sinon intéressant pour ta seconde option Marin, j'avais jamais trop touché au webrtc et il s'avère qu'effectivement c'est une belle mine d'or en terme d'infos côté client. Reste juste le problème qu'un mec peut bloquer/modifier l'appel à l'endpoint qui log les données.

Optix

  • AS41114 - Expert OrneTHD
  • Abonné Orne THD
  • *
  • Messages: 4 012
  • WOOHOO !
    • OrneTHD
BCP-162: logs, CGNat et cybercriminalité
« Réponse #18 le: 16 septembre 2019 à 13:16:56 »
on nous a plus ou moins expliqué que c'est pour ça qu'il n'est pas fermé.
Ouch, tu es déjà bien dans le collimateur alors. Suffit que ta tête ne revienne pas au prochain magistrat et qu'il en décide autrement...  :-X
(j'étais déjà dans cette situation et j'ai tout pris dans la gueule...)

Sinon intéressant pour ta seconde option Marin, j'avais jamais trop touché au webrtc et il s'avère qu'effectivement c'est une belle mine d'or en terme d'infos côté client. Reste juste le problème qu'un mec peut bloquer/modifier l'appel à l'endpoint qui log les données.
Selon moi, c'est pas la solution car :
- effctivement le WebRTC demande la permission d'échanger de la data, audio ou vidéo. Quand je me balade sur un forum, et que soudainemetn mon navigateur me demande ça... soit je me casse, soit je refuse.
- et aussi, du coup on voit ta véritable IP de ton serveur, c'est vraiment ce que tu veux ?

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 816
  • 73
BCP-162: logs, CGNat et cybercriminalité
« Réponse #19 le: 16 septembre 2019 à 13:52:46 »
- et aussi, du coup on voit ta véritable IP de ton serveur, c'est vraiment ce que tu veux ?

Nope, la 1ère étape de l'échange WebRTC c'est de taper sur un serveur STUN (STUN est un protocole sur UDP qui permet d'obtenir des informations sur les options de contournement de NAT possibles) public, en général celui de Mozilla ou de Google (il suffit d'en spécifier un lors de la création de l'objet RTCPeerConnection pour avoir l'IPv4 publique derrière un NAT).

La véritable adresse IP du serveur qui sert le Javascript, et qui reçoit les informations SDP en retour, n'a pas à être révélée.

- effctivement le WebRTC demande la permission d'échanger de la data, audio ou vidéo. Quand je me balade sur un forum, et que soudainemetn mon navigateur me demande ça... soit je me casse, soit je refuse.

Je viens de tester avec les dernières versions de Chrome ou de Firefox, il n'y a pas d'autorisation de demandée lors de l'appel à createOffer() ou setLocalDescription(). Seul l'usage du microphone ou de la webcam, quand il est demandé explicitement, requiert une autorisation explicite.

WebRTC peut être bloqué correctement en modifiant les paramètres avancés du navigateur, et l'obtention de la description SDP locale demandera une autorisation lors de l'utilisation de certains clients comme Tor Browser, mais à ma connaissance c'est une fonctionnalité spécifique à Tor Browser (et si ton utilisateur utilise Tor Browser, son numéro de port n'est probablement déjà plus d'une grande utilité à l'OCLCTIC).

Dans tous les cas le site est hébergé en France et les données whois sont toutes legit, la PJ (donc au dessus de l'OCLCTIC) m'ont carrèment dit que ce forum leur est utile car il leur fait office "d'honeypot", on nous a plus ou moins expliqué que c'est pour ça qu'il n'est pas fermé.

C'est intéressant, j'avais déjà entendu ce discours venant de l'OCLCTIC (pas pour un truc à moi).

Sinon intéressant pour ta seconde option Marin, j'avais jamais trop touché au webrtc et il s'avère qu'effectivement c'est une belle mine d'or en terme d'infos côté client. Reste juste le problème qu'un mec peut bloquer/modifier l'appel à l'endpoint qui log les données.

Il suffit de s'assurer que l'adresse IP matche avec celle observée concernant le client pour ne pas polluer la base (quoique tu perds des cas intéressants où WebRTC contourne le proxy/VPN en place), ensuite il n'y pas grand chose à polluer s'il s'agit d'envoyer un entier entre 0 et 65535, ou alors le mec a déjà les connaissances techniques pour se protéger un peu plus que ça.

cali

  • Officiel Ukrainian Resilient Data Network
  • Fédération FDN
  • *
  • Messages: 2 385
    • Ukrainian Resilient Data Network
BCP-162: logs, CGNat et cybercriminalité
« Réponse #20 le: 16 septembre 2019 à 15:22:34 »
J'ai pas trop aimé cette présentation Vivien, ça fait un peu trop à la solde du gouvernment.

Si il y a des vrais méchants à arrêter il faut de vrais enquêteurs, ils se débrouilleront sans la gestapo.

vivien

  • Administrateur
  • *
  • Messages: 43 568
    • Twitter LaFibre.info
BCP-162: logs, CGNat et cybercriminalité
« Réponse #21 le: 16 septembre 2019 à 15:40:54 »
Je n'ai pas donné d'exemple relevant du terrorisme, car là c'est pas le CGNat qui va arrêter les enquêteurs.

Mais pour des affaires courantes jusqu'à la pédophilie, c'est un vrai problème le CGNat.

Il y a une précision que j'ai donné à l'oral, mais cela manque quand on regarde les slides: les solutions évoquées par Europol "court terme" et "moyen terme" ne sont pas du ressort de l'Arcep, c'est uniquement la solution long terme qui rentre dans les compétences de l'Arcep et c'est 15 - 20 ans minimum avant que les FAI ne proposent plus de connectivité IPv4, d'où des réactions sur twitter lors de précédentes discussion avant l'été "C'est beaucoup trop long terme comme approche... En attendant, BCP-162 ca va prendre 3% de disque (donc rien) en plus sur tous les webs, sondes, firewalls et LBs de la planète, mais c'est mieux pour les enfants."


underground78

  • Expert
  • Abonné Free fibre
  • *
  • Messages: 7 357
  • Orsay (91)
    • FreePON : suivi géographique du déploiement fibre EPON chez Free
BCP-162: logs, CGNat et cybercriminalité
« Réponse #22 le: 16 septembre 2019 à 23:15:27 »
Non, ça ne marche pas comme ça.
Je suis assez persuadé que si. CloudFlare est un intermédiaire technique qui fournit un service, s'ils ne peuvent pas fournir les infos à l'autorité judiciaire, c'est leur problème pas celui de R.

R. fournit les infos qu'il peut avoir à son niveau (visiblement sérieusement) et c'est bien logique.

buddy

  • Expert
  • Abonné Bbox fibre
  • *
  • Messages: 13 965
  • Alpes Maritimes (06)
BCP-162: logs, CGNat et cybercriminalité
« Réponse #23 le: 17 septembre 2019 à 00:16:23 »
Mais Cloudflare à besoin de r. Non ? Sinon comment identifier qui a posté sur le topic y a l'heure h. (sans les logs du forum avec l'ip associée au message, c'est une aiguille dans une botte de foin..)