Protegendo uma rede de clientes não gerenciados

[helldanger1]

Componentes de cliente da quarentena VPN

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

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

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


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

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

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

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


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

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

 

[helldanger1]

Componentes do servidor de quarentena VPN

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

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

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

Negocia a comunicação com o agente cliente.

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

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


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

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

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

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

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

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

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

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

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

 

[helldanger1]

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

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

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

EAP-MD5

EAP protegido (PEAP)

EAP-TLS


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

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

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

 

[helldanger1]

Processo de decisão do 802.1X

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

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

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

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

 

[helldanger1]

Requisitos de PEAP 802.1X

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

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

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

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

 

[helldanger1]

Usando WEP ou WPA

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

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

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

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

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


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

 

[helldanger1]

Usando SMS para detectar sistemas não gerenciados

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

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

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

 

[helldanger1]

Processo de descoberta de rede

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

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

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

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

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

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


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

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

 

[helldanger1]

Implantação e gerenciamento

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

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

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

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

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

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

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

 

[helldanger1]

Implantando o IPsec por diretiva

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

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

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

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

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

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

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

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

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


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

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

 

[helldanger1]

Considerações sobre o gerenciamento IPsec

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

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

Classificação da alteração

Autorização da alteração

Plano de desenvolvimento da alteração

Plano de liberação da alteração

Análise da alteração


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

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

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

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

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



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

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

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

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

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

 

[helldanger1]

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

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

Criar recursos de quarentena.

Criar scripts para validar configurações de cliente.

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

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

Distribuir os perfis CM aos computadores clientes de acesso remoto.

Configurar a diretiva de acesso remoto por quarentena.

1. Criar recursos de quarentena

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

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

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

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

 

[helldanger1]

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

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

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

Clique em Iniciar e em Painel de controle.

Clique em Adicionar ou remover programas.

Clique em Adicionar/Remover Componentes do Windows.

Selecione Componentes e clique em Serviços de rede.

Clique em Detalhes.

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


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

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

 

[helldanger1]

4. Criar perfis CM de quarentena

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

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

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

5. Distribuir perfis CM

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

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

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

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

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


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

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

 

[helldanger1]

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

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

WPA2/AES e EAP-TLS

WPA2/AES e PEAP-MS-CHAP v2

WPA/TKIP e EAP-TLS

WPA/TKIP e PEAP-MS-CHAP v2


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

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

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

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

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

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

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

 

[helldanger1]

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 Microsoft Solution Accelerators ou a home page do Microsoft Systems Management Server (em inglês) em Systems Management Server Home para obter mais links, inclusive links para recursos sobre soluções de script do SMS.

 

[helldanger1]

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.

 

[helldanger1]

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.

fonte:technet