Using IBM i Port Restrictions

By Rich Loeber

Anything that you can do to discourage unwanted access to your IBM i system is a good idea. So, when I heard about Port Restrictions, I immediately thought that it would be a great idea to just shut down all the unused ports on our test box.

Unfortunately, the term “Port Restrictions” is a little misleading in this case. The IBM i OS port restrictions provide a method to reserve a specific port or range of ports to be used by a specific user or group of users. Some may initially think that this is a way to define ports that specific users are NOT allowed to use, but the exact opposite is what happens. When a port restriction is in place, the named users are granted access to the port.

According to IBM documentation, port restrictions are specifically designed for use with end-user custom applications and are NOT intended for use with IBM i OS network functions. For that level of control, you will need to implement an exit point solution such as SafeNet/i from my company, Kisco Information Systems.

If you want to explore using port restrictions, you would do well to review which ports are used by the IBM i OS and carefully avoid implementing any restrictions for those ports. While doing research for this article, we played around with putting in a restriction for FTP on our test box. We restricted port 21 (FTP) to a specific user on our system and then ended and tried to restart FTP on the system. It shut down OK but would not start back up with the new port restriction in place. As soon as we removed the port restriction, FTP started right back up again. We run IBM’s security audit journal on this system and the attempt to start FTP with the port restriction in place also generated an Authority Failure entry (AF).

To avoid this kind of problem with normal TCP/IP functions in the IBM i OS, you should review the list of ports used by the OS. Here is a link to a good list of those ports at the IBM i support website:

https://www.ibm.com/support/pages/tcpip-ports-required-ibm-i-access-and-related-functions

If you think other port numbers are being used on your system, you can use the NETSTAT command with the *CNN (Connection Status) option to see which port numbers are in use. The display will default to standard port descriptions, but you can use the F14 function key to change the display to show actual port numbers. Look through the list to see if there are any port numbers not on the IBM i OS list. If you are more comfortable using IBM i Access Client Solutions, you can display this information by clicking on Network -> TCP/IP Configuration -> IPv4 -> IPv4 Connections. This interface will default to showing the port numbers right away and you can export a file of the information in CSV format to help with your analysis of the port numbers in use.

If you do want to create a port restriction assigning a port to a specific user profile, use the Add TCP/IP Port Restriction (ADDTCPPORT) command. IBM i documentation for the use of the command can be found here:

https://www.ibm.com/docs/kk/i/7.2?topic=ssw_ibm_i_72/cl/addtcpport.htm

Here at Kisco, we have a test IBM i server sitting out on the internet without a firewall so that we can observe bad behavior. Our system is protected by our SafeNet/i software and we find that it is secure as a result. While reviewing the bad behavior on this test system, we see access attempts using the full range of port numbers on a regular basis. These connection attempts are disallowed since there are no applications active on the system looking for traffic on those ports, but if you have applications using specific ports, then you should take a serious look at implementing port restrictions on those port numbers.

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

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 5250 Session Access Controls

By Rich Loeber

With more and more people working remotely, controlling remote access to your IBM i from 5250 terminal session users is more important than ever.  More IBM i shops are opening their systems up to remote access and a terminal session exposes your system to potential abuse.

A good way to control terminal access is by authorizing the remote IP address before allowing a terminal session to connect.  This way, you can control what specific IP address or address range can connect.  This kind of control can be established on your system using an exit point for the Telnet Device Initialization point.  Implementing this control will let you create your own exit program to validate the incoming IP address before allowing the Telnet server on your system establish the connection.  Kisco’s SafeNet/i Exit Point solution delivers this capability.

But, there is a small problem with this approach.  The problem is that at the point at which the IBM Telnet Device Initialization exit calls your program, the only user profile available is QSYS. All Telnet connections run under the QSYS user profile.  As a result, all exit point controls will be applied for all users, not on a user-by-user basis.

To implement source IP access controls by user profile, a much preferred method, you will need to create an initial program that can be recorded for each user profile that you want to control.  This is recorded in the INLPGM parameter for each user profile.  In your initial program, you can then access the source IP address that the user is connecting from and then do your own validation taking the actual signon user profile into account.

In your initial program, you can access the user profile signing on by a simple RTVJOBA CL command.  Finding out the IP address that is being used is a bit more complicated, but not all that difficult.

For this, you will need to code a call to IBM’s QUSRJOBI application program interface (API).  Specifically, you will need to use the call format JOBI0600.  This will retrieve a set of job information for the terminal session that includes the IP address for the user that is connecting.  It will be in position 308 of the receiver variable specified for the API.  If you’re already familiar with using IBM API’s, this is a fairly easy process.  If you’re new to API’s, then prepare for somewhat of a learning curve.

Once you have the combination of user profile and IP address, then it is just a matter of validating the combination against a control database that you can set up for this purpose.

You will find yourself wanting to check a range of IP numbers for validation purposes.  For example, you might want to specify that all IP addresses from 10.1.1.2 to 10.1.1.10 are legitimate.  Depending on the range of numbers, this can be problematic.  If you do a direct range comparison on the previous example, the range will not validate.  When we set this up here, we converted the IP address into a standardized 12 digit number.  For example, 10.1.1.10 ends up being stored at 010 001 001 010 (without the spaces).  This gives you a good base for doing a range check and not having to worry about the effect of the periods and different individual ranges.

Once you have your initial program created and fully tested, you can then implement it by recording the program name and library in the INLPGM for each user profile where you want this control added.  Since your initial program will always run when that user signs on to your system, we recommend that you throughly test your solution before locking down user profiles.  You don’t want to leave yourself in a place where you cannot sign in to your system.

If this looks like a little too much work for you, Kisco Information Systems has recently implemented this idea in is i2Pass 2FA Solution for the IBM i.  It is available for a free trial if you’d like to examine it and it adds Two Factor Authentication to your 5250 terminal session controls as another layer of protection.  An added benefit is that the software is supported in case you run into problems.

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

Configuring Telnet for SSL

By Rich Loeber

Updated March 2, 2020 for Access Client Solutions emulator.

I was recently asked to secure remote access for 5250 terminal sessions for one of my customers.  I did not have any experience securing Telnet on the IBM i, but I located some good documentation from IBM and was able to get the Telnet connection secured fairly quickly and easily.  This tip will show you how.

Many IBM i shops still use the 5250 terminal interface for administration and operation of their systems.  For them, the interface is well known and comfortable.  The problem is that when used for remote access, the Telnet data stream is passed as open text and it is easy for someone with malicious intent to snoop in on the data stream and capture user profile and password information.

Fortunately, there is a way on the IBM i to encrypt your 5250 terminal sessions by implementing SSL (Secure Sockets Layer) for your Telnet connections.  The IBM i uses a Telnet connection to support your 5250 terminal sessions.

There are two steps that you need to complete in order to set up SSL for Telnet.  Part one involves configuration work on your IBM i server.  Part two is what is needed on your client (your PC) in order to use the SSL connection.

The server configuration will require that you have option #34 (Digital Certificate Manager or DCM) of the base OS installed along with the HTTP server functions.  On our 6.1 test box, the HTTP Server is 5761DG1.  Before plunging into the project, I strongly recommend that you make sure that you have the latest HTTP server PTFs installed.  When we first tried to use DCM after upgrading our OS, it would not work and we needed the PTFs.

To do the configuration work on your host, we found the following article with step by step instructions from IBM and I recommend that you use this procedure:

http://www-01.ibm.com/support/docview.wss?uid=nas8N1010449

This process will require you to set up a self-issued digital certificate on your system and then assign it to several applications, including Telnet.  If you have never used the Digital Certificate Manager on your system, be prepared to take some time to get used to it.  The instructions from IBM are actually quite good.

After you get this configuration work done, make sure that you update the Telnet Attributes on your system using the CHGTELNA (Change Telnet Attributes) command.  When starting, make sure that the Allow Secure Socket Layer (ALWSSL) parameter is set to *YES.  This will allow both SSL and non-SSL Telnet connections.  Once you are satisfied with the way the SSL connection is working, you can consider changing this setting to *ONLY which will then refuse non-SSL connection attempts.

Once the server configuration work is done, you can move on to the client configuration work.  Again, I found a good set of instructions from IBM on this that you can access here:  (These instructions are for IBM i Access For Windows.)

http://www-01.ibm.com/support/docview.wss?uid=nas8N1011018

This process may require that you install additional Client Access components on your PC, so access to your Client Access install CD may be required.  The process will call for your to import the certificate you created into your PC and then reconfigure your terminal session to use SSL.  When importing the certificate, there is a standard password to use.  That instruction is easily missed, so watch out for it.

If you are using IBM i Access Client Solutions (ACS), the Java based access software, the instructions for the 5250 emulator are easier once the digital certificate has been established using DCM (above).  Using ACS, create a terminal session.  When the session has been created, select the Configuration option under the Communications drop down menu.  Update the “Protocol” to look as follows:

Note that when the Protocol is changed to “Telnet – TLS/SSL”, the “Destination Port” will be changed to 992.  Click on OK and the session configuration change will be set correctly.  Make sure that you now save it.

In addition to setting this up for my customer, I also took the long delayed step of setting this up for my own server.  It is something I should have done long ago and I encourage all IBM i shops to adopt this standard for remote access Telnet session.

After initially posting this tip, a friend contacted me to suggest that implementing SSL on Telnet also helps customers with their PCI compliance requirements.  PCI requires 2 factor authentication.  He reported that one of his customers was able to meet this requirement using SSL.  The two factors involved are the password and the digital certificate.  Two factor authentication calls for something you know and something you have.  SSL for Telnet does just that.  (They also require use of VPN for any remote access.)

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.

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

By Rich Loeber

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

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

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

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

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

STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)

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

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

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

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

Network Intrusion – An Allegory

By Rich Loeber

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

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

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

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

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

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

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

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

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

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

Can NAT and IP Packet Filtering Work For You?

By Rich Loeber

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

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

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

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

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

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

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

The Case For Implementing Exit Points

By Rich Loeber

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

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

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

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

Case #1:

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

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

Case #2:

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

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

Case #3:

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

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

To sum up:

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

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

Network/Internet Security

By Rich Loeber

Updated October 20, 2020

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

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

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

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

  • System security – including your system level use of user profiles and regularly rotated passwords.  For most IBM i shops, this will be your last line of defense, so plan it well.  Consider using longer passwords or pass phases that are now supported by the IBM i OS.
  • Network security – this commonly involves implementation of a firewall between your network and the Internet but can also include services available from your ISP.  On the IBM i there are also things that can be done at the IBM i OS server level via exit programs that can address network security issues.
  • Application security – your applications should be designed to integrate with your security policies.  Application software can easily be misused and abused and your applications should be designed with this in mind, especially those applications that are open to network and Internet users.
  • Transmission security – when you use an uncontrolled network like the Internet, your data will be open to anyone while it is in transit from one place to another.  To protect your data, you need to consider encryption techniques and the use of Secure Sockets Layer (SSL) on your IBM i along with encryption.  Encryption should be required for all 5250 terminal connections.

In your plan for Network and Internet security, you need to have a plan for each of these layers of control in order to safeguard your system.  And, even then, a bully or a sneak might still get past you, so watch out.

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

Securing IBM i Socket Connections

By Rich Loeber

IBM i has included security exit points for adding protection for platforms that work with connected systems.  These exit points have been included in the IBM i OS for years and have regularly expanded to provide for more and more network applications.  Using the exit points, you can add protection for FTP, ODBC, File Server, Remote Command submissions and much more.  This has gone a long way towards making the IBM i a truly secure platform.

For many years, however, there were a whole group of applications that could run under the radar on the IBM i and not get picked up by the existing exit point traps.  These are socket level communication applications.  The good news is that starting with IBM i 7.2, IBM has added three new exit points to address this issue.

The three exit points added let you control Socket Accepts, Socket Connects and Socket Listens.  Applications that use socket connections can sometimes also use other network services, like FTP or remote commands, which existing exit points will cover; but some applications bypass all other network services and work directly with data at the socket level.  Having control over socket connections is critical to having a secure environment on your IBM i.

The TCP Accept exit point watches for systems trying to establish a connection to your system at the socket level.  Using the exit point, you can control which IP addresses to accept or reject, what user profiles to allow use and even control what TCP/IP port numbers that the connection can use.

The TCP Connect does the same thing as Accept except it is for outward connections from your IBM i system to remote systems.  The same controls can be implemented controlling the IP address, user profile and port number.

The TCP Listen runs on your IBM i and watches for incoming TCP Connects from remote systems.  A typical socket connection starts with a Listen and then proceeds on to the Connect with subsequent Accept.  Following this sequence, socket communication can take place without any other network services being involved.

Some of the existing applications that run on the IBM i and use these socket connections include the Apache HTTP server which does not have any additional exit point control available.  If you want to control who can use a browser on your system, this is a way to approach this issue.

Another area where this can help improve security on your system is by denying that initial contact with your system.  By denying the initial contact, a potential hacker is denied information about the system they are attempting to connect with.  For example, when you try to sign on to your system via FTP and before you even attempt to enter a user profile, the following is what you see for your FTP session:
This clearly identifies your system as IBM i by virtue of the reference to the QTCP user profile.  A savvy hacker will know that and this information will inform their future attempts to gain access to your system.  Many of the other TCP network services on the IBM i return this kind of identifying information in response to connection requests even when an invalid user profile is used.

When you implement socket level controls on your IBM i, you can deny access to all but approved IP addresses and port numbers.  When you do this, then this is what that same FTP access attempt looks like to a hacker:
Denying this connection at the socket level stops the session before any information is sent back to the requester.

Adding implementation of the socket exit points on your system can help you achieve your security goals for the IBM i.  The good news is that you don’t need to code your own solution if you don’t have the time or the talent.  Kisco’s SafeNet/i software, in its recently announced Release 11 of the product, now includes general use implementations of all three of these exit points along with all other security exit points available in the IBM i OS.

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