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.

Watch Out For FTP On Your IBM i

By Rich Loeber

FTP (File Transfer Protocol) is a nice and easy way to communicate between systems.  With FTP on your IBM i, you can transfer files to other systems, including other IBM i’s, with ease.  You can also use it to move programs and files between systems, all with relative ease.  But, increasingly, FTP is also becoming the hackers weapon of choice when cruising the Internet.  And, with FTP’s QUOTE command (among others), a knowledgeable hacker could do some serious damage to your system.

I tell you this based on personal experience with my own IBM i.  In a recent 7 day period, I identified more than 1,500 attempts to sign-on to my system from people not authorized.  All of these were malicious hacking attempts.  When I did a Trace Route on many of these, they pointed back to source IP addresses in The Netherlands, China, Colombia, Russia and other parts unknown.  Some attempts would not even trace back successfully.

I initially thought that nobody would bother my system since it is just a numbered address with no DNS entry to make it easy to find.  But, this is clearly not the case.  Some hackers use automated attack programs to just cycle through entire IP address ranges, and these are the folks who regularly stop in at my system.

The method used, from my personal observation, is to break in using the same user profile, usually ADMINISTRATOR, trying a different password every few seconds.  They will often cycle through and retry the same password more than once.  I’ve observed one break-in artist try this 850 times in a row over a period of several hours.

I know all this about my system because I monitor all network traffic and track it using our exit point software.  We have our system configured to only permit FTP access from trusted IP addresses.  The list is, necessarily, very small.  This protects our system from malicious remote access via FTP.  Also, if a hacker were to get past this check (which they never have so far), our system has no default passwords, so trying to cycle through known IBM i profiles and default passwords will also end up in failure.

So, what can you do to protect your system from FTP attackers?

First, make sure that you don’t have any default passwords set up on your system.  Use the Analyze Default Passwords (ANZDFTPWD) command from the SECTOOLS menu for this.  Initially, run it with the *NONE option for the ACTION parameter just to get a listing.  Then, when you’ve reviewed the list, make sure that the profiles with default passwords have their passwords reset to either a different, unique password or are set to *NONE.

Next, implement some sort of IP packet testing to only accept FTP connections from trusted IP addresses.  You can do this like we do using an exit program attached to the FTP sign-on server.  Or, if you have a fairly recent version of the OS, you can use the IP packet filtering capabilities in IBM i Navigator.  This will let you allow known IP addresses, or address ranges, to access your system while keeping everyone else out.  When setting this up, make sure you keep an active connection to your system while you are testing so that you don’t accidentally shoot yourself in the foot and lock out all access to your system.  Remember, the IP packet filtering will apply to all users connecting to your system, not just FTP users, so this will be a bigger job than you may think starting out.

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

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:


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:


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 @  All email inquiries will be answered.

Watch Out When Restoring User Profiles

By Rich Loeber

I was recently confronted with an issue on one of our test IBM i boxes.  The box is implemented as a “warm” backup site for one of our customers.  Every night, a simple FTP of changed objects takes place from their server to our test box.  The theory is that the customer can afford to loose one day’s worth of processed transactions for the ease and relatively low expense of maintaining this sort of backup site.

The problem posed to me concerned their security configuration.  While their program base and data files were all being properly synced night after night, their passwords were growing woefully out of date on the backup site.  If they had an emergency, nobody would remember their older passwords.

I thought that the solution would be simple.  Just run a SAVSECDTA (Save Security Data) on their system, then restore it on our test box.  Before doing this, I compared the user profile base on both systems and found some areas for concern where the same user profile existed in both places.  Fortunately, the RSTUSRPRF (Restore User Profiles) command lets you either restore specific profiles or restore all profiles with an exclusion list.  I wanted to exclude all Q* profiles plus a handful of common profiles that exist on both systems.  My list ended up being fairly short.

I was all set to bring these profiles current, but when I tried the RSTUSRPRF, I was gently reminded that this command can only be run when the system is in restricted state.  Our test box hosts several websites including one that runs in secure HTTPS mode.  Thinking this would be a quick process, I shut down the system after notifying a few people that there would be a short interruption in service.  When the system came to restricted state, I ran the user profile restore which ran quickly and without any issues.

I then restarted the system, and here is where it got interesting.  At first, it looked like everything was fine, but I soon found that the web server instance that was using HTTPS was not restarting correctly.  After poking around for a few minutes, I found that it was objecting to the digital certificate that was specified for the site.  I fired up the Digital Certificate Manager (DCM) to see what was going on and the certificate looked just fine.  I decided to delete the certificate and re-add it, and here is where the train wreck was revealed.

When I tried to re-issue the certificate, I was advised that my password for the certificate store was invalid and that I would have to change the password before I could issue the new certificate.  I dutifully changed the password, but the same error kept coming back up.

After a long investigation period, I finally determined (with help from on-line friends) that the root of the problem was the RSTUSRPRF.  It turns out that the restore user profile process restores critical data and keys for the digital certificate store while restoring your profiles.  I now had this information from our client’s box, not ours.  None of the certificates on our system were valid any longer and additional applications on the test box were also failing because of this.

The solution was fairly simple.  You just have to restore the Digital Certificate Manager objects from a security backup from your system on top of the restore just done from the foreign system.  The RSTUSRPRF has the following format for this process:


It took me a while to find a current backup of our system’s security data (another story for another time).  As soon as I did this, then DCM would work correctly and the invalid digital certificates could all be re-created.  While our system was not technically down for this time period, several applications were knocked out for almost 6 hours.

Who would ever guess that restoring user profiles would end up hosing your digital certificate files?  A friend blames this all on IBM for such a kludgey implementation of DCM.  I have to say that I agree.  The save and restore of this certificate information should not be hidden along with the user profile save/restore.  The fix should be a new command from IBM for RSTSECDTA.  Let the user profile restore do just that and move other operations to a different command process.

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

Controlling Telnet Sessions

By Rich Loeber

I am always amazed at how easy it is to establish a Telnet connection with another system.  Just open a command box on your PC and enter the TELNET command along with the IP address of the system you want to connect to.  On most IBM i boxes, you’ll get the familiar signon screen and as long as you have a legitimate user profile and password, you’re in business.  I recently had a IT manager ask me to connect to their system to do some diagnostic work.  They gave me what appeared to be very secure instructions to obtain a sign-on screen from a web-based applet.  I followed their instructions and ended up connecting and getting the work done.  When I was finished, on a whim, I tried a direct Telnet connection to their system and got through without a hassle.  Their IP address was provided through the web-based application sign-on process which was a significant weakness of that in my book as well.

In other tips about getting control over IP server functions, I recommended just shutting off the server function if you use it sparingly or not at all.  Unfortunately, Telnet does not fall into this category.  IBM i Access uses it to establish emulation sessions and most other legitimate methods for establishing a terminal session end up going through the Telnet server.  So, if you shut off Telnet, you’ll be shooting yourself in the foot.

The good news is that there are several things that you can do to get control over how Telnet sessions are issued on your system.  The first big step you can take is to turn of automatic configuration of virtual devices.  For terminal sessions, these are the pesky QPADEVnnnn sessions that you may be familiar with already.  You do this by setting the system value of QAUTOVRT to zero.

Before you do that, check your system to see if there are active sessions using one of these device names.  If so, then you’ll have to contact the users that are coming in with these device names and get their terminal session configurations updated to use a known device name.

Concurrent with this, you will also have to deactivate automatic device configuration.  Without taking this step, anyone can configure a new device name by just using it in a new configuration.  The first time they sign-on, the system will generate the required device description for them.  You can shut this off by setting the system value QAUTOCFG to zero (off).

Once you’ve made these changes, you should then go through your system and manually removed any QPADEVnnnn devices that have already been created and used on your system.  You can view all of these by going to the i/OS menu named CFGVRT and running option #3 or just run the following command:


This will display all of the virtual display devices on your system, just check those with names that start with the QPADEV.

While you’re making these changes, it would also be a good idea to check the system value QAUTORMT.  This should also be set to zero (off) to help assure a secure system.  This value is used for automatically creating remote controller devices.

Some of your people may rely on automatic device configuration when new devices are attached to your system, and that’s probably still OK.  But, it doesn’t happen every day in most shops which is a good reason to keep it turned off most of the time.  When you need automatic device configuration, you can activate it for a few minutes as needed and then shut it off again.

If you want even more control over Telnet session, you can activate the required exit point and check for specific source IP addresses and only permit Telnet session that are coming from a known address.  Our SafeNet/i network security software includes this feature and we turn away illegal connection attempts to our system on a daily basis with this activated.

Security Things To Watch Out For in the IFS

By Rich Loeber

The IBM i/OS is rightly known for good built-in security features.  For those of us who grew up with it since the early AS/400 days, security requirements for the “native” library file system are pretty easy to understand and administer.  When it comes to the Integrated File System (IFS), however, things can work differently.  This tip will explore some of the differences and how best to try and deal with them.

If you grew up with the IBM i/OS from the early days when it was known as OS/400, you know that the native file system that is based on libraries and objects within those libraries.  Security can be implemented at the library level and at the object level and the hierarchy is intuitive.  When it comes to the IFS, things can be different.

First, keep in mind that the IFS is a global term for a variety of file systems that are available to the System i user.  In fact, it includes what we refer to as the “native” file system within the QSYS.LIB file system.  Other file systems include the “Shared Folder System”, also known as the QDLS file system; the “/root’ file system, the QOPT file system, the QopenSys file system, the QFileSvr.400 file system and more.  These other file systems all employ an organization based on nested directories.  Where your files reside will determine your approach to securing them.  If you’re just using the native file system, this tip is not for you.  If you’re using any of the other file system (and most IBM i shops today are in this boat), then read on for some things to watch out for.

The exact security set up that you choose will depend on how the files are stored in the file system in question.  For example, the QOPT file system (for optical drive operations) has no security at all since there is no way to write security information to the file system, it is read-only.

The IFS file system is designed to follow POSIX (Portable Operating System Interface) standards wherever possible and certain unusual behaviors can happen when this is mixed in with the System i OS.  Here are some things to watch out for.

When you create a directory, the owner must also appear in the security authorization for the directory.  In the native file system, the owner has clear rights to an object, but not so in the IFS.  The owner’s rights must be defined as a private authority.

For files in the IFS, keep in mind that adopted authority is not honored for most file systems including the root, QDLS and QopenSys file systems.  Your application designs may rely on adopted authority for the native file system, but this approach will not work for most other file systems on the System i.

Most file systems will require *RX authority to read an IFS file.  This will apply to every step in the directory path.  If your application needs to read objects in the IFS, make sure that *RX is in place for the entire path structure.  Object management rights (the X character) are needed for some functions that you might not normally think of, so it is best to include it.

When making copies of files in the IFS, be careful which command you use.  The COPY command will duplicate the file including the file’s authority settings.  The CPYTOSTMF command, however, is only intended to copy the data in the file.  The file created by CPYTOSTMF will be owned by the user that runs the command and the owner’s rights from the original file will be dropped.  You will have to reset the authority the way you need it once the copy has completed.

For a complete discussion on these along with other things to watch out for, check out the IBM publication known as “Tips and tools for securing your iSeries”, chapter 11.

Working With IFS Security

By Rich Loeber,

For years, IBM’s i/OS provided robust security for its native file system.  For some of us who’ve been around for a while, this has been all we’ve known on our systems.  But, these days, more and more applications and users are working with the other non-native file systems that are collectively known as the Integrated File System, or IFS.  IBM’s i/OS provides the same level of security in the IFS, but the commands to review items in the IFS and a lot of the terminology is different from what the “natives” may expect to see.  This article will attempt to scratch the surface of this issue by explaining how you can view the IFS directories and files from your i/OS command line and how to interpret the security settings used in the IFS.

The main command that you need to start with is the “Work with Object Links” command (WRKLNK).  These “links” can take several different types, the most common of which are directories (DIR) and stream files (SMTF).  If you thought about this from a PC perspective, these would correspond to disk directories and files.

If you use the WRKLNK command with no parameters, a complete list of all of the top level directories in the IFS (the root) will be displayed.  This display will let you explore the entire IFS on your system, including the “native” file system which will be included under the QSYS.LIB file system.  If you want to go directly to a specific directory, you can do so with a qualified OBJ selection parameter.  For example:

WRKLNK OBJ(‘/qdls/kisco’)

On our test system here, we have a directory in the shared folders file system named KISCO.  The shared folders system is found in the QDLS file directory.  Running the above command gets us straight to this folder without having to spend time searching.

To check on the security setting for an displayed object, just put a ‘9′ next to that object.  This will bring up a Work With Authority display and will give you all of the security information about the object selected.  This will include the owner, any applicable authorization list, any public authorization settings and a list of user profiles that are authorized to the object.  If you want to print this information for an off-line review (or for security documentation), you can use the Display Authority command (DSPAUT).

Data authority in the IFS is described by a series of letter codes which, in combination, will describe the authorities in place.  The applicable access letter codes are as follows:

R – Gives access to object attributes (think READ)
W – Gives access to the object for change (think WRITE)
X – Allows the object to be used (think USE)

You will see these codes in combination or singly (preceded by the ever present *), depending on the authorities implemented.  For example, if full authority is being granted, then you will see the *RWX authority setting displayed.  Specific object authorities are also displayed on this screen.  You can use this screen to make changes and to check on specifics for any object shown by placing a ‘2′ next to the line in question and making updates.

So, if you’ve never (or rarely) considered what’s going on in the IFS on your system, now is the time to get started and the WRKLNK command gives you are very good starting point.

Controlling Remote Command Processing

By Rich Loeber,

One of the cardinal rules of securing your IBM i system is to prevent users from having open access to the i/OS command line unless absolutely necessary.  Typically, access to the command line is limited to operators, programmers and other IT staff users who need it to get their jobs done.  But, users in general should never be granted the use of the command line.

But, a knowledgeable PC user, using PC-based software tools such a iSeries Navigator, can run commands on your system without obtaining a signon screen and command line.  Also, when a user submits a remote command, IBM’s i/OS does not honor the Limit Capability (LMTCPB) setting for the user profile in use.  In my book, that is a significant security exposure!  Granted, the user must be knowledgeable, but it can be done.

There are several ways that this can be accomplished, as follows:

•    Using DDM (Distributed Data Management), a user can open a file and use the remote command function to run any command on the remote system.

•    Using the iSeries Navigator client, or other similar PC software, a user can issue a command through DPC (Distributed Program Call) APIs without even using DDM.

•    Using remote SQL and ODBC, some software can provide a remote command function without using either DDM or DPC

So, what’s a security officer to do?

To deal with the DDM issue, one easy way to control this is to simply turn DDM access off completely for your system.  You should first verify that no current applications running on your system require DDM, DRDA (Distributed Relational Database Architecture) or DB2.  To shut DDM off, simply run the following command:


This step is pretty drastic and will obviously not work for many shops where DDM, DRDA and/or DB2 are in use on a regular basis.  For those shops, your best defense is an aggressive security policy that protects your critical data assets.

If you want to take an more active approach to this issue, then you’ll have to look into coding an exit point program, or you can purchase a third party software package that implements exit point processing.  The easiest approach when creating your own exit program is to limit use of remote commands to a list of known user profiles.  This will allow you to grant permission to process remote commands for known and trusted user profiles while denying permission to all others.  In the exit point process, you can set a flag that will return a failure status to the PC software issuing the remote command process, so your user will know why their attempt failed.  You can find more information about exit point programming in several different manuals.  These include:

  • Implementation Guide for iSeries Security and Auditing – GG24-4200
  • iSeries Security Reference – SC41-5302
  • iSeries System API Reference book

Network/Internet Security

By Rich Loeber,

When your IBM i system is connected to a network, you cannot always guarantee the integrity of the person at the far end of a network connection. If your system is connected to the Internet, ethics go out the window altogether. You have to assume that the person at the far end is a bad guy, then proceed from there. With this tip, we’ll outline an approach to this problem that may help you to focus in on how to deal with the bad guys wherever they may be.

Internet bad guys generally fall into two categories, sneaks and bullies. The bullies you can probably identify easiest, they are the ones who go after you system with active attacks. They will try to break into your system trying just about everything in the book. On our test IBM i server in the office recently, we had a bully come by who tried to log on using over 700 different user profiles in a period of 5 minutes. Each logon attempt was met by our exit point software and tossed out right at the point of entry with a security warning message to our security officer for each try. The user profiles were all different and all “typical” of what you might expect to see in just about any shop in the country. When a bully comes after you, he does it with brute force. They can try to spoof your system, guess your passwords, deny others from using your system by keeping it overly busy dealing with their break-in attempt and much more.

The sneaks are a lot more passive. A sneak will sit back and monitor network traffic to your system and try to uncover secret information that will then give them what they need to gain access to your system “normally”. Sneaks are very hard to identify and the have insidious tools at their disposal to get the information they want. This can even include Trojan horses that gather the information for them. Since sneaks are so hard to identify, you should plan your security strategy assuming that someone is always watching your system.

To guard your system against both sneaks and bullies, you need to think about how to layer your system defenses to guard against anything and anyone. If your system is connected to the Internet, you must assume that a sneak or a bully is going to attempt to gain access and plan accordingly. The best defense is always a good offense and you should consider the various layers of your system and have a plan to deal with intruders at every level. This layered approach will help you develop a good defense. The layers you should give consideration to include:

  • System security – including your system level use of user profiles and regularly rotated passwords. For most IBM System i shops, this will be your last line of defense, so plan it well.
  • Network security – this commonly involves implementation of a firewall between your network and the Internet but can also include services available from your ISP. On the IBM i there are also things that can be done at the IBM i/OS server level via exit programs that can address network security issues.
  • Application security – your applications should be designed to integrate with your security policies. Application software can easily be misused and abused and your applications should be designed with this in mind, especially those applications that are open to network and Internet users.
  • Transmission security – when you use an uncontrolled network like the Internet, your data will be open to anyone while it is in transit from one place to another. To protect your data, you need to consider encryption techniques and the use of Secure Sockets Layer (SSL) on your IBM i server.
In your plan for Network and Internet security, you need to have a plan for each of these layers of control in order to guarantee your system. And, even then, a bully or a sneak might still get past you, so watch out.