IBM i Security: IFS Real-Time Ransomware Protection

Protecting the IBM i Integrated File System IFS from ransomware and other forms of malware can be a fairly quick process, and there are a number of simple steps you can take to minimize your systems’ vulnerabilities to prevent a successful attack. You should be aware, viruses, ransomware and other forms of malware do not run on the IBM i, however these threats can severely wreak havoc on the IBM i as a result of a few common security vulnerabilities that can often be resolved with a few simple changes. Other IBM i environments will have to take additional security measures to protect the system from these cybersecurity threats using IBM i exit programs and IBM i Multi-Factor Authentication on the IFS, which will be explained for those that need it.

Contact us with questions or any assistance you need concerning the topics covered in this blog post. Customers may request free configuration assistance with security access control configurations, auditing, reporting, real-time alert, SIEM integration or other topics covered in this blog post.

Although every environment is unique, the most common IBM i security exposure to these threats is derived from allowing users Write access to the Integrated File System IFS via IBM i NetServer File Shares. The IBM i NetServer is how the IBM i provides access to the Windows Network Neighborhood, and the technology that enables Server Message Block SMB clients to access shared IFS directories and output queues. To protect the IBM i IFS from ransomware, the most significant threat you need to be concerned with are File Shares that provide users with “Write” access. File Shares with Write access allows users to modify the directory’s contents, and often all sub-directories and their contents. In this scenario, a user workstation infected by ransomware that has a mapped drive to an IBM i File Share with Write capability is an active threat. These IFS folders’ and contents are all vulnerable to the malware’s destruction, whether it be encrypting, deleting or exporting the data. 

Does your IBM i have File Shares that allow Write Access? 
If you own Enforcive IBM i Security suite, you can run a File Shares report from the Report Generator to identify which directories are exposed to your Windows Network Neighborhood. This File Share report will also show if the File Share has Write Access. If you do not own Enforcive, you may also view the File Shares access permissions in IBM i Navigator. The Write access permission enables malware to delete and rename files and directories. These user actions correlate to the File Server Delete, Move and Rename functions for the IFS. All users with a mapped network drive to File Shares with Write access is the vulnerability.

How do you know who is accessing your File Shares and what functions users are performing?
If the File Shares are not needed, you should remove them, or at least remove Write access. However, you cannot make this decision without having all the facts. In order to monitor user access to File Shares or any user access to the IFS, you need to have an IBM i File Server exit program, such that is provided by Enforcive Enterprise Security Suite or Assure Security System Access Manager. These IBM i exit point solutions enable administrators to audit and control user access to your IBM i, and also provide corresponding audit reports such that would help you determine which File Shares require write access, and for which users. 

The output of the File Share Access report shows users accessing each File Share and related functions users performed. Run this report over the past 30 or 60 days, and you will know exactly how to implement changes to your File Shares. Be advised, if your do not have full auditing enabled and optimization turned off for the File Server exit program, you still do not have all the information you need. This could be the case if the report is showing users only using the ‘Allocate Conversation’ function, which is used for IFS Logon, or possibly no traffic at all if logging is set to ‘Violation Only’ and policies allow all user access. Assuming full logging of the exit program is enabled and Optimization is disabled, then you can feel comfortable changing the File Share to Read only. If you made any changes, depending on the volume of user IFS activity, you should monitor system performance and log file size when un-optimizing and enabling full logging for the first time.

After you have detailed logging of the File Server, you can use the Application Audit report to determine if the File Share can be removed entirely or if the Write permission is truly needed. Before making the change, keep in mind users cannot upload files to a File Share that is Read only, however there are other protocols that can be used to upload files such as SSH (sFTP). If you have a high volume of files, you may want to consider using an IBM i secure file transfer automation tool to keep files in synch with an external server.

If you are able to change all File Shares to Read Only, the threat of ransomware harming your IBM i is likely resolved, but please read on to identity any additional vulnerabilities and the simple steps you can take to secure your system.

How do you prevent ransomware from encrypting or deleting IFS files of a File Share with Write permissions?
If you are unable to make a File Share Read Only, there are two mechanisms that need to be in place to prevent ransomware from damaging your IFS. The first is a File Server exit program as already explained. The File Server exit program enables monitoring, auditing and enforcing access control policies needed for securing the IFS, and for this use case, ‘File Shares’. The second is IBM i Multi-Factor Authentication that can be invoked by the File Server exit program. The File Server exit program acts as the first line of defense against network threats, because it takes precedent over IFS Object and Data authority settings when accessed via the network. By adding IBM i MFA on the user’s IFS initial connection ‘Allocate Conversation’ or alternatively, you may require MFA for the specific functions that ransomware may use. In either case, you can ensure vulnerable IFS resources are always protected in real-time by requiring MFA. The four IFS ‘File Server’ functions that ransomware may use are Change File Attributes, Delete File or Directory, Move file (includes rename of a directory) and Rename.

All File Shares that require Write authority to be enabled, should be limited to only users with a business requirement. Use Enforcive Enterprise Security or Assure System Access Manager to control and limit user access, of which will even controls user access possessing *ALLOBJ special authority. Now that you have limited user access to the File Shares with Write capability, you only have this select group of users to worry about. When the File Server exit program invokes MFA for the user’s request, it ensures malware cannot make changes to your IFS resources, nor by any user that does not provide the additional authentication, regardless of the File Share type, User authority or File Server permissions.

If you have users required to use the File Server’s Rename, Delete File/Directory and Move functions, the only way to protect your IFS resources in real-time, is by using IBM i Multi-Factor Authentication in conjunction with the File Server exit program. Requiring MFA for the initial connection or for using specific functions, ensures the user requests are indeed the authorized user, and not a hacker or malware that has gained access to the user’s credentials. IBM i MFA is as an additional layer of security, providing the necessary real-time access controls that will help prevent malware from harming IFS resources, and is the only real-time protection option available for the IFS.

The IFS may pose as a threat to the network as a whole, even if File Shares have Read only access. File Shares with Read only access still allow users to download to their computer. The IBM i Integrated File System IFS is a significant part of the OS400 operating system, of which allows storing PC like files ‘stream files’ and supports various methods of user access, including uploading and downloading files. If an infected file is put on the IFS, the IFS is now serving as a conduit for the threat, since it can be accessed by other PCs and drives. As a result, these infected files can redistribute the threat throughout the network. It is therefore recommended to scan the IBM i IFS for viruses, malware, spyware, ransomware and other threats to help prevent IFS objects from posing a spreadable threat.

Enforcive Enterprise Security and Assure Security customers can also control who is authorized to put files on the IFS, of which these protocols also support enforcing MFA for additional access control scenarios as well.  Any file that is destined for the IFS, should first be scanned by anti-virus and malware protection software before storing on the IFS. If for some reason your company lets external system(s) access your IBM i to upload files or if your IBM i is acting as a Client to get files, consider using another server your company controls and scan the files on this server before importing into your IFS.

When implemented, your IBM i IFS should be well protected from viruses, malware, spyware, ransomware and other threats. However, system environments are constantly changing and can impact your readiness to prevent such occurrences, so you should take further proactive actions to setup real-time alerts for such system configuration changes using Enforcive’s Alert Center and like forward event logs to a SIEM or SYSLOG Server that is monitored by security professionals. Your security team will likely want to be made aware of any threats or changes that impact your environments security posture and even attempts. These types of alerts should be configured in Enforcive to forward File Server and System Audit event logs to a SIEM for the SOC team to analyze using the Data Provider module.

Just as important, consider the sensitivity of the data on your system. If your system has any sensitive customer, employee or like data that would be detrimental if exposed, it needs to be protected with encryption. Whether your company has a compliance requirement or not, it only makes sense to ensure sensitive data remains encrypted at rest, as well as in transit. Up to this point, this article explains access controls for protection and prevention, but in the event sensitive data is extracted, you do not want to be at the mercy of the extortionist. Any data not encrypted at rest, is separate threat and risk that will likely require your company to pay the ransom regardless of your data recovery success.

Enforcive has over 350 pre-defined IBM i reports covering over 65 categories, as well as many other mechanisms to help address compliance initiatives, security vulnerabilities and IFS concerns:

Which IFS directories and files ‘File Shares’ are being shared on the network?
When and how do you find out when new File Shares are created or settings change?
When users are impacted by Ransomware, how do you know if your IFS resources are impacted?
Do audit logs provide you with the details you need and can be quickly shared?
How have users accessed File Shares in the past?
Do you know the sources and users uploading and downloading IFS files?
Can configuration changes be monitored and send real-time alerts?
Are event logs sent to a centralized logging environment so that critical events can initiate a timely response by administrators?
Can impacted users’ access to system and resources be isolated quickly without impacting other users or critical processes?

Other tips and recommendations to protect the IFS, Network and Users
1. It is recommend to make the NetServer Guest User Profile set to *NONE to ensure only users with IBM i user credentials can access the system. If it is not, figure out why you are using the Guest profile and how you can safely make this change. The Guest IBM i NetServer account enables unauthenticated user access to the system without a password. If you own Enforcive, run the IBM i NetServer Guest Profile report in the Report Generator and make sure the report shows *NONE. You can change the IBM i NetServer Attributes for the Guest User Profile to be *NONE by following these instructions. Open IBM i Navigator, Expand Network section and select Servers, click ‘TCP/IP Servers’, right-click ‘IBM i NetServer’ and select ‘Properties’. Go to the ‘Security’ tab and click the ‘Expand Next Start’ button, then make sure no profile is set for ‘Guest user ID’.

2. Remove File Shares no longer being used or if an alternative more secure method can be provided to users.

3. Only share specific IFS directory’s contents if feasible.

4. It is recommended to put File Shares at the very end of an IFS path, so that the least amount of resources necessary are exposed, and monitoring and protection efforts are also minimized.

5. Remove Write authority to the shared directories if possible. If Write authority is required, restrict access to the File Shares to only users that require access using Authorization Lists (requires V7R5 or higher). Read only still allows users to download the contents of the directory, although the Enforcive File Server exit program can prevent. Removing read authority prevents files from being copied and stolen. Downloading files from IFS only requires Read access, but Read access does not allow update, regardless of user authority.

6. Require IBM i NetServer client’s to sign requests, which is not the default. Signing requests hardens security connections by using a key derived from the client's authentication data and protects against many different types of attacks, such as: connection hijacking, downgrade attack, rogue server and spoofing by counterfeit servers, active message modification, and replay attacks. To make this change, open IBM i Navigator, Expand Network and select Servers, click ‘TCP/IP Servers’, right-click ‘IBM i NetServer’ and select ‘Properties’. Go to the ‘Security’ tab and click the ‘Expand Next Start’ button, then select ‘Yes’ in the ‘Require clients to sign requests drop down box’.

7. Configure Windows Servers and user workstations to not automatically connect to a File Share at start up.

8. It is highly recommended that *PUBLIC Object Authority to root ‘/’ is *NONE. It is very important to note, having root ‘/’ as a File Share is extremely dangerous, as it allows anyone access to the entire system. If root is shared, removing the share will ensure users will have access to only specific file shares. If for whatever reason you must allow a File Share to root, it is recommended to secure the QPWFSERVER Authorization List and prevent access to ‘/QSYS.lib’, of which controls access of all remote clients, including Windows Network Neighborhood, IBM i Navigator, Access Solutions and others. By default, *PUBLIC has *USE authority to QPWFSERVER AUTL, but it is recommended to be *EXCLUDE to protection QSYS.LIB objects.

9. Hide File Shares by adding a Dollar Sign ‘$’ at the end of the name of the File Share, i.e. fileshare$ Hiding File Shares requires users to know the name in Windows Network Neighborhood before mapping a network drive.

10. Do not allow broadcasting of NetServer to the Windows Network Neighborhood by disabling “Send browse announcements”. To make this change, open IBM i Navigator, Expand Network and select Servers, click ‘TCP/IP Servers’, right-click ‘IBM i NetServer’ and select ‘Properties’. Go to the ‘Advanced’ tab and click the ‘Expand Next Start’ button, then Unselect the ‘Send browse announcements box’ and Save. This changes the IBM i NetServer Browse interval to 0.

11. Require “Reconnect at sign-on” for all Shares. To make this change, open IBM i Navigator, Expand Network and select Servers, click ‘TCP/IP Servers’, right-click ‘IBM i NetServer’, select ‘Properties’, ‘Security’ tab and click the ‘Expand Next Start" button and select ‘Yes’ in drop-down next to the ‘Require clients to sign requests’. Restart NetServer to implement change.

12. Limit access to sensitive IFS directories and configuration options using IBM i security access controls ‘exit programs’ for File Server, FTP, TFTP, RMTCMD and File Transfer.

13. Monitor for changes of NetServer configuration. 

The Center for Internet Security CIS provides tremendous resources for best security and auditing practices for the IBM i that covers every OS400 version and release. Enforcive has reports that addresses each CIS IBM i Benchmark, which is a great way to ensure your security assessments are always up to date with industry best practices. The CIS IBM i Benchmarks cover 10 categories that assess critical components of the IBM i that include technical configuration settings for security and auditing, explaining the purpose of each benchmark, provide instructions for how to assess your environment and how to make the necessary changes to comply with best practices. Enforcive also has policy compliance templates to help ensure your system’s settings are always in synch with your defined security policies.

IBM provides a guide for implementing the IBM i NetServer and provides steps on how to secure the NetServer for Administrators.