Surveillance ARP

Le
xavier
[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>
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #20848591
Xavier wrote in message
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
Le #20849131
Nicolas George
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
Bruno Tréguier
Le #20850621
Le 28/12/2009 à 20:36, (Xavier) a écrit :
Nicolas George
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
Le #20852351
Bruno Tréguier
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 :
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
Nicolas George
Le #20852521
Xavier wrote in message
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 #20852941
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 :
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
Le #20862511
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
Le #20863381
[Je redirige ver fco.bsd, où la suite sera plus en thème]
Riquer Vincent
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
Publicité
Poster une réponse
Anonyme