La réponse est simple. Lorsqu'un client veut joindre un site web, www.google.fr par exemple, son système va effectuer une requête DNS pour obtenir l'IP de google.
Il est vrai qu'on pourrait installer un relais DNS ou même un serveur DNS sur la machine hébergeant PepperSpot, et là le problème ne se pose pas, on peut bloquer le DNS.
Mais si le serveur DNS est "derrière" PepperSpot, c'est-à-dire dans le réseau auquel on a pas accès, le client n'arrivera jamais à obtenir l'IP de google si on bloque le DNS, et la page d'authentification ne s'affichera pas.
Je m'explique. PepperSpot redirige le client vers sa page d'authentification lorsqu'il détecte une demande de communication TCP. Si le client ne sait pas quelle IP joindre, la requête TCP ne se fera pas. De plus, la majorité des requêtes DNS sont effectuées en UDP... Voila pourquoi il peut être utile de ne pas bloquer les DNS.
Je suis cependant de ton avis, il est mieux de limiter au maximum les communications avec le réseau non accessible avant authentification. Ca dépend avant tout de la topologie du réseau.
Mais il ne faut pas oublier qu'un simple "apt-get install bind9" sous Debian suffit à installer un relais DNS fonctionnel... De plus, il est possible de spécifier l'adresse des DNS à joindre dans la configuration de PepperSpot...
A chacun de choisir la solution qui lui convient le plus, et la politique de sécurité la plus appropriée.
Tout d'abord bonjour à tous, et merci de l'intérêt que vous portez à cette dépêche.
Voici mes réponses aux différents commentaires.
Pour commencer, nous avons fait un fork de ChilliSpot dans la mesure où celui-ci n'est plus maintenu depuis 2006, et que les modifications apportées ont été très importantes. Cela nous permet de maintenir PepperSpot dans de bonnes conditions, et d'y apporter un support.
Concernant le contournement, lors de l'installation de PepperSpot, il est nécessaire d'appliquer un script IPTables sur la machine. La sécurité dépendra alors uniquement de ce script, et ne sera pas liée directement à PepperSpot. Pour l'IPoDNS (cas le plus répandu de contournement), il peut être possible de filtrer les requêtes DNS grâce au script firewall. On peut par exemple imaginer un serveur DNS dans le sous-réseau que couvre PepperSpot, ou en hôte autorisée, et il n'y aura alors aucune possibilité de contournement par ce biais.
Pour revenir à l'utilisation anormale des protocoles, je ne vois pas en quoi. Le script firewall installé avec PepperSpot sert à refuser toute connexion par défaut, avec d'éventuelles exceptions (ping, DNS, etc.). L'application va ensuite gérer elle même les différents paquets qui transitent, et acceptera ou non de les router vers Internet en fonction de différents paramètres (Adresse MAC, utilisateur Authentifié, Bande passante, etc.). Il est vrai que cela impose sûrement un temps de traitement un peu plus important que si le noyau gérait directement cela (PepperSpot utilise en effet un tunnel TUN/TAP pour router les paquets entre les différentes interfaces), mais il s'agissait de la méthode la plus efficace pour permettre de garantir une souplesse d'utilisation, et je comprends que les développeurs de ChilliSpot l'aient implémentée.
A propos du sur-coût d'administration, Earered, il est vrai que la configuration d'un serveur RADIUS n'est pas chose aisée de prime abord, mais cela permet de bénéficier de toutes les possibilités offertes par ce type d'authentification. Je ne vais pas les expliquer en détails ici, mais c'est un protocole d'authentification déployé à grande échelle, qui est utilisé chez la plupart des fournisseurs d'accès ou dans de très grands réseaux. Il est cependant possible de le configurer simplement en liant directement le serveur RADIUS à l'authentification système.
Enfin Tanguy, je pense que tu fais une petite confusion concernant WPA/TKIP. Il s'agit d'un protocole de sécurité de type 802.1X. On ne peut donc pas dire que PepperSpot fait la même chose étant donné que PepperSpot est une application. Il est capable de gérer des authentifications WPA/TKIP, et d'ailleurs bien d'autres, mais c'est totalement différent.
En tous cas, je vous invite vivement à tester PepperSpot et à nous envoyer vos éventuelles critiques et améliorations potentielles. Nous sommes aussi à la recherches des bugs et failles à corriger.
[^] # Re: Vos commentaires !
Posté par Thibault Vançon . En réponse à la dépêche PepperSpot, Portail Captif nouvelle génération. Évalué à 3.
Il est vrai qu'on pourrait installer un relais DNS ou même un serveur DNS sur la machine hébergeant PepperSpot, et là le problème ne se pose pas, on peut bloquer le DNS.
Mais si le serveur DNS est "derrière" PepperSpot, c'est-à-dire dans le réseau auquel on a pas accès, le client n'arrivera jamais à obtenir l'IP de google si on bloque le DNS, et la page d'authentification ne s'affichera pas.
Je m'explique. PepperSpot redirige le client vers sa page d'authentification lorsqu'il détecte une demande de communication TCP. Si le client ne sait pas quelle IP joindre, la requête TCP ne se fera pas. De plus, la majorité des requêtes DNS sont effectuées en UDP... Voila pourquoi il peut être utile de ne pas bloquer les DNS.
Je suis cependant de ton avis, il est mieux de limiter au maximum les communications avec le réseau non accessible avant authentification. Ca dépend avant tout de la topologie du réseau.
Mais il ne faut pas oublier qu'un simple "apt-get install bind9" sous Debian suffit à installer un relais DNS fonctionnel... De plus, il est possible de spécifier l'adresse des DNS à joindre dans la configuration de PepperSpot...
A chacun de choisir la solution qui lui convient le plus, et la politique de sécurité la plus appropriée.
# Vos commentaires !
Posté par Thibault Vançon . En réponse à la dépêche PepperSpot, Portail Captif nouvelle génération. Évalué à 3.
Voici mes réponses aux différents commentaires.
Pour commencer, nous avons fait un fork de ChilliSpot dans la mesure où celui-ci n'est plus maintenu depuis 2006, et que les modifications apportées ont été très importantes. Cela nous permet de maintenir PepperSpot dans de bonnes conditions, et d'y apporter un support.
Concernant le contournement, lors de l'installation de PepperSpot, il est nécessaire d'appliquer un script IPTables sur la machine. La sécurité dépendra alors uniquement de ce script, et ne sera pas liée directement à PepperSpot. Pour l'IPoDNS (cas le plus répandu de contournement), il peut être possible de filtrer les requêtes DNS grâce au script firewall. On peut par exemple imaginer un serveur DNS dans le sous-réseau que couvre PepperSpot, ou en hôte autorisée, et il n'y aura alors aucune possibilité de contournement par ce biais.
Pour revenir à l'utilisation anormale des protocoles, je ne vois pas en quoi. Le script firewall installé avec PepperSpot sert à refuser toute connexion par défaut, avec d'éventuelles exceptions (ping, DNS, etc.). L'application va ensuite gérer elle même les différents paquets qui transitent, et acceptera ou non de les router vers Internet en fonction de différents paramètres (Adresse MAC, utilisateur Authentifié, Bande passante, etc.). Il est vrai que cela impose sûrement un temps de traitement un peu plus important que si le noyau gérait directement cela (PepperSpot utilise en effet un tunnel TUN/TAP pour router les paquets entre les différentes interfaces), mais il s'agissait de la méthode la plus efficace pour permettre de garantir une souplesse d'utilisation, et je comprends que les développeurs de ChilliSpot l'aient implémentée.
A propos du sur-coût d'administration, Earered, il est vrai que la configuration d'un serveur RADIUS n'est pas chose aisée de prime abord, mais cela permet de bénéficier de toutes les possibilités offertes par ce type d'authentification. Je ne vais pas les expliquer en détails ici, mais c'est un protocole d'authentification déployé à grande échelle, qui est utilisé chez la plupart des fournisseurs d'accès ou dans de très grands réseaux. Il est cependant possible de le configurer simplement en liant directement le serveur RADIUS à l'authentification système.
Enfin Tanguy, je pense que tu fais une petite confusion concernant WPA/TKIP. Il s'agit d'un protocole de sécurité de type 802.1X. On ne peut donc pas dire que PepperSpot fait la même chose étant donné que PepperSpot est une application. Il est capable de gérer des authentifications WPA/TKIP, et d'ailleurs bien d'autres, mais c'est totalement différent.
En tous cas, je vous invite vivement à tester PepperSpot et à nous envoyer vos éventuelles critiques et améliorations potentielles. Nous sommes aussi à la recherches des bugs et failles à corriger.
A bientôt
Thibault