I have reviewed the security configurations on more than a thousand IBM i servers over the last decade. During that time, I've seen some poor configurations that leave these critical servers vulnerable.
Typically, I don't remember the specific details from these instances, but there was one review recently that will haunt me for quite some time.
So, what could have been so especially scary about this one? Unfortunately, there were a number of things.
Dangerous User Management
This server had almost 2500 user profiles, but the company had less than 250 employees.
You may think that doesn’t warrant any alarm bells, but it’s important to note that disabled profiles can still run batch jobs. If one of these profiles managed to fall into the wrong hands, it could be used to execute commands, alter data or even exfiltrate data.
To make matters worse, more than 2300 of those user profiles had *ALLOBJ authority, likely stemming from group profile authorities.
Nearly 1700 of those profiles had sat unused for at least 30 days, with a quarter of them still enabled.
When an employee separates from the company, their profile should no longer be able to sign on, run jobs on the system or keep administrative rights.
Left as-is, there is potential for abuse and malicious activity to go unnoticed until the damage is already done, especially if they have elevated authority.
Reckless Password and Sign On Policy
Close to 1300 user profiles had default passwords - user and password matching - with half of those enabled and ready to use. Using a default password is like installing a deadbolt on the server room door but leaving the key in the lock on the outside.
Anyone – including threat actors – with knowledge of the naming convention of your user profiles will be able to unlock that deadbolt.
Of the over 600 user profiles with failed sign on attempts and no successful sign on since those failed attempts, one of them has tried a terrifying 3+ million times. In a distant second is the user with 1.7 million failed sign-on attempts.
The profile issues paint a frightening picture, but what really drove the nail into the coffin was that there was NO LIMIT on invalid sign on attempts for these users - endless guesses at passwords through any of the TCP interfaces!
I cannot think of any scenario in which QMAXSIGN *NOMAX is OK. I stopped the review and insisted that they change this setting right then and there, but the reality is that with the plethora of overprivileged users, it's entirely possible that it will be changed back.
The Reality of Vulnerable IBM i Systems
I wish I could say this is the only time we've seen a system as vulnerable as this, but I would be lying. IBM i (AS400, iSeries, whatever you call it) has gone too long relying solely on a "security by obscurity" model.
How do you move the needle on a system like this? One change at a time. It may seem overwhelming, but Forta is here to partner with you to help strengthen your IBM i security. Run a Security Scan, talk with one of our IBM i security experts and start moving toward a “security by design” model.
For those looking for ongoing security support, our SecureCare for IBM i service can help identify and monitor critical security configurations on your system and report on items that demand attention. Regular reports are securely sent to Fortra’s team of true IBM i cybersecurity experts for analysis.
This service takes the pressure off of you and your system administration staff while facilitating regular security attention.
