Part 2: Network Protection & IFS Configuration Changes for IFS Defense in Depth Protection
This blog is the second in a series of posts that focus on IBM i Integrated File System (IFS) security and how to protect your IBM i IFS against virus & ransomware cyberattacks.
In part one of this series, we provided an overview of how IFS cyberattacks occur and outlined a five-layered Defense in Depth strategic plan to protect against virus and ransomware attacks against your IFS.
Defense in Depth protection deploys multiple layers of security controls for IFS protection. Multiple security controls provide redundancy when defending the IFS. If one security control fails, another control can step in to provide continual IFS protection.
Shown in figure 1, the five layers for an IFS defense in depth strategic plan are:
- Layer 1: Non-IBM i network protection
- Layer 2: Updating IFS related security configurations
- Layer 3: Using IBM i cyber-security software
- Layer 4: Perform regular IFS scanning and set up alerts
- Layer 5: Employ backup, recovery, disaster recovery (DR) and high availability (HA) protection
Let’s examine how each protection layer protects your IFS from cyberattacks.
Figure 1: The five layers of an IFS Defense in Depth Strategic Plan
Layer 1: Non-IBM i Network Protection
Layer 1 IFS Defense in Depth protection reduces IFS cyberattacks by eliminating viruses and ransomware from all devices that connect to your IBM I, including PCs/laptops, servers, & mobile devices. If your connecting device doesn’t contract viruses or ransomware, it can’t infect the IFS.
This strategy prevents and stops IFS cyberattacks by stopping malicious programs from infecting connecting devices. Do the following to implement layer 1 IFS Defense in Depth protection.
- Install anti-malware and anti-ransomware software on all devices that connect to your IBM i servers
- Initiate user education for recognizing and avoiding phishing tactics and social engineering scams that trick users into installing malicious software on their devices
Check with your organization’s enterprise security function to determine if these protections are in use and if not, how to implement them.
Layer 2: Update IFS-Related Configuration Settings
Layer 2 IFS Defense in Depth protection stops IFS virus & ransomware infections by configuring your IBM i IFS to reduce its virus and ransomware exposure areas. Making these OS changes will have a significant effect in reducing and mitigating any IFS damage suffered during a virus or ransomware attack.
You can reduce your virus and ransomware exposure areas by modifying the IBM i configuration settings shown in Table 1. These configuration changes can be performed using native IBM i commands and tools.
| IBM i configuration to review and how it affects virus & ransomware exposure areas
|
What to change to minimize exposure | How to implement the change |
|---|---|---|
| User profiles with Security Officer (*QSECOFR), All Object (*ALLOBJ) and Security Administrator (*SECADM) authorities. Reducing the number of users with elevated authorities reduces the possibility these users can damage IFS objects, if their device contracts a virus or ransomware.
|
Review user profiles with elevated user authorities and remove or change those authorities, as needed. | Inventory user profiles that have *QSECOR, *ALLOBJ or *SECADM authorities. Use the Display User Profile (DSPUSRPRF) command to view profiles. Use the Change User Profile (CHGUSRPRF) command to change profiles. |
| IFS file shares that share the QSYS.LIB or root (/) folders. When you share QSYS.LIB or root (/) as an IFS file share, any users with the proper authorities can corrupt, encrypt and rename objects in native IBM i libraries or in any sub-folder under the IFS, when a cyberattack occurs.
|
Remove or change any file shares that map to QSYS.LIB or root (/). Removing these shares reduces the number of IFS files/folders and native IBM i objects that can be damaged through viruses or ransomware. | File Shares can be created, viewed, and modified in the File System/file shares node of IBM Navigator for i or by using the GO NETS tool from a 5250 terminal. |
| Review and modify any additional QSYS.LIB access provided under the QPWFSERVER authorization list. The QPWFSERVER authorization list enables additional access requirements for all QSYS.LIB objects that can be accessed through a remote client.
|
Change QPWFSERVER access to tighten default QSYS.LIB access, as appropriate. | See IBM’s QPWFSERVER Authorization List in the QSYS.LIB File System document for details on modifying the QPWFSERVER access list. |
| Control access to IBM i file shares. Users who are mapped to a file share and have update access to that share can potentially corrupt, encrypt, or rename files in an IFS cyberattack. | Only include necessary users and groups in NetServer & IFS file share authorization lists. Review and modify any file shares that are publicly shared. Review and ensure that individual user permissions for IFS shared folders have appropriate authority to IFS directories and objects. Make file shares read-only as appropriate so files cannot be corrupted, encrypted, or renamed by most users.
|
File Shares can be created, viewed, and modified in the File System/file shares node of IBM Navigator for i or by using the GO NETS tool from a 5250 terminal. |
| Map IFS shares only as required. Users with unnecessary access to a file share can potentially damage files in that share, when their device is infected with viruses or ransomware | Avoid putting IFS drive mappings into default PC configurations or user setups. Avoid any drive mappings that auto-connect to the IFS. | Check Windows AD drive mappings and login scripts for automatic IBM i IFS drive mappings. Review IFS mapped drives that are configured on Windows PCs under the This PC function.
|
| Inventory and remove unneeded IFS file shares. Forgotten IFS file shares may still be active and attached to user setups, creating potential access points for viruses & ransomware to infect the IFS.
|
Find and remove any IFS file shares that are no longer needed. | File shares can be inventoried and removed through IBM Navigator for i or through the GO NETS menu. |
| Review IBM i NetServer Guest Profile Access. NetServer Guest Profile access provides a base level of access to IFS file shares for users who don’t have an IBM i user profile. If Guest Profile access provides read-write capabilities to IFS shares, guest profile devices mapped to an IFS file share can potentially infect the IFS with viruses or ransomware.
|
Review and limit what authorities are automatically granted to NetServer Guest profiles. | Check IBM’s Setting the Guest User Profile for IBM i NetServer Web page for more information on modifying guest user authority. |
Table 1: IBM i configuration settings that reduce virus and ransomware exposure areas
Layer 3: Use IBM i Cybersecurity Software
Layer 3 IFS Defense in Depth protection involves using third-party software for mitigating, avoiding and reducing IFS cyberattack risks. Protect against virus and ransomware attacks by employing solutions from a trusted vendor with a deep IBM i history in cybersecurity.
Third-party IFS cybersecurity software is available from several IBM i solution vendors, including SEA for the following categories:
- Anti-Virus software (AV) such as iSecurity Anti-Virus from SEA, detects, marks, quarantines and deletes infected files; stops attacks as they are occurring; and notifies & reports on virus attacks against the IFS.
- Anti-Ransomware software (AR) such as iSecurity Anti-Ransomware, to identify, delay, stop and report on ransomware attacks in real time; to disconnect remote devices performing suspicious activity; and to provide real-time alerts & activity logging and reporting.
It is inadvisable to use homegrown IBM i software to create your own cybersecurity system for battling viruses and ransomware. Cybercriminals are constantly modifying their malicious software, creating new strains and attack vectors for targeting your systems. It requires significant IBM i resources to develop and maintain an IBM i-based cybersecurity system on a daily basis.
For Anti-Virus and Anti-Ransomware software (AV/AR), look for the following valuable capabilities when choosing a solution, including:
Signature Refresh Methods: Automatically obtain frequently updated signature files that your AV/AR software will use to detect viruses and ransomware. Look for software that can retrieve updated signatures from different sources, including Internet retrieval and LAN retrieval from another server.
Virus scanning outside the IBM i: Some IBM i anti-virus software can relegate the scanning process to Internet-based Content Adaptation Protocol (ICAP) servers. With ICAP scanning, your IBM i system acts as an ICAP client that migrates the actual virus scanning process to an ICAP server. ICAP client processing frees up IBM i resources and reduces the overall impact that IFS virus scanning has on your server.
Recycle bin capability: Some AR software such as iSecurity Anti-Ransomware utilize an IBM i recycle bin. AR recycle bins retain copies of files deleted by a remote user. During a ransomware attack, administrators can potentially restore newly renamed and encrypted files from the recycle bin rather than having to restore them from a backup.
Continuous monitoring & assessment for ransomware activities: Look for anti-ransomware software that monitors and assesses ransomware activity based on suspicious actions. AR software may look at intermediate and final results of IFS activity from a remote device; unexpected changes to files; known ransomware identifiers; and IFS-based honeypots.
Don’t forget your other IBM i servers
Don’t just deploy anti-virus and anti-ransomware software on your production IBM i servers. Evaluate whether you need to deploy AV/AR solutions on your development, QA, testing, Web server and other IBM i partitions & servers. An IFS cyberattack on any companion or supporting IBM i servers can be almost as damaging as an attack on your production server, and these servers should also be protected.
Layer 4: Perform Regular IFS Scanning & Set Up Alerts
Layer 4 IFS Defense in Depth protection specifies that you configure and set up regular IFS scanning to detect virus and ransomware attacks. Use the scanning capabilities available in your third-party AV/AR solution to do the following:
- Real time IFS scanning: Automatically scan IFS objects as they are opened or closed. For virus detection, quarantine infected files to prevent the infection from spreading.
- Scheduled Batch IFS directory scanning: Configure your solution to schedule and automatically perform batch scans, using include/exclude processing to identify required folders and files to be scanned.
- Monitor and alert IT responders: Configure the package to send real time alerts whenever a virus or ransomware is found.
Layer 5: Employ backup, recovery, disaster recovery (DR) and high availability (HA) protection
Layer 5 IFS Defense in Depth protection specifies how to restore files that were damaged, renamed or encrypted by viruses and ransomware. This layer involves two steps:
- Recovering from viruses and ransomware; and planning for virus & ransomware recovery.
- Recovering from viruses and ransomware
For virus infections, you generally restore clean versions of infected files by using the solution’s data recovery capabilities or by restoring from backup.
For ransomware, there are three “cures” for restoring IFS files that have been made unusable by a ransomware attack.
1. Pay the ransomware and receive a decryption key: You pay the ransomware in bitcoin and the ransomware creator gives you a decryption key to use for unencrypting and renaming your files.
The FBI recommends not paying the ransom, but non-payment is sometimes required to restore your files and restart business processing. However, paying the ransomware and receiving a decryption key carries its own risks.
First, ransomware victims can’t be totally sure the decryption key will work. A ransomware victim could pay the ransom and still find themselves with unusable critical IFS files that have shut down part of the company’s business.
Second, the decryption key may work, renaming and unencrypting your files. But you do not know what else the ransomware has left. The ransomware program may not be totally removed from your system or bonus ransomware may be hiding in the IFS, waiting to be accessed by another user. Even if you get your files back, you may find yourself in the same ransomware situation days or weeks later.
Lastly, you may be encouraging the ransomware creator to attack you again. Paying the ransomware may encourage the creator to target you later with a different strain.
2. Restore the encrypted/renamed files: Once the attack is over, you can isolate the folders and files that have been damaged and restore from backup. This should rid your system of ransomware and return the damaged IFS objects to their last known good point.
3. Rebuild your IBM i server from scratch: Some industries have initiated protocols that after a server is corrupted by ransomware, the server must be rebuilt from scratch. To do this, you would have to use your disaster recovery (DR) plan from the last know good full system backup. This will rid your system of all ransomware but you will lose any production work entered since the backup was taken.
Planning for virus & ransomware file recovery
Besides knowing how to restore files corrupted by viruses and ransomware, layer 5 protection also means ensuring you have clean, recent backup media to restore from and that all your restoration processes work correctly. It is important to make sure your backup, restore, disaster recovery (DR), and high availability (HA) processes will meet your needs for virus & ransomware recovery.
Here’s what you need to do to ensure you’ll have the proper backup sets available for a virus and ransomware recovery scenario.
- Understand that High Availability (HA) may not help you with virus & ransomware corruption: Unless your HA software provides the ability to roll back updates, your HA setup won’t help restore corrupted files. Why? Because the corruption will be replicated to your target system.
- You may have to recover HA IFS files that were also damaged by the attack: If the corruption has been replicated to an HA system, you will probably have to restore the same target system IFS objects that you needed to restore on the production system.
- Perform regular Disaster Recovery exercises: Test your DR plan at least once a year to ensure your DR processes work correctly if you must rebuild an IBM i server from scratch.
- Determine the Recovery Window for your IFS: Some IBM i installations only back up the IFS when a full system backup (FSB) occurs. That means if you must recover IFS files from a full system backup, you will have lost any IFS object changes since the last FSB. Did the last FSB take place last weekend, last week, last month or last quarter? The answer will affect the freshness of any recovered data.
Reach out to IT operations and determine whether the IFS backup schedule is sufficient to restore IFS folders and objects in a timely manner, if an IFS restore is needed.
Definitely not the end for IFS cyberattacks
This concludes our two-part series on protecting your IBM i IFS from virus and ransomware cyberattacks. However, new cyberattacks appear all the time. Feel free to contact SEA if you have any questions about cybersecurity on the IBM i or if you’d like to evaluate and strengthen your own IBM i and IFS cybersecurity.
