AP sous linux

Le Fri, 17 Dec 2004 16:45:24 +0100, Eric Masson a écrit :

Et que pour prism54, l'intégration avec les outils du sieur Malinen
(wpa_supplicant, hostapd) c'est pas tout à fait ça non plus, même si ça
s'améliore.

Yop.
Pour le moment, j'ai une grooooosse préférence pour MadWiFi, même s'il
manque un poil de stabilité à mon goût.


--
[11:39] <Arold>: 8h
[11:39] <obionedtc>: 18h putain
[11:39] <Arold>: euh oui 18h
-+- : in Guide du Petit Joueur: t'as quelle heure, toi ? -+-

Cedric Blancher wrote:

Le Fri, 17 Dec 2004 16:45:24 +0100, Eric Masson a écrit :

Et que pour prism54, l'intégration avec les outils du sieur Malinen
(wpa_supplicant, hostapd) c'est pas tout à fait ça non plus, même si ça
s'améliore.

Yop.
Pour le moment, j'ai une grooooosse préférence pour MadWiFi, même s'il
manque un poil de stabilité à mon goût.

J'ai souhaité, en son temps (mi-2003 et bien entendu je n'étais pas le
seul), un rapprochement entre les API de madwifi et de hostap de manière à
simplifier les développements au-dessus.
J'ai un peu quitter la scène depuis cette époque mais apparemment cela n'a
toujours pas eu lieu. C'est toujours pénible d'avoir 2 célébrités.
Le support d'Atheros est forcément différent (et bien plus intéressant car
ouvrant la voie à plein d'autres idées de couches MAC) puisque le firmware
est dans le pilote ce qui n'est pas du tout le cas des chipsets Prism (qui
nous broutent le minou avec le primaire et le secondaire).

Jouni avait écrit, début 2003, qu'il voulait bien s'attaquer au problème de
l'USB à condition qu'on lui fournisse un échantillon. Apparemment là aussi,
ça n'est jamais arrivé.

Mais je crois que, finalement, le pire, c'est de ne pas avoir de
caractéristiques communes dans tous ses chipsets : chacun prêche pour sa
chapelle pour toujours les mêmes raisons mercantilissimes : l'utilisateur
final on s'en fiche, seul son porte-monnaie est intéressant.
Le Prism 2 ou 3 ne sera pas éternel, loin de là. Ca doit même commencer à
être difficile à trouver non ? A moins de commander en gros à Taïwan bien
entendu.

db

--
email : usenet blas net

Thomas Clavier wrote:

Kevin Denis wrote:

Question: Vous configureriez votre carte en ad-hoc ou en AP? Pourquoi?

Chez nous, tout est en adhoc avec protocole de routage dynamique
(www.lillesansfil.org) et ça marche drôlement bien !
Et alors, la ToIP, ça en est où (tout en se déplaçant bien entendu) ? Je

peux pas suivre tous les projets.

Si l'aspect securite deborde du cadre wifi, peut etre une redirection
sur fcs?

non, pas la peine, perso, je sécurise les applies et pas le réseau en
lui même. même le wpa c'est pas top.

Et il a bien raison le clavier : pourquoi réinventer la roue ? Qui plus est

pour prendre une roue voilée (WPA) ?

db
--
email : usenet blas net

Kevin Denis wrote:

In article <41c2eb25$0$21921$626a14ce@news.free.fr>, Dominique Blas wrote:

Allez, juste une info pour être sympa, si c'est une carte 11g, le
chipset semble être un Intersil Prism GT/Duette/Indigo, partant de là,
on trouve tout ce qui est nécéssaire pour répondre aux questions posées

Ca montre une fois de plus que certains posteurs se foutent de la gueule
du monde.

plait il?
Ok, je suis un peu bourrin et râleur mais il faut avouer que le bruit dans

le ng est une valeur à la hausse bientôt côtée en bourse (ou en brousse) !

C'est pourtant simple :
chez
http://groups.google.com
taper
AP linux group:fr.comp.reseaux.sans-fils
ce qui donne l'URL suivant :

http://groups.google.fr/groups?as_q=AP%20linux&as_ugroup=fr.comp.reseaux.sans-fils&lr=&hl=fr

Et là, ô miracle, des tas d'articles (qu'il faut éplucher bien évidemment),
d'Eric, de Cédric, de Thomas, de Jacques et de db (ben oui à l'époque je
m'appelais db, je suis timide par nature, je me suis émancipé ensuite).

Merveilleux Google, merci de nous apporter ta lumière ... :-)

db
--
email : usenet blas net

Le Fri, 17 Dec 2004 22:56:12 +0100, Dominique Blas a écrit :

Et il a bien raison le clavier : pourquoi réinventer la roue ? Qui plus est
pour prendre une roue voilée (WPA) ?

Qu'est-ce que tu as de spécial contre WPA ?


--
BOFH excuse #189:

SCSI's too wide.

"Cedric" == Cedric Blancher <blancher@cartel-securite.fr> writes:

Cedric> Yop. Pour le moment, j'ai une grooooosse préférence pour
Cedric> MadWiFi, même s'il manque un poil de stabilité à mon goût.

Un peu le même souci avec ath(4) et la couche 802.11 de FreeBSD
-current, je suis obligé d'ejecter la carte de temps en temps pour la
réinitialiser :/

M'enfin comme d'habitude Sam Leffler devrait résoudre ça en peu de
temps...

Éric

--
Ce que je comprends pas, c'est pourquoi leurs votes compte plus ?
Et surtout, ca leur rapporte QUOI ????
Putain faut vraiment être CON, grave.
-+- A in GNU - La Cabale, c'est plus FORT que toi ! -+-

Cedric Blancher wrote:

Le Fri, 17 Dec 2004 22:56:12 +0100, Dominique Blas a écrit :

Et il a bien raison le clavier : pourquoi réinventer la roue ? Qui plus
est pour prendre une roue voilée (WPA) ?

Qu'est-ce que tu as de spécial contre WPA ?

Je n'ai pas étudié WPA (comme je l'avais fait pour le WEP) et, à mon avis je
ne le ferai pas tout simplement parce que cela ne m'intéresse plus.
Je lirai probablement un jour un article dans un quelconque canard polonais
qui m'expliquera comment ça fonctionne et ce sera tout.
Par roue voilée j'entendais ceci :
www.netstumbler.com/2003/11/08/new_wpa_
security_breach_discussed_during_ratification_process/

mais surtout une roue usée !

Je m'en explique.

1. Il aura fallu 5 ans (depuis la sortie du standard 802.11) pour aboutir
à un semblant de protection au niveau MAC, j'ai nommé TKIP. Dieu que
ce fût
laborieux (WEP/WPA/WPA2 [802.11i]) ! Et avant WPA2 ou TKIP on
faisait quoi donc ?
On attendait patiemment que
des éminences grises nous pondent l'algorithme du feu de la mort ?
Certainement que non ! La sécurisation d'un réseau n'attend pas une
hypothétique nouvelle version. Surtout lorsqu'on dispose déjà des
outils adéquats depuis plusieurs années (qui ont par-dessus le
marché fait leurs
preuves) sur les réseaux filaires. Et c'est quoi la différence
entre un réseau filaire et un réseau sans-fil ? Une bête histoire de
changement de media, c'est tout.
Du reste, ceux qui souhaiteaient continuer à protéger le niveau MAC
et qui avaient accès aux firmwares (côté AP et côté
client) se sont empressés de réaliser du multi-WEP (clé WEP différente
pour chaque client [Cisco, HostAP]) voire de l'allocation dynamique
via 802.1x.

2. En effet pourquoi s'acharner à monter le niveau de sécurité des liaisons
alors qu'il existe ce qu'il faut autour (IPSEC notamment) ?
C'est du gaspillage d'énergie !
Et d'ailleurs, je pense que c'est ainsi qu'a travaillé l'IEEE
en considérant qu'il n'était pas du ressort du standard de prévoir
la sécurisation forte du lien mais bien le rôle d'une couche
plus élevée.
De plus, à l'époque, AES n'existait pas et je pense que peu nombreux
étaient
les algorithmes de chiffrement tombés dans le domaine public
(DES ?).

3. réponse : pour faire de l'argent et obliger au renouvellement des
produits ?
Car une fois que l'on est passé au 802.11g, ben c'est
presque
fini. Il y aura bien un 802.11n (100 Mb/s par canal) et puis p'têt
un 802.11k/l/m/q/r/s (200 Mb/s par canal) mais bon si c'est sur 3
mètres, bof.
Fallait donc trouver une autre raison chez les lessiviers du
sans-fil.

4. le clou enfin : lorsqu'on sait comment il est facile de planter grave une
zone Wifi pourquoi s'énerver à sécuriser le niveau 2 et faire
porter le marketing sur ce point alors que pour 80% des gens (qu'il
s'agisse de professionnels mais surtout du grand public) le plus
important
c'est la disponibilité et pas la confidentialité ?
Réponse en 3.

Comme tu dois le savoir, en sécurité (comme ailleurs mais notamment dans ce
domaine) on n'est jamais mieux servi que par soi-même. Or, en 2002 tout
existait déjà pour sécuriser de manière forte les liaisons sans-fil.
Les clients IPSEC étaient relativement nombreux et notamment sur la
plate-forme mobile la plus répandue : Windows (NT2000 et XP).
Ok, il fallait investir un peu mais je parle du monde professionnel là pas
du grand public.
ET même pour le grand public il était assez aisé, en considérant que le
nomade disposait d'un windows 2000 SP2 ou d'un XP, de monter un service
proposant la configuration de son client IPSEC, le chargement d'un
certificat fabriqué pour lui (en fonction d'info laissé par lui-même sur un
une page web) et l'établissement d'une connexion sécurisée (en 3DES hélas)
entre son poste et la tête de pont du fournisseur. Je sais je l'ai fait.

5. Lorsque je me suis intéressé au Wi-Fi (2002), j'ai pris soin de
considérer l'AP comme un simple transducteur filaire - hertzien et non
comme un système
plus complexe chaque jour embarquant des technos qui n'ont rien à y faire.
C'est une bête pb d'architecture et d'économie sur le long terme.
De cette manière ce qui a été mis en place en 2002 fonctionne toujours
aujourd'hui et, pour passer en 802.11g, il suffit de changer les interfaces
(*) qui sont sur bus PCI ou sur bus PCMCIA.

Evidemment le marché grand public n'a pas, et on ne le comprend que trop
bien, suivi cette démarche. La tentation était trop grande de bourrer le
bousin pour montrer toujours plus de fonctionnalités vis-à-vis de la
concurrence.
Ce qui est dommage c'est que le marché pro a également suivi cette tendance
poussé par le mouvement d'ensemble.
Avant de repartir très récemment dans l'autre sens à savoir le moins
d'intelligence
possible dans ces transducteurs et le plus possible au centre et/ou en
première couronne.

Du coup, au lieu de trouver des AP à $10 en quantité (ce que ça vaut en fait
en sortie de fondeur) on reste toujours aux alentours de $40 à $50.
Ceci m'a obligé, à l'époque, à passer à des AP sous Linux et donc,
forcément, à exploser le budget (entre $10 et $300 ça fait une différence)
mais j'ai pu conserver ma philosophie et réaliser finalement des économies
sur le long terme.

SonicWall a suivi ce même principe en terme de sécurisation des liaisons
avec son WiFISec.

Et Aruba a suivi mes conseils (je rigole) en terme d'architecture et dispose
aujourd'hui
d'une offre de ce type où l'AP est un vulgaire machin (interrogeable et
administrable tout de même et qui vaut $500 pièce mais c'est Aruba) et où
toute l'intelligence est centralisée
et/ou déportée au niveau des commutateurs.
Ceci permet de gérer les déplacements, les sauts de cellules, les
recouvrements, le plan de fréquence et la sécurité bien plus facilement.


Donc, pour conclure, Thomas a, bien entendu, fait les bons choix
architecturaux, surtout dans son cas : il serait en effet difficile
de demander à ses mobiles furtifs (qu'il ne connaît donc pas forcément) de
bien vouloir prendre la peine de patcher leur interface pour se protéger des
souci d'implantion du WEP dans sa première jeunesse, puis, 1 an après de
passer en WPA puis, 9 mois ensuite encore, en WPA2 !

Cette organisation réclame davantage de boulot en amont (prévoir l'accueil
des nouveaux,
leur proposer de charger un client de sécurité, voire gérer des certificats
et des listes de révocations, etc) mais, au final, en termes économiques et
en << calmitude > de l'admin (**) on y gagne.
Même raisonnement en ce qui concerne une entreprise : l'amortissement du
matériel info c'est 3 ans minimum pas 1 an comme les constructeurs
voudraient nous l'imposer.

db

(*) Il << suffit >> à condition que le pilote existe bien entendu ce qui
limite toujours le choix mais le principe reste sauf.

(**) Qui peut donc penser à accroître son réseau et y développer de nouveaux
services et non passer son temps à changer les AP.

--
email : usenet blas net

Le Sun, 19 Dec 2004 23:28:20 +0100, Dominique Blas a écrit :

Je n'ai pas étudié WPA (comme je l'avais fait pour le WEP)

Ben ça commence bien pour l'appui de ce qui suit. Je n'ai pas étudié,
mais je vais quand même chier dessus, parce que...

Je lirai probablement un jour un article dans un quelconque canard polonais
qui m'expliquera comment ça fonctionne et ce sera tout.

<pub>
MISC12
</pub>

Par roue voilée j'entendais ceci :
www.netstumbler.com/2003/11/08/new_wpa_security_breach_discussed_during_ratification_process/

Ah ouais, le mec qui a dit que si la passphrase utilisée en WPA-PSK
était faible, alors on pouvait l'attaquer par dictionnaire ?

"Moskowitz said in his paper that hackers can successfully launch offline
dictionary attacks against short pre-shared keys (PSKs), which are
passphrases used for WPA. He stressed that such attacks can't succeed
when longer passphrases are used. He also noted that enterprises that
use RADIUS back-ends for security are not at risk."

On attaquait déjà les clés WEP par dictionnaire avec les différents
algorithmes de génération de clé à partir de passphrase connus (genre
nwepgen par exemple). On attaque aussi les PSK IPSEC par dictionnaire, etc...


Enfin bon, ce que je retire de ta prose, c'est un beau mélange des
genres, qui oublie clairement que sur de l'ethernet (filaire ou non),
on ne fait pas que de l'IP, et qu'on ne peut donc pas utiliser IPSEC
partout. Et justement, l'IEEE affirme clairement ce soucis. Alors les gens
qui auraient voulu faire autre chose, ils auraient fait comment ?

Qu'ensuite, mettre de l'IPSEC en place, ce n'est clairement pas anodin, en
particulier au niveau de équipement supportant la terminaison des liens,
qui sera l'AP sur réseaux de Mme etM. Michu. L'AP qui gère l'IPSEC à
10$, je demande à voir. Ah ouais, mais si on fait comme Aruba... Ça
coûte combien un commutateur Aruba ? On peut aussi faire un réseau
maillé complet, certes, mais bon niveau souplesse : je vois bien la mère
Michu monter un PDC pour éviter les broadcast NetBIOS sur son partage
d'imprimante...

Qu'enfin si IPSEC te convient, c'est parfait, mais ce n'est pas le cas de
tout le monde (moi par exemple). Ma petite passerelle, elle tient pas la
charge, mon AP/routeur à 45¤ pas plus, par contre tous les deux
arrivent tout à fait à soutenir du WPA avec authentification par RADIUS
pour faire de l'EAP-TLS.


--
BOFH excuse #381:

Robotic tape changer mistook operator's tie for a backup tape.