[MISC] Re: [FRnOG] [FRNOG][TECH] Network Access Control
Re, > On a eu beau chercher, et chercher encore, très peu d'équipements en place > (en dehors des PCs) étaient capable de faire du 802.1x dans notre contexte > Le peu qui était censé le faire (comme nos téléphones IPs) le faisait mal, > voir très mal. En 2013-2014, en mono-vendor (Switches/AP WiFi/Phones), on n'a eut aucun soucis... et même la majorité des imprimantes ont fonctionné en 802.1x. Pour certains vieux machins, il a fallu faire de l'auth MAC, comme toi, mais rarissime et jamais pour des VLANs importants. > Ceci est aussi vrai en 802.1x ultra sécurisé via certificats, car vous ne > pourrez pas empêcher la pose d'un man in the middle physique, à l'insu de > l'utilisateur réellement connecté à la prise. True. > Enfin pour le sujet du VPN, attention aux perfs. > Le VPN ça consomme du CPU sur le poste, et c'est difficile de faire passer > beaucoup (vraiment beaucoup) de trafic. > Je n'arrive pas à dépasser les 40Mb/s et à condition de plafonner à 100% > tous les coeurs de mon i7 Un bon client VPN va utiliser AES-NI et autres CLMUL, pour une conso CPU dans les 30% d'un seul core pour 800+ Mb/s de throughput (idem sur mobile, où il y a aussi les jeux d'instructions AES). Donc là, t'es vraiment tombé sur un mauvais client VPN où un algo bizarre à été choisi côté boitier VPN... Cordialement, -- Philippe Bourcier web : http://sysctl.org blog : https://www.linkedin.com/today/author/philippebourcier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [FRNOG][TECH] Network Access Control
Re, > Oui encore faut il que ce soit transparent le plus possible pour > l'utilisateur. > En 2008 je déployais des Juniper NetScreen SA Avec du Stormshield et des clés > RSA SecureID. C'était > cool, ça marchait bien... Pour un geek. En 2008 on faisait encore des VPNs IPSEC et c'était pas toujours génial (pour rester poli)... On a fait beaucoup de chemin depuis (VPN SSL). Pour les tokens hardware, j'ai toujours été contre les trucs proprios bien opaques... c'est bien triste que des DSIs fassent ce choix-là, mais bon, perso, j'ai beaucoup d'exemples de déploiements/usages VPNs "sans soucis". > Rien n'empêche d'ajouter l'un a l'autre, 802.1x peut être transparent pour le > end user. Oui, toujours du 802.1x pour le LAN/WiFi, mais ensuite on monte le VPN... comme ça l'expérience de connexion au réseau est toujours identique pour local ou remote et il n'y a plus de duplication des règles via VPN ou pas. Ca rajoute un composant sur le chemin, mais la redondance des boîtiers VPNs ca se gère bien et depuis longtemps... Bref, je n'y vois que des avantages. Cordialement, -- Philippe Bourcier web : http://sysctl.org blog : https://www.linkedin.com/today/author/philippebourcier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [FRNOG][TECH] Network Access Control
Bonsoir, On a déployé du NAC en multi-sites, multi-vlan, multi-équipements, et c'est... pas simple. La totale, avec réseau de parking, et bientôt un portail captif unifié filaire et wifi si tout va bien Une fois en place, c'est génial, tu peux dire aux utilisateurs de brancher n'importe quoi sur n'importe quelle prise. L'équipe peut enfin se consacrer à des sujets plus intéressants que affecter des vlans Comme dit plus haut, le 802.1x ça juste marche sur du Windows + AD + certificats via ADCS C'est complètement transparent, y compris lors de la masterisation des postes. A aucun moment l'utilisateur ne s'en rend compte, on gère même l'affectation de vlan selon des groupes utilisateurs AD Bon rien que ça, on ne va pas se le cacher, c'est un peu de boulot, mais une fois en place ca tourne tout seul, quasiment aucune charge de troubleshoot. En revanche, le gros du boulot c'est le reste, car pour qu'un NAC soit vraiment efficace, tout doit être NACé, du sol au plafond. Pour y arriver, ne comptez pas que sur le 802.1x. On a eu beau chercher, et chercher encore, très peu d'équipements en place (en dehors des PCs) étaient capable de faire du 802.1x dans notre contexte Le peu qui était censé le faire (comme nos téléphones IPs) le faisait mal, voir très mal. Et ca nous bloquait pour les équipements normalement auto-provisionnés en sortie de carton (téléphone, borne wifi, DECT, ..), car sans conf 802.1x initiale, pas d'accès au serveur de provisionning.. Bref, on a fait de l'authent MAC en parallèle du 802.1x, pas le choix. Bon, on va pas se le cacher, l'authen MAC c'est plus pour l'affectation automatique des VLANs que pour la sécurité, c'est trop facile à usurper. On a des milliers de prises à gérer, et on affecte quasiment plus aucun vlan à la main. Notre HelpDesk est parfaitement autonome pour déplacer des bureaux, des imprimantes et j'en passe. Au final, on a surtout gagné en réactivité et en flexibilité. Pour conclure, un NAC n'apporte pas grand chose en terme de sécurité Certes ça protège un peu, mais tant que des "potentiels méchants" auront accès physiquement aux équipements et aux prises, vous ne pourrez pas les protéger correctement. Ceci est aussi vrai en 802.1x ultra sécurisé via certificats, car vous ne pourrez pas empêcher la pose d'un man in the middle physique, à l'insu de l'utilisateur réellement connecté à la prise. Il ne vous libérera donc pas de tout filtrer et contrôler via des pare-feux dignes de ce nom. Tout ce qui est sensible devrait en plus être réencapsulé dans des tunnels, ou accéder depuis des postes virtuels distant à mon sens. Et surtout, passez les patchs partout, ca va de soi, et pas uniquement sur les PCs bien sûr. Par contre, l'affectation automatique de vlan sur des milliers de prises, c'est le pied ! Pour rien au monde on ne reviendrai la dessus Enfin pour le sujet du VPN, attention aux perfs. Le VPN ça consomme du CPU sur le poste, et c'est difficile de faire passer beaucoup (vraiment beaucoup) de trafic. Je n'arrive pas à dépasser les 40Mb/s et à condition de plafonner à 100% tous les coeurs de mon i7 Bonne soirée à tous Le mar. 1 sept. 2020 à 20:46, Philippe Bourcier a écrit : > Bonsoir, > > 802.1x sans client lourd ca fonctionne parfaitement et ca se déploie > rapidement... > C'était mon approche favorite jusqu'au Covid. > > > 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). > > Mais j'avoue que je trouve ca vraiment sexy comme approche de faire du > "tous en VPN", d'autant que les clients VPNs sont bien au point pour ce qui > est du suivi/validation des mises à jour AV/OS pré-connexion... Je trouve > que c'est une très bonne idée. > > > 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] [FRNOG][TECH] Network Access Control
Le 01-09-2020 20:46, Philippe Bourcier a écrit : Bonsoir, 802.1x sans client lourd ca fonctionne parfaitement et ca se déploie rapidement... C'était mon approche favorite jusqu'au Covid. 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). Mais j'avoue que je trouve ca vraiment sexy comme approche de faire du "tous en VPN", d'autant que les clients VPNs sont bien au point pour ce qui est du suivi/validation des mises à jour AV/OS pré-connexion... Je trouve que c'est une très bonne idée. Oui encore faut il que ce soit transparent le plus possible pour l'utilisateur. En 2008 je deployai des Juniper NetScreen SA Avec du Stormshield et des clés RSA SecureID. C'était cool, ça marchait bien... Pour un geek. Le problème c'est qu'il faut que ce soit un max transparent pour le end user pour éviter le problème d'interface chaise clavier. Avec le télétravail post covid, je pense que les difficultés des services de support end user doivent s'être complexifiées. Bref, encore une fois, je le vois pas sous cet angle. Pour moi, sécuriser un réseau physique = 802.1x. sécuriser un réseau logique / périmètre et des clients de plus en plus nomades (donc pas sur le réseau physique) = firewall / détection d'application / client vpn un peu plus lourd pour renforcer les mesures avant la connexion. Rien n'empêche d'ajouter l'un a l'autre, 802.1x peut être transparent pour le end user. Cordialement, -- Philippe Bourcier web : http://sysctl.org/ blog : https://www.linkedin.com/today/author/philippebourcier --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Fabien VINCENT _@beufanet_ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [FRNOG][TECH] Network Access Control
Bonsoir, 802.1x sans client lourd ca fonctionne parfaitement et ca se déploie rapidement... C'était mon approche favorite jusqu'au Covid. > 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). Mais j'avoue que je trouve ca vraiment sexy comme approche de faire du "tous en VPN", d'autant que les clients VPNs sont bien au point pour ce qui est du suivi/validation des mises à jour AV/OS pré-connexion... Je trouve que c'est une très bonne idée. Cordialement, -- Philippe Bourcier web : http://sysctl.org/ blog : https://www.linkedin.com/today/author/philippebourcier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [FRNOG][TECH] Network Access Control
Hum, ça dépend ce qu'on entend par NAC. 802.1x ça juste marche dans la plupart des cas et ça fait le job de contrôle d'accès L2. Maintenant, si tu veux partir sur plus complexe avec des produits avec clients lourds installés sur les postes qui vérifient l'état de l'antivirus, les MaJ appliquées et les logiciels installés, effectivement c'est souvent un peu lourd, et passer au firewall / VPN pour contrôler les flux IP c'est souvent suffisant. Tout ça c'est dépendant d'une politique de sécurité. Si ton job c'est de verrouiller l'accès au réseau, alors 802.1x fait le café si tes équipements sont assez homogènes et supportent le 802.1x. Si ton job c'est de verrouiller l'accès aux services (aka du cloud over IP), alors oui un bon firewall/IPS/Détection d'applications et VPN fait le job. Mais c'est clair que les produits de NAC et d'enforcement des postes de travail, c'est vite une usine à gaz, surtout en si tu as autre chose que du windose. Fabien Le 01-09-2020 17:34, A Gaillard a écrit : 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/ -- Fabien VINCENT _@beufanet_ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [FRNOG][TECH] Network Access Control
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/
[FRnOG] [Tech] [CfP] virtual EPF 2020 // 14-16 September 2020 // FRNOG
*Call for Presentations virtual European Peering Forum 2020* AMS-IX, DE-CIX, LINX, Netnod are happy to host the virtual European Peering Forum (EPF) 2020 from the 14th - 16th September 2020. The event will welcome peering managers and coordinators from networks connected to the host Internet exchanges. Besides some interesting topical agenda, the three-day event accommodates room for attendees to virtually meet on a one-to-one basis to discuss bilateral peering business opportunities. The programme committee will be looking for presentations and related to peering and technical topics of interconnection. Your presentation should address * Interconnection Automation * Regional Peering * Interconnection / Peering Internet Governance and Regulatory Topics * Economic and Product Trends * Peering / Interconnection strategies * Interesting findings about Peering / Interconnection * 400GE and beyond * Any other hot topic related to Interconnection / Peering Submissions === Presentations must be of a non-commercial nature. Product or marketing heavy talks are strongly discouraged. Submissions of presentations should be made to the programme committee . Please include: * Author's name and e-mail address * Presentation title * Abstract * Slides (if available) * Time requested (max. 15 minutes incl. Q) Deadlines = Please send in your presentation asap. We decide on a first come first serve basis. More information about the event and other activities around the virtual EPF 2020 may be found at * https://peering-forum.eu/ * https://www.facebook.com/groups/1586607564933665/ -- Keep calm, keep distance, keep connected! Arnold Nipper email: arn...@nipper.de mobile: +49 172 2650958 signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [FRNOG][TECH] Network Access Control
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/
[FRnOG] [FRNOG][TECH] Network Access Control
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/
Re: [FRnOG] [MISC] Réunion FRnOG 34.0 reportée - pas de réunion en 2020
Re, > on pourrait faire une réunion "online" comme l'ont faites toutes les > conferences de sécu cette année... Je n'y vois aucun intérêt. Si c'est pour du contenu tech, il y a YouTube, etc. On va d'ailleurs faire quelque chose sur le sujet dans les semaines/mois qui viennent... Le côté interactions et social d'un event en ligne est quand même très limité et c'est bien au moins la moitié de l'intérêt d'une réunion de NOG, du coup j'ai du mal à imaginer organiser une moitié d'event. Cordialement, -- Philippe Bourcier web : http://sysctl.org/ blog : https://www.linkedin.com/today/author/philippebourcier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Réunion FRnOG 34.0 reportée - pas de réunion en 2020
Le 31/08/2020 à 10:52, Philippe Bourcier a écrit : > Bonjour et bonne rentrée à tous, > > Les conditions pour organiser la réunion de façon satisfaisante pour tous ne > sont malheureusement pas réunies. > En conséquence, la réunion du 11 Septembre est reportée et il n'y aura pas de > réunion FRnOG 34 en 2020. > > On y verra plus clair en 2021, j'espère... > Merci en tout cas à nos sponsors de continuer à nous soutenir pour cette > réunion. on pourrait faire une réunion "online" comme l'ont faites toutes les conferences de sécu cette année... > Cordialement, Amicalement > Philippe Bourcier Raphaël Jacquot --- Liste de diffusion du FRnOG http://www.frnog.org/
