Today, we’re talking about a sensitive topic: the idea of malware, ransomware, and viruses on your IBM i server.
Many of us have heard that you can’t get a virus on this platform, but the reality is that the integrated file system (IFS) is a tree-like structure. This structure can house Word documents, PDFs, MP3s, JPEG images, and these files can be just as infected on the IBM i server as they can on any Windows work station or server.
One of the misconceptions is that a virus on IBM i won’t do any damage to the native side of the system. But, as you can see, QSYS.LIB is one of the branches of the IFS. That contains all your native objects—your RPG programs, your query definitions, and even your physical data files.
A virus that lands in the integrated file system can spread to other objects in the IFS or even other servers. But it can also potentially drill down into QSYS.LIB, causing issues with the existing objects there. It’s not spreading the infection because that’s a projection mechanism with in the OS, but that’s not to say it can’t delete, rename, or potentially encrypt those native objects.
The good news is that the OS has some built-in functionality to support doing native anti-virus scanning within the IBM i environment, enabling us to potentially protect the system from an infected object delivering its payload.
Now, this functionality is in existence, but it’s dormant because the operating system contains no native scan engine. So, we need to talk about how we activate that.
If your first thought is when you get a virus that you would roll to a backup machine, maybe do a disaster rollover, just remember that once the object hits this IFS here, it has already been replicated to the IFS on that backup server.
How do we fix this? Let’s find out exactly how this can be done. I’d like to introduce the native scan engine for IBM i. It’s called Stand Guard. It plugs into the OS, which means we get several significant advantages over trying to do a scan from a remote server through a file share.
First of all, we’re able to do live scanning. Thanks to the integration with the operating system and the foundation that was built by IBM, we can scan an object before it is actually opened, which means it is preventing that infected object from delivering its payload.
The integration with the operating system is key to the success here. From a performance perspective, from an integrity perspective, we’re taking advantage of properties that exist on all the IFS files that say when to scan, how to scan, and what should we do if an infection is found. This functionality is self-contained as well, which means the IBM i server can be disconnected from the network and scan itself without being reliant on any type of network connectivity.
If you try to scan across the network, not only does that create a significant performance overhead, but all those IFS objects are traveling in clear text, which means you’re potentially transmitting data that people can collect. In addition, you need a profile that has all object authority, which means we now have a drive share set up that’s opening the door arguably wider than it was before.
You’re much better off doing this natively. In fact, to me it’s the only way to do a scan, and using the Stand Guard engine is the recommended approach. This engine is a commercial-grade scan engine, it’s powered by McAfee, it downloads its DAT files directly from that organization, and they’re typically updated on a daily basis.
This is a very comprehensive, powerful approach to protecting not only the IFS but also the native structures within IBM i.
Thanks for joining me. Hope to see you on the next vlog.