Who’s Connected to your IBM i?

By Rich Loeber

Have you ever wondered who is connected to your system with a network connection? In these days of interconnected systems, this should be a concern for all IBM i security officers. Even if you have fully deployed firewalls and exit point security, the answer to the above question might contain some surprises.

The good news is that the IBM i OS has an interactive utility that can answer this question for you simply and easily.

If you are comfortable with the 5250 terminal interface, just run the following command:

NETSTAT OPTION(*CNN)

A display will come up that shows all of the IP4 TCP/IP connections to your system that are currently active. Page down several panels until you see an IP address showing up in the left hand “Remote Address” column.

Scroll around and check to see if there are any IP addresses that you don’t recognize. If you see any for 127.0.0.1, these are probably tied to your use of IBM Navigator for i. The listing under the “Remote Port” and “Local Port” column will give you an idea of what the connection is doing on your system.

If you are more comfortable with using IBM’s Navigator for i interface, start the utility and select “Network”, “TCP/IP Configuration”, “IPv4″ and finally “IPv4 Connections” to get the same information as the NETSTAT command above. This interface has the added bonus of allowing you to generate listings or a CSV download version of what you are looking at.

If you see an IP address that you are not familiar with, both interfaces give you the option of stopping the connection. On our test system, I often like to look up the IP address to see who “owns” it. There are several options for tracing an IP address; one such is:

https://www.iplocation.net

In the above case, the IP address listed at 35.165.168.89 traces back to an Amazon server. That’s not much help in zeroing in on an individual, but it lets you know what might be going on. In the case of our server, this does not concern us as the SMTP server is locked up tight.

If you find connections that are suspicious, it is imperative that they be investigated. Check your exit point implementation to make sure that you have source IP address controls in place. Connection attempts will show up with the NETSTAT command before they are denied by your exit point implementation. If your exit point does not give you source IP address controls or you don’t have exit points implemented yet, consider Kisco’s SafeNet/i – http://www.kisco.com/safenet – to implement them.

Kisco’s iEventMonitor software – http://www.kisco.com/iem – can be configured to issue alerts when unfamiliar IP addresses are detected. It lets you define the IP addresses that you trust and any others that connect will result in an alert being issued. It even offers you an exit point so that you can take your own actions when an untrusted IP address is detected. We have implemented our own user exit program to terminate unknown IP address connections using the ENDTCPCNN command.

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

IBM i SMTP Relay Controls

By Rich Loeber

Updated March 4, 2021

Many IBM i shops keep the SMTP server active on their system to support host-based applications that format and send e-mail messages directly from their IBM i system.  With the SMTP server active, you could leave your system open to spammers who could take over the SMTP server to relay their spam messages.  This tip describes how to control SMTP relay on your system.  You can check to see if SMTP is active on your system by running the following command:

WRKACTJOB SBS(QSYSWRK) JOB(QTSM*)

If there are any tasks displayed, then the SMTP server is active on your system.

Controlling SMTP mail relay involves two processes.  First, you have to set the ALWRLY parameter in the SMTP Attributes on your SMTP server.  This is updated using the CHGSMTPA (Change SMTP Attributes) command.  Keep in mind that your user profile must have the *IOSYSCFG special authority to be able to use the CHGSMTPA command.  When you first prompt the command, press the F9 key to show all of the parameters.

If you just want to deny all mail relays, set this value to *NONE and you’re all set, you can stop reading now and move on with your life.  However, if you are sending mail from your IBM i using the SNDDST command, SNDSMTPEMM command or other program-controlled methods, you cannot leave this setting at *NONE as it will block mail being sent from your system.  Simply changing this setting to *ALL is not a good idea either as this will allow anyone to relay mail through your system.  The best choices are one of the following:

•    *LIST – only IP addresses that match an *ACCEPT SMTP list entry will be allowed or denied
•    *NEAR – only IP addresses that match a *NEAR SMTP list entry will be allowed
•    *BOTH – the system will look at both the *LIST and *NEAR entries

Once you have this part configured and have specified one of the three recommended settings, you will then have to update the SMTP list to indicate who can relay mail.  This is done using the ADDMSTPLE (Add SMTP List Entry) command.  There are a lot of options for this, but as a simple example let’s set up an entry that will permit mail to be relayed from your IBM i.  If you system has an IP address of 10.100.2.1, then you would add a relay accept transaction that looks like the following:

ADDSMTPLE TYPE(*ACCEPT) INTNETADR(‘10.100.1.2’)
SUBNETMASK(‘255.255.255.255’)

This entry will accept all SMTP mail that is sent from the specific IP address indicated in the INTNETADR parameter.  The subnet mask used here is coded so that only the specific IP address will be processed.  You can also use this command to post a *REJECT or *NEAR entry to the SMTP list to indicate specific IP addresses to be rejected or to define a system to be considered as a *NEAR system.  Varying the subnet mask can let you define ranges of IP addresses and if you need help on how to code these entries, feel free to contact me.  Once entries have been added to the SMTP list, you can delete them using the RMVSMTPLE (Remove SMTP List Entry) command.  It would be nice if IBM provided a WRKSMTPLE command too, but the test system I work on has no sign of this feature.

If you have been using SMTP list entries for a while, you may need to know what entries are already established on your system but IBM i provides no support for a review function.  You can, however, review what is already set up by examining the various members in the file named QATMADRLST in library QUSRSYS.  Each member, which you will find appropriately named, contains the list entries for that type.  A simple query report can list the entries and you can remove unwanted entries as needed.

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.

On-Line Meeting Etiquette

By Rich Loeber

I occasionally like to take this space to write about something other than IBM i security concerns and this is just such a time.  With the shelter-at-home orders in place for several weeks now, I have been having lots of meetings on-line using video conferencing tools.  My tool of choice has been Zoom, but I’m sure this can apply to any such service.

This blog entry is the result of observations of behavior during on-line meetings from people who are mostly new to the genre.  I hope that these “etiquette” tips are helpful for my readers as they get used to new ways of meeting and socializing on-line.

Lighting

Keep in mind that this is not only an audio conference call, but a video (ie: visual) conference call.  As such, your lighting is important.  A major benefit of video meetings is that you can better “read” others in the meeting because you can see them.  If the lighting for your image in the meeting is such that your face is in shadow, then the benefits are lost.  I have poor lighting in my office with a big window on one side and glaring florescent lights in the ceiling.  After some experimentation, I bought a bright LED desk lamp which I now use while turning the overhead lights off.  It produces a much better image.

One thing I’ve noticed that frequently happens is that someone sets up their camera (or laptop) so that there is a window behind them.  This invariably results with their face in shadow.  I was in a meeting of local relief organizations recently where one participant, who had a lot to say, was just a shadow on the screen for the entire meeting.  It was very frustrating.

Eating

I know you’re working from home and it is convenient to try and multi-task by having your lunch during the meeting, but I point out again that this is a visual medium.  If you were at an in-person meeting in a conference room, would you want to be the only participant having lunch while all the others sat there and watched you eat?  I doubt it.  The same is true of your virtual meeting.  For me, I think this even extends to chewing gum during the meeting.  During another meeting last month, someone actually spent part of the meeting in the kitchen cooking themselves lunch which they then proceeded to eat on camera.

Sound

Another good practice is to keep your microphone on mute when you are not talking or being called on to talk.  My office is located on a state highway.  I get big trucks rumbling by and the occasional emergency vehicle screaming past, so I stay on mute as much as possible.  If you’re working from home, it is not uncommon for a barking dog, a ringing telephone or any one of a myriad to audible interruptions to intrude that will detract from the meeting.

Attention

During the meeting, stay engaged.  If you are trying to process email or do other things during the meeting, it will show in your level of attention and participation.  Another behavior that I’ve observed is someone who spends an entire meeting propping up their head with their arm.  During that meeting, I wrote them off as bored to death and not interested in what was going on.  That may not have been true, but do you want to send that message to the others in attendance?

Rehearse

I have also been in several meetings where one or more participants had no idea what they were doing and how to control their conference session.  If you’re a host, take the time before any meetings to understand the tool that you will be using.  I can commend Zoom for the plethora of aids that they have available, including on-line orientation sessions for hosts and even meeting guests.  My solution is to have a dry run with a friend.  Take the time to understand how to turn your mic off and on.  Learn how to share content and then un-share it.  Learn the various display modes that you can use.  Get comfortable with the tool.  I was in yet another meeting recently when someone in the meeting accidentally shared their screen and then no amount of coaching them during the meeting could get the shared screen turned off.

If you have questions or comments, feel free to contact me directly by email: rich at kisco.com.

IBM i Security Concerns While You’re Working From Home

By Rich Loeber

During this time of Covid-19 crisis, most of our customers are reporting in that they are working from home and will probably be doing so for several months.  We are working independently here too where I find myself the only one in the office.

With so many people working with remote access, what are the security risks to your IBM i as a result?  If you aren’t mindful of security during this crisis, you could expose your system unnecessarily and create issues for you that will last a lot longer than the current crisis.

Here are a few that come to my mind right away ….

Telnet

If your users/programmers/system administrators are using 5250 terminal sessions to access your system, make certain that they are all using SSL for the connection.  Last month, I posted an update to a prior blog post on this topic.  If your terminal sessions are not using SSL, then your user profiles and passwords are traveling over the Internet as plain text.  Given that programmers and administrators tend to have super user profile privileges, this could be catastrophic.  In my opinion, this should be your number one concern.  http://www.kisco.com/ibm-i-security-tips/?p=312

Browser Based Applications

When you are in the office and working on browser based applications hosted on your IBM i system, you might consider yourself to be safe if you are running the application using an HTTP address.  While that may be true, when you run that same browser based application from home using HTTP, the data that transfers back and forth to your desktop environment will be sent in plain text.  Since most applications require a sign-on process, then your user profile and password are again exposed while in transit.

The solution is to update your HTTP application to use HTTPS protocols.  By making this change, the browser data streams will be encrypted, adding the necessary security that you will need.  Several years ago, I posted a tip here on how to make that change.

File Transfer Protocol (FTP)

While working in the office and hiding behind a firewall, bringing up a quick FTP session on your desktop to transfer IBM i information to/from your personal computer is a quick and easy way to get things done.  Doing that same thing while working remotely can, like telnet and the browser applications, expose your user profile and password as open text.

The solution is to change your access to use SFTP (Secure File Transfer Protocol).  The good news is that IBM i supports SFTP.  I found this article at an IBM website on how to set this up for your use.

This quick tip just scratches the surface of these issues.  These were the issues that came to mind as being highest on a list of concerns.  I would love to hear from any of my readers who have more ideas on areas where we should have serious concerns.

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

More About Controlling Access to Spool Files

By Rich Loeber

In my last tip, I talked about controlling access to spool files through implementation of IBM i OS object authority at the output queue level.  In this tip, I’ll be taking a look at three additional parameters that are associated with IBM i output queues that can extend the level of control you have over sensitive reports on your system.

The three parameters in question are:

  • Display any file (DSPAUT)
  • Operator controlled (OPRCTL)
  • Authority to check (AUTCHK)

These three work to give you more control over access to spool files beyond what is available through object level controls on the output queue.

One thing to keep in mind is the proliferation of user profiles with special authority of *SPLCTL.  This is the equivalent of the evil *ALLOBJ authority, but as applied to spool files.  You should restrict granting of *SPLCTL to only those user profiles where it is absolutely required.  As you read on in this tip, remember that if a user profile has *SPLCTL authority, then they can cut through these restrictions as they will not apply (with one exception as noted).

“Display any file” (DSPDTA) is intended to protect the contents of a spool file by setting authority requirements.  There are three values available, *YES, *NO and *OWNER.  Each of these provides progressively increased levels of authority requirements to view, copy or send spool files in the output queue. *YES allows anyone with READ authority to work with files in the output queue. *NO restricts that to the owner, those with *CHANGE authority and those with *SPLCTL special authority. *OWNER further limits this to just the owner profile and any profile with *SPLCTL authority.

“Operator controlled” (OPRCTL) controls whether or not a user with *SPLCTL special authority is allowed open access to this output queue.  The default value on the Create Output Queue (CRTOUTQ) command in the IBM i OS is *YES which is why most output queues are open season for users with *SPLCTL authority.  Changing this value to *NO will force normal object authority rules to control access to the output queue.  If you have an output queue with sensitive information stored and you are concerned about *SPLCTL users gaining access, this is the key parameter value that can save the day for you.

“Authority to check” (AUTCHK) controls how users with *CHANGE authority to the output queue will be given access to change, delete or copy spool files in the queue.  When this is set to *OWNER, only the owner profile of the spool file can change or delete spool files.  Using the value of  *DTAAUT changes this control so that it looks at object level controls for the output queue.

Using these parameters intelligently can give you much added control over how users access (or don’t access) spool files on your system.  Using them in combination can be a little confusing, but if you look in your IBM i OS Security Reference manual under the Work Management section on Securing Spool Files, you will find a full page chart for this set of parameters and how they can be used in combination to achieve your specific objectives.

If you have any specific 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.