Je vois passer régulièrement des fils concernant la protection des réseaux
(familiaux) WiFi.
Les réponses données par les différents contributeurs sont souvent
incomplètes, voire contradictoires.
J'ai donc décidé d'apporter ma contribution au débat (et j'espère que
j'éviterai au moins de me contredire, à défaut d'être complet). ;-)
Les conseils que je donne supposent l'utilisation de Windows, mais peuvent
en grande partie s'appliquer à d'autres systèmes.
1) Schéma d'attaque:
Il faut avant tout définir contre quoi on veut se protéger. Voici un
scénario possible, en l'absence de protection du réseau WiFi.
- Un attaquant se connecte à un réseau WiFi "familial" (par exemple un
modem-routeur passerelle NAT parefeu, quelques postes de travail) accès WiFi
non protégé (= dansl'état du déballage).
- Il repère facilement le FAI et donc potentiellement le type du
modem-routeur, simplement par le nom du point d'accès ("Wanadoo xxx",
"Netgear"); ou bien en naviguant sur internet, va sur le site de la CNIL,
obtient l'adresse IP "vue d'internet" du modem-routeur, fait un "Whois" et
identifie le FAI.
- A partir de la liste des modem-routeurs loués par le FAI, et avec les docs
prises sur le site du FAI, l'attaquant détermine le nom d'utilisateur / mot
de passe par défaut (en général, admin / admin).
- Avec un "ipcfg /all" sous Windows il détermine l'adresse du modem-routeur
vue du réseau interne, se connecte en http au modem-routeur avec le nom
d'utilisateur et le mot de passe par défaut.
- Il prend le contrôle du modem-routeur (change le mot de passe), prend
connaissance du nom d'utilisateur et du mot de passe de connexion à
internet.
- Puis il pirate le compte sur le site du FAI (se créée une BAL, prend
connaissance des messages, se crée des pages persos ou change le contenu de
celles qui existent).
- Et peut aussi pirater le contenu des PC du réseau familial, si les
partages de fichiers sont activés (cas par défaut sous Windows).
- Il peut enfin se livrer sur internet à des activités délictueuses ou
frauduleuses, en toute impunité, en se faisant passer pour le détenteur du
compte qui pourra, lui, avoir maille à partir avec la justice...
Bref, sans protection, risque de dégâts maximaux.
2) La protection :
- Il vaut mieux avoir un poste connecté directement en ethernet (liaison
filaire) au modem-routeur, pour le configurer. A défaut, il faudra établir
d'abord une liaison WiFi non sécurisée, et faire vite pour la sécuriser!
- Avant tout, mettez à jour les systèmes d'exploitation des postes de
travail (sous XP le WiFi est intégré au système), le BIOS du modem-routeur
et ceux d'éventuels autres éléments flashables du réseau, les divers drivers
et programmes d'installation des éléments du réseau. Ceci permettra sans
doute de profiter des plus hauts degrés de protection, de boucher des
failles et corriger des bugs.
- Changez le ou les mots de passe du modem-routeur.
- Choisissez en tant que mode de chiffrement: WPA2 / PSK si tous les postes
le peuvent, ou WPA / PSK sinon (le WEP n'est pas sûr); activez le changement
périodique de clé (par exemple toutes les heures); utilisez AES comme
algorithme de chiffrement. Utilisez comme "secret partagé" une longue phrase
de passe. Configurez tous vos postes WiFi de la même manière que le
modem-routeur (ou laissez faire la recherche automatique de réseau) et
copiez la phrase de passe du secret partagé (à transporter dans un fichier,
sur une clé USB, puis copier / coller, ou CTRL C / CTRL V sous Windows, pour
éviter les erreurs de saisie).
- Une fois les liaisons WiFi configurées, créez ou configurez sur chaque
poste la connexion correspondante (celle qui utilise le dispositif WiFi),
avec attribution d'une IP fixe, unique, dans la même tranche que celle du
modem-routeur, l'IP du modem-routeur comme passerelle et serveur DNS (et
255.255.255.0 comme masque de sous-réseau si on vous le demande).
- Si le but de votre réseau local est le simple partage de la liaison à
internet, désactivez dans les propriétés des connexions WiFi les éléments
"Client pour les réseaux Microsoft" et "Partage de fichiers et d'imprimantes
pour les réseaux Microsoft". Ne laissez activé que TCPIP et éventuellement
un élément de type "Connexion 802.1x" rajouté parfois lors de l'installation
d'un dispositif de connexion WiFi sécurisée lorsqu'on utilise une ancienne
version de Windows (2000 par exemple). Dans les propriétés de TCPIP,
désactivez Netbios.
- Si vous voulez réellement partager des fichiers, songez à des serveurs /
clients FTP. Pour l'administration des postes à distance, songez à Ultra
VNC. Pour un partage d'imprimante, certains modem-routeurs font serveur
d'impression (USR 9108 par exemple). Bref, même si vous en avez envie,
évitez d'activer les éléments de réseaux Microsoft sur des connexions vers
internet!
- Limitez l'accès des postes autorisés à configurer le modem-routeur aux
seuls postes du réseau interne (liste limitative des IP des appareils
autorisés à administrer le mode-routeur, avec leurs adresses IP internes).
Désactivez le serveur DHCP du routeur.
- Vous pouvez si vous le désirez perdre (un peu) de votre temps avec
quelques babioles inutiles qui n'apporteront rien en matière de sécurité,
mais si ça peut vous rassurer, ça ne fait pas de mal:
* changer le nom SSID du réseau, et ne pas le diffuser ("on" arrivera quand
même à le retrouver, avec un détecteur de réseau WiFi couplé à un analyseur
de paquets) ;
* filtrer l'accès au réseau WiFi par les adresses MAC des dispositifs de
connexion (ça se retrouve, comme le nom SSID du réseau, et puis ça s'usurpe
avec des utilitaires à disposition sur internet) ;
* changer l'adresse par défaut du modem-routeur et la tranche d'adresse des
postes (ça ne sert à rien si le réseau n'est pas protégé, ça ne sert plus à
rien s'il est protégé) ;
* changer le nom du groupe de travail Windows (inutile car vous n'avez pas
de réseau Windows si vous avez suivi ces conseils) ;
* comme l'a suggéré un posteur, mettre une horloge sur l'alimentation
électrique du modem-routeur (s'il est correctement protégé, il l'est tout le
temps; s'il est mal protégé, il ne faut pas le mettre en service).
--
Michel Nallino aka WinTerMiNator
http://anonapps.samizdat.net (Anonymat sur Internet)
Adresse e-mail invalide; pour me contacter:
http://www.cerbermail.com/?vdU5HHs5WG
Mais il faut alors que le serveur DHCP soit fiable. Bah, en général ce sont des trucs qui fonctionnent...
Si c'est une machine que tu contrôles, je veux bien. Si c'est la freebox, bof.
pchene
Bonjour,
Oui la MAC est plusque diffusée un petit tour sur le site de netstumbler devrait faire du bien par exemple : http://www.netstumbler.com/
Ou avec n'importe quel sniffer comme Ethereal, Wireshark, Sniffer Pro (Network Associates)...
Quand à l'IP.... c'est plusque basique :-))
Ces mesures de protection IP statique et filtrage MAC datent d'un autre temps sur les réseau Ethernet de 1990 à 1995 en gros. Les outils pour spoofer la MAC sous windows n'était pas diffusés à grande échelle comme maintenant et donc cela demandait des connaissance approfondie. Mais aujourd'hui, elle demeure non pas pour des raisons de sécurité mais plus pour faciliter la gestion d'un parc informatique, par exemple.
Et pour spoofer, comme déjà écrit précédement, avec un outil mais on peut le faire directement avec windows : http://www.klcconsulting.net/smac/
Pour jouer avec de l'ARP poisoning, et donc le spoof de MAC sous windows, il y aussi : http://www.oxid.it/ avec le fameux CAIN.
A+
Patrick
Bonjour,
Oui la MAC est plusque diffusée un petit tour sur le site de
netstumbler devrait faire du bien par exemple :
http://www.netstumbler.com/
Ou avec n'importe quel sniffer comme Ethereal, Wireshark, Sniffer Pro
(Network Associates)...
Quand à l'IP.... c'est plusque basique :-))
Ces mesures de protection IP statique et filtrage MAC datent d'un autre
temps sur les réseau Ethernet de 1990 à 1995 en gros. Les outils pour
spoofer la MAC sous windows n'était pas diffusés à grande échelle
comme maintenant et donc cela demandait des connaissance approfondie.
Mais aujourd'hui, elle demeure non pas pour des raisons de sécurité
mais plus pour faciliter la gestion d'un parc informatique, par
exemple.
Et pour spoofer, comme déjà écrit précédement, avec un outil mais
on peut le faire directement avec windows :
http://www.klcconsulting.net/smac/
Pour jouer avec de l'ARP poisoning, et donc le spoof de MAC sous
windows, il y aussi : http://www.oxid.it/ avec le fameux CAIN.
Oui la MAC est plusque diffusée un petit tour sur le site de netstumbler devrait faire du bien par exemple : http://www.netstumbler.com/
Ou avec n'importe quel sniffer comme Ethereal, Wireshark, Sniffer Pro (Network Associates)...
Quand à l'IP.... c'est plusque basique :-))
Ces mesures de protection IP statique et filtrage MAC datent d'un autre temps sur les réseau Ethernet de 1990 à 1995 en gros. Les outils pour spoofer la MAC sous windows n'était pas diffusés à grande échelle comme maintenant et donc cela demandait des connaissance approfondie. Mais aujourd'hui, elle demeure non pas pour des raisons de sécurité mais plus pour faciliter la gestion d'un parc informatique, par exemple.
Et pour spoofer, comme déjà écrit précédement, avec un outil mais on peut le faire directement avec windows : http://www.klcconsulting.net/smac/
Pour jouer avec de l'ARP poisoning, et donc le spoof de MAC sous windows, il y aussi : http://www.oxid.it/ avec le fameux CAIN.
A+
Patrick
pchene
Les raisons pour ne pas utiliser le DHCP sont d'abord pratiques: - si vous voulez ouvrir des ports entrants vers des serveurs (eMule, MSN Messenger etc.), c'est le bronx à régler en DHCP, - et en n'utilisant pas le DHCP, vous pouvez désactiver le client DHCP sur les postes du réseau (1 service de moins sous Windows).
Bonjour,
Non mauvaise raison, tu peux laisser ton Firewall tranquille, ainsi que ton DHCP en auto et tes virtual serveurs en paix. Dans les routeurs Dlink par exemple voir Menu "Special Applications" Comme il disent : Special Application is used to run applications that require multiple connections. Et donc le routeur devient transparent au flux emule quelque soit la becane connecté dessus et sans figer une adresse IP.
A+
Patrick
Les raisons pour ne pas utiliser le DHCP sont d'abord pratiques:
- si vous voulez ouvrir des ports entrants vers des serveurs (eMule, MSN
Messenger etc.), c'est le bronx à régler en DHCP,
- et en n'utilisant pas le DHCP, vous pouvez désactiver le client DHCP sur
les postes du réseau (1 service de moins sous Windows).
Bonjour,
Non mauvaise raison, tu peux laisser ton Firewall tranquille, ainsi que
ton DHCP en auto et tes virtual serveurs en paix.
Dans les routeurs Dlink par exemple voir Menu "Special Applications"
Comme il disent : Special Application is used to run applications that
require multiple connections. Et donc le routeur devient transparent au
flux emule quelque soit la becane connecté dessus et sans figer une
adresse IP.
Les raisons pour ne pas utiliser le DHCP sont d'abord pratiques: - si vous voulez ouvrir des ports entrants vers des serveurs (eMule, MSN Messenger etc.), c'est le bronx à régler en DHCP, - et en n'utilisant pas le DHCP, vous pouvez désactiver le client DHCP sur les postes du réseau (1 service de moins sous Windows).
Bonjour,
Non mauvaise raison, tu peux laisser ton Firewall tranquille, ainsi que ton DHCP en auto et tes virtual serveurs en paix. Dans les routeurs Dlink par exemple voir Menu "Special Applications" Comme il disent : Special Application is used to run applications that require multiple connections. Et donc le routeur devient transparent au flux emule quelque soit la becane connecté dessus et sans figer une adresse IP.
A+
Patrick
Guillaume
Bonjour,
nospheratus a wroté :
Oui je relis et je vois que tu argumente avec pas grand chose (3 personnes de ton entourage)
Bah j'ai pas d'amis que veux-tu j'fais avec ce que j'ai ;o)
Je ne saisis pas le sens de ta démarche. A quoi te sert-il de poster sur usenet dans un forum spécialisé dans la sécurité informatique, si tu viens y dire que de toute façon tu préfères te fier à l'avis de trois personnes de ton entourage qu'aux nombreux spécialistes de ce forum qui se sont intéressés à tes questions ? Contente-toi de l'avis de tes proches, s'il t'importe plus que celui des pros qui te répondent ici !
J'ai pas dis que le filtragepar Mac constituait une protection. J'ai dis qu'elle etait disons plus protectrice que le filtrage par IP.
Ben oui, mais tu te trompes, voilà tout.
Peux tu me définir un "vrai" pirate?
un mec avec un bandeau sur l'oeil ;-)
Comme ça : http://cjoint.com/?kqmjtaaaUJ ? Ph34r !
quitte à choisir autant prendrele filtrage par Mac adresse qui necessite du pirate une connaissance plus approfondie des reseaux.
Ton raisonnement est erroné.
D'abord, choisir une protection plutôt qu'une autre parce qu'elle exige une meilleure technicité de la part d'un potentiel intrus est un leurre : c'est la même chose que d'ouvrir sur un serveur de fichiers des partages cachés (par un $ au bout) en pensant que comme ils sont invisibles, ça va les protéger des accès illicites -ce qui est faux, évidemment, puisqu'il suffit de requêter différemment au serveur pour qu'il dise au visiteur tout ce qu'il veut savoir ... dans cet exemple tout comme dans le tien.
Ensuite, la protection par l'adresse MAC peut avoir un sens en mode connecté, parce qu'à une prise d'un switch correspond une adresse MAC et une seule, et qu'il y a forcément un problème s'il y a deux machines avec une MAC@ identique. Mais en mode _non connecté_ (ie. le WiFi), la borne émet et quiconque capte la fréquence peut lui répondre. Si une communication existe déjà entre une borne et un poste quelconque, on peut capter cette communication, et y trouver l'adresse MAC. Et si on recopie cette adresse sur sa propre interface et qu'on dialogue avec la borne, celle-ci n'a aucun moyen de savoir quelle transmission est légitime et laquelle ne l'est pas. Et comme DHCP -qui attribue les adresses IP- se *base* sur les adresses MAC, spoofer une MAC@ est la première étape nécessaire pour pénétrer un accès WiFi.
C'est pas que ce soit plus compliqué ou plus simple, c'est que c'est comme ça que ça marche, et c'est pour çà que se borner à ne filtrer que sur ces adresses est un leurre.
Je vois pas les choses ainsi. Si tu mets en place un filtrage par Mac adresse, en authorisant uniquement quelques mac a entrer sur le routeur, le mec qui va se presenter pour snifer sera jeter direct. Il faudra qu'il spoof une mac adresse pour sniffer ton rezo.
Mais non, pas du tout : la borne émet un signal radio que tout un chacun dans le périmètre d'émission peut capter, et donc capturer. Si dans la capture l'intrus potentiel y lit une adresse MAC, il la prend, il l'applique à son interface, et il peut passer à l'étape suivante (Wep/WPA - IP - ... ).
Si tu mets en place le filtrage par IP, je dirais que la majorité des routeurs des particuliers qui n'y connaissent pas grand chose laisse la config Ip par defaut, à savoir le routeur a pour IP 192.168.0.1 ou 192.168.0.251 en fonction des marques. Bon tu vas me dire que certains sont en 192.168.0.254, bref, là n'est pas le debat. Je pense que le mec ne mettra pas longtemps à trouver une Ip authorisée, j'dirais que bien souvent l'Ip 192.168.0.2 est authorisé, il suffit de laprendre et hop. Le "pirate" n'a qu'neviron 250 Ip à tester de toutes façon ça va vite ;-) Le filtrage par Mac offre quand meme un peu plus de possibilité non ?
Dans tous les cas, ça commence par une écoute des communications existantes sur la borne WiFi. En fonction de qu'il y trouve, l'intrus potentiel s'insère dans une communication existante, et comme il n'y a pas de support physique la borne n'a aucun moyen de différencier le trafic légitime du trafic parasite qui lui parvient. Ensuite c'est sur la base de l'adresse MAC -éventuellement recopiée- que *peut* s'établir un trafic IP (qui commence le cas échéant par une négociation DHCP), sous réserve que l'authentification WEP/WPA réussisse. Donc c'est lors de l'authentificationà qu'on sécurise, parce qu'avant, il suffit d'écouter causer la borne !
Si tu lis ce que j'ai mis plus haut tu peux comprendre que dans certains cas c'est une demande parfaitement valable. De toute façon en wifi l'adresse MAC est clairement annoncée.
pardon ? Explique un peu car là je te suis pas.
Je te suggère de consulter le modèle OSI, notamment dans les niveaux 1 à 3 : < http://www.frameip.com/osi/ > et de te pénétrer de l'idée que les couches les plus hautes reposent systématiquement sur les plus basses. Donc la couche IP repose sur la couche liaison, dans laquelle on a les adresses MAC.
Je suis d'accord avec toi. Mais reconnait que quitte à choisir mieux vaut un filtrage par mac que par Ip (il insiste le bougre lol )
Ben non, je ne reconnais pas! Pour toutes les raisons évoquées plus haut
Tsssssss tete de mule va ;-)
Tu devrais appliquer cette gentille critique à toi-même : si plusieurs intervenants de fcs te répètent la même chose, c'est qu'il y a une raison, et ce n'est pas de l'entêtement de _leur_ part. Si maintenant tu préfères te fier au jugement de tes proches, c'est ton problème, mais alors ce n'est pas la peine de demander des avis ici si c'est pour en faire fi.
-- Guillaume
Bonjour,
nospheratus a wroté :
Oui je relis et je vois que tu argumente avec pas grand chose (3 personnes
de ton entourage)
Bah j'ai pas d'amis que veux-tu j'fais avec ce que j'ai ;o)
Je ne saisis pas le sens de ta démarche.
A quoi te sert-il de poster sur usenet dans un forum spécialisé dans
la sécurité informatique, si tu viens y dire que de toute façon tu
préfères te fier à l'avis de trois personnes de ton entourage qu'aux
nombreux spécialistes de ce forum qui se sont intéressés à tes
questions ? Contente-toi de l'avis de tes proches, s'il t'importe plus
que celui des pros qui te répondent ici !
J'ai pas dis que le filtragepar Mac constituait une protection. J'ai dis
qu'elle etait disons plus protectrice que le filtrage par IP.
Ben oui, mais tu te trompes, voilà tout.
Peux tu me définir un "vrai" pirate?
un mec avec un bandeau sur l'oeil ;-)
Comme ça : http://cjoint.com/?kqmjtaaaUJ ?
Ph34r !
quitte à choisir autant
prendrele filtrage par Mac adresse qui necessite du pirate une
connaissance plus approfondie des reseaux.
Ton raisonnement est erroné.
D'abord, choisir une protection plutôt qu'une autre parce qu'elle
exige une meilleure technicité de la part d'un potentiel intrus est un
leurre : c'est la même chose que d'ouvrir sur un serveur de fichiers
des partages cachés (par un $ au bout) en pensant que comme ils sont
invisibles, ça va les protéger des accès illicites -ce qui est faux,
évidemment, puisqu'il suffit de requêter différemment au serveur pour
qu'il dise au visiteur tout ce qu'il veut savoir ... dans cet exemple
tout comme dans le tien.
Ensuite, la protection par l'adresse MAC peut avoir un sens en mode
connecté, parce qu'à une prise d'un switch correspond une adresse MAC
et une seule, et qu'il y a forcément un problème s'il y a deux
machines avec une MAC@ identique. Mais en mode _non connecté_ (ie. le
WiFi), la borne émet et quiconque capte la fréquence peut lui
répondre. Si une communication existe déjà entre une borne et un poste
quelconque, on peut capter cette communication, et y trouver l'adresse
MAC. Et si on recopie cette adresse sur sa propre interface et qu'on
dialogue avec la borne, celle-ci n'a aucun moyen de savoir quelle
transmission est légitime et laquelle ne l'est pas. Et comme DHCP -qui
attribue les adresses IP- se *base* sur les adresses MAC, spoofer une
MAC@ est la première étape nécessaire pour pénétrer un accès WiFi.
C'est pas que ce soit plus compliqué ou plus simple, c'est que c'est
comme ça que ça marche, et c'est pour çà que se borner à ne filtrer
que sur ces adresses est un leurre.
Je vois pas les choses ainsi. Si tu mets en place un filtrage par Mac
adresse, en authorisant uniquement quelques mac a entrer sur le routeur, le
mec qui va se presenter pour snifer sera jeter direct. Il faudra qu'il spoof
une mac adresse pour sniffer ton rezo.
Mais non, pas du tout : la borne émet un signal radio que tout un
chacun dans le périmètre d'émission peut capter, et donc capturer. Si
dans la capture l'intrus potentiel y lit une adresse MAC, il la prend,
il l'applique à son interface, et il peut passer à l'étape suivante
(Wep/WPA - IP - ... ).
Si tu mets en place le filtrage par IP, je dirais que la majorité des
routeurs des particuliers qui n'y connaissent pas grand chose laisse la
config Ip par defaut, à savoir le routeur a pour IP 192.168.0.1 ou
192.168.0.251 en fonction des marques. Bon tu vas me dire que certains sont
en 192.168.0.254, bref, là n'est pas le debat. Je pense que le mec ne mettra
pas longtemps à trouver une Ip authorisée, j'dirais que bien souvent l'Ip
192.168.0.2 est authorisé, il suffit de laprendre et hop. Le "pirate" n'a
qu'neviron 250 Ip à tester de toutes façon ça va vite ;-) Le filtrage par
Mac offre quand meme un peu plus de possibilité non ?
Dans tous les cas, ça commence par une écoute des communications
existantes sur la borne WiFi. En fonction de qu'il y trouve, l'intrus
potentiel s'insère dans une communication existante, et comme il n'y a
pas de support physique la borne n'a aucun moyen de différencier le
trafic légitime du trafic parasite qui lui parvient. Ensuite c'est sur
la base de l'adresse MAC -éventuellement recopiée- que *peut*
s'établir un trafic IP (qui commence le cas échéant par une
négociation DHCP), sous réserve que l'authentification WEP/WPA
réussisse. Donc c'est lors de l'authentificationà qu'on sécurise,
parce qu'avant, il suffit d'écouter causer la borne !
Si tu lis ce que j'ai mis plus haut tu peux comprendre que dans certains
cas c'est une demande parfaitement valable. De toute façon en wifi
l'adresse MAC est clairement annoncée.
pardon ? Explique un peu car là je te suis pas.
Je te suggère de consulter le modèle OSI, notamment dans les niveaux 1
à 3 : < http://www.frameip.com/osi/ > et de te pénétrer de l'idée que
les couches les plus hautes reposent systématiquement sur les plus
basses. Donc la couche IP repose sur la couche liaison, dans laquelle
on a les adresses MAC.
Je suis d'accord avec toi. Mais reconnait que quitte à choisir mieux
vaut un filtrage par mac que par Ip (il insiste le bougre lol )
Ben non, je ne reconnais pas! Pour toutes les raisons évoquées plus haut
Tsssssss tete de mule va ;-)
Tu devrais appliquer cette gentille critique à toi-même : si plusieurs
intervenants de fcs te répètent la même chose, c'est qu'il y a une
raison, et ce n'est pas de l'entêtement de _leur_ part. Si maintenant
tu préfères te fier au jugement de tes proches, c'est ton problème,
mais alors ce n'est pas la peine de demander des avis ici si c'est
pour en faire fi.
Oui je relis et je vois que tu argumente avec pas grand chose (3 personnes de ton entourage)
Bah j'ai pas d'amis que veux-tu j'fais avec ce que j'ai ;o)
Je ne saisis pas le sens de ta démarche. A quoi te sert-il de poster sur usenet dans un forum spécialisé dans la sécurité informatique, si tu viens y dire que de toute façon tu préfères te fier à l'avis de trois personnes de ton entourage qu'aux nombreux spécialistes de ce forum qui se sont intéressés à tes questions ? Contente-toi de l'avis de tes proches, s'il t'importe plus que celui des pros qui te répondent ici !
J'ai pas dis que le filtragepar Mac constituait une protection. J'ai dis qu'elle etait disons plus protectrice que le filtrage par IP.
Ben oui, mais tu te trompes, voilà tout.
Peux tu me définir un "vrai" pirate?
un mec avec un bandeau sur l'oeil ;-)
Comme ça : http://cjoint.com/?kqmjtaaaUJ ? Ph34r !
quitte à choisir autant prendrele filtrage par Mac adresse qui necessite du pirate une connaissance plus approfondie des reseaux.
Ton raisonnement est erroné.
D'abord, choisir une protection plutôt qu'une autre parce qu'elle exige une meilleure technicité de la part d'un potentiel intrus est un leurre : c'est la même chose que d'ouvrir sur un serveur de fichiers des partages cachés (par un $ au bout) en pensant que comme ils sont invisibles, ça va les protéger des accès illicites -ce qui est faux, évidemment, puisqu'il suffit de requêter différemment au serveur pour qu'il dise au visiteur tout ce qu'il veut savoir ... dans cet exemple tout comme dans le tien.
Ensuite, la protection par l'adresse MAC peut avoir un sens en mode connecté, parce qu'à une prise d'un switch correspond une adresse MAC et une seule, et qu'il y a forcément un problème s'il y a deux machines avec une MAC@ identique. Mais en mode _non connecté_ (ie. le WiFi), la borne émet et quiconque capte la fréquence peut lui répondre. Si une communication existe déjà entre une borne et un poste quelconque, on peut capter cette communication, et y trouver l'adresse MAC. Et si on recopie cette adresse sur sa propre interface et qu'on dialogue avec la borne, celle-ci n'a aucun moyen de savoir quelle transmission est légitime et laquelle ne l'est pas. Et comme DHCP -qui attribue les adresses IP- se *base* sur les adresses MAC, spoofer une MAC@ est la première étape nécessaire pour pénétrer un accès WiFi.
C'est pas que ce soit plus compliqué ou plus simple, c'est que c'est comme ça que ça marche, et c'est pour çà que se borner à ne filtrer que sur ces adresses est un leurre.
Je vois pas les choses ainsi. Si tu mets en place un filtrage par Mac adresse, en authorisant uniquement quelques mac a entrer sur le routeur, le mec qui va se presenter pour snifer sera jeter direct. Il faudra qu'il spoof une mac adresse pour sniffer ton rezo.
Mais non, pas du tout : la borne émet un signal radio que tout un chacun dans le périmètre d'émission peut capter, et donc capturer. Si dans la capture l'intrus potentiel y lit une adresse MAC, il la prend, il l'applique à son interface, et il peut passer à l'étape suivante (Wep/WPA - IP - ... ).
Si tu mets en place le filtrage par IP, je dirais que la majorité des routeurs des particuliers qui n'y connaissent pas grand chose laisse la config Ip par defaut, à savoir le routeur a pour IP 192.168.0.1 ou 192.168.0.251 en fonction des marques. Bon tu vas me dire que certains sont en 192.168.0.254, bref, là n'est pas le debat. Je pense que le mec ne mettra pas longtemps à trouver une Ip authorisée, j'dirais que bien souvent l'Ip 192.168.0.2 est authorisé, il suffit de laprendre et hop. Le "pirate" n'a qu'neviron 250 Ip à tester de toutes façon ça va vite ;-) Le filtrage par Mac offre quand meme un peu plus de possibilité non ?
Dans tous les cas, ça commence par une écoute des communications existantes sur la borne WiFi. En fonction de qu'il y trouve, l'intrus potentiel s'insère dans une communication existante, et comme il n'y a pas de support physique la borne n'a aucun moyen de différencier le trafic légitime du trafic parasite qui lui parvient. Ensuite c'est sur la base de l'adresse MAC -éventuellement recopiée- que *peut* s'établir un trafic IP (qui commence le cas échéant par une négociation DHCP), sous réserve que l'authentification WEP/WPA réussisse. Donc c'est lors de l'authentificationà qu'on sécurise, parce qu'avant, il suffit d'écouter causer la borne !
Si tu lis ce que j'ai mis plus haut tu peux comprendre que dans certains cas c'est une demande parfaitement valable. De toute façon en wifi l'adresse MAC est clairement annoncée.
pardon ? Explique un peu car là je te suis pas.
Je te suggère de consulter le modèle OSI, notamment dans les niveaux 1 à 3 : < http://www.frameip.com/osi/ > et de te pénétrer de l'idée que les couches les plus hautes reposent systématiquement sur les plus basses. Donc la couche IP repose sur la couche liaison, dans laquelle on a les adresses MAC.
Je suis d'accord avec toi. Mais reconnait que quitte à choisir mieux vaut un filtrage par mac que par Ip (il insiste le bougre lol )
Ben non, je ne reconnais pas! Pour toutes les raisons évoquées plus haut
Tsssssss tete de mule va ;-)
Tu devrais appliquer cette gentille critique à toi-même : si plusieurs intervenants de fcs te répètent la même chose, c'est qu'il y a une raison, et ce n'est pas de l'entêtement de _leur_ part. Si maintenant tu préfères te fier au jugement de tes proches, c'est ton problème, mais alors ce n'est pas la peine de demander des avis ici si c'est pour en faire fi.
-- Guillaume
Eric Masson
"pchene" writes:
'Lut,
Dans les routeurs Dlink par exemple voir Menu "Special Applications" Comme il disent : Special Application is used to run applications that require multiple connections.
Upnp, ça s'appelle et ça c'est vraiment dangereux, n'importe quelle application causant upnp (spécifications disponibles sur le net, voir Google) peut faire ouvrir tout et n'importe quoi au routeur. Et n'importe quelle application, ça peut recouvrir un code malicieux...
-- Il me vient une question. Et aucune n'est idiote. Il a-t-il une base associative à la gestion de la hiérarchie fr. Sinon, pourquoi ne pas en constituer une ? -+- YG in GNU : Neuneu Quichotte à l'asso des dinos. -+-
"pchene" <pchene@yahoo.fr> writes:
'Lut,
Dans les routeurs Dlink par exemple voir Menu "Special Applications"
Comme il disent : Special Application is used to run applications that
require multiple connections.
Upnp, ça s'appelle et ça c'est vraiment dangereux, n'importe quelle
application causant upnp (spécifications disponibles sur le net, voir
Google) peut faire ouvrir tout et n'importe quoi au routeur.
Et n'importe quelle application, ça peut recouvrir un code malicieux...
--
Il me vient une question. Et aucune n'est idiote.
Il a-t-il une base associative à la gestion de la hiérarchie fr.
Sinon, pourquoi ne pas en constituer une ?
-+- YG in GNU : Neuneu Quichotte à l'asso des dinos. -+-
Dans les routeurs Dlink par exemple voir Menu "Special Applications" Comme il disent : Special Application is used to run applications that require multiple connections.
Upnp, ça s'appelle et ça c'est vraiment dangereux, n'importe quelle application causant upnp (spécifications disponibles sur le net, voir Google) peut faire ouvrir tout et n'importe quoi au routeur. Et n'importe quelle application, ça peut recouvrir un code malicieux...
-- Il me vient une question. Et aucune n'est idiote. Il a-t-il une base associative à la gestion de la hiérarchie fr. Sinon, pourquoi ne pas en constituer une ? -+- YG in GNU : Neuneu Quichotte à l'asso des dinos. -+-
pchene
WPA-PSK n'est pas cracké, il n'y a pas, pour le moment, de faille avérée au niveau protocolaire.
Bonjour,
Question, allez vous lire les liens que j'indique à chaque fois ? Je commence à douter, car ce je fais avec WPA-PSK n'est pas nouveaux d'autres le font aussi très bien et pour le commentaire un lien de plus : http://libretto.debian.free.fr/aircrack.html
Lire aussi ceci en bas de la page du lien ci-dessus : Références : "Faiblesse dans le choix de la passphrase dans les réseaux WPA" ("Weakness in Passphrase Choice in WPA Interface") par Robert Moskowitz : http://wifinetnews.com/archives/002452.html. Où l'on voit que la qualité de la protection dépend de la qualité de la passphrase.
Avec un utilistaire de plus, toujours dans cette page : coWPAtty. Cet utilitaire a été écrit par Joshua Wright. Il permet de retrouver la passphrase qui a servi à générer la PSK (pre-shared key) utilisée dans un réseau WPA (Wifi Protected Access). La méthode utilisée est celle du "dictionnaire de force brute" (brute-force dictionary, ça sonne mieux en anglais). Le système tourne hors ligne.
Et le plus fun dans tout cela c'est que même dans les docs Cisco on a http://www.ciscopress.com/articles/article.asp?p70636&rl=1
A+
Patrick
WPA-PSK n'est pas cracké, il n'y a pas, pour le moment, de faille avérée
au niveau protocolaire.
Bonjour,
Question, allez vous lire les liens que j'indique à chaque fois ?
Je commence à douter, car ce je fais avec WPA-PSK n'est pas nouveaux
d'autres le font aussi très bien et pour le commentaire un lien de
plus : http://libretto.debian.free.fr/aircrack.html
Lire aussi ceci en bas de la page du lien ci-dessus :
Références :
"Faiblesse dans le choix de la passphrase dans les réseaux WPA"
("Weakness in Passphrase Choice in WPA Interface") par Robert Moskowitz
: http://wifinetnews.com/archives/002452.html. Où l'on voit que la
qualité de la protection dépend de la qualité de la passphrase.
Avec un utilistaire de plus, toujours dans cette page :
coWPAtty.
Cet utilitaire a été écrit par Joshua Wright. Il permet de retrouver
la passphrase qui a servi à générer la PSK (pre-shared key)
utilisée dans un réseau WPA (Wifi Protected Access). La méthode
utilisée est celle du "dictionnaire de force brute" (brute-force
dictionary, ça sonne mieux en anglais). Le système tourne hors ligne.
Et le plus fun dans tout cela c'est que même dans les docs Cisco on a
http://www.ciscopress.com/articles/article.asp?p70636&rl=1
WPA-PSK n'est pas cracké, il n'y a pas, pour le moment, de faille avérée au niveau protocolaire.
Bonjour,
Question, allez vous lire les liens que j'indique à chaque fois ? Je commence à douter, car ce je fais avec WPA-PSK n'est pas nouveaux d'autres le font aussi très bien et pour le commentaire un lien de plus : http://libretto.debian.free.fr/aircrack.html
Lire aussi ceci en bas de la page du lien ci-dessus : Références : "Faiblesse dans le choix de la passphrase dans les réseaux WPA" ("Weakness in Passphrase Choice in WPA Interface") par Robert Moskowitz : http://wifinetnews.com/archives/002452.html. Où l'on voit que la qualité de la protection dépend de la qualité de la passphrase.
Avec un utilistaire de plus, toujours dans cette page : coWPAtty. Cet utilitaire a été écrit par Joshua Wright. Il permet de retrouver la passphrase qui a servi à générer la PSK (pre-shared key) utilisée dans un réseau WPA (Wifi Protected Access). La méthode utilisée est celle du "dictionnaire de force brute" (brute-force dictionary, ça sonne mieux en anglais). Le système tourne hors ligne.
Et le plus fun dans tout cela c'est que même dans les docs Cisco on a http://www.ciscopress.com/articles/article.asp?p70636&rl=1
A+
Patrick
Eric Masson
"pchene" writes:
'Lut,
Question, allez vous lire les liens que j'indique à chaque fois ? Je commence à douter, car ce je fais avec WPA-PSK n'est pas nouveaux d'autres le font aussi très bien et pour le commentaire un lien de plus : http://libretto.debian.free.fr/aircrack.html
Et le plus fun dans tout cela c'est que même dans les docs Cisco on a http://www.ciscopress.com/articles/article.asp?p70636&rl=1
Et cela contredit la réponse que j'ai posté ?
Le dernier lien en particulier ne fait aucunement référence à une faille de WPA-PSK, il présente juste une méthode permettant de valider que la clé utilisée pour la protection du lan est dans le dictionnaire à disposition de l'outil utilisé pour l'attaque.
D'ailleurs pour quoter la fin du papier : "Our example provided a test using a previously known password. To successfully crack a random network, an attacker must have a large dictionary file, a powerful computer, and a little luck in order to obtain the password. Fortunately, this isn't as easy as it sounds."
Dans le cas de WEP, la différence de taille est qu'il est possible de retrouver la clé utilisée sans avoir recours à un dictionnaire, la capture du traffic (en volume suffisant) est suffisante pour la recalculer.
La différence majeure est que dans le cas de WEP, le protocole n'est pas cryptologiquement sûr (cela a été démontré) et a été cassé, alors que dans le cas de WPA, ce n'est pas le protocole qui est attaqué mais un défaut de mise en oeuvre, ce qui est radicalement différent.
Il n'est pas possible de faire reposer une quelconque sécurité sur une implémentation WEP alors que c'est tout à fait possible avec WPA-PSK (*) mis en oeuvre correctement.
* : Jusqu'à présent, car aucune faiblesse crytologique n'a pour le moment été mise en évidence dans le protocole.
-- Le fait est que dans mon bureau à moi que j'ai, quand le téléphone sonne et que le numéro ne s'affiche pas je considère que la personne n'a pas envie que je décroche. Et comme je suis un gars conciliant... -+-JCD in <http://www.le-gnu.net> : Le dino sait être conciliant -+-
"pchene" <pchene@yahoo.fr> writes:
'Lut,
Question, allez vous lire les liens que j'indique à chaque fois ?
Je commence à douter, car ce je fais avec WPA-PSK n'est pas nouveaux
d'autres le font aussi très bien et pour le commentaire un lien de
plus : http://libretto.debian.free.fr/aircrack.html
Et le plus fun dans tout cela c'est que même dans les docs Cisco on a
http://www.ciscopress.com/articles/article.asp?p70636&rl=1
Et cela contredit la réponse que j'ai posté ?
Le dernier lien en particulier ne fait aucunement référence à une faille
de WPA-PSK, il présente juste une méthode permettant de valider que la
clé utilisée pour la protection du lan est dans le dictionnaire à
disposition de l'outil utilisé pour l'attaque.
D'ailleurs pour quoter la fin du papier :
"Our example provided a test using a previously known password. To
successfully crack a random network, an attacker must have a large
dictionary file, a powerful computer, and a little luck in order to
obtain the password. Fortunately, this isn't as easy as it sounds."
Dans le cas de WEP, la différence de taille est qu'il est possible de
retrouver la clé utilisée sans avoir recours à un dictionnaire, la
capture du traffic (en volume suffisant) est suffisante pour la
recalculer.
La différence majeure est que dans le cas de WEP, le protocole n'est pas
cryptologiquement sûr (cela a été démontré) et a été cassé, alors que
dans le cas de WPA, ce n'est pas le protocole qui est attaqué mais un
défaut de mise en oeuvre, ce qui est radicalement différent.
Il n'est pas possible de faire reposer une quelconque sécurité sur une
implémentation WEP alors que c'est tout à fait possible avec WPA-PSK (*)
mis en oeuvre correctement.
* : Jusqu'à présent, car aucune faiblesse crytologique n'a pour le
moment été mise en évidence dans le protocole.
--
Le fait est que dans mon bureau à moi que j'ai, quand le téléphone
sonne et que le numéro ne s'affiche pas je considère que la personne
n'a pas envie que je décroche. Et comme je suis un gars conciliant...
-+-JCD in <http://www.le-gnu.net> : Le dino sait être conciliant -+-
Question, allez vous lire les liens que j'indique à chaque fois ? Je commence à douter, car ce je fais avec WPA-PSK n'est pas nouveaux d'autres le font aussi très bien et pour le commentaire un lien de plus : http://libretto.debian.free.fr/aircrack.html
Et le plus fun dans tout cela c'est que même dans les docs Cisco on a http://www.ciscopress.com/articles/article.asp?p70636&rl=1
Et cela contredit la réponse que j'ai posté ?
Le dernier lien en particulier ne fait aucunement référence à une faille de WPA-PSK, il présente juste une méthode permettant de valider que la clé utilisée pour la protection du lan est dans le dictionnaire à disposition de l'outil utilisé pour l'attaque.
D'ailleurs pour quoter la fin du papier : "Our example provided a test using a previously known password. To successfully crack a random network, an attacker must have a large dictionary file, a powerful computer, and a little luck in order to obtain the password. Fortunately, this isn't as easy as it sounds."
Dans le cas de WEP, la différence de taille est qu'il est possible de retrouver la clé utilisée sans avoir recours à un dictionnaire, la capture du traffic (en volume suffisant) est suffisante pour la recalculer.
La différence majeure est que dans le cas de WEP, le protocole n'est pas cryptologiquement sûr (cela a été démontré) et a été cassé, alors que dans le cas de WPA, ce n'est pas le protocole qui est attaqué mais un défaut de mise en oeuvre, ce qui est radicalement différent.
Il n'est pas possible de faire reposer une quelconque sécurité sur une implémentation WEP alors que c'est tout à fait possible avec WPA-PSK (*) mis en oeuvre correctement.
* : Jusqu'à présent, car aucune faiblesse crytologique n'a pour le moment été mise en évidence dans le protocole.
-- Le fait est que dans mon bureau à moi que j'ai, quand le téléphone sonne et que le numéro ne s'affiche pas je considère que la personne n'a pas envie que je décroche. Et comme je suis un gars conciliant... -+-JCD in <http://www.le-gnu.net> : Le dino sait être conciliant -+-
nospheratus
Salut Guillaume,
Je ne saisis pas le sens de ta démarche.
Je n'ai fais que réagitr un post qui me semblait pas exact.
A quoi te sert-il de poster sur usenet dans un forum spécialisé dans la sécurité informatique, si tu viens y dire que de toute façon tu préfères te fier à l'avis de trois personnes de ton entourage qu'aux nombreux spécialistes de ce forum qui se sont intéressés à tes questions ? Contente-toi de l'avis de tes proches, s'il t'importe plus que celui des pros qui te répondent ici !
Je faisais de l'humour, tu n'as peut-etre pas suivis la totalité des echanges qui sont j'(en conviens quelque peu long et je vais écourté le dialogue de sourd qui ne mène à rien. Ensuite il y a pro et pro, dire :"tu as tort et tais toi" c'est facile jusqu'à ton post je n'ai vu aucun arguments qui m'ont montré que j'avais tord. Les pros comme tu dis, j'ai plus trouvé qu'ils pensaient que leur savoir était universel sans penser à l'utilisateur lambda qui compose la majorité des internautes.
J'ai pas dis que le filtragepar Mac constituait une protection. J'ai dis qu'elle etait disons plus protectrice que le filtrage par IP.
Ben oui, mais tu te trompes, voilà tout.
Visiblement, mais bon j'ai toujours pas l'explication qui dit que le filtrage par Ip offre plus de protection que le filtrage par Mac adresse. Explique moi par A+B et j'admetrai.
Ton raisonnement est erroné.
D'abord, choisir une protection plutôt qu'une autre parce qu'elle exige une meilleure technicité de la part d'un potentiel intrus est un leurre : c'est la même chose que d'ouvrir sur un serveur de fichiers des partages cachés (par un $ au bout) en pensant que comme ils sont invisibles, ça va les protéger des accès illicites -ce qui est faux, évidemment, puisqu'il suffit de requêter différemment au serveur pour qu'il dise au visiteur tout ce qu'il veut savoir ... dans cet exemple tout comme dans le tien.
J'en conviens, mais tout de même plus on reduit le nombres de personnes ayant la possiblité de rentrer mieux c'est, car de toutes façons il n'y a pas de sécurité absolue. A t'ecouter on devrait laisser ouvert, car bon, de toutes façons c'est pénétrable.... Je suis pas d'accord, personnellement je pense qu'il est preferable de complixifier la démarrache d'un eventuel intrus.
Ensuite, la protection par l'adresse MAC peut avoir un sens en mode connecté, parce qu'à une prise d'un switch correspond une adresse MAC et une seule, et qu'il y a forcément un problème s'il y a deux machines avec une MAC@ identique. Mais en mode _non connecté_ (ie. le WiFi), la borne émet et quiconque capte la fréquence peut lui répondre. Si une communication existe déjà entre une borne et un poste quelconque, on peut capter cette communication, et y trouver l'adresse MAC. Et si on recopie cette adresse sur sa propre interface et qu'on dialogue avec la borne, celle-ci n'a aucun moyen de savoir quelle transmission est légitime et laquelle ne l'est pas. Et comme DHCP -qui attribue les adresses IP- se *base* sur les adresses MAC, spoofer une MAC@ est la première étape nécessaire pour pénétrer un accès WiFi.
C'est pas que ce soit plus compliqué ou plus simple, c'est que c'est comme ça que ça marche, et c'est pour çà que se borner à ne filtrer que sur ces adresses est un leurre.
Ok je comprends. Donc pour conclure, on peut dire que le filtrage par mac ou par Ip est completement facultatif, car pour entrer sur un reseau wifi, il suffit d'écouter et de paramètrer sa connexion comme il faut. Merci de l'info, j'ignorais celà. ENFIN une explication qui tient la route ;-)
Mais non, pas du tout : la borne émet un signal radio que tout un chacun dans le périmètre d'émission peut capter, et donc capturer. Si dans la capture l'intrus potentiel y lit une adresse MAC, il la prend, il l'applique à son interface, et il peut passer à l'étape suivante (Wep/WPA - IP - ... ).
Ok je comprends le fonctionnement.
Dans tous les cas, ça commence par une écoute des communications existantes sur la borne WiFi. En fonction de qu'il y trouve, l'intrus potentiel s'insère dans une communication existante, et comme il n'y a pas de support physique la borne n'a aucun moyen de différencier le trafic légitime du trafic parasite qui lui parvient. Ensuite c'est sur la base de l'adresse MAC -éventuellement recopiée- que *peut* s'établir un trafic IP (qui commence le cas échéant par une négociation DHCP), sous réserve que l'authentification WEP/WPA réussisse. Donc c'est lors de l'authentificationà qu'on sécurise, parce qu'avant, il suffit d'écouter causer la borne !
Ok. Je voyais pas le fonctionnement comme ça. Je voyais les bornes wifi fonctionner comme un switch. En fait la borne emmet le signale et n'ecoute pas, ce qui la rend donc volubile en matière d'informations de connexion. Je pensais qu'il fallait soit même ouvrir une connexion sur la borne pour qu'elle demande les infos. En mot simple, je pensais que toi tu ouvres ta connexion avec la mac authorisée, ensuite elle te donnait l'IP, et ensuite vérifiait la clef cryptée et appliquait les regles. En fait si je suis ce que tu dis, elle envoie à qui écoute qu'elle attends une connexion avec telle mac adresse et telle reseau, etc.... J'avoue etre un peu surpris de ce fonctionnement, mais vu que tu es un pro (c'est toi qui l'a dit) j'admet mon erreur et corrige donc mon jugement.
Je te suggère de consulter le modèle OSI, notamment dans les niveaux 1 à 3 : < http://www.frameip.com/osi/ > et de te pénétrer de l'idée que les couches les plus hautes reposent systématiquement sur les plus basses. Donc la couche IP repose sur la couche liaison, dans laquelle on a les adresses MAC.
J'y jetrai un oeil merci.
Tu devrais appliquer cette gentille critique à toi-même : si plusieurs intervenants de fcs te répètent la même chose, c'est qu'il y a une raison, et ce n'est pas de l'entêtement de _leur_ part. Si maintenant tu préfères te fier au jugement de tes proches, c'est ton problème, mais alors ce n'est pas la peine de demander des avis ici si c'est pour en faire fi.
Tu prends celà trop à coeur. Je faisais de l'humour. J'ai appris pas mal en lisant ton post, bien plus qu'en 10 enfilades de soit disant pros. Je me suis jamais presenté comme un specialiste loin de là. J'ai juste participé, et indiqué ce que je pensais. Jusqu'à toi, personne ne m'a rien démontré, sans doute parcequ'ils se contentaient de repeter ce qu'ils avaient entendu/lu. Désolé je suis pas comme ça, quand j'ai une conviction que je peux démontrer, meme si mes paramètres sont incorrects comme ici, mais j'ignorais certaines choses, je me contente pas de dire comme la majorité et defend mon point de vue. C'est mal ? Ce n'est pas adapté à l'usenet ? Je doute fort... Je pars du principe que tout le monde peut apprendre de tout le monde, et ce n'est qu'en expliquant les choses qu'on avance, pas en disant "c'est comme ça car on est 100 à le dire." Mon approche était erroné, je le reconnait. En fait mon erreur etait dans le fonctionnement de la borne, j'ai appris, je recommencerai pas deux fois la même erreur. Je te remercie pour tes explications, mais je trouve domage que tes amis les pros n'aient pas expliquer les choses comme toi depuis le début on aurait gagner pas mal de posts. Je note qu'il ne faut plus intervenir ici, les posts etant réservé à une poigné de nombrilistes qui refusent en bloc les autres sans meme donner la moindre explication quand un nouveau se trompe. Je me demande si c'est moi ou eux qui ne comprennent pas l'usenet.... Merci à toi. Cordialement, -- NosPHeratus http://www.nosland.com
Salut Guillaume,
Je ne saisis pas le sens de ta démarche.
Je n'ai fais que réagitr un post qui me semblait pas exact.
A quoi te sert-il de poster sur usenet dans un forum spécialisé dans
la sécurité informatique, si tu viens y dire que de toute façon tu
préfères te fier à l'avis de trois personnes de ton entourage qu'aux
nombreux spécialistes de ce forum qui se sont intéressés à tes
questions ? Contente-toi de l'avis de tes proches, s'il t'importe plus
que celui des pros qui te répondent ici !
Je faisais de l'humour, tu n'as peut-etre pas suivis la totalité des
echanges qui sont j'(en conviens quelque peu long et je vais écourté le
dialogue de sourd qui ne mène à rien. Ensuite il y a pro et pro, dire :"tu
as tort et tais toi" c'est facile jusqu'à ton post je n'ai vu aucun
arguments qui m'ont montré que j'avais tord. Les pros comme tu dis, j'ai
plus trouvé qu'ils pensaient que leur savoir était universel sans penser à
l'utilisateur lambda qui compose la majorité des internautes.
J'ai pas dis que le filtragepar Mac constituait une protection. J'ai dis
qu'elle etait disons plus protectrice que le filtrage par IP.
Ben oui, mais tu te trompes, voilà tout.
Visiblement, mais bon j'ai toujours pas l'explication qui dit que le
filtrage par Ip offre plus de protection que le filtrage par Mac adresse.
Explique moi par A+B et j'admetrai.
Ton raisonnement est erroné.
D'abord, choisir une protection plutôt qu'une autre parce qu'elle
exige une meilleure technicité de la part d'un potentiel intrus est un
leurre : c'est la même chose que d'ouvrir sur un serveur de fichiers
des partages cachés (par un $ au bout) en pensant que comme ils sont
invisibles, ça va les protéger des accès illicites -ce qui est faux,
évidemment, puisqu'il suffit de requêter différemment au serveur pour
qu'il dise au visiteur tout ce qu'il veut savoir ... dans cet exemple
tout comme dans le tien.
J'en conviens, mais tout de même plus on reduit le nombres de personnes
ayant la possiblité de rentrer mieux c'est, car de toutes façons il n'y a
pas de sécurité absolue. A t'ecouter on devrait laisser ouvert, car bon, de
toutes façons c'est pénétrable.... Je suis pas d'accord, personnellement je
pense qu'il est preferable de complixifier la démarrache d'un eventuel
intrus.
Ensuite, la protection par l'adresse MAC peut avoir un sens en mode
connecté, parce qu'à une prise d'un switch correspond une adresse MAC
et une seule, et qu'il y a forcément un problème s'il y a deux
machines avec une MAC@ identique. Mais en mode _non connecté_ (ie. le
WiFi), la borne émet et quiconque capte la fréquence peut lui
répondre. Si une communication existe déjà entre une borne et un poste
quelconque, on peut capter cette communication, et y trouver l'adresse
MAC. Et si on recopie cette adresse sur sa propre interface et qu'on
dialogue avec la borne, celle-ci n'a aucun moyen de savoir quelle
transmission est légitime et laquelle ne l'est pas. Et comme DHCP -qui
attribue les adresses IP- se *base* sur les adresses MAC, spoofer une
MAC@ est la première étape nécessaire pour pénétrer un accès WiFi.
C'est pas que ce soit plus compliqué ou plus simple, c'est que c'est
comme ça que ça marche, et c'est pour çà que se borner à ne filtrer
que sur ces adresses est un leurre.
Ok je comprends. Donc pour conclure, on peut dire que le filtrage par mac ou
par Ip est completement facultatif, car pour entrer sur un reseau wifi, il
suffit d'écouter et de paramètrer sa connexion comme il faut. Merci de
l'info, j'ignorais celà. ENFIN une explication qui tient la route ;-)
Mais non, pas du tout : la borne émet un signal radio que tout un
chacun dans le périmètre d'émission peut capter, et donc capturer. Si
dans la capture l'intrus potentiel y lit une adresse MAC, il la prend,
il l'applique à son interface, et il peut passer à l'étape suivante
(Wep/WPA - IP - ... ).
Ok je comprends le fonctionnement.
Dans tous les cas, ça commence par une écoute des communications
existantes sur la borne WiFi. En fonction de qu'il y trouve, l'intrus
potentiel s'insère dans une communication existante, et comme il n'y a
pas de support physique la borne n'a aucun moyen de différencier le
trafic légitime du trafic parasite qui lui parvient. Ensuite c'est sur
la base de l'adresse MAC -éventuellement recopiée- que *peut*
s'établir un trafic IP (qui commence le cas échéant par une
négociation DHCP), sous réserve que l'authentification WEP/WPA
réussisse. Donc c'est lors de l'authentificationà qu'on sécurise,
parce qu'avant, il suffit d'écouter causer la borne !
Ok. Je voyais pas le fonctionnement comme ça. Je voyais les bornes wifi
fonctionner comme un switch. En fait la borne emmet le signale et n'ecoute
pas, ce qui la rend donc volubile en matière d'informations de connexion. Je
pensais qu'il fallait soit même ouvrir une connexion sur la borne pour
qu'elle demande les infos. En mot simple, je pensais que toi tu ouvres ta
connexion avec la mac authorisée, ensuite elle te donnait l'IP, et ensuite
vérifiait la clef cryptée et appliquait les regles. En fait si je suis ce
que tu dis, elle envoie à qui écoute qu'elle attends une connexion avec
telle mac adresse et telle reseau, etc.... J'avoue etre un peu surpris de ce
fonctionnement, mais vu que tu es un pro (c'est toi qui l'a dit) j'admet mon
erreur et corrige donc mon jugement.
Je te suggère de consulter le modèle OSI, notamment dans les niveaux 1
à 3 : < http://www.frameip.com/osi/ > et de te pénétrer de l'idée que
les couches les plus hautes reposent systématiquement sur les plus
basses. Donc la couche IP repose sur la couche liaison, dans laquelle
on a les adresses MAC.
J'y jetrai un oeil merci.
Tu devrais appliquer cette gentille critique à toi-même : si plusieurs
intervenants de fcs te répètent la même chose, c'est qu'il y a une
raison, et ce n'est pas de l'entêtement de _leur_ part. Si maintenant
tu préfères te fier au jugement de tes proches, c'est ton problème,
mais alors ce n'est pas la peine de demander des avis ici si c'est
pour en faire fi.
Tu prends celà trop à coeur. Je faisais de l'humour. J'ai appris pas mal en
lisant ton post, bien plus qu'en 10 enfilades de soit disant pros.
Je me suis jamais presenté comme un specialiste loin de là. J'ai juste
participé, et indiqué ce que je pensais.
Jusqu'à toi, personne ne m'a rien démontré, sans doute parcequ'ils se
contentaient de repeter ce qu'ils avaient entendu/lu.
Désolé je suis pas comme ça, quand j'ai une conviction que je peux
démontrer, meme si mes paramètres sont incorrects comme ici, mais j'ignorais
certaines choses, je me contente pas de dire comme la majorité et defend mon
point de vue. C'est mal ? Ce n'est pas adapté à l'usenet ? Je doute fort...
Je pars du principe que tout le monde peut apprendre de tout le monde, et ce
n'est qu'en expliquant les choses qu'on avance, pas en disant "c'est comme
ça car on est 100 à le dire."
Mon approche était erroné, je le reconnait. En fait mon erreur etait dans
le fonctionnement de la borne, j'ai appris, je recommencerai pas deux fois
la même erreur. Je te remercie pour tes explications, mais je trouve domage
que tes amis les pros n'aient pas expliquer les choses comme toi depuis le
début on aurait gagner pas mal de posts.
Je note qu'il ne faut plus intervenir ici, les posts etant réservé à une
poigné de nombrilistes qui refusent en bloc les autres sans meme donner la
moindre explication quand un nouveau se trompe. Je me demande si c'est moi
ou eux qui ne comprennent pas l'usenet....
Merci à toi.
Cordialement,
--
NosPHeratus
http://www.nosland.com
Je n'ai fais que réagitr un post qui me semblait pas exact.
A quoi te sert-il de poster sur usenet dans un forum spécialisé dans la sécurité informatique, si tu viens y dire que de toute façon tu préfères te fier à l'avis de trois personnes de ton entourage qu'aux nombreux spécialistes de ce forum qui se sont intéressés à tes questions ? Contente-toi de l'avis de tes proches, s'il t'importe plus que celui des pros qui te répondent ici !
Je faisais de l'humour, tu n'as peut-etre pas suivis la totalité des echanges qui sont j'(en conviens quelque peu long et je vais écourté le dialogue de sourd qui ne mène à rien. Ensuite il y a pro et pro, dire :"tu as tort et tais toi" c'est facile jusqu'à ton post je n'ai vu aucun arguments qui m'ont montré que j'avais tord. Les pros comme tu dis, j'ai plus trouvé qu'ils pensaient que leur savoir était universel sans penser à l'utilisateur lambda qui compose la majorité des internautes.
J'ai pas dis que le filtragepar Mac constituait une protection. J'ai dis qu'elle etait disons plus protectrice que le filtrage par IP.
Ben oui, mais tu te trompes, voilà tout.
Visiblement, mais bon j'ai toujours pas l'explication qui dit que le filtrage par Ip offre plus de protection que le filtrage par Mac adresse. Explique moi par A+B et j'admetrai.
Ton raisonnement est erroné.
D'abord, choisir une protection plutôt qu'une autre parce qu'elle exige une meilleure technicité de la part d'un potentiel intrus est un leurre : c'est la même chose que d'ouvrir sur un serveur de fichiers des partages cachés (par un $ au bout) en pensant que comme ils sont invisibles, ça va les protéger des accès illicites -ce qui est faux, évidemment, puisqu'il suffit de requêter différemment au serveur pour qu'il dise au visiteur tout ce qu'il veut savoir ... dans cet exemple tout comme dans le tien.
J'en conviens, mais tout de même plus on reduit le nombres de personnes ayant la possiblité de rentrer mieux c'est, car de toutes façons il n'y a pas de sécurité absolue. A t'ecouter on devrait laisser ouvert, car bon, de toutes façons c'est pénétrable.... Je suis pas d'accord, personnellement je pense qu'il est preferable de complixifier la démarrache d'un eventuel intrus.
Ensuite, la protection par l'adresse MAC peut avoir un sens en mode connecté, parce qu'à une prise d'un switch correspond une adresse MAC et une seule, et qu'il y a forcément un problème s'il y a deux machines avec une MAC@ identique. Mais en mode _non connecté_ (ie. le WiFi), la borne émet et quiconque capte la fréquence peut lui répondre. Si une communication existe déjà entre une borne et un poste quelconque, on peut capter cette communication, et y trouver l'adresse MAC. Et si on recopie cette adresse sur sa propre interface et qu'on dialogue avec la borne, celle-ci n'a aucun moyen de savoir quelle transmission est légitime et laquelle ne l'est pas. Et comme DHCP -qui attribue les adresses IP- se *base* sur les adresses MAC, spoofer une MAC@ est la première étape nécessaire pour pénétrer un accès WiFi.
C'est pas que ce soit plus compliqué ou plus simple, c'est que c'est comme ça que ça marche, et c'est pour çà que se borner à ne filtrer que sur ces adresses est un leurre.
Ok je comprends. Donc pour conclure, on peut dire que le filtrage par mac ou par Ip est completement facultatif, car pour entrer sur un reseau wifi, il suffit d'écouter et de paramètrer sa connexion comme il faut. Merci de l'info, j'ignorais celà. ENFIN une explication qui tient la route ;-)
Mais non, pas du tout : la borne émet un signal radio que tout un chacun dans le périmètre d'émission peut capter, et donc capturer. Si dans la capture l'intrus potentiel y lit une adresse MAC, il la prend, il l'applique à son interface, et il peut passer à l'étape suivante (Wep/WPA - IP - ... ).
Ok je comprends le fonctionnement.
Dans tous les cas, ça commence par une écoute des communications existantes sur la borne WiFi. En fonction de qu'il y trouve, l'intrus potentiel s'insère dans une communication existante, et comme il n'y a pas de support physique la borne n'a aucun moyen de différencier le trafic légitime du trafic parasite qui lui parvient. Ensuite c'est sur la base de l'adresse MAC -éventuellement recopiée- que *peut* s'établir un trafic IP (qui commence le cas échéant par une négociation DHCP), sous réserve que l'authentification WEP/WPA réussisse. Donc c'est lors de l'authentificationà qu'on sécurise, parce qu'avant, il suffit d'écouter causer la borne !
Ok. Je voyais pas le fonctionnement comme ça. Je voyais les bornes wifi fonctionner comme un switch. En fait la borne emmet le signale et n'ecoute pas, ce qui la rend donc volubile en matière d'informations de connexion. Je pensais qu'il fallait soit même ouvrir une connexion sur la borne pour qu'elle demande les infos. En mot simple, je pensais que toi tu ouvres ta connexion avec la mac authorisée, ensuite elle te donnait l'IP, et ensuite vérifiait la clef cryptée et appliquait les regles. En fait si je suis ce que tu dis, elle envoie à qui écoute qu'elle attends une connexion avec telle mac adresse et telle reseau, etc.... J'avoue etre un peu surpris de ce fonctionnement, mais vu que tu es un pro (c'est toi qui l'a dit) j'admet mon erreur et corrige donc mon jugement.
Je te suggère de consulter le modèle OSI, notamment dans les niveaux 1 à 3 : < http://www.frameip.com/osi/ > et de te pénétrer de l'idée que les couches les plus hautes reposent systématiquement sur les plus basses. Donc la couche IP repose sur la couche liaison, dans laquelle on a les adresses MAC.
J'y jetrai un oeil merci.
Tu devrais appliquer cette gentille critique à toi-même : si plusieurs intervenants de fcs te répètent la même chose, c'est qu'il y a une raison, et ce n'est pas de l'entêtement de _leur_ part. Si maintenant tu préfères te fier au jugement de tes proches, c'est ton problème, mais alors ce n'est pas la peine de demander des avis ici si c'est pour en faire fi.
Tu prends celà trop à coeur. Je faisais de l'humour. J'ai appris pas mal en lisant ton post, bien plus qu'en 10 enfilades de soit disant pros. Je me suis jamais presenté comme un specialiste loin de là. J'ai juste participé, et indiqué ce que je pensais. Jusqu'à toi, personne ne m'a rien démontré, sans doute parcequ'ils se contentaient de repeter ce qu'ils avaient entendu/lu. Désolé je suis pas comme ça, quand j'ai une conviction que je peux démontrer, meme si mes paramètres sont incorrects comme ici, mais j'ignorais certaines choses, je me contente pas de dire comme la majorité et defend mon point de vue. C'est mal ? Ce n'est pas adapté à l'usenet ? Je doute fort... Je pars du principe que tout le monde peut apprendre de tout le monde, et ce n'est qu'en expliquant les choses qu'on avance, pas en disant "c'est comme ça car on est 100 à le dire." Mon approche était erroné, je le reconnait. En fait mon erreur etait dans le fonctionnement de la borne, j'ai appris, je recommencerai pas deux fois la même erreur. Je te remercie pour tes explications, mais je trouve domage que tes amis les pros n'aient pas expliquer les choses comme toi depuis le début on aurait gagner pas mal de posts. Je note qu'il ne faut plus intervenir ici, les posts etant réservé à une poigné de nombrilistes qui refusent en bloc les autres sans meme donner la moindre explication quand un nouveau se trompe. Je me demande si c'est moi ou eux qui ne comprennent pas l'usenet.... Merci à toi. Cordialement, -- NosPHeratus http://www.nosland.com
Eric Razny
Le Mon, 16 Oct 2006 09:32:12 +0000, Nina Popravka a écrit :
On 16 Oct 2006 08:29:39 GMT, Eric Masson wrote:
Enfin, la majorité des box gère upnp qui permet l'ouverture dynamique de ports sur la box à la requête des clients du lan et qui est amha, largement plus dangereux.
Remarque bien que conntrack, qui est intégré dans, par exemple, le firmware DD-WRT pour le WRT54G, semble, vu de ma fenêtre, faire très exactement la même chose.
Non. Pour netfilter/iptable, conntrack utilise différents modules qui peuvent ou non être activé *au choix de l'admin du routeur*. Les questions récurrentes du "pourquoi ftp ça ne passe pas?" des gens qui n'activent pas le module (pour ceux qui ont les fonctionnalités sous cette forme) sont assez probantes sur ce point.
Pour ce qui est de l'upnp il me semble (je ne suis pas un spécialiste de ce protocole que je désactive toujours) que c'est du tout ou rien.
Un risque très marrant, par exemple, est de pouvoir acceder à un serveur smtp interne qui, puisqu'il est interne, est insuffisament protégé (c'est mal) contre le relay. Miam :)
En ce moment avec les serveur web vunerables et les browers qui ont le droit de faire n'importe quoi ça ne doit pas être la mer à boire que de provoquer les requètes upnp qui vont bien :-/
A noter qu'il suffit d'une machine sur le lan qui est insuffisament protéger pour pouvoir configurer le routeur presque à sa guise
En conclusion je ne peux qu'être d'accord avec Eric et déconseiller l'utilisation du bidule d'autant qu'il n'est pas fréquent de justifier l'usage de l'upnp, au moins en entreprise (un proxy est souvent une solution plus raisonnable s'il est dispo pour le protocole choisi)
Le Mon, 16 Oct 2006 09:32:12 +0000, Nina Popravka a écrit :
On 16 Oct 2006 08:29:39 GMT, Eric Masson <emss@free.fr> wrote:
Enfin, la majorité des box gère upnp qui permet l'ouverture dynamique de
ports sur la box à la requête des clients du lan et qui est amha,
largement plus dangereux.
Remarque bien que conntrack, qui est intégré dans, par exemple, le
firmware DD-WRT pour le WRT54G, semble, vu de ma fenêtre, faire très
exactement la même chose.
Non.
Pour netfilter/iptable, conntrack utilise différents modules qui
peuvent ou non être activé *au choix de l'admin du routeur*. Les
questions récurrentes du "pourquoi ftp ça ne passe pas?" des gens qui
n'activent pas le module (pour ceux qui ont les fonctionnalités sous
cette forme) sont assez probantes sur ce point.
Pour ce qui est de l'upnp il me semble (je ne suis pas un spécialiste de
ce protocole que je désactive toujours) que c'est du tout ou rien.
Un risque très marrant, par exemple, est de pouvoir acceder à un serveur
smtp interne qui, puisqu'il est interne, est insuffisament protégé
(c'est mal) contre le relay. Miam :)
En ce moment avec les serveur web vunerables et les browers qui ont le
droit de faire n'importe quoi ça ne doit pas être la mer à boire que de
provoquer les requètes upnp qui vont bien :-/
A noter qu'il suffit d'une machine sur le lan qui est insuffisament
protéger pour pouvoir configurer le routeur presque à sa guise
En conclusion je ne peux qu'être d'accord avec Eric et déconseiller
l'utilisation du bidule d'autant qu'il n'est pas fréquent de justifier
l'usage de l'upnp, au moins en entreprise (un proxy est souvent une
solution plus raisonnable s'il est dispo pour le protocole choisi)
Le Mon, 16 Oct 2006 09:32:12 +0000, Nina Popravka a écrit :
On 16 Oct 2006 08:29:39 GMT, Eric Masson wrote:
Enfin, la majorité des box gère upnp qui permet l'ouverture dynamique de ports sur la box à la requête des clients du lan et qui est amha, largement plus dangereux.
Remarque bien que conntrack, qui est intégré dans, par exemple, le firmware DD-WRT pour le WRT54G, semble, vu de ma fenêtre, faire très exactement la même chose.
Non. Pour netfilter/iptable, conntrack utilise différents modules qui peuvent ou non être activé *au choix de l'admin du routeur*. Les questions récurrentes du "pourquoi ftp ça ne passe pas?" des gens qui n'activent pas le module (pour ceux qui ont les fonctionnalités sous cette forme) sont assez probantes sur ce point.
Pour ce qui est de l'upnp il me semble (je ne suis pas un spécialiste de ce protocole que je désactive toujours) que c'est du tout ou rien.
Un risque très marrant, par exemple, est de pouvoir acceder à un serveur smtp interne qui, puisqu'il est interne, est insuffisament protégé (c'est mal) contre le relay. Miam :)
En ce moment avec les serveur web vunerables et les browers qui ont le droit de faire n'importe quoi ça ne doit pas être la mer à boire que de provoquer les requètes upnp qui vont bien :-/
A noter qu'il suffit d'une machine sur le lan qui est insuffisament protéger pour pouvoir configurer le routeur presque à sa guise
En conclusion je ne peux qu'être d'accord avec Eric et déconseiller l'utilisation du bidule d'autant qu'il n'est pas fréquent de justifier l'usage de l'upnp, au moins en entreprise (un proxy est souvent une solution plus raisonnable s'il est dispo pour le protocole choisi)
Eric Razny
Le Mon, 16 Oct 2006 10:16:34 +0000, Fabien LE LEZ a écrit :
On 16 Oct 2006 08:29:39 GMT, Nina Popravka :
Mais il faut alors que le serveur DHCP soit fiable. Bah, en général ce sont des trucs qui fonctionnent...
Si c'est une machine que tu contrôles, je veux bien. Si c'est la freebox, bof.
Il existe aussi des cas où des machines du lan doivent communiquer avec un serveur (sur le lan ou pas) et si le dhcp est en rade (je ne sais plus si c'est toujours le cas mais à une époque j'ai vu pas mal de clients ayant des problèmes avec le serveur MS -oui, je sais... :) ) les applis ne marcheront pas alors qu'en IP fixée il n'y a pas de problème.
En pratique je n'ai rien contre le DHCP (surtout avec attribution des adresses IP en fonction de l'adresse MAC, sachant que les deux peuvent être bidonnées :) ) surtout quand il y a de nombreuses stations sur le reseaux, mais dans ce cas je mets les serveurs et machines critiques avec une adresse IP "en dur" et le reste en dhcp sur une autre plage.
Le problème du "en général ce sont des trucs qui fonctionnent" est que certains responsables oublient que dans certains environnement on ne peut pas se contenter de ça :)
Le Mon, 16 Oct 2006 10:16:34 +0000, Fabien LE LEZ a écrit :
On 16 Oct 2006 08:29:39 GMT, Nina Popravka <Nina@nospam.news.free.fr>:
Mais il faut alors que le serveur DHCP soit fiable.
Bah, en général ce sont des trucs qui fonctionnent...
Si c'est une machine que tu contrôles, je veux bien.
Si c'est la freebox, bof.
Il existe aussi des cas où des machines du lan doivent communiquer avec
un serveur (sur le lan ou pas) et si le dhcp est en rade (je ne sais plus
si c'est toujours le cas mais à une époque j'ai vu pas mal de clients
ayant des problèmes avec le serveur MS -oui, je sais... :) ) les applis
ne marcheront pas alors qu'en IP fixée il n'y a pas de problème.
En pratique je n'ai rien contre le DHCP (surtout avec attribution des
adresses IP en fonction de l'adresse MAC, sachant que les deux peuvent
être bidonnées :) ) surtout quand il y a de nombreuses stations sur le
reseaux, mais dans ce cas je mets les serveurs et machines critiques avec
une adresse IP "en dur" et le reste en dhcp sur une autre plage.
Le problème du "en général ce sont des trucs qui fonctionnent" est que
certains responsables oublient que dans certains environnement on ne peut
pas se contenter de ça :)
Le Mon, 16 Oct 2006 10:16:34 +0000, Fabien LE LEZ a écrit :
On 16 Oct 2006 08:29:39 GMT, Nina Popravka :
Mais il faut alors que le serveur DHCP soit fiable. Bah, en général ce sont des trucs qui fonctionnent...
Si c'est une machine que tu contrôles, je veux bien. Si c'est la freebox, bof.
Il existe aussi des cas où des machines du lan doivent communiquer avec un serveur (sur le lan ou pas) et si le dhcp est en rade (je ne sais plus si c'est toujours le cas mais à une époque j'ai vu pas mal de clients ayant des problèmes avec le serveur MS -oui, je sais... :) ) les applis ne marcheront pas alors qu'en IP fixée il n'y a pas de problème.
En pratique je n'ai rien contre le DHCP (surtout avec attribution des adresses IP en fonction de l'adresse MAC, sachant que les deux peuvent être bidonnées :) ) surtout quand il y a de nombreuses stations sur le reseaux, mais dans ce cas je mets les serveurs et machines critiques avec une adresse IP "en dur" et le reste en dhcp sur une autre plage.
Le problème du "en général ce sont des trucs qui fonctionnent" est que certains responsables oublient que dans certains environnement on ne peut pas se contenter de ça :)
