Devo esporre Active Directory a Internet pubblico per utenti remoti?


46

Ho un cliente la cui forza lavoro è composta interamente da dipendenti remoti che utilizzano un mix di PC / laptop Apple e Windows 7.

Al momento gli utenti non eseguono l'autenticazione con un dominio, ma l'organizzazione vorrebbe spostarsi in quella direzione per diversi motivi. Si tratta di macchine di proprietà dell'azienda e l'azienda cerca di avere un certo controllo sulla disattivazione dell'account, sui criteri di gruppo e su una leggera prevenzione della perdita di dati (disabilitare supporti remoti, USB, ecc.). Si preoccupano che richiedere l'autenticazione VPN per accedere ad AD sarebbe ingombrante, specialmente all'intersezione di un dipendente licenziato e le credenziali memorizzate nella cache su una macchina remota.

La maggior parte dei servizi nell'organizzazione sono basati su Google (posta, file, chat, ecc.), Pertanto gli unici servizi di dominio sono DNS e l'autent per la loro Cisco ASA VPN.

Il cliente desidera capire perché non è accettabile esporre i propri controller di dominio al pubblico. Inoltre, qual è una struttura di dominio più accettabile per una forza lavoro remota distribuita?

Modificare:

Centrify è in uso per una manciata di client Mac.


4
C'è una domanda correlata QUI . Consentire ai servizi esterni di connettersi al proprio AD per sincronizzarsi o autenticarsi non è una pratica terribile, ma posizionare i controller di dominio su una DMZ aperta, essenzialmente come richiesto, è molto insicuro. Senza la sicurezza in atto, stai chiedendo una varietà di potenziali attacchi e problemi. Consiglio vivamente contro di essa e suggerirei un client VPN o VPN da un firewall come Sonicwall con utenti di dispositivi locali.
Mike Naylor,

10
Imposta una VPN sempre attiva, a livello di macchina, con riconnessione automatica e basata su certificati. (OpenVPN, DirectAccess, ecc.), Pertanto l'autenticazione VPN non è legata agli account utente e l'utente non ha alcuna interazione diretta con il software VPN.
Zoredache,

Il DA è perfetto, ma ha seri requisiti di endpoint che il cliente non soddisfa (Mac, di sicuro.)
mfinni

1
+10 - Per il suggerimento di Zoredache.
Evan Anderson,

7
Se si esegue il backup dei dispositivi degli utenti finali, si sta facendo un errore. Se si esegue il backup dei dispositivi degli utenti finali tramite USB, si sta facendo davvero un errore.
MDMarra,

Risposte:


31

Sto pubblicando questo come risposta principalmente perché ognuno ha la propria "opinione educata" basata su esperienza, informazioni di terze parti, sentito dire e conoscenza tribale all'interno dell'IT, ma questo è più un elenco di citazioni e letture "direttamente" da Microsoft. Ho usato le virgolette perché sono sicuro che non filtrano correttamente tutte le opinioni fatte dai loro dipendenti, ma ciò dovrebbe rivelarsi utile se stai cercando authoritativeriferimenti diretti da Microsoft.


A proposito, penso anche che sia MOLTO FACILE dire DOMAIN CONTROLLER == DIRECTORY ATTIVO, il che non è del tutto vero. I proxy AD FS e altri mezzi (autenticazione basata su moduli per OWA, EAS, ecc.) Offrono un modo per "esporre" l'AD stesso al Web per consentire ai clienti di almeno tentare di autenticarsi via AD senza esporre gli stessi controller di dominio. Andare sul sito OWA di qualcuno e tentare di accedere e AD riceverà la richiesta di autenticazione su un controller di dominio back-end, quindi AD è tecnicamente "esposto" ... ma è protetto tramite SSL e sottoposto a proxy tramite un server Exchange.


Visto n. 1

Linee guida per la distribuzione di Windows Server Active Directory su macchine virtuali Windows Azure

Prima di andare "Azure non è AD" ... PUOI distribuire ADDS su una VM di Azure.

Ma per citare i bit rilevanti:

Non esporre mai gli STS direttamente a Internet.

Come best practice sulla sicurezza, collocare le istanze STS dietro un firewall e collegarle alla rete aziendale per impedire l'esposizione a Internet. Questo è importante perché il ruolo STS emette token di sicurezza. Di conseguenza, dovrebbero essere trattati con lo stesso livello di protezione di un controller di dominio. Se un STS è compromesso, gli utenti malintenzionati hanno la possibilità di emettere token di accesso che potenzialmente contengono reclami della propria scelta di affidarsi ad applicazioni di terze parti e ad altri STS in organizzazioni fidate.

ergo ... non esporre i controller di dominio direttamente a Internet.

Visto n. 2

Active Directory - Il mistero UnicodePwd di AD LDS

L'esposizione di un controller di dominio a Internet è normalmente una cattiva pratica, indipendentemente dal fatto che tale esposizione provenga direttamente dall'ambiente di produzione o attraverso una rete perimetrale. L'alternativa naturale è posizionare un server Windows Server 2008 con ruolo Active Directory Lightweight Directory Services (AD LDS) in esecuzione nella rete perimetrale.

Citazione n. 3 - non dalla SM ... ma utile ancora nel guardare al futuro

Active Directory come servizio? Azure, Intune accenna a un futuro di annunci cloud-hosted

Alla fine, non esiste una risposta "breve" che soddisfi gli obiettivi di liberare l'ufficio del server AD in cambio di un'alternativa di Azure. Mentre Microsoft è compiacente nel consentire ai clienti di ospitare servizi di dominio Active Directory su caselle Server 2012 e 2008 R2 in Azure, la loro utilità è buona quanto la connettività VPN che puoi raccogliere per il tuo personale. DirectAccess, sebbene una tecnologia molto promettente, ha le mani legate a causa delle sue sfortunate limitazioni.

Visto n. 4

Distribuire Servizi di dominio Active Directory o ADFS e Office 365 con Single Sign-On e macchine virtuali Windows Azure

I controller di dominio e i server AD FS non devono mai essere esposti direttamente a Internet e dovrebbero essere raggiungibili solo tramite VPN


Questa è una risposta ragionevole, anche se solo la prima citazione dice qualcosa su quali cose brutte potrebbero accadere se si ignora il consiglio.
Casey,

19

Active Directory (AD) non è stato progettato per quel tipo di distribuzione.

I modelli di minaccia utilizzati nella progettazione del prodotto presuppongono una distribuzione "dietro il firewall" con una certa quantità di attori ostili filtrati al confine della rete. Sebbene sia possibile indurire Windows Server a essere esposto alla rete pubblica, il corretto funzionamento di Active Directory richiede una posizione di sicurezza decisamente più lenta di un host rafforzato per le reti pubbliche. Un sacco di servizi deve essere esposto da un controller di dominio (DC) per AD funzioni correttamente.

Il suggerimento di Zoredache nei commenti, in particolare facendo riferimento a qualcosa come OpenVPN in esecuzione come servizio a livello di macchina con autenticazione certificato, potrebbe essere una buona scelta. DirectAccess, come altri hanno già detto, è esattamente ciò di cui hai bisogno, tranne per il fatto che non ha il supporto multipiattaforma che desideri.

A parte questo: ho giocato con l'idea di utilizzare l'IPSEC in modalità di trasporto basata su certificato per esporre l'AD direttamente a Internet, ma non ho mai avuto il tempo di farlo. Microsoft ha apportato modifiche nel lasso di tempo di Windows Server 2008 / Vista che presumibilmente hanno reso possibile tutto ciò, ma non l'ho mai esercitato.


2
+1 per OpenVPN in esecuzione come servizio, in passato ho usato con successo questo approccio con i guerrieri della strada. Ci sono stati sentimenti contrastanti da parte degli amministratori di Sr sys, in particolare perché se una macchina è stata compromessa, si tratta di una backdoor automatica nella rete. Preoccupazioni valide ovviamente, per ogni ambiente, anche se su, devono chiedersi se i benefici superano il rischio ....?
MDMoore313,

2
Microsoft gestisce la propria rete aziendale su Internet pubblica con IPSec. Quindi è fattibile.
Michael Hampton

1
@MichaelHampton ma usano l'isolamento del dominio con Windows Firewall e IPSec, quindi non è proprio "AD su Internet", è "AD su Internet e in una zona di sicurezza simile a quella che un firewall fornirebbe invece usando le regole del firewall basate su host"
MDMarra,

2
@ MDMoore313 - FTW di revoca del certificato, sebbene l'utente debba segnalare rapidamente la macchina rubata.
Evan Anderson,

Esistono anche modi con alcuni client VPN (ad esempio Juniper) per forzare una disconnessione dopo la connessione. Non è bello come quelli vecchi infusi da GINA, ma costringe l'utente ad accedere di nuovo mentre si trova sulla VPN per autenticare effettivamente contro AD e ottenere oggetti Criteri di gruppo, ecc. Effettuare prima il login con le credenziali memorizzate nella cache, avviare la VPN se necessario, e ti disconnette immediatamente e rimane connesso mentre accedi di nuovo.
TheCleaner

15

Quello che hanno detto tutti gli altri. Sono particolarmente nervoso per i tentativi di forza bruta citati da Christopher Karel. Una presentazione all'ultimo Def Con era sull'argomento:

Quindi pensi che il tuo controller di dominio sia sicuro?

JUSTIN HENDRICKS INGEGNERE DI SICUREZZA, MICROSOFT

I controller di dominio sono i gioielli della corona di un'organizzazione. Una volta che cadono, tutto nel dominio cade. Le organizzazioni fanno di tutto per proteggere i propri controller di dominio, tuttavia spesso non riescono a proteggere correttamente il software utilizzato per gestire questi server.

Questa presentazione tratterà metodi non convenzionali per ottenere l'amministrazione del dominio abusando del software di gestione comunemente usato che le organizzazioni distribuiscono e utilizzano.

Justin Hendricks lavora nel team di sicurezza di Office 365 dove è coinvolto in team rosso, test di penetrazione, ricerca sulla sicurezza, revisione del codice e sviluppo di strumenti.

Sono sicuro che puoi trovare molti altri esempi. Stavo cercando articoli su controller di dominio e hacking nella speranza di ottenere una descrizione di quanto rapidamente sarebbe stato trovato il controller di dominio, ecc., Ma penso che per ora lo farà.


1
Ecco il video della presentazione di Hendricks: youtube.com/watch?v=2d_6jAF6OKQ Volevo guardare i video di DefCon 21 e penso che inizierò con questo.
Evan Anderson,

14

Se stai cercando di convincere il management, un buon inizio sarebbe che:

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

Aggiornamento : vedi questo articolo tecnico sulla protezione dei controller di dominio dagli attacchi e la sezione intitolata Perimeter Firewall Restrictionsche afferma:

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

E la sezione intitolata Blocking Internet Access for Domain Controllersche afferma:

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

Sono sicuro che puoi raccogliere un po 'di documentazione Microsoft sull'argomento, quindi è così. Oltre a ciò, potresti dichiarare i rischi di una tale mossa, qualcosa sulla falsariga di:

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

Le credenziali memorizzate nella cache sono proprio questo: memorizzate nella cache. Funzionano per il computer locale quando non è in grado di connettersi al dominio , ma se tale account fosse disabilitato non funzionerebbero per nessuna risorsa di rete (svn, vpn, smb, fbi, cia, ecc.), Quindi non devono preoccuparsene . Ricorda inoltre che gli utenti hanno già diritti completi su qualsiasi file nella loro cartella del profilo su un computer locale (e probabilmente su supporti rimovibili) in modo che le credenziali disabilitate o meno possano fare quello che vogliono con quei dati. Inoltre, non funzionerebbero per il computer locale una volta che si riconnette alla rete.

Ti riferisci ai servizi forniti da Active Directory o da un controller di dominio, come LDAP? In tal caso, LDAP viene spesso suddiviso in modo sicuro ai fini dell'autenticazione e dell'interrogazione delle directory, ma la disattivazione di Windows Firewall (o l'apertura di tutte le porte richieste al pubblico - La stessa cosa in questo esempio) potrebbe causare gravi problemi.

AD non gestisce veramente i Mac, quindi sarebbe necessaria una soluzione separata (pensa OS X Server). Puoi unire un Mac a un dominio ma ciò non fa altro che autorizzarli con le credenziali di rete, impostare amministratori di dominio come amministratori locali sul Mac, ecc. Nessuna politica di gruppo. MS sta cercando di violare il terreno con le versioni più recenti di SCCM che affermano di essere in grado di distribuire applicazioni su mac e * nix box, ma devo ancora vederlo in un ambiente di produzione. Credo anche che potresti configurare i mac per connettersi al server OS X che si autenticherà nella tua directory basata su AD, ma potrei sbagliarmi.

Detto questo, alcune soluzioni creative potrebbero essere escogitate, come il suggerimento di Evan per l'utilizzo di OpenVPN come servizio e la disabilitazione del certificato macchina se / quando arriva il momento di lasciar andare quel dipendente.

Sembra che tutto sia basato su Google, quindi Google agisce come il tuo server LDAP? Consiglierei al mio cliente di mantenerlo tale, se possibile. Non conosco la natura della tua attività, ma per le app basate sul Web come un server git o redmine, anche quando l'installazione in casa può eseguire l'autenticazione con OAuth, sfruttando un account Google.

Infine, una configurazione di un guerriero stradale come questa richiederebbe quasi una VPN per avere successo. Una volta che le macchine vengono portate in ufficio e configurate (o configurate in remoto tramite script), hanno bisogno di un modo per ricevere eventuali modifiche alla configurazione.

I mac avrebbero bisogno di un approccio di gestione separato oltre alla VPN, peccato che non realizzino più veri server mac, ma avevano alcune decenti implementazioni dei criteri in OS X Server l'ultima volta che ho controllato (un paio di anni fa ).


In realtà, Centrify è in uso in questo ambiente per la gestione dei criteri su una manciata di sistemi Mac in questo momento.
ewwhite,

@ewwhite cosa intendi per gestione? Sembra nient'altro che un'utilità di autenticazione centrale.
MDMoore313,

@ MDMoore313 sei in ritardo di qualche ora, vinco: chat.stackexchange.com/transcript/127?m=13626424#13626424 - :)
TheCleaner

@TheCleaner haha ​​sembra così, questa volta vinci, conosci bene l'arte di Google Fu, ma la tua tecnica ti sfugge nel mio miglior Kung Fu con una terribile voce da labbra. Dopo aver pubblicato la tua risposta, ho dovuto cercare due volte per trovarne uno che non fosse un tuo duplicato!
MDMoore313,

2
LOL, non preoccuparti ... la prossima volta che incontreremo la vittoria potrebbe essere tua. (con una terribile voce da labbra)
TheCleaner,

7

È un peccato che DirectAccess sia disponibile solo su Win7 + Enterprise Edition, perché è fatto su misura per la tua richiesta. Ma non conoscere la tua edizione e vedere che hai MacOS, non funzionerà.

/ Modifica: sembra che alcune terze parti affermino di avere client DA per Unices: http://www.centrify.com/blogs/tomkemp/what_is_microsoft_directaccess_and_unix_linux_interoperability.asp

Sono disponibili soluzioni MDM che possono funzionare per soddisfare le tue esigenze; ne stiamo distribuendo uno (MAAS360) a un client che si trova in una posizione simile.


5

Questo sarebbe ovviamente un rischio significativo per la sicurezza. Inoltre, probabilmente non funzionerebbe come vorresti. Se persone casuali su Internet sono in grado di tentare l'accesso al proprio ambiente AD, le probabilità sono buone che tutti gli utenti vengano bloccati. Per sempre. E rimuovere i requisiti di blocco significa che è abbastanza facile controllare la forza bruta per password semplici.

Ancora più importante, non dovresti avere problemi a realizzare il tuo obiettivo (utenti finali che accedono a un laptop con credenziali di dominio) senza rendere i server AD direttamente accessibili. Vale a dire, i computer Windows possono memorizzare nella cache gli ultimi accessi X riusciti, in modo che quelle stesse credenziali funzionino quando vengono disconnesse. Ciò significa che gli utenti finali possono accedere e fare un lavoro utile, senza dover toccare i server AD. Dovranno ovviamente utilizzare una VPN per connettersi ad altre importanti risorse aziendali e allo stesso tempo possono aggiornare le impostazioni AD / GPO.


2
AD non usa (o almeno dipende da) le trasmissioni per nulla, per quanto sia stato AD, per quanto ne sappia. Alcune tecnologie potrebbero richiedere WINS, che può ricorrere alle richieste di trasmissione se non è disponibile un server WINS, ma ciò non è rilevante per l'AD in generale. Se dipendesse dalle trasmissioni, non potresti avere utenti remoti senza DC locali.
mfinni,

2
Modificato quella linea. Grazie per l'input. Chiaramente un ragazzo Linux come me non dovrebbe essere ospitato su Windows.
Christopher Karel,

Se fosse così "ovvio" non sarebbe una domanda, vero?
Casey,

2

Ewwhite,

La tua domanda è estremamente valida e merita un'attenta revisione.

Tutti i professionisti della sicurezza raccomandano livelli di sicurezza di fronte a qualsiasi risorsa di rete, inclusi firewall SPI, IDS, firewall basati su host, ecc. Dovresti sempre utilizzare un firewall gateway perimetrale proxy come ISA (ora TMG) ​​quando possibile.

Detto questo, Microsoft Active Directory 2003+ non ha avuto grandi vulnerabilità divulgate pubblicamente. La tecnologia LDAP e i suoi algoritmi di hash sono generalmente molto sicuri. È probabilmente più sicuro della VPN SSL se quella VPN esegue OpenSSL ed è vulnerabile al cuore.

Vorrei avvertire 5 cose:

  1. Fai attenzione agli altri servizi che si trovano ad affrontare la rete come Terminal Server, Servizi DNS, CIFS e in particolare IIS con il suo terribile record di sicurezza.

  2. Utilizzare LDAPS con un certificato di sicurezza per evitare di trasferire credenziali di dominio di testo in chiaro sul cavo. Ciò si verifica automaticamente dopo l'installazione di Servizi certificati (utilizzare una macchina separata per PKI)

  3. Metti uno sniffer di pacchetti sull'interfaccia e osserva il tuo traffico, correggi eventuali password in chiaro perché firewall o no, se non usi una VPN o LDAPS, alcuni sistemi legacy invieranno password in chiaro.

  4. Sappi che gli attacchi MITM possono imporre ai meccanismi di autenticazione nativi il downgrade ed esporre le password a un'autenticazione NTLM più debole.

  5. Essere consapevoli di alcune vulnerabilità di enumerazione degli utenti che potrebbero ancora esistere.

Detto questo, Active Directory ha un'ottima reputazione in termini di sicurezza. Inoltre, MS Active Directory non memorizza le password, ma solo gli hash che possono anche mitigare la gravità di un compromesso.

Potresti beneficiare di un'infrastruttura di sicurezza più fluida, non devi impostare server DNS speciali o utilizzare domain.local e puoi utilizzare il tuo dominio reale su Internet pubblico come domain.com.

Secondo la mia opinione professionale, c'è un sostanziale vantaggio nell'implementazione pubblica di tecnologie di sicurezza come Active Directory, dove altre tecnologie come Exchange, DNS e Web Server semplicemente non forniscono alcun vantaggio e tutti i rischi.

Nota: se si distribuisce Active Directory includerà un server DNS. Assicurati di disabilitare la ricorsione sui tuoi server DNS (abilitato per impostazione predefinita) o parteciperai assolutamente agli attacchi denial of service.

Saluti,

-Brian


-3

Dell (tramite l'acquisto di Quest (tramite l'acquisto di Vintela)) ha una soluzione multipiattaforma che viene distribuita frequentemente nelle aziende F500 per questo preciso scopo .

Cose da considerare ...

  1. I tuoi utenti sono sempre connessi? In tal caso, ti verrà offerto un ambiente di hosting flessibile basato su VM in grado di flettere quando molti utenti attivi stanno martellando LDAP
  2. Sei in esecuzione in più di un data center fisico? Considerare il bilanciamento del carico geografico di fronte ai servizi AD per ridurre il numero di hop tra gli utenti e i sistemi
  3. Inoltre, se la risposta a # 2 è sì, assicurati di impostare alcune risorse di rete dedicate per replicare la tua foresta come illustrato qui

E assicurati che la tua soluzione firewall sia in grado di gestire velocità di ritrasmissione estremamente elevate se disponi di utenti con uplink limitati, connessione da centri wifi rumorosi, ecc.


In che modo questo gestisce i computer Windows o protegge qualcosa come un controller di dominio che è esposto a Internet? Non legge affatto.
mfinni,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.