origin of connection

MODMOD

pts.

Tags:

AS/400

DataCenter

Security

Today I ran a DSPAUDJRNE ENTTYP(PW) USRPRF(*ALL) and while skimming over the results I noticed several entries similar to the following : Violation Type : U User Profile : ADMIN Device Name : Communications Device Remote Name : Local Name : Network ID : Job Name : QZDASOINIT Job User : QUSER Job Number : 399141 Timestamp : 2006-09-19-03.39.04.647936 I know that QUSER/QZDASOINIT jobs are SQL connections, and there is no 'ADMIN' profile. But I am concerned by the frequency that this is occuring. Does anyone know if there is a way I can trace back the IP address the request originated from?

Asked: September 19, 2006 10:55 AM Last updated: December 17, 2009 7:46 AM

Answer Wiki

Last updated: September 19, 2006 11:21 AM GMT

TomClukay0 pts.
History
Contributors
- Ordered by most recent
- TomClukay0 pts.

Thanks. We'll let you know when a new response is added.

My first thought would be to check the joblog of the QZDASOINIT job in question to see if it provides any additional information; a specific user ID and IP address is sometimes listed there. Other than that, I’m not really sure.

Discuss This Question: 5 Replies

MODMOD Sep 19, 2006 12:02 AM GMT

Unluckily, looking at the job won't work. this only happens once every few days, and at unpredictable times. and when I look back at the history log, it ends the job right after the failed login. The up side, is I have noticed a trend where the same user has run a SQL connection right after the failed connects, so I'm going to research if something is odd with their DSN. But, I'd still like to be able to review, and be sure they have the same IP address as an origin. we never get one of the normal CPIAD12 : "Servicing user profile USER from client IP." messages. We're still running V4R4, and I don't think IBM even had the CPIAD12 messages until V4R3, so, it's entirely possible there simply isn't a log of what I need. I just find that odd since IBM is usually very good about security, and auditability.

0 pointsBadges:

report
KevinBattreall Sep 20, 2006 9:34 AM GMT

Try looking at the history log. DSPLOG JOB(686507/QUSER/QZDASOINIT) User WBQUOTE from client 172.17.10.233 connected to job 686507/QUSER/QZDASOIN User WBQUOTE from client 172.17.10.233 connected to job 686507/QUSER/QZDASOIN

0 pointsBadges:

report
MODMOD Sep 20, 2006 9:57 AM GMT

unluckily, the history log doesn't do any good :/ since the login fails, a CPIAD12 (the user/client message) never generates. all that I get is : Job 399134/QUSER/QZDASOINIT started on 09/19/06 at 02:49:49 in subsystem QSER and Job 399134/QUSER/QZDASOINIT ended on 09/19/06 at 03:38:53; 1 seconds used; en bringing up the details on those messages doesn't contain an IP address, so, without a successful login to record the IP address, it doesn't do much good. (history log was one of the first things I tried)

0 pointsBadges:

report
ParityError Sep 20, 2006 11:53 AM GMT

If all else fails, you could try a comm trace and search for the attempted ADMIN login, especially if you have a suspected IP address you can filter on it and shorten your search.

0 pointsBadges:

report
TomLiotta Dec 17, 2009 7:46 AM GMT

The big problem is running V4R4 which is long obsolete. If you could run a current release, the IP address would be logged in the journal entry itself. Your only reasonable choice is to attach an exit program to the various SQL exit points. Retrieve the remote IP address from the job attributes when the connection is initiated. Tom

125,585 pointsBadges:

report