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.

In other tips about getting control over IP server functions, I have 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 off 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 remove 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.

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

Application Software Package Security

By Rich Loeber

I often hear from readers lamenting the deplorable state of security in the third party application software running on their IBM i.  Some products enforce the establishment of a standard group user profile along with a default password for that profile.  Others have their data files configured with all access to the public.  In this day and age, these situations are certainly inexcusable.  But, what can you do?

First, a little history is in order.  A lot of mature third party software has been around since before many of you were working in the IT field.  In those days, there were no PCs, no networks and little connectivity between systems.  Security was controlled at the application level.  By that, I mean that users were presented with menus and could only access data by choosing the right menu option.  If the user wasn’t authorized to use the data, the menu option would not be available to them.  For its day, it was a good security model.

But, today is very different, with FTP, ODBC, Access Client Solutions (ACS) and other such PC-based tools that are connected to your system via high speed network connections.  That old menu security model is not applicable to today’s environment.

In the modern IBM i implementation, if your data files have public access to all users, then someone can connect to your system with FTP and download to their heart’s content.  Granted, they will still need a user profile and password, but is that the security model that you want to enforce for your shop?  I don’t think so.

An even worse situation comes from users with ACS installed.  From their desktop, an adventurous user could easily browse around your system looking for interesting file names and libraries until they find just about everything on your system.

So, what’s the solution to this problem?

First, when you’re shopping for software, the product’s security implementation must be understood before you get too far down the road.  If the product is wide open, move on to another vendor.

If you’ve already got a product with this security model implemented, you probably are not in a position to just switch to another vendor.  In that case, the first thing you should do is contact the vendor and demand that the situation be corrected immediately.  There are lots of easy solutions that a responsible software vendor can implement to correct this problem.  Don’t take “No” for an answer.

If you get little cooperation from your software vendor, you should take matters into your own hands.  The quick solution is to implement exit point controls for the critical data in your system.  If you don’t have the know how or wherewithal to create your own exit point programs, there are quite a few general purpose products on the market today that are good which address this issue (I recommend SafeNet/i from my company!).

The worst thing you can do, however, is to just sit back and wait for your vendor to fix the problem.  In the interim, your data is exposed.  You may think you’re safe, but you just cannot guarantee the safety of your data in this environment.

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

Limiting Security Officer Access

By Rich Loeber

A reader recently posed the following question to me:

How can I limit the places a person can log on as QSECOFR? I don’t want someone to be able to log in from any desktop or workstation as QSECOFR other than the main console. Are there system values related to the QSECOFR profile?

The special user profiles on your system that are set up as security officers really do have the keys to the kingdom when it comes to accessing your system.  No files, programs, data objects, files in the IFS, and more are safe from access by someone who is logged onto your system from one of these user profiles.  Keeping these profiles limited to certain devices is a good objective so that someone using them will be under direct supervision.

The best way to approach this is through a combination of object security configuration on your terminal device descriptions along with a varied setting for the system value QLMTSECOFR.  Your system will come from the factory with this system value set to ‘0’ which lets anyone with *ALLOBJ authority sign on to any terminal session.  Changing this to ‘1’ will only let the security
officer signon to a terminal session where they have specific authority granted at the device description level.

But — WARNING WARNING WARNING — don’t go rushing off to make this change!  You must first get it set up and test it before adopting it as practice could result in your security officer profile getting permanently locked out of your system, and you don’t want that situation on your hands.

So, your first step is to identify the device description object for your system console and make sure that QSECOFR is expressly granted permission to use the object (ie: *ALL authority).   The device descriptions on your system are all stored in the QSYS library with object type of *DEVD.  You can make changes in the authorities for the object using the Edit Object Authority (EDTOBJAUT) command.  When your console device has been updated, find the backup console device description too (on most systems, it is called QCONSOLE) and do the same thing there.

To test this setup, first sign on as QSECOFR on a normal terminal session and leave that active for the duration of your test.  That way, if things go south on you, you still have an active security officer session to fall back on to make changes.  With this backup session active, make the changes to the system value and the device descriptions.  Vary the console device off and then back on too to make sure you’re using the updated authorities for the device.  Then, make sure that you can sign on from the console using the security officer profile.

Assuming that all is OK, you’ll need to scour your system for the other terminal device descriptions to make sure that the security officer profile is not authorized for any of them.  Once this is done, then try to sign on as the security officer on another terminal, it will be denied.

Only when you’re satisfied that everything is working as planned should you release the security officer session that you’ve been holding open as your back door.

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

Are All Of Your IBM i Doors Open? – Part 2

By Rich Loeber

In my last tip, I pondered the need to watch the doors into your system.  In the old days, there was a single door in the form of a display terminal.  Today, that is only one of many doors where users can get into your system.  While most users are trustworthy, there is always the opportunity for inadvertent damage to your data from someone who happens to get into your system through a door that should be closed to them.  Then, there are always those lurking in the shadows who are just looking for an unlocked door to gain access and wreak havoc in the process.

Last time, I talked about the most obvious doors and the most obvious solutions for those situations.  This week, we’ll take a closer look at the less obvious doors and how you can deal with them.

In addition to the obvious doors to your system like FTP and Telnet, IBM i has a variety of server functions included that provide network access points for a wide variety of host-client connectivity.  These includes the likes of a DRDA DDM server that can share data files on a record-by-record basis with a client; the File Server that allows files in the IFS to be directly accessed from desktop applications; the Remote Command server that allows a desktop system to issue IBM i commands directly from the desktop; and so on.  The list is quite comprehensive and many IBM i managers are not even aware of all of the possibilities.

So, my first recommendation for you out there is to educate yourselves about the doors that are there.  Play around with IBM Navigator For i (Navigator) on your system to see all of the server settings and whether or not they are running on your system.

To use Navigator (a component of IBM i Access Client Solutions [ACS]), it must be installed on your PC with all components.  Then, the Admin HTTP server must be active on your IBM i.  It runs in the QHTTPSVR subsystem and, if active, will show multiple jobs with names that start with ADMIN.  If you need to start the admin server, the command is:


You start Navigator from ACS.  It will start a session in your browser and you will need to sign on with a user profile with security officer permission.  From your browser, select the “Network” tab.  This will present you with a short list of new tabs, open the “Servers” tab next.  To see what servers are actually up and running on your system, look at the tabs marked “TCP/IP Servers” and “IBM i Access Servers”.  These will each show you a list of server functions on your system with a brief description of the function being served and what its current status is on your system.  It behooves you to know about all of those that are showing as started.

Once you have identified all of the server functions that are running (each is a door into your system), then you will need to validate its use on your system.  Identify the application that is using it and check to make sure that security is in place to control what can be accessed through each of these doors.  Also, make sure you know what user profiles are in use for each server function.  If common user profiles are shared between different server functions, you could have a security risk due to contextual conflicts between uses.  This kind of exposure can happen when an FTP user profile needs access to different data than an ODBC user.  If the same profile is used in both contexts, you could end up with a security exposure.  Also, remember that when you open a door for one application, it ends up remaining open for all of the profiles on your system.  You need to have a plan in place to keep the wrong people away from doors that they should not be using.

In some instances, the only way you will be able to make sense out of what is going on will be to implement one or more exit point programs to allow you to see exactly what kind of network requests are happening.  You can either write your own or get one of the several commercially available exit point solutions.  I recommend SafeNet/i from Kisco Information Systems, my company.  This will tell you which profiles are getting into your system through each door and what they are doing when they are in there.  Without knowledge at this level, you’re only guessing at what’s going on.  Guessing at activity does not promote good security policy implementation.

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

Are All Of Your IBM i Doors Open?

By Rich Loeber

Living in a remote area, a lot of people near us like to leave their doors unlocked for convenience sake.  Most of the time this is OK, but occasionally it gets someone into trouble.  A recent local incident got me thinking about all the doors that can be used to enter the IBM i and I wanted to take some time to explore this today.

My wife and I live in the middle of the Adirondack Park, a 6 million acre state park in northern New York (think “about the size of Massachusetts”).  This area houses a year round population of just over 130,000 souls.  As you might imagine, with that population density, security is not a big issue.  I know people here who have no idea where their keys are to lock the doors on their house, and are not worried about it.  Recently, there was a burglary in the town where my office is located.  Someone just walked into the back door of a shop and helped themselves to money in the cash register, then slipped back out without being seen.  This got me to thinking about security on the IBM i and how a similar situation might easily exist at many shops where doors are left open for no good reason.

In the “old” days, the only door you had to be concerned about was the computer terminal.  These were placed in public places and protected by user profiles and passwords.  In order for someone to sneak in, they’d have to be pretty bold and they’d have to know a profile/password pair.  Today, the user profile/password continues to be a primary locking mechanism for your system.  So, this continues to be your first line of defense.

Keeping your user profile list current is probably one of the most important tasks you can do.  Some critical things to remember include enforcing periodic and regular password changes, deactivating and even deleting old profiles for people who are no longer employed there and only providing the level of access permissions that a profile needs.  That’s pretty simplistic, but remember that you’re handing out keys to the doors of your system.  You want to limit the number of keys in circulation and you don’t want everyone to have a master key.  Also, you need to make sure that there are no default passwords active on your system, including passwords for well known third party software packages.  The system will watch the doors for you, but if there is no control over the keys, what’s the use?

Assuming that you have your keys under control, then you need to also take a look at all of the doors that are on a modern IBM i server these days.  The days of only needing to control terminals is long gone.  Today, you need to be concerned about the FTP door, the Telnet door, the Remote Execution door, the ODBC door, the SQL door, the Shared Drive, the Navigator for i door, the file upload/download door and on and on.

For some of these doors, you can easily control access by removing the door altogether.  If your shop does not use FTP on a regular basis, then don’t leave the FTP door in place.  On most systems that I work on, I find the FTP server up and running by default.  It is a simple matter to turn it off with the command:


and to use the Change FTP Attributes (CHGFTPA) command to set the AUTOSTART parameter to *NO so that it doesn’t restart with every IPL.  If you occasionally use FTP, you can start and stop it as needed using the STRTCPSVR and ENDTCPSVR commands.  With this approach, you not only lock the FTP door, you remove it from your system.  If the door isn’t there, it can’t be opened.

Another method for limiting FTP is to only have the FTP server active during normal business hours.  It is a simple matter to set up your system scheduler to start FTP in the morning and shut it down at the end of the day.  That locks the FTP door for more hours in the day than it is open.

Other servers can be handled this way too.  These include the Trivial FTP server, the TCP/IP DDM server and the Remote Execution server to name a few.  If your system has these servers active, each one represents another door that can be used to access your system.  If you’re not using these server functions, then remove the doors.

The easy way to check on these is to go to the operating system Configure TCP/IP menu (CFGTCP) and run option #20.  Check each of the displayed server functions and see how the AUTOSTART parameter is set.  If you don’t have any applications using these servers, then remove these doors to your system.  The fewer doors that are on your system, the tighter your security.

This only covers some of the doors into your system.  Next time around, I’ll address some of the doors that are a little more difficult to keep locked.  If you have specific questions about this topic, you can reach me at rich at,  All email messages will be answered.

Do You Have A Security Policy In Place?

By Rich Loeber

A conference speaker at a security forum that I attended some time ago posed a most interesting question.  He asked the simple question “What is your security policy?”.  I wondered what he might be getting at since the audience was made up of information technology security experts.  He went on to propose the idea that most security departments are more involved in security implementation than they are in enforcing security policy.  The tail, in effect, wagging the dog.

A security policy is a set of statements that describes how you view information security for your installation.   In each application area, the policy should describe how information created and stored in the application is going to be treated from a security perspective.  It might include statements such as “Only Payroll department employees can update payroll data”, or “Accounts payable vouchers can only be entered and maintained by employees in the Accounting department”.  As you consider your various policies, your Security Policy will roll out over time to include all aspects of information security.

The conference speaker I heard indicated that most IT security is determined and implemented by IT staff people with little input from the user departments.  This kind of security implementation, like any IT initiated application implementation, is destined to fail without user department participation.  Only the true owners of the data being secured can accurately create a security policy for their information.

If you don’t have a security policy in place, this might be a good time to think about creating one.  For your policy, you should consider all applications on your system including the operating system and system utilities.  For each application area, you should identify the owner of record and then meet with them to determine the security rules that should be in place.  The end user/owner of the application will probably know a lot more than you think about what applies to their information and how it needs to be secured.  Often, additional legal and operational situations will be known at the end-user level that your centralized IT security group is completely ignorant of.

Your security policy will end up being a series of descriptive statements about the information associated with each application area.  Once you have this in place, you can then review your security implementation, which is probably already in place to some extent, and see where your practice falls short of your policy.  You may identify areas on your system where your implementation falls far short of the policy objectives.  When this happens, you’ll need to involve your application owner to see what needs to be done to meet the policy.  Additional security tools may be required or tighter implementation of existing tools may do the trick.

You may even find areas where your implementation is stronger than what the policy states as a requirement.  For these situations, the additional security may not be necessary and could be resulting in administrative burdens that can be relieved by backing off on your implementation.

As you can see, without a stated security policy, you cannot effectively implement information security for your installation.  The only people who really know the requirements are probably not in the information security or IT departments.  So, get out there and get your policy down on paper, properly defined.  Then see if your implementation measures up to your requirements.

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

Object Signing, What’s That All About?

By Rich Loeber

All of the security measures you implement could easily be brought down if someone can introduce tampered data or programs into your system without your knowledge.  To address this, the IBM i OS has supported object signing ever since release V5R1 became available.   Object signing, simply stated, works by having each object on your system signed by the originator that guarantees that the object is what it claims to be and that it has not been altered.

Most systems today, many years after release of this feature, still only have the IBM operating system carrying signatures.  Run the WRKOBJ for *PGM objects on your system in the QSYS library.  When the list comes up, place and ‘8′ next to one of the objects and then scroll up to the second panel.  You should see the following fields displayed:

    Auditing/Integrity information:               
      Object auditing value  . . . . . . :   *NONE
      Digitally signed . . . . . . . . . :   YES  
        System-trusted source  . . . . . :   YES  
        Multiple signatures  . . . . . . :   NO   

Note that the object is showing as being digitally signed and that it is from a system-trusted source.

Similarly, if you do the same for some of your own programs, you will probably find that there is no signing in effect.  In fact, most IBM i implementations today that are not from IBM carry no signature.

So, what’s the big deal and how can this help you?

For now, probably not much.  The current implementation of this is clearly designed to help IBM protect its operating system.  IBM has provided some tools in the operating system to give users control.  The system value QVFYOBJRST can be set to only allow restore of objects that are signed.  You can differentiate this for objects that are system state and user state.  In fact, the recommended setting level of 3 will prevent any unsigned system state programs from being loaded onto your system, thereby adding a level of protection to the operating system’s integrity.

There is also the ability to scan your system for object integrity by using the Check Object Integrity (CHKOBJITG) command.  An option on this command will let you verify objects that are signed to make sure that operating system components have not been tampered with since they were loaded.  Scanning the operating system on your server can produce a database list of all objects on the system that have bad signatures.  Finding these could indicate that the operating system has been tampered with.

To add an additional layer of security to your own applications, this technology is available for user state programs as well.  But, seeing that the software developer community has not embraced this to date, you may just be asking for a headache by doing your own implementation while other third party software on your system does not comply.  IBM documentation is available, however, to implement this for your own applications.

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

Network Intrusion – An Allegory

By Rich Loeber

I have shared before that we live in the Adirondack Mountains in northern New York.  When most people think about New York, they don’t think much farther than New York City, but New York contains some beautiful and very wild locales and we live in the heart of one.  Our home is located on a large lake and my wife and I fell in love with our place the first time we saw it.

One of the key features of our place is a sandy beach.  A few days after we moved in, we got up in the morning to find a small flock of Canada Geese on the lawn and thought what beautiful birds these were.  After a few days of this, and a walk down to the beach area, our opinion of these geese headed downhill fast.  We were under an intrusion attack and needed to do something about it to protect our beach from the mess that the geese were creating.

Our first attempts at intrusion protection were simple, we just ran outside waving our arms and chased the geese off the beach.  They swam out on the lake a little way and then waited until we got tired and headed back inside.  Within minutes, they were back on the beach and we were right back where we started.  I then got the bright idea of leaving a “presence” on the beach to ward the birds off.  The next time I went out, I planted a broom on the beach and the geese did not return …. until the next day.

A friend told us that Canada Geese are afraid of owls and that a lot of locals reported good results from owl statues.  I search the Internet and found a garden supply house that sold inexpensive owl statues expressly for this purpose.  They even said that this particular owl species was feared by Canada Geese.  Our owl arrived a week later and with much anticipation, I put it up on the beach.  The next day, the geese were back huddled right around the owl.

Then, quite by accident, we found a solution that worked quite well.  We found that when we used a lawn sprinkler near the beach, the geese did not like it and stayed away.  So, we left the sprinkler out on the lawn and whenever we saw geese on the beach or swimming our way, we turned on the sprinkler and watched them head away.  After a few weeks of this, some of the geese found that they could avoid the sprinkler by going around it at the edge of the coverage area and we had to reposition the sprinkler to adjust.  But, the sprinkler technology was clearly one that worked.  The only problem with it was that it would not work when we were not at home.  It required direct intervention to repel an intrusion.  When we traveled away from home, we would come back and find the beach a mess.  If we just left the sprinkler on all the time, the yard would get soaked and we ended up with beach erosion. A better solution was still needed.

Last year, I think the problem was finally been solved.  I found a supplier who makes a motion sensor activated sprinkler!  As soon as I saw these on the web, I bought two of them at a very  reasonable price and waited for spring to try them out.  Two weeks into the season, after some early intrusions by the returning Canada Goose population, I deployed the motion activated sprinklers.  Since then, we have not seen a single goose on our lawn.

So, what does this have to do with computer intrusion protection?

Lessons learned from this exercise in our yard show me the importance of first knowing what is going on in your network.  If you don’t keep track, you’ll never know what’s going on in your yard.  You could be getting attacked on a regular basis and never know it.  Second, you need to find the solution that is right for you.  Not every intrusion situation is going to be the same (we have neighbors two houses away who never have a problem with geese, but frequently have bears getting into their trash).  Listen to recommendations from friends and associates, but do your research.  In my situation, I have left the owl statue in place as a constant reminder that some solutions are just dumb.  Lastly, once you have a solution, fine tune it.  Don’t be satisfied until you know that the solution is always working and achieving your objectives.  Keep up to date on developments in technology that you might use for your situation.  Stay current.  If you have a software solution, keep it current as your vendor releases updates.

If you are vigilant, you will be rewarded with a clean network.  In my case, I am looking forward to having a nice clean yard and beach area this summer.

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

Can NAT and IP Packet Filtering Work For You?

By Rich Loeber

In your efforts to secure your IBM i, you often come up against constraints imposed by company management.  Often, you will find that a specific technology or software add-on will give you an extra measure of needed security, but management has turned you down because of cost.  Since this is often an issue, it is always nice to find security tools that are built into the operating system that you can deploy without additional expense.  This tip will introduce you to two such tools on your system, NAT and IP Packet Filtering.  Both are included in the IBM i OS and are deployed through the Navigator For i.

NAT stands for “Network Address Translation”.  Among other things, NAT will allow you to provide public access to your system even though it sits behind a firewall.    It does so by changing the source and destination IP addresses for data packets as they flow through your system.  It can also be used to simplify configuration when multiple networks in your system operate on different addressing schemes.  Your system can act as a go-between making the connections possible.  NAT can also be used to hide real IP addresses between networks.

IP Packet Filtering lets you block specific IP addresses or filter packets based on information contained in each packet header.  This gives you a lot of power to control who can access your system and who cannot access your system based on the IP address they are coming from.  Using IP Packet Filtering, you can:

  • Permit or reject packets based on their destination IP address.
  • Permit or reject packets based on their source IP address.
  • Permit or reject packets based on either their source port number or their destination port number.
  • Apply these rules selectively when you have multiple network connections to your system.  Different rules can apply to each network adapter.
  • Stop undesirable traffic from passing through your system to other nodes in your network.
  • Selectively log traffic based on the way your rules are set up.

You can find more information about setting up and configuring NAT and IP Packet Filtering at the IBM iSeries Information Center (  Look for a manual titled “Networking – IP Filtering and NAT” for your release level of the IBM i OS.  The Navigator For i includes a setup wizard for IP Packet Filtering that may also help you to get started.

One note of caution.  While these “free” tools are available for your use, they are just another tool in your security toolbag.  Used together, these functions provide some of the functionality you’ll find in a firewall, but full implementation of a firewall product is preferable.  These tools should be used in conjunction with your overall security plan and strategy.

If you have questions about details of this tip, feel free to contact me directly by email: rich at

The Case For Implementing Exit Points

By Rich Loeber

Someone recently asked me if there was someplace on the Internet where they could see a case made for implementing exit points on their IBM i system.  I was at a loss for a comprehensive source and this got me thinking that it might be a good idea to just create one here.

Security exit points on the IBM i (and its predecessor OS/400) have been in existence since the mid 1990’s.  When the system was opened up to network access, the need for additional security over and above the standard IBM i OS security was apparent.   IBM’s solution was to let their customers solve the issues on their own by giving them access to specific decision points in the various network server functions that were being rolled out.  Server functions were being added to the IBM i OS to support network access to the system like FTP, ODBC, SQL, mapped drives in the IFS, file upload and download, remote command calls and a lot more.  Since that time, even more network functions have been added along with related new exit points.

To be fair and above board, I must also disclose here that my company, Kisco Information Systems, jumped on the exit point bandwagon right away when the exit points were initially rolled out.  Since 1996 we have been selling a comprehensive general use exit point solution called SafeNet/i, now in its 11th release.

The question I was asked was “Why does my shop need to implement exit point controls?”.  That is what I want to address here.  I will do so by describing several cases where additional security is needed over and above the already excellent security features that are built into the IBM i OS.

Case #1:

The classic case for exit point implementation comes from the 5250 terminal application days.  If you have a Payroll Application that runs on your IBM i and is maintained by one or more clerks, OS security has to give access to the payroll files for those clerks, but the application and terminal menu system can easily be used to restrict what operations they can do on the payroll master files.  That access will probably grant then *USE access so they can update files and generate payroll checks and reports.

The above scenario is secure from an application perspective, but you would never want your payroll clerk to be able to download the payroll master files and take them home on a USB drive, would you?  An exit point implementation can prevent this access.  The exit point process runs on top of the IBM i OS and can be used to restrict server functions by user profile, source IP address and even by objects accessed.  This leaves the IBM i OS security in tact for the 5250 terminal application and also prevents unauthorized access via the network connection.

Case #2:

Many IBM i shops have one or more “regular users” defined with *ALLOBJ access in their user profile.  This can happen for lots of reasons and in many cases, it would take a very long time to correct.  I never recommend granting *ALLOBJ access to regular users, but if your system has evolved with this issue, it cannot be fixed overnight.  In many cases, the application itself is providing the security.  The issue, however, is that these users literally have access to ALL OBJECTS on your system.  With network access to your system, one of these users could easily download sensitive data from your system, including credit card information and customer identity information, and hide it on a USB drive and walk out the front door and nobody would be the wiser.

An exit point implementation can address this issue.  Using exit points, you can restrict object access by user profile even though the user is set up with *ALLOBJ.  In fact, object access can even be restricted for the QSECOFR security user profile.  This can help to protect your system from abuse by a user profile that has been granted more access rights than they really need.

Case #3:

Since the TCP/IP communications utility FTP was added to the IBM i OS, a very easy to use network application lets users interact with the IBM i system without using a 5250 interface.  The FTP user can browse objects on your system and upload or download them.  A talented FTP user and even execute IBM i commands through FTP.  For some shops, you want a user to have these capabilities, but you wouldn’t want them granted on a broad basis.

Exit points can help with this too.  First, you can easily restrict which user profiles are allowed to use FTP.  Then, you can further restrict which FTP commands they are allowed to use letting them do a PUT, for example, but disallowing a GET.  Then, you can even give the user contextual access rights by only allowing an FTP connection from a known and trusted IP address, such as an internal IP address.  Then, if the user’s credentials are compromised, the FTP connection will still have to be established from a trusted source.

To sum up:

These are just a few examples of why IBM i shops should consider exit point implementation for additional security on your IBM i system.  There are literally dozens of additional scenarios that can be described, but these should get you started on making a case for exit points.  It is my belief that every IBM i shop should have some form of exit point controls in place in order to be secure.  If you are interested, I can heartily recommend Kisco’s SafeNet/i software if you want to jump in and get started.

If you have questions about details of this tip, feel free to contact me directly by email: rich at