By Rich Loeber
Ever since I started working in an environment where I needed a user profile and password (yes, there was a time when these were foreign concepts), I have always used a simple profile based on my first name. As I moved from System/34 to System/36 to AS/400 to iSeries to IBM i on PowerServer, I just kept that same simple profile name.
But .... no longer. I am now a firm believer that first name profiles are a very bad idea. There are several reasons for this change.
First, recent studies show that people are really bad about picking secure passwords. Current studies show that, unbelievably, the most commonly used password is "password"! Check this for a recent list of the most commonly used passwords.
Since people are so bad about choosing passwords, having a user profile that is easy to guess makes a scripted attack very possible. In a scripted attack, a hacker attempts to gain access to your system by trying a typical user profile in combination with the list of commonly used passwords. If your system has simple first name profiles, then it could be at risk. Even if the hacker does not gain access to your system, they could easily end up disabling a lot of your user profiles because of multiple logon failures.
There are two ways that a scripted attack is normally mounted. The most obvious is via FTP. In the scripted attack, a series of logon attempts is done using an automated FTP client. Common profiles are coupled with common passwords and repeatedly tried to see which combination works. When a match is found, the profile/password is reported back to the hacker so they can explore further at their leisure.
On our IBM i test box, FTP scripted attacks are all stopped before they get to the point where a logon is run. This is because we use our SafeNet/i exit point security software that only lets FTP connections in from known and trusted IP addresses. We collect the profiles used, however, so we can report to you on the most commonly used profiles that we are seeing. From these FTP attempts, the most common user profiles used are:
Since we are protected by SafeNet/i, we were not too worried about the few common user profiles we had until a recent attack resulted in two profiles being disabled. We quickly turned to our exit point log, but there was no record of the activity. We also checked the system log (DSPLOG) but nothing reported there shed any light on why the profiles, including my trusted personal profile, got shut down. As a last attempt to discover what happened, we turned to the system security audit journal. What we found there was an eye opener.
We run the POP server on our IBM i. We use it, in combination with the SMTP server, for sending outbound email from the system with our WebReport/i software. This lets us send email without depending on any other office servers. What we discovered from the system audit journal was that another form of scripted attack was taking place under the covers on the system with no knowledge on our part. A little research revealed that we were being subjected to what is known as a "Brute Force POP3 Attack". It is like an FTP scripted attack, but broader in scope.
An analysis of the T-PW records recorded in the security audit journal showed that over a one month period, more than 20,000 attempts had been made to log into POP3 accounts. Fortunately for us, we were protected by quite a few other best practices for IBM i security, not the least of which is that we do not use the POP server on our IBM i for inbound mail, so none of the mailboxes actually exist. That, however, does not stop the hacker from trying. And, since people tend to use the same password in all places, a user profile/password combination found at the POP server level could easily be tried to gain access to the system by other means. From our analysis of these break-in attempts via the POP server, the most common user profiles are:
By looking at these, it is clear that the hacker or hackers are not aware of the type of system that they are trying to access. None of these profiles are commonly used on the IBM i platform. But, you can see some profiles that might easily be in existence on a normal system deployment which gives cause for concern.
What can you do?
Here are some simple ideas in brief:
If you have any questions about this, or you need help with implementing any of these recommendations, feel free to contact me by email at rich @ kisco.com. All email inquiries will be answered.