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,  All email messages will be answered as quickly as possible.

Learning To Be A Security Officer – Part 2

By Rich Loeber

In a recent post I started a description of how you can learn the job of being a security officer in the IBM i world of computing.  This post will continue that thought by talking about how you can effectively use a security consultant, and learn from them in the process.

In the first post I talked about the need to read and to stay current with technology.  In addition to what I mentioned in that post, I also want to recommend to you the book “Inside Internet Security: What Hackers Don’t Want You To Know” by Jeff Crume.  I found a used copy at  It is a real eye opener for those of you who have only been thinking about the IBM i side of the security question.  The book is a little dated, but still contains a lot of good information that is clearly presented without a lot of acronymic netspeak that can be so confusing.

But today I want to talk about using a consultant.  The classic definition of a consultant is “someone who borrows your watch to tell you what time it is”, and to a certain degree, this is true.  But a good consultant will explain to you every aspect of your situation.

The best way I know of to tell you about using a consultant is to describe a situation from my past.  I had been working for 20+ years as a programmer, systems analyst and IT manager when I started consulting for a local direct marketing company.  I was there for about 6 months trying to address the multitude of issues that this fast growing company was experiencing.  The owner decided to bring in an expert and found a guy for $2000 per day (plus expenses, a fortune at that time) to spend a day with us.  We cleared our slates, got several key people together and followed the expert around for the day as he walked through the entire operation.  What an eye opener that was.  In one day, we identified every issue that needed to be fixed, quite a long list.  We turned this into a roadmap of sorts and started knocking items off.  That one day visit ended up changing the entire course of the company for the next 10 years.  It was more than worth the investment.

A security consultant should be able to do this same thing for you.  But you need to use the consultant effectively.  This starts by selecting a qualified person.  Develop a list of people from reliable sources.  Then check references to make sure that you’re getting what you need.  Once this is done and a date has been set, make sure that you have everyone needed completely available.  When the consultant arrives, the clock will be ticking and if you’re off doing something else, it will be a waste of time and your company’s money.  Clear the decks completely.  Don’t even take phone calls or check your email or texts.

While the consultant is with you, be completely honest with them.  If you hide things because you’re embarrassed by them, then your feedback from the consultant will be incorrectly skewed.  Go through everything that you’re doing and take copious notes on what the consultant has to say.  You’ll be amazed, if your consultant is good, at what you find out and you will learn to do a better job in the process.

After the consultant leaves, don’t just go on with business as ususal.  Make a list of the areas that the consultant brought up that need attention.  Then, develop an action plan to get each item on the list addressed.  And, make sure you have the right attitude as you go through this exercise.  The objective is not for you to come out looking good (which is often the case when reacting to an audit), but to address security exposures and get them closed.  Most consultants appreciate followup, so don’t be afraid to get back in touch with the consultant with questions and clarifications after the initial consultation.

That day we spent with the consultant completely changed my understanding of how a direct mail company should operate and it has stayed with me.  Your investment in a security consultant will do the same for you and for your company.  Consultants are expensive, but the alternative of having security exposures, could not only be costly but devastating to your company.

If you have any questions about this topic you can reach me at rich at,  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

Learning To Be A Security Officer

By Rich Loeber

I have been asked several times recently “How did you learn so much about security on the IBM i?”.  In this tip, I will try to let you know how I got to this point and, perhaps, it will help you on your journey as well.

First, you have to remember that I have been working on computer systems since my first job as a data control clerk in 1965.  During that time, I’ve moved through just about every aspect of the computing field from data entry clerk, system operator, programmer, systems analyst, project manager, department manager, independent contractor and software developer.  All along the way, security issues have come up and had to be researched and dealt with.  So, I guess some longevity contributes to where I am today.  But, old age is not an option to a lot of aspiring security officers for today’s IBM i installations.

As I think back over this history, several concepts come to mind that have helped me strengthen my understanding of computer security.

First and foremost is reading.  I am, by nature, an avid reader.  Over the course of my career, I have found that reading is crucial to staying current on what’s going on in the field.  This is more true today than it has ever been since things are changing faster now than at any time that I can recall.

When choosing what to read, I’d recommend a holistic approach that includes general computing topics, IBM i specific topics and security topics.  In today’s world, this means reading magazines, Internet publications and technical manuals.

There are a few magazines that are still in print for the IBM i world, although it is hard to know how much longer that will last.  Almost all of their content, however, is available on-line at websites maintained by the publishers.  Some of these charge a fee for access, but the charges are not prohibitive and the content is generally well worth the price of admission.  These publications tend to focus on “what’s new” topics, but their archives are a good source of general information that you will find most helpful.

For security topics on your IBM i, there is nothing better than going to the source …. the security manuals that come with your system.  These are available on a CD that came with your system and also on-line from the “IBM i and System i Information Center” (  The current manuals for all supported versions of the operating system are there along with an extensive library on security topics.  You can’t find better details than looking at these documents from IBM as they tell you exactly how the designers intend for security to be implemented on your system.  I know, reading the manuals can be tedious, but they’re really not that bad.  When I’m writing a tip for publication, I often find myself mired in them to get the exact details of how something works, according to IBM.

Another good way to stay current on what’s going on in the IBM i security field is to participate in an on-line discussions forum.  For me, I like David Gibb’s “” (  You can sign up for quite a few different forums and then just sit back and monitor the traffic via email.  The group that participates is great at answering your questions and you can read what others are doing.  I’m amazed at how much I pick up just by monitoring the email traffic.

So, the first step in improving your understanding of security is reading.  One thing to remember is that reading takes time.  I have the luxury these days of being able to set my own schedule and I make time for reading a priority.  You will need to dedicate time during your busy week for this activity.  Failure to do so could leave you out of date.

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

Rescinding Access Rights

By Rich Loeber

Most of the time, as an IBM i security officer, you are concerned with granting access rights to users.  To do this, you need to know what the user’s job responsibilities are and what they will be doing within the computing environment.  Based on existing security policies for your shop, you then configure security for each user so that they can get at the computing resources they need to do their job easily, smoothly and securely.

Once you have a user set up and running, however, I think they seem to fall off our radar since we’re then occupied with getting the next user(s) setup and configured.  You tend to address those areas where you have immediate demands at the expense of others.

One important thing to keep track of, however, are situations where access rights need to be modified or rescinded.  The most glaring situation is when someone leaves the company.  You should have a clearly developed plan of action to implement when someone leaves.  This plan should include:

  • Deactivating their user profile
  • Identifying any objects owned by their profile and reassigning them
  • Removing access rights for objects not owned by them
  • Deleting the user profile after all else is done

Just deactivating a profile is not sufficient.  Batch jobs can still be run under an inactive user profile and those jobs will still have rights to the object set that was defined for that user.  So, you must take the additional action of removing those access rights.  Rescinding access rights is just as important to a secure installation as granting those rights.

Chances are, your IBM i is currently sitting with loads of unnecessary access rights in place for people who are long gone.  Each one of those access rights is a potential security exposure and should be dealt with.  You should review the way the user was initially configured when their access rights were granted and then go through and reverse the process.

Making this work depends you being in the loop when someone leaves the company.  In a small shop, you normally learn this by word of mouth.  But, in any size shop, a formal notification process needs to be put in place to guarantee that inactive profiles are dealt with promptly.  This can be especially important if someone leaves on bad terms.  A firm procedure has to be in place with your HR staff and it must be enforced.

The other situation you need to be prepared for is when someone has a change in job responsibilities.  In this situation, you will not only need to grant new access rights for the user, but you will also have to backtrack and possibly remove some earlier rights that have already been granted.  Again, careful coordination must be worked out with your HR folks.  You are more likely to hear about this through less formal channels since the user will need to get reconfigured in order to start their new responsibilities.

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

Do You Believe Security Is An Issue?

By Rich Loeber

I am amazed at how many companies and organizations I run into where computer security is lax and nobody seems to care very much.  Recently I heard from a business associate who is just getting started in a new position.  He told me that his company’s IBM i is connected directly to the Internet with no protection at all, not even a firewall or even a router.  He demonstrated to his new boss how he could quickly hack into the system, track down the ID and password of a security officer and then sign on using that profile.  I won’t tell you how he did this, but it was not rocket science.  They are shopping for security protection for their IBM i now, but how did they get to this point to begin with?

What these organizations need is a Security Evangelist.  Someone who knows what the problem is and really believes in the message.  The dictionary contains several definitions of “evangelist” and the one I’m thinking of is “a person marked by evangelical enthusiasm for or support of any cause.”.  If you don’t believe the message, then you can’t sell it to your organization’s decision makers.

I then thought back over my almost 50 year career to try and pinpoint those places where I bought into the computer security message.  I can think of three events that really got me convinced that this is a legitimate issue.

When I started in the computing field in 1965, computers were new and companies that had them liked to show them off.  It was not unusual to have a glass enclosed computer room with open access to the public to walk by and watch the computer in operation.  Then, there was a Viet Nam war protest bombing of one of these computer centers and, overnight, they got boarded up and physically secured.  Companies realized that they were dependent on the computers for many operations and the public display put them at risk.

At around this same time, in 1973, along came the Equity Funding fraud.  This was a computerized fraud scheme where a financial conglomerate engaged in fraud on a huge scale to maintain a high stock price and fool Wall Street and investors.  At its height, the scandal involved as many as 100 employees who used their computer system to create fictitious insurance policies.  At one point during the fraud, someone estimated that if the insurance policies being written continued at the same growth rate, they would end up writing more policies than there were people in the US.  It was dramatized in the made for TV movie, “The Billion Dollar Bubble” staring James Woods and Sam Wanamaker.  I could not find the movie available on NetFlix or at Amazon, but if you can see this movie, it is very convincing.

These two events, which happened quite close to each other, got me thinking that the computer security issue was a real issue and not just something being touted by IBM to sell more of their services.

The last event that turned me into a security evangelist was reading the book “The Cuckoo’s Egg: Tracking a Spy Through the Maze of Computer Espionage” by Clifford Stoll.  This book, published in 1990, starts with a college IT guy from Berkeley trying to track down a 75 cent billing error.  His search leads him into the then new world of computer hackers on a global basis.  This book is still available from and if you’ve never read it, you should.

If you don’t believe in the computer security message, then you can’t convince others.  I became convinced by just keeping my eyes and ears open to what was going on around me.  If you’re working in the computer security field, you need to be an evangelist and get everyone at your organization on board.  If you don’t believe the message, how can you expect the rest to?  I think this is what’s needed today.  There is still just too much laxness in the field.

If you have security was stories you’d like to share, you can reach me at rich at  All email messages will be answered and I might even use some of your stories in future posts.

Restricting Use Of Certain System Commands

By Rich Loeber

When your IBM i is prepared in the factory, it is set so that most system commands and APIs have a public authority of *USE.  This setting will let anyone use just about any command or API on your system.  But, some of those commands and APIs could be used for malicious purposes.  This tip will show you a way that IBM has provided in the operating system to easily restrict those commands and APIs that can be most problematic.

The secret to this is the Revoke Public Authority (RVKPUBAUT) command.  This command, which calls a program named QSECRVKP in library QSYS, can be used to change the public authority for a host of commands and APIs to *EXCLUDE.  Doing this will allow you to control exactly which user profiles will have access to these commands so that you know who will be trusted with them.

Before you run out and execute the RVKPUBAUT command, you need to know what it is going to change on your system.  (For example, it restricts the RSTOBJ and RSTLIB commands.)  To get a full understanding of which commands and APIs will be changed, you can either take a look in the system documentation or, better yet, you can retrieve the CL program source for the QSECRVKP program and examine it yourself.   You can use the following command to retrieve the source code for this purpose:


This assumes that you already have a source physical file in your library named QCLSRC.

When you run this command, there is a single parameter.  You need to supply the name of the library where these objects are stored.  At a minimum, you should run the command for the QSYS library.  If you have more than one national language on your system, you should also run the command for every QSYSxxx library on your system.

If you see commands and/or APIs where you do not want to change the system default, you can make changes to the retrieved CL source program and recompile it.  Do not place the newly compiled program back into QSYS as that will destroy the original as shipped from the factory.  It would be best to put the copy in a different library along with your own copy of the command object named RVKPUBAUT.  Change the library settings on your copy of the command to point to your modified version of the program.  Then, when you run the command, run it from your library and not from the QSYS library.

You should also be aware that running the RVKPUBAUT command will change the public setting for the root directory of the IFS on your system.  It will change it to *USE unless it is already at that level or lower.

Once you have these commands and APIs restricted, you can then go about authorizing them to the specific individuals in your organization that really do need their use.  The best way to set this up is to create an authorization list for this set of users and then set up each of the commands and APIs to point to the authorization list.  Then, as people come and leave, a simple change to the authorization list will take care of all authorization issues to these restricted use commands and APIs.

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

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,  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

More Tips for Securing IBM i FTP

By Rich Loeber

A few weeks ago, I published a tip about the security exposure that FTP represents on your IBM i platform.  That tip has generated some interesting feedback along with some ideas from readers on how they address the issue.  This tip features some additional ideas for you to protect yourself from FTP abusers.

First and foremost is this.  If you don’t use FTP, or you only use it on rare occasions, then don’t leave the FTP server active on your system.  You can check to see if the FTP server function is active on your system by running the following command:


Look for jobs listed named QTFTPnnnnn.  If FTP is active, you will find several of these jobs shown.  To turn the FTP server off, run the ENDTCPSVR command specifying the *FTP server option.  Most systems come from IBM with the FTP server set to start automatically whenever TCP/IP is started.  You can change this by running the Change FTP Attributes (CHGFTPA) command.  Prompt it with the F4 key and check the first parameter.  If it is set to *YES, then FTP is going to start automatically at every IPL.  Changing this to *NO will stop this from happening.

In our shop, we use FTP enough during the course of the day that we keep the FTP server up and active.  But, we have job scheduler entries in the system to turn it off at the end of the day and then restart it every morning.  That way, for 24 hours of possible exposure, 16 of those hours are completely protected.  On the rare occasion when we need FTP during off hours, it is a simple matter to log in and start it again manually.

If the FTP server is inactive, then it cannot be misused.

The other good way to protect yourself from FTP abuse is through the implementation of exit point programs.  The FTP server has an exit point that can be used to filter incoming requests.  This is also true of the Telnet server, another point of possible abuse.  One reader of my last tip suggested implementing the freeware SECTCP utility written by the former IBMer Giovanni B. Perotti.  This utility is available for free download, after a simple registration process, from the following website:

I have downloaded and reviewed this code, but have not implemented since I have my own exit point software already active.  But, the reader swears by the code and Mr. Perotti certainly has a terrific reputation in the IBM i family of users.  So, if you’ve been thinking about implementing exit point controls, this might be any easy entry point for getting started.  The source code is all included with the download and, in fact, everything needs to be compiled in order to install the software.  The user instructions on getting started all appear to be fairly simple.

Also, if you don’t want the bother of maintaining your own exit point code, there are quite a few very good products available from reputable IBM i software developers today.  FTP and Telnet controls are just the tip of the iceberg where exit programming for security is concerned.  I, of course, recommend my own product: SafeNet/i.

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