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

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 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.

Network Attributes and IBM i Security

By Rich Loeber

Protecting your IBM i system from network users can be a daunting and challenging task.  This tip will give you a few basics about it and, hopefully, get you thinking about this issue.

In the good old days, the IBM i (then called AS/400) was a closed system with the only connections to other systems being dedicated telephone lines running IBM’s SNA protocol.  Control over access from remote users was pretty easy given this environment.  Then, along came networks and the Internet and this all changed.  Soon, every IBM i on the block came with an Ethernet card and TCP/IP enabled.  PCs running PC Support (aka: iSeries Access) replaced dumb terminals and emulation cards and the IBM i became a much more open system.

Now, many users with iSeries Access, can use upload and download utilities to access data on your system and even do entry and updates directly from these utilities.  In fact, many installations have embraced these technology changes and implemented solutions with these capabilities in mind.

But, with the opening up of the system, new security considerations come into play.  Consider the classic situation of a payroll clerk running your company’s payroll application from their trusty old green screen application.  Using secure menu design, you can implement a system that easily restricts this user’s access to the payroll files.  However, the IBM i security for these files will probably be *USE or *CHANGE to allow this user to process updates.  If this user were to experiment with the iSeries Access utilities for download, that level of permission would allow them to quickly and easily download the entire payroll file to their PC, make changes and then upload it back to your system.  That is most probably something that you never had in mind when security was first envisioned for this application.

So, as the security officer, what’s a person to do?

For starters, there are some simple network attribute settings that you can use to implement  controls.  You can view the network attribute settings on your system using the Display Network Attributes (DSPNETA) command and make changes using the Change Network Attributes (CHGNETA) command.  The three network attributes that I want to direct you to in this tip are:

  •     Job action (JOBACN)
  •     Client request access (PCSACC)
  •     DDM request access (DDMACC)

The Job action setting controls how the system will process remote requests to run jobs.  It has three settings which are *REJECT, *FILE and *SEARCH.  The default setting from the factory is *FILE.  If you are concerned about this, just change the default setting to *REJECT and you’re safe.  When it is set to *FILE, the incoming request is queued to a network file for the designated user and the job must then be reviewed and started by the user. *SEARCH sets up a search of the network job table, but that is a topic for an entire tip by itself.

The PCSACC parameter (which has its roots in PC/Support, the early version of Client Access/iSeries Access or whatever name it goes by today), controls how a PC will have access to objects on your system.  This has no bearing at all on the use of the workstation emulator, it is just for object access for the various iSeries Access functions like download, etc.

The possible values for PCSACC are:

  • *REJECT – all object requests are rejected regardless of what they are.
  • *OBJAUT – OS/400 object authority is checked and supported (the default setting).
  •  *REJFAC – the system checks for a registered exit program and passes authentication to the exit program for processing.
  •   program name – the registered program name is called to verify authentication.

If you just don’t want anyone to have object access, then change this parameter to the *REJECT setting.  In this day and age of platform integration, this will often not work for you, so you’ll have to explore the other options. On the surface, *OBJAUT sounds like a good choice, and for many shops it will work nicely.  However, this means that any user profile that is authorized to process and/or update files from an interactive application could also have full access from the iSeries Access side, which may not be ideal for maximum security.  Using a program name or a registered exit point is the best method, but implementing exit point processing is a daunting challenge and much too much for a simple tip article.  I’d recommend that rather than create your own exit programs, you consider purchasing one of the many good third party solutions that are available in today’s market including SafeNet/i from Kisco Information Systems.

The DDM Request Access setting decides how to handle security from remote systems requesting data using the Distributed Data Management functions.  These can be from PCs or from other DDM compatible platforms such as other IBM i systems or even mainframes.

The possible values for the DDMACC are similar to those for PCSACC with the exception that *REJFAC is not offered.  The same advice for this applies as for PCSACC.  The program name option provides the only “exit point” available to control DDM access.

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.

IBM i SMTP Relay Controls

By Rich Loeber

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.

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 anmed QATMADRLST in library QUSRSYS.  Each member, which you will find appropriately named, contains the list entries for that type.  I 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.

Hacking Report For Our IBM i – A Current Update

By Rich Loeber

In 2013, we issued quarterly reports about attempts at hacking our IBM i system.  At the outset of that series, we explained that Kisco 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. This article will update the information from that study and review the current state of observed intrusion attempts from more recent activity.  The landscape of what we are seeing in the way hacks are being attempted has changed quite a bit since our last report.

The biggest shift that we have observed is a significant fall off in hacks attempting to gain access using brute force FTP attacks.  However, the overall access attempts have increased from an average of 14 times as day in 2013 to nearly 50 times a day now.  Even after a recent change in IP address for our server, the hackers found the new location almost right away.

Thanks to our SafeNet/i exit point network control software, we successfully thwarted all unauthorized accesses.  Of these, 351 were attempts to gain access via FTP and another 6,009 attempts were to get a Telnet signon session during the analysis period that went from October 2016 through early February 2017.   The big change here is that hackers seem to have given up on FTP Script attacks in favor of just pounding away at the Telnet port.

For the FTP attacks, the profiles named ADMINSTRA and ADMIN were the most popular ones used.  This was true for the 2013 study as well.  Other profile names used included ANONYMOUS, FTP, and WWW-DATA.  Once again, these users were consistent with profiles tried in the 2013 study.

Our SafeNet/i Telnet exit point stops access before a signon screen is presented, so all we have to look at for the 6,009 Telnet attempts that were thwarted is the source IP address that was used.  We continue to see certain IP addresses with repeated access attempts.  The leading violator for this study period traced back to the Asia Pacific Network Information Center in Australia.  This hacker attempted to open a Telnet session more than 1500 times over a 2 hour period.

Some good news from the study, which we also observed in 2013, is that most hackers have no idea that our server is running IBM i OS.  No attempts were observed to connect to the system using connection points other than FTP and Telnet.  It may be that this is because hackers have so much success using FTP or Telnet, but it indicates that a lot of other avenues of access are not being employed, at least in our experience.

For the full study period, our server posted close to 300 thousand network transactions.  This is nothing in today’s computing environment, some of our customer’s servers can record that level of activity in just a few minutes.  But, 2.1% of those network access attempts were not authorized by us.  This is up from 0.5% for our 2013 study.  That is a four fold increase!  You have to take hackers seriously.  Failure to do so will get you in the headlines as the next Yahoo.

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

Hiding Places for Malicious Code

By Rich Loeber

The last time I wrote, it was about tracking down hidden programs on your system that you might not know about (see article).  That time, it was trigger programs that could be sitting on your system just waiting for a specific event.  But, as I’ve thought about this issue since then, there are other places where someone could “hide” a call to a malicious program and easily get overlooked.

This time, we’ll look at two other areas for concern.  These are the system job scheduler and exit programs.  Both are ways that someone intent on doing harm to your system could hide some malicious program waiting for something to happen so it can jump out and cause problems.  In each case, the IBM i OS contains a way to review the programs that are sitting there and you should take a look periodically to see how each is being used on your system.

The IBM i OS has had a nice, easy to use job scheduler built into it for a long time now.  Most shops where I’ve done consulting work seem to know about it and use it for regularly scheduled jobs.  But, that also means that the programming staff is aware of it and could misuse or abuse it.

To review the current contents of the system job scheduler, use the i/OS command Work with Job Schedule Entries (WRKJOBSCDE).  This command will display information about every job in the system job scheduler.  It will tell you what the job is, how it is invoked and when it is next scheduled to run.  You should review each entry to make sure that you know what it is doing and when it is next scheduled to run.  A suspicious job, to me, would be one that is not set to run for quite a while in the future.  Most scheduled jobs happen frequently, either on a daily, weekly or monthly basis.  If you see something on a different schedule than one of these, I’d pay particular attention.

Another place you need to periodically review are the registered exit point programs on your system.  Exit points are hooks into i/OS processes.  These are provided in the i/OS so customers can add their own customized processing called from the OS during normal operations.  For example, many of the third party network security products now available on the market (including our own SafeNet/i) use exit points to add security checking to the various network operations in i/OS.  The potential problem is that a rogue program could get registered to an exit point just waiting for a specific OS event to occur before it jumps up and gets noticed.

To review exit programs registered on your system, use the i/OS command Work with Registration Information (WRKREGINF).  This will display a list of the i/OS exit points on your system, and remember that they are different for every level of the OS.  For each exit point, use the option ‘8′ to see if there is a registered exit program for the exit point.  If you find any, make sure that you know what they are there for.  Don’t be surprised to find some exit programs already registered.  If you are using a network security system, you should find many programs registered.  Also, some come registered with i/OS.  For example, you will find that the IBM product Service Director, uses some of the exit points as does the i/OS Mail Server Framework (MSF).  Just make sure that you can identify each program that shows up as a result of your review.

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.