Question Comment sécuriser un réseau sans fil d'entreprise?


Nous mettons en place un nouveau réseau WiFi dans mon travail et j'essaie de réfléchir à une conception de la sécurité pour le réseau.

Cas d'utilisation 1: invités. Nous aurons une configuration de portail captif, les clients accepteront une politique d'utilisation acceptable et seront limités à Internet, sans accès au réseau local. Assez simple, nous allons laisser le pare-feu bloquer les ports dangereux et ne pas nous inquiéter car ils ne peuvent pas toucher notre réseau principal.

Cas d'utilisation 2: les employés utilisant BYOD et les ordinateurs portables de l'entreprise pouvant passer des mois hors site avant d'être amenés au bureau. Mélange de Windows et OSX. Ils s'authentifieront auprès de WPA2-Enterprise auprès de notre AD / RADIUS. Existe-t-il un bon moyen de donner à ces personnes un accès LAN sécurisé aux serveurs internes?

Je pensais que le simple fait de donner à ces personnes un accès illimité au réseau local posait problème. S'ils sont liés à un domaine, ils recevront éventuellement des mises à jour de sécurité de WSUS, mais pas nécessairement avant leur connexion. Anti-Virus n'est pas non plus garanti. Avec le réseau câblé que nous avons maintenant en place, ceci est mineur, mais je peux voir le BYOD se développer avec l'ajout d'un réseau wifi, en particulier pour notre vaste groupe de stagiaires d'été.

J'ai examiné Microsoft Network Access Protection pour appliquer les paramètres de sécurité et mettre en quarantaine les périphériques non conformes, mais je ne sais pas comment cela fonctionnera sous OS X (le seul agent que j'ai pu trouver, celui de UNET, contient des liens rompus sur le site Web. et le prix n'est pas clair). Cela semble aussi être assez complexe.

Est-ce exagéré? Dans le monde réel, comment les autres gèrent-ils ce scénario? Existe-t-il une solution plus simple comme celle de la solution de contrôle d'accès réseau?


5
2018-05-02 14:51


origine


J'ai une réponse à cela, mais il faudra attendre que je rentre à la maison ce soir. - Tom O'Connor
Bonjour @ Tom O'Connor, je serais toujours heureux de connaître votre opinion à ce sujet. - Quinten
Ahh J'ai oublié. J'y penserai ce soir. Je pense que la réponse acceptée est quasiment parfaite, mais je verrai s’il ya quelque chose qui manque. - Tom O'Connor


Réponses:


J'ai un client du district scolaire qui a une configuration similaire à celle dont vous parlez.

  • L'accès public est exécuté sur un VLAN séparé avec un serveur DHCP et DNS dédié et aucun accès au réseau de l'entreprise, à l'exception du pare-feu périphérique (plaçant effectivement le wifi public "à l'extérieur" du pare-feu - donc accès VPN et accès à la DMZ). les serveurs hébergés fonctionnent à partir du wifi public). La "loi relative à la protection de l'Internet sur les enfants" exige que nous filtrions fortement cette connexion afin que le public obtienne la politique la plus restrictive. (Si je pouvais l'exécuter sur un réseau local physique dédié et avec une connexion Internet distincte, je le ferais. Money dit le contraire.)

  • Les appareils appartenant aux étudiants s'authentifient auprès de WPA-RADIUS et ont accès à Internet. DHCP et DNS sont fournis par des serveurs de réseau local. Les règles de pare-feu basées sur les AP (nous utilisons des points d'accès Ruckus ZoneFlex, dotés d'un pare-feu iptables basé sur Linux dans chaque AP) empêchent l'accès au réseau local à l'exception de services spécifiques (HTTP vers le "système de gestion de l'apprentissage" et quelques autres serveurs Web). . Il existe une stratégie de refus par défaut pour l'accès aux sous-réseaux du réseau local.

Je pense qu'il existe une forte distinction entre les périphériques appartenant aux employés et ceux appartenant à un district, du point de vue de la politique de gestion. Je l'ai donc reflété dans la configuration opérationnelle.

  • Les appareils appartenant aux employés sont exactement les mêmes que ceux des étudiants, à la différence qu’il existe une politique de filtrage Internet différente et que les employés obtiennent un accès RDP aux sous-réseaux du réseau local où résident les ordinateurs de bureau. Il existe toujours une stratégie de refus par défaut pour l'accès aux sous-réseaux du réseau local. Le nombre de services offerts aux appareils appartenant à des employés par des serveurs basés sur un réseau local est très limité et, franchement, je souhaite que cela reste ainsi. Je ferai de mon mieux pour que nous conservions une politique de refus par défaut avec des exceptions entre les sous-réseaux "BYOD" et les sous-réseaux LAN. J'ai eu quelques désaccords avec des gens à ce sujet, mais je suis d'avis que les dispositifs «BYOD» ne peuvent jamais être aussi fiables que les dispositifs appartenant au District.

  • Les périphériques appartenant à un district, y compris les ordinateurs portables, obtiennent leur propre SSID avec authentification WPA-RADIUS pour les membres du groupe "Ordinateurs du domaine" uniquement. Il existe une politique largement ouverte d'accès au réseau local. Aucun utilisateur ne dispose de droits d'administrateur sur ses ordinateurs et je suis assez heureux de me faire croire que ces appareils sont généralement fiables. Si j'étais un peu plus paranoïaque, je déploierais Bitlocker à l'aide des TPM sur tous les ordinateurs portables afin d'empêcher la modification hors ligne du système d'exploitation par les utilisateurs. Ce dernier bit avec le chiffrement intégral du disque serait tout ce dont j'avais besoin pour que je sois raisonnablement certain que les périphériques appartenant au district sont au moins quelque peu fiables. Nous n'avons que des clients Windows mais, dans un environnement Mac, je pense que des fonctionnalités similaires appropriées sont disponibles pour garantir l'intégrité de la base de calcul sécurisée dès le démarrage.

Nous n'avons pas de machines qui restent hors site pendant des mois. Si je le faisais, j'hébergerais un serveur WSUS connecté à Internet et laisserais les clients y rechercher les mises à jour, même lorsqu'elles étaient hors site. En fonction de votre logiciel anti-virus, vous pourrez également le faire fonctionner de cette manière.

Ce n’est pas que je pense que NAC / NAP est "exagéré" - je pense que c’est un idée fondamentalement imparfaite. Certaines personnes avancent que les ceintures et les bretelles sont une raison d'utiliser le NAC / NAP, mais j'ai du mal à faire confiance à un client non fiable pour évaluer sa propre "santé". Je suis tout à fait pour effectuer des analyses de vulnérabilité contre les machines d'un hôte de confiance, mais demander à un hôte non fiable de faire une déclaration de confiance sur lui-même me semble très imparfait.


7
2018-05-02 15:24



C'est intéressant. Je n'avais pas pensé à configurer RADIUS pour autoriser l'authentification uniquement pour les périphériques joints à un domaine, je ne savais pas que c'était possible. Nous pourrions peut-être nous contenter d'un réseau invité et d'un réseau pour les ordinateurs appartenant à un domaine. - Quinten
J'aime utiliser RADIUS pour limiter les périphériques / utilisateurs à un SSID donné. Nos points d'accès Ruckus nous permettent d'utiliser un attribut RADIUS pour nous permettre de gérer cela à l'aide d'un système IAS simple et clair sur Windows Server. C'est bien. - Evan Anderson


Pourquoi le BYOD devrait-il être différent pour les utilisateurs à l'intérieur de vos locaux et à l'extérieur? Si c’était moi, j’aurais configuré le WIFI comme son propre réseau avec un accès Internet et j’utilisais un VPN pour accéder au contenu restreint.


0
2018-05-02 16:13



La plus grande raison est la complexité. Les utilisateurs se connecteraient deux fois. Je ne suis pas sûr de la sécurité que nous gagnerions au-dessus d’un VLAN et de placer les périphériques BYOD dans une zone de pare-feu restreinte. Les deux sont des tunnels cryptés d'un réseau non sécurisé au nôtre, et pour verrouiller l'accès, nous devions mettre en place des règles de pare-feu pour les points d'accès VPN ou WiFi. - Quinten