Reader Feedback On Guru: The Finer Points of Exit Points

July 12, 2022 Bruce Bading

Hey, Alex:

Hope you are doing well. I was reading this article about exit points and found some technical inaccuracies.

The Socket Exit can be used to cover the following: You can use exits block all unwanted ports blocked. I will be happy to talk with author of this article to explain how this works.

Not all services have exit points available.
User defined ports do not have exit points associated.

Best regards,

— Tony Perera, Trinity Guard, a division of Fresche Solutions

Hey, one and all:

As the article states, exit points are an enhancement to cybersecurity on the IBM i and should always be an integral part of zero trust and your overall strategy. The article in no way recommends to not implement exit programs or Socket Exits.

As much as possible, we avoid opinions and provide links to industry and substantiating vendor articles to validate statements:

Securing your workstations – IBM Documentation (Exit programs are not a replacement for object authority, which is designed to protect your objects from unauthorized access from any source.)

Sockets-related User Exit Points – IBM Documentation (Not all IBM developed applications call the configured user exit programs for one of the following reasons:

The application does not use sockets APIs for network communication.
The sockets API was called from a system task that is unable to call user exit programs).

The above bold and italicized font is copied directly from the IBM i knowledge base links on the subjects and is in no way altered or re-worded.

When implementing security on the IBM i, we will always recommend exit point and socket security and as BFB Security does not provide a comprehensive exit point solution, we may promote and recommend vendors that do.

It is simple logic, however, that when you have too many users with *IOSYSCFG, *ALLOBJ, and *SECADM special authorities, they can not only register exits and sockets, they can also remove them. This is why privilege account management, or PAM, is vitally important to limit and audit these authorities. When you have protocols that don’t require a password, you cannot protect your system from a breach when remote developers and users may use these un-authenticated root accounts. It’s not the fault of the exits or socket that developers choose to provide un-authenticated access with no password (example: DDMDRDA password required (*NO or *USERID) and it’s also not the shipped default out of the box experience of a new IBM i (literally out of the box). It’s also not the fault of developers who have not been trained and supported in DevSecOps.

Further, we cannot ignore the industry studies such as the Verizon DBIR that tracked 275 insider incidents in 2021 alone and promote privilege management. BFB Security follows the consensus of thousands in the Center of Internet Security (CIS) and our partner company IBM and specifically Rochester Lab Services (our previous employer).

Once you secure your sockets and services such as NFS or DDM/DRDA to prevent un-authenticated access and require credentialed authentication, the exits become a great tool to enhance your security the same way that firewalls and anti-virus do on networks, but hackers still bypass these when organizations don’t pay attention to internal vulnerabilities.

Note that Rochester Security, where I retired from in 2017, will state the same, locking doors and windows is secure as long as you don’t give everyone in the city a key or passcode.

The first two paragraphs on the second page of the article substantiate this. Exits do enhance your security.

Don’t get me wrong, exit programs are part of a system’s overall security, but again, read carefully what IBM states, “they are not a replacement for object authority.” They can however enhance existing network controls as in the following example:

SECURELIB/OBJA sets the *PUBLIC authority to *EXCLUDE. USERA and USERB are the only accounts that have *CHANGE authority to OBJA. This is a valid mandatory access control. But the administrator of the system does not want USERA and USERB to have ODBC access to OBJA and implements an exit program to enhance the network control by disallowing ODBC access to USERA and USERB.

To the contrary, our assessment tools collect all registered exit points and make recommendations that customers do implement exit points and sockets. We do however follow the zero trust model and implement PAM and Resource Security and follow all recommendations in the IBM i Security Reference and CIS Benchmarks (reviewed, commented and consensus approved by IBM Rochester, my former employer).

Controlling Access to SSH on IBM i | IBM i (OS/400, i5/OS) | Security (mcpressonline.com) (Note: IBM has not provided an exit point for the SSH daemon, and attempting to control access via the Sockets exit is tenuous at best.)

If you’ve read previous articles, you know that I’m all about implementing multiple layers of defense – in other words, using more than one technology to secure data. That way, if one technology is misconfigured or breached, there’s at least one other technology in place to protect your data. Steve Pitcher previously wrote about several issues associated with SSH, and I highly recommend you read these warnings.

Again, the above is taken directly from the linked article and has in no way been altered or re-worded.

Our assessment process also picks up the sshd_config and makes similar recommendations to Carol Woodbury’s in the article. In this way, we promote exits and socket security, but caution that we must implement multiple layers of defense.

Be safe out there. . . .

— Bruce

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search