As of the time of writing this document (original November 2020, updated June 2021), there are no known ransomware malware programs or viruses that run directly on the IBM i. However, the IBM i can be affected by an infected PC on the network. These PCs are most often infected by opening an infected email attachment, web browser injection, visiting a link to a site that distributes the malware program masquerading as a patch, update, or viewer, by the user being socially engineered by the attacker, or a combination of these.
The IBM i can be a file server to PCs holding any sort of binary data. This means that the IBM i could be a holder of an infected file, but the file will not run directly on or infect the IBM i. There are many ways a file could end upon the system in the first place, such as FTP, SCP, or removable media, not just from a network share. Those infected files could then be shared to a PC via those same methods or more widely if the system is also a web server. The bulk of this article will focus on the risks that come from the IBM i serving as file server, the largest attack surface for this type of malware.
There can be many purposes for these malware programs. First and most obvious, and its namesake, is to lock up systems and hold access to them until a ransom or fee is paid, usually in bitcoin due to its anonymous nature. This lock up is done by encrypting critical data, operating system files, and if possible, backups. The theory is that once the ransom is paid, a decryption program and key will be provided. Almost all IT security groups, including the FBI, recommend NOT paying the ransom. In the US, it may even be considered a crime to pay the ransom depending on the location of the attackers. Once a company is known to pay ransom, they will become a larger target to other groups. Only once the lure of money is gone, will ransomware go away.
Even if these systems can be restored from unaffected or segmented backups, there is a second and growing concern. Before encrypting systems, more strains of ransomware now will look around the network first. As part of their reconnaissance to get a better foothold and pivot to higher value computers or domain controllers, they will look for high value data or personally identifiable information (PII). Once found, it will be exfiltrated from the network to the attackers. Now, if the ransom is not paid, not only is the company on their own to recover their systems, but the attackers also threaten to publicly release the stolen information.
Keep in mind this information is about ransomware in general. Specifics on IBM i will follow. One resource for more information is the National Institute of Standards and Technology (NIST) Cybersecurity Special Publication (SP) 1800-26, Detecting and Responding to Ransomware and Other Destructive Events. And of course, from IBM’s own X-Force team The definitive guide to ransomware: Readiness, response, and remediation.
Protecting the IBM i
There are many steps a company can take to reduce the exposure of the IBM i to an attack like this. These mitigations focus on reducing the exposure of the IBM i file system to the network over NetServer, our version of SMB. First, make sure that guest access is disabled. Guest support is enabled by defining an existing user profile on the system that all unauthenticated users will be mapped to. Those network guest users will get the mapped user profile’s level of permissions. While our recommendation is to disable guest access, if it must be used, make sure the guest account as no special authorities and the lowest level of rights possible. Ideally, this would be read only to prevent any changes. To disable guest access, remove the user profile from the configuration so that it is blank. This will prevent just anyone on the network from accessing the IBM i and requires users to have an IBM i user profile and account.
Next, remove any shares that are no longer needed. Administrators can view the active number of sessions per share via IBM Navigator for i (File Systems > File Shares). This is just a snapshot in time; it is not a log nor cumulative. Each share can also be set to be read only. For example, if there is a directory that is an archive of PDF invoices generated by the system, they may only need to be viewed for reference from a PC. There is no need to expose this share as writeable to the network. While this type of change will prevent the files from becoming encrypted, it will not prevent them from being copied and sent to the attacker. This also does not override OS security (which will be discussed later) – the user would still need write and/or read authority to the objects from the OS level. As always, this should be properly set to avoid exposure even directly on the IBM i. This NetServer setting is in addition and provides further restrictions above and beyond the OS layer, mainly prevented writing from the network if it were otherwise allowed on the system.
In furtherance of reducing exposure, make sure that the mount points for the IFS are as far down the directory path as possible, limiting the number of files accessible. If only a certain sub-folder of an application needs to be accessible from the network, do not share the entire application folder. Share just the sub-folder containing the needed data. This may require creating a larger number of smaller shares under a particular folder. However, it will reduce the total files exposed and increase security. And this should go without saying, but to be explicit, NEVER SHARE THE IFS ROOT (/).
Remember that QSYS.LIB, the library or traditional portion of the IBM i file system, can also be shared, and thereby exposed, to network attacks. The system provides the QPWFSERVER authorization list which can be used to restrict which users are allowed to access QSYS.LIB from NetServer. Just like the read only attribute, this setting is in addition to the OS level security. A user would still need at least read authority to the libraries to access them over the network.
While the preceding talks to NetServer, there is a second way to share files from the IBM i across your network – NFS or Network File System. With NFS, rather than creating file shares, you create NFS exports. These exports publish directories and files which can then be mounted by an NFS client, such as Linux or Windows. When these exports are created, the authorized users for each export is defined. The major concern is that the user creating the NFS export can define anonymous access to the files, requiring no user authentication to access those objects. Worse, the default when an export is defined is that anonymous access is created unless overridden to be disabled. Like NetServer guest access, anonymous NFS access maps unauthenticated NFS users to a single, real IBM i profile. The default is QNFSANON. Make sure that the profile that these anonymous users map to has no special authority and as few permissions as possible, ideally read only. To disable anonymous access, define the NFS exports with ANON=-1 or select None in IBM Navigator for i.
As with NetServer, many of the same recommendations also apply to NFS exports. First, make sure the exports are not defined to allow anonymous, unauthenticated access. Next, if logical for business need, make the exports read only to prevent encryption from a ransomware attack from an NFS client. The root file system (/) and QSYS.LIB are both exportable via NFS. There is no authorization list like with NetServer to help prevent this. Finally, make sure the NFS exports are as far down the file path as possible to expose the least amount of data and files. Administrators can use IBM Navigator for i (Network > Servers > TCP/IP Servers > NFS > Exports) to look for these NFS exports and their settings.
Further Steps
Everything covered so far is in addition to the protection the IBM i operating system already provides. However, many clients have less than ideal object level authorities and permissions defined. While all objects are important, the key items are libraries and folders as they act as a gateway to the objects and files inside them. Best practices include removing *PUBLIC, individual, and group read and write permissions to objects. Access should be granted by using adopted authority (QSYS.LIB) or swapping profiles (IFS) to get access to data objects only via the approved applications. Do not forget that users or groups with *ALLOBJ special authority have access to all objects on the system. By removing write authority, the files are protected from being altered and encrypted. By removing read authority, the files are protected from being copied and stolen. One of the best ways to find out what authority is needed, what authority a user has, and where they are getting that authority from is to run an Authority Collection. This tool serves as a trace for seeing all the authority decisions the IBM i made under the covers, there are more than one might think!
Besides changes to user libraries and folders, IBM recommends making two changes to the IFS once the system is set up, configured, and running. These are to change the authority on the IFS root (/) and QOpenSys folders from *PUBLIC *RWX to just *RX. While these paths may need to be written to as the system is being configured, once operational there is no good reason to leave these locations as publicly writable. Review user and application created root IFS folders for excessive public write and read permissions and check the authorities under the /home directory if that is used by individuals for private storage.
In case there is a ransomware attack, the best way to recover is to have a well planned and tested recovery strategy. It is important that the backups are in an isolated or segmented network. Ransomware attackers look for online backups to corrupt or encrypt to make recovery more difficult. These backups must be kept in a safe place. Consider immutable backup technologies such as IBM’s SafeGuarded Copy or Recovery Point Flash. If the system is attacked, it is possible that those corrupted files would be replicated to an HA system or backup up on media and should be reviewed.
And as with all technology, staying up to date with supported operating system releases and software patches (PTFs) is crucial. Make sure the IBM i OS level is actively supported. Apply the latest cumulative, HIPER, Db2, and Security PTF groups at least once a quarter. Don’t forget third-party and open-source applications installed on the system as well.
Get an Assessment
Most IT standards require an annual security assessment performed by an outside organization. This is a great way to get “fresh eyes” to review the environment and make sure things are set how they should be. The IBM i Security Lab Services team provides security assessments to look for risks and weaknesses in the environment. An IBM i Security Assessment is a great way get a handle on the possible exposures. For more information about these assessments, please visit our website at: http://ibm.biz/IBMiSecurity#assessments.
IBM i Ransomware Protection Checklist
Disable guest/anonymous network access
Remove as many network shares/exports as possible
Set remaining shares/exports to read only, if possible
Move the share/export mount point to reduce the number of directories and files exposed
NEVER share/export the Root of the IFS (/)
Use QPWFSERVER to block access to QSYS.LIB from NetServer
Limit access to the shared data to as few people as possible
Change Library or IFS folder permissions to remove write authority (prevents file encryption)
Change Library or IFS folder permissions to remove read authority (prevents data exfiltration)
Change the IFS Root (/) and QOpenSys to *PUBLIC *RX from *RWX after system setup is complete
Have a completely tested isolated and segmented backup methodology and documented plan
Stay current on PTFs, patches, and OS levels
Get an annual security assessment from an outside source such as IBM Lab Services
