Hacking Report For Our IBM i – 1st Qtr 2013

By Rich Loeber

For years, Kisco Information Systems has kept a lone test IBM i server hanging out directly on the Internet.  No firewall, no security appliances, just a direct connection with a dedicated IP address.

Not a very good idea you say?  Well, Kisco sells a network security software solution called SafeNet/i and what better environment to test and prove that the software works.  Using a combination of the best IBM i OS security practices along with a full implementation of SafeNet/i, Kisco is happy to report that their server has never been hacked successfully ever since this test server was first placed on the web more than 15 years ago.

That’s a good record!

But, that is not the purpose of this report.

To help IBM i shops understand the reality of network threats, we are now reporting some results of what we see on this test box.  We hope that it will help IBM i users to better prepare for the very real threats that exist.

This report shows what we’ve seen on our server during the first three months of 2013.

During this time, our test box reported 211,346 network transactions that passed through the various exit points registered to SafeNet/i.  Out of this total, 1,603 (0.75%) were identified as illegal access attempts and were denied.  That represents about 18 times each day when someone tried to gain access to our system, but was not authorized for that network activity.

Of these 1,603 access denials, all of them fell into just two categories during this test period.  FTP access connections accounted for 1,025 and the other 593 are Telnet connection attempts.  All of these connection attempts were refused by SafeNet/i before the requests even reached IBM’s OS.

A further look at these access denials shows that 1,015 of them came from user profiles that do not exist on the server.  The most popular profile, by far, was “ADMINSTRA” which accounted for 700 failed attempts.  The next most popular was “ALAN” with 37 followed by “TEST”, “ADMIN” and “ALBERTO”.  All of these were FTP connection attempts.  These all appear to be FTP script connection attempts, probably cycling through a series of popular password combinations.  It argues strongly for user profiles on the IBM i that are not based on people’s first names or job functions.

Looking at the access denials from a different perspective, we see that all 1,603 during this test period were denied access because they originated from IP addresses not recognized by SafeNet/i.  For FTP and Telnet connection, SafeNet/i only allows a connection to be established when the IP address is recognized.  By carefully maintaining the table of legitimate connectors to the system, illegal connection attempts are controlled.

Of these illegal connection attempts, 49 source addresses tried to connect multiple times.  The most persistent tried to connect 367 times in succession, all of which were denied.  There were others from different source IP addresses who attempted to connect 271 times, 195 times and 118 times.  Some only tried twice.

Are these illegal connection attempts really something to be concerned about?  To check this, we did a reverse lookup on the most common IP addresses that were denied.  Two of the addresses checked back to an ISP in Brisbane, Australia.  Two others were tied to ISPs in Scranton, PA and Galloway, NJ neither of which are associated with any known developers that we normally work with on this server.  The obvious conclusion was that these access attempts were malevolent which is all the more troubling since the IP address of our server is not generally known to the public.

During this study period, 18 valid source IP addresses connected over and over again to get their legitimate network work completed.

For those attempting Telnet connections, the pattern is a little different.  Within the IBM i OS, all of these failed attempts are logged under the common user profile of QSYS.  Telnet attempts, however, do not follow the brute force attempts that FTP users try.  They tend to be solo connection attempts or just two in a row.

Kisco Information Systems will keep an eye on these connections attempts and will periodically issue updates on the results by quarter.  Feel free to check back to our IBM i Security Blog for future reports.  If you have questions about details of the report, feel free to contact me directly by email (rich at kisco.com).