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

Hiding Places for Malicious Code

By Rich Loeber

The last time I wrote, it was about tracking down hidden programs on your system that you might not know about (see article).  That time, it was trigger programs that could be sitting on your system just waiting for a specific event.  But, as I’ve thought about this issue since then, there are other places where someone could “hide” a call to a malicious program and easily get overlooked.

This time, we’ll look at two other areas for concern.  These are the system job scheduler and exit programs.  Both are ways that someone intent on doing harm to your system could hide some malicious program waiting for something to happen so it can jump out and cause problems.  In each case, the IBM i OS contains a way to review the programs that are sitting there and you should take a look periodically to see how each is being used on your system.

The IBM i OS has had a nice, easy to use job scheduler built into it for a long time now.  Most shops where I’ve done consulting work seem to know about it and use it for regularly scheduled jobs.  But, that also means that the programming staff is aware of it and could misuse or abuse it.

To review the current contents of the system job scheduler, use the i/OS command Work with Job Schedule Entries (WRKJOBSCDE).  This command will display information about every job in the system job scheduler.  It will tell you what the job is, how it is invoked and when it is next scheduled to run.  You should review each entry to make sure that you know what it is doing and when it is next scheduled to run.  A suspicious job, to me, would be one that is not set to run for quite a while in the future.  Most scheduled jobs happen frequently, either on a daily, weekly or monthly basis.  If you see something on a different schedule than one of these, I’d pay particular attention.

Another place you need to periodically review are the registered exit point programs on your system.  Exit points are hooks into i/OS processes.  These are provided in the i/OS so customers can add their own customized processing called from the OS during normal operations.  For example, many of the third party network security products now available on the market (including our own SafeNet/i) use exit points to add security checking to the various network operations in i/OS.  The potential problem is that a rogue program could get registered to an exit point just waiting for a specific OS event to occur before it jumps up and gets noticed.

To review exit programs registered on your system, use the i/OS command Work with Registration Information (WRKREGINF).  This will display a list of the i/OS exit points on your system, and remember that they are different for every level of the OS.  For each exit point, use the option ‘8′ to see if there is a registered exit program for the exit point.  If you find any, make sure that you know what they are there for.  Don’t be surprised to find some exit programs already registered.  If you are using a network security system, you should find many programs registered.  Also, some come registered with i/OS.  For example, you will find that the IBM product Service Director, uses some of the exit points as does the i/OS Mail Server Framework (MSF).  Just make sure that you can identify each program that shows up as a result of your review.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

The Enemy Within

By Rich Loeber

For many, this has been a hard year.  In many IBM i shops, we have been forced to find new ways to save on expense while still being asked to provide the same level of computing support as in past years.  This is not always easy, and I have seen evidence that some shops are sacrificing security to conserve on their budgets.

One significant area where I’ve seen this is on data asset protection.  More than one shop that I’ve been in touch with this year has decided to put their complete trust for data asset protection into their firewall at the expense of all other ways of protecting their data.

With your system attached to a network on a full time basis, and with the network interconnected to the Internet on an around the clock basis, trusting your data protection to a single piece of technology is just a bad idea.  Imagine yourself living in a neighborhood with a high crime rate.  Would you have a single lock on your door?  Like most people in this situation, wouldn’t you use two or three (or even more) methods to keep your doors and windows secured?

When your system is connected to the Internet, you are in a high crime neighborhood and you need to use the same approach to protecting your data.  When someone breaches your single point of protection, that could leave your entire system open to malicious abuse.

Also, trusting your data protection to just a firewall completely ignores the issues of intrusion from sources within the “protected” network.  In a small shop, where you can see who is in and who is doing what, maybe this is not much of a concern, but in today’s large shops with widespread deployment of networks, you cannot keep an eye on what everyone is doing.  Anyone who is within the “secure” network can find access to your system using a variety of tools available to today’s savvy computer users.

If you have deployed your firewall as your primary defense against intrusion, you are completely ignoring the enemy from within your organization.  Most security experts will tell you that at least half of all intrusions today (some say more) come from within your organization.  With the ease of downloading data and storing it in a convenient portable form, anyone in your organization could easily take home critical data assets from your organization on a laptop or even on a USB drive that looks like a key fob.

The question you need to ask yourself is, am I saving money wisely or am I thinking short term just to look good.  In today’s environment, you simply cannot put all of your eggs in one basket.  To adequately protect your system, you need to present multiple hurdles for your enemies to overcome.  If they get past one, there is a good chance that the next one they encounter will defeat them.

The good news is that your IBM i comes with a lot of tools available to you so you can build these additional lockouts.  To protect yourself from the enemy within, you will need to build strong object level access controls.  You will need to rigorously enforce a policy of no user profiles with *ALLOBJ authority.  You will need to also enforce a policy of password rotation on a frequent basis with password controls that prevent the reuse of passwords and the use of passwords that are easy to guess.  Lastly, the strong lock of exit point controls will also help keep your data safe.

All of these options, and more, are open to you.  Some may cost you some money, but the alternative of seeing your organization on the front page of the paper for data theft would be much more expensive in the long run.

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.

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.

Configuring Telnet for SSL

By Rich Loeber

I was recently asked to secure remote access for 5250 terminal sessions for one of my customers.  I did not have any experience securing Telnet on the IBM i, but I located some good documentation from IBM and was able to get the Telnet connection secured fairly quickly and easily.  This tip will show you how.

Many IBM i shops still use the 5250 terminal interface for administration and operation of their systems.  For them, the interface is well known and comfortable.  The problem is that when used for remote access, the Telnet data stream is passed as open text and it is easy for someone with malicious intent to snoop in on the data stream and capture user profile and password information.

Fortunately, there is a way on the IBM i to encrypt your 5250 terminal sessions by implementing SSL (Secure Sockets Layer) for your Telnet connections.  The IBM i uses a Telnet connection to support your 5250 terminal sessions.

There are two steps that you need to complete in order to set up SSL for Telnet.  Part one involves configuration work on your IBM i server.  Part two is what is needed on your client (your PC) in order to use the SSL connection.

The server configuration will require that you have option #34 (Digital Certificate Manager or DCM) of the base OS installed along with the HTTP server functions.  On our 6.1 test box, the HTTP Server is 5761DG1.  Before plunging into the project, I strongly recommend that you make sure that you have the latest HTTP server PTFs installed.  When we first tried to use DCM after upgrading our OS, it would not work and we needed the PTFs.

To do the configuration work on your host, we found the following article with step by step instructions from IBM and I recommend that you use this procedure:

http://www-01.ibm.com/support/docview.wss?uid=nas8N1010449

This process will require you to set up a self-issued digital certificate on your system and then assign it to several applications, including Telnet.  If you have never used the Digital Certificate Manager on your system, be prepared to take some time to get used to it.  The instructions from IBM are actually quite good.

After you get this configuration work done, make sure that you update the Telnet Attributes on your system using the CHGTELNA (Change Telnet Attributes) command.  When starting, make sure that the Allow Secure Socket Layer (ALWSSL) parameter is set to *YES.  This will allow both SSL and non-SSL Telnet connections.  Once you are satisfied with the way the SSL connection is working, you can consider changing this setting to *ONLY which will then refuse non-SSL connection attempts.

Once the server configuration work is done, you can move on to the client configuration work.  Again, I found a good set of instructions from IBM on this that you can access here:

http://www-01.ibm.com/support/docview.wss?uid=nas8N1011018

This process may require that you install additional Client Access components on your PC, so access to your Client Access install CD may be required.  The process will call for your to import the certificate you created into your PC and then reconfigure your terminal session to use SSL.  When importing the certificate, there is a standard password to use.  That instruction is easily missed, so watch out for it.

In addition to setting this up for my customer, I also took the long delayed step of setting this up for my own server.  It is something I should have done long ago and I encourage all IBM i shops to adopt this standard for remote access Telnet session.

After initially posting this tip, a friend contacted me to suggest that implementing SSL on Telnet also helps customers with their PCI compliance requirements.  PCI requires 2 factor authentication.  He reported that one of his customers was able to meet this requirement using SSL.  The two factors involved are the password and the digital certificate.  Two factor authentication calls for something you know and something you have.  SSL for Telnet does just that.  (They also require use of VPN for any remote access.)

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.

Tracking Remote Access Users On Your IBM i

By Rich Loeber

In the IBM i world, it has always been possible to track access to the system by user profile.  It is just a simple matter of activating and configuring the system audit journal and sitting back to wait for some information to be accumulated.  Then, using the DSPJRN judiciously, you can get a list of who signed on to your system and when they did so.

This was all well and good when your normal method of system access was through a green screen terminal, either hard wired or using a terminal emulator like IBM i Access.  But, in this day of network connections through TCP/IP server functions in the OS, the model doesn’t work well.  Users can log into your system using FTP or IBM i Access with little or no trace left in your security journal that they were even there.

In certain cases, an audit journal record for “Process user profile swap” is left (a type PS record in the journal).  I have seen this happen on a logon from IBM i Access using the TCP Signon Server.  Apparently, after a successful logon, IBM i Access does a user profile swap to the QUSER profile and this gets logged in the journal.  So, you could scan the journal for PS records and get some information about which user profiles are establishing network connections using this method.

You can also see some indication about remote users connecting to your system using IBM i Access (and similar clients) from the System History Log.  If you run the DSPLOG command, you can scan for the CPIAD09 message.  You can do this using the following command form:

DSPLOG PERIOD((*AVAIL *BEGIN)) MSGID(CPIAD09)

This will show you some evidence of remote logon activity too.

But these are just a drop in the bucket compared to everything that can go on within your system “under the covers”.  For example, if someone attempts to sign on to your system via FTP using a user profile that doesn’t even exist on your system, you will never even know about it even though you are journaling all security events.  Since this is a popular method that hackers use to try and break into your system, it would be nice to know when such attempts are being made.

When IBM opened up the system to TCP/IP connectivity, their solution to this issue was, and still is, to provide exit points in the OS.  For each of these servers (such as FTP, Telnet, SQL, TCP Signon and many more), the OS lets you create your own program to monitor network activity and even control access to it.

The problem with this approach is that it is entirely passive.  The OS is shipped with no exit program in place and the fact that exit points even exist is still not widely known.  In the mean time, all sorts of nefarious system connection activity can be going on and you, as security officer would never know it.  My company sells an exit point solution for the IBM i called SafeNet/i and the most common comment that we get from new customers who are just starting to use our product is that they had no idea so much activity was going on via network server connections.

Another problem with this approach is that coding and maintaining your own exit point solution is a daunting task.  Over the life of these exit points (they’ve been around for more than a dozen years now), some of the exit point data streams have changed significantly.  To IBM’s credit, they have left the old data stream in place and created a new exit point for the enhanced version, but you have to re-code your application to take advantage of the improvements when they are made.

The best solution is for you to lay out some money and purchase a good exit point solution.  There are a lot to choose from in the System i marketplace today including our SafeNet/i.  The maintenance problem then becomes your software vendor’s headache, not yours.  And, most solutions cover all of the exit points available so that you’re fully protected.  These exit point solutions give you control over which user profiles can access your system, in many cases, what objects they can work with and what source IP addresses they can connect from.  And, all network activity can be logged so that you can finally see everything that is going on “under the covers”.

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.

Controlling Remote Access to your IBM i

By Rich Loeber

These days, there is almost nowhere you can go on the planet where it is technically difficult to establish and internet connection and get beyond your current location.  We’ve all experienced this, especially with demands made on us during vacation trips and other travel requirements.  It seems like we’re always expected to be on call and available to react to issues back in the office.

While this sounds intrusive of our time, there are other situations where it is a huge benefit.  It allows people who are spread out all over the world to easily collaborate on projects just like they are in adjoining rooms.  It also lets you telecommute from home or even telecommute from a home office that is a long way from your physical office.  This gives you new options in choosing where to live, and it doesn’t always have to be near where you’re working.  It is just this kind of global connectivity that lets me live in a remote location in the Adirondack Mountains of northern New York and still be able to reach out to any potential customers on a worldwide basis.

The thing that makes all this possible is the Internet and remote access technology.  But, as you think about it, while you have access remotely to off site computing resources, so does anyone else who is connected to the Internet.  That is a huge security exposure to your IBM System i.  Even the much touted security on this exceptional system will have exposures.

Certainly, there are loads of infrastructure solutions that you can turn to.  There are no end of VPN (Virtual Private Network) solutions that you can implement that will create tunnels through the Internet to authenticate a connection, limit access and encrypt your data.  There are also firewalls you can implement that will limit traffic connections to your system.

But, these are all external to your IBM i.  What can you do, on your system, to protect yourself.  You need to be able to permit external access from users with legitimate needs but keep all others from doing the same.  There are so many different methods to establish remote access that you have to have a plan for each of them.  From simple FTP to Telnet, ODBC connections, IBM i Access connections, remote command submissions, file uploads and downloads, windows share drive connections and on and on.  The list is long and each one represents an exposure.

IBM has provided a good solution for this issue for more than 15 years now, system exit points.  The OS on your IBM i services each of these remote access requests through something called a Server Function.  FTP works through an FTP Server, Telnet through a Telnet Server, ODBC on most systems works through an SQL Server and so on.  Within the OS, IBM has implemented exit points in each of these server functions.

An exit point is a place in the OS where you can register a user written program to add processing that is not included in the OS.  The exit point passes a data stream that varies depending on the exit point, and your program sets a return code for the exit point in the OS to interpret.  The return code is typically a pass/fail code that lets the exit in the OS know whether or not to continue processing the remote access request.  Your program then examines the information in the data stream to determine if you want to allow or disallow the remote request.

A typical exit point program application might attach, for example, to the FTP server logon exit point and check the remote IP address of the FTP requester.  You can then easily compare this to a list of legitimate addresses that you have set up and then disallow remote access from any IP address that is not on your list.  Continuing with the FTP example, you can also create an exit program application for the FTP server point and then check the data stream to see which objects the FTP session is attempting to access on your system.  Again, you can compare these to a list of objects that the requesting user is trying access and the either accept for deny the request based on what you find.  You can even authenticate the user signed on to make sure that you have authorized them to even use FTP.

A word of caution is due at this point.  Programming for the exit point data stream is not for the faint of heart.  The documentation on certain exit points can be sketchy and testing can be problematic as it can easily interfere with normal operations on your system.  Fortunately, there are quite a few third party solutions available on the market today that are very good.  All that testing and figuring out of the data streams is done for you by programmers who have been wrestling with the issues for years.  I obviously recommend my company’s SafeNet/i as the best of the third party solutions currently available.

To give your IBM i the extra measure of control over remote access via network connections, the best solution is implementation of the exit point controls in the OS.

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.

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

And More Tips for Securing FTP on your IBM i

By Rich Loeber

For the last few months, I’ve been writing about the security exposure from FTP server running on your IBM i box (Power System i/i5/iSeries/AS400).  I started by describing FTP as being the access weapon of choice by many hackers, especially those just starting out.  This was confirmed by our most recent Hacker Report.  Last time around, I talked about a couple of simple suggestions on how to get this situation under control.  Today, I’ll add a couple more tips into the mix to help keep a lid on safeguarding your system from an FTP intrusion.

First, there are lots of good reasons why you want to allow FTP access to your system.  It is an easy way to upload and download data to and from your system from remote locations.  You can also use it for program maintenance from one IBM i to another by moving save files between systems.  Many IBM i software vendors, including my company, distribute software updates using some form of an FTP connection to your system.  So, don’t be afraid of it, but use it wisely.  You can see my last two articles on FTP here and here.

One thing to keep in mind when thinking about FTP is that all the rules of OS security apply to someone connecting to your system.  In order to gain access, they must have a valid user profile and password.  Once they sign on, your current OS security plan will be in place.  So, having a good security implementation tied in to your established user profiles will go a long way towards keeping your data safe.  One additional fact to add into your mix is that in order for data to be accessible to FTP, it must have a minimum security setting of *USE.  If you have a user profile that is regularly using FTP and there are concerns about access, make sure that they do not have a minimum setting of *USE for any objects you do not want them working with.

A problem can easily come up, however, when a user profile is used in different contexts.  By this, I mean when a user has access to certain sensitive objects for their daily work flow that are accessed by program control.  But, that user is also an FTP user and logs in to do file transfers using FTP.  Having different contexts could create a security exposure.  When this user signs on using FTP, they will still have access to the sensitive data files that they are authorized for from their daily work flow.  If this situation exists, you need to address a way to deal with it.

One method, as discussed last time around, might be addressed by implementing controls through the FTP server exit point.  You might also think to issue a second user profile to the user for FTP use.  This solution is not great since the user can still, by choice, establish an FTP connection under their primary user profile and gain access to sensitive data that way.  Far and away, the best solution is through additional exit point controls.  This could be set up to disallow an FTP connection under certain known profiles, thereby forcing the user to make their FTP connection through a secondary profile that you provide.  If you don’t want to tackle implementing your own exit point programming, there are several products available on the market from IBM i developers, including SafeNet/i from my company.

The Sytem i OS also supports profile swapping, which could be another solution to this problem.  Using swapping, the user signs on with one profile, but then the OS swaps their profile to look and act like a different profile.  Information about this technique can be found at the IBM Information Center and has been a part of the OS since V4R5.

If you have any questions about this topic you can reach me at rich at kisco.com,  I’ll try to answer any questions you may have.  All email messages will be answered.

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