Segmentação VLAN no Campus - Por SO?

Question

Pensamos em reorganizar nossa rede e a configuração de VLAN. Aqui está a situação.

Já temos nossos servidores, telefones VoIP e impressoras em suas próprias VLANs, mas nosso problema está nos dispositivos dos usuários finais. Há muitos para colocar na mesma VLAN sem ser martelado com transmissões! Nossa estratégia de segmentação atual os divide em VLANs como este:

• iPads do aluno
• iPads da equipe
• Macbooks para estudantes
• MacBooks da equipe de funcionários
• Dispositivos de jogos
• Pessoal (outro)
• Estudante (outro)

** Observe que nossa rede tem muito mais iPads e MacBooks do que a maioria. *

Como a principal razão pela qual estamos dividindo-os é colocá-los em grupos menores, isso tem funcionado para nós (na maioria das vezes). No entanto, isso exigiu que nossa equipe mantivesse listas de controle de acesso (endereços MAC) de todos os dispositivos pertencentes a esses grupos. Ele também tem o efeito colateral infeliz de agrupar ilogicamente o tráfego de broadcast. Por exemplo, usando essa configuração, os alunos em extremos opostos do campus usando iPads compartilharão transmissões, mas dois dispositivos pertencentes ao mesmo usuário (na mesma sala) provavelmente estarão em VLANs completamente separadas.

Eu sinto que deve haver uma maneira melhor de fazer isso.

Eu fiz muita pesquisa e estou tendo problemas para encontrar casos em que esse tipo de segmentação seja recomendado. O feedback sobre a pergunta SO mais relevante parece apontar para a segmentação de VLAN por prédio / local físico. Eu sinto que isso faz sentido porque, logicamente, pelo menos entre os usuários finais diversos, as transmissões normalmente são destinadas a dispositivos próximos.

• Existem outros campi / redes de grande escala por aí segmentando VLANs com base no SO do sistema final?
• Esta é uma configuração típica?
• A segmentação de VLAN baseada na localização física (ou em alguns outros critérios) seria mais eficaz?

EDITAR: Foi-me dito que em breve seremos capazes de determinar dinamicamente o sistema operacional do dispositivo sem manter listas de acesso, embora não tenha certeza do quanto isso afeta as respostas às perguntas. / p>     

Answer 1

Acho que segmentar sub-redes de usuários por SO é mais trabalho do que vale a pena e, honestamente, em todas as minhas interações com o pessoal de TI da HiEd, nunca ouvi ninguém falar sobre segmentação por sistema operacional. Que benefício você teria ao fazer isso? Além disso, o que você faz quando o sistema operacional de uma determinada máquina muda ou talvez uma situação mais comum seria o que fazer com um computador que o dual-boots diz OSX e Windows?

Temos cerca de seis "zonas" de segurança diferentes no campus:

1. Ethernet do escritório da faculdade / equipe geral (não privilegiada) cai
2. Ethernet de escritório de equipe privilegiada cai (principalmente a equipe de ITS)
3. Wifi convidado (só tem acesso à internet)
4. ResNet (redes de dormitórios)
5. Wi-Fi seguro (WPA2 / 802.1x, os usuários são colocados em uma VLAN específica, dependendo da função)
6. Salas de servidores

Cada uma das opções acima é dividida em sub-redes menores, geralmente por meio da construção e, em seguida, pelo qual o wiring closet se conecta. Para wireless, temos várias sub-redes às quais os usuários sem privilégios são atribuídos aleatoriamente. Para as salas de servidores, fazemos o agrupamento por SO (principalmente para a separação de segurança entre o Windows e o Linux), bem como subdividimos ainda mais dentro dos grupos do sistema operacional para servidores ITS versus servidores de propriedade do departamento. Mantemos ACLs de sub-rede para cada sub-rede com uma política de negação padrão, permitindo apenas o tráfego que permitimos explicitamente. Além dos firewalls de sub-rede, implementamos firewalls de host em todos os nossos servidores, seja Linux ou Windows. Há também várias VLANs para fins especiais funcionando para coisas como gerenciamento de servidores, gerenciamento de rede, iSCSI, equipamentos HVAC, painéis de acesso a portas, câmeras de segurança, etc.

Seu objetivo de manter pequenos domínios de broadcast é um bom objetivo. Honestamente, no entanto, não importa se duas pessoas sentadas próximas umas das outras estão no mesmo domínio de transmissão L2.

    

Answer 2

Parece MUITO trabalho para o departamento de TI ter que organizar e acompanhar os endereços e dispositivos MAC aos quais estão associados.

O maior efeito colateral que eu pensei foi que "dois dispositivos pertencentes ao mesmo usuário (na mesma sala) provavelmente estarão em VLANs completamente separadas". Você terá muitas pessoas ligando para o suporte de TI perguntando por que não conseguem ver os dispositivos uns dos outros no iTunes. :)

Eu ainda acho que a melhor solução é a segmentação por construção, depois por dispositivos oficiais do campus e, por fim, por dispositivos de alunos. Dessa forma, você pode ter certeza de que todos os dispositivos podem conversar entre si, que precisam conversar entre si, ao mesmo tempo em que alivia os alunos contra invasão de dispositivos oficiais do campus.

O que você acha?

    

Answer 3

Concordo com o que ErikA disse: dividir as VLANs em grupos funcionais:

• SERVER1, SERVER2, SERVER3, etc. (digamos, todos sob 10.2.0.0/16: Windows em 10.2.0.0/17, Unix em 10.2.128 / 16)
• DMZ1, DMZ2, etc. (todos abaixo de 10.3.0.0/16)
• WIRELESS1, WIRELESS2, (todos sob 10.4 / 16)
• GUEST1, GUEST2, (10.5 / 16)
• UNDERGRAD1, UNDERGRAD2, (10.6 / 16)
• GRADS1, GRADS2, (10.7)
• FACULDADE, (10.8)
• IMPRESSORAS (10.9)
• NETWORKING (10.10.x.y)

Às vezes, grupos de pesquisa específicos também podem ter suas próprias VLANs. Da mesma forma, você pode ter VLANs 'privadas' que não são roteáveis para o resto da rede para coisas como armazenamento (NFS, iSCSI); eles frequentemente tinham Jumbo Frames habilitados também, enquanto em qualquer outro lugar o MTU padrão era de 1500.

Se quiser dar alguma flexibilidade aos usuários da rede, você pode usar algo chamado "VLANs dinâmicas": é onde, quando uma máquina é conectada, o switch pega seu endereço MAC e consulta um servidor RADIUS, informando qual VLAN para fazer o porto. Verifique os atributos RADIUS de "Tipo de Túnel", "Tipo de Meio de Túnel" e "ID de Grupo Privado de Túnel". Da mesma forma para WiFi, quando um usuário faz o login via WPA2, e o AP fala com o servidor RADIUS, além da resposta permitir / negar o nome de usuário e senha, o servidor RADIUS pode responder com a VLAN que o AP deve colocar. usuário em.

MACs e usuários de host não registrados podem ser negados a qualquer acesso (uma porta bloqueada) ou colocados em uma VLAN padrão (guest), dependendo de sua política de segurança. Os switches HP (e outros?) Também são capazes de fazer coisas de dois níveis: por padrão, o acesso no nível MAC é dado, mas se o usuário executar um programa 802.1xe se autenticar (em vez de apenas o host "autenticar") -com alguém na verdade no teclado), o switch pode então a porta para uma VLAN ligada ao indivíduo.

Além disso, amarrar as VLANs funcionais com intervalos de sub-rede ajuda a tornar as regras de firewall mais fáceis em muitos casos, bem como a depurar de onde pacotes estranhos estão vindo (os hosts do Windows são estatisticamente mais propensos a serem atacados / comprometidos, colocando esses servidores em qualquer rede fácil de segmentar pode valer a pena considerar).

Ao provisionar usuários / dispositivos para acesso a Wi-Fi (MacBooks, iPads, iPods), você giraria as sub-redes / VLANs nas quais elas seriam colocadas: studentA seria colocado em WIRELESS1 / 10.4.1.0, studentB em WIRELESS2 / 10.4.2.0, studentC novamente em WIRELESS1 / 10.4.1.0, etc. Adicione mais sub-redes / VLANS conforme necessário para "balancear a carga" da carga do usuário. Similarmente para o facultyA, facultyB, facultyC. Se você notar um desequilíbrio na distribuição por causa da graduação / desistências / rotatividade de equipe, você sempre poderá reequilibrar-se com um script simples que atualize o banco de dados (SQL, LDAP, o que for).

Você pode certamente fazer isso construindo, mas dentro de cada prédio você terá também separação funcional: BLDA_SERVER_HR, BLDA_SERVER_FINANCE, BLDA_WIFI_STAFF, BLDA_WIFI_GUEST, BLDA_PRINTERS, BLDB_WIFI_GUEST, BLDB_PRINTERS, etc.