Hacking Report For Our IBM i – A Current Update

By Rich Loeber

In 2013, we issued quarterly reports about attempts at hacking our IBM i system.  At the outset of that series, we explained that Kisco keeps a lone IBM i server connected directly to the Internet in order to test it’s SafeNet/i exit point security software in a real world environment. This article will update the information from that study and review the current state of observed intrusion attempts from more recent activity.  The landscape of what we are seeing in the way hacks are being attempted has changed quite a bit since our last report.

The biggest shift that we have observed is a significant fall off in hacks attempting to gain access using brute force FTP attacks.  However, the overall access attempts have increased from an average of 14 times as day in 2013 to nearly 50 times a day now.  Even after a recent change in IP address for our server, the hackers found the new location almost right away.

Thanks to our SafeNet/i exit point network control software, we successfully thwarted all unauthorized accesses.  Of these, 351 were attempts to gain access via FTP and another 6,009 attempts were to get a Telnet signon session during the analysis period that went from October 2016 through early February 2017.   The big change here is that hackers seem to have given up on FTP Script attacks in favor of just pounding away at the Telnet port.

For the FTP attacks, the profiles named ADMINSTRA and ADMIN were the most popular ones used.  This was true for the 2013 study as well.  Other profile names used included ANONYMOUS, FTP, and WWW-DATA.  Once again, these users were consistent with profiles tried in the 2013 study.

Our SafeNet/i Telnet exit point stops access before a signon screen is presented, so all we have to look at for the 6,009 Telnet attempts that were thwarted is the source IP address that was used.  We continue to see certain IP addresses with repeated access attempts.  The leading violator for this study period traced back to the Asia Pacific Network Information Center in Australia.  This hacker attempted to open a Telnet session more than 1500 times over a 2 hour period.

Some good news from the study, which we also observed in 2013, is that most hackers have no idea that our server is running IBM i OS.  No attempts were observed to connect to the system using connection points other than FTP and Telnet.  It may be that this is because hackers have so much success using FTP or Telnet, but it indicates that a lot of other avenues of access are not being employed, at least in our experience.

For the full study period, our server posted close to 300 thousand network transactions.  This is nothing in today’s computing environment, some of our customer’s servers can record that level of activity in just a few minutes.  But, 2.1% of those network access attempts were not authorized by us.  This is up from 0.5% for our 2013 study.  That is a four fold increase!  You have to take hackers seriously.  Failure to do so will get you in the headlines as the next Yahoo.

If you have questions about details of the report, feel free to contact me directly by email (rich at kisco.com).

Reporting A Break In – My Experience

By Rich Loeber

If you are a regular reader of this IBM i security blog, you’ll know that my company sells and supports an exit point solution for the IBM i called SafeNet/i.  To provide a constant testing environment for this software and to be able to say that it protects your system effectively, we have a test server sitting directly on the Internet and not hiding behind a firewall.

For the year 2013, we issued quarterly reports here about the results we were seeing of hacking attempts into our server.  You can read about that here.   We concluded those reports at the start of 2014, but we continue to monitor results of break in attempts on the server.

Recently, we identified a new phenomenon where a hacker (or hackers) are attempting to break into our system using Telnet.  The pattern is always the same.  Exactly twenty seven attempts are made to open a Telnet session on the server.  The attack lasts for 2-3 minutes and then stops.

Once we identified the attack pattern, we started researching what was going on.  For each attempt, our software captured the source IP address being used.  We then did a reverse lookup to see where it was coming from.  There are a lot of “Who Is” services available on the web and we just picked on that we were familiar with and had used before.  Before diving into a specific service, it is a good idea to test it by checking some IP addresses that you know and see if you get the right results returned to you.

What we found was a bit of a surprise.  I expected these repeating attacks to be coming from a single source because they were all so alike.  What I found was that they were coming from all over the place.  A lot of the IP addresses traced back to RIPE in The Netherlands.  Another significant group traced back to the APNIC in Brisbane, Australia.  Still others traced back to domestic ISPs like Time Warner and Comcast.  Obviously, this was not a single individual.  Since the attacks are being mounted from all over the globe, it is logical to conclude that multiple individuals are using the exact same method for probing possible targets.  The attacks are probably being mounted by software resources repeating 27 identical Telnet logon processes to try and identify a server that responds with access results.

After this kept up for a month, I was concerned that while our system was protecting itself, there might be many others that are not as well protected and maybe someone should know about this activity …. and maybe put a stop to it.  I thought about starting with our local, small town police department, but thought better of it and called the New York State Police.  I gave the desk sergeant who answered the phone a brief description of what was going on, including the fact that our system was successfully defending itself and that the attackers had not even gotten to the point of getting a sign on screen displayed.  He took my name and contact information and then after putting me on hold for a minute, came back and referred me to our local small town police department.  Sigh.

A few minutes later, I got a phone call from the desk sergeant at the local police station.  I gave him a description of what was going on.  He knew a little about Internet fraud schemes, but I got the idea that he decidedly did not really know what I was talking about.  When I told him that our system had not been compromised yet, he said that since no crime had really been committed, there was not much he could do.  If I insisted on making a formal report, he could start an intrusive process that would require me to turn over my server to them for a security audit that could take month.  That is not an option for us.

Not willing to give up just yet, I started to see what other options might be open to me.  I tracked down the FBI Cyber Crime website at http://www.fbi.gov/about-us/investigate/cyber.  They provide some good descriptive information and reference you to the “Internet Crime Complaint Center”, also known as IC3.  IC3 gives you a place to report your incident in some detail, although it is clearly oriented towards consumer fraud issues.  I went ahead and submitted a report.  The site states that an analyst will review the report and decide what action to take.  As of this writing (about 2 weeks after initial submission), we have received an automatic confirmation that our submission was received, but nothing further.

Since submitting our report, the attacks have kept up on a daily basis.  We are logging a minimum of 5 attacks a day and on some days it has gone as high as 12 attacks.

I promise to continue to report on the process as things happen.

The response that nothing can be done because no crime has been committed does not ring true for me.  If I had called in a complaint about a stranger knocking on the front door of my house over and over again, I’m sure I would have gotten the response that I was looking for, but such was not the case for my cybercrime report.

The lesson you can take away from this is that you absolutely must have exit point controls in place on your IBM i server in order to provide adequate protection.  You must protect yourself from malicious incursions, law enforcement is not going to be able to help much, if at all.

Stay tuned!

If you have any questions about this topic, you can reach me at rich at kisco.com, I’ll give it my best shot.  All email messages will be answered.

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 (we use our own SNDWEET for this), 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.

Hacking Report For Our IBM i – 2013 in Review

By Rich Loeber

In January of 2013 year, we issued our first Hacking Report for our IBM i system.  At that time, I promised to publish additional reports of what we are seeing on this test server.  This is our final report for the 2013 and I want to wrap of this one year experiment with our fourth quarter results and some observations about the entire year.

During the final three month period for 2013 we observed a hacking results that were remarkably consistent with the three previous quarters.  The bulk of hacking attempts mounted against our test server were once again in the area of FTP Signon and Telnet Signon.

Once again, someone knocked on the door of our test server 14 times a day trying to gain access.  This attack rate was remarkably consistent for the entire year.

Some interesting things to note ….

Thanks to our SafeNet/i exit point control software, we successfully thwarted 847 attempts to gain access via FTP and another 428 attempts to get a Telnet signon session during the final quarter of the year.   For the year, we was almost 4000 FTP hack attempts and just under 2000 Telnet tries.  The take home lesson is that you absolutely must take life on the Internet seriously.  Our server is small potatoes and does not have any high value assets on it, but hackers are there knocking at the door on a regular basis anyway.  I think it is just because it is there and they have been unsuccessful.

Brute force FTP attacks continued during the final quarter.  Once again, the profile named ADMINSTRA was the most popular one used.  In fact, this was true for each quarter during the year.  Other profile names used included ADMIN, REMOTE, SCANNER, SYS, BACKUPEXEC and WWW-DATA.  Once again, and this was consistent during the whole year, none of the typical Q profiles were attempted.

We also continue to see certain IP addresses with repeated access attempts.  The leading violator for the final quarter traced back to The RIPE network in The Netherlands.  The next two highest both traced back to the Asia Pacific Network Information Center in Australia.

For the full year, our server posted close to 1 million network transactions.  This is nothing in today’s computing environment, some of our customer’s servers can record that level of activity in just a few minutes.  But, taken as a whole for the year, 0.5% of those network access attempts were not authorized by us.  Hackers, you have to take them seriously.  Failure to do so will get you in the headlines as the next Target.

This will conclude our year of tracking hacker activity on our server.  If you have questions about details of the report, feel free to contact me directly by email (rich at kisco.com).

Hacking Report For Our IBM i – 3rd Qtr 2013

By Rich Loeber

In January of this year, Kisco Information Systems issued our first Hacking Report for our IBM i system.  At that time, I promised to publish additional reports of what we are seeing on this test server.  This is our report for the third quarter of 2013 and represents activity observed from July 1st through the end of September.

During this three month period, we observed a slight decrease in the volume of network transactions on our system, less than 1% in total.  At the same time, we saw a drop in the number of illegal access attempts that were rejected by our SafeNet/i software.  From 1,417 rejections last quarter, we saw an 8.4% decrease down to 1,209.  This represents an average of 14 unauthorized access attempts every day, down from 16 last quarter.

Life on the Internet continues to be unsafe.  Having someone knock on the door of my primary server 14 times a day trying to get in is not my idea of fun.  But this is what passes for “normal” in today’s internetworked world.

Some interesting things to note ….

On our server, the unauthorized access attempts continue to fall into two categories.  The miscreants attempt to access the system by FTP and Telnet.

SafeNet/i on our FTP Server on the IBM i OS rejected 792 access attempts which represents a decrease from last quarter.  During this time, the number of legitimate FTP access attempts was 746, so the unauthorized attempts exceeded the legitimate attempts.  We serve client requirements and software development needs using FTP, so we have to keep the FTP server active.  This is a clear warning message, however, that if you are keeping the FTP server active on your system, you really need to have access controls in place like those provided by SafeNet/i.

During this quarter, however, we saw that brute force FTP attacks using a large number of different common user profiles disappeared.  In its place, we are seeing repeated attempts to gain access using very common user profiles but cycling through multiple passwords on each attempt.  Using this method, the most popular user profiles used were ADMINISTRA, MYSQL, APACHE, TEST, TEST1, TEST12, TEST123 and WWW-DATA.  All of these profiles are common in the Unix world, so it appears that the IBM i platform is still not well recognized.

For unauthorized Telnet access attempts, we saw an increase in activity, nearly doubling, back to the level we observed during our first quarter report.  The access attempts via Telnet tend to come in single attempts or at the most, two or three successive attempts.  SafeNet/i captures these before an actual signon screen is presented, so they never get to the feature in IBM’s i OS that forces a profile to go inactive.  (The same is true for the way we are intercepting unauthorized FTP attempts.)

We also continue to see certain IP addresses with repeated access attempts.  The leading violator for this quarter traced back to Bright House Networks in Florida.  The next three highest all traced back to the Asia Pacific Network Information Center in Australia.

Another trend that we note that is disturbing is that for the 92 days covered by our study, there were only 5 days with no malicious activity.  That means that almost every day our server sits out there, someone is trying their hand at gaining access illegally.

We will continue to review our server’s status on a quarterly basis and report the results on our blog space.  If you have questions about details of the report, feel free to contact me directly by email (rich at kisco.com).

Hacking Report For Our IBM i – 2nd Qtr 2013

By Rich Loeber

In January 2013, we at Kisco Information Systems issued our first Hacking Report for our IBM i system.  At that time, I promised to publish additional reports of what we are seeing on this test server.  This is our report for the second quarter of 2013 and represents activity observed from April 1st through the end of June.

During this three month period, we observed a slight increase in the volume of network transactions on our system, about a 13% increase.  At the same time, we saw a drop in the number of illegal access attempts that were rejected by our SafeNet/i software.  From 1,603 rejections last quarter, we saw an 11.6% decrease down to 1,417, or nearly 16 unauthorized access attempts every day, down from 18 last quarter.

This all goes to prove that life on the Internet continues to be unsafe.  If someone tried to break into my home 16 times a day, I’d be worried.  But this is what passes for “normal” in today’s networked world.

Some interesting things to note ….

On our server, the unauthorized access attempts still all fall into two categories.  The miscreants attempt to access the system by FTP and Telnet.

SafeNet/i on our FTP Server on the IBM i OS rejected 1,117 access attempts which represents a small increase from last quarter.  During this time, the number of legitimate FTP access attempts was 694, so the unauthorized attempts exceeded the legitimate attempts.  We serve client requirements and software development needs using FTP, so we have to keep the FTP server active.  This is a clear warning message, however, that if you are keeping the FTP server active on your system, you really need to have access controls in place like those provided by SafeNet/i.

We also took a look a the most popular user profiles being used to attempt access to our system via FTP.  Like last quarter, the leading profile is still ADMINSTRA with 157 attempts.  The next most popular profiles used were USER, ADMIN, BACKUP and DATA.  For these profiles, the pattern we continue to see the pattern of multiple access attempts from the same source using a different password each time.  This lends credence to the need to use less common profile names coupled with complex passwords.

For unauthorized Telnet access attempts, we saw a decrease in activity by about half.  The access attempts via Telnet tend to come in single attempts or at the most, two or three successive attempts.  SafeNet/i captures these before an actual signon screen is presented, so they never get to the feature in IBM’s i OS that forces a profile to go inactive.  (The same is true for the way we are intercepting unauthorized FTP attempts.)

We also continue to see certain IP addresses with repeated access attempts.  Interestingly, the leading violator for this quarter traced back to MicroSoft in Redmond, Washington.  The next three highest all traced back to the Asia Pacific Network Information Center in Australia.

When we went public with our IBM i server hacking results at the start of this year, there was some concern expressed that we might be challenging hackers to break into our test server.  We are happy to report that the challenge was apparently not taken up with the second quarter results being consistent with what we saw for the first quarter.

One other thing to note is that unauthorized access attempts are, in fact, limited to FTP and Telnet.  In a way, this is good news.  There are a lot of other doors and windows in the IBM i platform, but nobody is trying to use them.  All of the unauthorized access attempts that we have observed for the six months that we have been watching have been limited to just these two access points.

We will continue to review our server’s status on a quarterly basis and report the results on our blog space.  If you have questions about details of the report, feel free to contact me directly by email (rich at kisco.com).

The Case For Better User Profile Names

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:

ADMINISTRA
ADMIN
TEST
ALAN
ALBERTO
ALEX
AMANDA
ANGELA
ANNA
ANONYMOUS

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:

ADMIN
INFO
DATA
TEST
ROOT
MARK
SERVER
MAIL
MARY
SUPPORT
ORACLE
GUEST
DANIEL
GEORGE
ALEX

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:

  • Don’t keep the POP server active on your system if you don’t need it.
  • Don’t keep the FTP server active on your system if you don’t need it.  If you do need it, only have it active during hours when you expect it will be used and shut it down during other times.
  • Implement enforced password rotation if it is not already active.
  • Implement the user profile password rules to always require a numeric digit as a component of the password.
  • Review the active profiles on your system for simple first names and get them changed.
  • Check the common profiles used on most IBM i systems and make absolutely certain that their passwords are complex and hard or impossible to guess.
  • Implement exit point controls, check out our SafeNet/i product.
  • Consider disallowing vowels in your passwords.  IBM i system value password controls will let you do this.  At a minimum, rule our the letters E and A.
  • Check your system security audit journal regularly for T-PW records to see if you are getting unexpected password denials.

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.

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).