Preliminary indications are that Rochester is doing a fast and capable job of addressing security problems that come up. Unfortunately, the truth is difficult to independently substantiate because of the IBM corporate policy of not commenting about security problems. While some may applaud IBM for its reticence because it ostensibly prevents "the bad guys" from learning about any alleged security weaknesses, the majority of security professionals maintain that real security comes from a more open policy of disclosure and correction. Stated another way, it's better to tell "the good guys" what the problem is and how to fix it than to be silent about the problem and hope that no bad guys stumble across it. While we can't do anything about IBM's unwillingness to discuss security problems, I can highlight the security problems (listed most cryptically as "Integrity Problems" in the PTF database) for you here and direct you to the fixes.
IBM recently issued a series of security-related PTFs that are absolutely frightening. There is scant information to be had about these PTFs outside of IBM and absolutely none to be had from internal sources. This in itself is unusual, but even more alarming is the dire warning included in the PTF cover letters for these fixes. The cover letter for one of the V5R1 PTF's (SI03047) states: "An OS/400 security exposure has been identified that may allow unauthorized access to system services through TCP/IP utilities. IBM strongly recommends that all customers apply this PTF immediately or that TCP/IP utilities not be run until the PTFs can be applied" (emphasis added). When IBM says discontinue the use of TCP/IP until these PTFs are added, I'd have to call the problem serious. You should, too.
This sounded like such a big deal to me that I spent a good portion of my time at the spring COMMON Conference in Nashville trying to find further information about these PTFs. It seemed that a great number of IBMers knew what these PTFs were about, but absolutely no one was willing to say anything more than "Load the PTFs!" No amount of pressure or guile was enough to get anyone to loosen up. The more I asked, the less information I got. One thing I was able to learn was that communication about these PTFs even within IBM has been restricted, down to a strictly need-to-know basis. This leads me to the conclusion that it must be damn serious and we should all abide by the admonition in the PTF cover letter quickly.
Working off of the cover letters themselves, here is the information that I was able to glean. The problem apparently allows an outsider to gain access to the system by using certain TCP/IP services. The PTF cover letters asks that you stop and restart the *DIRSRV, *FTP, *POP, and *REXEC servers, so it's a good bet that these are the ones involved--or at least most involved. It also means that these are *IMMEDIATE PTF's-- that is, they can take effect immediately and do not require an IPL. Now if you are already fairly current with your PTFs, stopping and restarting these servers may be all that is required. But there are enough PTFs out there that are listed as "Integrity Problem" (IBM code words for a security-related PTF) that you may want to load up on your favorite snack food, tune your radio to the ball game, and nestle down with your iSeries for a much-needed update.
While out on the IBM PTF database on the Web, I searched on the words "Integrity Problem" for V5R1, V4R5, and V4R4 and came up with 23, 116, and 250 (the apparent maximum) hits, respectively. This gives you some indication of the need to stay current with PTFs just from a security perspective, if for no other reason.
On a more ominous note, I was unable to confirm that PTFs were issued for this set of problems for any release prior to V4R4. Because no one at IBM is talking about this particular problem, it is unclear whether the problem(s) originated in V4R4, or (as is more likely) they preceded V4R4 but IBM has just not issued fixes for earlier releases. If you are still running at V4R3 or earlier, you should be very concerned. Check with your service provider to see if there have been any updates to the TCP/IP utilities.
The table below lists the different PTFs by supported release. Click on the PTF number to be linked directly to the IBM online PTF database.
| V5R1M0 | V4R5M0 | V4R4M0 |
Keep ODBC Users out of Selected Libraries
Q: How can I stop PC users from accessing any IBM Q*** libraries (such as QGPL)? I was testing the ODBC connection for user class *USER. I configured ODBC to point to the specific library, but I was still able to see the files in library QGPL through the MS Access "Import Object" prompt.
How can I eliminate the possibility that an experienced user could create ODBC connections and access whatever he wants?
A: This exact issue was the reason I got into the security software business in the first place. You have witnessed an exposure that most iSeries shops have, but have not yet addressed. The answer to your question depends a lot on how much access to data you would like your users to have.
If you want to completely lock out users from data via ODBC (and let's not forget other PC-based data access methods, such as FTP, DDM, and Client Access File Transfer, while we are at it), you can deploy a series of exit programs that prevent users from downloading data to their PCs. The exit programs in this scenario would be simple programs that simply reject all data access attempts. While this may be the (technically) easiest method of securing the data, unfortunately this heavy-handed approach would be ill received in most iSeries shops today. PCs have become such an integral part of IT operations that any server that cannot feed its hungry appetite for data is likely to have its days numbered. Writing a series of exit programs that permits the system administrator to allow well-regulated access to iSeries data is a much more difficult task--one that could easily chew up months and months of an experienced system programmer's time.
Fortunately, there are third-party packages that you can purchase that will perform just this kind of task (fair disclosure: my employer, The Powertech Group, is a vendor of this type of software), so you're probably much better off acquiring the technology than trying to build it. A good exit program package will show you who is accessing the system and allow you to set rules that define acceptable activity. To research a listing of security software vendors, go to the MC Press Vendor and Product Directory.
QSYSOPR Message Queue Security
Q: We had a user "cancel" a production job (not his) by displaying the QSYSOPR message queue and replying to an outstanding message. One of the choices on the users' regular daily menu is the option to DSPMSG, and from there, the user can get to all QSYSOPR messages. Users shouldn't have authority to anything but their own jobs and menus. If a typical user can do this using the IBM function, we have a security issue.
Our default assistance level is *Intermediate. Can I close the security hole by turning off the assistance level so a user can't change it or by changing the *PUBLIC authority on QSYSOPR?
A: The issue you face has nothing to do with assistance level; your user could reply to those messages at any assistance level. It has more to do with the security on the QSYSOPR message queue itself. You also suggest changing *PUBLIC authority to the QSYSOPR message queue. That's an option, but proceed with caution. If you remove anyone's authority to write (*ADD) messages to QSYSOPR, you risk getting your system wrapped into a tight little ball!
Here's how: Any batch (and many communication) jobs that generate error messages will submit those messages to the QSYSOPR message queue under the authority of the *CURRENT user of the batch job. If the *CURRENT user does not have enough authority to send a message to the QSYSOPR message queue, an exception error is generated and a new error message is sent to the QSYSOPR message queue (again). The *CURRENT user will still not be authorized to write this new error message to the QSYSOPR message queue, which will cause another exception, and another error message, and round and round you go.
To remove a user's ability to answer messages in the QSYSOPR message queue, you can either lock the message queue to an active job (such as the system console) or remove the user's *READ access to the queue (I know; it's counter-intuitive), but make sure that the user still has *OPR and *ADD authority.
When you answer a message in a message queue, you are really sending a new message (hence the *ADD) to the message queue that is a reply to an existing message (not a *CHANGE as you might guess). So removing the *READ capability will get you closest to the results you seek.
Adopting Authority
Q: On one of the EDTOBJAUT screens, a strange entry sometimes appears that says *ADOPT - *ALL, as in the example below.
Object . . . . . . . : JRNLIB
Library . . . . . : QSYS
Object type . . . . : *LIB
Object
User Group Authority
CSOBOWNER *ALL
QPGMR *ALL
*PUBLIC *EXCLUDE
*ADOPT *ALL
What does it mean when the system shows *ADOPT?
A: In this display, *ADOPT signifies that you are using adopted authority to see this display. I would guess that you are neither CSOBOWNER nor a member of the CSOBOWNER group profile and that you are neither QPGMR nor a member of the QPGMR group profile. This means that you are viewing this display by adopting the authority of CSOBOWNER, QPGMR, or some other user who has *ALLOBJ special authority.
John Earl is chief technology officer for the PowerTech Group in Seattle, Washington. This month, John's hobby is scanning the OS/400 PTF database for the string "Integrity Solution." If you have a security question or a favorite IBM code phrase, you can send John an email at
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online