Re: [FRnOG] [TECH] Borne Wifi

2020-10-15 Par sujet A Gaillard
Hello,

Pour info sur un sujet connexe, ça fait plusieurs années que les instances
mondiales de gestion des fréquences parlent d'étendre les bandes ISM, dont
l'usage du Wi-Fi sur la bande du 6 GHz.
En début d'année 2020 la Wi-Fi Alliance a validé les usage du 6 GHz avec
une future norme nommée Wi-Fi 6E (pour Extended).
Et info récente qui date de la semaine dernière, l'équivalent ANFR chez les
rosbeef a validé l'usage de la moitié de la bande 6 GHz aux UK (second pays
après les US) et a dit qu'ils arrêtent désormais l'oligation d'utiliser le
DFS sur le 5,8 GHz.
https://www-scienceworldreport-com.cdn.ampproject.org/c/s/www.scienceworldreport.com/amp/articles/61726/20201008/ofcom-to-secure-spectrum-for-cutting-edge-wi-fi-6e.htm
Quand est-ce que ça arrivera en France ? aucune idée.

Par contre petit conseil : ne déployez pas trop rapidement des bornes en
802.11ax (Wi-Fi 6), car elles ne seront pas compatibles avec ces nouvelles
bandes de fréquences ouvertes prochainement ! (tant que les constructeurs
n'auront pas affiché leur compliance avec le Wi-Fi 6E)


Adrien.

Le jeu. 15 oct. 2020 à 12:01, OBConseil via frnog  a
écrit :

> On 15/10/2020 11:18, Julien Escario wrote:
> > Le 15/10/2020 à 11:06, Oliver varenne a écrit :
> >> Déjà, fait limiter au pays "France"
> >
> > Bah, ca dépend beaucoup de l'endroit où tu te trouves. Ici, il faut
> > sélectionner aussi la Suisse et l'Allemagne par exemple ;-)
> >
> > Et choisir aussi la bande C, le reste ne vous intéresse pas (en wifi
> > extérieur en tout cas, pas encore).
> >
> > C'est un peu de boulot, oui. Si un spécialiste de la carto sait
> > récupérer tout ça en opendata et générer un outil magique, ce serait
> > chouette mais je n'ai pas trouvé et c'est très loin de mes compétences.
> >
> > Julien
>
> A titre perso, je blacklist dans mes équipements toute la bande entre
> 5600 et 5700Mhz (en faisant attention aux débordements selon la largeur
> de canal choisie, évidemment).
>
> Quitte à "pousser" un peu sur les bandes en bas (4950Mhz) ou en haut
> (5900Mhz) - attention au fait que le gain des antennes chute
> drastiquement dans ce cas donc bourriner sur 6000Mhz n'a strictement
> aucun intérêt hormis pour ses actions EDF.
>
> Les radars météo sont particulièrement vulnérables car ils récupèrent
> des échos, il n'y a pas de transmission de données en tant que telle et
> ils ont une sensibilité gigantesque par rapport à nos équipements.
> En plus je crois que certains vieux modèles sont pas particulièrement
> sélectifs.
>
> Pour les équipements télécoms, par contre, à moins de faire l'imbécile
> et de shooter exprès avec une antenne directionnelle vers un équipement
> sur une bande réservée (ou alors que ton émetteur bave vraiment
> méchamment sur des harmoniques), il me semble qu'il y a peu de risques.
>
> Enfin, comme ça a déjà été dit, ça ne sert à rien de pousser la
> puissance des AP si les stations peuvent pas répondre, ça plante
> simplement les clients. En point-à-point, l'idéal est de choisir des
> antennes les plus directives possibles, même si c'est cher.
>
> Après il faut prendre ses responsabilités & ses risques et étiqueter
> tous ses appareils avec les coordonnés (y compris  téléphone) du
> responsable.
>
>
> Julien
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


[FRnOG] Re: [TECH] NAT et IP hors RFC-1918

2020-09-23 Par sujet A Gaillard
Exact pour vos 2 remarques :

   1. En effet on ne pourra jamais régler le problème d'overlap pour ces
   machines, mais j'aimerais bien trouver une solution pour que les machines
   du réseau adressées normalement ne voient pas cet overlap : Ce n'est pas
   l'objectif du DNS-NAT in fine ?
   2. Tu as raison Stéphane, je retire la solution de double NAT de la
   liste pour éviter de devoir longer les murs dans les prochains jours !


Adrien.

Le mer. 23 sept. 2020 à 17:20, Stephane Bortzmeyer  a
écrit :

> On Wed, Sep 23, 2020 at 04:59:35PM +0200,
>  A Gaillard  wrote
>  a message of 49 lines which said:
>
> >- Trouver une solution à base de double NAT
>
> Attention, la personne qui viendra maintenir celà dans N années va
> vous maudire, et inventer le voyage dans le temps pour revenir dans le
> passé vous agresser.
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


[FRnOG] [TECH] NAT et IP hors RFC-1918

2020-09-23 Par sujet A Gaillard
Bonjour à tous,

Au début de l'été je vous écrivais concernant une problématique d'IP hors
RFC1918 adressées sur le LAN (derrière un MPLS) d'un de mes clients, et
grâce à vous j'avais pu éclaircir le fonctionnement du mécanisme RTS en
place chez mon client sur certains équipements !

Je creuse le sujet et je cherche des solutions pour gérer plus simplement
le routage au sein du réseau de mon client :

   - Réadresser les machines en IP RFC1918 --> en effet sauf
   qu'organisationnellement ça ne va pas être possible à court terme :)
   - Continuer à utiliser le RTS --> en effet aussi, mais c'est assez
   pénible à maintenir, et il y a toujours le problème d'overlap entre
   l'adressage interne hors RFC1918 et quelques IP sur Internet
   - Trouver une solution à base de double NAT --> est-ce que vous auriez
   des idées à ce sujet ?
   - Trouver une solution à base de DNS-NAT --> est-ce que vous auriez des
   idées à ce sujet ?
   - Est-ce que vous avez déjà expérimenté d'autres solutions pour ce genre
   de problème ?

Concrètement pour le double NAT et le DNS-NAT, est-ce que vous voyez des
solutions particulières qui permettraient de gérer ça "simplement" ? Et à
défaut, est-ce que vous savez s'il existe des services managés spécifiques
pour ce genre de solution ?

Toute réponse, même tâtonnante, m'aiderait beaucoup pour démêler mon sac de
noeuds ;)

Merci !
Adrien.

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] Logs pour un Hotspot.

2020-09-14 Par sujet A Gaillard
Hello,

J'ai rédigé un whitepaper sur le sujet avec une juriste au sein de ma boite
:)
Il est téléchargeable sur cette page, environ à mi-scroll
https://almond.consulting/information-security/


Adrien.

Le lun. 14 sept. 2020 à 08:45, Philippe Marrot  a
écrit :

> Bonjour,
>
> Dans le cadre de la mise en place d'un Hotspot Wifi dans un établissement
> de santé, je
> m'interroge sur les "données de connexion" à conserver pendant 1 an.
>
> Quelles sont elles techniquement précisément dans ce cadre ?. (en dehors de
> l'identification de l'utilisateur)
>
> enfin, est-il obligatoire dans ce cadre de:
>
> - mettre en place un filtrage des connexions (P2P , classification des
> sites Web)
> - Un enregistrement en tant qu'opérateur Wifi ?.
>
> Merci pour vos infos et pointeurs.
> PM.
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [FRNOG][TECH] Network Access Control

2020-09-01 Par sujet A Gaillard
Hello,

Même retour que Guillaume, le NAC c'est beau sur le papier.
En vrai à installer ça coute 2 bras, c'est hyper compliqué à gérer, dès que
t'as de l'historique (type vieux téléphones, vieilles caisses, vieilles
caméras, etc.) tu fais des exceptions qui cassent une bonne partie de la
plus-value sécurité. Et à gérer pendant la vie de la solution, tu as besoin
d'une équipe dédiée, à la fois technique pour comprendre ce qu'il se passe,
et capable de répondre aux "clients" interne lorsque madame michu n'arrive
pas à se brancher sur la prise RJ45 du bureau de Michel qui, lui, avait une
exception pour faire fonctionner son fax.

Les quelques clients qu'on a accompagné sur le sujet avait de belles
ambitions, mais s'en sont souvent arrêté à la moitié de la phase 1
lorsqu'ils n'ont pas fait retour arrière.

Je conseillerais donc d'éviter de partir dans ce genre de projet pour
éviter de perdre des sous en société de conseil, en gestion de projet, en
équipements, en support, en recrutement d'équipe, et au passage permettre
d'économiser 2 ans de la vie de plusieurs personnes :)


Adrien.

Le mar. 1 sept. 2020 à 16:20, Guillaume Tournat via frnog 
a écrit :

> Bonjour,
>
> Cela me parait un meilleur investissement de considérer que le LAN n'est
> plus un réseau de confiance (approche Zero Trust)
>
> et que l'utilisateur doive être connecté en VPN en interne comme en
> externe (always on).
>
> De ce fait, les accès sont systématiquement authentifiés. Hormis l'accès
> vpn, tout autre flux => portail captif pour accès web.
>
>
> Le 01/09/2020 à 15:57, Jerome Lien a écrit :
> > Bonjour à tous,
> >
> > on se pose régulièrement la question d'ajouter un NAC dans notre
> > réseau pour mieux gérer les accès wifi/utilisateurs, les branchements de
> > tout et n'importe quoi sur les prises réseaux, les déplacements
> > d'équipements sans prévenir et voire de la conf de vlan automatique ...
> >
> > Actuellement on gère +/- 100 vlan pour la segmentation pour + de 5000
> IP's
> >
> > Je pense que certain d'entre vous on cela chez eux, des retours
> > d'expériences à partager ?
> >
> > merci à tous,
> > jérôme
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] Re: [TECH] IP publiques en RFC1918 et RTS

2020-06-11 Par sujet A Gaillard
Merci à tous pour vos réponses enrichissantes !

Je pense que Manuel ne doit pas être loin de la réponse, en allant me
renseigner un peu sur ce type de RTS il se pourrait que le mécanisme que
mon client cite corresponde à ça.

Merci encore ;)
Adrien.

Le mer. 10 juin 2020 à 21:33, Michel Py 
a écrit :

> >> Manuel Martinez a écrit :
> >> Après la re-numérotation de plans IP si c’était simple, ca se saurait,
>
> > Stephane Bortzmeyer a écrit :
> > Oui, je suis étonné de l'optimisme de Philippe. Mon experience est
> plutôt celle de Michel : pièjakon en vue.
>
> Le problème est toujours le même : tu as beau essayer de le dire à tout le
> monde, la moitié des personnes qui devraient faire quelque chose n'en ont
> rien à faire, et ne font pas le changement.
>
> > Hier, à la réunion OARC, on a parlé d'un serveur DNS racine qui avait
> changé d'adresse IP il
> > y a trois ans et dont un tiers (!) du trafic est toujours envoyé à
> l'ancienne adresse.
>
> Cà ne m'étonne pas du tout. Quand un fait une renumérotation, il faut
> laisser le sniffeur sur l'ancienne adresse pendant des lustres pour pouvoir
> comprendre qui continue à envoyer des requêtes, trouver comment les
> contacter, leur expliquer que oui c'est leur problème et qu'il faut qu'ils
> se remuent le popotin.
>
> Un des ennemis que l'on ne soupçonne pas : /etc/hosts
>
> Michel.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


[FRnOG] [TECH] IP publiques en RFC1918 et RTS

2020-06-09 Par sujet A Gaillard
Bonjour à tous,

Je sèche un peu sur un sujet évoqué à l'oral avec un client sur lequel je
n'arrive pas à trouver d'infos : j'aurais besoin des lumières des plus
barbus d'entre vous :)

Ce client m'explique qu'ils ont fait partie des premiers à acheter des
adresses IP publiques avant que toutes les normes d'usage soient bien
actées. Ils se retrouvent aujourd'hui avec des IP publiques en RFC 1918.
Ils m'indiquent ensuite qu'ils utilisent des mécanismes type "RTS" pour
s'en sortir et que ça fonctionne à peu près.

Les seuls mécanismes que je connais qui se nomment RTS viennent du monde
Wi-Fi/radio (RTS/CTS) et, à la limite, du monde BGP avec la gestion des VRF
(Route Targets), ce qui ne correspondent pas à la problématique. En
cherchant sur les Internets je ne trouve pas grand chose de plus.

Est-ce que ce genre de contexte vous parle ? Si oui, est-ce que vous
pourriez me pointer vers des liens, des docs et/ou des schémas qui
pourraient éclairer cet étage bien sombre ?

Merci beaucoup !
Bonne journée,
Adrien.

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] Projet de recherche sur l'étude des DDoS

2020-05-06 Par sujet A Gaillard
 Hello,

Pour le point précis de l'analyse rapide de PCAP épais, j'étais tombé
sur l'outil
*Brim *qui complète Wireshark. J'ai pas testé, mais l'interface à l'air
jolie, et les fonctions de recherche de trames et de deepdive sur les
paquets à l'air super simple et rapide par rapport à Wireshark.
le Git : https://github.com/brimsec/brim

le lien pour télécharger l'outil sur Windows :
https://www.brimsecurity.com/download/

une démo sur youtube : https://www.youtube.com/watch?v=InT-7WZ5Y2Y


Autrement pour ton type de recherche, je pense que ce serait intéressant de
contacter les éditeurs de solution anti-DDOS du marché pour leur expliquer
la démarche, type Akamai, Cloudflare, Radware, voire même des Cloud
Provider (Azure, AWS, GCP). Ce sont eux qui auront les données brutes les
plus intéressantes et les plus globales. Sinon il faut directement aller
toquer à la porte des services de RaaS pour louer vous même des botnets et
faire des attaques contre votre infra, ou interroger leurs admins :)


Adrien.


Le mer. 6 mai 2020 à 11:08, Philippe Bourcier  a écrit :

> Re,
>
> > * Comment tu traite des gros pcap. Des gens font de grosses captures ?
> j'ai quitté ce jeux là il y
> > a trop longtemps. A l'époque libpcap etait pas top niveau perf et sur
> des interfaces rapide (>1G)
> > ça défonçait n'importe quel CPU.
>
> Si tu veux juste différencier le résidentiel vs pro vs serveurs, je dirais
> que tu n'as surtout pas besoin d'une capture pcap, mais juste d'un log
> netflow et d'une base Maxmind Enterprise (ils donnent accès aux bases
> gratuitement pour les projets de recherche)...
>
> > * Comment tu trouve un device IoT dans le lot ? Imagine une chromecast
> chez toi, il aura l'IPv4
> > publique de ta box. Et si le smart bidulle à une puce 2/3/4/5G ça
> passera par le CG-NAT de
> > l'opérateur ça noie le poisson non ? On reconnait ça avec du
> fingerprinting ?
>
> Passive fingerprinting ? D'où le pcap ?
>
> Effectivement, on peut noter qu'il y a quelques challenges techniques pour
> pouvoir réaliser cette partie de l'étude de manière fiable...
>
>
> Cordialement,
> --
> Philippe Bourcier
> web : http://sysctl.org/
> blog : https://www.linkedin.com/today/author/philippebourcier
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] Meraki... première et dernière...

2019-11-19 Par sujet A Gaillard
Hello,

Attention à ne pas confondre les produits Extreme d'origine, et les
produits Aerohive récemment achetés par Extreme dont parle Jérôme :)
Idem, on a de l'Aerohive pour plusieurs centaines de bornes dans quelques
dizaines de sites à l'international : quelques galères de gestion de parc
de temps à autre (mais moins qu'avec d'autres solutions je trouve) mais pas
de soucis radio à constater. Le prix est assez cher pour le coup, mais le
produit vaut le coup et l'interface d'admin est plutôt top !

En ce moment on parle aussi beaucoup de Mist qui débarque doucement en
France et qui propose du neuf dans le domaine, que je n'ai pas encore testé.

Adrien.

Le mar. 19 nov. 2019 à 11:25, Xavier Beaudouin  a écrit :

> Hello Jérome,
>
> > personne n'a parlé d'aerohive ou maintenant extreme network. Cela fait 8
> > ans que l'on vit avec et pour nos besoins nous en sommes trés content
> (250
> > Ap's sur +/- 80 000m2). Si besoin je peux être plus explicite sur
> demande.
> >
> > https://www.extremenetworks.com/products/extremewireless/
>
> Well nous aussi on vis avec ce genre de choses, depuis un temps certain ou
> ça appelais Enterasys ...
>
> On a pas loin 450+ AP connectés sur 2 EWC en "cluster".
>
> Globalement ça marche assez bien. A part des bugs assez mystiques et une
> interface
> web datant de 10 ans en arrière un peu brain damaged.
> Quelques bugs aux upgrade (hint : faire un tech dump complet AVANT et
> APRES l'upgrade
> et après les corrections des bugs via l'interface pour envoyer des baffes
> au
> support), des fonctions magique qui devraient marcher, mais en fait non
> (l'upgrade
> de firmware via leur systeme de tunnel par exemple, dans ces cas de
> multiples SSID).
>
> Des choses qui ont évolués, l'abandon du mdp par defaut du constructeur en
> SSH 
>
> Des choses qui manque :
> - 802.1X en dual stack -> bah non... les vns n'ont pas l'option pour y
> coller un ipv6...(wtf)
> - une interface un peu moins conne
>
> Des choses bien :
> - le tunneling du traffic L2 vers le controleur, pratique en cas de
> multisites
>
> Par rapport a WLC cisco :
> - le prix... c'est moins cher ET on peux prendre des switch POE standard
> pour les antennes
>
> Ceci dit, on commence aussi a déployer de l'Ubnt d'abord pour le prix, et
> SURTOUT parce
> qu'on a pas à payer une license pour un controleur (license au nombre
> d'AP...), ce qui
> quand même est assez (trop?) par rapport au support à géométrie variable
> qu'on trouve
> (et qui n'est pas du même niveau que celui de Cisco).
>
> Voila...
> /Xavier
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] 6Ghz et 60Ghz en France

2019-06-07 Par sujet A Gaillard
Hello,

Pour avoir les infos d'attribution pour la France, c'est l'ANFR qui a en
charge de répartir les bandes de fréquence.
Tout est répertorié dans le lourd Tableau National de Répartition des
Bandes de Fréquences dont la dernière version date du 11 avril 2019
https://www.anfr.fr/fileadmin/mediatheque/documents/tnrbf/TNRBF_2019-04-11.pdf

Pour la bande des 6 GHz, il faut aller voir le feuillet 61 (p152), le
tableau détaillé est en 61a, mais c'est le 61b qu'il faut lire pour
comprendre "un peu mieux" le détail.
Pour la bande des 66 GHz, il faut aller voir le feuillet 86 (p202).

Pour ce qui est des limites de puissances suivant si on est en
intérieur/extérieur, elles sont fixées par décret :

   1. Pour le 2,4 GHz, ça avait été fait par l'ART (ex-ARCEP) en 2002 -->
   https://www.arcep.fr/uploads/tx_gsavis/02-1008.pdf ; il y a aussi l'ETSI
   EN-300 328
   2. Pour le 5 GHz, on site souvent la norme européenne ETSI EN-301 893
   qui est ultra complète dont la dernière version est parue en 2017 il me
   semble -->
   
https://www.etsi.org/deliver/etsi_en/301800_301899/301893/02.01.01_60/en_301893v020101p.pdf
   ; et la suite de la bande dans l'ETSI EN-302 502

Je n'ai pas cherché pour les bandes du 6 GHz et 66 GHz :)

Pour ce qui est des normes des autres pays européen, il semblent qu'ils
doivent se conformer aux normes ETSI, mais je ne sais pas si certains ont
légiférer localement pour les changer :)


Adrien.

Le jeu. 6 juin 2019 à 17:43, David Ponzone  a
écrit :

> 6Ghz: certainement pas ouvert pour le moment, c’est en discussion
> (
> https://blog.netxp.fr/wifi-evolution-de-la-regulation-des-frequences-6-ghz/
> )
>
> 60Ghz: à priori, la bande de 57 à 66 serait sans licence, raison pour
> laquelle il y a pas mal de produits dispos (Lightpointe par exemple).
> Mais évidemment, portée assez courte.
>
> > Le 6 juin 2019 à 17:17, Julien Escario  a
> écrit :
> >
> > Bonjour,
> > Fût une époque reculée, j'avais trouvé un petit doc qui donnait un
> > aperçu de la réglementation en 2.4 et 5Ghz sans licence pour quelques
> > pays d'Europe avec les PIRE correspondantes mais je ne parviens plus à
> > trouver ce genre de doc, y compris chez l'ANFR.
> >
> > Est-ce que quelqu'un aurait un pointeur vers un tel tableau, notamment
> > pour les bandes 6Ghz et 60Ghz ?
> > Pour la France déjà, ce serait bien.
> >
> > On commence à voir arriver des équipements abordables pour faire du
> > point à point dans ces fréquences et j'ai un gros doute sur la légalité.
> >
> > Merci,
> > Julien
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] Légalité et légitimité de la "De-Auth attack" (Air Marshal) de Meraki

2018-09-26 Par sujet A Gaillard
Hello,

1) Pour le domaine privé, je ne considère pas cette fonction utile, du
moins pas de manière automatique. En terme de réaction WIPS je vois
l'intérêt : je déclenche une réaction de De-Auth lorsque je détecte une AP
classée en Rogue sur mon réseau. A mon sens émettre des De-Auth en continu
sur tous les SSID environnants est plutôt destructif, aussi bien pour ma
propre bande passante (aussi bien du point de vue airtime que du
processeur) que pour l'environnement ^^
Pour ce qui est des menaces, un Rogue AP peut permettre tout un tas de
choses à partir de l'interception de la connexion d'un client : depuis la
possibilité de lui présenter une fake page de sa banque pour qu'il tape son
code jusqu'à prendre le contrôle complet de son poste. Si ce sont des
clients d'hôtel OSEF, mais si ce sont tes employés avec tes données
confidentielles et l'accès à ton réseau depuis leur poste, ça devient tout
de suite moins drôle.

2) Comme dis précédemment, un équipement peut être validé avec des
fonctionnalités qui peuvent ne pas être validées dans un pays. En France il
est interdit de réaliser du brouillage radio volontaire, en effet, mais on
parle bien de radio pur. On est sur du déni de service protocolaire et on
ne rentre pas dans le cadre de la loi. A mon sens il y a un vide juridique
sur ce point et la seule manière de l'attaquer serait de dire que la bande
de fréquence en question est libre et que dans ce cadre il est interdit
d'empêcher quelqu'un d’émettre sur cette bande quel qu’en soit le moyen.
Ainsi, une réponse ciblée OK, mais un mécanisme de De-Auth auto NON

3) En effet le PMF, ou 802.11w, est une solution mais réellement très peu
implémentée sur les devices clients. Et en effet comme dit plus haut, le
WPA2 apportait le support du PMF, le WPA3 le requiert : les constructeurs
de puces et cartes Wifi vont devoir se mettre en ordre de marche pour
devenir enfin compliant.


Adrien.

Le mer. 26 sept. 2018 à 17:14, Paul Rolland (ポール・ロラン) 
a écrit :

> Hello,
>
> On Wed, 26 Sep 2018 17:04:10 +0200
> Jérôme Nicolle  wrote:
>
> > * Quelle est la légalité (au moins en France) d'une telle fonction ? Est
> > ce qu'un tel équipement peut ne serait-ce qu'être certifié pour
> > commercialisation ?
>
> Meraki est commercialise en France... par des canaux tout a fait legaux,
> donc je suppose que la validation a ete faite... ou que la fonctionnalite
> n'a pas ete mise en avant ;)
>
> Paul
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH]Captive portal, WiFi et IPv6 : des solutions ?

2018-05-07 Par sujet A Gaillard
 Hello,

Pour la partie roaming dont parles David pour Meraki, c'est ce que font
aussi depuis quelques années Aerohive et Aruba (oups, HP) avec des tunnels
GRE dynamiques pour gérer le roaming L3 complètement transparents pour
l'admin. Pour avoir testé le fonctionnement, c'est fluide et on perd
difficilement plus d'1 ping.

A ce moment là, toute la question pour toi j'imagine, c'est de savoir
comment tu traites tes flux (c'est bien pour un service Hotspot j'imagine).
Pour moi tu as plusieurs solutions sans parler d'IPv4 ou IPv6 à ce stade :

   - Soit tu as une architecture contrôleur et le choix peut être de
   remonter l'ensemble de tes flux _*central-switching*_ pour les faire
   sortir sur Internet au travers d'un portail captif
  - Dans ce cas là pour décharger ton WAN, il faudrait appliquer
  directement ta restriction de bande passante au niveau radio par la
  solution Wifi, mais impossible de le faire par Login à ce moment là
   - Soit tu as une architecture contrôleur et le choix de faire sortir les
   flux sur Internet directement sur chaque site _*local_switching*_
  - Une des solutions pour le portail captif est de mettre un boitier
  par site --> très cher
  - Une autre idée pourrait être de prendre une solution de portail
  captif Cloud type Cloud4Wi  --> mis en place
  dans un contexte avec plusieurs milliers de sites aussi, par contre ne
  réalise pas de filtrage d'URL ni de log
  - Enfin, autre type de solution Cloud qui ne nécessite pas
  nécessairement d'avoir les accès Internet directement sur chaque site :
  type Cloudifi  qui utilise Zscaler pour
  remonter les flux via des tunnels pour les traiter/filtrer/loguer et
  présenter le portail captif avant de les balancer sur Internet
   - Soit tu as une architecture controler-less et ça revient aux deux
   choix précédents : soit tu simules du *central-switching* avec un
   équipement central, soit tu fais du *local-switching* (natif) avec tes
   propres boitiers portail captif ou les solutions Cloud

Du coup pour ta problématique IPv4/IPv6, à voir si les solutions Ucopia et
Netinary ne ferait pas ça directement.


Adrien.

Le 7 mai 2018 à 11:30, Jérôme Nicolle  a écrit :

> David,
>
> Le 07/05/2018 à 11:08, David Ponzone a écrit :
> > Un des modes de fonctionnement permettant le L3 Roaming pourrait
> > satisfaire une partie de ton besoin:
> >  Bridging/Layer_3_Roaming>
>
> OK, lu. Ça ne réponds pas au besoin et poserai un autre problème : le
> trafic est en "hairpin" sur le "mobility controller", qui dans mon cas
> devrait être à l'autre bout du WAN (pas d'équipement "lourd" sur les
> sites distants), ce qui gaspillerai beaucoup de bande passante :/
>
> --
> Jérôme Nicolle
> 06 19 31 27 14
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: Fwd: [FRnOG] [TECH] Faille WPA2

2017-10-20 Par sujet A Gaillard
Bonjour à tous,

Quelques points pour faire un état des lieux rapide.

L'infrastructure est vulnérable dans les cas suivants :

   - Si le 802.11r est activé (Fast BSS Roaming)
   - Si les 80211v et/ou 802.11z sont activés
   - Si la topologie du réseau WiFi comporte du Mesh
   - Si la topologie du réseau WiFi comporte des liens PtP
   - Si vous êtes dans un cas de faille, le fait de faire du TKIP (au lieu
   du CCMP) ajoute un risque d'injection de trames

Concernant la partie device, voici ce qu'il faut savoir :

   - La quasi totalité des équipements Windows et une bonne partie des
   équipements iOS ne sont pas vulnérables dans la mesure où les OS eux-mêmes
   interdisaient déjà les Retry sur le message 3 du handshake WPA/WPA2 (c'est
   à dire l'objectif de la faille)
   - Les terminaux Androïd sont quasiment tous vulnérables
   - Les devices deviennent vulnérables s'ils se mettent en mode ad-hoc
   - Les devices sont vulnérables s'ils émettent en multicast et/ou en
   broadcast
   - Le driver unix wpa_supplicant a été mis à jour récemment pour corriger
   la faille


Des deux côtés le mot d'ordre est donc de mettre à jour :)

Adrien.

Le 19 octobre 2017 à 18:16, Michel Py 
a écrit :

> >> Pierre Colombier a écrit :
> >> Si j'ai bien compris le papier, la faille est dans le client, pas dans
> l'AP ?
>
> C'est ce que j'avais compris aussi.
>
> > Louis a écrit :
> > non. Il y a 10 failles dont 9 côté client et une côté AP.
>
> Tu as un lien ? J'avais l'impression que la vulnérabilité n'était que si
> on utilise un lien d'AP à AP.
>
> Michel.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [BIZ] Audit de sécurité

2017-07-25 Par sujet A Gaillard
Plusieurs cabinets ont été cités, je rajouterais celui dans lequel je suis,
et en cours de certification PASSI actuellement : *NetXP*

Cordialement,
Adrien.

Le 25 juil. 2017 12:11, "Florent Cottey"  a
écrit :

Le 25 juillet 2017 à 10:14, Alexei Popof  a écrit :

> Avez-vous des adresses sur Paris de cabinets d'audit de confiance adaptés
> à une PME de 25 salariés. Nous gérons des flux financiers importants et
> c'est pour cela que la DG souhaite montrer au CA que tout a été fait au
> mieux pour se protéger.
>

Bonjour,

tous les prestataires qualifiés PASSI seront de confiance. C'est une
démarche encadrée par l'Etat.
https://www.ssi.gouv.fr/administration/qualifications/
prestataires-de-services-de-confiance-qualifies/prestataires-daudit-de-la-
securite-des-systemes-dinformation-passi-qualifies/
Cette liste n'est pas exhaustive car de bonnes sociétés ayant déjà leur
clientèle n'ont pas ressenti le besoin de s'inscrire dans cette démarche.
Je pense à Synactiv, Lexfo ou XMCO.

Après il faut voir le besoin. Est-ce du généraliste sur votre système
d'information ?
- gestion de votre Active Directory
- renforcement du réseau
- fichiers qui traînent sur les partages réseau
- mots de passe faibles
- systèmes non patchés

Est-ce du très spécifique sur les flux financiers ? Y a-t-il des
applications maison à regarder avec attention ?

Je pense que ce deuxième point doit arriver dans un second temps après
avoir sécurisé le système d'information car il suffit souvent d'avoir les
mots de passe des utilisateurs avec des failles assez simples pour ensuite
accéder aux applications avec des comptes légitimes.

En étape 0 je conseillerai de passer soi-même un scanner de vulnérabilité
type Nessus. Ca évitera de payer des experts pour trouver des
vulnérabilités triviales à identifier.

Florent

---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] MDM & Android

2016-05-23 Par sujet A Gaillard
Bonjour,

Pour les solutions les pus velues de MDM qu'on trouve en entreprise comme
MobileIron ou AirWatch, on peut en effet mettre en place un magasin d'apps
interne. Cependant comme l'a dit Valérie, je ne pense pas que ces solutions
soient sizées pour le besoin;

L'utilisation de la solution de Meraki semble plutôt un bon choix, et
concernant la mise en place d'un store, il faudra se tourner vers des
solutions dédiées non pas de MDM mais de MAM (Mobile Application
Management). Google Apps propose un service comme celui-ci, tout comme
d'autres en mode SaaS comme Appaloosa-Store il me semble. Je n'ai pas
connaissance d'outils dédié (cad pas à mode Cloud) pour faire du MAM en
dehors des deux premières solutions industrielles citées.

Cordialement,
Adrien.

Le 23 mai 2016 à 11:46, Valérie P  a écrit :

> Hello Gaël,
>
> Ayant bossé sur quelques problématiques de MDM voici quelques pistes :
> - Comme David vu le volume de téléphones à gérer je me tournerai vers la
> solution Meraki qui fait le job gratuitement (jusqu'à 100 terminaux
> Android, iPhone, Mac, PC, Chromebook...), et de manière efficace sans
> compliquer les choses comme le ferait un MobileIron qui pour le coup est
> parfait pour des besoins très très spécifiques et super poussés, mais pas
> spécialement adapté (ergonomie, facilité d'exploitation) pour ton type de
> besoins.
> - Concernant la gestion des versions Play Store et systèmes, d'expérience
> c'est en dehors des compétences des plateformes de MDM qui vont pouvoir
> donner de la visibilité sur les versions logicielles mais ne pourront pas
> imposer un upgrade.
> - Pour l'install avec Meraki sur Android, l'installation d'une app sera
> nécessaire (comme avec MobileIron d'ailleurs, et comme avec les autres
> outils de MDM sauf erreur de ma part)
> donc un compte Play Store sera nécessaire (là encore, comme avec les autres
> outils, c'est une limitation de l'OS).
>
> Bonne chance pour ton projet! :)
>
> Valerie
>
> 2016-05-23 0:42 GMT+02:00 Benjamin Perdrijau :
>
> > Bonjour,
> >
> > Dans mon entreprise, nous déployons beaucoup de projets de MDM pour des
> > sociétés dons les besoins sont similaires aux tiens.
> > Cependant, nous ne déployons pas d'opensource, la solution que nous
> > déployons le plus régulièrement actuellement est MobileIron.
> > Ce n'est pas OpenSource, pas gratuit mais cela fait plusieurs années
> qu'ils
> > sont sur le marché et que cette solution est utilisée par de nombreuses
> > entreprises ayant besoin de gérer une flotte de mobiles/tablettes multiOS
> > ou non.
> >
> > https://www.mobileiron.com/fr/solutions/enterprise-mobile-management-emm
> >
> > Cordialement,
> > Benjamin
> >
> > Le 21 mai 2016 à 09:09, Simon Morvan  a écrit :
> >
> > > Android for Work ?
> > > https://www.google.com/work/android/features/management.html
> > >
> > > On 20/05/2016 19:24, Gaël Demette wrote:
> > > > Bonsoir à tous,
> > > >
> > > > Nous commençons à avoir un petit parc de tablettes qui grandit (40 à
> > > date), ces tablettes doivent être prêtées à nos client finaux,
> > > préconfigurées, et idéalement gérées à distance pour le suivit des
> mises
> > à
> > > jour et cie.
> > > > En gros, pour simplifier mon explication, j’ai des tablettes Alcatel
> > > OneTouch, avec tout un tas de bordel installé dessus (Facebook,
> twitter,
> > et
> > > pléthore d’app dont personne n’a jamais entendu parler).
> > > >
> > > > Je veux :
> > > > * Un Android vanilla
> > > > * Firefox (notre webapp) & Teamviewer (si vous avez des retours sur
> de
> > > meilleurs softs n’hésitez pas, mais Teamviewer fait le job, c’est juste
> > en
> > > cas de problème de ne pas avoir à faire déplacer un commercial).
> > > > * Gérer les app en remote (notre webapp risque d’être déclinée en app
> > > native, la push directement serait bien :))
> > > > * Contrôler les versions (Play store & système).
> > > > * Dans un monde parfait, un système de gestion en script à la
> Ansible,
> > > Salt, Puppet, etc… !
> > > > * Je préfère de l’open source (en cas de problème, de bug, de fine
> > > tuning, c’est plus rapide pour nous de le fix directement).
> > > > * Dans l’idée, je me vois bien brancher une tablette qu’on reçoit sur
> > un
> > > Pi, hop ça la configure, et on peut l’apporter au client. Mais ça me
> > semble
> > > un peu Utopique…
> > > > * Ne pas configurer de compte play store
> > > >
> > > > Je n’ai aucun besoin de gérer de l’iOS (j’ai cru voir dans mes
> > > recherches que les outils faisant abstraction de la techno étaient bien
> > > foireux), cependant, si vous connaissez des solutions multi
> plateformes,
> > je
> > > suis à l’écoute.
> > > >
> > > > Ca fait un moment que je cherche, et je ne trouve rien qui approche
> mon
> > > besoin… Y’a bien les solutions de MDM comme wso2 mais ça semble
> vraiment
> > > d’être des usines à gaz…
> > > > Des retours sur ces solutions peut être ?
> > > >
> > > > Quoi qu’il en soit, même une couverture partielle de 

Re: [FRnOG] [MISC]Hotspot

2015-12-15 Par sujet A Gaillard
Bonjour Aubin,

Pour être précis, il faut ce déclarer en tant qu'OCE (Opérateur de
Communication Electronique) auprès de l'ARCEP.

D'un point de vu légal voici les obligations :
 - Présenter des CGU aux utilisateurs
 - Rétention des logs de connexion ("identifiant" de l'utilisateur et liste
des URL accédéesthéoriquement sur deux BDD différentes) pendant 12 mois
 - Positionnement de filtrage d'URL sur les sites interdits par la loi
(sinon c'est l'entité qui met à disposition le Hotspot qui se retrouve
responsable légal)
 - Déclaration à la CNIL de possession d'informations utilisateurs

Cordialement,
Adrien.

Le 15 décembre 2015 à 09:54, Alexis Lameire  a
écrit :

> me semble t'il, il faut avoir le statut d'hébergeur pour ce type d'usage,
> ce que vous avez fait.
>
> Les fréquences du wifi, ne sont pas réglementé, donc pas besoin de
> déclaration à l'arcep tant qu'on respecte les 100mW d'émission et que vous
> brouillez pas les voisins.
>
> D'un point de vue data, vous devez par contre conserver les logs de
> connexion pendant 1 ans il me semble.
>
> Je suis pas expert wifi, je laisse donc a qui de droit confirmer mes propos
>
> Alexis Lameire
>
> Le 15 décembre 2015 à 09:53, Aubin Chapuzet  a
> écrit
> :
>
> > Bonjour à tous
> >
> >
> >
> > Nous souhaitons mettre en place un Hotspot wifi dans un espace public.
> >
> >
> >
> > Quelqu’un sait-il ce que dit la loi au niveau fréquence. Faut-il faire
> une
> > déclaration  pour l’utilisation des fréquences ?
> >
> >
> >
> > Pour information nous sommes déjà déclaré à l’arcep en tant qu’opérateur.
> >
> >
> >
> > Merci d’avance.
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC]Hotspot

2015-12-15 Par sujet A Gaillard
@Samuel :
Parce que c'est la loi malheureusement, et c'est ce que les enquêteurs te
demanderont. En HTTPS il y a deux manière de le faire, soit du gros MitM
bien sale, soit du filtrage sur le CN du certificat qui passe dans
l'échange permettant de monter la session TLS. C'est de cette manière que
fonctionne les Netinary, Ucopia et consor de mémoire.

Et je disais juste "rester propre" par rapport à la loi (même si j'avoue
être contre ce genre de chose) : si tu ne peux pas prouver que c'est un de
tes clients qui s'est connecté à un site interdit par l'ARJEL, c'est toi
qui est déclaré comme responsable pénalement des actions de ton clients

Le 15 décembre 2015 à 10:43, Pierre-Henri <phac...@gmail.com> a écrit :

> Bonjour,
>
> Comment procède tu dans ce cas lors d'une réquisition judiciaire ?
> Si la gendarmerie te demande de leur fournir l'identification de la
> personne qui s'est connecté à telle heure, sur tel site ?
> Potentiellement, tu as des dizaines ou des centaines de personnes si tu ne
> garde pas un minimum de trace.
>
> Pierre-Henri
>
>
> Le 15 décembre 2015 à 10:32, Samuel Thibault <samuel.thiba...@ens-lyon.org
> >
> a écrit :
>
> > A Gaillard, on Tue 15 Dec 2015 10:00:46 +0100, wrote:
> > >  - Rétention des logs de connexion ("identifiant" de l'utilisateur et
> > liste
> > > des URL accédéesthéoriquement sur deux BDD différentes) pendant 12
> > mois
> >
> > Il n'y a pas de raison de conserver les URL accédées. Du point de vue du
> > fournisseur d'accès Internet, la notion de "connexion", c'est juste
> > l'association au hotspot et éventuellement authentification de
> > l'utilisateur. Les connexions TCP etc. ne le concernent pas.
> >
> > Samuel
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC]Hotspot

2015-12-15 Par sujet A Gaillard
Et pourtant si, pour un OCE, lors d'une enquête cyber, les entités sont
amenées à présenter les logs avec les URL accédées et le Timestamp associé
:/

De plus, c'est nécessaire de choper les URL pour faire le filtrage si on
veut rester propre.

J'ai oublié de préciser les règles de puissances d'émission qui varient
suivant si on est en intérieur ou en extérieur (ça va de 100 mW à 1 W) mais
le tableau est assez facile à retrouver sur le site de l'arcep
<http://www.arcep.fr/index.php?id=9272>. Attention cependant à certaines
bandes sur le 5 GHz qui nécessite de mettre en place des mécanismes
spécifiques (TPC et DFS)

Mais comme dit David, l'ARCEP n'aura jamais le temps de vérifier que tout
ça est en place, c'est seulement en cas d'enquête que tu peux te faire
épingler.

Adrien.

Le 15 décembre 2015 à 10:32, Samuel Thibault <samuel.thiba...@ens-lyon.org>
a écrit :

> A Gaillard, on Tue 15 Dec 2015 10:00:46 +0100, wrote:
> >  - Rétention des logs de connexion ("identifiant" de l'utilisateur et
> liste
> > des URL accédéesthéoriquement sur deux BDD différentes) pendant 12
> mois
>
> Il n'y a pas de raison de conserver les URL accédées. Du point de vue du
> fournisseur d'accès Internet, la notion de "connexion", c'est juste
> l'association au hotspot et éventuellement authentification de
> l'utilisateur. Les connexions TCP etc. ne le concernent pas.
>
> Samuel
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC]Hotspot

2015-12-15 Par sujet A Gaillard
Concrètement je suis bien d'accord avec David pour le coup : Loi écrite
avec les pieds par des gens qui ne savent pas comment ça fonctionne.

@Jérôme : pour la CNIL, il faut tout de même déclarer "le système
d'authentification et d'archivage des données utilisateurs"


Le 15 décembre 2015 à 10:56, David Ponzone  a
écrit :

> Qui c’est ?
> Et en clair, tu réponds quoi ?
> L’identité  de la personne ?
> Rien dans la loi (mais j’avoue que je l’ai lue en diagonale) ne te
> contraint à prendre les identités des utilisateurs.
> Si tu sors un email (bidon), un numéro de mobile (bidon), ou une adresse
> MAC (bidon), ça ira très bien aux enquêteurs.
>
> Cette loi a été (une fois de plus) écrite par des gens qui ne savent pas
> de quoi ils parlent, et qui ne comprennent pas que si un restaurant demande
> un passeport pour donner l’accès au WIFI, il perdra des clients.
>
> Je pense que dans le domaine du WIFI public, il faut faire ses meilleurs
> efforts pour collecter ce qu’on peut, sans rentrer dans la contrainte
> excessive pour le client ou les utilisateurs.
>
>
> > Le 15 déc. 2015 à 10:49, Samuel Thibault 
> a écrit :
> >
> > Pierre-Henri, on Tue 15 Dec 2015 10:43:06 +0100, wrote:
> >> Comment procède tu dans ce cas lors d'une réquisition judiciaire ?
> >> Si la gendarmerie te demande de leur fournir l'identification de la
> >> personne qui s'est connecté à telle heure, sur tel site ?
> >
> > S'ils savent que la connexion vient de chez toi, c'est qu'ils savent
> > l'IP source. En gardant un log des attributions d'IPs, tu sauras qui
> > c'est.
> >
> > Samuel
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] Lien Radio ou Laser sur 200m

2015-04-03 Par sujet A Gaillard
Bonjour,

Non, concernant le droit, il n'y a pas plus de limitation en Radio qu'en
Laser.

Pour les technologies Laser, tu as LightPointe ou fSONA qui fonctionnent
très bien, mais comme toutes les techno laser, ça reste cher, plus
compliqué à mettre en place (un écart d'alignement d'1° et tu plombes ton
débit) et sensible à la météo ainsi qu'au obstacles directs (un pigeon
devant le rayon et tu perds le lien). L'avantage c'est que ça reste du
matériel très robuste (beaucoup utilisé par l'armée dans les zones de
guerre) et qui crache du débit de manière très stable.

Concernant les solutions radio, je n'ai testé personnellement que les
solutions Radware et Alvarion, qui étaient plutôt solides aussi (Alvarion
n'existe plus). Mais pour une distance de 250 mètres pour 1 GBps, un simple
pont WiFi avec antennes directionnelles en 802.11ac devrait le faire sans
problème.

Adrien.

Le 3 avril 2015 11:02, boris.tas...@securmail.fr a écrit :

 Bonjour,

 C'est peut-être une bêtises, mais y a pas une histoire de droit/accord
 pour passer au dessus d'un espace public?


 Le 2015-04-03 10:55, TROUSSE Fabrice a écrit :

 Bonjour la liste,



 Ce n'est pas le but principal de cette liste mais à mon avis beaucoup
 d'entre vous ont du rencontrer le problème.



 J'ai besoin de secourir un lien fibre entre deux bâtiments (qui
 traverse une route) vers Toulouse.

 Les deux bâtiments sont en visu direct à moins de 250 mètres.
 Possibilité de poser les équipement sur les toits terrasses.

 Dans l'idéal 1 gbits.



 Je regarde les solutions radio ou laser de type lightpointe AireBridge
 SX/SXR ou AireBeam. Il y a aussi ubiquiti.

 Si vous aves des avis, conseils, je suis preneur.



 Merci par avance,



 Fabrice



 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/



 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] connectivité temporaire pour site isolé

2014-07-04 Par sujet A Gaillard
Salut,

Concernant ce type de produit, la plupart des constructeurs appellent ça
des Branch Router, utilisés principalement dans de petites agences qui
n'ont pas forcément de lien WAN.

On peut en trouver de très bons chez les constructeurs WiFi nextgen comme
Aerohive ou Aruba, avec l'avantage qu'ils sont très simples à manager :
*Aerohive :* http://www.aerohive.com/products/routers
*Aruba (categorie RAP) :*
http://www.arubanetworks.com/products/access-points/

Ce type d'équipement à l'avantage de pouvoir faire nativement du WiFi sans
avoir à ajouter une bornes à côté.
D'autre part, pour la solution Aerohive, le BR permet aussi d'avoir
plusieurs ports RJ45 de la même manière qu'un petit switch (pour brancher
d'autres switch ou d'autres AP par exemple)

Ces équipements permettent aussi de réaliser les fonctions de base : DHCP,
cahce DNS, proxy web (jamais testé sur ces modèles), filtre et contrôle de
bande passante. Par contre, je ne pense pas qu'il est possible avec ça de
faire un switching transparent entre 4G et satellite, du moins je n'ai
jamais eu affaire à ça.

J'imagine qu'il existe d'autre type de branch router chez les autres
constructeurs, mais couplé au WiFi, les deux types d'équipements cités sont
de bonnes solutions (et peuvent être réutilisés plus tard dans des
contextes différents)

Adrien.


Le 4 juillet 2014 17:34, Joel Marchand joel.march...@huma-num.fr a écrit :


 Bonsoir,

 Merci à tous pour vos éléments de réponse, fort instructifs pour nous !

 Le Fri, Jul 04, 2014 at 03:15:15PM +0200, David Ponzone disait :
  Va en falloir des 1Mbps pour arriver à une bande passante décente pour
 50 personnes.
  Nous avons validé 4 ADSL agrégés au niveau 2 (en MLPPP), et on peut
 faire plus, mais l’efficacité n’est pas parfaite.
  50 personnes travaillant sérieusement  dessus, je sais pas ce que ça
 donne.
  Reste la possibilité d’agrégation au niveau 3 (load-balancing), mais ça
 n’est pas le même résultat.
  Il faut voir ce dont Joel prévoit comme flux: web simple, des photos, de
 la vidéo ?

 Pardon pour l'oubli de la déf. de nos besoins : pas de video, pas de photo,
 pas de voix, uniquement du Web avec du texte et qqs icones pour faire joli.

  Pour les liaisons temporaires, il faut pas oublier la majoration de 20%
 :)
 
  Pour le SDSL, ATM ou pas, il faut oublier, vu les specs de la ligne fax
 de la Villa:
 
  Calibre et longueur de la ligne: 04 01760 | 06 03340
  C’est pas en centre ville hein, donc probablement pas prioritaire dans
 les plans de déploiement fibre Grand Public.

 Dixit le site du centre où nous allons, la fibre va arriver, mais
 après notre semaine de formation. Nous ne voulons donc pas investir,
 mais simplement trouver quelque chose qui nous arrange pour notre semaine.

  Pour la 4G, si la zone est couverte, et qu’il y a pas trop de clients
 dans le coin, ça peut marcher correctement, mais c’est extrêmement
 imprévisible.

 Nous ferons un retour sur cette liste, car de toutes facons, c'est
 l'une des solutions déjà retenue. Nous n'arrivons pas par contre
 à obtenir un contact chez Orange, pour savoir si une telle offre
 de modem-routeur 4G existe, ou s'il faut se débrouiller tout seul
 avec une clef 4G connectée à un petit routeur qui ferait aussi borne WiFi,
 comme ceux reperés chez TP-Link.

 Enfin j'en profite pour savoir s'il existe des mémos pour newbies,
 afin de construire un petit réseau local efficace derrière un
 tel point d'accès 4G et/ou satellite.

 Je pense en vrac à
 - serveur DHCP si le machin loué ne le fait pas
 - serveur-cache DNS
 - proxy-cache Web
 - filtres pour éviter de consommer les forfaits de data
 sur des choses automatiques comme
 - les MAJ d'OS, anti-virus, applications
 - les synchros vers Dropbox etc
 bref pour n'utiliser la bande passante que
 pour la formation au sens strict
 - savoir partager un lien 4G et un lien satellite,
 ou switcher de manière transparente entre les deux

 Je vois confusément comment on peut faire cela avec un PC Linux
 avec 2 interfaces réseau (1 vers le machin, 1 vers le LAN où
 seraient connectées les bornes WiFi), mais s'il existe des kits
 ou des recommandations, je serais preneur.

 Bien cordialement,

 Joel Marchand

 --
 Très Grande Infrastructure de Recherche Huma-Num - CNRS UMS 3598
 3ème étage - bureau 372 - CS n°71345
 190-198 avenue de France - 75648 PARIS CEDEX 13
 Tél : 01 49 54 83 09  - http://www.huma-num.fr/personne/joel-marchand


 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] Solutions de service de sécurité réseau dans le Cloud

2013-09-20 Par sujet A Gaillard
: frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] On Behalf
  Of Guillaume Tournat
  Sent: Thursday, September 19, 2013 11:49 AM
  To: frnog@frnog.org
  Subject: Re: [FRnOG] [TECH] Solutions de service de sécurité réseau dans
  le Cloud
 
  Le 19/09/2013 11:18, A Gaillard a écrit :
   Bonjour la liste,
  
   J'élabore actuellement un document état de l'art à propos des
   solutions de service de sécurité réseau dans le Cloud. Je n'en suis
   pas au début de mes recherches, mais j'aimerais avoir l'avis, le point
   de vue et les connaissances d'autres personnes. A l'issu de cet état
   de l'art, l'objectif pour moi est de tester de manière complète une
   poignée des solutions que j'aurais choisi en fonction de leur intérêt.
  
   La question que je vous pose dans un premier temps est : Quels sont
   les solutions dont vous avez déjà entendu parler ou même que vous avez
   déjà manipulé en terme de service de sécurité réseau hébergé dans le
  Cloud ?
  
   Pour faire un tri, j'ai classifié rapidement les services de sécurité
   réseau comme suit, et j'ai ajouté les solutions qui me sont venues à
   l'esprit ou que j'ai trouvé au cours de mes recherches :
  
   - Proxy : Zscaler, Blue Coat, Nov'IT, Symantec Web Security Cloud,
   McAfee Cloud Security Plateform
   - Antivirus : SourceFire (Immunet), Panda Security
   - Antispam : Cisco Ironport Cloud Email Security, Secuserve
   - Firewall : CloudFlare, XRoads Network, Cisco ASA 1000V Cloud
   Firewall
   - IPS/IDS : Virtela, Cloud Leverage (Cloud IPS/Firewall)
   - AntiDDOS : OVH mitigation, Clear-DDOS
   - PKI : Keynectis (opentrust), GlobalSign (MSSL et ePKI)
   - GTM : Akamai GTM, F5
 
 
  De tete, je vois déjà :
 - Proxy : Websense Hosted Web Security
 - Antispam : Websense Hosted Email Security, Trend Micro Hosted Email
  Security
 - Antivirus : les 3 précédents
 - Firewall : pfsense ?
 
  gu!llaume
 
 
  ---
  Liste de diffusion du FRnOG
  http://www.frnog.org/
 
 
  ---
  Liste de diffusion du FRnOG
  http://www.frnog.org/
 

 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


[FRnOG] [TECH] Solutions de service de sécurité réseau dans le Cloud

2013-09-19 Par sujet A Gaillard
Bonjour la liste,

J'élabore actuellement un document état de l'art à propos des solutions de
service de sécurité réseau dans le Cloud. Je n'en suis pas au début de mes
recherches, mais j'aimerais avoir l'avis, le point de vue et les
connaissances d'autres personnes. A l'issu de cet état de l'art, l'objectif
pour moi est de tester de manière complète une poignée des solutions que
j'aurais choisi en fonction de leur intérêt.

La question que je vous pose dans un premier temps est : Quels sont les
solutions dont vous avez déjà entendu parler ou même que vous avez déjà
manipulé en terme de service de sécurité réseau hébergé dans le Cloud ?

Pour faire un tri, j'ai classifié rapidement les services de sécurité
réseau comme suit, et j'ai ajouté les solutions qui me sont venues à
l'esprit ou que j'ai trouvé au cours de mes recherches :

- Proxy : Zscaler, Blue Coat, Nov'IT, Symantec Web Security Cloud, McAfee
Cloud Security Plateform
- Antivirus : SourceFire (Immunet), Panda Security
- Antispam : Cisco Ironport Cloud Email Security, Secuserve
- Firewall : CloudFlare, XRoads Network, Cisco ASA 1000V Cloud Firewall
- IPS/IDS : Virtela, Cloud Leverage (Cloud IPS/Firewall)
- AntiDDOS : OVH mitigation, Clear-DDOS
- PKI : Keynectis (opentrust), GlobalSign (MSSL et ePKI)
- GTM : Akamai GTM, F5

J'ai bien conscience que cette liste est loin d'être complète ni même
juste, puisqu'évidemment les solutions proposées ne font bien souvent pas
QUE firewall ou antivirus ou antispam, au contraire (c'est d'ailleurs pour
ça que c'est difficile de les trier).

Dans un deuxième temps, j'aimerais bien vous demander vos expériences sur
certaines des solutions, sur comment elles fonctionnent vraiment et quels
sont les avantages et inconvénients de celles-ci (d'un point de vu aussi
bien technique que financier, SLA, architecture, etc.), mais pour
l'instant, et pour ne pas que ça fasse brouillon, je vais m'en tenir à ma
première question concernant le listing !

Dans tout les cas merci à vous tous !

---
Liste de diffusion du FRnOG
http://www.frnog.org/