Protegendo uma rede de clientes não gerenciados

[helldanger1]

Identificando o fluxo de tráfego da rede

Além das informações sobre dispositivos e configurações que possam afetar o isolamento de rede baseado em IPsec, é importante examinar os padrões do tráfego da rede. Ao reunir esse tipo de informação, é importante considerar fatores como a maneira como os dispositivos não baseados no Windows (como computadores Linux) ou dispositivos que usam versões do Windows anteriores ao Windows 2000 SP4 se comunicam com outros sistemas baseados no Windows. Considerações adicionais incluem:

Há sub-redes dedicadas a tipos específicos de tráfego, como comunicações de mainframe?

O tráfego entre os locais precisa ser separado?

Há algum tipo de tráfego que requeira o alto nível de segurança fornecido pela criptografia, como comunicações com um banco de dados do RH?

Há algum dispositivo de segurança ou regras de firewall que possam causar um impacto na implementação, como o bloqueio da porta UDP 500?

Como os aplicativos estão se comunicando? Por exemplo, eles usam RPC (Chamada de procedimento remoto), que pode exigir considerações adicionais?

Como os hosts e servidores se comunicam? Eles usam conexões no nível de porta/protocolo ou estabelecem várias sessões com uma grande variedade de protocolos?

Identificando a estrutura do Active Directory

Para entender o impacto que a implementação de IPsec pode ter em uma estrutura do Active Directory, é importante reunir informações sobre a estrutura de floresta do Active Directory, o layout do domínio, o design da unidade organizacional (UO) e a topologia do site, além das informações de rede identificadas anteriormente. Essas informações devem incluir o seguinte:

Número de florestas

Número e nomes dos domínios

Número e tipos de relações de confiança

Número e nomes dos sites

Estrutura de UO e Diretiva de Grupo

Quaisquer informações de diretiva IPsec existentes (se o IPsec estiver em uso no momento)

 

[helldanger1]

Identificando hosts

Algumas das informações de host relevantes que precisam ser reunidas incluem:

Nomes dos computadores

Endereços IP, especialmente endereços estáticos

Endereços MAC

Versão de sistema operacional, inclusive níveis de revisão de service packs e hotfixes.

Participação no domínio

Local físico

Tipo e função do hardware

Identificando considerações de capacidade do IPsec

Há algumas considerações que precisam ser feitas no planejamento da capacidade quando se desenvolve um plano para implementar o IPsec, especialmente quando se contempla o uso de criptografia IPsec, porque ela requer uma certa quantidade de utilização do host e sobrecarga da rede. Algumas considerações incluem:

Utilização de memória pelo servidor. Cada sessão pode consumir até 5 KB de RAM.

Utilização da CPU pelos servidores , estações de trabalho e dispositivos de infra-estrutura. Estas informações são especialmente significativas para servidores. Assegure-se de que os dispositivos já não estejam superutilizados.

Latência e utilização da rede. A latência aumentará quando se usa o IPsec. Quando a Microsoft implantou o IPsec, a utilização da rede sofreu um aumento de 1% a 3%.

Uso da NAT e tipo de criptografia. A comunicação AH não pode passar através de NATs. Portanto, o ESP terá que ser usado para criptografar as comunicações. O ESP tem uma sobrecarga maior de utilização do que a da criptografia AH, a menos que a criptografia ESP/nulo seja usada.

Impacto da Diretiva de Grupo. Os GPOs IPsec têm um impacto na inicialização dos computadores e nos tempos de logon. Linhas de base devem ser medidas antes e depois das implementações de teste para se determinar o efeito real sobre esses tempos.

 

[helldanger1]

Identificando níveis de confiança

Outra importante consideração envolve a determinação dos hosts que participarão desta solução e em que capacidade. Para determinar isso, é necessário estabelecer uma definição clara das condições a serem atendidas para ser considerado confiável e dos graus de confiança que podem existir. As seguintes informações ajudam nesse processo por oferecerem algumas definições claras de confiança, os critérios necessários para se atingir determinados níveis de confiança e como estes afetam o processo de planejamento.

Há quatro estados básicos que podem ser aplicados a um host com relação aos níveis de confiança. Em ordem de confiança, do mais alto para o mais baixo, esses níveis são:

Confiável. O status de confiável implica que os riscos de segurança do host são gerenciados e que outros hosts confiáveis podem assim pressupor que um ato mal-intencionado não será iniciado nesse host. Ainda que esse estado não signifique necessariamente que esse host seja completamente seguro, ele significa que o estado do host é responsabilidade de um departamento de TI e é gerenciado por algum mecanismo, seja ele um processo documentado ou automático.

Visto que esse host é confiável, a comunicação entre ele e outros hosts confiáveis não deve ser impedida pela infra-estrutura de rede. Porque é seguro partir do pressuposto de que nenhum ato mal-intencionado seria cometido por esse host, não há necessidade de bloquear ou filtrar o tráfego do host por meio de firewalls ou medidas semelhantes.

Digno de confiança. O estado digno de confiança indica que, apesar de o computador ser capaz de se tornar um dispositivo confiável, ele ainda requer algumas alterações na configuração ou atualizações de algum tipo para ser certificado como confiável. A identificação desses computadores é especialmente importante durante a fase de projeto, visto que eles fornecem alguma indicação sobre a quantidade de esforço e custo necessários para se estabelecer uma rede isolada.

Conhecido , Não confiável. Há vários motivos por que um computador conhecido pode não ser capaz de se tornar um ativo confiável, desde limitações financeiras até requisitos comerciais ou mesmo requisitos funcionais. Por exemplo, os fundos para o projeto podem ser insuficientes para atualizar todos os computadores, algumas unidades de negócios podem ter a propriedade de seus próprios domínios ou um aplicativo mais antigo pode ser incompatível com os sistemas operacionais para os quais há suporte no momento, não podendo ser executado em um computador seguro.

Independentemente do motivo, proprietários de empresas com computadores conhecidos mas não confiáveis devem ser consultados para se determinar se há algo que possa ser feito para atualizar o computador e para se determinar como resolver essa situação e ao mesmo tempo manter um perfil aceitável de risco.

Desconhecido , Não confiável. O estado desconhecido, não confiável deve ser o estado padrão para todos os hosts. Os hosts nesse estado não são gerenciados e suas configurações são desconhecidas. Portanto, nenhum outro estado de confiança pode ser atribuído a eles. Deve-se partir do pressuposto de que esses hosts são passíveis de serem comprometidos e podem ser usados como plataformas para atividade mal-intencionada e, portanto, que representam um nível de risco inaceitável para a empresa. Esta solução é projetada para reduzir o impacto potencial de tais sistemas.

 

[helldanger1]

Usando as informações reunidas

Quando todas as informações relevantes tiverem sido reunidas, será possível desenvolver um plano de implementação e determinar se a solução de isolamento de rede baseado em IPsec é apropriada para o ambiente de rede atual. Algumas das considerações que podem influenciar a implementação dessa solução incluem as seguintes:

Custo das atualizações necessárias para tornar os hosts compatíveis com um estado confiável e com os requisitos do IPsec.

Custo de atualizações ou substituições de infra-estrutura se os dispositivos da rede atual não oferecerem suporte ao IPsec.

Balanceamento da possível perda da QoS (Qualidade do Serviço) baseada em roteador e dos benefícios de segurança do isolamento de rede, porque a priorização baseada em porta não funcionará quando o IPsec for implementado, mas a QoS baseada em endereço IP continuará a funcionar.

Os monitores de rede e os dispositivos IDS podem falhar quando o IPsec for implementado, especialmente quando a criptografia ESP for usada. Analisadores podem ser usados para solucionar esse problema se o dispositivo tiver um analisador IPsec disponível.

A implementação do IPsec pode exigir atualizações de hardware devido ao aumento da sobrecarga e das demandas sobre a CPU e a memória de servidores e de dispositivos de rede.

O gerenciamento das expectativas pode ser um problema, visto que a latência da rede pode aumentar.

O gerenciamento de usuários fornecedores e convidados também pode gerar sobrecarga excessiva, visto que tais usuários têm dispositivos não confiáveis e podem ter motivos comerciais para acessar recursos da rede isolada. Essas exceções podem se tornar difíceis de gerenciar à medida que seu número e freqüência aumentam, mas podem ser atenuadas pelo uso de uma zona limite entre redes confiáveis e não confiáveis.


Esses problemas ilustram por que são necessários planejamento e testes cuidadosos antes da implementação de alterações que possam afetar toda a rede, como a implementação de IPsec e do isolamento de rede. É preciso ter muita atenção ao determinar-se a forma como implementar esta solução e também a sua viabilidade, devido ao estado atual da rede e dos custos financeiros e políticos de se atualizar uma rede. Além disso, implantações limitadas ou incrementais que somente isolam os recursos visados devem ser discutidas como uma estratégia de atenuação possível para ajudar a solucionar tais preocupações.

Mais uma vez, o isolamento de rede baseado em IPsec é apenas uma parte de uma solução abrangente. Cada solução neste guia ajuda na defesa contra dispositivos não confiáveis que podem se conectar à rede, mas cada parte desta solução pode atuar autonomamente e, ainda assim, aumentar o nível de segurança de qualquer rede. Portanto, mesmo que o isolamento de domínio e servidor IPsec não seja uma solução aceitável no momento, ainda pode ser útil implementar as outras soluções listadas aqui e, talvez, voltar ao isolamento de rede após a rede ter-se tornado mais madura e compatível com os requisitos descritos neste documento.

 

[helldanger1]

Usando os Serviços de Quarentena VPN para proteger-se contra computadores remotos não gerenciados

Em uma sessão padrão de servidor de acesso remoto baseado no Windows, o servidor executará as seguintes ações quando um cliente de acesso remoto iniciar uma sessão:

O servidor de acesso remoto executa verificações com relação às diretivas de acesso remoto configuradas e permite a conexão.

O servidor verifica as permissões de acesso remoto do usuário.

O servidor então autentica as credenciais do usuário em relação ao Active Directory ou algum outro serviço de autenticação.

O servidor atribui um endereço IP ao cliente remoto.


A essa altura, o cliente remoto tem acesso total à rede, e nenhuma verificação foi executada para verificar os níveis de atualização, a existência ou o status da atualização do software antivírus ou qualquer outra informação relacionada à diretiva de segurança. Essa funcionalidade é menos que ótima, porque às vezes significa que atualizações, alterações de configuração ou patches não são aplicados a usuários remotos ou computadores móveis.

Entretanto, uma conexão com Quarentena VPN é diferente, conforme mostrado na seguinte figura e lista numerada:

Figura 8. Processo de Quarentena VPN

Antes da conexão, o cliente remoto executa um script pré-conexão Gerenciador de Conexões que verifica pré-requisitos básicos de conexão (como o nível de atualização da segurança e a data do arquivo de assinatura de vírus) e armazena os resultados. Após executar esse script, o cliente estabelece uma sessão de acesso remoto por meio de um túnel VPN.

O servidor de acesso remoto autentica as credenciais do usuário via RADIUS, que verifica o Active Directory para conferir as credenciais.

Depois que o Active Directory autenticar o usuário, o servidor de acesso remoto coloca o cliente em um estado de quarentena aplicando a diretiva de acesso remoto. Durante a quarentena, o acesso à rede é limitado àquilo que a diretiva de quarentena especifica. Esse acesso limitado pode ser conseguido com um filtro IP que restrinja o acesso a recursos específicos que possam ser usados para atualizar o cliente ou por meio da especificação de um tempo limite que desconecte o cliente após um período.

Um script pós-conexão notifica o servidor de acesso remoto se o cliente está ou não em conformidade com os requisitos especificados. Se a conexão não cumprir os requisitos no tempo limite, o usuário é notificado dos detalhes da falha e a conexão é eliminada.

Se o script pós-conexão indicar que o cliente cumpre os requisitos especificados, o servidor de acesso remoto remove o cliente do modo de quarentena removendo as restrições do filtro IP e concedendo a permissão para acessar os recursos da rede especificados pela diretiva de acesso remoto.


Um cliente de acesso remoto pode acessar somente os recursos localizados na rede de quarentena especificada, seja esta uma sub-rede separada ou um conjunto definido de servidores conectados à Internet. Uma rede de quarentena deve fornecer recursos que permitam a um cliente remoto executar atividades para fazer com que um computador remoto fique em conformidade com os padrões de segurança. Geralmente, esses recursos incluem o acesso a um servidor DNS para resolução de nomes, um servidor de arquivos para recuperação de atualizações e talvez um servidor Web para instruções ou atualizações baseadas na Web.

O uso de uma sub-rede de quarentena neste processo exigiria configurações de tempo limite de sessão mais longos para garantir que haja tempo suficiente para o download e a instalação de atualizações no computador cliente remoto. Para evitar esse problema, o computador cliente pode ser direcionado a usar outras fontes ou usar servidores de atualização conectados à Internet fora da sessão VPN, ainda que esta abordagem exija um script mais complexo e possa apresentar outros problemas de segurança. Em ambos os casos, é o script que determina o comportamento da quarentena, e não a rede de quarentena propriamente dita.

Observação Scripts de diretivas IPsec podem ser criados se a solução de quarentena tiver que acomodar sistemas que não sejam adicionados a um domínio. Nesses casos, netsh ou lpseccmd.exe podem ser usados para aplicar diretivas simples com certificados para oferecer suporte à autenticação IPsec. O IPsec também pode funcionar para sistemas adicionados a um domínio em configurações de quarentena VPN, assim como em uma solução em camadas.

 

[helldanger1]

Componentes de cliente da quarentena VPN

Como observado na seção anterior, a primeira etapa no processo de quarentena VPN começa com o cliente, especificamente com o script pré-conexão Gerenciador de Conexões. O Gerenciador de Conexões faz parte do Kit de Administração do Gerenciador de Conexões (CMAK), que centraliza e automatiza o estabelecimento e o gerenciamento de conexões de rede e oferece suporte a várias das principais áreas de uma configuração de quarentena VPN, inclusive:

Verificações de segurança pré-conexão para gerenciar as configurações do computador cliente automaticamente.

Verificações de segurança pós-conexão e validações de logon.


O Gerenciador de Conexões permite aos administradores definir ações personalizadas por meio de perfis que podem ser distribuídos para vários computadores. Esse recurso simplifica o processo de conexão para usuários remotos limitando o número de configurações que eles podem alterar. Algumas das configurações que podem ser alteradas incluem:

Estabelecimento de listas de números de telefone que podem ser usados para conexões discadas.

Personalização de elementos gráficos, ícones, mensagens e texto da Ajuda.

Execução de ações personalizadas pré- e pós-conexão, que podem incluir atividades como a redefinição do perfil do discador ou a configuração das regras de filtro de pacotes do Firewall do Windows.


Outro componente do CMAK é o agente cliente (RQC.exe), que se comunica com o Serviço de Quarentena de Acesso Remoto (RQS.exe) no servidor de acesso remoto usando a porta TCP 7250. Quando uma conexão de quarentena é estabelecida, o RQS envia ao RQC uma chave secreta compartilhada. Se o cliente atender às condições necessárias, o RQC enviará a chave compartilhada para liberar o cliente da quarentena.

Os perfis do Gerenciador de Conexões são pacotes personalizados auto-extraíveis de discador de cliente do Gerenciador de Conexões que podem ser criados e configurados com o CMAK. O assistente do CMAK orienta os administradores pelo processo de configuração do perfil, que pode então ser distribuído por meio de diversos mecanismos, que vão desde a Diretiva de Grupo até a distribuição pelo software Microsoft SMS (Systems Management Server) 2003. Quando o executável criado é executado no computador cliente, ele instala o perfil no computador local, juntamente com as configurações necessárias para estabelecer a comunicação com os servidores de acesso remoto. Quando a instalação é concluída, o usuário precisa somente iniciar o nome do perfil no menu Conectar a no Windows XP para estabelecer a conexão.

 

[helldanger1]

Componentes do servidor de quarentena VPN

O servidor de acesso remoto a VPN é a peça central desta solução e desempenha as seguintes funções:

Executa o Serviço de Quarentena de Acesso Remoto (RQS.exe).

Aplica diretivas de acesso remoto para configurações de acesso por quarentena.

Negocia a comunicação com o agente cliente.

Recebe informações de conformidade com a diretiva do agente cliente.

Aplica diretivas de acesso remoto para determinar as permissões de acesso aos recursos da rede.


O Serviço de Quarentena de Acesso Remoto é um componente opcional no Windows Server 2003 com Service Pack 1 e oferece suporte às APIs necessárias para se colocar computadores clientes remotos em quarentena e então removê-los do modo de quarentena depois que o agente cliente envia a notificação de conformidade com a diretiva. Esse serviço (RQS.exe) monitora a porta TCP 7250 para receber a notificação do componente do lado do cliente (RQC.exe) de que o computador cliente cumpre os requisitos da diretiva. Essa funcionalidade significa que quaisquer firewalls, inclusive firewalls baseados no host, precisam permitir o tráfego na porta TCP 7250 para que esta solução funcione.
Componentes de rede da quarentena VPN

Os componentes de rede a seguir incluem tanto partes obrigatórias quanto opcionais, conforme observado, que podem fazer parte de uma solução de rede de quarentena VPN.

Servidor RADIUS de IAS (Serviço de Autenticação da Internet) (recomendado). Embora os servidores IAS sejam necessários somente se o RADIUS for usado como provedor de autenticação, eles têm algumas vantagens convincentes com relação a outras soluções de autenticação, inclusive suporte para EAP (Extensible Authentication Protocol) para permitir certificados e autenticação de dois fatores baseada em cartão inteligente. Se o RADIUS for usado, recomenda-se usar o IAS fornecido com o Windows Server 2003 como provedor de RADIUS, pois ele oferece suporte às VSAs MS-Quarantine Session Timeout e MS-Quarantine-IPFilter, algo que outros servidores RADIUS podem não fazer.

Active Directory (recomendado). O Active Directory funciona como um banco de dados de autenticação de contas de usuários para o RADIUS e integra-se com o IAS e com outros serviços. Quando usado em combinação com o IAS, ele pode oferecer suporte à autenticação de dois fatores com certificados ou outros métodos.

Servidor DHCP (recomendado). Servidores DHCP são usados para oferecer o fornecimento de endereços IP aos clientes remotos.

Servidor DNS (recomendado). Um servidor DNS fornece serviços de resolução de nomes para que os clientes na rede de quarentena possam se conectar a outros servidores (se fornecidos) que possam ajudar a atualizar os computadores clientes remotos.

Servidor Microsoft Software Update Service (WSUS) (opcional). Os servidores WSUS podem fornecer as atualizações de segurança e os hotfixes que podem ser necessários aos computadores remotos para atender aos requisitos de liberação do estado de quarentena. Outros métodos também podem ser usados, inclusive SMS 2003 ou mesmo os serviços padrão do Windows Update, se os computadores precisarem ser direcionados a fontes externas para atualização.

Servidor de arquivos (opcional). Servidores de arquivo podem ser usados para fornecer compartilhamentos onde os computadores em quarentena podem acessar atualizações de software e arquivos de assinatura antivírus para cumprirem os requisitos de diretiva.

Servidor Web (opcional). Servidores Web podem ser usados em quarentena para fornecer ao usuário instruções para remoção de seus computadores do estado de quarentena. Alguns pacotes de atualização também usam componentes da Web para distribuição, como alguns produtos antivírus.

 

[helldanger1]

Usando a autenticação 802.1X para se proteger contra clientes sem fio não gerenciados

A seção anterior apresentou a autenticação 802.1X como a opção mais eficaz disponível para ajudar a proteger redes sem fio contra computadores não confiáveis. Os vários métodos 802.1X que contam com suporte nativo nas versões atuais do Microsoft Windows foram descritos, e uma explicação de por que a autenticação 802.1X não é tão eficaz para redes cabeadas foi fornecida (apesar de ela ser muito eficaz para redes sem fio). Com essas informações, é possível discutir as diferenças entre os métodos para os quais há suporte e determinar qual pode ser mais adequado a diferentes tipos de ambientes de rede de empresas de médio porte.
Comparações do 802.1X

Conforme discutido anteriormente, há três métodos 802.1X que contam com o suporte das versões atuais do Microsoft Windows. Esses métodos são:

EAP-MD5

EAP protegido (PEAP)

EAP-TLS


Desses três métodos, o primeiro (EAP-MD5) é considerado o menos seguro, porque as frases secretas usadas nesta abordagem são transmitidas pelo ar e, portanto, podem ser interceptadas. As outras duas opções (PEAP e EAP-TLS) são dignas de consideração para a implantação em redes de empresas de médio porte.

A implementação da Microsoft do PEAP usa o Microsoft Challenge Handshake Authentication Protocol versão 2 (MS-CHAP v2), que foi projetado originalmente como um método de autenticação de VPN discada, mas que se ajusta bem ao PEAP por oferecer suporte às diretivas de senha de usuário de alta segurança disponíveis através do Active Directory. Esta abordagem é de implementação mais simples do que a do EAP-TLS e custa menos em termos de recursos e custo inicial, porque não há tantos servidores e serviços adicionais necessários à implementação. Embora esta solução não exija certificados para os servidores de autenticação, esses certificados podem ser gerados por provedores de certificados terceirizados, visto que não são muitos os necessários à implementação.

Entretanto, o EAP-TLS é considerado a implementação mais segura disponível da autenticação 802.1X, porque exige certificados tanto do cliente quanto do servidor de autenticação para autenticação mútua. Visto que um grande número de certificados seria necessário para essa implementação, sugere-se que uma infra-estrutura de chave pública seja implementada para oferecer suporte, caso ela ainda não exista. Portanto, considera-se o EAP-TLS como tendo custos mais altos de implementação e suporte quando comparado ao PEAP com MS-CHAP v2.

 

[helldanger1]

Processo de decisão do 802.1X

Para facilitar o processo de decisão com relação à melhor implementação do 802.1X para um determinado ambiente de rede, a Microsoft criou a seguinte árvore de decisão de autenticação 802.1X.

Figura 9. Árvore de decisão do 802.1X

Este fluxograma pode causar alguma confusão por usar o termo “empresa de grande porte”. Esse termo geralmente descreve qualquer empresa com pelo menos 500 funcionários e uma equipe de TI de suporte de pelo menos 5 especialistas em tecnologia. Dada esta informação, fica claro que qualquer uma das duas soluções seria apropriada para o ambiente de uma empresa de médio porte. Portanto, o processo de decisão se desenrola mais em torno das questões de aceitação de riscos e relação custo-benefício.

A principal diferença entre PEAP e EAP-TLS envolve a necessidade de uma infra-estrutura de certificados, motivo pelo qual o EAP-TLS é geralmente considerado a opção mais adequada para as necessidades das empresas de grande porte, e o PEAP é normalmente considerado suficiente para empresas menores, caso não haja requisitos regulamentares que exijam padrões mais restritos de segurança. Considerações de custo à parte, às vezes as organizações têm necessidades adicionais de uma infra-estrutura de certificados, o que oferece uma justificativa adicional para um investimento em PKI. Afinal de contas, se muitos certificados forem necessários para fins de conteúdo protegido da Web ou de assinatura de códigos, é razoável também usar esse investimento em infra-estrutura para implementar a forma mais segura de autenticação 802.1X.

 

[helldanger1]

Requisitos de PEAP 802.1X

Uma implementação de PEAP baseado em Microsoft com MS-CHAP v2 exigiria pelo menos dois servidores RADIUS IAS para atuarem como servidores de autenticação e autenticar clientes sem fio com relação a um banco de dados de contas do Active Directory. O número de servidores RADIUS pode exigir ajustes com base no número de sites remotos ou para acomodar grandes números de tentativas de autenticação de usuários.

A existência de locais remotos não implica automaticamente na necessidade de servidores RADIUS IAS adicionais. No entanto, se os locais remotos não tiverem conexões redundantes de alta largura de banda, ou se já tiverem seus próprios controladores de domínio e outros recursos locais, então mais servidores de autenticação deverão ser adicionados para esses sites.
Requisitos de EAP-TLS 802.1X

Como mencionado anteriormente, o EAP-TLS requer mais recursos do que as implementações PEAP por causa dos requisitos de certificado adicionais. Obviamente, é possível usar provedores de terceiros para emissão dos certificados necessários para todos os clientes sem fio e servidores de autenticação, mas essa abordagem é mais dispendiosa do que a implementação de uma infra-estrutura de certificados, exceto quando o número de clientes sem fio é estritamente limitado a poucos usuários.

No total, uma implementação EAP-TLS simples exigirá pelo menos quatro servidores, ou mais se forem usados em empresas maiores ou para redes distribuídas geograficamente. Dois dos quatro servidores atuarão como servidores RADIUS IAS redundantes e os outros dois funcionarão como a infra-estrutura de certificados. Dos dois servidores de certificado, recomenda-se que um (o servidor de certificado raiz) seja criado fora da rede e permaneça desconectado dela, o que pode significar que o número de servidores pode ser reduzido em um em determinadas circunstâncias.

 

[helldanger1]

Usando WEP ou WPA

Outro problema com relação à segurança sem fio é se deve usar-se ou não a criptografia sem fio e, em caso afirmativo, que padrão deve ser usado. Para um ambiente de empresa de médio porte, existe poucos motivos pelos quais seja razoável considerar a não utilização de criptografia sem fio. Esses motivos estão associados a empresas que fornecem conexões sem fio à Internet para acesso público. Caso contrário, para ajudar a garantir a segurança de uma rede sem fio, é fundamental que alguma forma de criptografia sem fio seja implementada em conjunto com a autenticação baseada em 802.1X.

A criptografia sem fio vem nas duas formas principais a seguir, com uma variante adicional. Essas formas são:

WEP. O padrão WEP (Wired Equivalent Privacy) fazia parte do padrão IEEE 802.11 original que usa criptografia RC4 de 64 ou 128 bits para proteger comunicações sem fio. Foram descobertas falhas graves que tornam esse método extremamente vulnerável a ataques de escuta passiva. Várias ferramentas estão prontamente disponíveis para decodificar transmissões WEP em um período relativamente curto de tempo, às vezes em uma questão de minutos. Em geral, o uso do WEP não é recomendado para ambientes comerciais, mas ele pode ser relativamente protegido por meio do uso de vários métodos, inclusive da autenticação 802.1X.

WPA. Como resposta aos pontos fracos inerentes ao padrão WEP, um consórcio de líderes do setor, que inclui a Microsoft e o Wi-Fi Institute, criou o padrão WPA (Wi-Fi Protected Access) como uma implementação parcial do padrão 802.11i, que ainda estava em desenvolvimento na época. Esse padrão oferece uma criptografia muito mais segura, que usa o TKIP (Temporal Key Integrity Protocol) para criptografia de dados, que é muito superior ao imperfeito padrão WEP. A maioria dos pontos de acesso sem fio (WAPs) no mercado hoje em dia oferece suporte ao padrão WPA, assim como todas as versões atuais do sistema operacional Microsoft Windows.

WPA2. O padrão Wi-Fi Protected Access 2 (WPA2) foi estabelecido em setembro de 2004 pela Wi-Fi Alliance. Ele é certificado como uma implementação completa da especificação IEEE 802.11i, que foi ratificada em junho de 2004. Esse padrão oferece suporte a métodos de autenticação EAP baseados em 802.1X ou à tecnologia PSK (algumas vezes denominada WPA de modo pessoal), mas apresenta o mecanismo de criptografia avançada que usa o CCMP (Counter-Mode/CBC-MAC Protocol) denominado AES (Advanced Encryption Standard). Essa implementação da criptografia sem fio é extremamente segura. A maioria dos fornecedores oferece alguma forma de suporte ao WPA2, inclusive versões atuais do sistema operacional Microsoft Windows.


Se possível, WPA2 ou WPA devem ser usados para ajudar a proteger os dados sem fio. No entanto, isso pode não ser possível porque esses padrões são mais novos, especialmente se já tiver sido feito um investimento significativo em tecnologia sem fio que não ofereça suporte a eles. Conforme mencionado anteriormente, é possível aumentar o nível de segurança oferecido pelo padrão WEP por meio da configuração da autenticação 802.1X e das trocas freqüentes de pares de chaves. Ainda assim, o uso do WEP deve ser reservado para redes sem fio que estejam em um estado de transição para o padrão WPA ou WPA 2.

 

[helldanger1]

Usando SMS para detectar sistemas não gerenciados

O Microsoft SMS (Systems Management Server) 2003 é uma ferramenta de gerenciamento muito versátil em uma rede Microsoft. Com o SMS é possível centralizar várias funções de gerenciamento, inclusive distribuição de software, implantação de atualizações de segurança e auditoria de sistema. No centro dessas funções está a capacidade de contar com um inventário de sistemas automatizado e centralizado, do qual se possa implantar essas ferramentas incrivelmente úteis, ponto em que a detecção de sistemas não gerenciados entra em cena.

O SMS 2003 fornece diferentes métodos de descoberta que os administradores podem usar para criar o banco de dados da coleção de computadores, que contém informações sobre cada computador na rede. Esses métodos de descoberta vão desde o método de descoberta baseado no Active Directory (que atualiza a coleção com detalhes fornecidos pela lista de contas de computadores do Active Directory) até o método de descoberta de rede (que sonda a rede ativamente para verificar a existência de quaisquer dispositivos conectados). Esses métodos de descoberta são configuráveis para ocorrer automaticamente em intervalos predefinidos e atualizam os bancos de dados de coleções quando concluídos.

Para atender à necessidade de detectar sistemas não gerenciados quando conectados à rede, é possível configurar a descoberta de rede para ocorrer com maior freqüência e então revisar os achados em intervalos regulares para se determinar quando um novo sistema foi conectado à rede. Quando essas conexões de sistemas acontecem, elas podem ser verificadas em qualquer lista estabelecida de novos computadores ou de solicitações de conexão à rede para confirmar que o novo sistema esteja autorizado a usar a rede.

 

[helldanger1]

Processo de descoberta de rede

Uma das desvantagens dessa abordagem para descoberta de sistemas não gerenciados é que o SMS pode ter dificuldade para descobrir os detalhes dos computadores que usam sistemas operacionais que não sejam o Microsoft Windows. Na verdade, mesmo versões mais antigas do que o Microsoft Windows 98 SE podem passar despercebidas pelos métodos de descoberta do SMS 2003, visto que eles não oferecem suporte a implementações do WMI (Windows Management Interface). Assim sendo, é necessário adicionar scripts a esse processo de solução, de forma que qualquer novo dispositivo seja detectado quando for conectado à rede. A figura a seguir ilustra como esse processo funciona.

Figura 10. Processo de descoberta de computadores não gerenciados do SMS

Esta figura mostra os métodos de descoberta que podem ser usados para adicionar diferentes tipos de computador ao banco de dados de coleção do SMS. Há três tipos diferentes de computadores a serem confrontados, inclusive:

Sistemas gerenciados acessíveis por SMS. Esses computadores podem ser gerenciados pelo SMS e já foram colocados sob o gerenciamento do SMS. Eles já existem no banco de dados de coleção do SMS e devem ser configurados para gerenciamento automático. Eles provavelmente são considerados parte da rede confiável e não requerem nenhuma atenção adicional.

Sistemas não gerenciados acessíveis por SMS. Esses computadores podem ser gerenciados pelo SMS, mas não foram colocados sob o gerenciamento do SMS. Eles podem ou não ser detectáveis pelo SMS, dependendo de seu posicionamento na rede (por exemplo, atrás de firewalls ou não), e podem incluir computadores gerenciados de outras maneiras. Esses computadores devem existir em uma lista de isenção que inclua detalhes de gerenciamento. Caso não existam, devem ser considerados não confiáveis e podem requerer uma investigação adicional. Eles podem ser descobertos pelo SMS, impedindo qualquer dispositivo de rede que bloqueie essa atividade.

Sistemas não gerenciados inacessíveis por SMS. Esses computadores não podem ser gerenciados pelo SMS e não estão sob o controle do SMS. Eles podem ou não incluir sistemas conhecidos gerenciados de outras maneiras. Esses computadores devem existir em uma lista de isenção que inclua detalhes de gerenciamento. Caso não existam, devem ser considerados desconhecidos e não confiáveis e requerer uma investigação adicional. Esses computadores podem ser detectados somente com o uso de processos diferentes da descoberta SMS, inclusive scripts de descoberta personalizados.


A esta altura, deve estar claro que o processo de descoberta de sistemas não gerenciados na rede depende do estabelecimento de processos que documentam os detalhes de cada conexão de computador autorizada na rede. Essa documentação deve incluir detalhes sobre o computador, se ele é ou não gerenciado por métodos automatizados (como SMS) e, em caso negativo, que processo é usado para manter o computador em conformidade com as diretivas de segurança estabelecidas, se houver. Obviamente, pode haver um computador autorizado em uma rede que não seja obrigado a cumprir os padrões de segurança, mas esses computadores devem ser forçados a permanecer em um segmento de rede não confiável que seja isolado da rede confiável.

Quando existe um processo documentado de “adição de computador” que indica todos os computadores conhecidos existentes na rede de uma maneira autorizada, torna-se possível usar essas informações para determinar o que está autorizado e o que não está. Quaisquer computadores descobertos na rede que não existam nessa lista devem ser considerados suspeitos e imediatamente investigados.

 

[helldanger1]

Implantação e gerenciamento

A seção "Desenvolvimento" forneceu informações sobre os detalhes necessários à criação de planos de implantação. Esta seção detalha alguns dos problemas comuns de implantação, assim como processos que podem ajudar os implementadores de tecnologia a implementar estas soluções ou ajudar os responsáveis pela tomada de decisões a entender melhor as implicações destas soluções, para que possam tomar uma decisão informada sobre sua adequação a um determinado ambiente.
Usando IPsec para isolar domínios e servidores

Devido à complexidade associada ao isolamento de rede baseado em IPsec, sugere-se que os implementadores optem por uma abordagem em fases da implantação desta solução em uma rede de produção. Há duas maneiras de se realizar uma implantação em fases, que se baseiam em como as diretivas IPsec estão implantadas: por grupo ou por diretiva.

Independentemente do método usado, é importante usar amostras piloto de cada grupo durante os estágios iniciais da implantação, além de testar o impacto desta solução em um ambiente de teste, se possível. A implantação do IPsec deve seguir um processo formal de solicitação de controle de alteração que detalhe os planos de reversão, assim como o compromisso informado dos proprietários da tecnologia e dos processos comerciais afetados.
Implantando o IPsec por grupo

O método de implantação do isolamento de rede IPsec por grupo usa diretivas totalmente definidas, mas controla a implementação usando ACLs nos GPOs que distribuem as diretivas. Todas as diretivas IPsec terão todas as isenções e sub-redes seguras completamente definidas com todas as ações de filtro apropriadas ativadas antes da implantação.

Quando a configuração é concluída, os administradores criam GPOs para cada diretiva IPsec e grupos de computadores para gerenciar esses GPOs. Quando criadas, as diretivas IPsec apropriadas são atribuídas ao seu GPO correspondente, e os GPOs são vinculados aos objetos apropriados no Active Directory. Nenhuma das diretivas deve ser distribuída a essa altura do processo, porque as ACLs que controlam a atribuição dos GPOs estão vazias.

Quando os computadores piloto são identificados, as contas de computador correspondentes podem ser colocadas nos grupos de computador apropriados, e a diretiva IPsec será aplicada após o próximo intervalo de pesquisa de GPO. À medida que mais computadores são adicionados à lista de implantação em fases, suas contas correspondentes podem ser colocadas nos grupos apropriados para distribuição de diretiva.

Este método exige um planejamento cuidadoso para garantir que as comunicações não sejam interrompidas. Por exemplo, se um servidor que hospeda um aplicativo usado por todos os hosts for colocado em um grupo protegido que requeira comunicação criptografada por IPsec, então os computadores que ainda não foram adicionados a grupos e qualquer host que não possa usar a criptografia IPsec serão prejudicados.

 

[helldanger1]

Implantando o IPsec por diretiva

Este método aborda a implantação criando as diretivas IPsec a partir do zero durante a implantação, em vez de criá-las antes da implantação verdadeira para produção. Quando se usa este método, as diretivas IPsec iniciais incluem somente listas de exceções, sem regras definidas para os computadores negociarem a segurança. Após a diretiva inicial ser distribuída, os administradores podem criar uma regra de segurança com um filtro que afete somente uma única sub-rede. À medida que a implantação progride, outras sub-redes podem ser adicionadas à regra de segurança até que a diretiva chegue ao fim do estado de implantação.

As vantagens de se usar este método de implantação em fases é que o IPsec é negociado apenas para uma pequena porcentagem do tráfego TCP/IP total, em vez de para todas as sub-redes, como acontece com a abordagem grupo a grupo. Além disso, este método permite o teste de todos os caminhos de rede de uma única sub-rede, o que reduz o número de clientes afetados se ocorrerem problemas. No entanto, o problema com essa abordagem é que ela se aplica a todos os computadores no grupo ou domínio de isolamento, e não a computadores específicos, como na abordagem grupo a grupo. Além disso, todos os computadores terão que enfrentar o atraso de três segundos para retorno para limpo em algum momento ao iniciarem conexões com sub-redes especificadas.

Esta abordagem funciona bem para redes complexas com várias sub-redes, mas é muito pouco interessante para redes menores, com relativamente poucas sub-redes.
Listas de isenção

Mesmo o modelo de isolamento de rede mais bem projetado encontrará algumas restrições quando implementado em um ambiente de produção. Normalmente, os principais componentes de um ambiente de rede, como servidores DNS e controladores de domínio, apresentam alguns desafios que precisam ser solucionados. Tais sistemas precisam ser protegidos, mas também precisam estar disponíveis para todos os sistemas em uma rede. Portanto, devem estar abertos a solicitações de conexão de entrada. Outros problemas também podem se manifestar durante a conversão do plano em produção, mas existe um método para resolver esses problemas: listas de isenção.

Uma lista de isenção é uma lista dos computadores que não podem ser protegidos com IPsec e que precisarão ser implementados em cada diretiva IPsec projetada. Visto que o IPsec oferece suporte apenas à filtragem estática, qualquer host adicionado a uma lista de isenção permitirá tráfego tanto de saída quanto de entrada de todas as partes da rede, confiáveis ou não. Por isso, a lista de isenção deve ser mantida tão pequena quanto possível, porque esses hosts precisarão de proteção adicional por meio da proteção de servidor e da filtragem de firewall com informações de estado baseada em host para atenuar os riscos que enfrentam de dispositivos não gerenciados. Também pode ser útil considerar a colocação dos hosts da lista de isenção em uma única sub-rede ou VLAN para facilitar o gerenciamento, ou a consolidação das funções de servidor para reduzir o número de hosts isentos.

Alguns dos hosts que podem precisar ser adicionados a uma lista de isenção incluem:

Os controladores de domínio não oferecem suporte à comunicação IPsec com membros do domínio, ainda que forneçam as diretivas IPsec para os membros do domínio e executem a autenticação Kerberos em que o isolamento de rede se baseia.

Os hosts que podem sofrer um impacto inaceitável em seu desempenho, o que pode ocorrer em hosts que precisam gerenciar milhares de clientes simultaneamente, assim como em hosts afetados pelo atraso de três segundos para retorno para limpo, como os servidores DHCP.

Os hosts que não têm uma implementação IPsec compatível ou que fornecerão serviços a computadores confiáveis e não confiáveis, mas que não usarão IPsec.


Assim como acontece com o grupo de limite, deve haver um processo formal para aprovar os hosts que precisam ser adicionados à lista de isenção.

Observação Há uma correção de “Diretiva simples” para Microsoft Windows XP e Windows Server 2003 que torna as listas de isenção desnecessárias. Para obter mais informações, consulte os artigos (a página pode estar em inglês) da Microsoft Knowledge Base 914841 em How to simplify the creation and maintenance of Internet Protocol (IPsec) security filters in Windows Server 2003 and Windows XP e 914842, em http://support.microsoft.com/?kbid=914842.

 

[helldanger1]

Considerações sobre o gerenciamento IPsec

Uma vez implementadas, as diretivas IPsec afetam a comunicação entre muitos hosts na rede. Portanto, alterações que ocorrem após a implantação podem ter um efeito profundo em muitos usuários. Por esse motivo, todas as alterações feitas na rede de isolamento baseada em IPsec devem seguir um processo de gerenciamento de alterações MOF padronizado que inclua o seguinte:

Solicitação de alteração (RFC)

Classificação da alteração

Autorização da alteração

Plano de desenvolvimento da alteração

Plano de liberação da alteração

Análise da alteração


A Microsoft recomenda o uso do Windows Server 2003 como plataforma de gerenciamento IPsec. Para facilitar as tarefas de gerenciamento, os administradores podem usar o snap-in do MMC de Diretiva de Segurança IPSec ou a ferramenta de linha de comando Netsh no console do Windows Server 2003. Caso contrário, o gerenciamento das diretivas IPsec é uma tarefa relativamente simples, porque elas são distribuídas via Diretiva de Grupo. Portanto, a adição de novos computadores à rede confiável pode ser automatizada se um processo de "adição de computador" estabelecido for usado.

No entanto, será necessário ter em mente o seguinte ao considerar-se as alterações:

Qualquer alteração em uma ação de filtro que estava sendo usada para uma SA IPsec fará com que SAs estabelecidas sob essas configurações de diretiva sejam excluídas. Essa funcionalidade cria uma nova tentativa de modo rápido se houver tráfego na rota, o que pode resultar na interrupção do tráfego da rede.

A alteração do método de autenticação ou do método de segurança do modo principal fará com que o IKE exclua os principais modos existentes. Em algumas circunstâncias, esta funcionalidade pode ocasionar a falha das negociações do modo principal IKE do lado do servidor com o cliente.

Quando as diretivas IPsec em um GPO forem alteradas, determinados atrasos (inclusive o atraso de replicação do Active Directory e o atraso de pesquisa de GPO) ocorrerão, podendo variar de minutos a horas, dependendo do tamanho e da complexidade do ambiente.



Outra consideração de gerenciamento refere-se a como isolar computadores suspeitos na ocorrência de infecções. Existem várias maneiras de lidar com atividades mal-intencionadas, inclusive:

Isolar o domínio de isolamento. Com a modificação do filtro IPsec – Modo de solicitação segura para desativar comunicações não protegidas, a rede isolada pode ser completamente desconectada da rede não confiável quando um dispositivo não confiável está sob suspeita de ser uma plataforma para atividades mal-intencionadas.

Bloquear portas suspeitas. Com a criação de listas de filtros com dois filtros unilaterais, é possível bloquear o tráfego pelas portas. Essa abordagem deve ser usada com cautela, porque pode bloquear tráfego necessário, como DNS, o que dificultaria reversões ou alterações adicionais ao IPsec.

Criar isolamento em domínios filhos. Com a alteração das diretivas para que um domínio use uma chave pré-compartilhada em vez do protocolo Kerberos para autenticação IPsec, é possível isolar um domínio de outros domínios em uma floresta.

Criar isolamento em grupos predefinidos. Com o uso de chaves pré-compartilhadas ou certificados para a autenticação IPsec em vez do protocolo Kerberos, é possível criar grupos de isolamento que usam diferentes chaves ou certificados que executam o mesmo tipo de funcionalidade de isolamento.

 

[helldanger1]

Usando os Serviços de Quarentena VPN para proteger-se contra computadores remotos não gerenciados

A implantação real do controle de quarentena VPN basicamente envolve seis etapas além de qualquer processo de solicitação de gerenciamento de alteração e de processos de teste pré-implantação que possam existir em uma determinada organização. Essas seis etapas incluem:

Criar recursos de quarentena.

Criar scripts para validar configurações de cliente.

Instalar o componente de escuta Rqs.exe nos servidores de acesso remoto.

Criar perfis de quarentena do Gerenciador de Conexões (CM) com o CMAK do Windows Server 2003.

Distribuir os perfis CM aos computadores clientes de acesso remoto.

Configurar a diretiva de acesso remoto por quarentena.

1. Criar recursos de quarentena

Se os clientes de quarentena forem usar recursos internos para atualizarem-se até o estado de conformidade com as diretivas de segurança estabelecidas, precisará haver um conjunto de recursos acessíveis que eles possam usar para instalar as atualizações necessárias e outros softwares necessários para torná-los seguros. Conforme detalhado na seção anterior, esses recursos geralmente incluem um nome de servidor, servidores de arquivos e, às vezes, servidores Web. Algumas abordagens podem ser usadas ao se designar esses recursos de quarentena, inclusive designar servidores existentes que residam na rede interna e colocar os recursos necessários em suas próprias sub-redes separadas.

A primeira abordagem, designar servidores individuais, pode reduzir os custos associados à adição de tais servidores para distribuir atualizações, porque são usados servidores existentes. No entanto, essa abordagem requer filtros de pacote complexos, porque cada recurso precisará de seu próprio conjunto de filtros no atributo MS-Quarantine-IPFilter da diretiva de acesso remoto por quarentena.

Colocar todos os recursos de quarentena em uma única sub-rede dedicada aos serviços de quarentena pode envolver a adição de mais servidores ao ambiente de rede, mas essa solução requer somente um único filtro de pacote de entrada e saída para todos os recursos de quarentena.
2. Criar scripts de validação

Os scripts de quarentena executam uma série de testes que garantem que os computadores do acesso remoto estejam em conformidade com as diretivas de segurança. Quando esses testes são concluídos, o script precisa iniciar o componente de cliente RQC.exe (se bem-sucedido) ou direcionar o computador cliente para os recursos apropriados para atualizá-lo. Obviamente, o script também poderia simplesmente fazer cumprir um tempo limite da rede e apresentar uma mensagem de falha se as diretivas de rede determinarem essa abordagem. Esses scripts podem ser tão simples quanto um arquivo de lote de linha de comando ou executáveis completos.

 

[helldanger1]

Alguns exemplos de scripts estão disponíveis para análise e download na página Scripts de exemplo de quarentena VPN (a página pode estar em inglês) no Centro de Download da Microsoft em Download details: VPN Quarantine Sample Scripts for Verifying Client Health Configurations.
3. Instalar RQS.exe em servidores de acesso remoto

O processo de instalação do serviço Agente de Quarentena de Acesso Remoto (Rqs.exe) em um computador Microsoft Windows Server 2003 é diferente para servidores com o Service Pack 1 (SP1). Por motivo de espaço, esta seção descreve somente a instalação no Windows Server 2003 com SP1, porque partimos do pressuposto de que todos os sistemas têm todos os service packs e atualizações de segurança recentes.

Para instalar o Rqs.exe em um servidor Windows Server 2003 com SP1

Clique em Iniciar e em Painel de controle.

Clique em Adicionar ou remover programas.

Clique em Adicionar/Remover Componentes do Windows.

Selecione Componentes e clique em Serviços de rede.

Clique em Detalhes.

Selecione Subcomponents of Networking Services, clique em Serviço de Quarentena de Acesso Remoto e em OK.


Esse processo instala, sem iniciar, o serviço de quarentena, que precisa ser iniciado manualmente por um administrador após a solução ter sido completamente configurada e o ambiente ter sido preparado para implementação.

Uma etapa adicional no processo de instalação inclui a modificação das seqüências de caracteres da versão do script de forma a corresponderem à seqüência de caracteres de versão configurada para Rqc.exe no script de quarentena. O Rqs.exe pode ser configurado para aceitar várias seqüências de caracteres de versão de script que são, por sua vez, gravadas no Registro do servidor de acesso remoto em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\rqs\AllowedSet, que é onde essas configurações precisam ser aplicadas por meio de um tipo de valor REG_MULTI_SZ. Normalmente, o valor Allowed Set é definido como RASQuarantineConfigPassed, mas valores adicionais de seqüência de caracteres podem ser adicionados.

 

[helldanger1]

4. Criar perfis CM de quarentena

Um perfil CM de quarentena é, na verdade, um perfil CM de acesso remoto normal que tem as seguintes adições:

Uma ação pós-conexão que executa o script que foi criado para verificar a conformidade com a diretiva da rede e o script propriamente dito. Isso é feito por meio da página Ações Personalizadas do assistente do CMAK.

Um componente de notificação também precisa ser adicionado ao perfil na tela Arquivos Adicionais do assistente do CMAK.

5. Distribuir perfis CM

Os perfis CM de quarentena recém-criados precisam ser distribuídos e instalados em todos os computadores clientes de acesso remoto. Um perfil vem na forma de um arquivo executável que precisa ser executado em cada computador cliente de acesso remoto para que este instale o perfil e configure a conexão de rede de quarentena.

A distribuição desses perfis pode ser um processo manual, no qual eles são enviados como anexos aos usuários junto com instruções, por exemplo. A distribuição também pode ser automatizada com ferramentas como a distribuição de software SMS 2003. Há vários métodos que podem ser usados, é a melhor abordagem é diferente para cada ambiente.
6. Configurar uma diretiva de acesso remoto por quarentena

O procedimento de configuração de uma diretiva de acesso remoto por quarentena difere, dependendo de ela estar ou não configurada em um servidor IAS ou em outro provedor de autenticação, como segue:

Se ela estiver configurada em um servidor RADIUS IAS, use o snap-in Serviço de autenticação da Internet.

Se estiver configurada em um provedor de autenticação Windows, use o snap-in Roteamento e Acesso Remoto.


Quando se cria uma diretiva, uma diretiva de acesso remoto em modo normal deve ser feita primeiro. Então, os atributos MS-Quarantine-Session-Timeout e MS-Quarantine-IPFilter devem ser adicionados na guia Avançado das propriedades do perfil de diretiva de acesso remoto.

Se o RADIUS estiver sendo usado, a diretiva de acesso remoto por quarentena precisará ser replicada nos outros servidores RADIUS seja por meio da cópia da configuração ou por sua criação manual em cada servidor.

 

[helldanger1]

Usando a autenticação 802.1X para se proteger contra clientes sem fio não gerenciados

Conforme descrito nas seções anteriores, as opções de segurança recomendadas pela Microsoft para a proteção da rede sem fio de uma empresa de médio porte, da mais segura para a menos segura, são:

WPA2/AES e EAP-TLS

WPA2/AES e PEAP-MS-CHAP v2

WPA/TKIP e EAP-TLS

WPA/TKIP e PEAP-MS-CHAP v2


Ainda que EAP-TLS ou PEAP-MS-CHAP v2 possam tornar o WEP mais seguro, o uso do WEP como parte de qualquer das duas soluções é recomendado somente para uso durante a transição para os padrões mais seguros WPA ou WPA2.

Os processos de implementação de EAP-TLS e PEAP-MS-CHAP v2 têm algumas similaridades. Ambos requerem o uso de servidores RADIUS IAS da Microsoft como parte da solução e exigem certificados de alguma forma, mas o EAP-TLS requer certificados tanto do computador cliente quanto do servidor, enquanto que o PEAP-MS-CHAP v2 precisa de certificados somente para os servidores de autenticação. Esse é o motivo pelo qual uma estrutura de certificado é altamente recomendada quando se implementa o EAP-TLS, visto que o custo de se comprar certificados de provedores de terceiros para todos os clientes pode ser proibitivo.
Autenticação sem fio com EAP-TLS e PEAP-MS-CHAP v2

Os processos de implementação do EAP-TLS e do PEAP-MS-CHAP v2 envolvem vários detalhes que estão além do escopo deste documento. Entretanto, já existem vários recursos excelentes para ajudar a projetar e implementar soluções para a proteção de redes sem fio, como:

A página Implantação de redes 802.11 seguras usando o Microsoft Windows (a página pode estar em inglês) no Microsoft TechNet, que fornece informações sobre a implementação de ambas as abordagens de autenticação IEEE 802.1X, está localizada em Deploying Windows XP Service Pack 2 using Software Update Services.

O download Protegendo LANs sem fio com serviços de certificados em Download details: Securing Wireless LANs with Certificate Services fornece recursos e informações detalhadas sobre a implementação do EAP-TLS em redes Microsoft.

O download Protegendo LANs sem fio com PEAP e senhas em Download details: Securing Wireless LANs with PEAP and Passwords fornece informações detalhadas sobre a implementação do PEAP-MS-CHAP v2 em redes Microsoft.

A atualização Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Services Information Element (WPS IE) para Windows XP com SP2 em A atualização WPA2 (Wi-Fi Protected Access 2)/WPS IE (Wireless Provisioning Services Information Element) para Windows XP com Service Pack 2 está disponível é necessária ao suporte do Microsoft Windows XP com SP2 para o padrão WPA2.