it-swarm.com.de

Sollte ich mein Active Directory für Remotebenutzer dem öffentlichen Internet aussetzen?

Ich habe einen Kunden, dessen Belegschaft ausschließlich aus Remote-Mitarbeitern besteht, die eine Mischung aus Apple und Windows 7-PCs/Laptops) verwenden.

Die Benutzer authentifizieren sich derzeit nicht bei einer Domain, aber die Organisation möchte aus mehreren Gründen in diese Richtung gehen. Hierbei handelt es sich um firmeneigene Computer, und das Unternehmen bemüht sich um eine gewisse Kontrolle über die Deaktivierung des Kontos, Gruppenrichtlinien und eine leichte Verhinderung von Datenverlust (Deaktivieren von Remote-Medien, USB usw.). Sie befürchten, dass für den Zugriff auf AD eine VPN-Authentifizierung erforderlich ist Dies wäre umständlich, insbesondere an der Kreuzung eines gekündigten Mitarbeiters mit zwischengespeicherten Anmeldeinformationen auf einem Remotecomputer.

Die meisten Dienste in der Organisation basieren auf Google (E-Mail, Datei, Chat usw.). Die einzigen Domänendienste sind DNS und die Authentifizierung für das Cisco ASA-VPN.

Der Kunde möchte verstehen, warum es nicht akzeptabel ist , seine Domänencontroller der Öffentlichkeit zugänglich zu machen. Was ist eine akzeptablere Domänenstruktur für eine verteilte Remote-Belegschaft?

Bearbeiten:

Centrify wird für eine Handvoll Mac-Clients verwendet.

46
ewwhite

Ich poste dies hauptsächlich als Antwort, weil jeder seine eigene "gebildete Meinung" hat, die auf Erfahrung, Informationen von Drittanbietern, Hörensagen und Stammeswissen innerhalb der IT basiert. Dies ist jedoch eher eine Liste von Zitaten und Lesungen "direkt" von Microsoft. Ich habe Anführungszeichen verwendet, weil ich sicher bin, dass sie nicht alle Meinungen ihrer Mitarbeiter richtig filtern, aber dies sollte sich dennoch als hilfreich erweisen, wenn Sie nach authoritative Referenzen direkt von Microsoft suchen.


Übrigens, Ich denke auch, dass es SEHR EINFACH ist, DOMAIN CONTROLLER == Active Directory zu sagen, was nicht ganz der Fall ist. AD FS Proxys und andere Mittel (formularbasierte Authentifizierung für OWA, EAS usw.) bieten eine Möglichkeit, AD selbst dem Web "zugänglich zu machen", damit Clients zumindest versuchen können, sich über AD zu authentifizieren Gehen Sie auf die OWA-Site einer anderen Person und versuchen Sie, sich anzumelden. AD erhält die Anforderung zur Authentifizierung auf einem Backend-DC, also ist AD technisch gesehen "ausgesetzt" ... wird jedoch über SSL gesichert und über einen Exchange-Server übertragen.


Zitat Nr. 1

Richtlinien für die Bereitstellung von Windows Server Active Directory auf virtuellen Windows Azure-Maschinen

Bevor Sie zu "Azure ist nicht AD" wechseln, können Sie ADDS auf einer Azure-VM bereitstellen.

Aber um die relevanten Bits zu zitieren:

Setzen Sie STSs niemals direkt dem Internet aus.

Platzieren Sie STS-Instanzen als bewährte Sicherheitsmethode hinter einer Firewall und verbinden Sie sie mit Ihrem Unternehmensnetzwerk, um eine Exposition gegenüber dem Internet zu verhindern. Dies ist wichtig, da die STS-Rolle Sicherheitstoken ausstellt. Infolgedessen sollten sie mit dem gleichen Schutzniveau wie ein Domänencontroller behandelt werden. Wenn ein STS kompromittiert wird, können böswillige Benutzer Probleme verursachen Zugriffstoken, die möglicherweise Ansprüche ihrer Wahl enthalten, auf Anwendungen von vertrauenswürdigen Parteien und andere STS in vertrauenswürdigen Organisationen.

ergo ... setzen Sie Domänencontroller nicht direkt dem Internet aus.

Zitat Nr. 2

Active Directory - Das UnicodePwd-Geheimnis von AD LDS

Das Aussetzen eines Domänencontrollers gegenüber dem Internet ist normalerweise eine schlechte Praxis, unabhängig davon, ob diese Belichtung direkt aus der Produktionsumgebung oder über ein Umkreisnetzwerk erfolgt. Die natürliche Alternative ist So platzieren Sie einen Windows Server 2008-Server mit der AD LDS-Rolle (Active Directory Lightweight Directory Services), die im Umkreisnetzwerk ausgeführt wird.

Zitat Nr. 3 - nicht von MS ... aber dennoch nützlich, um nach vorne zu schauen

Active Directory-as-a-Service? Azure, Intune deutet auf eine in der Cloud gehostete AD-Zukunft hin

Am Ende gibt es keine gute "kurze" Antwort, die die Ziele erfüllt, das Büro des AD-Servers im Austausch gegen eine Azure-Alternative zu befreien. Während Microsoft es Kunden selbstgefällig macht, Active Directory-Domänendienste auf Server 2012- und 2008 R2-Boxen in Azure zu hosten, ist ihre Nützlichkeit nur so gut wie die VPN-Konnektivität, die Sie für Ihre Mitarbeiter aufbringen können. DirectAccess ist zwar eine vielversprechende Technologie, hat aber aufgrund seiner eigenen unglücklichen Einschränkungen die Hände gebunden.

Zitat Nr. 4

Bereitstellen von AD DS oder AD FS und Office 365 mit einmaliger Anmeldung und virtuellen Windows Azure-Maschinen

Domänencontroller und AD FS Server sollten niemals direkt dem Internet ausgesetzt und nur über VPN erreichbar sein

31
TheCleaner

Active Directory (AD) wurde nicht für diese Art der Bereitstellung entwickelt.

Die beim Entwurf des Produkts verwendeten Bedrohungsmodelle setzen eine Bereitstellung hinter der Firewall voraus, bei der einige feindliche Akteure an der Netzwerkgrenze gefiltert werden. Während Sie Windows Server sicher so sichern können, dass es einem öffentlichen Netzwerk ausgesetzt ist, erfordert die korrekte Funktion von Active Directory eine Sicherheitslage, die deutlich lockerer ist als ein Host, der für öffentlich zugängliche Netzwerke gehärtet ist. Ein Los von Diensten muss von einem Domänencontroller (DC) verfügbar gemacht werden, damit AD ordnungsgemäß funktioniert.

Der Vorschlag von Zoredache in den Kommentaren, der sich insbesondere auf OpenVPN bezieht, das als maschinenweiter Dienst mit Zertifikatauthentifizierung ausgeführt wird, passt möglicherweise gut. Wie bereits erwähnt, ist DirectAccess genau das, was Sie benötigen, außer dass es nicht die plattformübergreifende Unterstützung bietet, die Sie möchten.

Nebenbei bemerkt: Ich habe mit der Idee gespielt, IPSEC mit zertifikatbasiertem Transportmodus zu verwenden, um AD direkt dem Internet zugänglich zu machen, hatte aber nie Zeit dafür. Microsoft hat im Zeitrahmen von Windows Server 2008/Vista Änderungen vorgenommen, die dies angeblich möglich gemacht haben, aber ich habe es nie wirklich ausgeübt.

19
Evan Anderson

Was alle anderen gesagt haben. Ich bin besonders nervös wegen der von Christopher Karel erwähnten Brute-Force-Versuche. Eine Präsentation auf der letzten Def Con war zum Thema:

Sie denken also, Ihr Domänencontroller ist sicher?

JUSTIN HENDRICKS SECURITY ENGINEER, Microsoft

Domänencontroller sind die Kronjuwelen einer Organisation. Sobald sie fallen, fällt alles in der Domäne. Unternehmen unternehmen große Anstrengungen, um ihre Domänencontroller zu sichern. Oftmals sichern sie jedoch die zur Verwaltung dieser Server verwendete Software nicht ordnungsgemäß.

In dieser Präsentation werden unkonventionelle Methoden zur Gewinnung von Domänenadministratoren durch Missbrauch häufig verwendeter Verwaltungssoftware behandelt, die von Unternehmen bereitgestellt und verwendet werden.

Justin Hendricks arbeitet im Office 365-Sicherheitsteam, wo er an Red Teaming, Penetrationstests, Sicherheitsforschung, Codeüberprüfung und Tool-Entwicklung beteiligt ist.

Ich bin sicher, Sie können viele andere Beispiele finden. Ich suchte nach Artikeln über Domänencontroller und Hacking in der Hoffnung, eine Beschreibung zu erhalten, wie schnell die DC gefunden werden würde usw.), aber ich denke, das reicht für den Moment.

15

Wenn Sie versuchen, das Management zu überzeugen, wäre ein guter Anfang:

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

Update : Siehe dieser Technet-Artikel zum Sichern von Domänencontrollern gegen Angriffe und den Abschnitt Perimeter Firewall Restrictions das besagt:

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

Und der Abschnitt mit dem Titel Blocking Internet Access for Domain Controllers welche Staaten:

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

Ich bin sicher, Sie können eine Microsoft-Dokumentation zu diesem Thema zusammenstellen, das ist es also. Darüber hinaus könnten Sie die Gefahren eines solchen Schrittes wie folgt angeben:

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

Zwischengespeicherte Anmeldeinformationen sind genau das - zwischengespeicherte. Sie arbeiten für den lokalen Computer, wenn dieser kann keine Verbindung zur Domäne herstellen, aber wenn dieses Konto deaktiviert wäre, würden sie für keine Netzwerkressource (svn, vpn, smb, fbi, cia,) funktionieren. etc) also brauchen sie sich darüber keine Sorgen zu machen. Denken Sie auch daran, dass Benutzer ohnehin bereits die vollen Rechte für alle Dateien in ihrem Profilordner auf einem lokalen Computer (und wahrscheinlich Wechselmedien) haben, sodass Anmeldeinformationen deaktiviert sind oder sie mit diesen Daten nicht das tun können, was sie möchten. Sie würden auch nicht für den lokalen Computer funktionieren, wenn er sich wieder mit dem Netzwerk verbindet.

Beziehen Sie sich auf die Dienste, die Active Directory oder ein Domänencontroller bereitstellt, z. B. LDAP? In diesem Fall wird LDAP zum Zwecke der Authentifizierung und Verzeichnisabfrage häufig sicher aufgebrochen. Das Ausschalten der Windows-Firewall (oder das Öffnen aller erforderlichen Ports für die Öffentlichkeit - in diesem Beispiel dasselbe) kann jedoch zu schwerwiegenden Problemen führen.

AD ist nicht wirklich verwalten Macs, daher wäre eine separate Lösung erforderlich (denken Sie an OS X Server). Sie können einen Mac einer Domäne hinzufügen, dies bedeutet jedoch nur, dass sie sich mit Netzwerkanmeldeinformationen authentifizieren, Domänenadministratoren als lokale Administratoren auf dem Mac festlegen usw. Keine Gruppenrichtlinie. MS versucht, diesen Grund mit neueren Versionen von SCCM) zu durchbrechen, die behaupten, Anwendungen auf Macs und * nix-Boxen bereitstellen zu können, aber ich habe es in einer Produktionsumgebung noch nicht gesehen Ich glaube auch, dass Sie die Macs so konfigurieren könnten, dass sie eine Verbindung zu OS X Server herstellen, der sich bei Ihrem AD-basierten Verzeichnis authentifiziert, aber ich könnte mich irren.

Abgesehen davon könnten einige kreative Lösungen entwickelt werden, wie beispielsweise Evans Vorschlag, OpenVPN als Service zu verwenden und das Maschinenzertifikat zu deaktivieren, wenn/wenn die Zeit gekommen ist, diesen Mitarbeiter gehen zu lassen.

Es hört sich so an, als ob alles auf Google basiert. Google fungiert also als Ihr LDAP-Server? Ich würde meinem Kunden empfehlen, es so zu halten, wenn es überhaupt möglich ist. Ich kenne die Art Ihres Unternehmens nicht, aber für webbasierte Apps wie einen Git- oder Redmine-Server kann die Authentifizierung bei OAuth unter Verwendung eines Google-Kontos erfolgen, selbst wenn die Einrichtung im eigenen Haus erfolgt.

Schließlich würde ein Roadwarrior-Setup wie dieses fast erfordern ein VPN, um erfolgreich zu sein. Sobald die Computer ins Büro gebracht und konfiguriert wurden (oder per Skript remote konfiguriert wurden), müssen sie über Änderungen in der Konfiguration verfügen.

Die Macs würden zusätzlich zum VPN einen separaten Verwaltungsansatz benötigen. Es ist schade, dass sie keine echten Mac-Server mehr herstellen, aber sie hatten bei meiner letzten Überprüfung (vor ein paar Jahren) einige anständige Richtlinienimplementierungen in OS X Server ).

14
MDMoore313

Es ist bedauerlich, dass DirectAccess nur für Win7 + Enterprise Edition verfügbar ist, da es auf Ihre Anfrage zugeschnitten ist. Aber wenn Sie Ihre Edition nicht kennen und sehen, dass Sie MacOS haben, funktioniert das nicht.

/ Bearbeiten - Es sieht so aus, als hätten einige Drittanbieter behauptet, sie hätten DA-Clients für Unices: http://www.centrify.com/blogs/tomkemp/what_is_Microsoft_directaccess_and_unix_linux_interoperability.asp

Es stehen MDM-Lösungen zur Verfügung, die Ihren Anforderungen entsprechen. Wir rollen einen von ihnen (MAAS360) an einen Kunden aus, der sich in einer ähnlichen Position befindet.

7
mfinni

Dies wäre offensichtlich ein erhebliches Sicherheitsrisiko. Außerdem würde es wahrscheinlich nicht so gut funktionieren, wie Sie es möchten. Wenn zufällige Personen im Internet versuchen können, sich in Ihrer AD-Umgebung anzumelden, stehen die Chancen gut, dass alle Benutzer gesperrt werden. Für immer. Das Entfernen der Sperranforderungen bedeutet, dass die Brute-Force-Überprüfung auf einfache Kennwörter ziemlich einfach ist.

Noch wichtiger ist, dass Sie keine Probleme haben sollten, Ihr Ziel zu implementieren (Endbenutzer, die sich mit Domänenanmeldeinformationen bei einem Laptop anmelden), ohne die AD-Server direkt zugänglich zu machen. Windows-Computer können nämlich die letzten X erfolgreichen Anmeldungen zwischenspeichern, sodass dieselben Anmeldeinformationen funktionieren, wenn die Verbindung getrennt wird. Dies bedeutet, dass Endbenutzer sich anmelden und nützliche Arbeit leisten können, ohne Ihre AD-Server berühren zu müssen. Sie müssen natürlich ein VPN verwenden, um eine Verbindung zu anderen wichtigen Unternehmensressourcen herzustellen, und können gleichzeitig die AD/GPO-Einstellungen aktualisieren.

5

Ewwhite,

Ihre Frage ist äußerst gültig und verdient eine sorgfältige Prüfung.

Alle Sicherheitsexperten empfehlen Sicherheitsebenen vor jeder Netzwerkressource, einschließlich SPI Firewalls, IDS, Host-basierte Firewalls usw.). Sie sollten immer eine Proxy-Perimeter-Gateway-Firewall wie ISA (jetzt TMG) ​​wenn möglich.

In Microsoft Active Directory 2003+ wurden jedoch keine größeren Sicherheitslücken öffentlich bekannt gegeben. Die LDAP-Technologie und ihre Hash-Algorithmen sind im Allgemeinen sehr sicher. Es ist wohl sicherer als das SSL-VPN, wenn dieses SSL-VPN OpenSSL ausführt und anfällig für Herzblutungen ist.

Ich würde 5 Dinge warnen:

  1. Seien Sie besorgt über die anderen Dienste, mit denen das Netzwerk konfrontiert ist, wie z. B. Terminalserver, DNS-Dienste, CIFS und insbesondere IIS mit seiner schrecklichen Sicherheitsaufzeichnung).

  2. Verwenden Sie LDAPS mit einem Sicherheitszertifikat, um zu vermeiden, dass Klartextdomänenanmeldeinformationen über die Leitung übertragen werden. Dies geschieht automatisch nach der Installation von Certificate Services (verwenden Sie einen separaten Computer für PKI).

  3. Setzen Sie einen Paket-Sniffer auf die Schnittstelle und beobachten Sie Ihren Datenverkehr, korrigieren Sie alle Klartext-Passwörter, da die Firewall oder nicht, wenn Sie kein VPN oder LDAPS verwenden, senden einige Legacy-Systeme Klartext-Passwörter.

  4. Wissen Sie, dass MITM-Angriffe die nativen Authentifizierungsmechanismen dazu zwingen können, ein Downgrade durchzuführen und Kennwörter einer schwächeren NTLM-Authentifizierung auszusetzen.

  5. Beachten Sie einige Sicherheitslücken bei der Benutzeraufzählung, die möglicherweise noch vorhanden sind.

Trotzdem verfügt Active Directory über eine hervorragende Erfolgsbilanz im Bereich Sicherheit. Darüber hinaus speichert MS Active Directory keine Kennwörter, sondern nur Hashes, die möglicherweise auch die Schwere eines Kompromisses verringern.

Sie können von einer nahtloseren Sicherheitsinfrastruktur profitieren, müssen keine speziellen DNS-Server einrichten oder domain.local verwenden und können Ihre eigentliche Domain im öffentlichen Internet wie domain.com verwenden.

Meiner beruflichen Meinung nach hat die öffentliche Bereitstellung von Sicherheitstechnologien wie Active Directory einen erheblichen Vorteil, da andere Technologien wie Exchange, DNS und Webserver einfach keinen Nutzen und das gesamte Risiko bieten.

Hinweis: Wenn Sie Active Directory bereitstellen, enthält es einen DNS-Server. Deaktivieren Sie die Rekursion auf Ihren DNS-Servern (standardmäßig aktiviert), da Sie sonst unbedingt an Denial-of-Service-Angriffen teilnehmen.

Prost,

-Brian

2