Protecting IBM i against ransomware (it’s easier than you think)
We get asked this question all the time: “how can I protect IBM i against ransomware?”
Ransomware is a hot button topic. It should be. The average ransom that companies paid in Q1 2019 rose to $12,762 from $6,733 the previous quarter. In some instances, ransoms are in the six-figure range or higher for large organizations with a low tolerance for downtime.
So, how do you protect the data on your IBM i partitions from being held hostage?
The first step is to acknowledge that your IBM i may be vulnerable
For many years our community has touted the security features of IBM i. None of that changes, of course. It’s highly securable. The problem is most people think it comes secured by default. It does not.
A great example is the system value QCRTAUT. It’s shipped at a value of *CHANGE. This means the default public authority for any newly created object is wide open (i.e., *CHANGE) for any user (i.e., *PUBLIC) on the system. We do a lot of security assessments. QCRTAUT has been set to *EXCLUDE on only four partitions that I’ve seen.
Another example is the root directory of the Integrated File System (IFS). It ships with *RWX authority for *PUBLIC. Ideally, that root directory authority should be scaled back to *RX for *PUBLIC. Scaling that back isn’t likely a huge problem, however, you must realize that every directory you’ve ever created off the IFS root has inherited the permissions of the root directory until you’ve manually changed them. It’s quite possible that many of your custom directories are wide open from a permissions standpoint. Now those directories and file systems aren’t a major problem for ransomware…unless of course, you’ve shared them.
File shares. File Shares. File Shares.
Weak security and read/write file shares can be a dangerous combination. Think about it. If you’ve created a file share over a directory that has write authority for *public (remember that’s the default shipped value for QSYS and the IFS), then any authenticated user has the ability to alter files in that share that have inherited those same rights. This works the same way if you’ve shared something in QSYS or the IFS.
Some systems even provide a Guest profile in NetServer. What’s that? Well if you have a Guest profile in your NetServer configuration it means that if you don’t have credentials to log onto an IBM i file share then NetServer will provide you one. And that profile has whatever rights *public does as well. Personally, I see that on maybe 30% of all NetServer setups.
The further to the root you share equals more damage that can be done. In some instances, we find the root directory is shared. In others, both a root share exists alongside a NetServer Guest profile with default authorities set at the IFS level. A true recipe for disaster. Imagine if you will, if you shared the root directory, did not have a decent object authority strategy (or had users with excess special authorities) and you had a piece of malicious code on the network looking to encrypt or delete the contents of your file shares. If this malicious code happened upon your system’s root share, it’s highly possible the bulk of your system is done like dinner.
If you want to protect against ransomware then you need to harden your file shares. Limit the shares you have. Only share what you need. Of the shares that are valid, employ various tactics to prevent them. If they don’t need to be read/write shares, present them to users as read-only shares. Ensure the directories being shared are protected by *public *exclude authority and only allow access to those who must access them. Reduce your users with *ALLOBJ special authority. Ensure you don’t have a NetServer Guest profile. The goal is to reduce as much risk as you can by taking a multi-prong approach to security.
Backup and Recovery
If you’ve taken steps to harden your defenses and reduce your risk, you’ve made it harder for malicious code to affect your system. Of course, nothing is ever 100% effective. At the end of the day having a comprehensive, reliable and tested backup will be the difference between recovering your system to a pre-attack state or dealing with irreparable damage to your business. The ransomware victims you see in the news media are usually the latter. They had no other recourse but to pay a ransom and hope for the best. When’s the last time you’ve tested a Save 21 tape to see if it works? How often do you do a Save 21? Or 22? Or 23? Are you relying on the backup program someone wrote in 1994 and haven’t reviewed the source code since? In my humble opinion, any backup media is suspect until you’ve successfully recovered from it. We had an incident last year with a customer who declared a disaster with no maintenance and a destroyed system. Two tapes were shipped to our data center. One was labeled “Full System Save – 2012” and the other was a nightly tape. The full system save tape had exactly three libraries on it. Sometime in the previous six years it had been cleared and overwritten. Maybe it’s the luck of the Irish with me, but we managed to get all user profiles, user libraries and DLOs off the tape and we were able to rebuild the 5.4 system on a 7.3 OS. They were lucky the 2nd tape worked. They were lucky the nightly tape had almost everything they needed. They were super lucky all the 5.4 objects passed observability to get to 7.3.
Don’t be lucky. Be sure. Your backup and recovery due diligence could mean your job.