Fileserver aus Domain nehmen zur erhöhung der Sicherheit

[peter999 24]

Hallo zusammen,

 

ich habe gerade folgenden Vorschlag von einem Dienstleister erhalten. Zur Erhöhung der Sicherheit unseres Fileservers sollen wir diesen aus der Domain nehmen. Falls unser Betriebsnetz übernommen wird, wäre bei entsprechend konfigurierten Diensten auf dem Fileserver die Gefahr von Verschlüsselung usw. viel geringer. u.a. weil die User die im AD angelegt sind keinen Zugriff auf den Fileserver haben.

Was genau gewinne ich denn da? Ich muss die User doppelt anlegen, ich hab Probleme mit Gruppen und allem anderen. Zusätzlich ist es doch, bei einem nicht Domain Mitglied, ein leichtes die Kennwörter zu umgehen, oder sehe ich das falsch? Ich sehe es eher genau andersrum, man nimmt sich doch die Sicherheit eines ADs mit so einer Aktion.

Zusätzlich habe ich auch noch nie etwas dergleichen gelesen, also gehe ist es vermutlich eine blö** Idee?

 

Vielen Dank für eure Einschätzungen,

Peter

[zahni 550]

Hm, und wie sollen sich die Anwender dann mit dem Fileserver verbinden?

Und warum empfiehlt Dir der DL keine sinnvollen Schutzmaßnamen, wie Applocker / SRP / Contentfilter Mail und Proxy?

[MurdocX 949]

(Edit)

Hallo,

 

sobald der Fileserver aus dem AD genommen wird, dann fällt die Authentifizierung von Kerberos auf NTLM für die zugreifenden Benutzer. Damit sind die Benutzer Passwort-Hashes noch schlechter gegen ein Abgreifen gesichert. Die Daten können dennoch mit Berechtigung des Benutzers durch die Malware auf dem Fileserver verschlüsselt werden. 

 

Mehr Sicherheit gegen eine Übernahme ist folgendes:

• Einsetzen der lokalen Windows-Firewall
  • Protokolle zur Administration des Servers zu unterbinden oder einschränken (WMI, WinRM, RDP, NP, SMB (Auto Shares: $admin, C$))
  • Eingehende Administrative Verbindungen restriktiveren und validieren des zugreifenden durch IPSec oder IP.
• Festlegen der Windows-Firewall-Richtlinien durch eine Gruppenrichtline
• Durchdachtes Backup & Restore - Konzept nach den Firmen definierten Anforderungen

bearbeitet 13. November 2022 von MurdocX
Konkretisierung

[daabm 1.354]

Was habt Ihr, ist doch ein valider Ansatz: Entziehe den Usern den Zugriff, dann kann in ihrem Kontext kein Trojaner mehr Schaden anrichten... SCNR

[cj_berlin 1.312]

vor 2 Stunden schrieb MurdocX:

Ein besserer Ansatz wäre gewesen Protokolle zur Administration des Servers, wie z.B. SMB ... zu unterbinden. 

Wie unterbinde ich SMB auf einem Fileserver? 

[MurdocX 949]

vor 1 Minute schrieb cj_berlin:

Wie unterbinde ich SMB auf einem Fileserver? 

Ich dachte es wäre klar gewesen, das es sich auf die Klammern bezieht ;) 

[Lian 2.421]

Zitate mit Auslassungen fallen unter schwarze Rhetorik, auch wenn wir uns nur textuell austauschen...

 

[daabm 1.354]

vor 3 Stunden schrieb peter999:

 

Falls unser Betriebsnetz übernommen wird, wäre bei entsprechend konfigurierten Diensten auf dem Fileserver die Gefahr von Verschlüsselung usw. viel geringer. u.a. weil die User die im AD angelegt sind keinen Zugriff auf den Fileserver haben.

 

Um mal auf den realen Boden der Tatsachen zurückzukommen:

 

Wenn ein User kompromittiert ist, gewinnt Ihr damit gar nichts. Der User braucht Zugriff auf "seine" Dateien, und damit können diese Dateien in seinem Kontext verschlüsselt werden. Wurde ja oben schon genannt: Ihr verliert Kerberos und habt zwangsweise NTLM-Fallback mit allen Nachteilen.

 

Wenn ein Domain Admin (DA) kompromittiert ist, könnte man darauf kommen, das als valide Maßnahme anzusehen. Ist aber denkbar schlecht... Ein DA sollte auf einem Fileserver nichts zu tun haben, idealerweise kann er sich weder lokal anmelden noch remote zugreifen. Ein DA macht nichts anderes als die Domäne zu verwalten. Er verwaltet keine Fileserver und auch keine Shares oder ACLs auf Fileservern. Er kann sich nur auf DCs anmelden.

 

 

[WSUSPraxis 48]

Peter ich will Dir nicht zu nahe treten ! Aber ich würde den DL vom Hof jagen wenn dieser die Mehrwerte nicht erklären kann !