Locking Down Exit Point And IFS Vulnerabilities On IBM i - IT Jungle

panggilansaja.blogspot.com

March 24, 2021 Pauline Brazil Ayala

It’s true that the IBM i server is among the most securable servers on the planet. But all too often, customers do not take the time to secure their environments properly. This is particularly true for two of the most oft-neglected components of the IBM i environment: exit points and the IFS.

IBM introduced exit points with the launch of OS/400 V3R1 way back in 1994. We remember that version well here at Trinity Guard, because soon after that, we developed the industry’s first exit point monitoring software for the AS/400 at PentaSafe, the spiritual predecessor of our company.

Exit points allow the IBM i server to exist securely in an Internet-connected world. They remain a critical layer of security due to the fact that the server’s original menu-based security system, developed in the old days of Twinax connections, is incapable of recognizing modern Internet protocols, like FTP, ODBC, and Telnet. Without any visibility into data arriving on the server via these network protocols, there is no way to detect unauthorized access to sensitive database files.

This part bears repeating: Without exit point programs in place to monitor exit points, administrators have no visibility into what activities these network connections are allowing on the box. By default, there is no logging for any activity occurring over these connections. You are as blind as a bat! And your network firewall will not help you. Neither will having stringent application authority levels for your users help, since this activity bypasses that system by coming in through the exit points.

The solution to this problem is simple: Build or buy exit point software to grant or deny access to users and applications connecting to the IBM i server. This is why IBM built the exit points in the first place! Sophisticated users will be able to write exit point programs that can handle the parameters that are passed by the exit points, and to use APIs to grab other pieces of data that are necessary (such as IP addresses) that are not passed in the parameters.

However, building these exit point programs — and perhaps more importantly, maintaining them as new versions of the operating systems are released — is not a simple task. It is possible to do all this work yourself, but unless you have a lot of time to build it, test it, and keep it running, it’s our opinion that you are better served by buying network security software from a trusted vendor. It will also typically run better, particularly in high-volume environments where having well-functioning JDBC/ODBC connections are critical to overall performance.

If you’re aware of the exit point situation, then you’re already ahead of the game. Believe it or not, but we run into IBM i customers all the time who are not aware of the significant security risks posed by the exit points and the need to monitor the exit points with exit point programs. Exit points are your friends, as they enable the IBM i server to function in the modern TCP/IP age, but they must be locked down to prevent the darker elements of the Internet from leaking into your system of record.

But here’s the thing: Exit points are not static. In fact, IBM keeps adding exit points with new releases of the operating system. With the launch of IBM i 7.1 back in 2010, IBM introduced a new exit point for controlling I/O occurring over socket connections.

Sockets are an increasingly popular way to pass data between the IBM i DB2 database and applications. On IBM i, many applications developed with open source languages, like Node.JS and Python are using socket connections. These languages are growing in popularity on the IBM i server, so it is especially important to get visibility into the socket connections that they use – what the connection is and where it’s coming from.

That brings me to the IFS. The Windows-like file system has been with us for decades, but its use has gone up significantly in recent years because of open source software. Just like with sockets, many applications built with open source languages that run in PASE also use the IFS as its primary repository for storing data.

And just as we’ve seen with exit points, unfortunately, many IBM i shops neglect to properly configure their IFS, leaving it open to malware, hackers, and worse.

One of the greatest risks of leaving the IFS unsecured these days is ransomware. You might have heard that native IBM i applications are immune from Windows viruses, and that’s true. But the IFS emulates a Windows file system, which means that viruses designed to infect Windows machines can also infect the IFS.

Proper configuration of your IBM i server is the key to good security.

At Trinity Guard, we have seen several IBM i clients who have let their IFS get infected with viruses and ransomware. In one situation, the client would clean all of their PCs, only to discover that they kept reinfecting all machines on the network! The culprit was the IFS, of course.

It’s important that IBM i users properly configure the IFS. Just as users must ensure that all native libraries are properly secured, IBM i administrators must make sure their IFS has all the proper authorities in place. In most cases, this entails going through each directory and making sure that the files have the right permissions.

Many IBM i customers try to do this manually, but that also entails a lot of hard work. And if you happen to miss one authority, you can bet that that will be the one that the hackers exploit! It’s also difficult to ensure that these authorities stay the same as the system evolves over time. For large environments, keeping all of these permissions straight from a Qshell interface is a challenging task, to say the least.

Once again, this is an area where independent software vendors can come to the rescue. The IBM i server can be secured with manual configuration, but it’s much more difficult to do it that way. A better solution is to leverage existing tools that not only automate much of the work of locking down the IFS and exit points, but keeping it locked down as the system changes. It will also show auditors that you take security seriously, if you’re lucky enough to get audited.

In closing, the IBM i is definitely one of the most securable systems on the planet, but all too often, customers don’t take the take time to configure the settings required to actually get to the high security level that it’s capable of achieving. The IFS and exit points are two of the most critical systems on modern IBM i machines, particularly when using open source software, but they also present vulnerabilities when left unconfigured.

Getting these systems locked down is critical to actually fulfilling the IBM i server’s high security potential, and avoiding the high costs that come with a data breach or ransomware attack. Finding the right partner that can help you achieve a higher level of security is easier than you may think, particularly when you have the right vendor at your side.

Please join us for a webinar taking place Thursday, March 25, at 12 CT to see examples of these vulnerabilities in action, as well as learn how to bolster your IBM i network security and defend against them. Register here: https://attendee.gotowebinar.com/register/1353293618450615567

This content was sponsored by Trinity Guard.

Pauline Brazil Ayala is the vice president of operations and co-founder at Trinity Guard.