Exportar (0) Imprimir
Expandir Tudo
Expandir Minimizar

Protegendo uma rede de clientes não gerenciados

Nesta página

Publicado em: 29 de agosto de 2006

Introdução
Definição
Desafios
Soluções
Resumo
Apêndice A: Proteção de Acesso à Rede

Introdução

Bem-vindo a este documento da coleção Orientações de segurança para empresas de médio porte. A Microsoft espera que as informações a seguir o ajudem a criar um ambiente de computação mais seguro e produtivo.

Sinopse

No ambiente preocupado com a segurança de hoje, uma abordagem aprofundada à proteção da rede das empresas de médio porte e dos dados nela residentes é uma questão muito complexa. Não basta mais confiar em defesas de perímetro e conjuntos antivírus por si sós para proteger os ativos de rede e as informações confidenciais. As organizações e os profissionais de segurança agora entendem que os riscos internos à rede, sejam intencionais ou acidentais, têm o potencial de ser ainda mais perigosos do que as ameaças externas.

Para eliminar o grande número de vulnerabilidades que representam riscos às empresas de médio porte, investimentos significativos de tempo e recursos foram feitos em áreas como gerenciamento de patches, soluções antimalware e iniciativas de gerenciamento de identidade. Para garantir que tais investimentos sejam usados universalmente na empresa e para maximizar a eficácia do investimento, a empresa precisa encontrar maneiras de fazer cumprir com eficiência as suas diretivas de segurança.

Computadores não autorizados são sistemas que não são considerados riscos substanciais porque não há como determinar se eles cumprem as diretivas de segurança estabelecidas. Computadores não autorizados podem representar um problema para administradores de sistema e profissionais de segurança. Sistemas sem conformidade apresentam diversos riscos, desde sua vulnerabilidade a infecção por malware até a possibilidade de serem plataformas potenciais para um ataque. Tradicionalmente, sempre foi difícil gerenciá-los e torná-los compatíveis.

Este documento discute alguns métodos eficazes que podem ser usados para ajudar a fazer cumprir a conformidade com diretivas de segurança. Esta abordagem maximiza os benefícios dos esforços de gerenciamento do risco e acrescenta uma camada extra de segurança às redes das empresas de médio porte que ajudará a reduzir os riscos associados aos computadores não confiáveis e não gerenciados.

Visão geral

Este documento consiste em quatro seções principais que concentram-se em detalhes para ajudar o leitor a compreender melhor os conceitos e princípios associados à proteção da rede de uma empresa de médio porte de computadores não gerenciados. Essas quatro seções principais estão resumidas a seguir:

Introdução

Esta seção fornece uma sinopse do documento, assim como uma visão geral da estrutura do documento e algumas informações relativas ao seu público-alvo.

Definição

Esta seção fornece alguns detalhes e definições que serão úteis à compreensão das soluções discutidas no documento.

Desafios

Esta seção descreve alguns dos problemas comuns enfrentados por uma empresa de médio porte ao determinar como ajudar a se proteger contra computadores não gerenciados e não confiáveis. Ela funciona como um plano de fundo geral dos problemas abordados por este documento.

Soluções

Esta seção discute soluções que ajudam a abordar os desafios apresentados por computadores não gerenciados por meio da avaliação de possíveis abordagens e da discussão de problemas relacionados ao desenvolvimento de planos para a solução do problema. Ela também fornece algumas informações sobre métodos de implantação e gerenciamento.

Quem deve ler este guia

Este documento técnico destina-se a ajudar os profissionais de tecnologia e os gerentes técnicos a compreender e tomar decisões informadas sobre como ajudar a proteger a rede de uma empresa de médio porte contra as ameaças apresentadas por dispositivos não gerenciados. Ainda que o público não técnico possa usar este documento para compreender melhor este problema de segurança específico, o conhecimento básico dos seguintes itens é útil à compreensão total e à aplicação do assunto discutido neste documento.

As tecnologias específicas discutidas incluem:

  • Autenticação IEEE 802.1X

  • Diretivas IPsec

  • Segurança de rede

  • Microsoft® Systems Management Server 2003

  • Microsoft Windows Server™ 2003

  • Serviço de diretório do Active Directory®

  • Microsoft Operations Management Server

  • Microsoft IAS (Serviço de autenticação da Internet)

  • Autenticação RADIUS


Definição

Este guia foi projetado para usar o modelo de processo MOF (Microsoft Operations Framework), além das funções de gerenciamento do serviço (SMFs) de Administração de Segurança MOF.

Em especial, as soluções apresentadas neste documento recomendam o uso de uma abordagem de processo contínuo, em vez de uma abordagem de implantação linear, para ajudar a melhorar a segurança da rede contra ameaças apresentadas por computadores não gerenciados.

Especificamente, a aplicação dessas soluções deve implicar nas etapas mostradas na seguinte figura:


Figura 1. Aplicando MOF

Figura 1. Aplicando MOF

Como mostra a figura, quaisquer respostas aos problemas de segurança apresentados por sistemas não gerenciados devem ser processos contínuos de teste e ajuste, e não apenas questões de planejamento e implantação. As ameaças que podem afetar a rede de uma empresa de médio porte estão sempre mudando, e os sistemas que protegem a rede de uma empresa precisam se adaptar continuamente a tais ameaças.

A aplicação das soluções discutidas neste documento atende à SMF de Gerenciamento de Segurança, descrita a seguir:

  • Avaliar a exposição da empresa e identificar os ativos a serem protegidos.

  • Identificar maneiras de reduzir os riscos apresentados por dispositivos não protegidos em níveis aceitáveis.

  • Desenvolver um plano para atenuar os riscos à segurança.

  • Monitorar a eficiência dos mecanismos de segurança.

  • Reavaliar a eficácia e os requisitos de segurança periodicamente.


Para obter mais informações sobre o MOF, consulte o site Microsoft Operations Framework no Microsoft TechNet, em www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx.

Para obter mais informações sobre a SMF de Gerenciamento de Segurança, consulte a página Funções de gerenciamento de segurança, disponível em http://go.Microsoft.com/fwlink/?LinkId=37696.

O gerenciamento de riscos é o processo de determinação do nível de risco aceitável para uma organização, de avaliação dos riscos atuais, da descoberta de maneiras de atingir o nível de risco aceitável e do gerenciamento de riscos. Embora este documento lide com alguns conceitos de gerenciamento de riscos, uma discussão aprofundada é um assunto independente que merece um foco dedicado. Para obter mais informações sobre a análise e a avaliação de riscos, consulte o Guia de Gerenciamento de Riscos de Segurança em http://go.Microsoft.com/fwlink/?LinkId=30794.


Desafios

Alguns dos desafios envolvidos na proteção contra computadores não gerenciados incluem:

  • Como evitar que computadores não gerenciados acessem recursos da rede.

  • Como manter computadores móveis em conformidade com atualizações e diretivas.

  • Como fazer cumprir diretivas de segurança estabelecidas em computadores que se conectam remotamente à rede.

  • Como proteger uma rede contra dispositivos sem fio não autorizados.

  • Como detectar sistemas não gerenciados, como laptops de fornecedores ou dispositivos pessoais, quando eles se conectam à rede.

  • Como se proteger contra outros dispositivos móveis, como PCs de mão ou de bolso.


Soluções

A seção "Desafios" relacionou vários fatores a considerar para proteção contra as ameaças que computadores não autorizados representam para uma rede. Além de defender a rede cabeada interna tradicional, deve-se também adotar medidas para ajudar a proteger a rede sem fio e quaisquer caminhos de acesso remoto. Para abordar todas as maneiras possíveis para um computador não autorizado se conectar a uma rede, a solução precisa ter escopo abrangente.

As discussões na seção a seguir tratam os desafios listados, lidando com as seguintes abordagens:

  • Uso do domínio IPsec e do isolamento de servidor para evitar que computadores não gerenciados acessem os recursos da rede.

  • Uso da quarentena VPN para fazer cumprir as diretivas de segurança em computadores que se conectam remotamente à rede.

  • Uso da autenticação 802.1X para se proteger contra dispositivos sem fio não confiáveis.

  • Uso de SMS para detectar computadores não gerenciados quando estes se conectam à rede.


Observação   Este documento parte do princípio de que o leitor já implementou processos para garantir que computadores membros residentes nas estruturas de domínio da empresa de médio porte estejam em conformidade com quaisquer requisitos de segurança e patches estabelecidos, e que está pesquisando métodos para fazer cumprir a conformidade e proteger-se contra dispositivos sem conformidade. Está além do escopo deste documento discutir como fazer com que os computadores sejam compatíveis ou como usar mecanismos de atualização de segurança automáticos, como WSUS ou os recursos de gerenciamento de patches do SMS.

Avaliação

Esta seção apresenta algumas respostas potenciais para ajudar a abordar o problema apresentado por computadores não gerenciados às empresas de médio porte. Ela também discute algumas das decisões que precisam ser tomadas antes da escolha de qualquer uma dessas respostas. Qualquer das respostas discutidas ajudará a melhorar o nível de segurança da rede de uma empresa de médio porte. No entanto, quando implementadas como parte de uma abordagem abrangente de defesa em profundidade, as respostas combinadas criam uma resposta mais sofisticada aos problemas discutidos na seção "Desafios".

Usando IPsec para isolar domínios e servidores

O isolamento físico de computadores e redes não é uma idéia nova. Ele vem sendo praticado de muitas maneiras ao longo dos anos, geralmente onde redes de desenvolvimento e de teste estão envolvidas. Entretanto, as abordagens de isolamento físico mais antigas não se aplicam bem à tarefa de proteger sistemas gerenciados de dispositivos não gerenciados potencialmente comprometidos. Isso é verdadeiro especialmente nos ambientes de rede de empresas modernas, onde a computação móvel está aumentando seu domínio e a demanda por soluções automatizadas e flexíveis é crescente. A tabela a seguir descreve os métodos comuns de isolamento físico que eram usados no passado, assim como as dificuldades associadas ao seu uso nesta capacidade.

Tabela 1. Abordagens ao isolamento da rede

Camada OSI

Abordagem

Problemas

Camada 1

Usar cabos separados para segmentos que precisam ser isolados da rede confiável.

  • Custos associados ao uso de novos cabos para cada nova conexão.

  • Aumento da sobrecarga administrativa para gerenciar o abandono de novos cabos para movimentação de usuários.

  • Falta de flexibilidade e dificuldade de gerenciamento à medida em que a empresa cresce.

  • Probabilidade crescente de omissão e erro devido aos altos requisitos de gerenciamento.


Camada 2

Usar VLANs para criar sub-redes lógicas isoladas da rede confiável.

  • Aumento do custo associado à atualização das estruturas de switch para oferecer suporte às VLANs.

  • Maior sobrecarga administrativa para controle de mudanças na rede, movimentação de usuários e resposta a solicitações de conexão de convidados.

  • Passível de omissão e erro quando várias movimentações de usuário ocorrem ou quando dispositivos móveis são usados.



Como essa tabela demonstra, a rede da empresa moderna requer uma solução mais flexível para ajudar a fazer cumprir a conformidade com os padrões de segurança que ajudam a proteger contra sistemas não gerenciados. Apesar de haver algumas soluções de terceiros para o problema, elas envolvem instalações do lado do cliente em todas as estações de trabalho gerenciadas e adicionam uma camada de complexidade à rede. Felizmente, as versões atuais do Microsoft Windows têm uma funcionalidade incorporada que ajuda a solucionar esse problema sem a necessidade de instalação de softwares adicionais e de curvas de aprendizado administrativo.

O isolamento de servidor e domínio da Microsoft permite aos administradores de TI restringir as comunicações TCP/IP aproveitando a Diretiva de Grupo e o IPsec incorporados do Active Directory, o que resulta nos seguintes benefícios:

  • Usa a camada da rede do modelo OSI, o que significa que pode se expandir pelos limites de switch e roteador.

  • Independente das estruturas de switch e das limitações físicas da rede.

  • Reduz o custo por aproveitar os recursos de autenticação incorporados dos computadores baseados em Windows.

  • É automatizado e não requer a manutenção constante associada a mudanças na rede e à movimentação de usuários.

  • Fornece a capacidade não apenas de autenticar computadores confiáveis, mas também de criptografar as comunicações entre sistemas confiáveis.

  • Faz cumprir diretivas de segurança recusando conexões de dispositivos não gerenciados.

  • Auditoria e gerenciamento de recursos aprimorados.

  • Capacidade de isolar rapidamente recursos específicos na ocorrência de um ataque.


As preocupações típicas em relação ao uso do IPsec para proteger comunicações foram abordadas por recentes desenvolvimentos em resposta a tais problemas. Especificamente, NAT (Conversão de Endereço de Rede) não é mais uma preocupação devido aos recursos de passagem de NAT disponíveis nas versões atuais do Microsoft Windows, como Windows Server 2003 e Microsoft Windows XP com Service Pack 2 (SP2). Além disso, o suporte para plataformas não compatíveis com IPsec é possível via listas de isenção configuráveis e/ou uma exceção de retorno para permitir a comunicação em texto não criptografado com tais sistemas.

Soluções de isolamento de domínio e servidor, conforme apresentadas neste documento, são usadas até mesmo na própria rede interna da Microsoft. Além de recomendar essas soluções aos clientes, a Microsoft depende do nível adicional de segurança fornecido por esta solução e tem um compromisso de longo prazo de oferecer suporte a este método de tornar as redes altamente seguras e gerenciáveis a fim de proporcionar uma computação confiável.

Entendendo o isolamento de domínio e servidor

Em poucas palavras, a criação de uma rede isolada envolve a separação de vários tipos de computadores na rede de uma empresa, de acordo com o tipo de acesso que devem ter. Neste caso, os vários tipos estão em dois conjuntos: gerenciados e não gerenciados. Duas condições básicas devem ser atendidas a fim de se atingir um nível funcional de isolamento de rede. Essas condições são:

  • Os computadores que residem na rede isolada podem iniciar uma comunicação com todos os computadores de toda a rede, inclusive com aqueles que residem fora da rede confiável.

  • Os computadores que residem fora da rede isolada podem iniciar uma comunicação somente com outros computadores de fora da rede confiável. Eles não podem iniciar uma comunicação com computadores localizados dentro da rede confiável.


O isolamento de servidor e domínio IPsec aproveita estruturas de domínio existentes usando configurações de Diretiva de Grupo. Tudo o que é necessário à criação de uma rede isolada já existe em computadores que usam Windows XP, Windows 2000 Server ou Windows Server 2003. Quando as configurações necessárias de Diretiva de Grupo tiverem sido definidas, o processo de inserção de um novo computador na rede isolada envolve simplesmente a adição desse computador ao domínio.


Figura 2. Isolamento de rede usando domínios do Active Directory

Figura 2. Isolamento de rede usando domínios do Active Directory

Conforme ilustrado na figura anterior, qualquer computador que não seja membro do domínio é considerado não confiável e, portanto, reside fora da rede isolada. Qualquer sistema que resida fora da rede isolada não pode iniciar uma comunicação IPsec e, portanto, não pode estabelecer uma conexão com nenhum sistema localizado dentro do domínio isolado. Entretanto, os membros do domínio isolado estão livres para estabelecer uma comunicação em texto não criptografado com os dispositivos de fora da rede isolada.

Obviamente, muitas organizações têm computadores e servidores que, ainda que gerenciados e confiáveis, não existem em um domínio do Active Directory ou não podem usar o IPsec por diversos motivos, mas ainda assim têm uma necessidade comercial de se comunicar com sistemas localizados dentro da rede isolada. Para solucionar esse dilema, outro grupo isolado (ou grupo de limite) pode ser criado usando-se listas de isenção, conforme mostrado na figura a seguir.


Cc875843.PNFUC03(pt-br,TechNet.10).gif

Figura 3. Isolamento de rede e grupos de limite

Um modelo de isolamento de rede como este possibilita ajudar a reduzir o monitoramento de segurança de uma rede comercial. No entanto, esta solução por si só não pode garantir que os sistemas confiáveis permaneçam em conformidade com os padrões que os tornam confiáveis. Esta não é uma solução de segurança de rede abrangente por si só. Ela é uma parte útil de um processo de segurança maior que, em conjunto com outras soluções, pode ajudar a reduzir os riscos enfrentados pela rede de uma empresa de médio porte. Especificamente, quando usada com outras soluções de segurança, como WSUS, SMS, MOM, entre outras, é possível usar este método de isolamento para ajudar a fazer cumprir a conformidade com a diretiva de segurança na rede isolada.

Outras soluções de segurança baseadas no Active Directory possibilitam a automação de tarefas que ajudam a garantir a conformidade contínua com a diretiva de segurança na rede isolada confiável. No entanto, um grupo de limite dependerá de diferentes métodos para garantir que os computadores nessa rede não se tornem pontos fracos na solução de rede isolada. Tais computadores precisam ser validados como sendo compatíveis antes de serem adicionados ao grupo de limite, e precisam ter diretivas e métodos específicos associados que garantam sua conformidade contínua com os requisitos de diretiva de segurança para sistemas confiáveis.

Entendendo o IPsec

IPsec é um padrão de segurança do Protocolo de Internet que oferece um mecanismo geral de segurança da camada IP baseado em diretiva que é ideal para o fornecimento de autenticação host a host. Diretivas IPsec são definidas de modo a ter regras e configurações de segurança que controlam o fluxo do tráfego de entrada e de saída em um sistema de host. Essas diretivas são gerenciadas centralmente no Active Directory por meio de objetos de Diretiva de Grupo (GPOs) para atribuição de diretivas a membros do domínio. Elas proporcionam a capacidade de ajudar a estabelecer comunicações seguras entre membros do domínio, o que consiste na base desta solução.

O IPsec usa o protocolo de negociação IKE (Internet Key Exchange) para negociar opções entre dois hosts e determinar como se comunicar de maneira segura com o IPsec. Os acordos feitos entre dois hosts e os vários parâmetros que definem esse método de negociação são chamados associações de segurança ou SAs. O Microsoft Windows pode usar um dos três métodos IKE a seguir:

  • Protocolo de autenticação Kerberos versão 5

  • Certificados digitais X.509 com pares de chaves RSA correspondentes

  • Chaves pré-compartilhadas usando frases secretas


Observação   Embora o PKI possa ser usado como um método de autenticação, a integração com a autenticação de domínio do Windows 2000 (Kerberos) no protocolo de negociação IKE torna o PKI uma abordagem não recomendada.

A negociação IKE do Windows pode ser configurada para permitir a comunicação com computadores que não respondam à solicitação de negociação IKE. Essa funcionalidade é chamada retorno para limpo e, além de ser essencial durante um desenvolvimento, ela também é útil neste contexto porque permite que sistemas no grupo de limite se comuniquem com membros da rede isolada. Qualquer comunicação que não possa ser protegida pelo IPsec é denominada uma associação de segurança temporária e é registrada como um evento bem-sucedido de auditoria no Log de segurança.

O IPsec pode desempenhar outras funções úteis além da autenticação, inclusive a capacidade de tratar a integridade e a criptografia do tráfego da rede usando as opções AH (Authentication Header) e ESP (Encapsulating Security Payload). Ainda que os AHs possam ser usados para ajudar a garantir que um pacote não tenha sido modificado em trânsito, o uso de cabeçalhos para executar essa tarefa a torna incompatível com a NAT (Conversão de Endereço de Rede). O ESP, normalmente usado para criptografar tráfego, pode ser usado no modo de criptografia nula (ESP/nulo), o que permite uma verificação da integridade de dados compatível com NAT.

O IPsec também pode funcionar em dois modos diferentes: transporte ou túnel. O modo de transporte IPsec é o método recomendado para proteger o tráfego entre dois hosts. Ele funciona pela simples inserção de um cabeçalho após o cabeçalho IP original e, então, pela criptografia do restante do pacote com AH ou ESP. O modo de túnel é normalmente usado para túneis VPN de gateway a gateway em que os pacotes originais e os cabeçalhos IP são encapsulados totalmente e um novo cabeçalho IPsec substitui o cabeçalho IP original.

Para obter mais informações, consulte a página Isolamento de servidor e domínio da Microsoft (a página pode estar em inglês) em www.microsoft.com/technet/itsolutions/network/sdiso/default.mspx.

Defesa em profundidade


Figura 4. Modelo de defesa em profundidade com isolamento lógico

Figura 4. Modelo de defesa em profundidade com isolamento lógico

A figura anterior demonstra como o isolamento lógico se ajusta ao modelo de defesa em profundidade. Embora o isolamento de domínio e servidor pareça concentrar-se na proteção do computador host, como faria um firewall baseado em host, ele reside no território das comunicações de rede com seu uso do IPsec. Embora esta solução abarque a lacuna entre o host e a rede interna, ela não reside inteiramente em nenhum dos dois conjuntos por ser uma solução de ‘isolamento lógico’. Portanto, a seguinte funcionalidade está fora de seu escopo:

  • O isolamento lógico não pode proteger dispositivos de rede, como roteadores.

  • O isolamento lógico não pode proteger links de rede, como o que WPA 802.11i faz para criptografia sem fio e EAP-TLS 802.1x faz para controle de acesso sem fio.

  • O isolamento lógico não pode oferecer segurança para todos os hosts na rede, porque regula somente os sistemas com uma credencial de máquina confiável e uma diretiva IPsec baseada em domínio.

  • O isolamento lógico não se ajusta bem e não tem um método automaticamente configurável que possa proteger o caminho no nível do aplicativo, como faz o HTTPS e o SSL para os aplicativos da Web.


É importante compreender e levar em consideração o papel que o isolamento lógico desempenha em uma solução abrangente de defesa em profundidade. Por si só, essa solução não pode proteger todos os aspectos da infra-estrutura de uma empresa de médio porte. No entanto, quando usada como parte de uma solução abrangente, ela pode desempenhar um papel muito valioso.

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

Sistemas remotos que usam soluções VPN para acessar uma rede comercial apresentam problemas únicos de uma perspectiva de diretiva de segurança. A maioria das soluções de acesso remoto somente valida as credenciais de um usuário remoto, mas não verifica se o computador remoto está em conformidade com as diretivas de segurança. Esta abordagem de validação é um problema porque potencialmente nega os esforços de proteção da rede contra ameaças associadas a problemas como arquivos com assinatura antimalware desatualizada, níveis de atualização de segurança desatualizados, configurações de roteamento incorretas e falta de proteção de firewall adequada.

O Network Access Quarantine Control baseado no Microsoft Windows Server 2003 ajuda a eliminar esse problema atrasando o acesso remoto a uma VPN até que o estado da configuração do computador que está se conectando possa ser verificado como estando em conformidade com os padrões de diretiva de segurança atuais.

Entendendo os Serviços de Quarentena VPN

O Network Access Quarantine Control é um recurso fornecido com a família Windows Server 2003 que atrasa os serviços de acesso remoto normais até que os computadores que estão se conectando remotamente sejam examinados e validados por um script configurado pelo administrador. Normalmente, quando uma sessão remota é iniciada, o usuário é autenticado e o computador remoto recebe um endereço IP. A essa altura, porém, a conexão é colocada no modo de quarentena, em que o acesso à rede é limitado até que o script fornecido pelo administrador seja executado no computador remoto. Depois que o script tiver sido executado e tiver notificado o servidor de acesso remoto que o computador remoto está em conformidade com as diretivas de rede configuradas, o modo de quarentena é removido e o acesso à rede é concedido ao computador remoto.

Enquanto uma conexão remota está no modo de quarentena, as seguintes restrições podem se aplicar a ela:

  • Um conjunto de filtros de pacote de quarentena pode ser configurado para restringir o tipo de tráfego que o cliente pode iniciar ou receber.

  • Um timer de sessão em quarentena pode ser configurado para restringir o período em que um cliente pode permanecer conectado enquanto no modo de quarentena.


O Network Access Quarantine Control pode ser usado como parte de uma solução de segurança abrangente que auxilia no cumprimento das diretivas de segurança e ajuda a garantir que sistemas não confiáveis não possam se conectar a uma rede confiável. Entretanto, ele não é uma solução de segurança por si só e não pode evitar conexões de usuários mal-intencionados que obtiveram um conjunto válido de credenciais.

Observação   O Network Access Quarantine Control não é o mesmo que a NAP (Proteção de Acesso à Rede), uma nova plataforma de cumprimento de diretiva que será incluída na família de sistemas operacionais Windows Server Longhorn, a ser lançada em breve. Para obter mais informações sobre a NAP, consulte o "Apêndice A: Proteção de Acesso à Rede" no final deste documento.

Componentes do Network Access Quarantine Control


Cc875843.PNFUC05(pt-br,TechNet.10).gif

Figura 5. Componentes do Windows Network Access Quarantine Control

A figura anterior ilustra os componentes típicos de uma solução de acesso remoto do Windows que usa o Network Access Quarantine Control. Esses componentes incluem:

  • Cliente de acesso remoto compatível com quarentena. Este componente é um computador que executa uma versão do Windows capaz de oferecer suporte a perfis CM criados com o Kit de Administração do Gerenciador de Conexões (CMAK), fornecido com o Windows Server 2003. As versões do Windows que oferecem esse suporte incluem Windows 98 Second Edition e mais recentes. Esses computadores clientes precisam ter um componente notificador instalado, um script dos requisitos de diretiva de rede e estar configurado para executar o script como uma ação pós-conexão.

  • Servidor de acesso remoto compatível com quarentena. Este componente é um computador com Windows Server 2003 executando o Roteamento e acesso remoto, que oferece suporte ao uso de um componente de escuta, aos atributos específicos ao fornecedor (VSAs) de RADIUS MS-Quarantine-IPFilter e MS-Quarantine-Session-Timeout, além de um componente de escuta instalado.

  • Servidor RADIUS compatível com quarentena. Este componente é opcional e é usado quando a autenticação RADIUS é configurada no servidor de acesso remoto que executa Windows Server 2003 e IAS para oferecer suporte aos VSAs de RADIUS MS-Quarantine-IPFilter e MS-Quarantine-Session-Timeout.

  • Recursos de quarentena. Esses componentes são os servidores e serviços que podem ser acessados pelo cliente remoto enquanto no modo de quarentena. Normalmente, eles consistem em servidores que fornecem serviços DNS, perfis CM ou provedores de atualizações de segurança para atualizar os clientes.

  • Banco de dados de contas. Normalmente, este componente é o domínio Active Directory onde a conta do usuário remoto está armazenada e onde as propriedades de discagem estão localizadas.

  • Diretiva de acesso remoto por quarentena. Esta diretiva é necessária para fornecer as condições necessárias à ocorrência de conexões por acesso remoto e para especificar os atributos MS-Quarantine-IPFilter ou MS-Quarantine-Session-Timeout.


Defesa em profundidade


Figura 6. Defesa em profundidade e Network Access Quarantine Control

Figura 6. Defesa em profundidade e Network Access Quarantine Control

Como mostra esta adaptação do modelo de defesa em profundidade da Microsoft, a quarentena VPN se estende por três camadas do modelo: host, rede interna e perímetro. Embora esta solução não proteja o cliente diretamente, ela ajuda a proteger os servidores contra ameaças que poderiam ser introduzidas por clientes remotos que não cumprem com as orientações de segurança. Ela também protege os clientes remotos indiretamente por garantir que eles cumpram com os requisitos de diretiva para funcionar eficazmente, o que incentiva a manutenção das atualizações em dia.

Além disso, esta solução melhora a proteção da rede propriamente dita contra os efeitos prejudiciais que os computadores não gerenciados podem criar quando não configurados corretamente, inclusive a propagação de malware, que pode ter efeitos nocivos ao desempenho da rede. Embora o perímetro possa parecer não estar relacionado porque esta solução não evita diretamente ataques de força bruta à VPN (que reside no perímetro), ele oferece outra camada de segurança que um invasor teria que enfrentar para obter acesso direto a recursos que residem na rede interna, mesmo que tal invasor tenha obtido credenciais de autenticação.

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

O uso do padrão 802.1X do IEEE (Institute of Electrical and Electronic Engineers) ajusta-se bem à tarefa de ajudar a defender redes sem fio contra o uso não autorizado. Em poucas palavras, a menos que um computador esteja configurado para ser autorizado para comunicar-se na rede, ele simplesmente não se comunicará. Embora essa solução funcione bem em redes sem fio, ela não é tão eficaz em redes cabeadas, ainda que seja possível usar esse padrão de tal maneira. Sua eficácia limitada é o motivo pelo qual este documento prescritivo recomenda uma abordagem combinada para a proteção da rede de uma empresa de médio porte. Usando uma combinação das soluções mais eficazes que ajudam a abordar cada aspecto de uma rede comercial típica, uma solução robusta de defesa em profundidade pode ser implementada.

Entendendo a autenticação IEEE 802.1X

A autenticação IEEE 802.1X é um mecanismo de controle de acesso baseado em porta que pode ser configurado para exigir autenticação mútua entre os clientes e uma rede. Quando ela é implementada, qualquer dispositivo que falhe na autenticação não poderá participar de nenhuma comunicação com a rede em questão.

O 802.1X oferece suporte ao EAP (Protocolo de Autenticação Extensível), que tem diversas variantes, inclusive três que contam com o suporte padrão original de versões atuais do Microsoft Windows:

  • EAP-MD5. Com o MD5, um servidor de autenticação envia um desafio para um cliente (suplicante) e o suplicante combina essa solicitação de desafio com seu próprio identificador e frase secreta. Essa resposta é transformada em um hash MD5 e enviada de volta ao servidor de autenticação, que descriptografa e compara a resposta com o desafio original. Se a resposta coincidir, a autenticação acontece. Este método não é seguro na maioria das implementações porque a senha propriamente dita é enviada e pode ser interceptada e descriptografada por terceiros.

  • EAP protegido. O EAP protegido (PEAP) usa um certificado do lado do servidor e informações de autenticação do cliente (como nomes de usuário e senhas) para estabelecer a autenticação mútua. A implementação da Microsoft deste padrão usa MS-CHAPv2, que depende de informações tradicionais de senha e conta de domínio e de um servidor RADIUS para estabelecer a autenticação. Este método é geralmente considerado suficientemente seguro para ambientes menores, que não podem arcar com os requisitos administrativos e de infra-estrutura adicionais resultantes do método EAP-TLS.

  • EAP-TLS. Com este método, um servidor de autenticação configura uma sessão TLS (Transport Layer Security) com o suplicante para enviar um certificado digital para o cliente. O suplicante valida esse certificado quando recebido e envia seu próprio certificado em resposta, que, por sua vez, é validado pelo servidor de autenticação. Desde que cada lado confie no certificado do outro, a autenticação acontece. Esta abordagem se ajusta melhor a redes que podem oferecer suporte a uma infra-estrutura PKI e a servidores de autenticação RADIUS. Ela também é a opção mais segura disponível para redes sem fio, especialmente quando combinada com o uso do padrão WPA2 802.11i.


Antes da autenticação de um cliente, ele precisa confiar no autenticador (um ponto de acesso sem fio ou switch de rede) até ser autenticado pelo servidor responsável pela autenticação. Portanto, durante o handshake de autenticação inicial, toda a comunicação é encaminhada pelo autenticador entre o suplicante e o servidor de autenticação. Quando a autenticação é concluída, o suplicante pode acessar a rede diretamente.

Por que o 802.1X não é eficaz em redes cabeadas

Embora o 802.1X geralmente ajude a tratar a segurança de redes sem fio, há alguns problemas associados à implementação deste método para a proteção de redes cabeadas. O primeiro problema é que, embora o 802.1X tenha vários objetos de Diretiva de Grupo do Active Directory que oferecem suporte à sua implementação em redes sem fio, ele não oferece suporte à autenticação 802.1X em redes cabeadas. Portanto, o 802.1X exigiria uma sobrecarga considerável de gerenciamento para tal implementação. Além disso, muitos switches, dispositivos de impressão em rede e outros dispositivos de infra-estrutura em rede não oferecem suporte ao 802.1X, o que muito provavelmente implicaria em altos custos com atualizações a serem implementadas para oferecer suporte a esta implementação na maioria das redes de empresas de médio porte.

Além dos custos administrativos e de infra-estrutura associados a tal implementação, há também algumas falhas na segurança introduzidas quando este padrão voltado para ambientes sem fio é usado em redes cabeadas. Por exemplo, como a autenticação 802.1X ocorre somente quando uma conexão é estabelecida e hubs estão visíveis ao 802.1X, tudo o que um invasor precisaria fazer é conectar um hub à rede interna, juntamente com um computador autenticado e um computador “sombra” com o qual conduzir o ataque.

Observação   Essas desvantagens e vulnerabilidades específicas não afetam as redes sem fio. Esses problemas com a segurança do 802.1X ocorrem somente quando ele é usado em redes cabeadas.

Esses problemas são o motivo pelo qual o IPsec é recomendado para o isolamento de domínio e servidor em vez do 802.1X. Entretanto, essa recomendação não significa que não há lugar para o 802.1X na rede de uma empresa de médio porte. Como afirmado anteriormente, o 802.1X é uma ferramenta valiosa que ajuda a solucionar problemas de segurança sem fio e que se torna ainda mais segura com a adição de uma solução de isolamento de rede baseada em IPsec.

Defesa em profundidade


Figura 7. Defesa em profundidade com segurança sem fio 802.1X

Figura 7. Defesa em profundidade com segurança sem fio 802.1X

Como mostra a figura anterior, a segurança sem fio usando a autenticação 802.1X ocupa a camada de rede do modelo de defesa em profundidade. Embora possa parecer que a segurança sem fio também se estenderia pelo perímetro, as redes sem fio são, em realidade, uma parte da rede local, enquanto o perímetro lida mais com redes externas, como a Internet. Algumas partes dos métodos de segurança sem fio têm componentes de host, mas a segurança sem fio não foi projetada para proteger o host diretamente.

Usando SMS para detectar e corrigir sistemas não gerenciados

O Microsoft SMS (Systems Management Server) 2003 é usado com freqüência para gerenciar computadores na rede, manter informações de inventário de ativos e distribuir softwares e atualizações para manter a conformidade com as diretivas de segurança e manter a semelhança entre a instalação de software e plataforma. A funcionalidade de descoberta e inventário de rede do SMS 2003 está dentro do escopo deste documento porque fornece um método que pode ajudar a detectar sistemas não confiáveis quando eles se conectam à rede. Essa funcionalidade também oferece uma maneira de ajudar na correção, dependendo das diretivas implementadas como resposta ao uso de um computador não gerenciado.

Este documento parte do pressuposto de que o leitor já usou o SMS e outros métodos para obter a conformidade dos computadores membros do domínio com as diretivas de segurança, o que inclui estar informado sobre todas as atualizações de segurança. Portanto, discussões referentes ao gerenciamento de patches usando o SMS 2003 e outras ferramentas estão além do escopo deste documento. Para obter mais informações sobre esses tópicos, assim como outras informações relacionadas ao SMS, consulte o acelerador da solução Gerenciamento de patches usando o Systems Management Server 2003 (a página pode estar em inglês) em www.microsoft.com/technet/itsolutions/cits/mo/swdist/pmsms/2003/pmsms031.mspx ou a home page do Microsoft Systems Management Server em www.microsoft.com/smserver/default.mspx.

Descobrir e documentar ativos existentes

Para empresas que já tenham implementado o SMS, a documentação de ativos existentes provavelmente já foi concluída e o inventário dos sistemas gerenciados e não gerenciados deve estar completo. Tal inventário deve conter informações sobre os requisitos e procedimentos de atualização de segurança para computadores que não são gerenciados pelo SMS, seja devido ao projeto ou porque não são agentes em funcionamento desse tipo de cliente. Esses computadores não gerenciados podem incluir dispositivos em um perímetro de segurança (também conhecido como DMZ, zona desmilitarizada e sub-rede filtrada), computadores de teste ou dispositivos autônomos.

É importante contar com uma lista bem documentada dos dispositivos que não são gerenciados pelo SMS, não somente pelos requisitos de segurança, mas porque essa lista precisa ser comparada com quaisquer novas informações de inventário para se determinar se sistemas recentemente descobertos são autorizados ou desconhecidos. Para manter essas listas atualizadas, é importante ter um processo em uso para a adição de novos sistemas não gerenciáveis à rede comercial, o que inclui não somente as informações de identificação, mas também o processo envolvido na manutenção dos sistemas seguros, assim como atribuições de propriedade.

Embora o SMS possa não ser capaz de reunir muitas informações sobre esses sistemas não gerenciados além de um endereço IP e um nome, essas informações por si sós com freqüência bastam para determinar se novos dispositivos na rede são autorizados ou não.

Desenvolvimento

A seção "Avaliação" mostrou que uma mescla de diferentes soluções que abordam funções específicas na rede de uma empresa de médio porte é a abordagem mais abrangente para ajudar a defender essa rede. O isolamento de domínio e servidor abrange a rede cabeada para garantir que somente computadores conhecidos e gerenciados possam acessar os recursos confiáveis. A Quarentena VPN garante que sistemas remotos que se conectam apenas ocasionalmente à rede local permaneçam em conformidade com as diretivas de segurança. A autenticação 802.1X protege a rede sem fio, para que somente máquinas autorizadas possam estabelecer conexões. Finalmente, o SMS é usado para ajudar a manter os computadores confiáveis atualizados e descobrir computadores não autorizados não confiáveis quando eles se conectam à rede. Todas essas soluções se combinam para ajudar a proteger uma rede contra conexões e computadores não autorizados.

Além de discutir os requisitos para a implementação dessas soluções, esta seção também tratará alguns dos problemas potenciais que precisam ser abordados para ajudar a garantir que cada solução seja a abordagem mais apropriada para cada ambiente de empresa de médio porte.

Usando IPsec para isolar domínios e servidores

O desenvolvimento de um plano para implementar o isolamento de domínio e servidor baseado em IPsec envolve determinar se essa solução é viável ou não para um determinado ambiente de rede e reunir informações de pré-requisitos necessárias ao desenvolvimento de um plano de implementação. O conceito de isolamento de rede IPsec foi apresentado na seção "Avaliação" deste documento. Agora que os benefícios dessa abordagem são conhecidos, é possível ponderá-los em relação a quaisquer problemas possíveis que possam ser associados com a implementação. Esta seção discutirá alguns problemas da implementação do isolamento de rede baseado em IPsec, assim como os requisitos dessa implementação, a fim de ajudar o processo de tomada de decisão.

Identificando a arquitetura da rede

Visto que o IPsec é uma camada do próprio Protocolo de Internet, uma compreensão detalhada da infra-estrutura atual da rede e do fluxo do tráfego é essencial ao sucesso da implantação desta solução. Embora as informações sobre os esquemas de endereçamento IP, os layouts de sub-rede e os padrões de tráfego da rede sejam componentes importantes que devem ser identificados, uma documentação detalhada da segmentação da rede e um modelo do fluxo atual do tráfego da rede são absolutamente essenciais ao sucesso do desenvolvimento e da implantação de um plano eficaz de isolamento de rede.

Observação   Está além do escopo deste documento discutir os detalhes da documentação do ambiente de rede. A criação da documentação é vital ao sucesso de qualquer iniciativa abrangente de segurança de rede, inclusive esta. Portanto, se essa documentação não existir, a implementação efetiva de projetos como este deve ser considerada um risco exagerado até que a documentação tenha sido concluída.

A documentação da arquitetura de rede deve refletir com precisão os detalhes atuais com relação às seguintes informações:

  • Detalhes e localizações de firewalls e balanceadores de carga

  • Informações sobre dispositivos de rede, inclusive tamanho da RAM, marca/modelo e configurações de MTU

  • Relatórios de tráfego de rede e de utilização

  • Uso da NAT

  • Segmentação VLAN

  • Links de rede para dispositivos

  • Informações do IDS (sistema de detecção de invasões)


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)


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.


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.


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.

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:

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

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

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

  4. 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:


Cc875843.PNFUC08(pt-br,TechNet.10).gif

Figura 8. Processo de Quarentena VPN
  1. 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.

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

  3. 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.

  4. 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.

  5. 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.

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.

Para obter mais informações sobre o CMAK, consulte a página do Kit de Administração do Gerenciador de Conexões (a página pode estar em inglês) no Microsoft TechNet, em http://technet2.microsoft.com/WindowsServer/en/library/be5c1c37-109e-49bc-943e-6595832d57611033.mspx?mfr=true.

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.


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.

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

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.

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.

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.

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.

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

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.

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.

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 http://support.microsoft.com/?kbid=914841 e 914842, em http://support.microsoft.com/?kbid=914842.

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.


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:

  1. Criar recursos de quarentena.

  2. Criar scripts para validar configurações de cliente.

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

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

  5. Distribuir os perfis CM aos computadores clientes de acesso remoto.

  6. 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.

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 www.microsoft.com/downloads/details.aspx?FamilyID=a290f2ee-0b55-491e-bc4c-8161671b2462&displaylang=en.

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

  1. Clique em Iniciar e em Painel de controle.

  2. Clique em Adicionar ou remover programas.

  3. Clique em Adicionar/Remover Componentes do Windows.

  4. Selecione Componentes e clique em Serviços de rede.

  5. Clique em Detalhes.

  6. 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.

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.

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:


Usando SMS para detectar e corrigir sistemas não gerenciados

Conforme estabelecido na seção "Desenvolvimento", o processo de descoberta do SMS é muito útil para localizar computadores recém-conectados à rede quando eles são gerenciáveis por SMS. Também foi mencionado o fato de que o SMS tem dificuldade para descobrir alguns sistemas não gerenciáveis durante o processo de descoberta, o que demanda outro mecanismo para suprir essa falha.

Pode haver alguns motivos pelos quais o SMS pode não descobrir computadores conectados à rede. Esses motivos incluem:

  • O computador está conectado, mas não está sendo executado no momento da descoberta e não tem uma conta de computador no domínio.

  • O computador está conectado a uma sub-rede onde um firewall ou outro dispositivo de rede impede a comunicação entre o servidor SMS e essa sub-rede.

  • O computador está conectado a uma rede acessível, mas está usando um sistema operacional que não pode ser descoberto pelo SMS.


Para lidar com essas eventualidades, é necessária uma solução personalizada que combine a utilidade do SMS com scripts que abordem as exceções de forma que o SMS possa gerenciá-las. Scripts personalizados podem ser usados para verificar a rede em intervalos regulares com um processo agendador, o que significa que eles podem descobrir dispositivos que fiquem ativos por breves períodos de tempo. Tais scripts também podem ser executados de estações de trabalho ou servidores localizados em sub-redes isoladas, o que significa que eles podem detectar quando sistemas não gerenciados se conectam a esses segmentos que não contam com outro tipo de monitoramento. Esses scripts não tentam executar processos de descoberta baseados em WMI e, portanto, não são afetados pelo sistema operacional em uso nos clientes não gerenciados.

Para obter mais informações sobre como usar o SMS para descobrir dispositivos na rede, consulte o acelerador da solução Gerenciamento de patches usando o Systems Management Server 2003 (a página pode estar em inglês) em www.microsoft.com/technet/itsolutions/cits/mo/swdist/pmsms/2003/pmsms031.mspx ou a home page do Microsoft Systems Management Server (em inglês) em www.microsoft.com/smserver/default.mspx para obter mais links, inclusive links para recursos sobre soluções de script do SMS.


Resumo

Este documento mostrou que é possível usar uma abordagem abrangente para ajudar a gerenciar as preocupações associadas a sistemas não gerenciados. O isolamento de rede IPsec foi usado para ajudar a impedir que sistemas não gerenciados obtivessem acesso a recursos da rede confiável e para auxiliar no cumprimento da conformidade por meio da negação de serviço a computadores sem conformidade. Os serviços de Quarentena VPN podem ser usados para ajudar a fazer cumprir a conformidade em computadores móveis que usam uma solução de acesso remoto, mas que raramente se conectam à rede local. Os padrões IEEE 802.1X e WPA/WPA2 podem ser usados para ajudar a proteger contra dispositivos não autorizados em LANs sem fio. Finalmente, SMS e scripts de detecção podem ser usados para ajudar na detecção de sistemas não gerenciados, assim como para ajudar a manter os computadores gerenciados atualizados com todos os patches e atualizações de segurança.

Ainda que essas soluções técnicas ajudem a resolver muitos problemas associados a dispositivos não gerenciados, elas são melhoradas quando diretivas de segurança sólidas são criadas e processos rigorosos de gerenciamento de alterações são estabelecidos. Quando todas essas soluções, diretivas e processos são combinados, o resultado é uma infra-estrutura gerenciável de empresa de médio porte que pode reduzir os custos administrativos e reduzir os riscos à segurança a níveis aceitáveis.


Apêndice A: Proteção de Acesso à Rede

A Proteção de Acesso à Rede (NAP) é um novo recurso que fará parte da nova geração do Windows (Microsoft Windows Server Longhorn e Windows Vista™) e que ajudará a fazer cumprir a conformidade com as diretivas de integridade do computador. Com a NAP, os administradores podem definir limites de diretiva de validação de integridade por meio de uma interface de programação de aplicativo (API) que limite o acesso à rede para computadores que não cumpram os requisitos de integridade quando se conectam à rede.

A flexibilidade da NAP permite aos administradores configurar soluções personalizadas para os requisitos de seu ambiente, seja para simplesmente registrar em log o estado de integridade dos computadores que se conectam à rede, para distribuir automaticamente atualizações de software ou para limitar a conectividade dos sistemas que não cumpram os requisitos de integridade. Além disso, a NAP é suficientemente flexível para permitir a incorporação a aplicativos de terceiros e soluções de programas personalizadas, de forma que o cumprimento das diretivas de integridade dos computadores seja abrangente. A NAP também será abrangente. Seus componentes de aplicação permitirão aos administradores forçar a conformidade com diretivas de integridade via DHCP, VPN e redes sem fio 802.1X. Além disso, ela será compatível com IPsec.

Para obter mais informações sobre a NAP, consulte sua home page em Proteção de Acesso à Rede (a página pode estar em inglês), em www.microsoft.com/technet/itsolutions/network/nap/default.mspx.



Download

Obtenha o documento Protegendo uma rede de clientes não gerenciados


Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2014 Microsoft