Don’t take your eye off the security ball when it comes to open source.

I’ve had a few conversations in the last few weeks about open-source solutions on IBM i. While I’m an advocate and even sometimes a cheerleader for open solutions, these conversations have left me with concern about IBM i security. Don’t get me wrong; progression toward the open-source world is needed in our community. It opens up doors to hire new people with new ideas and sets them up to become productive as developers very quickly. We’re given the opportunity now, at this point, to do arguably what we’ve not been able to do as a community with our traditional applications written in RPG: enforce rudimentary object-level controls and not give away the keys to the kingdom with special authorities.

I came upon a conversation in which a vendor required the ability to securely transfer files to an IBM i partition. A number of people advocated using SSH and a chroot jail to ensure that the vendor is accessing only the directory structure assigned to him.

Couple of issues here.

First, I guarantee that if you turn on the SSH server and allow a NAT rule through your firewall to your IBM i, it will be hit with brute force password dictionary attacks within a couple of hours and continue all day, every day. Congrats! You’ve just made your IBM i a target on the public Internet. If you do implement SSH, you must ensure that any source IP addresses are from trusted sources, even on your internal network. Ensure that your firewall is limiting this traffic as a matter of risk reduction. Or even better, don’t allow a vendor direct access to your IBM i at all! Have them put files on a meaningless Windows server instead and then transfer to your IBM i via a more secure, internal option that you can control. Otherwise it’s a free-for-all.

I propped up a dummy server with SSH running with access from the public Internet last week to prove a point. Within a couple hours the server was subject to a dictionary attack. How did I know? The audit journal can capture invalid password attempts.

If you’re not watching for this stuff, your systems are getting probed and prodded all day long. Eventually, either valid accounts can be locked out that could potentially cripple a production process or a password attempt will succeed, especially if you allow *NOMAX for your QMAXSIGN system value.

Second, chroot is not a security measure. And yes, I’ll die on this hill. Chroot does not stop a user from interacting with QSYS, which means a chrooted user can call programs there. There are a number of documented methods on how to break chroot without needing root authority. Chroot can certainly help slow down an attacker, but it will not stop one. It’s a baby gate. It’ll work until someone learns how to climb over it.

Third, object authority must be taken seriously. I don’t care if you’re using file shares, FTP, FTPS, or SSH/SFTP. If a user interacts with the IFS, then object security on those directories will be your saving grace…or at least give you a fighting chance at minimizing damage. That means connected user profiles also get zero special authorities. If you condemn users to operate inside one directory structure by way of object security, then their potential damage is limited.

That leads me to the next issue: developers with *ALLOBJ.

By default, the ability to set up open-source solutions in the default directories on IBM i requires an IBM-recommended *ALLOBJ authority. Here’s where something like chroot can come in handy. You can load instances of IBM i open-source solutions into different chroot directory containers. With proper authority on those directories, your developers can work inside there and even update their OSS packages themselves.

Or you can just give developers *ALLOBJ authority.

I was privy to another conversation this past week in which an IT manager didn’t want to keep SSH running or have it auto-started via the job scheduler, but he was completely fine with a contract developer having *ALLOBJ special authority and the ability to start it whenever required. This stuff makes my head implode.

Security is all about risk reduction.

SSH is used to facilitate terminal shells (i.e., Bash, etc.) and is a preferred environment to work with open-source tools. There are no exit points associated with SSH, so monitoring and controlling what users do inside SSH is a problem. I already mentioned and demonstrated above that it’s a major attack vector.

Developers with *ALLOBJ own the entire system. Period. Full stop.

Not to say that developers are malicious. Of course not. But they’re human and are subject to human mistakes. It’s the equivalent to logging into a Linux distribution as root and then doing development.

I would argue that allowing developers the ability to start/stop TCP servers is a mistake. In my opinion, that’s not in their job description. Developers should be given rights to development libraries/directories only, and then code should be promoted to production by way of proper change-management procedures.

Developers with *ALLOBJ pose a far bigger risk than allowing SSH if you accept only connections from specific source IP addresses either on the system by way of packet rules or via the firewalls, where I would argue that type of rule really belongs.

Again, risk reduction is the name of the game. It’s a multipronged approach that needs attention now before there’s 32 years’ worth of open source security doors we need to close in addition to the ones we have now.