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.

Mets l'OCLCTIC en contact avec CloudFlare et roulez jeunesse.

Je pense que c'est la bonne solution.

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

- 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.

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

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..)