Thoroughly Modern: Good Security Is Just As Important As Good Code

June 13, 2022 Pauline Brazil Ayala

Can my IBM i really be hit with a virus? Can it be hit with ransomware?

These are the questions I regularly get from clients as a security expert with more than 20 years of experience. With the pervasiveness of these ransomware threats and sophisticated cyberattacks that we’re seeing in recent times, it only makes sense that we pay close attention to these threats.

Security on the IBM i is a complex topic, and it is not one that is easily tackled with a few bullet points and tweaks of systems settings. Just like programming on the platform, for that matter. And people have to take the same care with security that they do with programming. These days, applications are not much good if they are not secure, as more than a few companies have found out the hard way. This is a big mind shift, and one that a lot of IT organizations need to get in gear with.

So, let’s dive right into protecting your IBM i from network threats and viruses and explore how to secure your network access and your IFS.

In the table below are some recent statistics on cybercrime and threats. Did you know that in 2021, every 11 seconds a company was hit by ransomware? It’s not going to suddenly stop, and it is in fact becoming more common, more prevalent, and more sophisticated – and surprisingly many companies are still not ready to defend against these types of threats. A recent penetration testing – sometimes called pen testing in the lingo – study reveals cyber criminals can penetrate 93 percent of company networks, 93 percent. We’re all hoping we’re in that 7 percent, but the reality is that many of us are probably not. So, we want to learn as much as we can about how to protect our systems.

Nearly 50 percent of IBM i shops have little to no security knowledge and skills. This is something that we see over and over again as an issue that y’all are dealing with and we try to help with. Sometimes it’s because the person that handled security 20 years ago retired five years ago and nobody’s been paying attention to it since, or maybe the current person simply doesn’t know what to do. Hopefully we’re going to help you out with that a little bit today and give you some next steps on where you can go from here.

When we’re talking about ransomware and these sophisticated cyberattacks, you don’t have to look very far in the news to see where the top threats are coming from. What we see mainly in organizations is that phishing is still right at the top of the list. I’ve seen statistics recently that also said more than 40 percent of ransomware attacks are from phishing schemes and over 40 percent are also from exploitation of remote access. Then there are more sophisticated threats that take advantage of software vulnerabilities. Of course, then there’s an internal lack of training that we just have to keep working at and keep working at, because we’re only as strong as our weakest link, right? The weakest password on the system is the strength of our security.

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 within your organization does not mean that your IBM i is safe from network threats internal to the organization, as well as possibly externally to the organization. In many cases, there are overly exposed objects and IFS files and directories. Meaning the permissions and the object authorities are not set correctly. So we have valuable data that’s sitting out there, but it’s not protected. We’re not implementing the tools that IBM i has given the system and using the configuration that’s available to protect the data that we have out there. Then of course, there’s the tried and true profiles with too much authority. We see this over and over again, profiles with all object authority. It should be very limited on your system, very limited and managed very carefully.

So viruses are something that can penetrate the IBM i. I know that there’s someone thinking, “What? You don’t know what you’re talking about.” I know that on the IBM i the system is an EBCDIC character format and typically viruses that are hitting windows and systems like that are in ASCII format. So you have to look at what “penetrate the IBM i” actually means. If you’re not securing your network layer, especially your socket exit point, it means that viruses can reside in your IBM i in the Integrated File System (IFS) and can infect your corporate network from there.

QSIS.LIB is also a part of the IFS. So the IFS is just like a Windows directory structure that is not in EBCIDIC. Data out there can get corrupted and data that is found in QSYS.LIB is part of that structure. So it’s accessible through the IFS. It can be changed, it can be corrupted, it can be damaged, deleted. If there’s unauthorized access to it, whether it’s from a particular user, by hand, or whether it’s from a malware that finds its way onto your IFS, it can do damage. You need to pay attention to the IFS in a particular way.

There are two basic questions when you’re securing your network: Do you know who is connecting to your system? And do you have the ability to block the unwanted network connections?

This is what we commonly see on many systems. Users with way too much authority, with all object authority and objects, files, programs, data areas. Access to these objects is often left unrestricted. Typically, we’re used to thinking, “Okay, this is how we sign on to the IBM i.” Years ago, this was, of course, the only way to sign on through what we call the front door or what I’m calling the front door at the local sign on screen.

Then we depended on menus to control access to the files and programs and data areas. So the user would sign on and the access to the files and programs was governed by the initial menu user parameter, and the application at the menu level had the restrictions for what could be accessed. However nowadays, this is probably a lesser used way of signing onto the system. There are many remote servers that connect people to applications on the is IBM i as well as socket connections where you’re connecting through things like web servers and SFTP and things like this. And thus there are many ways for a user to sign on their access data on the IBM i. The remote servers are active by default on IBM i. So FTP is running, the database servers running, file server is running, remote command server is running.

All of these servers, there’s many more, are active and brought up by default. There is no logging or monitoring of these types of access by default. Socket communications are enabled and they bypass the exit points of the remote servers. So the socket layer, the application layer, we’re talking about the remote servers and at a lower level is the socket level. So when applications are connecting through socket APIs, it bypasses the traditional exit programs or exit points that some people may have secured already. But this is one to make sure you’re thinking about and paying attention to, because a lot of things can penetrate at this lower level rather than at the typical or traditional exit point level.

If this user has who has all object authority no longer has that menu configuration to restrict access to the files and programs and data areas, etc., on the system, public is still “star all”, which means anybody can access the data and the user has too much authority anyway. If there’s no menu to control access, what’s preventing this user or the threats that come with it, whether it’s J. Smith coming in through a socket connection and accessing the data, or whether it’s the 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. Where’s the gatekeeper? What is the check that’s going to monitor and secure these types of accesses? Because there’s no audit trail by default and there’s no security by default. There’s infrastructure architecture on the IBM i to help with this, but out of the box, there’s nothing there.

The solution is exit programs. I’m just using the FTP remote server as an example, if an exit point is configurable for any remote server and an exit program can be installed on the exit point, exit programs are user written programs that are processed when an exit point is invoked. So 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 have the ability to determine whether or not the request is rejected or whether it’s approved and the data is accessed. So once again, whether it’s J. Smith, or whether it’s the ransomware that got on his system, or the malware that got on his system, or whatever user happened to hijack his, his system, the request is being evaluated. It’s not just a free for all, and anything is being allowed in. Now, there’s a chance to secure the request and also audit the request so you have a trail of what is happening on your system, and you can see who is accessing your system.

If you go to work with registration information, you can see the list of exit points that are available on the IBM i. When you select option eight on an exit point, you can view the exit programs that are installed. If you go to this facility and you don’t see any exit programs installed on your exit points, now not every exit point is a remote server exit point or applicable to network traffic. There are different types of exit points, but for the ones that are, if you don’t see for things like file server FTP, the socket layer. If you don’t see an exit program on there, then that means that you don’t have any security. If you see a program on there and you don’t know what it is, you also need to find that out because that could also be a vulnerability, which is not probably as likely, but you want to know what it’s doing. These are powerful programs.

Special note: Socket APIs connect through a special type of exit point. They’re not a remote server. It’s a different type of exit point. The IBM i platform is moving to more and more open source system programs and tools, which is great. There’s a lot more available through the pace environment on the IBM i and clients like Putty that use SFTP transactions and things like that. They use that type, the connections to the IBM i at the socket layer. We actually had an example of an admin who was using our software and we found that he was wondering what was causing all of the alerts about failed socket transaction attempts. So he had TG detect configured to send alerts when there was a failed socket transaction. He couldn’t figure out who was trying to access the IBM i system. So we went to one of our products called TG secure and network security, which is where we implement exit programs and could see the incoming transactions to show the IP that the transactions were coming from. Turned out the IP that he saw was his own. This was right around the time the Log4Shell vulnerability had just been announced and sure enough, when we ran a vulnerability scan on his Windows machine, we found the malware and were able to clean it up and prevent the rest of the system, and the network, from being infected. So it’s things like that that we’re looking at, and that attempt was through SFTP. I am going to show you an example of that here in a minute.

This is just a screenshot of the incoming transactions in TG secure that we have available. So different data that you can see that’s collected when you have an exit program installed on an exit point. This one, for example, is the database server. This transaction came in, you can tell the IP address that it came from, the function that happened, how many times the transaction occurred. This is going to show you that the transaction passed, and this is what the object was that was accessed, and, of course, the timestamp of the transaction. Like I said, with an exit program, you can configure whether or not you want the transaction to pass or fail so this gives you the ability to do that. You can create rules to allow or deny the traffic that’s collected, that you can see here.

Of course, you want to monitor everything that’s coming in. This is just another example of some data that’s available at the socket layer. If you’re monitoring socket connections, for these types of connections to be collected, you want to have QD level system value set to include net CMN, net fail, and net SOC.

This is the actual socket exit point and writing these programs is quite time consuming. It is possible and you are welcome to do it. We also have automated this, however, and it is best to automate what you can on such complex systems. The point is a critical one that you want to have secured.

In TGSecure, if a rule is created, it allows you to define the action, whether it’s pass or fail. You can also get alerts on these transactions as well so that you can receive emails when someone is trying to access your system. Additionally, TG Central is our web-based GUI console for the TG security suite.

As far as IFS security is concerned, you want to block or at least monitor and then track the connections to your IBM i through all remote access points. It’s important because your IFS can be very open. You need to know the public authority settings for your IFFs folders and the permissions on your files in there. You also need to know if you have the ability to monitor the IFS for authority changes. I know that this can seem like a mountain for some organizations, but it is possible. First of all, you need to understand what your permissions are in the IFS. You can do that by going to a command line and typing WRKLNK and selecting option nine to work with authorities and you’ll see all the permissions available for the directory that you’re in.

You can also go into the QSHELL environment and run ls – l to list the permissions and ownerships. This is the type of data that you’re going to see right here. Basically you’re going to see the directory listing. Then it’s going to tell you the type of item that it is, whether it’s a file directory, symbolic link, etc., and then the types of permissions. Then the read, write, execute permissions for the owner of the item, the group, and then others, which others is basically public start public. If others can read, write, or execute on your root directory, for example, you have a major vulnerability there where anybody can access anything. Again, if there is a ransomware attack on your system and the root is open, then obviously it can get to your root and corrupt your entire IFS.

There are different ways to access data on the IBM i and this is the same type of issue. You can look at this now as instead of object authorities, as IFS files and directories, and the permissions on those. Even if you don’t have drives map to the IFS, this data can still be vulnerable. I know I’ve mentioned SFTP a few times. Again, that’s a prime example of how an application can bypass the file server. That access is not going through a remote server.

How your permissions are configured on your IFS are very important. You need to make sure that your public is not read, write, execute for sensitive data, lock down your root directory, spend the time to analyze the permissions available, and then implement that security scheme. To do that, implementing strong IFS permissions, you can use the change auth command, and you can set data authorities as well as object authorities on there. You can also use a QSHELL commands to resolve authority issues. To change permissions on a file or directory, you can use the chmod command or to change an owner on a file or directory, you can use the chown command.

What we recommend doing is using TG secure. In the resource manager, there is an option to configure authority schemas. So you can set up the way that you want the authorities in your IFS to look.

For example, in this one, I have both IFS objects and native objects because the object authorities on your native objects is critical as well. This one is going to show you that you can. How I have this one set up, I have the object owner for this directory to be TG owner and I’ve secured it with an authorization list, as well as I’ve set the public user to exclude so that nobody can access this directory.

Then for the owner of the directory, I’ve given them read, write, execute authority, for this finance library. I’ve set the public authority to off list and the authorization list is TG off list. I’ve also set TG owner to have all authority to this library. This is a tool that allows you to configure what you want the authorities to be. There’s also an option in TG Secure to sort through authority collection data if that’s something that you’d like to use 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’s going to show you the current value and the expected value of the schema for each item that’s in the schema, in the scope of the schema. It’s a nice way to see what the authority should be and what it currently is. Then you can choose to enforce that through authority schemas and automate that as well.

In summary, use exit point programs to monitor and secure your network access for remote servers and socket connections. Remember that there’s no default monitoring for remote connections and permissions of files and directories in the IFS must be secured and monitored regularly for changes to protect your data.

For anyone who is just getting started with security, we can do a free security assessment 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 TGSuite 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 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 TGSuite.

Pauline Brazil Ayala is vice president of operations of Trinity Guard, a business unit of Fresche Solutions.

This content is sponsored by Fresche Solutions.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search