Watch Out For FTP "Script Kids"

By Rich Loeber

Some time ago, I wrote about the dangers of having an open FTP server running on your IBM i. At that time, I advised that FTP was a clear point of potential entry into your system by persons with malicious intentions.

Since then, I've been observing repeated attack attempts on my personal IBM i in my office and I've identified a particular type of attack that has me worried. It is what is called a "Script Kid" attack. It is called this because the attack is mounted using an FTP script so it can be repeated over and over again on any target. The word "Kid" is used because it is so easy, even a child could mount the attack.

Typically, a "Script Kid" attack will repeatedly attempt to log on to your system using a well known profile name. Fortunately for IBM i security officers, the most common profiles used by the Kids are ADMIN and ADMINISTRATOR which are very popular profiles in the Unix world. Good news for us as these attacks will generally get nowhere on the IBM i.

However, not all Kids stick with this basic attack form. One that worries me a lot happened a few weeks ago and is the event that prompts this writing today.

This Script Kid started signon attempts through FTP using common first names. Each name made 3 signon attempts, each using a different password. I'm sure the script called for commonly used passwords such as "password", "security" or the same value as the user profile. Scanning through the log of rejects for this attempt, I see a very comprehensive list of first names used such as ABBY, ABIGAIL, ABRAHAM, ABUSE, ACCOUNTS, ADAM, ADRIAN, ALAN, ALBERT and so on.

On the surface, this attack pattern seems like it would fail miserably as long as you have good password policies in place. And, as far as preventing access to your system, this is a true statement. However, this kind of attack could have a devastating impact on your system by cycling through commonly used profiles and causing them to be disabled by the operating system. Most IBM i shops allow for three logon retries when an incorrect password is entered. After the third attempt, the profile is disabled and can only be reactivated by a security officer. You could easily find yourself suddenly inundated with requests to reactivate disabled accounts all over your shop, bringing work on your system to a halt. (For password resets, our iResetMe software can help.)

So, how can you defend against this type of attack? For me, on my small test machine, I just shut down the FTP server when I saw the attack start up. But that is not an easy option for most of you. In my shop, I intentionally set up a phony profile on the system with the user profile of "ADMIN". I set it up to disable on the first bad password attempt and I designed the profile in such a way that it could not be used to gain access regardless of whether it resulted in a successful logon or not. Then, I had our system monitoring software watch for messages in the QSYSMSG message queue. When I am texted that the ADMIN profile has been disabled, then I know that an attack is under way.

The best solution is to have profile names that are uncommon. Don't use first names for your profiles. A good solution is to pick profile names based on a combination of first and last name. For those accounts that come with your system from IBM, the infamous Q profiles, make sure that none of them are used for regular production purposes. You should keep these profiles on your system in a disabled state. Sooner or later, a Script Kid is going to get around to putting QSYSOPR, QUSER and QSECOFR in their list of profile names to try. You should also keep a backup security officer profile available in case QSECOFR gets disabled. Finally, and I've said this many times before, never allow a profile to be created on your system using the default password.

If you have any questions about this topic you can reach me at rich at kisco.com, All email messages will be answered as quickly as possible.