Offene Fragen

Damit ist der Schutz für alle Dateien auf einem Dateiserver gegeben, die älter als die ausgewählte Frist an Tagen sind. Aber als Produkt würde ich das Skript noch nicht bezeichnen. Dazu gibt es noch einige offene Aufgabenstellungen:

Entsperrung

Nun kann es aber doch wieder vorkommen, dass eine Datei oder ein Ordner zumindest temporär "entsperrt" werden muss. Für einen normalen Anwender ist es nicht möglich, dieses "Deny" zu umgehen, es sei denn er wäre auch Administrator mit entsprechenden Rechten und würde bei der UAC-Nachfrage auch noch zustimmen. Das ist aber kein praktikabler Weg. Dabei jedes mal den Administrator "wach" zu machen, ist natürlich keine Lösung. Aber auch hier gibt es Möglichkeiten, eine solche Sperre per "Self Service" durch den Anwender frei zu geben:

Aktuell habe ich noch keine dieser Optionen umgesetzt. Zuerst war mit der Schutz, die Dokumentation und Tests wichtiger. Starten Sie doch erst mal mit 90 Tagen. Sie werden sich wundern, wie selten jemand dann um eine "Entsperrung" bittet.

Denkbar sind mehrere Optionen:

  • WebService mit ClientAdd-on
    Ich könnte mir vorstellen, dass auf dem Fileserver ein kleiner Webservice aktiv ist und beim Anwender z.B. eine Explorer-Add-on diesen Dienst zum entsperren nutzt. Der Anwender würde dann im Windows Explorer über das Kontextmenü einfach ein "Entsperren" anfordern und der Webservice könnte in Echtzeit die ACLs wieder entfernen. Sinnvoll nutzbar ist diese Lösung nur mit einem passenden Client. Damit aber ein Virus dann nicht genau diese Logik missbraucht, sollte der Serverprozess den Vorgang zumindest drosseln oder mit Captchas o.ä. absichern.
  • Kopieren und Warten
    Eine andere Methode wäre eine eigene Freigabe "UNLOCK" o.ä., in die der Anwender einfach die noch geschützte Datei "kopiert". Ein auf dem Server daraufhin angestoßenes Skript könnte die originale Datei anhand des Namens und der Größe auf dem Server finden und die Sperre entfernen. Natürlich sollte das Skript vielleicht einen Index über alle Dateien haben, um schnell zu reagieren. Über den "Owner" der Datei könne das Skript dem Mitarbeiter ja eine Meldung senden, dass die Datei wieder entsperrt ist. Störend bei dieser Lösung ist, dass die Datei kopiert wird, was bei WAN-Anwendern Datenvolumen bedeutet und dass die Datei temporär in einem allgemeinen Share zu finden wäre. Leider kennt Windows keine Rechte wie damals bei NetWare, dass man eine Datei nur anlegen und schreiben aber danach nicht mehr öffnen konnte.
  • WebServer mit Mehrwert
    Daher wäre auch eine dritte Lösung interessant, insbesondere bei der Arbeit mit UNC-Pfaden. Wenn ich auf "\\servername\share\verzeichnis\Datei.ext" zugreife, dann ist es auch für Anwender kein Problem daraus ein "https://servername\share\verzeichnis\Datei.ext" zu machen. Damit landet der Anwender dann aber auf einer Webseite, die neben den Dateien eben auch einen "Unlock"-Button anbieten kann.
    Als Service könnte man die Url zum Verzeichnis sogar als URL-Datei mit in das Verzeichnis ablegen. Mit dem passenden Namen würde sie auch ganz oben stehen.

Durch die Änderung würden die gewünschten Dateien beschreibbar und wenn der Anwender diese dann ändert, dann sind sie auch wieder solange ungeschützt, bis das Skript läuft und die Ruhezeit noch nicht erreicht ist. Ändert der Anwender nichts, dann ist die Datei nach dem nächsten Lauf schon wieder geschützt.

Nächste Version?

Der Einsatz eines Powershell-Scripts ist für Firmenadministratoren einfach möglich, aber für den normalen Privatanwender nicht wirklich nutzbar. Ideal wäre es, wenn es eine einfach zu installierende Software gäbe, die genau dieses Schutzprinzip auch auf einem Einzelplatzrechner umsetzt. Er könnte in den Heimatlaufwerken und gemeinsamen Laufwerken alle länger nicht genutzte Dateien nicht einfach "ReadOnly" setzen, sondern per DENY die Rechte für "normale" Anwender verbieten. Mit einem passenden "Entsperrprogramm", welches z.B. mit Captcha o.ä. ein Missbrauch durch einen neueren Trojaner verhindert, könnte er dann Ordner oder Dateien wieder entsperren. Es müsste also einen Windows Installer für eine Version als "Dienst" oder geplanten Task geben, der als LocalSystem die Rechte setzt und per Tray-Icon o.ä. einen einfachen Entsperrzugang erlaubt.

Es geht natürlich dennoch nichts über ein gutes Backup mit mehreren Generationen auf ein unabhängiges Speichermedium.

Offene Punkte

Die Lösung mit Powershell funktioniert und ist sogar recht flott und für Administratoren mit ihrem Server sehr schnell einzusetzen. für einen unbeobachteten Dauerbetrieb wären einige Dinge noch besser zu machen.

  • RemoveDenyACL
    Aktuell habe ich noch kein Skript, welches genau diese Rechtevergabe rückgängig macht. Kritisch ist das nicht, denn Sie können ja einfach die Gruppe "leer" machen und so die Wirkung außer Kraft setzen.
  • Error Handling und Performance Counter
    Aktuell ist es nur ein einfaches Skript ohne umfangreiche Fehlerbehandlung, Benachrichtigungen oder Performance Counter. Es ist ein schneller Weg z.B. über einen Taskplaner ältere Dateien zu schützen.
  • Kein Schutz für regelmäßig geänderte Dateien.
    Wenn Sie an Access-Datenbanken oder andere Buchhaltungsdatenbanken denken, die nicht über eine Client-Server-Lösung angesprochen werden, dann ist hier so ein Schutz kaum zu schaffen. Ein "Deny-Write"-ACL würde die Funktion nachhaltig stören. Auch eine Outlook-PST-Datei kann nicht genutzt werden, wenn Sie diese nur Lesen können. Das Skript kann solche Dateien noch nicht erkennen. Eine Exclude-Liste könnte helfen. OST, PST, MDB sind schnell umgesetzt aber nur ein Teil einer Lösung. Vielleicht wären "Exclude-Pfade" hier eine sinnvolle Erweiterung oder die Steuerung über eine versteckte Datei.
  • NTFS-Rechte
  • 260 Zeichen Pfadlänge
    Powershell kann von Hause aus maximal 260 Zeichen im Fullname. Sehr tiefe Verzeichnisstrukturen werden einfach übersprungen.
  • Change Detection mit USN-Journal ?
    Auch wenn die Suche durch 100.000 lokale Dateien sehr schnell geht, könnte es interessant sein, die geänderten Dateien über andere Wege zu suchen. NTFS führt ein USN-Journal, über die Änderungen nachverfolgt werden können, die sich auch nicht mit NTFS-Rechten verbergen lassen. Vielleicht ist dies ein besserer Weg.
  • Windows Programm oder Dienst
    Nicht jeder kann mit Powershell umgehen und speziell Privatanwender haben damit vielleicht ein Problem. Insofern könnte ich mir auch einfach ein Windows GUI-Programm vorstellen, welche interaktiv oder per Taskplaner arbeitet oder zumindest eine GUI, die den Status eines Dienstes anzeigen kann. Vielleicht wäre so ein Programm ja auch für Endanwender interessant um auch Fotos gegen unabsichtliche Löschung zu sichern. Es muss ja nicht immer ein Crypto-Trojaner sein
  • UNDO-Option
    Wenn ein Anwender doch einmal eine ältere Datei verändern möchte, dann könnte man sich eine "Freischaltung" auch ohne Admin vorstellen. z.B. könnte der Anwender irgendwie einen Trigger lostreten (z.B. eine Mail an eine Adresse mit dem Pfad im Betreff), um das Verzeichnis wieder zu entsperren. Oder das Skript hinterlässt eine "Hyperlink-Datei" zum Anklicken, um über einen IIS auf dem Server das Entsperren für eine Zeit zu erlauben.

Es gibt also viele Optionen, hier noch Verbesserungen zu erreichen.

USN Journal

Je größer die Dateisysteme und je komplexer die Berechtigungen werden, desto länger wird es dauern, bis das Skript durchgelaufen ist. Natürlich kann das Skript problemlos in der Nacht den ganzen Server ablaufen aber ich habe mir schon überlegt, wie es einfacher geht. So könnte das Skript zuerst einmal nur die Dateien bearbeiten, die sich in dem relevanten Zeitraum geändert haben. Es kann weiterhin rekursiv durchlaufen aber könnte sich auf Dateien beschränken, deren "LastWriteDate" in zwischen dem aktuellen Limit und dem Limit beim vorherigen Lauf bewegt. Allerdings ist das nicht fehlerfrei, da ja ein Admin eine Datei wieder zurücksetzen kann und das Skript diese dann nicht mehr schützen würde. Der Ansatz allein über das LastWriteTime funktioniert also nur mit Verzögerungen. Allerdings führt z.B. Windows ein USN-Journal auf dem Dateisystem mit.

Darüber wäre es möglich, sehr schnell alle geänderten Dateien zu ermitteln. So könnte eine Liste von "zur Sperre ausstehenden Dateien" angelegt und gepflegt werden, die dann später geschützt werden müssen.

To obtain a handle to a volume für use with Update sequence number (USN) change journal operations, call the CreateFile function with thelpFileName parameter set to a string of the following form: \\.\X: Note that X is the letter that identifies the drive on which the NTFS volume appears. Quelle: https://msdn.microsoft.com/de-de/library/windows/desktop/aa365259(v=vs.85).aspx

Generelle Fragen zu anderen Datenspeichern

Die Lösung bezieht sich nur auf die Dateien in einem Dateisystem mit NTFS-Rechten. Solange Verschlüsselungstrojaner sich auf diese einfachen und dennoch lohnenswerten Ziele beschränken, ist das schon ein wichtiger Schritt. Das Tool schützt aber nicht gegen Veränderungen von z.B. Terminen und Kontakten in Outlook. Und vielleicht gibt es bald auch mal einen Trojaner, der SQL-Tabellen verändert, wenn der aufrufende Benutzer die Berechtigungen dazu hat und der Trojaner aus der Konfiguration einer Software den Zugang ermitteln kann.

Aus meiner Sicht ist es nur eine Frage der Zeit bis der erste Trojaner sich per MAPI und Outlook auf die Termine, Kontakte und natürlich Mails stürzt, um dort die Inhalte und Anlagen zu verändern. Ein Exchange Administrator wird dies daran erkennen, dass die Transaktionsprotokolle vermutlich schnell wachsen und die Server viel Client-Traffic haben.

Wohl dem, der hier mit einem Journal arbeitet, um zumindest die Mails wieder zu erhalten oder mit In-Situ-Archiv.

Seit die Trojaner sogar Webseiten verschlüsseln, bin ich über mein besonderes CMS namens Sharepoint Designer froh. Ich bearbeite lokal und auf der Webseite liegen statische HTML-Seiten.

Allerdings werden die wenigsten Administratoren diese Einstellung auf allen Postfächern permanent aktiv machen.

Weitere Links