Discussion :

[Loloperso]

Bonjour,

J'ai mis en place un proxy Squid à la maison et j'ai comme projet d'utiliser DansGuardian pour filtrer (un peu) les accès à Internet des jeunes.

Je me demande si ça vaut le coup :

• impossible de bloquer des accès aux sites en https; et les plus grands basculent automatiquement sur https aujourd'hui
• les applications android (et peut-être d'autres OS) semblent ne pas communiquer sur le port 80 : squid devient inutile (y compris pour le cache au passage ;-) )

J'ai l'impression que ce n'est pas la peine de passer du temps sur DansGuardian : aujourd'hui, on ne surfe plus dans un navigateur par le port 80 finalement... Il me semble aujourd'hui impossible de limiter les accès... Partagez-vous cet avis ?

Je ne parle pas évidemment de l'accompagnement du parent, des explications, des échanges dans la vraie vie, avec les enfants; seulement des aides que pourraient apporter les solutions techniques.

Merci pour vos avis ou pistes :-)

[ram-0000]

[*]les applications android (et peut-être d'autres OS) semblent ne pas communiquer sur le port 80 : squid devient inutile (y compris pour le cache au passage ;-) )[/LIST]

Ha ?
Peut être que tu ne les voies pas parce qu'elles sortent en 3G/4G et pas en WiFi domestique ?

[Loloperso]

Pour la 3G/4G, bonne piste, mais je suis sûr que non parce qu'il s'agit d'un abonnement sans data...

En service, ce téléphone communique beaucoup sur des ports élevés (>1024) : donc je me suis dit que les applis youtube et cie communiquent par là... ou par le port 443.

En fait, un téléphone android passant son temps à faire des échanges avec tout le monde, j'ai du mal à m'y retrouver.

Bon, j'avoue que c'est une discussion sans vraiment de question, à part : à votre avis, faut-il vraiment passer du temps à notre époque à installer/configurer du filtrage dns ???

[ram-0000]

Pour la 3G/4G, bonne piste, mais je suis sûr que non parce qu'il s'agit d'un abonnement sans data...

Heu ... Pas de data, pas de web me semble t'il !!

Ou alors ton téléphone sort autrement (Wifi ?)

[sevyc64]

En service, ce téléphone communique beaucoup sur des ports élevés (>1024) :

Quand on parle de port 80 (443, ou autre) on parle du port du serveur sur lequel le client va aller se connecter.
Coté client (ton navigateur par exemple), tous les clients utiliseront un port (pseudo*)aléatoire en sortie >1024 pour aller établir la communication. Ce port est d'ailleurs généralement défini par l'os et non pas par le logiciel lui-même.

* pseudo aléatoire, parce que, pour un logiciel donné, à la première connexion l'os va prendre un port aléatoirement parmi les ports libres. Tant que le logiciel ne ferme pas la connexion, il utilise le même port. Dès qu'il ferme la connexion, à la connexion suivante, l'os va lui attribuer un nouveau port qui sera généralement le port précédent+1 , s'il est libre.

[Invité]

Dès qu'il ferme la connexion, à la connexion suivante, l'os va lui attribuer un nouveau port qui sera généralement le port précédent+1 , s'il est libre.

Oui, généralement...
Le problème, c'est qu'un Man-in-the-Middle sera capable de prédire le port source de la prochaine connexion TCP par simple écoute du trafic.
C'est pourquoi certaines implémentations de TCP embarquent des algos pour "durcir" la prédictibilité du port source TCP (Obfuscation of the Ephemeral Port Selection, RFC6056).

Il existe des techniques similaires pour "durcir" le calcul des séquences utilisées lors du 3-Way Handshake (RFC6528). Les toutes premières implémentations de TCP utilisaient des algos basiques qui permettaient de faire des attaques basées sur la prédiction des ACK numbers. C'est l'attaque de Mitnik :

https://fr.wikipedia.org/wiki/Attaque_de_Mitnick

https://en.wikipedia.org/wiki/TCP_se...diction_attack

qui consiste à SYN flooder la source trustée par le serveur pour la "paralyser"... Je vous laisse découvrir la tactique

Et pour le scoop, avec un pote dans les années 95 du siècle dernier (), on avait reproduit cette attaque pendant quelques minutes sur un host dont je tairai le nom (même s'il y a prescription)

Steph

[Loloperso]

Heu ... Pas de data, pas de web me semble t'il !!
Ou alors ton téléphone sort autrement (Wifi ?)

Bonjour,

Désolé, retard dans les réponses, vacances, tout ça...

En fait, bien sûr le téléphone se connecte par wifi au routeur de la maison. J'ai d'ailleurs cette certitude car quand il accède au web par le navigateur, je vois les log dans Squid.

Mais je ne comprends pas comment les différentes applications (de la météo à youtube, en passant par les jeux) récupèrent leurs données : je soupçonne qu'elles passent par un port >1024, puisque je ne vois rien dans les log de Squid (port 80). Est-ce que quelqu'un connaît les usage/habitudes des développeurs d'applications ?

Et bien sûr, ma supposition est qu'il devient du coup impossible de filtrer les accès.

Bon, ce n'est pas capital, plutôt de la culture générale à mon niveau. Si vous avez des pistes/infos etc, je vous remercie en tous les cas.
Et puis je marquerai le sujet comme "résolu" la prochaine fois, parce que je reconnais qu'il n'y a pas une question très très précise

[sevyc64]

Comme déjà dit, coté client, pour sortir, le port utilisé sera très certainement choisi aléatoirement et très certainement >1024.

Coté serveur, le port interrogé par le client dépendra du type de service demandé.

S'il s'agit d'un service standard (http, ftp, etc) accessible aussi à l'utilisateur en utilisant un logiciel standard, ça sera très probablement un port standard qui sera utilisé, ex: port 80 pour un service web utilisable aussi à travers un navigateur.
S'il s'agit d'un service accessible uniquement par une application cliente dédiée à cet effet le port utilisé peut ne pas être standard et peut être n'importe quel port parmi les 65000 disponibles.

Mais quand je parle d'application dédiée, c'est au sens large.
Supposons un site qui permet la visualisation de vidéo en ligne, la page web et le serveur web offrant ce service seront accessibles via le port 80, fonctionnement standard d'un navigateur. Cette page web va contenir diverses choses et par exemple des scripts pour charger en plus certains éléments de la page, le fichier vidéo à visionner par exemple. Non seulement ces éléments peuvent ne pas se trouver sur le même serveur, mais peuvent n'être accessibles que par un port non standard. Ils ne sont pas destinés à être charger directement mais via une application dédiée, représentée ici par les scripts sur la page web.

Si tu fais un filtrage par port en te basant sur les ports standards, c'est bien les port de destination qu'il faut filtrer et non pas les ports source coté client. Tu ne bloqueras certainement pas tout (le fichier vidéo à proprement parlé dans mon exemple) mais tu bloqueras déjà une grosse majorité des points d'accès (la page web donnant accès au fichier vidéo), et donc sans accès ...

[Loloperso]

Ok, je commence à comprendre... ou à entrevoir où il faut que je cherche à comprendre

Merci, aussi pour le temps pris à détailler les réponses : ça va m'aider!