Discover how to use our ONTAP native (free) tool to detect ransomware and prevent it from happening again.

With the average ransomware payment per incident continuing to rise, organizations can expect the financial impact of ransomware attacks to keep increasing in the coming years. SafetyDetectives is a group of security experts who focus on testing antivirus programs, password managers, and other cybersecurity software. They predict that by the end of 2021, the financial strain from ransomware will be as much as $20 billion per year.

 

Statistics like that are why many organizations are focusing on quick recovery from ransomware. But what if you could detect when a ransomware event has begun and then prevent it from spreading in the first place? WithNetApp® ONTAP®data management software, you have the capability to detect and to prevent the spread of ransomware built in at no additional cost!

 

This blog post is the third in a six-part series that discusses how you can detect and prevent ransomware by using native NetApp® ONTAP® features, recover quickly from an attack, and avoid paying the ransom. It’s best to read them in chronological order:

  • The first entry covered the objectives of cybercriminals and the largest portion of the cost of a ransomware attack, which is not the ransom.
  • The second entry is focused on ONTAP native tools that you can use for early detection of a ransomware outbreak.
  • The third entry took a deep dive into NetApp FPolicy® native mode, which helps prevent most older types of ransomware that are still prevalent today.
  • The fourth entry focused on how to prevent the most modern variants of ransomware, including “zero-day” exploits, by using FPolicy external mode.
  • The fifth entry highlighted the three key steps to successfully recover from a ransomware attack.
  • The sixth entry focused on ONTAP Snapshot technology and how it provides very rapid restores (terabytes in seconds, not hours), protects your backups from ransomware encryption, and prevents deletion of valuable backup data.

What Is FPolicy, NetApp’s Zero Trust Engine?

NetApp FPolicy (an evolution of the name File Policy) is a file-access notification framework that you use to monitor and to manage file access over the NFS or SMB/CIFS protocol. It has been part of ONTAP for over a decade, and it is incredibly useful in helping you detect ransomware. This Zero Trust engine is valuable because you get extra security measures beyond permissions in access control lists (ACLs).

 

The concept behind Zero Trust is to never trust and to always verify. You can learn more about it in another recent NetApp blog post. The key point, though, is that just because a user (or administrator) has permission to access a file or folder, they shouldn’t necessarily be able to change whatever content they want to in that location.

 

FPolicy was initially intended to help you block unwanted files from being stored on your enterprise-grade storage appliance. (For example, many users stored .mp3 files on their home folders before music streaming services like Spotify became popular, allowing users to stream music from their personal devices.) However, FPolicy also gives you a way to block known ransomware file extensions, too. The user still has full access permissions to their home folder, but FPolicy doesn’t allow them to store whatever files your administrator marks as blocked, whether it’s .mp3 files or known ransomware file extensions.

FPolicy Modes

FPolicy has two modes of operation: native and external. Native mode provides both blacklisting and whitelisting of file extensions. As I mentioned earlier, you get native FPolicy with ONTAP at no additional charge. It’s built in, and you don’t need an extra license to enable it. External mode has the same capabilities as native mode, but it also integrates with an FPolicy server that runs externally to the ONTAP system as well as a security information and event management (SIEM) system. So, you get extra capabilities to detect more advanced ransomware. Here is an example of the external mode configuration:

Detect ransomware with our SIEM system.

 

One of the key differentiators with external mode is that you can use UBA capabilities. These capabilities are important because they can stop even zero-day ransomware attacks. I will get into more details about external mode in the next blog post, but for now, let’s focus specifically on the native mode capabilities of whitelisting and blacklisting.

FPolicy Whitelisting

If you know exactly what type of files will reside on the NFS exports or SMB/CIFS shares, then it is advantageous to set up whitelisting. For example, if the only document type that you need to store on a particular share is .pdf files, then you should allow only the .pdf extension and block all others. Ransomware that encrypts files and modifies the extensions is then rendered useless.

 

It’s fairly straightforward to enable this type of FPolicy configuration. Here is an example of the steps to create a whitelist from the CLI:

 

  1. Create a new FPolicy event and specify the storage virtual machine (SVM) that it will run against, the file protocol (NFS or SMB/CIFS), and the types of file operations that it applies to.

Cluster1::> vserver fpolicy policy event create -vserver svm1 -event-name whitelist1 -protocol cifs -file-operations create,open,write,rename 

 

  1. Create a new policy and direct it to use the event that you created in step 1. Also specify which FPolicy engine (native or external) to use.

Cluster1::> vserver fpolicy policy create -vserver svm1 -policy-name whitelist_policy -events whitelist1 -engine native 

 

  1. Assign the file scope. Specify in ONTAP which file extensions to ignore (the extensions that you are whitelisting, in this case, .pdf files) and which file extension the policy applies to (always “*” for whitelisting). Also specify which file shares or exports to include in the policy. The following case specifies a share because the policy applies to the SMB/CIFS protocol.

Cluster1::> vserver fpolicy policy scope create -vserver svm1 -policy-name whitelist_policy  -file-extensions-to-exclude pdf -file-extensions-to-include * shares-to-include public

 

  1. Enable the policy and place the appropriate priority if you’re configuring multiple policies.

Cluster1::> vserver fpolicy enable -vserver svm1 -policy-name whitelist_policy -sequence-number 1

 

  1. Verify the configuration by using the vserver fpolicy policy scope

Cluster1::> vserver fpolicy policy scope show -vserver svm1 -instance

 

Vserver: svm1

Policy: whitelist_policy

Shares to Include: public

Shares to Exclude: –

Volumes to Include: –

Volumes to Exclude: –

Export Policies to Include: –

Export Policies to Exclude: –

File Extensions to Include: *

File Extensions to Exclude: pdf

Is File Extension Check on Directories Enabled: true

Is Monitoring of Objects with No Extension Enabled: false

 

In the preceding configuration, only .pdf files are now allowed, preventing the contents of the share from being encrypted by ransomware that uses file extensions. But what if you are unsure about which file types need to be stored on the share or export? You can still prevent many kinds of ransomware by using the blacklisting capability in native mode.

FPolicy Blacklisting

Blacklisting is exactly what you would expect it to be. Files with a certain type of extension are not permitted to be saved on the storage system and shares. It comes in handy when you know a very specific type of ransomware that you’re trying to block that uses file extensions after completing the encryption process. The WannaCry virus (.wncry) comes to mind as a popular extension to blacklist. If an outbreak has already started in your environment, blacklisting can be a quick way to stop the bleeding.

 

The following example shows how to create a blacklist from the CLI. The steps are very similar to creating a whitelist policy:

  1. Create a new FPolicy event and specify the SVM that it will run against, the file protocol (NFS or SMB/CIFS), and the types of file operations that it applies to.

Cluster1::> vserver fpolicy policy event create -vserver svm1 -event-name blacklist1 -protocol cifs -file-operations create,open,write,rename 

 

  1. Create a new policy and direct it to use the event that you created in step 1. Also specify which FPolicy engine (native or external) to use.

Cluster1::> vserver fpolicy policy create -vserver svm1 -policy-name blacklist_policy -events blacklist1 -engine native 

 

  1. Assign the file scope. Specify in ONTAP which file extensions to block (the WannaCry virus and the extension .wncry, in this case). Also specify the policy that it applies to and which file shares or exports to include in the policy. The following case specifies a share because the policy applies to the SMB/CIFS protocol.

Cluster1::> vserver fpolicy policy scope create -vserver svm1 -policy-name blacklist_ -file-extensions-to-include WNCRY shares-to-include public

 

  1. Enable the policy and place the appropriate priority if you’re configuring multiple policies.

Cluster1::> vserver fpolicy enable -vserver svm1 -policy-name blacklist_policy -sequence-number 1

 

  1. Verify the configuration by using the vserver fpolicy policy scope

Cluster1::> vserver fpolicy policy scope show -vserver svm1 -instance

 

Vserver: svm1

Policy: blacklist_policy

Shares to Include: public

Shares to Exclude: –

Volumes to Include: –

Volumes to Exclude: –

Export Policies to Include: –

Export Policies to Exclude: –

File Extensions to Include: WNCRY

File Extensions to Exclude: –

Is File Extension Check on Directories Enabled: true

Is Monitoring of Objects with No Extension Enabled: false

I Use FPolicy in Native Mode, So Why Do I Need to Use External Mode?

Both blacklisting and whitelisting can be quite valuable in preventing ransomware from encrypting your files. Because they’re built into ONTAP, they’re inexpensive approaches to prevent ransomware. However, both operate on the principle of applying events to file extensions. More modern versions of ransomware simply open files and encrypt the contents without changing the file extension. So, even when you use native mode whitelisting and blacklisting, you could still potentially be hit by ransomware.

 

That vulnerability is why the next blog post in this series will focus on the external FPolicy mode. When you combine it with an external FPolicy server, you can prevent ransomware attacks that don’t use extensions. Plus, you can use UBA capabilities to stop those pesky zero-day ransomware attacks.

 

If you want to get a jump start or learn more about the NetApp solution to ransomware, check out our technical report TR-4572: The NetApp Solution for Ransomware.

Matt Trudewind

Now on his 2nd tour at NetApp across 8 years, Matt is a Senior Technical Marketing Engineer with a primary focus on ransomware prevention and recovery as well as portfolio Security. This includes but is not limited to Data Governance, Data Privacy Frameworks, Security Tools, and Security Best Practices. Prior to this role he was a Staff Engineer focused on ONTAP product Supportability specifically in the areas of networking and SMB/CIFS. In between NetApp stints Matt worked with a NetApp partner (Eze Castle Integration) for 7 years as pre sales/post sales storage architect focusing on early 7-mode to cDOT migration. He has also focused on Microsoft Windows Active Directory, Exchange, SQL and VMware during his 21 years of IT experience with 15 of those years coming in the storage industry. Prior to NetApp and ECI, he also worked a contract at Microsoft as a Technical Support Engineer.

Add comment