Ransomware Recovery Solutions

What do you do when you are the victim of a ransomware attack?

This can depend on the depth of that attack and what steps you have taken to prevent it. Chilli IT take these threats very seriously with our commitment to provide recovery solutions through IBM i Safeguarded Copy.

We can also all make our lives easier by employing robust security controls that prevent
ransomware attacks succeeding in the first place or reducing their effect. That’s great in an ideal
world, but in the real world having the resources and time to plug every security gap can be a
monumental task, but small changes here and there can give you good protection.

How does a ransomware attack work?

A ransomware attack is made by corrupting or encrypting your system in such a way as to make it
unusable. There’s a good chance that this attack could come via a file share set up over your IBM i’s
Integrated File System (IFS). The IFS is an umbrella file system providing, amongst other things,
Unix or PC like file systems to your applications. One of those file systems is QSYS.LIB. This is
the super library QSYS under which exists the operating system; licensed program libraries and
most importantly of all your user libraries containing your software and data files.

We may not take much notice of QSYS.LIB being a file system in the IFS because we usually
access it using the IBM i commands, programs and API’s designed for that file system. For
example, to delete a file we would use the DLTF command rather than drill into a file share and
delete it that way. If your aim was to make your IBM i unusable via a ransomware attack, probably
one of the best ways to do it is to attack the contents of the QSYS.LIB file system.

There are many more people who know how to traverse a file share than there are who know their
way round an IBM i command line. This situation provides a security gap that is widened when you
consider that the default security configuration for the root file system is *RWX or Read, Write and
Execute. If the root file system is set up as a file share this allows you to drill into the root of the file
system and then into the QSYS.LIB file system and do untold damage.

How to prevent complete corruption

You may want to rethink your file shares or the authorities on the root file system but before you do
this you would have to check out whether any of your existing processes would be affected. There
is one very simple thing you can do however and that is prevent access to the QSYS.LIB file system
via file shares because there are few reasons to access this file system in that way.

This is done by changing the *PUBLIC authority to the QPWFSERVER authorization list from
*USE (access to QSYS.LIB file system allowed) to *EXCLUDE (access to QSYS.LIB file system
denied). *PUBLIC is a catch-all for any user not specifically named. This will prevent anyone who
does not have *ALLOBJ special authority and who does not have specific *USE authority to the
QPWFSERVER authorization list from drilling into the QSYS.LIB file system via a file share. All
other parts of the IFS are unaffected. You will want to make sure that you control which users have
*ALLOBJ special authority and who is authorised to the authorization list but these steps should
form part of good security control, especially the availability of *ALLOBJ special authority.

The above step will go a long way to prevent the complete corruption of the system and may keep it
available for you without having to consider complete recovery processes.