Risiko Share einrichten

Früher war die Verwaltung von Windows Servern und SMB-Freigaben relativ einfach aber Microsoft hat durch einen "Assistenten" zur Freigabe indirekt ein Risiko eingebaut, welche Sie wissen sollten

Auslöser

Bei einem Routine-Audit einer Umgebung mit Windows Servern ist mir eine Freigabe auf einem Server aufgefallen, bei der Domain Benutzer deutlich zu viele Rechte hatten. Es gibt um einen Job/Automatisierungsserver, auf dem verschiedene Skripte mit privilegierten Berechtigungen verschiedene Routineaufgaben ausgeführt und die Ergebnisse für Anwender bereitgestellt haben. Solche Konstruktionen haben wir bei sehr vielen Kunden, um Reports für die Fachabteilungen zu erzeugen. Der Prozess ist recht einfach:

  • Taskplaner startet Skript in Verzeichnis
    Der Windows Taskplaner startet ein CMD, VBS, PS1-Skript , welches in einem Verzeichnis vorgehalten wird.
  • Skript schreibt Ausgabe in "HTML/EXPORT"-Unterverzeichnis
    Um eine Trennung von "Code" und Daten zu erreichen, gibt es unter dem Skript-Verzeichnis ein Unterverzeichnis "HTML" für die Ergebnisse.
  • Logging nach "LOG"
    Die Aktivität des Skripts wird mit "Start-Transcript" in ein eigenes Verzeichnis protokolliert.
  • Zugriff der Benutzer per SMB oder HTTP
    Damit die Anwender die Ergebnisse einsehen können, werden Sie im IIS als statische Webseite eingebunden oder einfach als SMB-Share freigegeben. Der SMB-Weg ist natürlich nett, wenn die Ausgaben z.B. CSV-Dateien zur Weiterverarbeitung sind und ein Download nicht erforderlich ist.

Das Hauptverzeichnis mit all den Skripten kann auch problemlos mit GIT versioniert werden, wenn wir das "HTML/EXPORT"-Verzeichnis ausschließen. Natürlich könnten die Ausgabeverzeichnisse auch ganz woanders liegen um eine echte Trennung zu erhalten.

Was natürlich nie passieren darf, ist eine Freigabe des Programmcode über "Domain Benutzer" mit entsprechenden Schreibberechtigungen. Aber genau das habe ich in einer Umgebung gefunden und schnellstens behoben. Ich konnte allerdings nicht mehr den Verlauf ermitteln, wie es zu dieser Berechtigung gekommen ist. Wie leicht es aber ist, mit Bordmitteln seine NTFS-Rechte unabsichtlich zu verändern, beschreibe ich auf dieser Seite, auf der ich mir die Funktion der "Einfachen Freigabe" genauer angeschaut habe.

Standardfunktion

Ich habe auf einer Festplatte eine Verzeichnisstruktur angelegt:

C:\Skripte                      Das Basisverzeichnis
C:\Skripte\Report-Mailbox       Das Skriptverzeichnug
C:\Skripte\Report-Mailbox\html  Hier landen die Ausgaben
C:\Skripte\Report-Mailbox\log   Hier ist der Platz für die Logs

Das Skript "Report-Mailbox" erstellt einen Bericht über alle Postfächer und deren Größe und LastLogin und speichert eine HTML-Tabelle ins Verzeichnis "html".

Die Standardrechte für alle Verzeichnisse hier sind: (vereinfacht)

Benutzer          Permission  Inherited
==========================================
SYSTEM            FULL        (Inherited from C:\)
Users             READ        (Inherited from C:\)
Administrators    FULL        (Inherited from C:\)
adm-fcarius       FULL        (Inherited from C:\)
Creators/Owner    FULL        (Inherited from C:\)

Soweit ist das noch nicht überraschend.

Simple Sharing

Der nächste Schritt war natürlich die Freigabe des HTML-Verzeichnis über den Explorer für die jeweilige Gruppe. Wie von Microsoft vorgesehen wähle ich das passende Kontextmenü:

 

Interessant finde ich hier, dass ich im Windows Explorer schon die Option "Stop sharing" sehe, obwohl ich noch nichts "freigegeben" habe. In meinem Beispiel habe die Gruppe "ADGroup1" addiert und gespeichert:

Microsoft hat aber hier nicht den Weg gewählt, die Freigabe auf diese Benutzer und Gruppen zu beschränken. Auf der klassischen Freigabe selbst ist "Everyone/Jeder" mit Vollzugriff  eingetragen:

Die Steuerung des Zugriffs erfolgt über die NTFS-Berechtigungen, die wie folgt aussehen:

Die Kartekarte "Freigabe" zeigt die gleichen beiden Einträge, die auch bei der vereinfachten Anzeige sichtbar sind.

Irritierend finde ich aber, dass im gleichen Fenster ein "Share"-Tab vorhanden ist, der die echten Berechtigungen auf der Freigabe anzeigt.

Das ist einmal gut, damit ein Administrator nicht im Unklaren gelassen wird aber kann auch verwirren.

Sharing zurückbauen

Über das Kontextmenü kann ich auf einem Verzeichnis sehr einfach wieder die Freigabe entfernen. Allerdings muss ich dazu wissen, dass der Ordner freigegeben ist, denn im Windows Explorer wird dies nicht mehr angezeigt. Im Zweifel müssen Sie im Servermanager schauen, welche Freigabe es gibt:

Die Option "Stop Sharing" gibt es übrigens auf jedem Verzeichnis, auch wenn diese aktuell nicht freigegeben ist:

Achtung: Wenn Sie auf einem nicht freigegebenen Verzeichnis ein "Stop Sharing" einfach durchklicken, dann ändert der Explorer dennoch die Berechtigungen!

Im nächsten Dialog werde ich noch einmal gefragt, was ich machen möchte.

Wenn ich hier auch noch "Stop Sharing" klicke, dann entfernt der Windows Explorer sowohl die Freigabe als auch die Benutzer die über die Freigabe zusätzlich berechtigt wurden. Zurück bleiben bei mir nur folgende drei Eintröge

Benutzer           Permission   Inherited       Kommentar
==================================================================================
SYSTEM             FULL         NONE            Das Konto ist wohl immer dabei
Administrators     FULL         NONE           Auch die lokalen Administratoren werden addiert
adm-fcarius        FULL         NONE           Das ist in meinem Fall der "Creatore"

Allerdings wird die Vererbung immer abgeschaltet. Das passiert auch, wenn der Ordner vorher gar nicht freigegeben war uns sie irrtümlich auf "Stop Sharing" geklickt haben.

Das ist aus meiner Sicht überraschend.

Also habe ich diese Änderungen wieder Rückgängig gemacht, in dem ich der Vererbung reaktiviert und alle Rechte ersetzt habe:

Damit war die Ausgangssituation wieder hergestellt.

Advanced Sharing

Die altgedienten Administratoren kennen die "moderne" Variante des Sharing oft nicht, weil sie schon immer eine Freigabe entweder per Kommandozeile "NET SHARE", den Servermanager oder die Checkbox eingerichtet und entfernt haben. Bei diesem Weg wird der Eintrag im LanmanServer entfernt aber an den Berechtigungen nichts geändert:

Die ist also der aus meiner Sicht "nachvollziehbarere Weg", über den ich dann auch die Berechtigungen auf dem Share selbst eintrage

Verschachtelte Freigaben Sub vor Root

Abschließend hat mich noch interessiert, wie sich Windows bei mehreren Freigaben innerhalb des gleichen Baums verhält. Interessant ist, dass es dabei auf die Reihenfolge ankommen.

Ich habe zuerst das Unterverzeichnis und dann das Stammverzeichnis wie folgt freigegeben:

           Verzeichnis                         ShareName          Rechte 
=============================================================================
Schritt1:  C:\Skripte\Report-MailboxHTML\HTML  HTML         ADGroup2:Read
Schritt2:  C:\Skripte                          Skripte"     ADGroup1:Read

Bei der Freigabe des Stammverzeichnisses wurde ich gefragt, wie ich mit dem Unterverzeichnis umgehen wollte

Wenn ich hier nun "Change settings" mache, dann blieb das Unterverzeichnis als Freigabe erhalten aber die Berechtigungen von "ADGroup2" wurden entfernt und die Vererbung wurde wieder aktiviert:

Wenn ich bei der Rückfrag aber ein "Don't change Settings" anwähle, dann richtet der Assistent oben den Share wieder mit unterbrochener Vererbung ein aber das Unterverzeichnis bleibt unangetastet.

Egal, welche Option sie nun wählen, müssen Sie ggfls. nacharbeiten. Bei der ersten Option verliert die vorher berechtigte Gruppe in dem Unterverzeichnis die Berechtigungen, obwohl die Freigabe noch vorhanden ist. Bei der zweiten Option kann über die neue Freigabe nur ein Teil der Verzeichnisse erreicht werden, wenn die Berechtigungen im Unterverzeichnis restriktiver gesetzt sind.

Generell würde ich davon abraten, Freigaben so überlappend mit dem Assistenten zu setzen und damit das Risiko einzugehen, ihre NTFS-Rechte zu verändern.

Verschachtelte Freigaben Root vor SUB

Damit fehlt noch die Variante, bei der zuerst das übergeordnete Verzeichnis freigegeben wird und danach das tiefer liegende Verzeichnis

Verzeichnis                         ShareName          Rechte 
=============================================================================
C:\Skripte                          Skripte"     ADGroup1:Read
C:\Skripte\Report-MailboxHTML\HTML  HTML         ADGroup2:Read

Die Berechtigungsgruppen habe ich unverändert gelassen. Bei der Einrichtung der zweiten Freigabe wurde dann aber schon die von oben vererbte Berechtigung der Gruppe ADGroup1 mit angezeigt:

Der Assistent liest dazu die Berechtigungen des Verzeichnis aus um die "eingebauten Rechte" von Administratoren und Creator zu ignorieren. Wenn ich hier nun die "ADGRoup1" entferne, dann wird die Vererbung auf dem Verzeichnis unterbrochen, so dass nur doch die hier angegeben Berechtigungen greifen.

Allerdings wird die Freigabe "HTML" nicht eingerichtet! Es werden nur die Rechte geändert.

Daher habe ich den Prozess wiederholt und die bisher berechtigten Objekte nicht entfernt sondern nur die Gruppe ADGroup2 zusätzlich addiert. Bei dem Vorgang wurde die NTFS-Vererbung nicht abgeschaltet und einfach nur das Recht addiert:

Allerdings wurde auch hier die gewünschte Freigabe "HTML" nicht angelegt. Beim Klick auf die Eigenschaften wird eine Freigabe angezeigt aber diesmal die weiter oben liegende Freigabe:

Erst nachdem ich unter "Advanced Sharing" die Checkbox gesetzt habe, wurde die zusätzliche Freigabe wieder eingerichtet.

Rechte auf der Wurzel

Da auf einer NTFS-Partition standardmäßig die Vererbung von Rechten aktiv ist, lohnt sich auch ein Blick auf die Wurzel. Her vergleiche ich die Rechte auf der Betriebssystempartition "C:" von Windows und einer separaten Datenpartition "E:", die beide mit NTFS formatiert wurden.

Leider hat Windows die Ausgabe etwas umsortiert aber es sind alle Einträge identisch vorhanden. Es gibt nur zwei Unterschiede: Der "Owner" ist einmal "TrustedInstaller" und auf der Datenpartition "System" und auf der Datenpartition hat "Everyone" das READ/EXECUTE-Recht mit der Einschränkung auf nur diesen Ordner.

Risiko: SharePermissions

Aus meiner Sicht ist es die falsche Entscheidung, auf dem Share immer die folgenden Berechtigungen einzuräumen:

Everyone      : Full Control
Administrators: Full Control

Es wäre so einfach auf dem Share die Berechtigungen zu hinterlegen, die im Assistenten eingetragen wurden. Das würde auch bei einer späteren erneuten Konfiguration es einfacherer und damit sicherer machen, die Liste der aktuell berechtigten Benutzer und Gruppen aus dem Share zu lesen und nicht aus den NTFS-Rechten zu filtern. Natürlich behindert dies eine Ausweitung von Berechtigungen auf Datei oder Ordner-Ebene und ist sicher nichts für kein "Gruppenlaufwerk" mit komplexer Hierarchie. Vergleichen Sie einmal eine Dateifreigabe mit einem freigegeben Postfach oder einer Sharepoint Bibliothek oder einem OneDrive-Ordner.

Sie sollten dennoch immer auch die Rechte auf Dateien korrekte setzen, da z.B. Suchmaschinen nichts über die Rechte der "Einsprungadresse" wissen und in Ergebnissen dann vielleicht zuviel anzeigen.

Mein Vorschlag ist hier, die Rechte auf dem Share auf das Minimum zu reduzieren und nicht auf "Everyone:Full" zu belassen.

Risiko: Nicht-Vererbung

Der zweite Baustein betrifft ihren Prozess zur Einrichtung von Freigaben und Berechtigungen. Ich propagiere den Weg, dass Berechtigungen von oben nach untern Zunehmen aber möglichst nicht reduziert werden. Nur in wenigen Ausnahmefällen würde ich die Vererbung unterbrechen oder sogar mit DENY-ACLs arbeiten wollen. Gerade auf Datenverzeichnissen ist es für Administratoren aber auch für Monitoring- und Auswerte-Skripte und für eine Suche eher störend, wenn Teile des Datenraums nicht sichtbar sind oder solche Prozesse dann immer mit administrativen Berechtigungen gestartet werden müssen.

Ist ist immer nervig, wenn Sie den Füllgrad einer Festplatte auf der Wurzel betrachten und die rekursive Aufzählung aller Dateien z.B. mit Sequoia View und WinDirStat ganz andere niedrigere Zahlen liefert und sie dann erst einmal die "dunkle Materie" suchen müssen,

Daher sehe ich in der Unterbrechung der Vererbung an sich ein Risiko, da damit auch legitime Zugriffe von darüber liegenden Verzeichnissen erst einmal unterbunden werden. Wenn z.B. mein Skript mit einem Dienstkonto oder "Group Managed Service Account (GMSA)" läuft, würde ich nicht automatisch daran denke, dass die Einrichtung einer neuen Freigabe dieses Recht abschneidet. Erst im Fehlerfall wird ein Administrator dies letztlich herausfinden und hat nun die Wahl zwischen:

  • Dienstkonto addieren
    Damit löse ich das primäre Problem aber in meinen Netzwerken ist die Anzahl der Administratoren gering aber so kann diese Personengruppe der "Operatoren" diese Verzeichnis weiterhin nicht sehen.
  • Vererbung reaktivieren
    Über diesen Weg könnten aber viel mehr Berechtigungen von oben herunter. Schon die Standardberechtigung "User:Read" von der Wurzel würde in Verbindung mit der Freigabe die Daten für jeden authentifizierten Benutzer offenlegen, was sicher nicht gewünscht ist

Ich schüttle immer noch den Kopf, dass Microsoft hier diesen Weg gewählt hat, auf dem Share selbst die Rechte komplett zu öffnen und dann mit NTFS-Rechten und unterbrochenen Vererbungen den Zugriff zu steuern. Es wäre doch sehr viel einfacher gewesen, auf der Freigabe mit Berechtigungen zu arbeiten und dem Admin auf dem Server selbst.

Aktionsplan ShareEnum

Wie ich anfangs schon geschrieben habe, kann ich nicht nachvollziehen, wie bei auf dem fraglichen Server die Gruppe "Users" auf dem Server wirklich Schreibrechte hatte und warum das Basisverzeichnis aller Skripte so freigegeben wurde, wie es nur über die neue Explorer-Freigabe erfolgt sein konnte, so dass über Share nun "Jeder:Vollzugriff" hatte und die NTFS-Freigaben dieses Recht auch nicht weiter eingeschränkt haben. Schon das Lesen von Powershell-Skripten für normale Anwender ist zu verhindern, denn allzu oft stehen in den Codes doch die ein oder anderen Zugangsdaten oder andere schützenswerte Informationen. Ein Schreibzugriff ist sogar noch schlimmer, wenn damit Code verändert werden könnte, der mit privilegierten Identitäten ausgeführt wird.

Insofern sollten Sie die Change nutzen, und bei all ihren Servern die Freigaben überprüfen. Ein sehr einfach zu nutzendes Tool ist z.B. ShareEnum.

Es holt sich alle Computerkonten und zählt alle Freigaben auf. Sie sollten immer alarmiert sein, wenn die Berechtigungen auf den Freigaben nicht nur explizite Berechtigungsgruppen sondern z.B. "Jeder" enthält. Dann ist das Risiko hoch, dass unpassend gesetzte NTFS-Berechtigungen den Zugriff auf zu viele Informationen erlauben.

Sicher ist auch eine Automatisierung per PowerShell  möglich.

Empfehlung

Ich habe mir angewöhnt, Freigaben bewusst durch explizite Angabe der Berechtigungen auf der Freigabe UND Steuerung der NTFS-Rechte zu erstellen und zu verwalten. Ich vermeide den "Assistenten" aus dem Windows Explorer, welcher eine Freigabe mit "Everyone:Full" erstellt, die Vererbung abschaltet und von oben nicht mehr wirksame Berechtigungen nicht einmal kopiert.

Weitere Links