Admin Alert: A Better Technique for Detecting Invalid Log-In Attempts
June 8, 2005 Joe Hertvik
Recently, I wrote an article explaining how to monitor the OS/400 history log, QHST, for invalid log-in attempts. No sooner had that issue of Four Hundred Guru hit the Web than I received a reader email that contained an excellent suggestion for finding even more invalid log-in attempts than I had found with my technique. Here’s the scoop.
Reader Shalom Carmel wrote in to note that my original solution was too focused on finding invalid log-in attempts from 5250 green-screen terminals, to the detriment of locating invalid log-in attempts originating from other applications and OS/400 servers. He wrote:
In your article, “Scanning QSYSOPR for Selected Messages,” you suggested that scanning the OS/400 history log, QHST, for message ID CPF2234 was the best way to find invalid log-in attempts. While this is true for users who are attempting to log-in through a workstation device, it misses the whole subset of users who perform their i5 and iSeries log-ins through non-interactive applications and services, such as FTP, ODBC, POP3, LDAP, and iSeries Navigator. For these users, the only place to search for log-in failure messages is in the OS/400 Audit Journal. You can find invalid log-in attempts for all users by running the green-screen Display Audit Journal Entries command (DSPAUDJRNE), like this:
DSPAUDJRNE ENTTYP(PW) OUTPUT(*PRINT)
or by running the Display Journal command (DSPJRN), like this:
DSPJRN JRN(QAUDJRN) ENTTYP(PW) OUTPUT(*PRINT)
And Shalom is correct. These commands produce detailed reports listing OS/400 log-in violations using any protocol or service, which is a big improvement over the QHST-only technique that I outlined in my previous article. They do this by showing all the security journal audit entries that deal with invalid password entries, which is specified on these commands by using entry type PW in the Journal Entry Types parameter (ENTTYP). If you want to go even farther and show authorization failure entries (journal entry type AF) as well as invalid password entries in your reports, you could run the commands like this:
DSPAUDJRNE ENTTYP(PW AF) OUTPUT(*PRINT)
or
DSPJRN JRN(QAUDJRN) ENTTYP(PW AF) OUTPUT(*PRINT)
However, please note that when you run the DSPAUDJRNE command for two journal entry types, it will produce one report for each type. If you’re interested in expanding these reports for even more journal entry types, the iSeries Information Center DSPAUDJRNE Web page shows a list of all journal entry types and their functions that you can use in either one of these reports.
But there are a few items that you need to be aware of to get the most out of these reports.
First, auditing control must be active on your OS/400 partition. Auditing controls creates journal entries in the system audit journal that detail actions involving user profiles actions or actions against system objects. To activate system auditing, the following system values must be set on the system.
1. The Auditing Control system value (QAUDCTL) must contain the *AUDLVL literal. If QAUDCTL has a value of *NONE (the shipped value), security auditing is disabled.
and
2. The Security Auditing Level system value (QAUDLVL) must contain the *AUTFAIL literal, which tells OS/400 to audit authorization failures.
|
While you can set up security auditing to monitor other possible security violations, these are the minimum requirements to set up user profile authorization monitoring. You can set these values by using the Work with System Values command (WRKSYSVAL), and selecting option 2=change to add the correct literals to each system value.
The other thing to keep in mind is this: while these reports detail the same log-in violation information, the report produced by the DSPAUDJRNE command is much more useful. The DSPJRN report shows raw journal entry data only with very little formatting or column headings while the DSPAUDJRNE report formats the data for easier comprehension. Another benefit of using DSPAUDJRNE over DSPJRN is that, because the information is condensed on one line, the DSPAUDJRNE report is four times smaller than the DSPJRN report for the same data. And that can make a big difference.
The fortunate thing is that, because OS/400 is such a full-featured solid operating systems developed over many years, there are several ways to extract the information you are looking for. And thanks to alert readers like Shalom, you can usually extract the best information that covers all the items you are looking for.
RELATED STORY
