Controlling Access to Spool Files

By Rich Loeber

A nice feature of the IBM i OS lets you view the contents of spool files before they have been printed or distributed electronically.  For a lot of users, this saves time and paper and provides a lot of convenience.  But, not all spool files should be able to be viewed by every user.  This tip will take a look at some ways to control who is allowed to see which spool files on your system.

Print spool files are special objects on your system that are stored in the QSPL library.  You cannot control access at the spool file level on your IBM i system.  Access to the spool files must be controlled through the output queue that is associated with each spool file.

If you have sensitive or confidential information that is being stored in a print spool file, the best way to secure it is to create a special output queue (or set of output queues) that are secure to a known set of users.  To direct the spool file into the right output queue can sometimes be tricky.  IBM i generally checks the following sequence of things to direct the output from a job:

  • the printer file
  • job attributes
  • user profile
  • workstation device description
  • system print device (QPRTDEV) system value

To direct your sensitive output to the right output queue, your best bet is to specify it in the printer file being used by your application.

Output queues can be created in any library on your system.  Output queues for printer devices generally get created in the QUSRSYS library, but you are not limited by that.  To improve security, create your secure output queue in a separate library that has limited access at the library level.

Once the output queue has been created, you can then limit access to it using the Grant Object Authority (GRTOBJAUT) command and Edit Object Authority (EDTOBJAUT) command.  To specifically limit general access to the output queue, the PUBLIC setting for the *OUTQ object must be set to *EXCLUDE.  Then, in the individual user authorities, you can provide for access for specific user profiles or (better yet) group profiles.

You should also note that user profiles with the special authority of *SPLCTL will be able to view and work with spool files regardless of their access control limitations to your secure output queue.  This is a form of all object authority, but only applied to spool files.  You should limit the number of profiles on your system that have the *SPLCTL authority in order to maintain the security of your sensitive output queues.

There is also a special setting on the output queue called the “Display Data” (DSPDTA) parameter that can be used to control viewing spool files.  When you set this to *NO, then only the spool file owner profile can view the contents of the spool files in the output queue.  You can check the value of this parameter using the Work with Output Queue Description (WRKOUTQD) command to see how it is set up for your secure output queue.

There are some other intricacies that are covered in the IBM i security manual.

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

Command Line Security – Part 2

By Rich Loeber

Last time, in part one of this two part series, we talked about limiting access to the use of the IBM i OS command line.  For some installations, however, you may have some good business reasons for providing command line access.  In part two, we’ll take a look at how you can restrict access to specific commands in IBM i OS.

Every command in the OS exists as an object on the system with object type *CMD.  The best way to control access to use of the commands is through IBM i  object security.  Command objects can exist in any library.  The OS commands are generally all found in the QSYS library.  Command objects can be part of the IBM i OS and they can also be part of application programs installed on your system either from your own homegrown applications or from software providers other than IBM.

Most OS commands are shipped from IBM with the public authority set to *USE.  This means that anyone on your system can run any command.  To restrict a command, change the public authority to *EXCLUDE.  When you make this change, then only users with all object authority (generally a no-no in a security conscious installation) will be able to run the command.  Then, using either an authorization list or by granting specific user profile access, you can control who can run the command.

For example, suppose that you decide that you want to restrict the use of the Work with Output Queue (WRKOUTQ) command.  This is one of the commands that is shipped with public authority of *USE.  To change the public authority to *EXCLUDE, run the following Grant Object Authority (GRTOBJAUT) command:

GRTOBJAUT OBJ(QSYS/WRKOUTQ) OBJTYPE(*CMD) USER(*PUBLIC) AUT(*EXCLUDE)

Now, if you have a set of users that you specifically want to allow access to the command, you can grant them individual access using the following command format:

GRTOBJAUT OBJ(QSYS/WRKOUTQ) OBJTYPE(*CMD) USER(MYPROFILE) AUT(*USE)

The USER parameter can point to a specific user profile or to a group profile.  If you have implemented group profile security, this is the better way to approach this issue.

When setting up command security using this method, you can use wildcard characters for the object name in the Grant Object Authority command.  Using this method, you can update the public and private authority for many related commands all at the same time.  The IBM i OS Security Guide suggests controlling all of the commands that change device configurations as an example.  Using that example, the following command would do the trick:

GRTOBJAUT OBJ(QSYS/CHGDEV*) OBJTYPE(*CMD) USER(*PUBLIC) AUT(*EXCLUDE)

Your best approach is still to limit user’s ability to run commands directly from the command line.  But, if you absolutely have to allow it, then make sure that an inquisitive users doesn’t accidentally (or purposefully) run a command that you don’t want them running.

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

 

Command Line Security – Part 1

By Rich Loeber

When a user on your IBM i system signs on to a terminal session, they will be presented with a command line.  Given enough security permissions, a user can do just about anything from that command line, if they are inquisitive enough.  This article will discuss several options for controlling what a user can, and more importantly what they cannot do, when they are presented with a command line.

Controlling use of the command line begins with the way your user profile is set up.  Specifically, the option to “Limit capabilities” (LMTCPB).  This will define what, if any, controls the system will impose over use of the command line.  Unfortunately, many systems just use the default “*NO” setting for this value and that leaves the command line wide open for use (and abuse).

There are three possibilities for the LMTCPB parameter in the user profile:

 

  • *NO – means there are NO limits on the user of the command line.  In addition to processing commands from the command line, the user can also make certain changes to their user profile that you might not want them making.
  • *PARTIAL – this is a little better than the *NO option and it limits certain actions that the user can take at signon and from the command line, but they can still run commands.
  • *YES – this is the best option for most of your users.  The user cannot specify different parameters for menu and library from the signon screen and they cannot change the setup for their user profile.  The user also is not permitted to run any IBM i OS commands from the command line.

“But,” your user says, “I need to be able to check my output reports using the WRKSPLF or WRKOUTQ command!”  This is a common issue in some shops, but setting the LMTCPB for the user profile to *NO or *PARTIAL is not the answer.  If a user needs to use a very limited set of IBM i OS commands, the best way to solve that issue is by creating menu options for them to use.  They can continue to run the commands from the menu option with no problem.

One thing to also be careful about is the starting menu that you present to your user.  Again, the default that comes from IBM is to give your users access to the IBM i OS “MAIN” menu in QSYS.  This menu can easily lead an inquisitive user to options and capabilities that you probably don’t want them seeing or using.  If you follow the menu options, you can easily get into areas where a user just does not belong.  So, make sure that you specify a starting menu that strictly limits where the user can go.  Spend some time testing your menu structures to make sure that they do not lead a user to capabilities that they should not be granted.

Next time around, in Part 2 of this article, I’ll take a look at how to effectively limit how users use of commands in the IBM i OS when you absolutely have to let users have access to the command line.

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

Changing Your Signon Screen – A Good Idea

By Rich Loeber

The classic IBM i signon screen has been around since forever.  I first saw it in 1988 when I took delivery of my first AS/400 system, a lowly B10.  In the old days, the appearance of the signon screen made no difference since the system was a closed system.  With the advent of networks, this situation changed dramatically.

Today, all IBM i systems are networked and users connect via that network connection.  The signon screen is projected to terminal emulation software throughout the network and even over the Internet for users that are accessing the system from remote locations.  Because of this, the signon screen standard context can be easily recognized by people with malicious intent and scrubbed (sniffed) for user id and password information.

Granted, for many users, this information is encrypted.  But, with the proliferation of open access protocols, there are many emulators that do not encrypt this information.  Examples of this are hand-held devices (tablets and phones) and the Telnet capabilities of Windows platforms.  For my own system, I access it when traveling via my Android smartphone and no encryption is taking place.

A second reason is that the classic signon screen presents a field that could provide a saavy user with a way to bypass your intended signon process sequence.  Next time you sign on using this screen, just type QCMD in the “Program/procedure” field and you will get a demonstration of what I mean.

For these reasons, it is probably a good idea to design your own signon screen and that you change the standard terminology used to identify the User and Password fields and disallowing the “Program/procedure” field.  Making the change is fairly easy, but you need to be careful and you need to test your new screen before rolling it out for general use.

IBM ships the source code for the standard signon screen in a source physical file named QAWTSSRC in library QSYS.  In this source file, you will find two sets of code for the two possible standard screens on your system, QDSIGNON and QDSIGNON2.  The first is used when you have standard 10 character passwords configured and the latter is used when you have set your system up for long (128 character) passwords/pass-phrases.  I recommend that you move the source that you want to use into a separate library, thereby preserving the original source in case you get in trouble.

Once you have the source moved into your own library, you can then use Screen Design Aid (SDA, PDM option #17) to make your changes.  When working on your screen, make sure that you observe the following:

  • Do not delete any of the input capable fields that are on the signon screen.
  • Do not change the sequence of any of the input capable fields.  You can move them around on the screen, but keep their sequence in tact.
  • Do not change the characteristics, especially field lengths, for any of the input capable fields.
  • Do not attempt to use any DDS HELP capabilities for the signon screen.

Since one objective is to change the reference to “User” and “Password”, pick out suitable replacements for these and make sure to change the text for those areas.  I would suggest alternatives here, but that could just start a new default standard which would defeat the objective of this tip.

The second objective can be accomplished by removing the text field for the “Program/procedure” field and then changing the PROGRAM field so that it is non-display.  This will keep the integrity of the signon screen while preventing this field from being used.

When you are all done, compile the screen into a library other than QSYS.  To implement the new screen, you will need to update the subsystem description.  You can use the Change Subsystem Description (CHGSBSD) command; press the F10 key to display all parameters and you’ll find one that controls the signon screen in use.  Test your new screen in the QPGMR subsystem to make sure it works as desired before rolling it out to QINTER and other production subsystems.  I strongly recommend that you NOT use an alternate signon screen for your system console which is typically associated with the QCTL subsystem.

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

Security and Performance Issues

By Rich Loeber

Normally, you would not think of system performance in terms of a security issue.  But, if someone with the right know-how is abusing privileges on your system, then it becomes a security issue.  This tip will help you to identify some performance issues that fall into this category.

A performance issue that has security implications can happen when someone with the right special authorities on their user profile abuses those and consumes excessive system resource in their own interest.  This can happen, for example, when programmers boost the execution priority for their jobs at the expense of interactive processing.  It can also happen when someone runs a batch job interactively, thereby bringing other interactive users to a crawl.  When this occurs, it is clearly a security issue as the user or users in question are abusing their assigned privileges.

Controlling the execution priority of a job is a function of the Job Priority.  This is set by the Job Description that is used for the job.  It can also be changed on the fly by someone with *JOBCTL special authority associated with their user profile.  If you see this happening, you might want to just remove *JOBCTL from their user profile.  Restricting access to the CHGJOB command can also help.  The CHGJOB command is shipped from IBM with public access set to *USE, so any user profile can use the command.  Restricting access could affect applications running on your system, so you should consider this change carefully.

To restrict access to the CHGJOB command, run the following command on your system:

GRTOBJAUT OBJ(CHGJOB) OBJTYPE(*CMD) USER(*PUBLIC)
AUT(*EXCLUDE)

This will change the command so that only authorized user profiles can use it.  To add a user profile to those allowed access to this command, use the following command:

GRTOBJAUT OBJ(CHGJOB) OBJTYPE(*CMD) USER(MYUSRPRF)
AUT(*USE)

This will allow the profile MYUSRPRF to use this command while excluding all others.  Of course, any user profile with All Object Authority (*ALLOBJ) will still have access, so that wrinkle also has to be allowed for.

Limiting access to command objects on your system is a good way to control who can do what.  Another command that you should consider for similar treatment is the Change Shared Storage Pool (CHGSHRPOOL) command.  This command can be used to control performance characteristics for jobs running on your system through the allocation of memory resources and processing time slices.

If you still have problems with performance issues preventing production from getting done efficiently, there may be a problem of users running batch jobs interactively.  If your applications are running from IBM i OS commands, you can change the commands so that they will not function when called in an interactive environment.  You can do this using the Change Command (CHGCMD) command, setting the ALLOW parameter to remove the *INTERACT, *IPGM and *REXX options.

If you make changes to any IBM i OS commands, you should keep a list of the commands changed and the specific changes made.  Installing PTFs or OS upgrades from IBM could change them back, so you should keep your list with your IBM i OS documentation to serve as a reminder to check the commands following a PTF install or OS upgrade.

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

Annual Checkup

By Rich Loeber

A few years ago, when I passed the age when I thought I might live forever and started maturing (a little), I decided that it would be a good idea to go see my doctor once a year for an annual checkup.  It was paid for by insurance and there was just no good reason not to go.  That first checkup (after many years of neglect, I might add) turned out OK.  The doctor told me a few things that I already knew (loose weight, get more exercise) and generally thought that I was doing OK.

After that first checkup, I got the annual appointment into my schedule and started going faithfully.  Then, after we moved up to the mountains of Northern New York, the doctor at our new home came back with a different response to my checkup.  He saw some things that didn’t look right and wanted to schedule some additional tests.  To make a long story short, he found a blocked cardiac artery and we were able to deal with it well before the onset of a heart attack.

What, you ask, does this have to do with computer security on your IBM i system?  Just this …. you need to do a full system checkup at least once a year just to see if there are any surprises.  I have done dozens of these checkups over the years on systems under my responsibility and I ALWAYS find something that needs attention.  If you’re responsible for system security, you need to do this, and year end is a good time to be thinking about it.  Nobody gets much work done during the last couple of weeks of the year and it’s a good time to go tinkering around in your system.

So, what should you include in your checkup?  Here’s a list of things to start with.  It is by no means comprehensive but will probably get you started and lead you into the areas where you need to be concerned:

●    Check the security settings in your system values using the Print System Security Attributes [PRTSYSSECA] command and reconcile differences on your system from the recommended settings.
●    List the user profiles on your system and check for employees who have left or changed their job assignment.
●    Create a database of your user profiles using the DSPUSRPRF command with the *OUTFILE option, then run a series of query reports to search for expired passwords, profiles with *ALLOBJ authority, and so on as appropriate for your installation.
●    Run the Security Wizard in the IBM i  Navigator (Or Access Client Solutsion) and check any differences on your system from the recommendations suggested.
●    Using the user profile database already created, list your user profiles by group to make sure that the groups are set up as you expect to see them.
●    Create a database of all *FILE objects on your system using the DSPOBJD command with the *OUTFILE option.  Then generate a report using your favorite query tool of new files created since your last audit and make sure that security on these new objects complies with established policies.
●    Run the Analyze Default Passwords [ANZDFTPWD] command to make sure that no default passwords exist on your system.
●    Check *FILE objects on your system with *PUBLIC access authority using the Print Publicly Auth Objects [PRTPUBAUT] command.  Make sure that the objects with public access all comply with established policies.
●    Go to the SECTOOLS menu and see if any of the options available can be of specific help to your audit efforts.
●    Review your backup process and offsite storage arrangements.  Do a physical inspection of the offsite location and make sure you can quickly and easily identify and retrieve backup sets.

Due to space constraints, this is not a comprehensive list but is intended to get you started on the audit process.  As you go through it, document both what you are doing and your findings.  That way, when next year end rolls around, you’ll be better prepared for the process and you’ll have a baseline to compare your results with.  Good luck, and I hope you don’t find any clogged arteries!

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

Anatomy of an IBM i Hack Attempt

By Rich Loeber

Kisco Information Systems keeps a lone IBM i server connected directly to the Internet in order to test it’s SafeNet/i exit point security software in a real world environment. In the past, we have reported on our experience with quarterly reports in 2013 and even an update earlier this year in March 2017.

Last month we experienced an unusual and persistent hack attempt that surprised us by its depth and the amount of time that was used.  This blog post is to report on what happened and, perhaps, remind everyone about how important it is to take hacking seriously in this day and age.

Starting at 20:30 on October 20, 2017 someone from IP address 79.137.65.236 began a persistent FTP script attack on our server.  This happened on a Saturday evening when nobody was in the office to notice any unusual network traffic. The attack consisted of signon attempts via the FTP server using a very long series of profile names.  The signon attempts were repeated every few seconds.

The script being used called for each of the hack attempts to be repeated 85 times with the same user profile.  We don’t capture the passwords being used, but it is obvious that each attempt was trying to use a different password.  In our case, since our SafeNet/i did not recognize the IP address that was being used as a valid client address, the IBM i OS never got to the point of password validation and subsequent deactivation of the profile by the OS.

The user profiles used during this hack attempt were mostly comprised of common English first names such as ANDREA, BARBARA, KIM, ROBERT and so on.  There were also a few coomon Hispanic names used such as JUAN and FERNANDO.  Other profiles were also used and some of them got special attention with additional signon attempts.  The profile name ADMINISTRA was used 255 times (85 three times?).  Other common profiles that deserved extra attention included ADMIN, INFO, SPAM, “NULL” and, for some reason, BARBARA, all of which were attempted 170 times (85 twice?).

In addition to these common profile names, quite a few other “common” technical terms were  used, each for its own series of 85 tries.  These included profile names like ABACUS, ACCESS, ACCOUNT, ADMIN, APPLE, BACKUP, DEMO, GARAGE, MAIL, MAILSCANNE, ORANGE, NETGEAR1, PASSWORD, PAYMENTS, POSTMASTER, QWERTY, QWERASDF, SALES, SCANNER, TEMP, TEST, USER, WEB, WEBMASTER, WELCOME,123 and SYSADMIN.

The hack came to an end on Sunday morning when I received an email from SafeNet/i advising  me that thousands of break in attempts had been made.  When I checked the system I found that it was still going on and simply turned the FTP server off.  Nobody needed FTP on a Sunday morning.  I restarted the FTP server about an hour later, but the hack did not resume.

After the hack was done, I did a lookup using the IP address that was used and it traced back to the RIPE Network Coordination Center in The Netherlands.  A few days later we reported the abuse attempt to them.  Shortly after reporting it, we received a standard reply email that was un-formatted and very difficult to read.  We went to the RIPE website and there was a place to trace the IP address within their organization and it traced back to an organization in France.  An abuse report submitted to them has not been answered as of yet.  Based on past experience, trying to trace back an abuser is a rabbit hole that you can rarely get out of.  In the past, we have tried reporting hack attempts to the local police, state police and the FBI, always to no avail.

There are some take away things to think about from just this one hack attempt.  You should consider the following:

  • Review your user profiles and look for common English first names.  Consider changing them to something more complex.
  • Stay away from common technical terms, and even some uncommon ones, for user profile use.
  • Don’t run the FTP server when it isn’t needed.  The FTP script hack is the one used most frequently.  If the server isn’t active, it can’t be hacked.
  • Make sure that you have exit point software installed and active to control which IP addresses are allowed to connect to your system.  Our SafeNet/i does this and successfully fended of this entire hacking scenario on our box.

The whole point of the FTP hack is to discover working user profiles and, hopefully, also uncover one that is using a very common password.  Once a hacker has this, they are ready to come back via Telnet or some other server connection and really get into your system.  You need to be prepared to stop them before that can happen.

If you have questions about details of the report, feel free to contact me directly by email (rich at kisco.com).

Watch Your User Profiles

By Rich Loeber

Once you’ve set up a user profile on your IBM i systems, are you tracking changes to it over it’s lifetime?

The user profile is your first line of defense in the ongoing battle of protecting your system.  When a new employee shows up for work, you go to great lengths to get their profile set up just right.  You make sure that they get access to the menus and files they need to get their work done and you set up their object access accordingly.  If you’ve been at this a while, you probably already have a mental checklist of all the things that you need to do for a new user in each department or work group in your shop.

But, what about subsequent changes to those profiles.  Are you watching these updates to make sure that your carefully engineered security scheme is being maintained over the life of each user profile?

In the IBM i OS, there are a couple of ways that you can monitor for this.

First, you can use the system security audit journal as an after-the-fact review process for user profile changes and updates.  To run this report, use the Display Audit Journal Entries (DSPAUDJRNE) command.  Prompt the command using the F4 key and select the entry type code CP (Change user profile entries).  The resulting report will show you at least some of the user profile change activity for the selected period of time on your system.

If you want more immediate information about user profile changes, then the only alternative is for you to code an exit program.  There are four possible exit points that you can use on the system to track user profile activity:

QIBM_QSY_CRT_PROFILE    Create User Profile
QIBM_QSY_CHG_PROFILE    Change User Profile
QIBM_QSY_DLT_PROFILE    Delete User Profile (2 points, one before the other after)
QIBM_QSY_RST_PROFILE    Restore User Profile

An exit point is a marker in the IBM i OS where you can attach your own program.  The OS will call your program, passing parameters, during the process of working with these user profile events.  You can code your program do meet your very specific needs.  This can include on-line notification, detailed change tracking, rules enforcement and more.  You can even pass a return code back to the exit point indicating that the profile change should be disallowed.

Your will find more details about creating exit programs to work with these user profile exit points in the IBM i Security Reference manual.  Registering your program can be done using the Work With Registration Information (WRKREGINF) command.  You will see many exit points displayed, be sure to limit your changes to the specific exits named above.

If you don’t want to code your own solution, there is an audit reporting feature built into Kisco’s iEventMonitor software that can be used for near real time reporting of profile change events.  It is available for a free trial if you’d like to find out if would be helpful in your situation.

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

Tracking Use On Critical Files/Objects

By Rich Loeber

Most shops have at least one, and probably more than one, mission critical information assets stored on the IBM i system.  If you’re doing your job as security officer, that asset is locked up tight to make sure that only authorized user profiles can get to it.  But, do you know for a fact who is actually accessing that critical data?

Here is one way that you can review who is reading and even who is changing data on an individual object-by-object basis on your system.  That is by using object auditing, a built-in feature of the IBM i OS.

For starters, you have to have to have Security Auditing active on your system.  You can do a quick double check for this using the Display Security Auditing (DSPSECAUD) command.  If security auditing is not active, you will need to get it up and active on your system.  That is a process for a different tip.  If you need help getting this started, send me an email (see below).

With security auditing active, you can set up access tracking on an object-by-object basis using the Change Object Auditing (CHGOBJAUD) command.  Depending on what you’re objective is, you can set the OBJAUD parameter to a number of values.  Check the HELP text for more information.  If you want to check everything, just set it to *ALL.  If you are only tracking usage for a limited time period, be sure to change this value back to *NONE when you’re finished as this will reduce some system overhead.

Once object auditing has been activated, the system will start adding entries to the system audit journal whenever any activity happens on the object you have activated.

To view the journal information, you use the Display Audit Journal Entries (DSPAUDJRNE) command.  The first parameter, ENTTYP, selects the specific information that you want to see.  Setting this value to ‘ZC’ will produce a listing of all of the times that the tracked object was changed.  If any applications are deleting the object, using the report for value ‘DO’ will report those happenings.  Using the value of ‘ZR’ will produce a larger listing showing all of the times that the tracked object was read.  Depending on how your object is used, you might find that the ZR report is just too huge without filtering it down …. read on.

The generated reports are simple Query listings.  The reports are generated from a file that the DSPAUDJRNE command creates in your QTEMP library.  The database file is named QASYxxJ4 where “xx” is the value you used on the ENTTYP parameter.  Once this database file has been created, you can use it to generate your own reports.  This way, you can slice and dice the data for your own unique needs.  For example, if you are looking for specific user profiles, you can add that as a selection criteria.  Or, if you want to analyze access by time-of-day or day-of-the-week, you can do that too.  The possibilities are quite open at this point.

I set this up on my test system to track accesses to an obscure data area that I was quite sure is only rarely used.  I set the tracking and left it for a few hours, then went back to it.  Even on this test system, I was surprised by the number of times the data area was used, and I’m the only user on the system!  Who knows what surprises you will turn up.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Terminal Session Security

By Rich Loeber

Like all modern systems, the IBM i requires a user profile and password before you can log on and use the system.  You might think that this simple requirement would always ensure that only authorized users will have access to your system.  But, with the proliferation of devices that can connect to the system, it is not always that simple.

In the old days, we used to have devices that are now called “dumb terminals”.  To use the system, you’d log on to the sign on screen and when you were done, you’d log off.  You could tell by looking at the screen whether the session was active or not.  If the signon screen was displayed, then the session was inactive.

Today, with a proliferation of PCs, tablets and cell phones and with easy access to Telnet based terminal emulation software, it is not always that clear.  On a PC using IBM i Access, the first time you log into the system for the day, there is an IBM i Access logon that establishes connection from the PC to your host system.  Then, there may or may not be another logon for your terminal session.  If you have your PC set up to bypass terminal sign on to the host, then there will be no second signon process.  Once your connection to the host system has been established, the only way to break it is to either log off from Windows altogether or reboot your system.

There are a couple of potential problems with this configuration.  It makes working with your system a lot easier just like leaving the keys in your car makes getting going a lot easier, but you wouldn’t want to do it on a regular basis.

If you are using bypass signon, once your initial connection has been established, anyone can come by and start up your terminal emulation session and gain access to your system without knowing either your user profile or your password.  If you’re a programmer or a systems administrator, that could be a significant exposure to your system as you will probably have very generous access rights to objects on your system.  If your PC is located in a public or semi-public setting, you should think twice about having this setup.

Another exposure, which can happen when you leave a terminal session active, is that anyone can come along and use the Client Access upload or download functions to gain access to your system, again without knowing your user profile or password.  If you have any virtual drives mapped to your host, those could also be compromised by someone using your PC without your knowledge or approval.

One simple solution is to activate your PC’s screen saver with a password requirement to unlock the keyboard when it goes into screen saver mode.  That way, if you go for coffee and get delayed by a dumb question from the boss, the screen saver will kick in and protect your system in your absence.  The problem comes from user systems that you, as security officer, are responsible.  Each user can probably reset their screen saver settings on their own, thereby defeating this important additional security measure.  A periodic inspection of all PCs installed in public and semi-public settings for these exposures would probably be a good idea.

Most terminal emulation software for use on tablets allow you to build in a macro for the signon process.  So, anyone picking up your tablet, might be able to establish a connection to your system.  If tablets are available in public areas, then disabling the signon macro function would be a good idea.

If you have questions about details of the report, feel free to contact me directly by email (rich at kisco.com).