Ne pas autoriser les ordinateurs du domaine à communiquer entre eux

9

Notre domaine comprend environ 60 ordinateurs. J'ai été chargé de m'assurer que les postes de travail Windows 10 ne peuvent pas communiquer entre eux. Mon responsable m'a demandé de créer des itinéraires statiques afin que les ordinateurs puissent uniquement communiquer avec les imprimantes réseau, le serveur de fichiers, DC et accéder à Internet.

Étant donné que tous ces ordinateurs sont sur le même réseau, je ne pense pas que les routes statiques vont empêcher ces ordinateurs de se voir. Quelle est la meilleure façon d'autoriser les ordinateurs du domaine à utiliser les ressources réseau sans communiquer directement entre eux?

taiwie
la source
12
Les itinéraires ne sont pas le moyen de le faire. Les règles de pare-feu le sont.
EEAA
Avez-vous des commutateurs et un pare-feu gérables?
sdkks
2
Si les postes de travail sont connectés sans fil, l'isolement du client dans les points d'accès avancés empêchera tout client wifi 2 de communiquer entre eux.
sdkks
@EEAA Je pense que l'objectif pourrait être d'empêcher totalement les attaques layer2 des machines compromises vers d'autres.
sdkks
1
@sdkks Ces attaques sont facilement atténuées via des règles strictes de pare-feu entrant.
EEAA

Réponses:

16

Si vous avez un commutateur qui le prend en charge, les «ports protégés» pour les connexions câblées ou «l'isolement du client» pour les points d'accès sur le Wi-Fi peuvent vous aider à éliminer le trafic entre les hôtes du même réseau de couche 2.

Par exemple, c'est du manuel de commutateur de Cisco :

Les ports protégés ont les caractéristiques suivantes: Un port protégé ne transfère aucun trafic (unicast, multicast ou broadcast) vers un autre port qui est également un port protégé. Le trafic de données ne peut pas être transféré entre les ports protégés de la couche 2; seul le trafic de contrôle, tel que les paquets PIM, est transmis car ces paquets sont traités par le CPU et transmis dans le logiciel. Tout le trafic de données passant entre les ports protégés doit être transmis via un périphérique de couche 3.

Donc, si vous n'avez pas l'intention de transférer des données entre eux, vous n'avez pas besoin d'agir une fois qu'ils sont «protégés».

Le comportement de transfert entre un port protégé et un port non protégé se déroule comme d'habitude.

Vos clients peuvent être protégés, le serveur DHCP, la passerelle, etc. peuvent être sur des ports non protégés.

Mise à jour 27-07-2017
Comme l'a souligné @sirex, si vous avez plusieurs commutateurs qui ne sont pas empilés, ce qui signifie qu'ils ne sont pratiquement PAS un seul commutateur, les ports protégés n'arrêteront pas le trafic entre ceux-ci .

Remarque: Certains commutateurs (comme spécifié dans la matrice de prise en charge du commutateur Catalyst VLAN privé) ne prennent actuellement en charge que la fonction PVLAN Edge. Le terme «ports protégés» fait également référence à cette fonctionnalité. Les ports PVLAN Edge ont une restriction qui empêche la communication avec d'autres ports protégés sur le même commutateur. Cependant, les ports protégés sur des commutateurs séparés peuvent communiquer entre eux.

Si tel est le cas, vous auriez besoin de ports VLAN privés isolés :

Dans certaines situations, vous devez empêcher la connectivité de couche 2 (L2) entre les périphériques d'extrémité sur un commutateur sans placer les périphériques dans différents sous-réseaux IP. Cette configuration empêche le gaspillage des adresses IP. Les VLAN privés (PVLAN) permettent l'isolement au niveau de la couche 2 des appareils dans le même sous-réseau IP. Vous pouvez restreindre certains ports du commutateur pour atteindre uniquement des ports spécifiques auxquels une passerelle par défaut, un serveur de sauvegarde ou Cisco LocalDirector sont connectés.

Si PVLAN s'étend sur plusieurs commutateurs, les jonctions VLAN entre les commutateurs doivent être des ports VLAN standard .

Vous pouvez étendre les PVLAN sur plusieurs commutateurs à l'aide de jonctions. Les ports de jonction acheminent le trafic à partir de VLAN réguliers et également à partir de VLAN principaux, isolés et communautaires. Cisco recommande l'utilisation de ports de jonction standard si les deux commutateurs qui subissent la jonction prennent en charge les PVLAN.

Si vous êtes un utilisateur Cisco, vous pouvez utiliser cette matrice pour voir si vos commutateurs prennent en charge les options dont vous avez besoin.

sdkks
la source
1
les réseaux locaux virtuels isolés fonctionneraient également et seraient compatibles avec plusieurs commutateurs
Sirex
@Sirex en raison de la jonction et du transfert VLAN?
sdkks
1
Oui. si je comprends bien, c'est la différence entre les deux solutions.
Sirex
@Sirex J'ai ajouté votre suggestion d'amélioration
sdkks
en tant que note, il existe également une fonctionnalité appelée MTU VLAN (Multi-Tenant Unit VLAN) sur la série intelligente TP-Link qui rend chaque port sur un VLAN séparé avec liaison montante.
fsacer
11

Vous pouvez le faire si vous avez fait quelque chose d'aussi horrible que de créer 1 sous-réseau par client. Ce serait un cauchemar de gestion.

Le pare-feu Windows, avec les stratégies appropriées, vous y aidera. Vous pouvez faire quelque chose comme l'isolement de domaine, mais encore plus restrictif. Vous pouvez appliquer des règles par unité d'organisation, avec les serveurs dans une unité d'organisation et les postes de travail dans une autre. Vous voudrez également vous assurer que les imprimantes (et les serveurs) ne sont pas sur le même sous-réseau que les postes de travail pour simplifier les choses.

https://technet.microsoft.com/en-us/library/cc730709(v=ws.10).aspx

En ce qui concerne les imprimantes réseau - vous pourriez rendre cela encore plus facile si vous n'autorisez pas l'impression directe, mais hébergez les imprimantes en tant que files d'attente partagées à partir d'un serveur d'impression. C'est une bonne idée depuis longtemps pour plusieurs raisons.

Puis-je demander quel est l'objectif commercial réel de cette opération? Est-ce pour aider à prévenir les épidémies de logiciels malveillants? Garder la vue d'ensemble / la ligne d'arrivée à l'esprit permet de définir les exigences, de sorte que cela devrait toujours faire partie de votre question.

mfinni
la source
Je suppose que c'est pour se protéger contre les attaques comme l'exploit de wannacry.
sdkks
3
Bien sûr, c'était aussi ma supposition, mais j'aime rappeler aux interrogateurs cette facette de la question.
mfinni
Oui, l'objectif ici est de limiter la propagation de toute épidémie de logiciels malveillants.
taiwie
Tant qu'il n'y a pas de périphérique BYOD qui n'est pas membre du domaine, cette solution ne coûtera rien à OP. (En supposant que toutes les machines sont Windows)
sdkks
-3

Si vous pouvez lier chaque poste de travail à un utilisateur spécifique, vous pouvez autoriser uniquement cet utilisateur à accéder à ce poste de travail.

Il s'agit d'un paramètre de stratégie de domaine: ouvrez une session localement à droite.

Cela n'empêche pas l'utilisateur de se rendre au poste de travail le plus proche et de saisir son mot de passe pour accéder à sa machine désignée, mais il est facilement détectable.

De plus, cela n'affecte que les services liés à Windows, donc un serveur Web sur les machines serait toujours accessible.

Paolo
la source
1
Cela n'empêche pas non plus les logiciels malveillants qui utilisent des exploits non corrigés de se déplacer entre les postes de travail.
mfinni
@mfinni Sure. Malheureusement, op n'a pas précisé si l'exigence est réelle (gestionnaire technique averti) ou un gestionnaire demandant des mots à la mode. L'objectif est également important: pour une protection réelle contre les menaces que vous mentionnez, une solution de faible niveau osi est requise, comme indiqué dans d'autres réponses. Et si les hôtes communiquent avec les serveurs, il n'y a toujours pas de protection contre la propagation de logiciels malveillants ...
Paolo