NetApp ONTAP Dateiserver schützen und gegen Ransomware abschotten

Von
Tobias Steinicke
-
NetApp

Sicherlich habt ihr auch die Schlagzeilen über die jüngste Ransomware Locky gelesen. Cryptolocker und Teslacrypt, die Pest. Locky anscheinend noch schlimmer. Wie viele andere nistet sich Locky auf dem Client ein, schaut aber auch noch links und rechts, was es so auf Dateiservern im Firmennetzwerk verschlüsseln kann. Nahezu jeder Anwender dürfte Zugriff auf entsprechende Projekt- oder Abteilungslaufwerke haben und schon nimmt das Unheil seinen Lauf. Auch wenn sich hoffentlich relativ zügig Backups einspielen lassen und der oder die verseuchten Clients aus dem Netzwerk entfernen lassen, heißt es erstmal wieder extra Stunden investieren.

Workaround für Windows Dateiserver

Franky wies auf einen Workaround hin, um die firmeninternen Windows Fileserver zumindest ansatzweise gegen diese Mistviecher abzuschotten. Sein Ansatz ist dabei, den Ressourcen-Manager für Dateiserver zu verwenden, der sich z.B. auch zum Implementieren von Quotas oder dem Sperren von Musik- und Videodateien eignet. Genau auf diese Funktionalität greift Franky zurück und legt eine entsprechende Dateigruppe an, die per se gefiltert und nicht erlaubt wird. Dazu gehören Dateiendenungen wie *.locky, *.zzz, *.xxx und viele mehr. Versucht nun ein Anwender (oder die Ransomware) eine solche Datei zu erzeugen oder zu ändern, schlägt der Ressourcen-Manager an und unterbindet das Erstellen.

Ansatz für NetApp OnTap mittels fpolicy

Ich habe das Ganze für diejenigen unter Euch angepasst, die als Dateiserver NetApp ONTAP (CIFS) im Einsatz haben. Auch auf ONTAP lässt sich eine entsprechende Filter implementieren. Dazu geht ihr wie folgt vor

  1. Verbindet Euch per SSH auf Euren NetApp Dateiserver (z. B. via PuTTY)
  2. Erzeugt mittels dem Befehl fpolicy create f_Ransomware screen eine Filterpolicy mit dem Namen f_Ransomware
  3. Mit dem Befehl fpolicy ext inc set f_Ransomware locky,xxx,zzz fügt ihr die Policy die Dateiendungen *.locky, *.xxx und *.zzz zum Filtern hinzu. Diese Dateiendungsliste könnt ihr kommagetrennt erweitern
  4. Anschließend muss die Filterpolicy noch zugeordnet werden. Führt dazu den Befehl fpolicy monitor set f_Ransomware -p cifs,nfs create,rename aus.
  5. Danach führt ihr die Befehl fpolicy options f_Ransomware required on aus.
  6. Abschließend erfolgt die Aktivierung mit dem Befehl fpolicy enable f_Ransomware
  7. Sobald ihr ENTER drückt erscheint die Meldung „Warning: User requests may be denied because there are no file screening servers registered with the filer. Are you sure?“ Bestätigt diese Meldung mittels y und drückt erneut Enter
  8. Die Filterpolicy ist nun aktiv.

Eine Möglichkeit zur E-Mail Benachrichtigung habe ich allerdings nicht gefunden. Hilfreiche Hinweise sind in den Kommentaren willkommen  🙂

Update:

Vielen Dank an Ronny für die Variante für cDOT Version 8.3.1

fpolicy policy event create -vserver -event-name e_ransomware -protocol cifs -file-operations create rename
fpolicy policy create -vserver -policy-name p_ransomware -events e_ransomware
fpolicy policy scope create -vserver -policy-name p_ransomware -shares-to-include * -file-extensions-to-include locky,locked,k,encoderpass,ecc,ezz,exx,zzz,xyz
vserver fpolicy enable -vserver -policy-name p_ransomware -sequence-number 2

Anmerkung: Den Teil der file-extensions-to-include habe ich eingekürzt, da dies hier ansonsten nicht auf die Webseite passt. Bitte ergänzt entsprechend die restlichen Dateitypen, wie unten gelistet.

Weitere Dateiendungen zur Filterpolicy hinzufügen

Weitere Dateiendungen können später mit dem Befehl fpolicy ext inc add f_Ransomware DATEIENDUNG hinzugefügt werden.
Eine Auswahl der gängigen Dateitypen habe ich von Franky übernommen. Bedenkt, unter ONTAP ohne *. eingeben

Filterpolicy anzeigen lassen

Der Befehl fpolicy show f_Ransomware zeigt Euch die gesetzten Parameter an:

File policy f_Ransomware (file screening) is enabled.

No file policy servers are registered with the filer.

Operations monitored:
File create,File rename
Above operations are monitored for NFS and CIFS

List of extensions to screen:
0X0,AAA,ABC,BLEEP,CCC,CRINF,CRJOKER,CRYPT,CRYPTO,CTB2,CTBL,ECC

List of extensions not to screen:
Extensions-not-to-screen list is empty.

Number of requests screened : 0
Number of screen failures : 0
Number of requests blocked locally : 7

Gängige Dateitypen und Dateien von Locky, CryptoLocker & Co.

Dateitypen

  • *.k
  • *.encoderpass
  • *.locky
  • *.key
  • *.ecc
  • *.ezz
  • *.exx
  • *.zzz
  • *.xyz
  • *.aaa
  • *.abc
  • *.ccc
  • *.vvv
  • *.xxx
  • *.ttt
  • *.micro
  • *.encrypted
  • *.locked
  • *.crypto
  • _crypt
  • *.crinf
  • *.r5a
  • *.xrtn
  • *.XTBL
  • *.crypt
  • *.R16M01D05
  • *.pzdc
  • *.good
  • *.LOL!
  • *.OMG!
  • *.RDM
  • *.RRK
  • *.encryptedRSA
  • *.crjoker
  • *.EnCiPhErEd
  • *.LeChiffre
  • *.keybtc@inbox_com
  • *.0x0
  • *.bleep
  • *.1999
  • *.vault
  • *.HA3
  • *.toxcrypt
  • *.magic
  • *.SUPERCRYPT
  • *.CTBL
  • *.CTB2
  • *.porno

Auffällige Dateien

  • HELPDECRYPT.TXT
  • HELP_YOUR_FILES.TXT
  • HELP_TO_DECRYPT_YOUR_FILES.txt
  • RECOVERY_KEY.txt
  • HELP_RESTORE_FILES.txt
  • HELP_RECOVER_FILES.txt
  • HELP_TO_SAVE_FILES.txt
  • DecryptAllFiles.txt
  • DECRYPT_INSTRUCTIONS.TXT
  • INSTRUCCIONES_DESCIFRADO.TXT
  • How_To_Recover_Files.txt
  • YOUR_FILES.HTML
  • YOUR_FILES.url
  • encryptor_raas_readme_liesmich.txt
  • Help_Decrypt.txt
  • DECRYPT_INSTRUCTION.TXT
  • HOW_TO_DECRYPT_FILES.TXT
  • ReadDecryptFilesHere.txt
  • Coin.Locker.txt
  • _secret_code.txt
  • About_Files.txt
  • DECRYPT_ReadMe.TXT
  • DecryptAllFiles.txt
  • FILESAREGONE.TXT
  • IAMREADYTOPAY.TXT
  • HELLOTHERE.TXT
  • READTHISNOW!!!.TXT
  • SECRETIDHERE.KEY
  • IHAVEYOURSECRET.KEY
  • SECRET.KEY
  • HELPDECYPRT_YOUR_FILES.HTML
  • help_decrypt_your_files.html
  • HELP_TO_SAVE_FILES.txt
  • RECOVERY_FILES.txt
  • RECOVERY_FILE.TXT
  • RECOVERY_FILE*.txt
  • HowtoRESTORE_FILES.txt
  • HowtoRestore_FILES.txt
  • howto_recover_file.txt
  • restorefiles.txt
  • howrecover+*.txt
  • _how_recover.txt
  • recoveryfile*.txt
  • recoverfile*.txt
  • recoveryfile*.txt
  • Howto_Restore_FILES.TXT
  • help_recover_instructions+*.txt
  • _Locky_recover_instructions.txt

Weitere Informationen

Kommentar

Mit dieser Möglichkeit schafft man zumindest eine gewisse Gegenwehr gegen die Ransomware, wenn auch keine beständige oder ausreichende. Da sich die Dateitypen laufend ändern, die Ransomware ständig neu „zusammengeklickt“ wird, wird das Filtern zur Sisyphus-Arbeit. Es ist aus meiner Sicht mit am Wichtigsten die Anwender eindringlich zum Impfen: „Öffnet keine suspekten oder unbekannten Anhänge. Bekommst Du sonst Rechnungen? Nein – warum dann jetzt aufeinmal… Also lass die Finger von dem Anhang…“  🙄

Verwandte ArtikelMehr vom Autor

36 Kommentare

  1. Hallo Tobias,
    vielen Dank für diesen Eintrag. Ich bin gerade dabei unsere beiden Netapps abzuschotten. Auf unserem Testsystem hat es schon mal super funktioniert. Vielen Dank.

  2. Hallo Tobias,

    gute Idee, die File-Extensions zu blocken.

    Habt ihr das auch mal im Real-Einsatz getestet? Es wäre interessant, wie die Crypter arbeiten.

    Was ist, wenn der Crypter erst die Datei verschlüsselt und dann das Original löscht.
    Das Verschlüsseln ist ja wegen der neuen Dateiendung nicht möglich, das löschen der alten Datei aber schon.
    Habe ich bei dieser Lösung dann einen leeren Share, statt einem Share voll mit verschlüsselten Dateien?

    PS:
    Für Nutzer von Synology-NAS Systemen funktioniert das übrigens auch:

    Unter „Control Panel -> File Services -> Win/Mac/NFS -> Advanced Settings -> Veto files“ kann man die Dateiendungen ebenfalls eintragen.

    Da das eine Samba-Funktion ist, geht das generell bei alles Samba-Servern.

    Viele Grüße
    Martin

    • Hallo Martin,

      so gesehen nicht im Real-Einsatz getestet. Toi, toi, toi wenn die Plage nicht bei uns auf den Systemen landet.
      Das von dir angemerkte Problem ist mir auch schon durch den Kopf gegangen, sprich Verschlüsseln, Original löschen – d. h. potentiell wird das Original trotzdem gelöscht, ja könnte sein :-/
      Evtl. fällt die Malware aber auch auf die Bretter und „springt“ erstmal weiter. Wie gesagt, konnte so nicht im Real-Einsatz getestet werden. Da ist es auch schade, dass NetApp im Gegensatz zum Windows Filer keine Möglichkeit bietet, eine E-Mail zu senden, wenn eine verdächtige Datei entdeckt wird und von wem diese erstellt wurde.

  3. Vielen Dank für die Anleitung. Mich würde das ganze für cDOT (also ab Version 8.3) interessieren. Hier sind die Befehle doch ganz anders…

    • Hier mal unsere aktuelle Policy . CDOT 8.3.1

      fpolicy policy event create -vserver -event-name e_ransomware -protocol cifs -file-operations create rename
      fpolicy policy create -vserver -policy-name p_ransomware -events e_ransomware
      fpolicy policy scope create -vserver -policy-name p_ransomware -shares-to-include * -file-extensions-to-include locky,locked,k,encoderpass,ecc,ezz,exx,zzz,xyz,aaa,abc,ccc
      vserver fpolicy enable -vserver -policy-name p_ransomware -sequence-number 2

      Wenn jemand noch eine andere hat, darf die gern geshared werden.

      • Super, Dir vielen Dank Ronny!

        Zur Info für alle:
        Habe die File-Extensions in Ronnys Kommentar abgekürzt, dass die Zeile sonst hier die Webseiten-Breite sprengt 🙂
        Bitte also oben in der Liste analog zu den anderen Dateitypen bedienen.

  4. Hi,

    Erstmal danke für diese Idee.
    Aber was genau macht die fpolicy?
    Soweit ich das herausgelesen habe unterbindet diese die Erstellung von Dateien mit den genannten Extensions. Ist das richtig?

    Im Falle von Locky wird also erst die Datei verschlüsselt und dann das original gelöscht. Wenn ich also jetzt die Erzeugung der .locky Files blockiere (falls das damit gemeint war), wird dann die Löschung des Originals auch mit unterbunden?

    Grüße,
    Toni

    • Hallo Toni,

      ja, so der Ansatz. Die fpolicy verhindert das Erstellen bzw. umbenennen bestehender Dateien mit diesen Extensions. Da ich aber die Routinen von Locky nicht im Detail kenne, kann ich dir nicht sagen, ob die Dateien evtl. dennoch gelöscht werden (hängt vlt. auch von der Version von Locky ab und wie die Routinen implementiert sind). Die Idee ist hier aber, dass Locky einfach auf die Nase fällt….

      Diese Methode bietet auch keinen definitiven Schutz, zumal sich die Dateiendungen sicherlich schon bald wieder ändern.
      Nachteilig bei ONTAP ist, dass nicht automatisch eine Mail abgesetzt werden kann, wie es bei Windows FS der Fall ist.

  5. Hallo,
    wirklich eine gute Idee mit der fpolicy. Leider kann ich es auch nicht einsetzen da nicht gesagt werden kann, wie der Virus arbeitet. Wenn er dann alle Daten verschlüsselt und die Datei nur nicht umbenennt, ist das Ergebnis verheerender als vorher. Durch die Änderung des Dateinamen hat man wenigstens die Möglichkeit relativ problemlos betroffen Dateien zu erkennen.

    Und bis man raus hat, wie der Virus arbeitet, sind dann hoffentlich auch die Virenpattern aktualisiert.

    Trotzdem finde ich den Lösungsansatz interessant. Wer weis wofür ich das noch mal nutzen kann 🙂

  6. Wir haben die fpolicy-Funktion auch seit kurzem eingeschaltet. Wie sieht es aus mit Performance-Einbußen auf den NetApp-Systemen in Zusammenhang mit fpolixy ? Hat jemand damit schon Erfahrungen gemacht ? Alternativ wäre der Einsatz von speziellen fpolicy-Servern möglich, wie wir gelesen haben.

  7. Hi,
    I like your post very much and have implemented it on FAS. Question, are we sure that the file is not encrypted before the renaming? If not we have actually caused a bigger problem. If file is pulled to memory, original is then deleted and they go to write one back with a blocked extension this process will block that. Perhaps then the folder will have no file in it, neither the original nor the encrypted one. Then there is no way to know what file to restore. Knowing the exact order of things is important. Any idea?
    Thanks!

    • Hi Scott,
      thanks for you comment. Unfortunately it’s not 100% sure how the ransomware would work nor if newer releases might do it like that. The idea behind was also that the ransomware might run into a kind of error without encrypting and without deleting. But it might happen that no encryption is done but the deleting…. I didn’t had a chance to test it in a DMZ with letting Locky running „wild“ 🙁

  8. Hi Again,
    Thanks for the reply. I guess we are all siting ducks with this but you are correct, it may error some functions out and perhaps help a bit. If I do get a direct answer on what this version of Locky does I will reply back. Thanks again!

    Scott

  9. Hello Tobias,
    Thank you for your site. Thanks to you, I arrived to put the policy. I would like to Know if I can find in the logs Netapp, the data following for example @ip, computer_name, date, user_name who „change“ the files on the Netapp to ransomware. Sorry for my bad English. Thank you for your help.

  10. Hallo,

    gibt es seit Februar schon eine aktuellere Liste der Dateiendungen die zu exkludieren sind?
    Oder ist da nichts dazugekommen

  12. Hallo,

    Wir haben auf unseren NetApp CIFS Shares seit einigen Wochen fpolicy aktiviert. Nun hatten wir das Pech und wurden von einem Ransomware Virus heimgesucht. Dabei versuchte der Virus zuerst mit der Endung Crypt zu verschlüsseln (leider haben wir das noch nicht bemerkt). Danach hat der selbe Virus umgestellt und angefangen, Files zu verschlüsseln und mit der Original-Endung wieder zu speichern – fpolicy hat natürlich nichts mehr gebracht – Schei… Zum Glück gibt’s die NetApp Snaphots 🙂

    Meine Frage an dich, Tobias; gibt es eine Möglichkeit den „Number of blocked“ zu Monitoren? zB SNMP Trap oder sogar Mail?
    Danke

    Gruss
    Urs

    • Hallo Urs,
      habe so eine Einstellung leider noch nicht gefunden, Mail gar nicht. SNMP habe ich auch noch nix gefunden.
      Wir „tracken“ das bei uns als Workaround mit einem TreeSize Job, der regelmäßig über die Shares rotiert und die verdächtigen Dateien meldet.
      Bei dir ist es natürlich richtig fies, wenn einfach wieder die Original-Endungen verwendet werden :-/

    • Also es gibt keine Möglichkeit an die Info heran zu kommen welche Datei den Counter von Fpolicy nach oben gesetzt hat ohne fpolicy Server. Dieses Statement hat der NetApp Support (leider) bestätigt.

      Ebenfalls lässt sich leider keine eigene API Anwendung Programmieren weil der Code für FPolicy nicht mehr im allgemeinen SDK von der NetApp enthalten ist (auch leider). Ein altes SDK hat den Code jedoch funktioniert dieser gegen die aktuell Supporteten OnTAP Versionen nicht.

      Lediglich der FPolicy Counter lässt sich mit dem SDK z.B. mit Icinga überwachen. Ein kurzes bsp für den Code (quick & dirty in Perl) dabei muss alles zwischen angepasst werden. Eventuell kann es jemand gebrauchen oder es hilft nicht nur mir. Der User muss folgendes dürfen „Allowed Capabilities: login-http-admin,api-options-get,api-fpolicy-list-info“:

      ##########################
      #!/usr/bin/perl
      require 5.6.1;
      use lib ‚/usr/lib/perl5/5.10.0/NetApp‘; #Bedarf der Anpassung
      use strict;
      use warnings;
      use NaServer;
      use NaElement;

      #Hier wird die netapp uebergeben z.B. na123-rz1
      my $parameter1=$ARGV[0];
      #Hier wird der Wert zu Blockender Dateien gesetzt
      my $parameter2=$ARGV[1];

      my $s = new NaServer($parameter1, 1 , 9);
      $s->set_server_type(‚FILER‘);
      $s->set_transport_type(‚HTTP‘);
      $s->set_port(80);
      $s->set_style(‚LOGIN‘);
      $s->set_admin_user(“, “);

      my $api = new NaElement(‚fpolicy-list-info‘);
      $api->child_add_string(‚policy-name‘,’invoke_elem($api, ‚value‘);
      if ($xo->results_status() eq ‚failed‘) {
      print ‚Error:\n‘;
      print $xo->sprintf();
      exit 1;
      }

      my @test=$xo->sprintf();
      foreach (@test){
      if ($_ =~ /\(\d*)\/ )
      {
      if ( $1 <= $parameter2 )
      {
      print "Nein Counter steht bei: ".$1."\n";
      exit 0;
      }

      else
      {
      print "!!!ACHTUNG COUNTER UEBERSCHRITTEN: ".$1." !!!\n";
      exit 2;
      }
      }
      }
      ##########################

  13. Hallo Tobbi,

    danke für den guten und ausführlichen Artikel zum Thema FPolicy im Zusammenhang mit Ransomware. Mit der Fpolicy kann man wunderbar bestimmte Dateitypen unterbinden, aber gegen die Ransomware ist es nur bedingt brauchbar, denn damit blockt man nur die Schreibvorgänge der verschlüsselten Dateien ab. Was mit den originalen Dateien passiert, also ob die nach dem verschlüsseln gelöscht werden, oder nicht, ist eine gute Frage, so einen Fall müsste man in einer Test-Umgebung nachstellen 🙂

    Der beste Schutz nach wie vor sind Snapshots @ NetApp 🙂

    Grüße,
    Lukas

    • Hi Lukas,

      jepp, gebe ich Dir Recht. Ist leider so. Insgesamt sollte es schon eine mehrschichtige Strategie sind, die teilweise auch mit unseren Anwendern steht und fällt 🙂 Würde man die endlich mal dazubekommen, nicht immer die „Rechnungen“ zu öffnen 😀

  14. Hallo Tobbi,

    du beschreibst (neben den potenziellen Dateitypen) „auffällige Dateien“. Kann ich diese direkt mittels fpolicy – oder anders – unterbinden, oder geht das wirklich nur für File-Extensions? Möchte ja beispielsweise keine *.txt generell exkludieren.

    Danke – liebe Grüße,
    Florian

    • Hallo Florian,
      soweit ich weiß, beherrscht fpolicy nur File Extensions, du kannst also nicht nach boese-datei.txt filtern.

      Vielleicht ist für Dich aber auch die Lösung mit TreeSize Pro ein Workaround? Das Tool gibt es für schmales Geld und kann z. B. Berichte per Mail erzeugen, wenn entsprechende Dateien gefunden wurden.

      Dies habe ich umgesetzt, da NetApp meines Wissen ja leider auch keine SMTP Mails bei geblockten FileExts findet.

  15. Hello Tobias and Ronny also

    Thank you so much for this post, I spent an hour reading several of NetApp’s KB articles and you have given me everything I need in 1 blog post and 1 response.

    Thank you 😀

    Hazel

  16. Have you ever seen an occasion where any of the file extensions listed are used for legitimate files? So, if you block some of these file types, could it interfere with users being able to work?

Kommentieren Sie den Artikel

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein