Protegendo domínios do Active Directory em uma rede potencialmente hostil

Question

O Active Directory é um dos melhores recursos do Windows Server, mas também é um grande alvo brilhante. Se comprometida, o invasor passa a usar sua rede do Windows.

Em um ambiente com servidores Windows voltados para o exterior (servidores da web no meu caso), quais etapas são necessárias para proteger o Active Directory contra ataques? Como você reduz o dano potencial se um membro do domínio for comprometido? Finalmente, existe alguma maneira de reduzir o potencial de dano se um controlador de domínio estiver comprometido?

Estou procurando informações relacionadas especificamente ao Active Directory (2003 e 2008). Práticas recomendadas universais (ler seus registros, senhas seguras de Administrador, etc.) devem ser fornecidas.

    

Answer 1

• Não faça login em qualquer máquina em sua rede com um administrador de domínio ou uma conta com privilégios semelhantes, exceto para seus DCs. Dessa forma, um sistema comprometido não pode roubar suas credenciais.

• Tenha uma conta privilegiada separada para gerenciar suas máquinas voltadas para a Web.

• Tenha um firewall de nível de rede restrito em suas máquinas voltadas para a Web, se possível.

• Tenha suas máquinas voltadas para a Web em uma DMZ, se possível - que é basicamente apenas uma sub-rede com conectividade limitada para o resto de sua rede interna.

• Se um controlador de domínio estiver comprometido ... a rigor, seu domínio desapareceu e precisa ser reconstruído. Mais praticamente depende do tipo de compromisso e é algo que você teria que avaliar caso a caso. Eu herdei dois domínios estritamente falando "comprometidos", reconstruí um e consertei o segundo. Há muitos fatores a serem considerados.

Answer 2

Aqui estão os métodos gerais que uso. Espero poder acrescentar muito a estes:

• Os controladores de domínio estão em seu próprio segmento de rede. Todo o tráfego de ou para os controladores de domínio deve passar pelo firewall da rede.

• Os controladores de domínio não executam serviços acessíveis externamente.

• Os intervalos de porta RPC são restritos em todos os controladores / membros de domínio para um grupo conhecido de portas:

  1. Ferramentas administrativas - > Serviços de componentes - > Serviços de componentes - > Computadores
  2. Meu computador - > Propriedades - > Protocolos Padrão - > TCP / IP orientado a conexão - > Propriedades
  3. Adicionar
  4. Defina o intervalo de portas (algo como 6051-6071). Quanto maior a sua rede e quanto mais você usar o RPC, maior será o intervalo necessário. Para uma rede de 25 a 30 máquinas Windows, descobri que 20 portas são mais do que suficientes.
  5. Defina a atribuição de intervalo de portas e a alocação de porta dinâmica padrão como "Intervalo de Internet"
  6. OK
  7. Reinicializar

• Permitir aos membros do domínio apenas o seguinte acesso ao Controlador de Domínio (no firewall da rede, no firewall do host do Controlador de Domínio e no firewall do host do Membro do Domínio - use a Diretiva de Grupo para impor isso):

  • Porta TCP / UDP 53 (DNS)
  • Porta TCP / UDP 88 (Kerberos)
  • Porta UDP 123 (NTP)
  • Porta TCP / UDP 135 (mapeador de pontos finais RPC)
  • Porta TCP / UDP 137 (NetBIOS)
  • Porta UDP 138 (NetBIOS)
  • porta TCP 139 (NetBIOS)
  • porta TCP / UDP 389 (LDAP)
  • Porta TCP / UDP 445 (SMB sobre IP)
  • Porta TCP 3268 (Catálogo Global LDAP)
  • Porta TCP / UDP 6051-6071 (RPC - substitua o intervalo que você escolheu acima)

• Defina a Política IPSec para que todo o tráfego do Controlador de Domínio para o Controlador de Domínio seja criptografado por fio

• Use a Diretiva de Grupo para reforçar regras de firewall de rede no firewall do host. Especificamente:

  • Restringir a área de trabalho remota às suas estações de trabalho / rede administrativas
  • Restringir o SNMP ao seu administrador e monitorar as estações de trabalho / rede
  • Restringir o syslog de saída (eu uso o event-to-syslog) para o seu servidor de log
  • Restringir o SMTP de saída ao seu servidor de e-mail
  • O padrão "restringir tudo para dentro / fora para apenas o que o servidor requer" tática

• Configure todos os serviços de rede para serem executados como usuários do Active Directory (aplicativos do IIS executados em usuários denominados "svc-servicename"). Esses usuários são atribuídos a um único grupo com privilégios nerfizados e removidos do grupo Usuários do Domínio.

• Renomeie a conta de Administrador para outra coisa, adicione "Administrador" como uma conta de convidado desativada (trivial a ser superada, mas pode bloquear alguns scripts burros).

• Os servidores voltados externamente estão em um domínio separado das máquinas HQ / Office. Eu tenho uma relação de confiança unidirecional (DMZ confia no HQ) para simplificar alguns logins, mas estou tentando eliminar isso gradualmente.

Answer 3

Um documento de práticas recomendadas da Microsoft que eu li uma vez sugeriu que seus servidores voltados para a Internet (Web, e-mail, etc.) deveriam ser máquinas independentes ou estar em uma floresta separada do Active Directory de sua floresta corporativa. Essa floresta separada deve existir inteiramente em uma DMZ, enquanto sua floresta corporativa da AD deve existir inteiramente dentro dos limites mais rígidos do seu firewall corporativo. Muito menos usuários precisam de acesso a servidores voltados para a Internet do que a recursos regulares de computação corporativa, portanto, a configuração de um sistema dessa maneira não deve impor uma sobrecarga administrativa extra significativa em termos de suporte ao usuário. Você só precisa lembrar seus nomes de usuário e senhas separados para cada domínio.

    

Answer 4

Esta é uma visão um tanto contrária. Eu trabalho em um ensino superior com um segmento de LAN sem fio que os alunos (e em algum lugar entre um a três dispositivos em suas malas) podem se conectar. Isso está dentro do nosso firewall de borda da Internet, mas ainda é protegido, em certa medida, pela suculenta bondade da rede maior. No entanto, existem algumas restrições.

Para permitir a impressão de alunos de seus laptops, temos que permitir logins de domínio que, por sua vez, exigem visibilidade dos DCs. O mesmo vale para os compartilhamentos de rede. Além disso, os laptops dos alunos não são controlados e não temos nenhum tipo de controle sobre o que está neles.

Quando cheguei aqui, fiquei surpreso que uma rede Windows tão aberta pudesse sobreviver . Mas aconteceu. Sim, Slammer era uma dor real para erradicar. Sim, nós tivemos o servidor hackeado ocasional (do lado da Internet, não do lado da WLAN). Em suma, a quantidade de mal-intencionados que vimos na WLAN está mais interessada em enviar grandes quantidades de e-mails do que em escanear tudo o que é local para a máquina.

Nós temos uma barreira de autenticação entre a WLAN e qualquer coisa interessante, o que ajuda.

Além disso, estamos sempre indo para os logs de login da WLAN para ver quem estava em qual IP quando a RIAA nos envia um aviso de infrator para um torrenter.

    

Answer 5

Eu recomendaria a leitura do Guia de Boas Práticas para Proteger as Instalações do Active Directory .

Coisas que considero importantes em uma rede não confiável:

• IPSec para tráfego de autenticação
• Use autenticação de dois fatores (smartcard ou desafio-resposta é barato)
• Desativar NTLM

As duas primeiras sugestões exigem que você configure um serviço de PKI. A implementação da PKI pode ser uma verdadeira dor no pescoço, mas pode lhe dar muita capacidade realmente interessante e permitir que você opere de forma eficaz e segura em um ambiente não confiável.

    

Answer 6

Uma regra geral é que a única coisa que acontece em um controlador de domínio é o próprio Active Directory. Nem sempre é possível, é claro, mas é tudo sobre como reduzir o número de serviços potencialmente expostos.

    

Answer 7

Você precisará entender os ataques pass-the-hash (PtH) e pass-the-ticket (PtT), pois esses são os principais meios pelos quais os invasores se espalham por toda a rede do Windows. A Microsoft tem a orientação PtH, mas pode ser um pouco complicado se você ainda não estiver familiarizado com os problemas de segurança: link

A melhor maneira é usar o design de floresta vermelha da Microsoft. A floresta vermelha é uma floresta separada com uma relação de confiança unidirecional que abriga suas contas de administrador de domínio. Requer esforço extra e servidores, mas você pode obter 95% dos benefícios sem ele, se tiver cuidado.

Qualquer conta com privilégios no AD (administradores de domínio, help desk, etc.) nunca deve entrar em qualquer servidor membro regular ou estação de trabalho. Ou seja, você deve definir os direitos Negar logon para incluir administradores de domínio e outros grupos privilegiados em máquinas membros regulares.

Em geral, toda a atividade do administrador deve ocorrer em sistemas que não têm acesso à Internet e conectividade IP restrita a computadores que o fazem.

Obviamente, você só pode restringir os administradores de domínio dessa maneira se tiver contas separadas para administração de servidores e estações de trabalho. Você também deve ter contas desprivilegiadas separadas para web / email. Essa separação de papéis é um dos aspectos-chave para proteger uma rede.

Um administrador de domínio deve NUNCA entrar em um sistema DMZ ou em uma máquina conectada à Internet. Você não deveria nem mesmo RDP de um. Você deve ter estações de trabalho dedicadas para essas contas, e suas contas de estações de trabalho regulares não devem ser capazes de fazer logon nas estações de trabalho administrativas do AD. Deve haver zero contas que podem fazer logon em estações de trabalho regulares e AD. Isso impede que as credenciais altamente privilegiadas sejam roubadas quando um invasor obtém privilégios de administrador / sistema em uma estação de trabalho e, subsequentemente, se espalha para outras pessoas (geralmente ao roubar credenciais quando um administrador de estação de trabalho efetua login).

De maneira semelhante, deve haver contas dedicadas para máquinas DMZ , e nenhuma conta deve ter acesso à DMZ e aos recursos internos. Também é possível configurar um domínio separado da DMZ (com ou sem uma confiança no domínio interno).

Recuperar o AD depois de um compromisso é possível, mas isso deve ser feito de forma absolutamente correta --- e, obviamente, haverá algum tempo de inatividade enquanto o domínio está sendo restaurado e limpo. Nossa recuperação estimada de uma CD comprometida foi vários dias antes da implementação de uma floresta vermelha; é menos de 12 horas com uma floresta vermelha.

Observe que cada medida de segurança é uma parte da solução total e você precisa de todo o restante. Essas sugestões são específicas para proteger o AD. Você ainda precisa segmentar sua rede e ter restrições adequadas de firewall / ACL. Você ainda precisa proteger suas contas de usuário adequadamente com cartões inteligentes (altamente recomendados) ou boas políticas de senha. Você ainda precisa de detecção de intrusão, antivírus, um bom firewall externo e um proxy da Web.