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.
RECENT POSTS
CATEGORIES
