[XPost fr.comp.os.unix, fr.comp.securite, suivi sur fr.comp.os.unix]
Bonjour,
Pour des raisons légales (nous offrons un accès Wifi à des étudiants
logés chez nous), je dois maintenir une base de données des machines qui
ont pu même une seule minute se connecter sur le réseau. Ce réseau Wifi
est segmenté du reste, et dispose de sa propre passerelle/firewall
Bon, pour ceux qui utilisent DHCP -la majorité, je suppose-, j'ai un
démon qui scrute le fichier leases toutes les 5 minutes, et remplit/
met à jour une base SQL. Ca marche très bien.
Par contre, je ne suis pas à l'abri -Murphy dit : ça arrivera- d'un
utilisateur qui se configurera en IP statique, parce que le voisin en
DHCP lui aura indiqué la passerelle et le DNS.
Un outil comme arpwatch (http://ee.lbl.gov/) ou arpalert
(http://www.arpalert.org/) est-il nécessaire, ou bien puis-je me
contenter dans mon démon d'appeler `arp -a` (je les aurai toutes,
puisque je suis sur la passerelle) en plus de l'examen de dhcpd.leases,
et prendre les mesures appropriées pour les @ MAC qui ne seraient pas
encore dans ma base ?
Merci,
--
XAv
Disponible au 01/06/2010
<http://www.xavierhumbert.net/perso/CV2.html>
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
Xavier wrote in message <1jbg51i.yh6sxb1mo281jN%:
Pour des raisons légales (nous offrons un accès Wifi à des étudiants logés chez nous), je dois maintenir une base de données des machines qui ont pu même une seule minute se connecter sur le réseau. Ce réseau Wifi est segmenté du reste, et dispose de sa propre passerelle/firewall
Quelqu'un qui veut faire des choses illégales ne reculera pas devant l'opération triviale consistant à changer son adresse MAC : cette base de données ne sert essentiellement à rien.
Xavier wrote in message <1jbg51i.yh6sxb1mo281jN%xavier@groumpf.org>:
Pour des raisons légales (nous offrons un accès Wifi à des étudiants
logés chez nous), je dois maintenir une base de données des machines qui
ont pu même une seule minute se connecter sur le réseau. Ce réseau Wifi
est segmenté du reste, et dispose de sa propre passerelle/firewall
Quelqu'un qui veut faire des choses illégales ne reculera pas devant
l'opération triviale consistant à changer son adresse MAC : cette base de
données ne sert essentiellement à rien.
Pour des raisons légales (nous offrons un accès Wifi à des étudiants logés chez nous), je dois maintenir une base de données des machines qui ont pu même une seule minute se connecter sur le réseau. Ce réseau Wifi est segmenté du reste, et dispose de sa propre passerelle/firewall
Quelqu'un qui veut faire des choses illégales ne reculera pas devant l'opération triviale consistant à changer son adresse MAC : cette base de données ne sert essentiellement à rien.
xavier
Nicolas George <nicolas$ wrote:
Quelqu'un qui veut faire des choses illégales ne reculera pas devant l'opération triviale consistant à changer son adresse MAC : cette base de données ne sert essentiellement à rien.
Oui, bien entendu, et j'en suis conscient. Simplement, j'ai une obligation (légale ? En tout cas demandée par mes chefs) d'enregistrer toutes les adresses MAC qui passent.
Il y a deux ans, un type est venu sur notre réseau public pour commettre une fraude à la carte bancaire : comme il est passé par un proxy extérieur (port != 80 ou 443, on est en redirect transparent sur ces deux ports), je n'avais aucune trace à montrer à l'enquêteur de la gendarmerie.
Là, une @ MAC, fut-elle usurpée, j'ai quelque chose à montrer, et donc j'ai fait mon boulot.
-- XAv Disponible au 01/06/2010 <http://www.xavierhumbert.net/perso/CV2.html>
Nicolas George <nicolas$george@salle-s.org> wrote:
Quelqu'un qui veut faire des choses illégales ne reculera pas devant
l'opération triviale consistant à changer son adresse MAC : cette base de
données ne sert essentiellement à rien.
Oui, bien entendu, et j'en suis conscient. Simplement, j'ai une
obligation (légale ? En tout cas demandée par mes chefs) d'enregistrer
toutes les adresses MAC qui passent.
Il y a deux ans, un type est venu sur notre réseau public pour commettre
une fraude à la carte bancaire : comme il est passé par un proxy
extérieur (port != 80 ou 443, on est en redirect transparent sur ces
deux ports), je n'avais aucune trace à montrer à l'enquêteur de la
gendarmerie.
Là, une @ MAC, fut-elle usurpée, j'ai quelque chose à montrer, et donc
j'ai fait mon boulot.
--
XAv
Disponible au 01/06/2010
<http://www.xavierhumbert.net/perso/CV2.html>
Quelqu'un qui veut faire des choses illégales ne reculera pas devant l'opération triviale consistant à changer son adresse MAC : cette base de données ne sert essentiellement à rien.
Oui, bien entendu, et j'en suis conscient. Simplement, j'ai une obligation (légale ? En tout cas demandée par mes chefs) d'enregistrer toutes les adresses MAC qui passent.
Il y a deux ans, un type est venu sur notre réseau public pour commettre une fraude à la carte bancaire : comme il est passé par un proxy extérieur (port != 80 ou 443, on est en redirect transparent sur ces deux ports), je n'avais aucune trace à montrer à l'enquêteur de la gendarmerie.
Là, une @ MAC, fut-elle usurpée, j'ai quelque chose à montrer, et donc j'ai fait mon boulot.
-- XAv Disponible au 01/06/2010 <http://www.xavierhumbert.net/perso/CV2.html>
Bruno Tréguier
Le 28/12/2009 à 20:36, (Xavier) a écrit :
Nicolas George <nicolas$ wrote:
Quelqu'un qui veut faire des choses illégales ne reculera pas devant l'opération triviale consistant à changer son adresse MAC : cette base de données ne sert essentiellement à rien.
Oui, bien entendu, et j'en suis conscient. Simplement, j'ai une obligation (légale ? En tout cas demandée par mes chefs) d'enregistrer toutes les adresses MAC qui passent.
Il y a deux ans, un type est venu sur notre réseau public pour commettre une fraude à la carte bancaire : comme il est passé par un proxy extérieur (port != 80 ou 443, on est en redirect transparent sur ces deux ports), je n'avais aucune trace à montrer à l'enquêteur de la gendarmerie.
Là, une @ MAC, fut-elle usurpée, j'ai quelque chose à montrer, et donc j'ai fait mon boulot.
Bonsoir Xavier,
Si votre conception du travail bien fait se limite à donner satisfaction à vos chefs sans vous poser de question sur le bienfondé de leurs consignes, vous pouvez effectivement vous contenter de ça. ;-)
Je vous conseille plutôt, dans ce cas, un truc genre arpwatch, plutôt qu'un "arp -a". arpwatch a l'avantage de tracer les manips un peu curieuses également, genre les IP qui changent d'adresse MAC sans raison. Comme arpwatch ne sait pas forcément que vous utilisez du DHCP, il faut en revanche faire en sorte que vos allocations d'adresses soient statiques: une MAC, une IP. Cela dit, une MAC est tellement simple à changer, de nos jours, que je rejoins totalement l'avis de Nicolas: il est totalement illusoire d'espérer tracer quoi que ce soit (ou presque) avec cela: une écoute du réseau, une usurpation de MAC, et hop, l'intrus fait ce qu'il veut sans que personne n'y voie quoi que ce soit.
Maintenant, si vous voulez aller un peu plus loin et montrer à vos donneurs d'ordre que la solution qu'ils préconisent n'est pas forcément la meilleure s'ils veulent *réellement* limiter le réseau à des personnes dûment autorisées, intéressez-vous à 802.1x, qui est une méthode standard d'authentification, disponible sur tous les O.S. modernes... Vos étudiants seront peut-être moins enclins à partager cette info que s'il s'agissait d'une clef WEP ou WPA, s'ils savent que son utilisation dans un but illégal peut les mettre directement en cause.
Autre solution fonctionnellement similaire: le portail captif, à employer si jamais le 802.1x pose problème à certains de vos utilisateurs.
Cordialement,
Bruno
Le 28/12/2009 à 20:36, xavier@groumpf.org (Xavier) a écrit :
Nicolas George <nicolas$george@salle-s.org> wrote:
Quelqu'un qui veut faire des choses illégales ne reculera pas devant
l'opération triviale consistant à changer son adresse MAC : cette base de
données ne sert essentiellement à rien.
Oui, bien entendu, et j'en suis conscient. Simplement, j'ai une
obligation (légale ? En tout cas demandée par mes chefs) d'enregistrer
toutes les adresses MAC qui passent.
Il y a deux ans, un type est venu sur notre réseau public pour commettre
une fraude à la carte bancaire : comme il est passé par un proxy
extérieur (port != 80 ou 443, on est en redirect transparent sur ces
deux ports), je n'avais aucune trace à montrer à l'enquêteur de la
gendarmerie.
Là, une @ MAC, fut-elle usurpée, j'ai quelque chose à montrer, et donc
j'ai fait mon boulot.
Bonsoir Xavier,
Si votre conception du travail bien fait se limite à donner satisfaction
à vos chefs sans vous poser de question sur le bienfondé de leurs
consignes, vous pouvez effectivement vous contenter de ça. ;-)
Je vous conseille plutôt, dans ce cas, un truc genre arpwatch, plutôt
qu'un "arp -a". arpwatch a l'avantage de tracer les manips un peu
curieuses également, genre les IP qui changent d'adresse MAC sans
raison. Comme arpwatch ne sait pas forcément que vous utilisez du DHCP,
il faut en revanche faire en sorte que vos allocations d'adresses soient
statiques: une MAC, une IP. Cela dit, une MAC est tellement simple à
changer, de nos jours, que je rejoins totalement l'avis de Nicolas: il
est totalement illusoire d'espérer tracer quoi que ce soit (ou presque)
avec cela: une écoute du réseau, une usurpation de MAC, et hop, l'intrus
fait ce qu'il veut sans que personne n'y voie quoi que ce soit.
Maintenant, si vous voulez aller un peu plus loin et montrer à vos
donneurs d'ordre que la solution qu'ils préconisent n'est pas forcément
la meilleure s'ils veulent *réellement* limiter le réseau à des
personnes dûment autorisées, intéressez-vous à 802.1x, qui est une
méthode standard d'authentification, disponible sur tous les O.S.
modernes... Vos étudiants seront peut-être moins enclins à partager
cette info que s'il s'agissait d'une clef WEP ou WPA, s'ils savent que
son utilisation dans un but illégal peut les mettre directement en cause.
Autre solution fonctionnellement similaire: le portail captif, à
employer si jamais le 802.1x pose problème à certains de vos utilisateurs.
Quelqu'un qui veut faire des choses illégales ne reculera pas devant l'opération triviale consistant à changer son adresse MAC : cette base de données ne sert essentiellement à rien.
Oui, bien entendu, et j'en suis conscient. Simplement, j'ai une obligation (légale ? En tout cas demandée par mes chefs) d'enregistrer toutes les adresses MAC qui passent.
Il y a deux ans, un type est venu sur notre réseau public pour commettre une fraude à la carte bancaire : comme il est passé par un proxy extérieur (port != 80 ou 443, on est en redirect transparent sur ces deux ports), je n'avais aucune trace à montrer à l'enquêteur de la gendarmerie.
Là, une @ MAC, fut-elle usurpée, j'ai quelque chose à montrer, et donc j'ai fait mon boulot.
Bonsoir Xavier,
Si votre conception du travail bien fait se limite à donner satisfaction à vos chefs sans vous poser de question sur le bienfondé de leurs consignes, vous pouvez effectivement vous contenter de ça. ;-)
Je vous conseille plutôt, dans ce cas, un truc genre arpwatch, plutôt qu'un "arp -a". arpwatch a l'avantage de tracer les manips un peu curieuses également, genre les IP qui changent d'adresse MAC sans raison. Comme arpwatch ne sait pas forcément que vous utilisez du DHCP, il faut en revanche faire en sorte que vos allocations d'adresses soient statiques: une MAC, une IP. Cela dit, une MAC est tellement simple à changer, de nos jours, que je rejoins totalement l'avis de Nicolas: il est totalement illusoire d'espérer tracer quoi que ce soit (ou presque) avec cela: une écoute du réseau, une usurpation de MAC, et hop, l'intrus fait ce qu'il veut sans que personne n'y voie quoi que ce soit.
Maintenant, si vous voulez aller un peu plus loin et montrer à vos donneurs d'ordre que la solution qu'ils préconisent n'est pas forcément la meilleure s'ils veulent *réellement* limiter le réseau à des personnes dûment autorisées, intéressez-vous à 802.1x, qui est une méthode standard d'authentification, disponible sur tous les O.S. modernes... Vos étudiants seront peut-être moins enclins à partager cette info que s'il s'agissait d'une clef WEP ou WPA, s'ils savent que son utilisation dans un but illégal peut les mettre directement en cause.
Autre solution fonctionnellement similaire: le portail captif, à employer si jamais le 802.1x pose problème à certains de vos utilisateurs.
Cordialement,
Bruno
xavier
Bruno Tréguier wrote:
Bonsoir Xavier,
Bonjour Bruno,
Si votre conception du travail bien fait se limite à donner satisfaction à vos chefs sans vous poser de question sur le bienfondé de leurs consignes, vous pouvez effectivement vous contenter de ça. ;-)
En fait j'ai proposé une solution à base de 802.1x et de portail captif avec un annuaire LDAP et un serveur Radius, on m'a dit que pour les 6 mois qu'il restait à l'Institut dans ces locaux, l'investissement en temps était trop élevé : j'ai un réseau étendu sur 9 ha, segmenté en plusieurs VLANs, ça m'obligerait, outre la config Radius/LDAP, à reconfigurer toux les switches Cisco. Bref, on m'a dit, tu fais plus simple (WPA sur les PA Wifi), et tu surveilles.
Je vous conseille plutôt, dans ce cas, un truc genre arpwatch, plutôt qu'un "arp -a". arpwatch a l'avantage de tracer les manips un peu curieuses également, genre les IP qui changent d'adresse MAC sans raison. Comme arpwatch ne sait pas forcément que vous utilisez du DHCP, il faut en revanche faire en sorte que vos allocations d'adresses soient statiques: une MAC, une IP.
J'avais fait cela sur le réseau interne, à titre de test, et arpwatch est plutôt verbeux, si je me souviens bien. Mais c'est effectivement vers là que je m'orientais
Cela dit, une MAC est tellement simple à changer, de nos jours, que je rejoins totalement l'avis de Nicolas: il est totalement illusoire d'espérer tracer quoi que ce soit (ou presque) avec cela: une écoute du réseau, une usurpation de MAC, et hop, l'intrus fait ce qu'il veut sans que personne n'y voie quoi que ce soit.
Ben oui, mais sans authentification "dure", je ne vois pas comment faire plus...
Maintenant, si vous voulez aller un peu plus loin et montrer à vos donneurs d'ordre que la solution qu'ils préconisent n'est pas forcément la meilleure s'ils veulent *réellement* limiter le réseau à des personnes dûment autorisées, intéressez-vous à 802.1x, qui est une méthode standard d'authentification, disponible sur tous les O.S. modernes... Vos étudiants seront peut-être moins enclins à partager cette info que s'il s'agissait d'une clef WEP ou WPA, s'ils savent que son utilisation dans un but illégal peut les mettre directement en cause.
J'ai lu ce document : <http://cric.grenoble.cnrs.fr/SiteWebAuthentification/index.php> et c'est dans l'absolu la meilleure solution. Mais encore une fois, on m'a dit d'aller vite... Et le rédacteur du document parle d'un projet d'une année :-) Moi, j'aurais bien voulu, c'est une expérience intéressante à engranger...
Autre solution fonctionnellement similaire: le portail captif, à employer si jamais le 802.1x pose problème à certains de vos utilisateurs.
chillispot fonctionne sans 802.1x ? Ce n'est pourtant pas ce qu'il m'avait semblé, et c'est sans doute une piste intéressante...
Cordialement,
Pareillement et merci,
-- XAv Disponible au 01/06/2010 <http://www.xavierhumbert.net/perso/CV2.html>
Bruno Tréguier <bruno.treguier_at_shom.fr@nullepart.invalid> wrote:
Bonsoir Xavier,
Bonjour Bruno,
Si votre conception du travail bien fait se limite à donner satisfaction
à vos chefs sans vous poser de question sur le bienfondé de leurs
consignes, vous pouvez effectivement vous contenter de ça. ;-)
En fait j'ai proposé une solution à base de 802.1x et de portail captif
avec un annuaire LDAP et un serveur Radius, on m'a dit que pour les 6
mois qu'il restait à l'Institut dans ces locaux, l'investissement en
temps était trop élevé : j'ai un réseau étendu sur 9 ha, segmenté en
plusieurs VLANs, ça m'obligerait, outre la config Radius/LDAP, à
reconfigurer toux les switches Cisco. Bref, on m'a dit, tu fais plus
simple (WPA sur les PA Wifi), et tu surveilles.
Je vous conseille plutôt, dans ce cas, un truc genre arpwatch, plutôt
qu'un "arp -a". arpwatch a l'avantage de tracer les manips un peu
curieuses également, genre les IP qui changent d'adresse MAC sans
raison. Comme arpwatch ne sait pas forcément que vous utilisez du DHCP,
il faut en revanche faire en sorte que vos allocations d'adresses soient
statiques: une MAC, une IP.
J'avais fait cela sur le réseau interne, à titre de test, et arpwatch
est plutôt verbeux, si je me souviens bien. Mais c'est effectivement
vers là que je m'orientais
Cela dit, une MAC est tellement simple à
changer, de nos jours, que je rejoins totalement l'avis de Nicolas: il
est totalement illusoire d'espérer tracer quoi que ce soit (ou presque)
avec cela: une écoute du réseau, une usurpation de MAC, et hop, l'intrus
fait ce qu'il veut sans que personne n'y voie quoi que ce soit.
Ben oui, mais sans authentification "dure", je ne vois pas comment faire
plus...
Maintenant, si vous voulez aller un peu plus loin et montrer à vos
donneurs d'ordre que la solution qu'ils préconisent n'est pas forcément
la meilleure s'ils veulent *réellement* limiter le réseau à des
personnes dûment autorisées, intéressez-vous à 802.1x, qui est une
méthode standard d'authentification, disponible sur tous les O.S.
modernes... Vos étudiants seront peut-être moins enclins à partager
cette info que s'il s'agissait d'une clef WEP ou WPA, s'ils savent que
son utilisation dans un but illégal peut les mettre directement en cause.
J'ai lu ce document :
<http://cric.grenoble.cnrs.fr/SiteWebAuthentification/index.php>
et c'est dans l'absolu la meilleure solution. Mais encore une fois, on
m'a dit d'aller vite... Et le rédacteur du document parle d'un projet
d'une année :-) Moi, j'aurais bien voulu, c'est une expérience
intéressante à engranger...
Autre solution fonctionnellement similaire: le portail captif, à
employer si jamais le 802.1x pose problème à certains de vos utilisateurs.
chillispot fonctionne sans 802.1x ? Ce n'est pourtant pas ce qu'il
m'avait semblé, et c'est sans doute une piste intéressante...
Cordialement,
Pareillement et merci,
--
XAv
Disponible au 01/06/2010
<http://www.xavierhumbert.net/perso/CV2.html>
Si votre conception du travail bien fait se limite à donner satisfaction à vos chefs sans vous poser de question sur le bienfondé de leurs consignes, vous pouvez effectivement vous contenter de ça. ;-)
En fait j'ai proposé une solution à base de 802.1x et de portail captif avec un annuaire LDAP et un serveur Radius, on m'a dit que pour les 6 mois qu'il restait à l'Institut dans ces locaux, l'investissement en temps était trop élevé : j'ai un réseau étendu sur 9 ha, segmenté en plusieurs VLANs, ça m'obligerait, outre la config Radius/LDAP, à reconfigurer toux les switches Cisco. Bref, on m'a dit, tu fais plus simple (WPA sur les PA Wifi), et tu surveilles.
Je vous conseille plutôt, dans ce cas, un truc genre arpwatch, plutôt qu'un "arp -a". arpwatch a l'avantage de tracer les manips un peu curieuses également, genre les IP qui changent d'adresse MAC sans raison. Comme arpwatch ne sait pas forcément que vous utilisez du DHCP, il faut en revanche faire en sorte que vos allocations d'adresses soient statiques: une MAC, une IP.
J'avais fait cela sur le réseau interne, à titre de test, et arpwatch est plutôt verbeux, si je me souviens bien. Mais c'est effectivement vers là que je m'orientais
Cela dit, une MAC est tellement simple à changer, de nos jours, que je rejoins totalement l'avis de Nicolas: il est totalement illusoire d'espérer tracer quoi que ce soit (ou presque) avec cela: une écoute du réseau, une usurpation de MAC, et hop, l'intrus fait ce qu'il veut sans que personne n'y voie quoi que ce soit.
Ben oui, mais sans authentification "dure", je ne vois pas comment faire plus...
Maintenant, si vous voulez aller un peu plus loin et montrer à vos donneurs d'ordre que la solution qu'ils préconisent n'est pas forcément la meilleure s'ils veulent *réellement* limiter le réseau à des personnes dûment autorisées, intéressez-vous à 802.1x, qui est une méthode standard d'authentification, disponible sur tous les O.S. modernes... Vos étudiants seront peut-être moins enclins à partager cette info que s'il s'agissait d'une clef WEP ou WPA, s'ils savent que son utilisation dans un but illégal peut les mettre directement en cause.
J'ai lu ce document : <http://cric.grenoble.cnrs.fr/SiteWebAuthentification/index.php> et c'est dans l'absolu la meilleure solution. Mais encore une fois, on m'a dit d'aller vite... Et le rédacteur du document parle d'un projet d'une année :-) Moi, j'aurais bien voulu, c'est une expérience intéressante à engranger...
Autre solution fonctionnellement similaire: le portail captif, à employer si jamais le 802.1x pose problème à certains de vos utilisateurs.
chillispot fonctionne sans 802.1x ? Ce n'est pourtant pas ce qu'il m'avait semblé, et c'est sans doute une piste intéressante...
Cordialement,
Pareillement et merci,
-- XAv Disponible au 01/06/2010 <http://www.xavierhumbert.net/perso/CV2.html>
Nicolas George
Xavier wrote in message <1jbgbqo.kq4ckh2cjnfkN%:
Là, une @ MAC, fut-elle usurpée, j'ai quelque chose à montrer, et donc j'ai fait mon boulot.
Dans ce cas, si c'est juste pour l'esbroufe, ne te pose pas de questions : sauve les logs du serveur DHCP, voire du /dev/urandom, tu auras autant fait ton boulot.
Xavier wrote in message <1jbgbqo.kq4ckh2cjnfkN%xavier@groumpf.org>:
Là, une @ MAC, fut-elle usurpée, j'ai quelque chose à montrer, et donc
j'ai fait mon boulot.
Dans ce cas, si c'est juste pour l'esbroufe, ne te pose pas de questions :
sauve les logs du serveur DHCP, voire du /dev/urandom, tu auras autant fait
ton boulot.
Là, une @ MAC, fut-elle usurpée, j'ai quelque chose à montrer, et donc j'ai fait mon boulot.
Dans ce cas, si c'est juste pour l'esbroufe, ne te pose pas de questions : sauve les logs du serveur DHCP, voire du /dev/urandom, tu auras autant fait ton boulot.
Bruno Tréguier
Le 29/12/2009 à 12:52, (Xavier) a écrit :
Bonjour Bruno,
Bonjour Xavier,
En fait j'ai proposé une solution à base de 802.1x et de portail captif avec un annuaire LDAP et un serveur Radius, on m'a dit que pour les 6 mois qu'il restait à l'Institut dans ces locaux, l'investissement en temps était trop élevé : j'ai un réseau étendu sur 9 ha, segmenté en plusieurs VLANs, ça m'obligerait, outre la config Radius/LDAP, à reconfigurer toux les switches Cisco. Bref, on m'a dit, tu fais plus simple (WPA sur les PA Wifi), et tu surveilles.
Ok, je comprends mieux maintenant, mais j'ai toujours un peu de mal avec les "demi-solutions", parce que là, ce qu'on vous demande, c'est de fournir une info pas fiable, juste pour être "dans les clous" du point de vue de la loi (planquer les miettes sous le tapis, en d'autres termes... ;-) ).
[arpwatch]
J'avais fait cela sur le réseau interne, à titre de test, et arpwatch est plutôt verbeux, si je me souviens bien. Mais c'est effectivement vers là que je m'orientais
C'est verbeux au début (en phase d'apprentissage), mais après, normalement, ça se calme (ou alors y'a un "loup" ;-) ).
J'ai lu ce document : <http://cric.grenoble.cnrs.fr/SiteWebAuthentification/index.php> et c'est dans l'absolu la meilleure solution. Mais encore une fois, on m'a dit d'aller vite... Et le rédacteur du document parle d'un projet d'une année :-) Moi, j'aurais bien voulu, c'est une expérience intéressante à engranger...
C'est certain. Merci pour le lien au passage ! ;-) Il est très intéressant.
Autre solution fonctionnellement similaire: le portail captif, à employer si jamais le 802.1x pose problème à certains de vos utilisateurs.
chillispot fonctionne sans 802.1x ? Ce n'est pourtant pas ce qu'il m'avait semblé, et c'est sans doute une piste intéressante...
Je ne parlais pas spécialement de chillispot, en fait. Il y a effectivement des portails captifs utilisant 802.1x, comme chillispot, et d'autres qui ne l'utilisent pas, comme NoCat (je crois).
Bonnes fêtes de fin d'année, et bon courage !
Cordialement,
Bruno
Le 29/12/2009 à 12:52, xavier@groumpf.org (Xavier) a écrit :
Bonjour Bruno,
Bonjour Xavier,
En fait j'ai proposé une solution à base de 802.1x et de portail captif
avec un annuaire LDAP et un serveur Radius, on m'a dit que pour les 6
mois qu'il restait à l'Institut dans ces locaux, l'investissement en
temps était trop élevé : j'ai un réseau étendu sur 9 ha, segmenté en
plusieurs VLANs, ça m'obligerait, outre la config Radius/LDAP, à
reconfigurer toux les switches Cisco. Bref, on m'a dit, tu fais plus
simple (WPA sur les PA Wifi), et tu surveilles.
Ok, je comprends mieux maintenant, mais j'ai toujours un peu de mal avec
les "demi-solutions", parce que là, ce qu'on vous demande, c'est de
fournir une info pas fiable, juste pour être "dans les clous" du point
de vue de la loi (planquer les miettes sous le tapis, en d'autres
termes... ;-) ).
[arpwatch]
J'avais fait cela sur le réseau interne, à titre de test, et arpwatch
est plutôt verbeux, si je me souviens bien. Mais c'est effectivement
vers là que je m'orientais
C'est verbeux au début (en phase d'apprentissage), mais après,
normalement, ça se calme (ou alors y'a un "loup" ;-) ).
J'ai lu ce document :
<http://cric.grenoble.cnrs.fr/SiteWebAuthentification/index.php>
et c'est dans l'absolu la meilleure solution. Mais encore une fois, on
m'a dit d'aller vite... Et le rédacteur du document parle d'un projet
d'une année :-) Moi, j'aurais bien voulu, c'est une expérience
intéressante à engranger...
C'est certain. Merci pour le lien au passage ! ;-) Il est très intéressant.
Autre solution fonctionnellement similaire: le portail captif, à
employer si jamais le 802.1x pose problème à certains de vos utilisateurs.
chillispot fonctionne sans 802.1x ? Ce n'est pourtant pas ce qu'il
m'avait semblé, et c'est sans doute une piste intéressante...
Je ne parlais pas spécialement de chillispot, en fait. Il y a
effectivement des portails captifs utilisant 802.1x, comme chillispot,
et d'autres qui ne l'utilisent pas, comme NoCat (je crois).
En fait j'ai proposé une solution à base de 802.1x et de portail captif avec un annuaire LDAP et un serveur Radius, on m'a dit que pour les 6 mois qu'il restait à l'Institut dans ces locaux, l'investissement en temps était trop élevé : j'ai un réseau étendu sur 9 ha, segmenté en plusieurs VLANs, ça m'obligerait, outre la config Radius/LDAP, à reconfigurer toux les switches Cisco. Bref, on m'a dit, tu fais plus simple (WPA sur les PA Wifi), et tu surveilles.
Ok, je comprends mieux maintenant, mais j'ai toujours un peu de mal avec les "demi-solutions", parce que là, ce qu'on vous demande, c'est de fournir une info pas fiable, juste pour être "dans les clous" du point de vue de la loi (planquer les miettes sous le tapis, en d'autres termes... ;-) ).
[arpwatch]
J'avais fait cela sur le réseau interne, à titre de test, et arpwatch est plutôt verbeux, si je me souviens bien. Mais c'est effectivement vers là que je m'orientais
C'est verbeux au début (en phase d'apprentissage), mais après, normalement, ça se calme (ou alors y'a un "loup" ;-) ).
J'ai lu ce document : <http://cric.grenoble.cnrs.fr/SiteWebAuthentification/index.php> et c'est dans l'absolu la meilleure solution. Mais encore une fois, on m'a dit d'aller vite... Et le rédacteur du document parle d'un projet d'une année :-) Moi, j'aurais bien voulu, c'est une expérience intéressante à engranger...
C'est certain. Merci pour le lien au passage ! ;-) Il est très intéressant.
Autre solution fonctionnellement similaire: le portail captif, à employer si jamais le 802.1x pose problème à certains de vos utilisateurs.
chillispot fonctionne sans 802.1x ? Ce n'est pourtant pas ce qu'il m'avait semblé, et c'est sans doute une piste intéressante...
Je ne parlais pas spécialement de chillispot, en fait. Il y a effectivement des portails captifs utilisant 802.1x, comme chillispot, et d'autres qui ne l'utilisent pas, comme NoCat (je crois).
Bonnes fêtes de fin d'année, et bon courage !
Cordialement,
Bruno
Riquer Vincent
Xavier a écrit :
Pour des raisons légales (nous offrons un accès Wifi à des étudiants logés chez nous), je dois maintenir une base de données des machines qui ont pu même une seule minute se connecter sur le réseau. Ce réseau Wifi est segmenté du reste, et dispose de sa propre passerelle/firewall
Ne serait-il pas plus simple d'utiliser un portail captif ? Plus sûr également : identifier une machine, c'est bien. Identifier un utilisateur, si le but est d'être conforme à la loi française, c'est mieux.
Xavier a écrit :
Pour des raisons légales (nous offrons un accès Wifi à des étudiants
logés chez nous), je dois maintenir une base de données des machines qui
ont pu même une seule minute se connecter sur le réseau. Ce réseau Wifi
est segmenté du reste, et dispose de sa propre passerelle/firewall
Ne serait-il pas plus simple d'utiliser un portail captif ? Plus sûr
également : identifier une machine, c'est bien. Identifier un
utilisateur, si le but est d'être conforme à la loi française, c'est mieux.
Pour des raisons légales (nous offrons un accès Wifi à des étudiants logés chez nous), je dois maintenir une base de données des machines qui ont pu même une seule minute se connecter sur le réseau. Ce réseau Wifi est segmenté du reste, et dispose de sa propre passerelle/firewall
Ne serait-il pas plus simple d'utiliser un portail captif ? Plus sûr également : identifier une machine, c'est bien. Identifier un utilisateur, si le but est d'être conforme à la loi française, c'est mieux.
xavier
[Je redirige ver fco.bsd, où la suite sera plus en thème] Riquer Vincent wrote:
Ne serait-il pas plus simple d'utiliser un portail captif ? Plus sûr également : identifier une machine, c'est bien. Identifier un utilisateur, si le but est d'être conforme à la loi française, c'est mieux.
Effectivement, je viens de jeter unoeil à NoCat, ça semble correspondre.
Juste un truc me chiffonne dans le port FreeBSD. Je passe sur le fait que c'est marqué "IGNORE : uses a UID registered to another port". J'ai été voir dans le script d'install, c'est 181, donc Nagios. Je ne l'utilise pas, ça ne me pose pas de problème de commenter dans le Makefile.
Par contre, il y a deux ports, marqués comme mutuellement incompatibles, net/nocatauth-gateway et net/nocatauth-server. Quand on regarde la pkg-plist, c'est presque identique, mais seulement presque. Et ni CVSWeb, ni Google, ni nocat.net ne m'ont aidé sur ce coup. Des idées ?
Merci !
-- XAv Disponible au 01/06/2010 <http://www.xavierhumbert.net/perso/CV2.html>
[Je redirige ver fco.bsd, où la suite sera plus en thème]
Riquer Vincent <vincent@riquer.fr> wrote:
Ne serait-il pas plus simple d'utiliser un portail captif ? Plus sûr
également : identifier une machine, c'est bien. Identifier un
utilisateur, si le but est d'être conforme à la loi française, c'est mieux.
Effectivement, je viens de jeter unoeil à NoCat, ça semble correspondre.
Juste un truc me chiffonne dans le port FreeBSD. Je passe sur le fait
que c'est marqué "IGNORE : uses a UID registered to another port". J'ai
été voir dans le script d'install, c'est 181, donc Nagios. Je ne
l'utilise pas, ça ne me pose pas de problème de commenter dans le
Makefile.
Par contre, il y a deux ports, marqués comme mutuellement incompatibles,
net/nocatauth-gateway et net/nocatauth-server. Quand on regarde la
pkg-plist, c'est presque identique, mais seulement presque. Et ni
CVSWeb, ni Google, ni nocat.net ne m'ont aidé sur ce coup. Des idées ?
Merci !
--
XAv
Disponible au 01/06/2010
<http://www.xavierhumbert.net/perso/CV2.html>
[Je redirige ver fco.bsd, où la suite sera plus en thème] Riquer Vincent wrote:
Ne serait-il pas plus simple d'utiliser un portail captif ? Plus sûr également : identifier une machine, c'est bien. Identifier un utilisateur, si le but est d'être conforme à la loi française, c'est mieux.
Effectivement, je viens de jeter unoeil à NoCat, ça semble correspondre.
Juste un truc me chiffonne dans le port FreeBSD. Je passe sur le fait que c'est marqué "IGNORE : uses a UID registered to another port". J'ai été voir dans le script d'install, c'est 181, donc Nagios. Je ne l'utilise pas, ça ne me pose pas de problème de commenter dans le Makefile.
Par contre, il y a deux ports, marqués comme mutuellement incompatibles, net/nocatauth-gateway et net/nocatauth-server. Quand on regarde la pkg-plist, c'est presque identique, mais seulement presque. Et ni CVSWeb, ni Google, ni nocat.net ne m'ont aidé sur ce coup. Des idées ?
Merci !
-- XAv Disponible au 01/06/2010 <http://www.xavierhumbert.net/perso/CV2.html>
