Auditing Power User Activity

By Rich Loeber

I regularly hear from IBM i shops where users, especially programmers, claim that they absolutely must have access to all objects to get through a normal work day.  There are also many shops where certain users claim that they need to be defined to the system as security officers to get their jobs done.  Now, we all know that this is just not true, but some shops cave in and provide these authority levels as a form of appeasement.  So, if you’re the security officer in one of these shops, it is really incumbent on you to know two things:

  1. What profiles have these special authorities
  2. What those profiles are up to on your system

Fortunately, in the IBM i world, you can give someone the keys to the kingdom, but also have the system watch over their shoulder.

The first step is to identify the users that need watching.  To do this, run a Display User Profile (DSPUSRPRF) command for all profiles using the *OUTFILE option to create a database that you can analyze.  The basic information option is sufficient for your purposes.  Using the new file just created, write a Query report (or any similar database reporting tool you may have) to select all profiles with the user class field set to *SECOFR or that have the values *ALLOBJ and *SECADM in the list of special authorities.  This will give you your list of profiles that need watching.

The rest of this tip assumes that you have security auditing active on your system.  If you don’t, drop me a line and I’ll let you know how to get this active on your system.

Your next step is to check the system value QAUDLVL and make a note of the specific audit values that are already being logged on your system.  For those profiles that you specifically now want to track all security activity, you will then need to use the Change User Auditing (CHGUSRAUD) command to add all of the audit values that are not currently listed in the QAUDLVL system value.  This will ensure that all actions by these users will be included in the security journal.

Now, for those users that are particularly savvy, you will want to remove their ability to change the system auditing that you have just imposed on their profiles.  You can do this by removing the *AUDIT special authority on their profile.  Chances are excellent that they will never notice that this is gone, and by removing it, they will not be able to undo what you’ve just set up.  A note of caution, you will not be able to remove this from the QSECOFR profile.  Make sure that the password for this profile is not generally known as that could also defeat your objectives.

Lastly, check the system value QAUDCTL and make sure that it is set to the special value *AUDLVL.  If it is not already set to this value, check around before making the change to make sure that you will not end up shooting yourself in the foot by making this change.

Now that you have all the pieces in place, you will find all of the information you need to do to track these users in the system security journal.  Use the Display Journal (DSPJRN) command to display the information or move it into a database file on a regular basis for reporting and analysis purposes.  You will find information in the iSeries Security Manual on how to process information from the security journal and how to interpret the codes and other information available there.

If you have any questions about this topic, you can reach me at (rich@kisco.com), I’ll give it my best shot.  All email messages will be answered.

Restoring Your Security Configuration

By Rich Loeber

I recently wrote about saving your security configuration.  Once you’ve got your system backed up including all of the security information, what’s the best way to make sure that all of that security information is restored correctly when you have to do a full system restore.  Missing something or getting things in the wrong sequence could result in your objects being restored without the security configuration that you want.

First, you will need to plan the sequence of events in your restore operation.  For security to come out right, you should always restore your saved user profiles first.  The second task is then to restore the objects to your system.  Lastly, once the profiles and objects have all been restored, you should restore the private authorities to objects.

Let’s take a look at how to accomplish each of these steps in a way the makes certain that your security settings are all preserved.  As a safeguard, make sure you have access to the password for the QSECOFR profile on the system being restored.  You should have access to the current password and the password being restored.  If you have any serious security issues during the restore, you may have to logon as QSECOFR as a recovery option, so having access to these passwords may become critical.

To restore your saved user profiles, use the Restore User Profiles (RSTUSRPRF) command.  If you are restoring all user profiles, you should be aware that all settings for each profile will be based on the saved version of that profile.  If any changes have been made to a profile and you are restoring to the same system, those changes will be lost.  Also, make sure that the user profile being used to do the restore has both all object (*ALLOBJ) and security administrator (*SECADM) special authorities.  Otherwise, any profiles being restored with *ALLOBJ special authority could have that authority stripped during the profile restore operation.  This will not affect critical IBM Q profiles, in case you’re worried.

Once your user profiles are successfully restored, the next step is to get your objects restored.  You can use any of the following commands to restore objects on your system:

•    Restore Library (RSTLIB)
•    Restore Object (RSTOBJ)
•    Restore Configuration (RSTCFG)
•    Restore Object (RST) – for objects in the IFS
•    Restore Document Lib Object (RSTDLO) – for objects in shared folders (QDLS)

When restoring objects, be careful how you use the “Allow object differences” (ALWOBJDIF) parameter.  If you attempt to restore an object that already exists on the system and the object being restored is owned by a different profile than that being restored, the allow object differences command setting of *NONE will result in the object not being restored.  If you use a value of *ALL, then the object will be restored and the system owner will be preserved.

Also, you need to be aware that there are special considerations for public authority and authorization list values during object restores.  Generally, if an object is being restored that already exists on the system, the current object settings are preserved rather than applying those from the saved object.  For objects secured by authorization lists, the ALWOBJDIF parameter can result in objects not being restored when there is a difference between the current value and that being restored.  There is a thorough discussion of what is restored and not restored in the Security Reference Manual, Chapter 8.  Check on the issues of private authorities, object auditing, authority holders and more for these considerations.

To restore authorities, it is recommended that you run the Restore Authority (RSTAUT) command after all objects have been restored.  This will rebuild the object authorities in the user profiles.  Your restore will not be complete until this step is done.

Saving Your Security Configuration

By Rich Loeber

As your IBM i shop’s security officer, you’ve developed a security policy; analyzed the user base; classified the various points of information access and implemented your policy to protect the data assets on your system. You have a current user profile base that you’re maintaining on a regular basis. When new applications come along, you review the security requirements and make sure that they can fit within your established policies. You probably even have a plan in place for offsite backup storage for your shop with a regular schedule of backups and tape rotations.

But, have you given thought to how your security policies are stored on your system and how they figure into your backup process? If not, you might be in for a rude awakening when you need to restore your system following a catastrophic system loss. This tip will take a look at how the various pieces of your security implementation are stored on your IBM i processor. A future tip will then look at how your can make sure that your security setup can be restored successfully.

Your security configuration is stored in three different places on your IBM i server. You should be familiar with these storage locations and how they relate to your security implementation.

Some security information is stored with individual objects. These include things like public authority settings, who owns the object, what the owner’s authority to the object is, group authorities to the object, the name of any authorization list that applies to the object along with private authority information.

In addition to the security information stored with each individual object, there is also a wealth of security information stored with your user profiles. This information includes user profile attributes, the profile’s UID (User Identification Number) and GID (Group Identification Number), private authority information to objects, object ownership information, group profile information, profile auditing information and information about registered functions for the profile.

Lastly, there is security information stored with existing authorization lists on your system. This includes a list of objects secured by the list along with other normal authority information to be considered for objects secured by the list.

When you save the objects on your system, only part of the security information is getting backed up to tape. In order to get a complete backup of your system, including all of the current security information, you must not only save the objects, you must also save the security information. This requires using the Save Security Data (SAVSECDTA) command. This command will backup the user profiles, authorization lists and any authority holders that you have in your security configuration. Only when both the objects and the associated security data for your system are saved will you get a full backup of your security implementation.

There are some restrictions on the use of the SAVSECDTA command, so if you introduce it into your save/restore plan now, make sure that you understand those restrictions and accommodate them. Of special concern is the PRECHK parameter and the possibility that it could abnormally terminate your backup operation. See the HELP text associated with the SAVSECDTA command for more information.

IBM i Security New Year’s Resolutions

By Rich Loeber

Many people, self included, take this time of year for a little introspection.  We try to see where we have problems or weaknesses and then contemplate methods and strategies to make changes.  If we’re serious, we’ll sit down and make a list of things to do in the New Year.  As the security officer for your IBM i shop, this is a good opportunity to do just that for your installation and here’s my list of some items you should consider.

  • Finally take the plunge and move the security level of your system up at least one level.  If you’re running at level 20 (shame on you!), move to level 30.  If you’re at level 30, move to level 40.  Take the time to plan the move and use system security auditing to check results before you make the change.
  • Check your system for user profiles with permanent passwords; then change them all.  This will, at least, enforce an annual change in these passwords.  And, this means your personal password too!
  • Review the user profiles on your system and look for people who have left the company.  Make sure those profiles are disabled and their passwords have been changed to *NONE.  If you can do so easily, remove the profiles.
  • Review all user profiles with the *ALLOBJ special authority or *SECADM/*SECOFR user class.  Verify that each profile has a valid business reason for these high level access permissions.
  • Do a full audit of all of the security related system values on your box and make sure they are set up to enforce your company’s security policies correctly.
  • Audit your system backup plan and make sure that the tapes are being properly labeled and stored for quick and accurate recovery if needed.
  • Check on the way your backup tapes are transported to and from your off-site storage facility to make sure they are secure in transit.
  • Dust off your Disaster Recovery plan and make sure it still works.  Bring it up to date, then schedule an actual test.
  • Review physical security arrangements for your computer room and for all devices attached to your system.  Do a walk thru and actually look at the various work locations.  Check for things like passwords on post-it notes and lists of system resources.  Spank a few hands (not literally) for violators.  Your physical presence in the end-user’s environment will go a long way towards reinforcing the importance of security.
  • Resolve to review your system security audit journal on a regular basis.  If you don’t have it active, turn it on.  If you have it turned on but never look at it, develop a review process to check for problem issues.
  • If you don’t have network security implemented at the exit point level on your system, commit to getting this done in the new year.  Either write your own exit routines or take a look at one of the many packages available for this important area of system security.  If you’re new to this, take a good look at Kisco’s SafeNet/i Exit Point solution.

If you have other items to add to the list, let me know by email.  I’d love to hear about your new year’s resolutions.

For me, I’m going to just resolve to loose 20 pounds this year.  But then, that was my resolution last year and I’m weighing in at the same rate this year.  At least things didn’t get worse.  Let’s hope that your system security resolutions fare better.

Blocking Object Access

By Rich Loeber

I am often asked specific questions by readers about a situation in their shop. I enjoy hearing from readers about their real-life situations. One of the most frequent questions I hear is “How do I keep a specific user from accessing certain data files on my system?”.

The answer depends a many variables. First of all, if the user you want to block has been set up with all object authority at the user profile level (SPCAUT containing the *ALLOBJ setting), then there is really nothing you can do at the operating system level to block access. This is a frequent song that I sing, but there should be precious few user profiles on your system with this level of access. And, you should have some pretty good business reasons for granting it to those profiles where this level is supported.

Assuming that this is not an issue, then the easiest way to block access to a specific file is to edit the authority for that object using the Edit Object Authority (EDTOBJAUT) command. Add an entry for the user profile you want to block and set it to *EXCLUDE. If you want to block everyone except certain users, then set the *PUBLIC access to the object to *EXCLUDE and specifically authorize the profiles where access needs to be granted.

If your object is secured by an authorization list, then you should to make these changes to the associated authorization list. The list in force is shown when you edit the object authority. Having your object authority controlled by an authorization list is a good idea as it lets you make security changes at any time, not just when the object is not in use. Also, you can secure multiple objects with the same authorization list thereby simplifying your security administration task.

If you decide that you want to block access to all the files in a given library, then you can edit the object authority for the library. Adding public *EXCLUDE access authority at the library level will extend to all objects within the library. Remember, this will extend to all objects in the library, not just data file objects. This could be a concern for you depending on how your applications are implemented.

You can also exclude users from accessing objects that are stored in the Integrated File System (IFS). In the IFS, you can specify *EXCLUDE authority for any object for a given user profile. From the command line, you can work with IFS security from the WRKLNK command. From iSeries Access, the security functions are also available and may be easier to work with for you.

Lastly, if you have a whole group of people where you want to block access, consider placing them all into a group on your system. If you are already using group profiles and your blocking scheme does not match up with your current group implementation, then you can set up the users to be blocked in a supplemental group. The IBM i/OS provides for up to 14 supplemental groups for each user profile on the system giving you a lot of flexibility. Remember, doing things at the group level reduces your security administration overhead.

 

Using QSYSMSG on your IBM i

By Rich Loeber

If you’ve been around the IBM i for any length of time, you already know that the system operator message queue, affectionately known as QSYSOPR, can be a melting pot of important and not so important information about your system operations.  This is helpful if your are diligent about carefully monitoring the message queue.  Unfortunately, in many shops, the queue does not get the respect it deserves and messages are frequently cleared, especially when they are not demanding an operator response of some sort.

This can lead to problems when important informational messages are processed but, since they don’t demand a response, get deleted before being recognized for what they represent.  A typical example might be the CPF0907 message.  The text for this message is “Serious storage condition may exist”.  Since the IBM i lives and literally dies on the availability of storage, a low storage condition should be a red flag for you.  If you miss this warning message, the results could be catastrophic.

Fortunately, there is a solution for this problem.

IBM’s i/OS has an optional secondary message queue that you can set up to catch critical messages.  When these critical messages are issued to the QSYSOPR message queue, the i/OS checks to see if the secondary queue exists on your system and, if it is there, a second copy of the message is also sent there.

To implement this optional feature, just run the following command on your system:

CRTMSGQ  QSYS/QSYSMSG TEXT(‘Optional MSGQ to receive specific messages’)

With the QSYSMSG message queue created in the QSYS system library, now specific critical informational messages will be duplicated to this secondary message queue.  By monitoring this additional message queue, you can catch important messages from the system and be assured of reacting properly to them.

The best way to do this is to set up a monitor for the message queue.  My company, Kisco Information Systems, has two such products available that include message queue monitoring capability.  SNDTWEET will relay these messages out to a list of contacts via Twitter.  Our WebReport/i software will do the same using email notices.  If you want to create your own monitoring program, you can find a sample program at the IBM Information Center.  Just search on your version of the i/OS for “QSYSMSG”.

To get a better idea of what kind of messages you can expect to intercept using the QSYSMSG message queue, here is a partial list of these important messages.  As you can see, many of these messages are security related, including devices that have been varied off-line because of illegal sign-on attempts, and call for a quick response:

Message ID    Description
CPD4070    Negative response received for remote location &5, device description &4.
CPF0907    Serious storage condition may exist.
CPF1269    Program start request received on communications device was rejected with reason codes.
CPF1393    User profile has been disabled because maximum number of sign-on attempts has been reached.
CPF1397    Subsystem varied off workstation.
CPF5244    Internal system failure for remote location &5, device description &4.
CPF5251    Password or user ID not valid for request for remote location &5.
CPF8AC4    Reserved library name &7 in use.
CPF9E7C    i5/OS grace period expired.
CPI091F    PWRDWNSYS &1 command in progress.
CPI0948    Mirrored protection is suspended on disk unit &1
CPI0953    ASP storage threshold reached.
CPI0954    ASP storage limit exceeded.
CPI0955    System ASP unprotected storage limit exceeded.
CPI0964    Weak battery condition exists.
CPI0965    Failure of battery power unit feature in system unit.
CPI0966    Failure of battery power unit feature in expansion unit.
CPI0970    Disk unit &1 not operating
CPI0998    Error occurred on disk unit &1
CPI0999    Storage directory threshold reached.
CPI1117    Damaged job schedule &1 in library &2 deleted.
CPI1136    Mirrored protection still suspended.
CPI1138    Storage overflow recovered.
CPI1139    Storage overflow recovery failed.

And there are many, many more critical situations that can be monitored using this method.  Since it is so easy to loose these messages in the QSYSOPR message queue, setting up the QSYSMSG message queue and then monitoring it programmatically is a good practice for all IBM i shops.

Adopted Authority Basics

By Rich Loeber

On your IBM i, every object is owned by a user profile, even if it is just a system default owner profile.  As objects are created, the ownership is established by the person who creates the object.  When new objects are added to your system that were created on a different system, such as third party software or objects restored to your system from another IBM i, the ownership that was in effect on the other system is carried over onto your system.

Program objects have a unique aspect of ownership that many programmers and users of IBM’s i/OS may not be aware of.  There is a setting in each *PGM object on your system that controls authority checking whenever that *PGM object is executed.  This is controlled by the USRPRF parameter when the program is compiled.  For existing programs, it can be changed by the CHGPGM command.

The default setting for the various compilation commands in i/OS, as shipped from the factory, sets the USRPRF parameter to the value “*USER”.  This means that when that program runs, the security settings are checked according to the user profile in effect for the user who actually runs the program.  This is the intuitive setting that you would normally want to have in effect.  When a user runs a program, you only want them to have access to objects on your system that they are authorized to work with.  If they run a program that they are not supposed to be using; one that accesses objects they are not authorized for, then you want the OS security to kick in an prevent the object access.  As long as your programs are set to *USER for the USRPRF parameter, then this is exactly what will happen.

The alternate setting for the USRPRF parameter in programs is *OWNER.  When this is specified, then the program is said to “adopt” the security settings for the user profile that owns the *PGM object (regardless of who is running the program).  So, using this method, someone with fairly limited security authorization can run a program and access objects that they are not normally cleared for.  A good example of when this is desirable would be with a payroll application where a clerk is cleared for file maintenance under program control but you don’t want them to have access to the payroll files for any other purposes.  By having the maintenance program adopt the authority of the program owner, you can accomplish this with ease.

So, what’s the problem then with adopted authority?

The problem is that it can be misused and, under certain circumstances, open your system to abuse.  Because of this, you need to know which programs on your system use adopted authority and then check those programs to make sure that they are well behaved and don’t break any of the generally accepted rules for programs of this type.

As an example, having a program that uses adopted authority which is owned by a user profile with *ALLOBJ authority could lead to a security exposure.  If that program contained an option to display an open command line, then the user could gain access to your entire system.  When reviewing this situation, it is important to remember that not only can security authority be adopted, it can also be inherited.  This happens when a program with adopted authority is run and then calls another program deeper in the program stack.  That called program will inherit the adopted authority of the program that called it from higher up in the program call stack.  This inheriting feature is only in effect for a single call level.  If your called program then, in turn, calls a third program, then the inherit feature is no longer in effect.

IBM’s i/OS contains a reporting feature that will allow you to review programs that adopt authority so you can see where your possible exposures may lie.  The Print Adopting Objects  (PRTADPOBJ) command will let you review this on-line or via a printed report.  It is run by user profile and, at a minimum, you should take a look at all of your user profiles that have *ALLOBJ authority.

This just scratches the surface of the issues associated with programs that adopt their owner’s authority.  For additional research, take a long look at the IBM i Security Manual.  It will show you ways to limit the use of adopted authority and provide additional insights into the issues presented.

More Control over User Profiles

By Rich Loeber

No matter how good your office procedures are for setting up, enabling, disabling and removing users from your system, there is always room for error.  There is nothing like a quick check of your user profile base to help keep your user profiles in good order.  The user profile is a key that lets people into your system and keeping the keys in order is, or should be, a primary obligation of your security controls.

For many of us who have been doing this for a while, the quick review takes the form of a session with the WRKUSRPRF command using the *ALL option.  But, this is a tedious process at best and you can easily miss something important this way.  The ideal would be to get the user profile information organized into various views to focus in on the myriad aspects of security that exist in today’s IBM i world.

Fortunately, IBM’s i/OS contains a facility to help you with this.  The command “Print User Profile” (PRTUSRPRF) has the ability to generate up to four different format reports that will organize your user profile information base to give you a good overview.  The report information for the four different reports concentrate on:

  • Authority type information
  • Environment type information
  • Password type information
  • Password level type information (V5R1 and higher only)

The command has up to four parameters to control the information presented on the listings.  Some of these parameters are context sensitive and will not always be prompted depending on other values you enter.  In addition to indicating which of the four report formats you want, you can also narrow your selection of the specific user profiles to be included, thereby letting you analyze like profiles together.  These selection options let you limit the reports to only users with specific special authority settings and users for specific user classes.  You will probably want to start by specifying all users, but if you’re in a very large shop, this may produce too much information for you to be able to focus in on.

The four reports, however, are the key to using this tool effectively.  The report on authority type information shows each selected profile along with a reference to any group profile or supplemental groups that the profile belongs to.  Then, the special authorities in effect for the user are shown along with their user class, the user profile object ownership setting and other object ownership related information.  A quick scan of this report can quickly show you users that are categorized in an incorrect group, users who are in a group that gives them more access rights than you really intend and many other options.

The report on environment type information presents a different report format.  This report focuses in on the job execution environment in place for each user profile.  These things include the current library, initial menu/library, default job description and other settings that control how jobs run by each user profile will be setup by your system.  This report lets you do a quick audit of user profiles to make sure that they are set up for just the work they should be doing and no more.

The third report produces password type information.  This report lists the current enabled/disabled status of each profile, the current number of invalid signon attempts, the last signon, when their password was last changed and more information that will help with administration of password controls.  In preparing this article, I discovered some unusual values on this report that seemed to indicate someone attempting to gain access to our test system via Telnet using the QSRV and QSYSOPR user profiles.  Both profiles were disabled and the not-valid signon attempts were at the maximum.  Since nobody uses these profiles in our shop, I can only conclude that an illegal signon attempt was made for both of these.  Fortunately, it appears that these attempts failed since we do not have the default passwords still active for any of the IBM supplied ‘Q’ user profiles.  Using this report, you can perform a very quick scan of the setup for each user and quickly spot anomalies, like I did.

The fourth report prints a report on password level type information.  Under the more recent versions of i/OS, you can optionally use longer passwords (up to 128 bytes long) and you can specify a controlled switch over from one setup to another.  This fourth report supplies you with information on how this extended password level is configured for each user on your system.  You can see additional information about this on the system value QPWDLVL and by using the DSPSECA command on these systems.

These four reports, and their various mutations when you use the filtering options, will give you a good tool in keeping current on the status of the user profile pool on your system.  A monthly review of the first three reports would be in order and you can simplify this by just loading these commands into your system job scheduler to automatically run on a monthly basis.

Getting Control over User Profiles

By Rich Loeber

Every IBM i shop has the potential to have active user profiles on the system for users who have left the company.  Unless your personnel department is extra careful about global notifications when people leave, then you may have a security exposure that you don’t even know about.

You can, if you’re careful about setting up user profiles, take care of this problem when new profiles are created.  The “Password expiration interval” (PWDEXPITV) parameter on the Create User Profile (CRTUSRPRF) command lets you set up a separate expiration day interval for each user.  On a system-wide basis, you can also enforce a default expiration interval with the system value QPWDEXPITV.  Using the system value, you just have to use the default *SYSVAL setting for the PWDEXPITV parameter for each user profile.  I suspect that a lot of shops use this arrangement.

However, in every shop, there are users who have passwords that are set to never expire.  This is not recommended, but may make sense for some people who can closely guard their password and use the system heavily.  (I know many programmers and system operators who enjoy this luxury.)  For these people, simply relying on the password expiration interval won’t work, leaving you an even more serious exposure since the type of people who want permanent passwords also tend to have broad access to your system.

The good news is that IBM’s i/OS contains a way for you to enforce periodic expiration on user profiles that have not been used for a specified period of time.  There are several i/OS commands that will help you to enforce a policy of automatically forcing unused profiles to inactive status by disabling them.

The “Analyze Profile Activity” (ANZPRFACT) command will let you set up and control the number of days that the system should use to check for unused profiles.  Then, after this has been set, the system will scan the active profiles on your system once per day and disable those that have not been used for the specific period of time.  Before you start to use this, however, be sure to read on.  (Note, you can disable this check by running this command again and changing the setting to *NOMAX.)

The “Display Active Profile List” (DSPACTPRFL) command will let you display a list of specific profiles that the ANZPRFACT command will ignore when it is checking for unused profile activity.  These might be certain profiles that own object code on your system but are not actually used for signon purposes.  Some applications may require that these owner profiles remain active on your system.  This may be particularly true of third party software.

The “Change Active Profile List” (CHGACTPRFL) command lets you modify this list of profiles on your system.  You can use this command to add or remove entries from the list.  It is important to note that most Q profiles (IBM profiles) are automatically excluded from ANZPRFACT processing.  If you prompt the ANZPRFACT  command and use the HELP facility, you can access a quick list of the Q profiles that are excluded.

It is important for you to check the list (DSPACTPRFL) and update the list (CHGACTPRFL) before any regularly scheduled analysis processing takes place.  This will make sure that you don’t shoot yourself in the foot by disabling a user profile that needs to remain active.  If you use third party software on your system, check with each developer to find out if their ownership profile needs to remain enabled on your system.  Some third party software won’t care of the profile is disabled, but it is important to get the developer’s blessing before taking this step.  If you do have an owner profile that needs to remain enabled, you can always prevent user logon attempts by changing the password to *NONE.

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:

WRKDEVD DEVD(*VRTDSP)

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.