In 2021, a company was hit by ransomware every 11 seconds. And there are no signs of the intensity or the frequency of attacks slowing down – these cyber threats are only becoming more sophisticated. Unfortunately, many companies are still not ready to defend against these threats – a recent penetration testing (pen testing) study reveals that cyber criminals can penetrate 93% of company networks. Instead of crossing our fingers and hoping to be in that 7%, we should be focusing on learning as much we can about how to protect our systems better.
Security on the IBM i is a complex topic and it demands the same care that we dedicate to programming it. More than a few companies have found out the hard way that applications are not much good if they are not secure. Making this rather big change in perception can help IT organizations prepare to defend their systems effectively. Nearly 50% of IBM i shops have little to no security knowledge and skills – more often than not, the ‘security guy’ retired 5 years ago and nobody’s been paying attention to it since. “Can my IBM i really be hit with a virus?”, “Can it be hit with ransomware?” – these are the questions that are regularly raised by clients. If that is you, this article will hopefully be able to guide you on where to go from here.
One of the top threats we face today is phishing – over 40% of ransomware attacks are from phishing schemes. Other significant threats include exploitation of remote access (comprising another 40% of all attacks), software vulnerabilities, and an abject lack of internal training. So, how do these relate specifically to the IBM i? Network exposures are valid threats on the IBM i – just because your IBM i is behind a firewall does not mean that it is safe from internal OR external network threats. In many cases, objects and IFS files & directories are overly exposed, leaving valuable data completely unprotected. The tools that IBM i has given the system are not properly implemented and the configuration that’s available to protect the data is usually not set. Many IBM i shops also tend to have multiple (if not all) profiles with all object authority, a permission configuration that should ideally be given to very limited profiles and then very carefully managed.
Viruses can penetrate the IBM i. While the system is an EBCDIC character format and typically, viruses that hit Windows and similar systems are in ASCII format, it is important to consider what “penetrate the IBM i” actually means. If your network layer is not secure, especially your socket exit point, it means that viruses can reside in your IBM i in the Integrated File System (IFS) and infect your corporate network from there.
QSIS.LIB is also a part of the IFS, which is just like a Windows directory structure that is not in EBCIDIC. Data can get corrupted – data that is found in QSYS.LIB is part of that structure and therefore, can be changed, corrupted, damaged, or even deleted. So, if someone has unauthorized access to it, by hand, or via malware, it can cause significant damage – hence, the urgent need to secure the IFS.
There are two basic questions to ask when you’re securing your network:
Do you know who is connecting to your system?
Do you have the ability to block unwanted network connections?
User Authority
It is very common to see users with unrestricted all object authority and objects, files, programs, data areas. Years ago, this was the only way to sign on through, what we call, the front door. We depended on menus to control access to the files, programs, and data areas – the user would sign on and the access to the files and programs was governed by the initial menu user parameter, and the application had restrictions on what could be accessed at the menu level. However, this is probably a lesser used way of signing onto the system now. There are many remote servers that are active by default, connecting people to applications on IBM i as well as socket connections through web servers and SFTP.
The FTP, the database servers, file servers, and remote command servers continue to run on every day, but, by default, there is no logging or monitoring of these types of access. If you have socket communications enabled, they bypass the exit points of the remote servers. When applications connect through socket APIs (aka the lower layers), it bypasses the traditional exit programs or points that some people may have secured already. It is important to understand that a lot of things can penetrate at this lower level, rather than at the typical or traditional exit point level.
If a user who has all object authority no longer has a menu configuration that restricts access to the system, anybody can still access the data. If there’s no menu to control access, there is nothing preventing this user or the threats that come with it – whether that is J. Smith coming in through a socket connection and accessing the data, or malware that got onto J. Smith’s laptop and is now trying to make a socket connection to the data on the IBM i platform. There are no gatekeepers or checks to monitor and secure these types of access. IBM i does has infrastructure architecture to help with this, but there are no default audit trails or security.
Exit Programs
The solution to this is exit programs. Using the FTP remote server as an example, if an exit point is configurable for any remote server, an exit program (user-written programs processed when an exit point is invoked) can be installed on it. When a remote request is made to a server on the IBM i OS, the exit program is processed before the request is executed. In the exit program, you can choose to approve or reject the request to access the data. Essentially, whether it’s J. Smith or ransomware/ malware that got on his system, the request will be evaluated, offering you a chance to audit the request. Additionally, you also have a trail of what is happening and the ability to see who is accessing your system.
Note: You can see a list of exit points available on the IBM i on the registration information.
There are different types of exit points and not every exit point is a remote server exit point or applicable to network traffic. For the ones that are, if you don’t see file server FTP, the socket layer, or an exit program, that means that they aren’t secure. Additionally, if you see an unfamiliar program there, it might be a vulnerability – it is well worth your time to figure out what specifically it does.
Socket APIs
They connect through a special type of exit point that are not a remote server. With more open-source system programs and tools on the IBM i platform, a lot more is available through the Pace environment on the IBM i and clients like Putty that use SFTP transactions. They use connections to the IBM i at the socket layer.
To illustrate how this is relevant, let’s consider this hacking attempt. A system administrator had configured TG Detect to send alerts when there was a failed socket transaction – at one point, he got a lot of alerts but couldn’t figure out who was trying to access the IBM i system. We used TG Secure and network security to implement exit programs and see the incoming transactions that show their IP address. Turned out, the IP was his own. A vulnerability scan on his Windows machine revealed malware. The alerts made sure that he had the chance to clean up the malware and prevent the rest of the system & network from being infected. This attempt was through SFTP, which is why it is very important to monitor this traffic.
This is a screenshot of the incoming transactions on TG Secure – lots of data is collected when you have an exit program installed on an exit point. One of them is the database server: when a transaction comes in, you know which IP address it came from, the function that happened, and how many times the transaction occurred. It also shows you that the transaction passed, what object was accessed, and the timestamp of the transaction. With exit programs, you can pass or fail transactions i.e., create rules to allow or deny the traffic that’s collected. It is imperative that you monitor everything that’s coming in. If you’re monitoring socket connections, for these types of connections to be collected, you want to have QOD level system value set to include net CMN, net fail, and net SOC.
It is possible to manually write exit programs, but it can be quite time consuming. In the long run, it is best to automate what you can on such complex systems and exit programs are no exception – automating this can make sure every critical exit point you have is (and remains) protected.
IFS Vulnerabilities
Your IFS can be extremely vulnerable, so ideally you should block or at least monitor and track connections made to your IBM i via all remote access points. Additionally, pay attention to the public authority settings for your IFS’ folders & the permissions on your files within and monitor the IFS for authority changes. It can seem like a massive task for some organizations, but it is not unachievable. Understanding what your permissions are in the IFS is the first step – go to a command line, type WRKLNK, and select option 9 to work with authorities. You should be able to see all the permissions available for the directory that you are in. You can also go into the QSHELL environment and run ls minus l to list the permissions and ownerships, you should be able to see the directory listing. It will tell you what type of item it is – a file directory, symbolic link, et. al. – and the read, write, and execute permissions for the owner of the item, the group, and then others (*PUBLIC). It is important to make sure that *PUBLIC cannot read, write, or execute on your root directory – goes without saying, if there is a ransomware attack on your system and the root is open, then it has complete access to your root and can corrupt your entire IFS.
As discussed before, there are different ways (like socket connections, remote server connections) to access data on the IBM i. Even if you don’t have drives mapped to the IFS, the data can still be accessed – a prime example of how an application can bypass the file server would be SFTP.
Secure Your IFS
One of the most important actions you can take today is to configure the permissions on your IFS carefully – *PUBLIC should not have read, write, execute for sensitive data. Lock down your root directory and spend the time to analyze the permissions available, and then implement that security scheme. To implement strong IFS permissions, you can use the CHANGE AUTH command and set data & object authorities there. You can also use a QSHELL commands to resolve authority issues. To change permissions on a file or directory, use ‘chmod’ or to change its owner, use ‘chown’.
Automation with TG Secure
The resource manager within TG Secure offers the option to configure authority schemas, making it easier for you to set up IFS authorities
You can sort through authority collection data to identify the least privileged model for your system, to know what the minimum required authorities are for operating an application
It can also generate authority compliance reports – it will show you the current value and the expected value of the schema for each item in the schema, in the scope of the schema. It’s a great way to see what the current authority is and what it should be. You can also automatically enforce them through authority schemas as well
In summary, to defend your servers and IBM i against internal and external threats, it is important to monitor and secure your system, especially network access for remote servers and socket connections, with exit point programs. There is no default monitoring for remote connections, so permissions of files and directories in the IFS must be configured to secure and monitored regularly to protect your business data.
For anyone who is just getting started with security, have a free security assessment done on your system to understand the state of security on your IBM i server. If you are a little bit more advanced, download the free trial to all the tools within TG Security Suite for 30 days and run some reports on your system. These tools allow you to collect the least privilege model information for your system and generate you report cards that give you a good idea of where you stand. You can also watch this on-demand session on IFS and Network Security, featuring live demos of TG Security Suite.
