Devo expor meu Active Directory à Internet pública para usuários remotos?

Question

Tenho um cliente cuja força de trabalho é composta inteiramente por funcionários remotos que usam uma combinação de PCs / laptops da Apple e do Windows 7.

Os usuários não autenticam em um domínio no momento, mas a organização gostaria de se mover nessa direção por vários motivos. Estas são máquinas pertencentes à empresa, e a empresa procura ter algum controle sobre desativação de conta, política de grupo e alguma prevenção leve de perda de dados (desativar mídia remota, USB, etc.). Eles estão preocupados com a autenticação VPN para acessar o AD seria complicado, especialmente na interseção de um funcionário rescindido e credenciais em cache em uma máquina remota.

A maioria dos serviços na organização é baseada no Google (e-mail, arquivo, bate-papo, etc.), de modo que os únicos serviços de domínio são o DNS e a autenticação de sua VPN Cisco ASA.

O cliente gostaria de entender por que não é aceitável expor seus controladores de domínio ao público. Além disso, o que é uma estrutura de domínio mais aceitável para uma força de trabalho remota distribuída?

Editar:

O

Centrify está sendo usado por um punhado de clientes Mac.

    

Answer 1

Estou postando isso como uma resposta principalmente porque todos têm sua própria "opinião educada" baseada na experiência, informações de terceiros, boatos e conhecimento tribal dentro de TI, mas isso é mais uma lista de citações e leituras "diretamente" de Microsoft Eu usei aspas porque tenho certeza de que elas não filtram adequadamente todas as opiniões feitas por seus funcionários, mas isso deve ser útil mesmo assim, se você estiver atrás de authoritative das referências diretas da Microsoft.

BTW, Eu também acho que é MUITO FÁCIL DIZER DOMAIN CONTROLLER == DIRETÓRIO ATIVO, o que não é bem o caso. Os proxies do AD FS e outros meios (autenticação baseada em formulários para o OWA, EAS, etc.) oferecem uma maneira de "expor" o próprio AD à Web para permitir que os clientes tentem autenticar pelo AD sem expor os próprios DCs. Vá ao site do OWA de alguém e tente fazer o login e o AD irá obter a solicitação de autenticação em um DC de backend, portanto, o AD é tecnicamente "exposto" ... mas é protegido via SSL e intermediado por proxy por meio de um servidor Exchange .

Citação # 1

Diretrizes para implantar o Windows Server Active Directory em máquinas virtuais do Windows Azure

Antes de ir "O Azure não é o AD" ... você pode implantar o ADDS em uma VM do Azure.

Mas para citar os bits relevantes:

Never expose STSs directly to the Internet.

As a security best practice, place STS instances behind a firewall and connect them to your corporate network to prevent exposure to the Internet. This is important because the STS role issues security tokens. As a result, they should be treated with the same level of protection as a domain controller. If an STS is compromised, malicious users have the ability to issue access tokens potentially containing claims of their choosing to relying party applications and other STSs in trusting organizations.

ergo ... não exponha os controladores de domínio diretamente à Internet.

Citação # 2

Active Directory - O mistério UnicodePwd do AD LDS

Exposing a domain controller to the Internet is normally a bad practice, whether that exposure comes directly from the production environment or through a perimeter network. The natural alternative is to place a Windows Server 2008 server with Active Directory Lightweight Directory Services (AD LDS) role running in the perimeter network.

Citação # 3 - não do MS ... mas ainda útil em olhar para frente

Active Directory-as-a-Service? Azure, Intune insinuando um futuro do AD hospedado em nuvem

In the end, there is no great "short" answer which meets the goals of ridding the office of the AD server in exchange for an Azure alternative. While Microsoft is being complacent in allowing customers to host Active Directory Domain Services on Server 2012 and 2008 R2 boxes in Azure, their usefulness is only as good as the VPN connectivity you can muster for your staff. DirectAccess, while a very promising technology, has its hands tied due to its own unfortunate limitations.

Citação # 4

Implante o AD DS ou o AD FS e o Office 365 com logon único e máquinas virtuais do Windows Azure

Domain controllers and AD FS servers should never be exposed directly to the Internet and should only be reachable through VPN

    

Answer 2

O Active Directory (AD) não foi projetado para esse tipo de implantação.

Os modelos de ameaça usados no design do produto assumem uma implantação "por trás do firewall" com uma quantidade de atores hostis filtrados na borda da rede. Embora você possa certamente proteger o Windows Server para que fique exposto à rede pública, o funcionamento correto do Active Directory exige uma postura de segurança decididamente mais frouxa do que um host reforçado para redes voltadas para o público. Um lote de serviços precisa ser exposto por um Controlador de Domínio (DC) para que o AD funcione corretamente.

A sugestão do Zoredache nos comentários, particularmente referenciando algo como o OpenVPN sendo executado como um serviço de toda a máquina com autenticação de certificado, pode ser um bom ajuste. O DirectAccess, como outros já mencionaram, é exatamente o que você precisa, exceto que ele não tem o suporte multiplataforma que você deseja.

Como um aparte: Eu brinquei com a idéia de usar o IPSEC de modo de transporte baseado em certificado para expor o AD diretamente à Internet, mas nunca tive tempo de fazê-lo. A Microsoft fez alterações no período de tempo do Windows Server 2008 / Vista que supostamente tornaram isso viável, mas eu nunca o exercitei de fato.

    

Answer 3

O que todo mundo disse. Estou particularmente nervoso com as tentativas de força bruta que Christopher Karel mencionou. Uma apresentação no último Def Con foi sobre o tema:

So You Think Your Domain Controller is Secure?

JUSTIN HENDRICKS SECURITY ENGINEER, MICROSOFT

Domain Controllers are the crown jewels of an organization. Once they fall, everything in the domain falls . Organizations go to great lengths to secure their domain controllers, however they often fail to properly secure the software used to manage these servers.

This presentation will cover unconventional methods for gaining domain admin by abusing commonly used management software that organizations deploy and use.

Justin Hendricks works on the Office 365 security team where he is involved in red teaming, penetration testing, security research, code review and tool development.

Tenho certeza que você pode encontrar muitos outros exemplos. Eu estava procurando artigos sobre controladores de domínio e hackers na esperança de obter uma descrição da rapidez com que o CD seria encontrado, etc., mas acho que isso será feito por enquanto.

    

Answer 4

Se você está tentando convencer a gerência, um bom começo seria:

It goes against Microsoft's Best Practices for Active Directory Deployment.

Atualização : consulte este artigo de technet para proteger os controladores de domínio contra ataque e a seção intitulada Perimeter Firewall Restrictions que declara:

Perimeter firewalls should be configured to block outbound connections
from domain controllers to the Internet. 

E a seção intitulada Blocking Internet Access for Domain Controllers , que diz:

Launching web browsers on domain controllers should be prohibited not only
by policy, but by technical controls, and domain controllers should not be
permitted to access the Internet

Tenho certeza de que você pode obter alguma documentação da Microsoft sobre o assunto, e é isso. Além disso, você pode declarar os perigos de tal movimento, algo como:

A gaping hole would be created, possibly resulting in severe data loss and/or loss of company secrets.

As credenciais em cache são apenas isso - armazenadas em cache. Eles trabalham para a máquina local quando não conseguem se conectar ao domínio , mas se essa conta estiver desativada eles não funcionarão para nenhum recurso de rede (svn, vpn, smb, fbi, cia, etc) então eles não precisam se preocupar com isso. Lembre-se também que os usuários já têm direitos completos sobre qualquer arquivo na pasta de perfil em uma máquina local de qualquer maneira (e provavelmente mídia removível), de modo que as credenciais desabilitadas ou não podem fazer o que quiserem com esses dados. Eles também não funcionariam para a máquina local depois de se reconectar à rede.

Você está se referindo aos serviços que o Active Directory ou um controlador de domínio oferece, como o LDAP? Em caso afirmativo, o LDAP geralmente é quebrado com segurança para fins de autenticação e consulta de diretórios, mas apenas desativar o Firewall do Windows (ou abrir todas as portas necessárias para o público - a mesma coisa neste exemplo) pode causar problemas graves.

O AD não realmente gerencia Macs, portanto, seria necessária uma solução separada (pense no OS X Server). Você pode unir um Mac a um domínio, mas isso faz pouco mais do que deixá-los autenticar com credenciais de rede, definir administradores de domínio como administradores locais no mac, etc. Nenhuma política de grupo. A MS está tentando abrir caminho com novas versões do SCCM que afirmam ser capaz de implantar aplicativos em macs e caixas * nix, mas eu ainda não o vi em um ambiente de produção. Eu também acredito que você poderia configurar os macs para se conectar ao OS X Server, que seria autenticado em seu diretório baseado em AD, mas eu poderia estar errado.

Dito isto, algumas soluções criativas podem ser inventadas, como a sugestão de Evan para usar o OpenVPN como um serviço, e desabilitar o certificado de máquina se / quando chegar a hora de deixar o funcionário ir.

Parece que tudo é baseado no Google, então o Google está agindo como seu servidor ldap? Eu recomendaria ao meu cliente que continue assim, se possível. Não sei a natureza do seu negócio, mas para aplicativos baseados na web, como um servidor git ou redmine, mesmo quando a configuração interna pode autenticar com o OAuth, aproveitando uma conta do Google.

Por fim, uma configuração roadwarrior como essa exigiria que <<> exija que uma VPN seja bem-sucedida. Uma vez que as máquinas são trazidas para o escritório e configuradas (ou configuradas remotamente por meio de script), elas precisam de uma maneira de receber qualquer alteração na configuração.

Os macs precisariam de uma abordagem de gerenciamento separada, além da VPN, é uma pena que eles não criem mais servidores mac reais, mas eles tiveram algumas implementações de políticas decentes no OS X Server na última vez que verifiquei de anos atrás).

    

Answer 5

É lamentável que o DirectAccess esteja disponível apenas no Win7 + Enterprise Edition, porque é feito sob medida para sua solicitação. Mas sem saber sua edição e vendo que você tem MacOS, isso não funcionará.

/ Edit - parece que terceiros afirmam ter clientes DA para Unices: link

Existem soluções de MDM disponíveis que podem trabalhar para atender às suas necessidades; estamos rolando um deles (MAAS360) para um cliente que está em uma posição similar.

    

Answer 6

Isso obviamente seria um risco de segurança significativo. Além disso, provavelmente não funcionaria tão bem quanto você gostaria. Se pessoas aleatórias na Internet puderem tentar logins em seu ambiente do AD, é bom que todos os seus usuários sejam bloqueados. Para sempre. E remover os requisitos de bloqueio significa que é muito fácil verificar a força bruta para senhas simples.

Mais importante, você não deve ter problemas para implementar sua meta (usuários finais que fazem login em um laptop com credenciais de domínio) sem tornar os servidores do AD diretamente acessíveis. Ou seja, as máquinas Windows podem armazenar em cache os últimos X logins bem-sucedidos, para que essas mesmas credenciais funcionem quando desconectadas. Isso significa que os usuários finais podem fazer login e fazer um trabalho útil, sem precisar tocar em seus servidores do AD. Eles obviamente precisarão utilizar uma VPN para se conectarem a outros recursos corporativos importantes e atualizar as configurações do AD / GPO ao mesmo tempo.

    

Answer 7

Ewwhite,

Sua pergunta é extremamente válida e merece uma análise cuidadosa.

Todos os profissionais de segurança recomendam camadas de segurança na frente de qualquer recurso de rede, incluindo Firewalls SPI, IDS, Firewalls com Host, etc. Você sempre deve usar um firewall de gateway de perímetro proxy como ISA (agora TMG) quando possível.

Dito isto, o Microsoft Active Directory 2003+ não teve grandes vulnerabilidades divulgadas publicamente. A tecnologia LDAP e seus algoritmos de hash geralmente são muito seguros. É indiscutivelmente mais seguro que o SSL VPN se esse VPN SSL executar o OpenSSL e estiver vulnerável ao heartbleed.

Eu recomendaria 5 coisas:

1. Esteja preocupado com os outros serviços que a rede enfrenta, como o Terminal Server, os Serviços DNS, o CIFS e, especialmente, o IIS com seu registro de segurança terrível.

2. Use o LDAPS com um certificado de segurança para evitar passar credenciais de domínio de texto não criptografado pela conexão. Isso acontece automaticamente após a instalação dos Serviços de Certificados (use uma máquina separada para PKI)

3. Coloque um sniffer de pacotes na interface e observe seu tráfego, corrija senhas de texto não criptografado porque é firewall ou não, se você não usa VPN ou LDAPS, alguns sistemas legados enviarão senhas em texto puro.

4. Saiba que os ataques MITM podem forçar os mecanismos de autenticação nativos a fazer downgrade e expor senhas a uma autenticação NTLM mais fraca.

5. Esteja ciente de algumas vulnerabilidades de enumeração de usuário que ainda podem existir.

Dito isso, o Active Directory tem um excelente histórico de segurança. Além disso, o MS Active Directory não armazena senhas, apenas hashes que também podem atenuar a gravidade de um comprometimento.

Você pode se beneficiar de uma infra-estrutura de segurança mais simples, não precisa configurar servidores DNS especiais ou usar domain.local e pode usar seu domínio real na Internet pública, como domain.com.

Na minha opinião profissional, há um benefício substancial na implantação de tecnologias de segurança, como o Active Directory publicamente, em que outras tecnologias, como o Exchange, DNS e Web Servers, simplesmente não oferecem nenhum benefício e todo o risco.

Nota: se você implantar o Active Directory, ele incluirá um servidor DNS. Seja CERTAIN para desabilitar a recursão em seus servidores DNS (habilitado por padrão) ou você estará absolutamente participando de ataques de negação de serviço.

Felicidades,

-Brian

    

Answer 8

A Dell (através da compra da Quest (através da compra da Vintela)) tem uma solução multi-plataforma que é implantada com freqüência em empresas F500 para este propósito expresso .

Coisas a considerar ...

1. Seus usuários estão sempre conectados? Em caso afirmativo, você será melhor atendido com um ambiente de hospedagem flexível baseado em VM que pode se flexionar quando muitos usuários ativos estão martelando o LDAP
2. Você está executando em mais de um data center físico? Considere o balanceamento de carga geográfico em frente aos serviços do AD para reduzir o número de saltos entre usuários e seus sistemas
3. Além disso, se a resposta para # 2 for sim, certifique-se de configurar alguns recursos de rede dedicados para replicar sua floresta conforme descrito aqui

E certifique-se de que sua solução de firewall é capaz de lidar com taxas de retransmissão extremamente altas se você tiver usuários em uplinks acelerados, conectando-se de centros wifi barulhentos, etc.